ietf-smtp
[Top] [All Lists]

RE: slight update to draft-macdonald-antispam-registry

2011-05-11 16:48:53

-----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 Hector 
Santos
Sent: Wednesday, May 11, 2011 1:04 PM
To: ietf-smtp(_at_)imc(_dot_)org
Subject: Re: slight update to draft-macdonald-antispam-registry

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.

This mindset conflates protocol specification with implementation and BCP.

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.

This all talks about software design and operation.  The proposal to which I'm 
responding said "notify an operator".  There's a gigantic difference between 
the two in terms of what's appropriate for a standards track RFC and what is 
not.

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