[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis: Permitted and prohibited characters in addresses

2008-01-07 23:59:42

At 19:36 07-01-2008, Frank Ellermann wrote:
If RFC 2822 was a product of DRUMS it is IMO a showcase, and if
RFC 2821 was a product of DRUMS it is a counter-example.  That
is now ancient history, the reality is:

- RFC 2821 doesn't tell us what to do with IPv6, 2821bis admits
  that this isn't trivial.
- RFC 2821 silently assumed that nobody forges envelope sender
  addresses because that made no sense in the time of 821, and
  it also made no sense with the design of 821.  But 1123 broke
  the 821 design, and 2821 did not admit that it is broken.

Quoting Section 3.6.2.:

  "This specification does not deal with the verification of return
   paths for use in delivery notifications.  Recent work, such as that
   on SPF [42] and DKIM [43] [44], has been done to provide ways to
   ascertain that an address is valid or belongs to the person who
   actually sent the message."

- RFC 2821 silently assumed that "accept, and let's see how it
  works out" is the best strategy.  But in practice this either
  means "bounce to a forged envelope sender address" or "drop
  the mail if it didn't work out".

Section 6.2 talks about this:

  "Conversely, if a message is rejected because it is found to contain
   hostile content (a decision that is outside the scope of an SMTP
   server as defined in this document), rejection ("bounce") messages
   SHOULD NOT be sent unless the receiving site is confident that those
   messages will be usefully delivered."

In practice, you can avoid the "drop the mail if it didn't work" by making that decision at the SMTP stage as far as possible.

- While RFC 2821 inherited the 1123 5.3.6(a) bug 2821bis should
  admit that "keeping the envelope sender as is" in forwarding
  to third parties violates an essential point in the original
  SMTP, the complete transfer of responsibility at all relays,
  with obvious ways (251+551) to accept or reject this transfer
  of responsibility.

In the original SMTP, 251 or 551 are used when destination information is incorrect and the SMTP server knows the correct destination. This is different from 1123 5.3.6(a) which talks about alias expansion. We have to keep the envelope sender as is unless we want to bring back source routing.

- The discrepancies about what mailing lists really are (noted
  in the Last Call) should be also addressed.  Bugs and issues
  should be fixed or documented.  Just "not talk about it" (if
  it could hurt the feelings of ML operators) does not cut it.

Mailing lists may use either an alias or a list model. The distinction between the two is that the alias operates by forwarding (envelope sender is not rewritten) whereas the list operates by redistribution, changing the envelope sender to point to the list administrator.

For that particular issue, assuming that 2822upd can't fix
it, yes.  Generally I've no good idea, of course 2821bis is
better than 2821, therefore it should be published.  But it
doesn't address important problems with the 1123 design for
a world where almost 90% of the mail traffic is spam.

If we are going to address the spam problem, we have to restrict a lot of the mail functionality which 2821 offers. We'll never see 2821bis published if we start that discussion.

I'm also not sure about IPv6 MX and AAAA issues when an IPv6-
only sender meets an IPv4-only receiver with the help of an
IPvAnything forwarder, a variant of the 1123 5.3.6(a) issue.

The IPv6-only sender can relay the mail through a host that supports dual-stack operation.