On Mon, Sep 15, 2014 at 10:24 PM, Wietse Venema wie...@porcupine.org wrote:
When you follow the include: directives you get lists of net/mask
forms that are easy to convert to postscreen.
$ host -t txt spf1.amazon.com | tr ' ' '\12' | sed -n '/^ip.:/{
s/^ip.:\(.*\)/\1 permit/
Jose Borges Ferreira:
On Mon, Sep 15, 2014 at 10:24 PM, Wietse Venema wie...@porcupine.org wrote:
When you follow the include: directives you get lists of net/mask
forms that are easy to convert to postscreen.
$ host -t txt spf1.amazon.com | tr ' ' '\12' | sed -n '/^ip.:/{
On 15 Sep 2014, at 14:31 , Andrew J. Schorr asch...@telemetry-investments.com
wrote:
I could be wrong, but if greylisting works reliably,
And there we get to the root of the problem. It does not work reliably because
it ignores how large companies like Google and Yahoo and Amazon send mail.
Am 16.09.2014 um 12:47 schrieb LuKreme:
On 15 Sep 2014, at 14:31 , Andrew J. Schorr
asch...@telemetry-investments.com wrote:
I could be wrong, but if greylisting works reliably,
And there we get to the root of the problem. It does not work reliably
because it ignores how large companies
-Ursprüngliche Nachricht-
Von: owner-postfix-us...@postfix.org [mailto:owner-postfix-
us...@postfix.org] Im Auftrag von LuKreme
Gesendet: Dienstag, 16. September 2014 12:48
An: postfix-users@postfix.org
Betreff: Re: postscreen deep protocol tests and Amazon timeouts
On 15 Sep 2014
Am 16.09.2014 um 13:41 schrieb Uwe Drießen:
just not how email works for large senders.
If my Server had a problem the big sender becomes the
same error like greylisting
no, because he just tries later or another MX
If the big sender can not handle it they breaks the RFC not I.
They
Am 16.09.2014 um 13:41 schrieb Uwe Drießen:
E-Mail is not real time communication by design !
the problem is ,users are ignorant to this *g
Best Regards
MfG Robert Schetterer
--
[*] sys4 AG
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
Sitz der Gesellschaft:
: postscreen deep protocol tests and Amazon timeouts
On 15 Sep 2014, at 14:31 , Andrew J. Schorr aschorr@telemetry-
investments.com wrote:
I could be wrong, but if greylisting works reliably,
And there we get to the root of the problem. It does not work reliably
because it ignores how large
On September 16, 2014 2:03:36 PM Robert Schetterer r...@sys4.de wrote:
Am 16.09.2014 um 13:41 schrieb Uwe Drießen:
E-Mail is not real time communication by design !
the problem is ,users are ignorant to this *g
Never seen a time limithed offer ?
Hi,
I enabled postscreen deep protocol tests in postfix 2.11.1 and found this
problem with Amazon. I see these entries in the log:
Sep 14 12:41:45 ti74 postfix/postscreen[18143]: [ID info] CONNECT from
[54.240.13.2]:36074 to [38.76.0.61]:25
Sep 14 12:41:51 ti74 postfix/postscreen[18143]: [ID
Andrew J. Schorr:
Hi,
I enabled postscreen deep protocol tests in postfix 2.11.1 and found this
problem with Amazon. I see these entries in the log:
Sep 14 12:41:45 ti74 postfix/postscreen[18143]: [ID info] CONNECT from
[54.240.13.2]:36074 to [38.76.0.61]:25
Sep 14 12:41:51 ti74
Wietse Venema wrote:
As long as the SMTP session still exists, the client may still make
a mistake, and postscreen will not whitelist it.
Thanks for the explanation. I am surprised that Amazon's mailservers are so
stupid.
Don't use deep protocol tests if they cause problems. These tests
are
Am 15.09.2014 um 18:19 schrieb Andrew J. Schorr:
Wietse Venema wrote:
As long as the SMTP session still exists, the client may still make
a mistake, and postscreen will not whitelist it.
Thanks for the explanation. I am surprised that Amazon's mailservers are so
stupid.
Don't use deep
Andrew J. Schorr:
Wietse Venema wrote:
As long as the SMTP session still exists, the client may still make
a mistake, and postscreen will not whitelist it.
Thanks for the explanation. I am surprised that Amazon's mailservers are so
stupid.
Don't use deep protocol tests if they cause
Wietse Venema wrote:
A possible option is to periodically grab the SPF records of Amazon,
Google, and the like, and to whitelist those IP addresses permanently.
I had been hoping that the whitelisting would obviate the need to do
something like this. Perhaps with the extra whitelists that I
li...@rhsoft.net wrote:
what i recently implemented was
* give thx MX a second IP
* add it everywehere as backup-mx
* disable postcreen WL on that IP
I am doing the same thing here. It is helpful, but I don't think it solves all
problems. The implicit greylisting of the deep protocol tests
Am 15.09.2014 um 22:31 schrieb Andrew J. Schorr:
li...@rhsoft.net wrote:
what i recently implemented was
* give thx MX a second IP
* add it everywehere as backup-mx
* disable postcreen WL on that IP
I am doing the same thing here. It is helpful, but I don't think it solves all
Andrew J. Schorr:
Wietse Venema wrote:
A possible option is to periodically grab the SPF records of Amazon,
Google, and the like, and to whitelist those IP addresses permanently.
I had been hoping that the whitelisting would obviate the need to do
something like this. Perhaps with the
18 matches
Mail list logo
