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 problems. These tests
> > are off by default for a good reason.
>
> Sigh. Without the deep protocol tests (and the implicit greylisting), my
> systems are inundated with spam. We find that spamassassin is missing far too
> many spam messages. With the deep protocol tests enabled, our spam has been
> reduced to almost zero. So I don't think turning them off is a realistic
> option for us. Thanks for implementing this feature; it really helps.
A possible option is to periodically grab the SPF records of Amazon,
Google, and the like, and to whitelist those IP addresses permanently.
I mention Google here because they, too, would not retry from the
same client IP address when I was using deep protocol tests.
> If we don't use the deep protocol tests, we would probably have to use
> something like milter-greylist. Perhaps that might give a better outcome,
In this specific case, "postscreen_command_time_limit = 29s" would
work around the problem. But that is not robust.
A more robust fix may be to consider the deep protocol tests as
"completed" when receiving "RSET" after "RCPT TO" and the session
passes all tests up to that point. Then, "RSET" kind-of becomes
like "QUIT", except perhaps that it does not hang up.
This would also work around a problem where I have seen Sendmail
make two connections from the same IP address (like Amazon) and
make the second connection before closing the first one. But at
least they did not run into the postscreen time limit.
Wietse
