ietf-mxcomp
[Top] [All Lists]

Re: What semantics are conveyed

2004-03-10 09:48:09

Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com> wrote:
I believe that your refering to the following quotes:

Section 1:
"This document contains minor updates to the semantics of parts of RFC 2821"

  Which is not the same as the original text in that section of the
document.  I specifically chose to say it does NOT change the
semantics of RFC 2821, because I truly believe it does not. (Subject
to certain caveats.)

Section 1.1:
"  These proposals change the semantics of the MAIL FROM command
    as defined in RFC 2821, section 3.3. to imply that the domain
    in the source mailbox is also the responsible party for
    sending the message, and thus must be verified.
"

  This text is wrong.  See the rest of the LMAP discussion document
for explanations why.  A better phrasing is:

  "... the recipient MAY CHOOSE to ask the domain in the source
   mailbox if they accept responsibility for the message.  If the
   domain does not accept responsibility, then no bounce path exists, and
   by other recommendations of RFC 2821 [ref], the message should not
   be delivered."

I suggested to add those comments originally based on something Pete
Resnick brought up. In particular, I am basing this on section 4.4
of RFC 2821:

"  The primary purpose of the Return-path is to designate the address to
    which messages indicating non-delivery or other mail system failures
    are to be sent.
"

  So we have some choices:

  a) ignore any secondary purposes of the Return-path, which appear to
     be permitted by the above text

  b) Add secondary purposes to the Return-path

  c) Pretend that SMTP was handed down by god and is written in stone,
     and that as mere mortals, there's nothing we can do to change it

  d) Realize that people wrote SMTP, and people can change SMTP.


  It's nice that SMTP is implemented and widely deployed, but if it's
time to change it, then let's talk about changing it.  The Internet
has changed, and RFC 2821 hasn't.  People are abusing the flaws of RFC
2821 to send spam.  So let's stop pretending it's perfect, and just
fix it.

  Refusing to address the issues in SMTP because of appeals to dated
standards is a cop-out.

  As for Section 4.4 of RFC 2821, the fact that I rejected a message
as spam would appear to fall into the "mail system failures" category.
I determined that you failed to satisfy my criteria for accepting
messages.  If I can't bounce the message back to you, then I should
never have accepted it in the first place.

  Alan DeKok.