[Top] [All Lists]

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

2010-03-26 13:13:17

-----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 Rosenwald, Jordan
Sent: Friday, March 26, 2010 10:42 AM
To: ietf-smtp(_at_)imc(_dot_)org
Subject: RE: New Version Notification for draft-macdonald-antispam-

Then it comes back to Todd's original point - what's the value?  If
effort adds codes that only raise more questions and answers none of
existing ones...

I see this as a two-part problem.

There are three parts to the SMTP reply: the SMTP code, the Enhanced Status 
Code (optional) and the text (optional).

The first part: The text portion of the reply is the portion most likely to 
either draw or quell end user response because it's what appears prominently in 
dialog boxes and DSNs.  If the text is null or generic, then it doesn't tell 
the user anything, and then you get a support hit; if the text is highly 
descriptive, the need to get support is quashed.  The text is unspecified, 
meaning it's up to implementers (in this case, ISPs that control the responding 
MTAs).  So the positive or negative value is really up to you to manage.

The second part: The SMTP and ESC parts are the parts an ESP, for example, 
could theoretically use as automated feedback into their systems to identify 
mail streams many receivers find objectionable (content, specific recipients, 
whatever).  If your organization finds feedback loops valuable, you might find 
this valuable as well.  But it's only got value if both sides will use it.

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