On Fri, Mar 26, 2010 at 1:11 PM, Murray S. Kucherawy <[email protected]> wrote:
>
>> -----Original Message-----
>> From: [email protected] [mailto:owner-ietf-
>> [email protected]] On Behalf Of Todd Herr
>> Sent: Friday, March 26, 2010 10:02 AM
>> To: [email protected]
>> Subject: Re: New Version Notification for draft-macdonald-antispam-
>> registry-00
>>
>> Has anyone heard of any problems dealing with Yahoo!'s 421 4.16.55?
>>
>>   http://help.yahoo.com/l/us/yahoo/mail/postmaster/errors/421-ts01.html
>>
>> 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.

Yahoo doesn't issue an ENHANCEDSTATUSCODES during ehlo, so technically
yahoo can issue whatever it wants.

I've reread the relevant drafts and I can't anything that states MTA
behavior would be influenced by extended smtp error codes. Extended
smtp error codes are for reporting purposes. From the abstract of
3463:

   This document defines a set of extended status codes for use within
   the mail system for delivery status reports, tracking, and improved
   diagnostics.

>> 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.

Please realize that the list I've come up with is by no means the final list.
Feel free to add to it.

-- 
Jeff Macdonald
Ayer, MA

Reply via email to