On Wed, Nov 17, 2010 at 07:26:35PM +0000, George Forman wrote:
> > No, RFC 2821/5321 notwithstanding, Postfix must reject RSET, to give
> > clients a chance to disconnect before before real mail is rejected.
> > So DO NOT exempt "rset_cmd". Otherwise, the change makes sense. Postfix
> > gives the intended response after "." (Queue file write error) and
> > the next command if any (say RSET) triggers a "421" disconnect.
> >
> > --
> > Viktor.
>
> Thanks for the feed back. I have tested the changes. The sequence is now:
> .
> 451 4.3.0 Error: queue file write error
> RSET
> 421 4.3.0 Mail system error
>
> This change does violate RFC2821/5321 for RSET:
> An SMTP server MUST NOT close the connection as the
> result of receiving a RSET; that action is reserved
> for QUIT (see Section 4.1.1.10).
No, an SMTP server may return 421 and disconnect any time it sees fit.
http://tools.ietf.org/html/rfc2821#section-3.9
> By excluding rset_cmd as in the code snipet,
> the RSET response is 250 OK.
> The next command's response '421 4.3.0 Mail System Error'.
It is wrong to exclude RSET, since a buffered error response may then
incorrectly reject a new mail transaction. It is better to reject
RSET and give a sanely behaved client a chance to go away before it
runs into more trouble.
For now the impact is only theoretical, since "state->access_denied" is
only set with "delay_reject = no" when a client fails client restrictions,
and so any transaction would have been refused in any case, but it is
best to not set traps for future code changes.
--
Viktor.
