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).
--
Viktor.
