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 postfix/postscreen[18143]: [ID info] NOQUEUE: reject:
> RCPT from [54.240.13.2]:36074: 450 4.3.2 Service currently unavailable;
> from=<2014091416414306531411d1354e8fb388268666764...@bounces.amazon.com>,
> to=<X@Y>, proto=ESMTP, helo=<a13-2.smtp-out.amazonses.com>
> Sep 14 12:46:52 ti74 postfix/postscreen[18143]: [ID info] COMMAND TIME LIMIT
> from [54.240.13.2]:36074 after RSET
> Sep 14 12:46:52 ti74 postfix/postscreen[18143]: [ID info] PASS NEW
> [54.240.13.2:36074
> Sep 14 12:46:52 ti74 postfix/postscreen[18143]: [ID info] DISCONNECT
> [54.240.13.2]:36074
As documented, deep protocol tests (the tests after the 220 greeting
and DNSBNL queries) require that a "good" SMTP client hangs up
before it is permitted to talk to a Postfix SMTP server process.
> For some reason that is not clear to me, the session does not disconnect by
> itself, and postscreen times it out after the postscreen_command_time_limit
> expires 5 minutes later.
The remote SMTP client sent RSET, and then went into a coma. That
is a bug in the remote SMTP client. If the client had sent QUIT and
hung up, postscreen would immediately whitelist it.
As long as the SMTP session still exists, the client may still make
a mistake, and postscreen will not whitelist it.
If postscreen could look into the future and predict that the client
won't make mistakes in the remainder of an SMTP session, then I
would be very rich.
Don't use deep protocol tests if they cause problems. These tests
are off by default for a good reason.
Wietse
