> Date: Wed, 17 Nov 2010 13:01:05 -0500
> From: victor.ducho...@morganstanley.com
> To: postfix-users@postfix.org
> Subject: Re: Invalid response code: 503 5.7.0 Error: access denied
>
> On Wed, Nov 17, 2010 at 05:24:12PM +0000, George Forman wrote:
>
> >
> > The scenario is as follows (see log snipet below for sequence details):
> > The client MTA attempts to send a message. On the DOT command, Postfix
> > returns: '451 4.3.0 Error: queue file write error'
>
> This happens when a milter malfunctions. Check your logs, they contain
> lots of relevant details.
Yes - The milter is failing to respond in this case.
>
> > The client MTA sends a RSET command. Postfix responds with '503 5.7.0
> > Error: access denied'
>
> Postfix is intended to disconnect with a:
>
> 421 4.3.0 Mail system error
>
> The code in question:
>
> if (smtpd_milters != 0 && (state->err & CLEANUP_STAT_WRITE) != 0)
> state->access_denied = mystrdup("421 4.3.0 Mail system error");
>
> does not have the intended effect.
>
> > The client MTA ignores the RSET response (based on RFC2821).
>
> It should not ignore a 5XX return code from RSET. It should disconnect.
>
I agree. The MTA client is not honoring the response code sent by Postfix.
This is the crux of our problem. We cannot get the remote MTA to fix their
client
and we're forced to make changes.
> > The client MTA sends MAIL FROM command. Postfix responds with '503 5.7.0
> > Error: access denied'
>
> The client is wrong to keep re-using a session after a 5XX error on RSET.
>
> > My analysis has shown the Postfix's milter interface fails when waiting
> > for a response.
>
> More likely, the milter, not the interface, but this is what I
> expected before getting this far in your post.
>
> > I am still actively investigating specifically the vstream event that
> > triggers CLEANUP_STAT_WRITE to be returned.
>
> Most likely a milter failed. Look in the logs!
Yes it is the milter service that is failing in this situation. I should have
made that clear
from the beginning.
>
> > My QUICK FIX was to modify the 503 to a 521 error code in smtpd.c
> > (smtpd_proto function).
>
> > 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.
>
> --
> 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).
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'.
Thoughts?
George
