From: william(at)elan.net
Sent: Tuesday, October 19, 2004 5:39 AM
On Tue, 19 Oct 2004, Tony Finch wrote:
On Tue, 19 Oct 2004, william(at)elan.net wrote:
2. PRA (RFC2822 headers) domain authorizations records will
always be the same as MAIL-FROM data
Wrong. If your site is doing BATV or SES etc. then the PRA
record will be
+all but the MAIL FROM record will be include:jobbyjobby -all. Also the
MAIL FROM will always be different from the Sender: and From:
Did I not mention right below that I do not agree with the premise
that Meng was trying to force on us by making PRA use SPF1 records?
Anyway the point of idea is to is to allow to domain record to indicate
if emails would have same MAIL FROM and From or not. If somebody is using
BATV or SES obviously they would not and this record would not be there.
Not exactly. If we know the format of SES and BATV, and the MTA was not
smart enough to remove the signature (as it should) before writing the
Return-Path: header, the new MUA software you are talking about could
certainly remove the SES/BATV signature and get back the "plain" return-path
that will be the same as the 2822 identity. As long as you are advocating
new MUA software, the same should occur with VERP bounce addresses.
But there is something more important to say about William's excellent
concept of a modifier that states that 2822 identity and 2821 identity must
match: there is no reason to push this test off on the MUA, the MTA can and
should reject such messages during the SMTP session. This is desirable from
a number of viewpoints.
1) The spammer _knows_ that delivery failed, instantly. This immediate
feedback is preferable to the spammer knowing the message was accepted but
not knowing the final disposition. Even though most spam are discarded
before final delivery, there is still a small chance it will be delivered
and read, which is good enough reason to keep sending spam through that same
channel. With SMTP rejection, there is no chance the message was delivered
or read and the spammer knows that.
2) Implementation in the MTA is much more likely to be widespread as there
are a relatively small number of products and a much smaller installed base
than MUA's.
3) Silently dropping mail in the MUA after MTA acceptance has always been a
questionable practice. We all do it in self-defense and because, in the
case of spam, we know that the bounce address is probably bogus. The more
we can reject during SMTP, the more the original assumptions behind SMTP can
be trusted. That is, an MTA that accepts a message accepts full
responsibility for ultimate delivery or sending a DSN back to the
originator. There is no mechanism for MUA rejection besides silent
deletion. This breaks the model and we should not encourage it, if we have
a choice.
Very good idea, William! This beats the heck out of PRA, and I'm delighted
to see it. To be compliant with RFC2822 remailing, the 2821 identity should
have to match the highest of From:, Sender: or the most recent
Resent-Sender:. This is _not, not, not_ using the PRA scheme. PRA changes
the usage of the Resent-From: header to be the same as SUBMITTER, which
identifies the most recent SMTP-client in the message transfer path. What I
am proposing is to keep the (2)822 header usage exactly the same as it is
has been since 1982 and simply interpret those headers as per (2)822 to find
the _originating_ identity that has to match with the (2)821 originating
identity. This is an end-to-end check while PRA is hop-by-hop. It
accomplishes a purpose not envisioned by the "inventors" of PRA, not
disclosed by them and not claimed by them, so I'm pretty confident this is
free and clear of Microsoft's IP.
I also agree that the situations where people can't send mail with the same
2821 and 2822 identities are becoming less and less common. Mailing lists
are already compliant. Both the traveling salesman and vanity domain
problems can be solved through the use of SMTP AUTH. While not widely
deployed in the U.S. due to lethargy and inertia, this could easily change.
If not having the two identities match resulted in some mail not getting
delivered, this would produce the necessary "encouragement" for providers to
implement SMTP AUTH where it does not currently exist. All of the common
MTA's that I have heard of support it and it is a matter of good
administrative planning to roll it out in an organized manner.
I'm not pretending it is trivial for an organization that has 100K accounts
to roll this out or that it wouldn't cost them anything. I'm saying it is
simply the way things are going and they will have to do it sooner or later,
so they might as well do it sooner and benefit from a reputation as a
"clean" sender. Everyone is gradually realizing that email forgery, both
benevolent and malicious, is becoming less and less acceptable. Since it is
difficult to tell the benevolent from the malicious forgeries, the easiest
solution is to implement SMTP AUTH across the board and limit the sender to
the identity the sender authenticated with, or one that the owner of an
alternate identity has specifically delegated to the sender, for both 2821
and 2822.
--
Seth Goodman