Re: SMTPD Policy Readme Suggestion
- On Sunday 30 July 2006 09:31, Wietse Venema wrote:
> Scott Kitterman:OK.
> > 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...]
> Whenever possible, a receiver-
> SMTP SHOULD test the first digit (severity indication) of the reply
> 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.
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.