ietf-smtp
[Top] [All Lists]

Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.

2005-05-10 08:39:55

On Mon, May 09, 2005 at 04:11:59PM -0400, Bruce Lilly wrote:
      X.7.1   Delivery not authorized, message refused

         The sender is not authorized to send to the destination.  This
         can be the result of per-host or per-recipient filtering.  This
         memo does not discuss the merits of any such filtering, but
         provides a mechanism to report such.  This is useful only as a
         permanent error.
[ ... ]
No:
o there is no 4.7.1, only a 5.7.1.

The RFC says:
   Document Conventions
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in BCP 14 [RFC2119].

My version of the RFC says (like yours):

   This is useful only as a permanent error.

If the author of the RFC had the intention to forbid it for non-permanent
errors he would have had to write

   This MAY only be used for permanent errors.
or
   This MUST NOT be used for non-permanent errors.

As he didn't, the comment about usefulness is a hint. Not more, not less.

I think we should stick to what is written and not to what one could interpret
from it.

------------------------------------

On the topic of
   450 and 451
SMTP codes ...

http://cvs.puremagic.com/viewcvs/greylisting/schema/whitelist_ip.txt?rev=1.11

# Before submitting a potential entry, please check that your implementation
# uses the 451 error code (not 450 or another 4xx code).  Some problems have
# been reported for sites like MSN/Hotmail, Prodigy, and various other 
# senders that appear to be having "weird" retry patterns (sometimes 
# resulting in bounces) when using code 450 or others.

# Because error code 450 is most commonly used for a mailbox lock failure,
# many sites seem to treat it as a very short duration failure, and will
# retry several times within seconds, and then bounce the mail, while they
# handle a code 451 more "normally".

We currently use

    451 4.7.1 Delivery not authorized, message refused for policy reasons, try 
again later

as we have noticed that a lot of communication partners often treat 450 -
besides the problems mentioned above - as a permanent error *sigh*

        \Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"