[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postfix-users
Subject:    Re: SMTPD Policy Readme Suggestion
From:       Scott Kitterman <postfix () kitterman ! com>
Date:       2006-07-30 14:30:13
Message-ID: 200607301030.13887.postfix () kitterman ! com
[Download RAW message or body]

On Sunday 30 July 2006 09:31, Wietse Venema wrote:
> Scott Kitterman:
> > Currently, the policy readme does not give guidance on when to use REJECT
> > per Access 5 (thus using reject_code, which defaults to 554) or when it
> > would be more appropriate to use a different rejection code.  It just
> > refers to Access 5.  I believe it might be useful to have an informative
> > note providing at least a hint that the default code is not appropriate
> > at all stages of the SMTP dialogue.
> >
> > Based on at least my reading of RFC 821 (Para 4.3 Sequencing of Commands
> > and Replies), the only SMTP command to which 554 is an appropriate
> > response is DATA.  RFC 2821 reads similarly (Para 4.3.2 in this case).
> >
> > In the Protocol description section,
> > http://www.postfix.org/SMTPD_POLICY_README.html#protocol, there is
> > already an Access 5 discussion near the end.  My thought was that a
> > sentence or two might be inserted after the current temporary reject
> > discussion.  Something like:
> >
> > "NOTE: Access 5 REJECT actions use reject_code (default:554) to determine
> > the result code.  The default code (554) should only be only in the
> > "DATA" and "END-OF-MESSAGE" stages.  For the "HELO/EHLO", "MAIL FROM",
> > and "RCPT TO" stages Access 5 550 action is generally more appropriate."
>
> This is not necessary. All 5XX replies imply a permanent error,
> and ALL 4XX replies imply a transient error. RFC2821 specifies 554
> in responses other than DATA. See also section RFC2821 4.2:
>
>    The list of codes that appears below MUST NOT be construed as
>    permanent. [...new codes may be added over time...]
>
> and:
>
>    Whenever possible, a receiver-
>    SMTP SHOULD test the first digit (severity indication) of the reply
>    code.
>
> I suppose RFC821 has similar text, because that is what I used when
> I implemented Postfix.
>
> The extra paragraph is redundant for someone who already knows the
> RFC. And it does not help someone unfamiliar with the RFC. The
> extra paragraph just increases their information overload problem
> with irrelevant content.
>
> > I discovered an error in my policy server where I was incorrectly using
> > 554 instead of 550 after RCPT TO.  I don't know if this is actually
> > significant enough to warrant an update, but I thought it might save
> > someone else making the same mistake I did.
>
> It's not a mistake, and any software that breaks because of the difference
> is has a serious robustness problem.
>
> 	Wietse

OK. 

Nothing broke.  I was trying to better understand a Kmail issue and an 
associate of mine who uses Sendmail got a 550 from Sendmail while I was 
producing a 554 with my policy service.  It ended up being a distraction from 
the real source of the problem.

It seemed like a minor point for increased correctness, but it certainly makes 
sense to not want to increase the information overload.

Thank you,

Scott K
[prev in list] [next in list] [prev in thread] [next in thread]