ietf-smtp
[Top] [All Lists]

RE: New Version Notification for draft-macdonald-antispam-registry-00

2010-03-26 20:29:05


-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of J.D. Falk
Sent: Friday, March 26, 2010 8:50 AM
To: ietf-smtp(_at_)imc(_dot_)org
Subject: Re: New Version Notification for draft-macdonald-antispam-
registry-00

Yup, me too.  I'd also be curious how the most common MTAs (sendmail,
postfix, exchange, etc) react to reply codes they've never seen before.
They /should/ handle 'em gracefully, but there could be surprises.

I don't recall seeing any code in sendmail that reacts to other than the
first digit of the SMTP reply code itself, and nothing that looks at the
enhanced status code.  No idea about other MTAs.

The most you're likely to find is code to check for 552 specifically and treat
it as temporary, due to the error in RFC 821. And any MtA that bases a message
handling decision on any part of an enhanced status code is deeply and totally
broken in any case; in the highly unlikely event that such an error has been
made I see no reason why we should even consider catering to it.

As a practical matter, SMTP server spit back codes not specifically defined in
any standard on a pretty regular basis. Undefined third digit values, e.g., 505
or 557 are the most common, but I've also seen stuff like 53Z codes generated.

This behavior is fairly easy to explain: RFC 821 and its successors include
both explicit code lists as well as a general theory of reply codes. So,
depending on what parts you pay the most attention to, you can come away with
the idea that you should always use the code off the list that's the closest or
you may believe it is OK to invent new codes willy-nilly.

But regardless of the explanation, I think the likihood of there being enough
MTAs incapable of handling unusual second and third digit values is vanishingly
small. As for extended status code, I've seen exactly one case of an agent that
looked at the extended code when it should have been looking at the regular
code, and even in that case only the first digit mattered. (It was nevertheless
a deeply broken MTA that had to be fixed, since there are legitimate use cases
where the first regular code digit and first extended code digit do not agree.)

This might create a need though.

We will have screwed up badly if it does.

                                Ned

<Prev in Thread] Current Thread [Next in Thread>