Victor Duchovni:
> On Wed, Nov 17, 2010 at 01:01:05PM -0500, Victor Duchovni wrote:
>
> > > I am looking for suggestions on a longer term solution.
> > > I have made a change in smtpd_proto function:
> > >
> > > New code:
> > > /* XXX We use the real client for connect access control. */
> > > if (state->access_denied &&
> > > (! (cmdp->action == quit_cmd || cmdp->action ==
> > > rset_cmd))) {
> > > smtpd_chat_reply(state, "%s", state->access_denied);
> > > state->error_count++;
> > > continue;
> > > }
> >
> > 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.
>
> The problem here is that smtpd_access_denied is misused from its original
> intent of reporting 503 after a client fails to heed a 554 banner. Perhaps
> the intended "421" disconnect on the next command should use a different
> mechanism, or alternatively the code above could peek at the 2nd and 3rd
> characters of the buffer and disconnect if these match "21" (a big ugly,
> but avoids new complexity in the internal state).
I forced the 503 reply code for RFC 2821 compliance in Postfix
1.1.0, and I concluded independently that we can make an exception
for [45]21 here, since those replies are final.
Wietse
