[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.
[ ... ]
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",
    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.
   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 ...

# 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*


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"