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.
Regards,
-sm