From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Todd Herr
Sent: Friday, March 26, 2010 10:02 AM
Subject: Re: New Version Notification for draft-macdonald-antispam-
Has anyone heard of any problems dealing with Yahoo!'s 421 4.16.55?
If not, then we can probably expect the same with x.8.y, yes?
I haven't heard of any MTA that actually looks at ESCs, but that's just me.
I'm interested in the SMTP conversation being the only conversation
that needs to take place about a given message. To the extent that
something like this proposal can get me to that goal, without driving
follow up questions from senders (e.g., "I got 554 5.8.5 unacceptable
content; what do I have to do to make my content acceptable?") then
I'm interested in seeing this move forward.
But can that really be eliminated? It seems to me any generic-sounding reply
text is likely to draw response from some end users at some point, even if the
RFC defining the code used is very precise. And the RFCs don't mandate the
text you use, only the semantics of the specific codes that precede the text.
Some implementors have read the RFCS as requiring specific reply text and have
implemented accordinfly. Which is another reason why I continue to push back
against the idea that we have to coter to every possible form of brokenness
Was this a concern with the largely generic 5.7.1 when it was introduced? In
my experience, it's widely used. For that matter, all the x.y.0 codes in ESC
are generic in purpose.
Exactly so. You are free to use a generic code if you believe that is what's
It's really all about the text, which is under the control of the
One of the intended uses of enhanced status codes is to provide a means
of generating a localized error message. So yes, it is all about the text,
but the text may not be what the generating agent put in but rather something
created by an intermediary based on the status code.