[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: slight update to draft-macdonald-antispam-registry
Murray S. Kucherawy wrote:
I don't know what "standard set of recommendations" means in
We're talking about providing a protocol, and including in an
IANA registry (which is the direction this appeared to be going)
some prescribed operator action seems inappropriate to me. Define
what the new code means, and leave it there.
This mindset is archaic and outdated in 2011 and beyond. The world is
too complex and yet the issues are widely known. The audience of this
document is not going to be reading it with an anal document editor
perspective or "did I follow the IETF protocol guessing rule" mindset.
Todays practitioners dealing with a high degree of mail integration
and automation requirements need all the insights and recommendations
they can get and when talking specifically about a special category of
"Anti-Spam" extended reply codes, an idea that touches base with
delivery reliability and security, having some form of AVS severity
status will help provide implementator guidance at many levels of
This is not odd. SMTP is filled with modern mail handling insights and
it added a few very important ones in RFC5321:
New Last sentence in Section 6.2, 1st para:
When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"
message in response to DATA), it is accepting responsibility for
delivering or relaying the message. It must take this responsibility
seriously. It MUST NOT lose the message for frivolous reasons, such
as because the host later crashes or because of a predictable
resource shortage. Some reasons that are not considered frivolous
are discussed in the next subsection and in Section 7.8.
New section 6.2. Unwanted, Unsolicited, and "Attack" Messages
New section 7.8. Resistance to Attacks
6.2 changes many things with its modern recognition of new security
needs and the presence of new protocols such as SPF/SENDER-ID, ADSP
and future augmented PAYLOAD security technology which allows for
avoiding abusive bounce notifications.