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"
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: RFC3463, 450 reply codes, and 4.7.1 extended codes., (continued)
- Re: RFC3463, 450 reply codes, and 4.7.1 extended codes., Hector Santos
- RE: RFC3463, 450 reply codes, and 4.7.1 extended codes., Vaudreuil, Greg M (Greg)
- RE: RFC3463, 450 reply codes, and 4.7.1 extended codes., Bruce Lilly
- Re: RFC3463, 450 reply codes, and 4.7.1 extended codes., Valdis . Kletnieks
- Re: RFC3463, 450 reply codes, and 4.7.1 extended codes., Bruce Lilly
- Re: RFC3463, 450 reply codes, and 4.7.1 extended codes.,
Markus Stumpf <=
- Re: RFC3463, 450 reply codes, and 4.7.1 extended codes., Bruce Lilly
- Re: RFC3463, 450 reply codes, and 4.7.1 extended codes., Markus Stumpf
|
Previous by Date: |
Re: draft-duan-smtp-receiver-driven-00.txt, Hector Santos |
Next by Date: |
Re: RFC3463, 450 reply codes, and 4.7.1 extended codes., Bruce Lilly |
Previous by Thread: |
Re: RFC3463, 450 reply codes, and 4.7.1 extended codes., Bruce Lilly |
Next by Thread: |
Re: RFC3463, 450 reply codes, and 4.7.1 extended codes., Bruce Lilly |
Indexes: |
[Date]
[Thread]
[Top]
[All Lists] |
|
|