-----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-
registry-00
Then it comes back to Todd's original point - what's the value? If
this
effort adds codes that only raise more questions and answers none of
the
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.