Le 1 mai 2013 à 17:15, Simon Waters a écrit :
> [...]
>
> Secondary question - can I force the output of "sendmail -bv" to go to a
> specific email address - seems always to go to the invoker - e.g. can I
> easily send this to the end users email address (which I know). Since an
> option to ge
On 02/05/13 08:12, Axel Luttgens wrote:
Le 1 mai 2013 à 17:15, Simon Waters a écrit :
[...]
Secondary question - can I force the output of "sendmail -bv" to go
to a specific email address - seems always to go to the invoker -
e.g. can I easily send this to the end users email address (which I
On 2013-05-01 07:14:37 -0500, /dev/rob0 wrote:
> On Wed, Apr 24, 2013 at 03:44:19PM -0700, Steve Jenkins wrote:
> > warn_if_reject reject_unknown_reverse_client_hostname,
>
> Safe, because many large receivers do this as well.
That's interesting. Several months ago, I intended to add it,
On 2013-05-01 6:31 PM, Ben WIlliams wrote:
The version is postfix 2.3.3.
Really? 7 yrs old, unsupported since the last patch (2.3.19) in 2009...
I'd suggest updating...
--
Best regards,
Charles
Am 02.05.2013 14:08, schrieb Charles Marcus:
> On 2013-05-01 6:31 PM, Ben WIlliams wrote:
>> The version is postfix 2.3.3.
>
> Really? 7 yrs old, unsupported since the last patch (2.3.19) in 2009...
stoneold yes, but unsupported not really
[root@vmware-recovery:~]$ rpm -qa | grep postfix
post
On 5/2/2013 1:20 AM, Michael Ionescu wrote:
> I have a corner case where I need to allow an emails generated at my
> site with certain off-site sender addresses to be routed through my MTA
> to the off-site smarthost officially responsible for the sender domain.
>
> This can be easily done using s
On 5/2/2013 6:27 AM, Vincent Lefevre wrote:
> On 2013-05-01 07:14:37 -0500, /dev/rob0 wrote:
>> On Wed, Apr 24, 2013 at 03:44:19PM -0700, Steve Jenkins wrote:
>>> warn_if_reject reject_unknown_reverse_client_hostname,
>>
>> Safe, because many large receivers do this as well.
>
> That's int
On 2013-05-02 9:15 AM, Reindl Harald wrote:
Am 02.05.2013 14:08, schrieb Charles Marcus:
>On 2013-05-01 6:31 PM, Ben WIlliams wrote:
>>The version is postfix 2.3.3.
>Really? 7 yrs old, unsupported since the last patch (2.3.19) in 2009...
stoneold yes, but unsupported not really
Unsupporte
Am 02.05.2013 21:16, schrieb Charles Marcus:
> On 2013-05-02 9:15 AM, Reindl Harald wrote:
>> Am 02.05.2013 14:08, schrieb Charles Marcus:
>>> >On 2013-05-01 6:31 PM, Ben WIlliams wrote:
>>The version is postfix 2.3.3.
>>> >Really? 7 yrs old, unsupported since the last patch (2.3.19) in 20
On Thu, May 02, 2013 at 03:16:28PM -0400, Charles Marcus wrote:
> On 2013-05-02 9:15 AM, Reindl Harald wrote:
> >Am 02.05.2013 14:08, schrieb Charles Marcus:
> >>>On 2013-05-01 6:31 PM, Ben WIlliams wrote:
> >The version is postfix 2.3.3.
> >>>Really? 7 yrs old, unsupported since the last pa
On 2013-05-02 3:24 PM, Reindl Harald wrote:
Am 02.05.2013 21:16, schrieb Charles Marcus:
Unsupported according to the postfix site..
says who?
Wietse?
ftp://ftp.porcupine.org/mirrors/postfix-release/index.html
Scroll down, genius. The 'no longer supported stable releases' start
with 2.6
Am 02.05.2013 21:30, schrieb Charles Marcus:
> On 2013-05-02 3:24 PM, Reindl Harald wrote:
>> Am 02.05.2013 21:16, schrieb Charles Marcus:
>>> Unsupported according to the postfix site..
>
>> says who?
>
> Wietse?
>
> ftp://ftp.porcupine.org/mirrors/postfix-release/index.html
> Scroll down, g
Hi all.
I have received reports from users that mail originating from Russia have been
blocked. I am indeed blocking cyrillic encoding via header_checks (because it's
usually been spam) and as a solution I would like to implement an opt-out
system.
Is it possible? Can I have some users skip header
On Thu, May 02, 2013 at 09:33:56PM +0200, Reindl Harald wrote:
> Am 02.05.2013 21:30, schrieb Charles Marcus:
> > On 2013-05-02 3:24 PM, Reindl Harald wrote:
> >> Am 02.05.2013 21:16, schrieb Charles Marcus:
> >>> Unsupported according to the postfix site..
> >
> >> says who?
> >
> > Wietse?
>
On 5/2/2013 2:42 PM, Chris wrote:
> Hi all.
>
> I have received reports from users that mail originating from Russia have been
> blocked. I am indeed blocking cyrillic encoding via header_checks (because
> it's
> usually been spam) and as a solution I would like to implement an opt-out
> system.
On 02.05.2013 17:57, Noel Jones wrote:
>> [...]
>> prequeue proxy virusfilter [...] precludes
>> rewriting the Received: header [...]
>> QUESTION 1: Is this correct?
>> [...]
>> QUESTION 2: Is there a definitive overview of all the ways postfix
>> detects loops and at what stages these are employ
On 5/2/2013 4:14 PM, Michael Ionescu wrote:
>
>
> On 02.05.2013 17:57, Noel Jones wrote:
>>> [...]
>>> prequeue proxy virusfilter [...] precludes
>>> rewriting the Received: header [...]
>>> QUESTION 1: Is this correct?
>>> [...]
>>> QUESTION 2: Is there a definitive overview of all the ways post
Am 03.05.2013 00:40, schrieb Noel Jones:
> Postfix transport features are global to each instance, and are
> non-conditional. If you're using sender dependent transports, you're
> going to have a hard time without multiple instances
not if you are firm with mysql-tables and queries
sender/sende
On Thu, May 02, 2013 at 11:14:23PM +0200, Michael Ionescu wrote:
> > "C" Multiple postfix instances is the preferred solution. Postfix
> > supports multiple instances on the same machine quite well. The
> > added overhead to the machine is negligible. There is some extra
> > administration, but
Greetings,
After having a problem with a lot of mail being queued by a compromised
end users mailbox, I was unable to find a script able to remove messages
from the queue based on the sasl_username.
The pfdel script is very handy for removing things when the from/to
addresses are stable, but
On 5/2/2013 10:53 PM, Nick Bright wrote:
Greetings,
After having a problem with a lot of mail being queued by a
compromised end users mailbox, I was unable to find a script able to
remove messages from the queue based on the sasl_username.
The pfdel script is very handy for removing things w
Hi,
After many years of hassle free use from our email system we are now getting
a rather odd disconnect as shown below.
May 3 16:07:36 spambox nss_wins[14039]: connect from
sender.remote.com[1.2.3.4]
May 3 16:07:38 spambox postgrey[2865]: action=pass, reason=client AWL,
client_name=remote.remo
On Thu, May 02, 2013 at 10:31:07PM -0700, mailtime wrote:
> After many years of hassle free use from our email system we are now getting
> a rather odd disconnect as shown below.
>
>
> May 3 16:07:36 spambox nss_wins[14039]: connect from
> sender.remote.com[1.2.3.4]
Yuck, nss_wins openlog(3) b
Thanks for your thoughts i will follow that article and see what i get back.
In regard to the 14039, no only the 4 entries (pertaining to that
transaction)
I do finally have a log file from one of sending mail servers though.
20:08:45.214 RX: <220 spambox.co.nz ESMTP Postfix>
20:08:45.214 TX:
20
On Thu, May 02, 2013 at 11:09:35PM -0700, mailtime wrote:
> 20:08:45.927 TX: SIZE=6469087>
The message size is ~6 MB.
> 20:08:50.163 TX:
> 20:08:50.323 RX: <354 End data with .>
Message content transmission starts at 20:08:50.323.
> 20:09:12.407 SMTPResponse(Sending Body): Socket error - 100
25 matches
Mail list logo
