On Wed, 20 Oct 2004, Seth Goodman wrote:
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.
If I understand correctly BATV would make return-path into something like:
xioerei123oie+e43432oioe(_at_)domain(_dot_)com where that long random string is
an encrypted signature of original "user(_at_)domain(_dot_)com". The from would
still
most likely be "user(_at_)domain(_dot_)com" so while full local parts would not
match the domain part should still match. I believe same also true for SES.
Same is not true however for SRS which rewrites the email with new
return-path using domain of the forwarder. In this case forwarder
would have to use domain name with SPF record that does not have this
modifier so as not to cause errors. However smart verifier client which
knows about SRS format can transform that back and get original email
mail-from address and can then do SPF lookup on that original domain.
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.
Unfortunetly SMTP server can not do the match until it received the headers.
As such rejection is not possible after MAIL or RCPT, but can only be done
after DATA for those mail clients that accept 500 after DATA (which most
spammers software does not; sometimes they dont even accept 500 after mail
or RCPT). Now that said,
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.
There is nothing otherwise that stops MTA from doing this verification
after email has been received and if something is wrong then attempting to
bounce the email (especially since during session it confirmed by means of
SPF the bounce address and knows it to be good). Its just that most MTAs
right now don't look at the headers but this may well change with
introduction of email signatures.
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.
That is why the first step should be to verify that bounce address is not
bogus (i.e. MAIL-FROM) then if something is wrong with message otherwise
you can send a bounce instead of just silently dropping the email.
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.
I agree. Especially since when talking about it to Pete Resnick he on the
MARID jabber chat actually said that current Resent-* usage is such that
it is considered new email message and he would expect that new MAIL FROM
address to be set by the remailer and it would be one from Resent-Sender
or Resent-From.
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.
If we assume that Microsoft's IPR applies only to Caller-ID than this
should be free of it. But Microsoft wrote patent that is why too broad
and its not so clear what is going to be covered by it.
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.
Based on me talking to some other people on this problem it appears the
following is true:
1. Almost all personal email is compliant (> 50% of email is like that)
2. Almost all mail lists are compliant (mail lists typically set Sender:
to the same address as new MAIL-FROM they enter)
3. Most forwarders are compliant (they don't touch From and most don't
reset the MAIL-FROM)
However also:
4. Most gateways are not compliant (they set MAIL-FROM to address of
the gateway system)
5. Bulk commercial email is primarily not compliant (this is when
large company paid to commercial mailer to send their email to
users and commercial emailer would typically want to handle bounces
and while From: can be "GreatDeals(_at_)dell(_dot_)com" the bounces could
be e123456(_at_)dell(_dot_)mailer(_dot_)com).
At the same time for both #4 and #5 the email address used in MAIL-FROM
is often set to specific subdomain specially used for bounce-handling
matchine. So while that subdomain may have SPF record, I would expect
that owners of that subdomain already know that ALL email with that
subdomain in MAIL FROM would not match From: and they would therefore
not use equivalency modifier (Note: I'll later email and explain how
to help commercial emailers be compliant in the way that they can use
equivalency modifier in their record to protect their client's email).
So in reality the modifier is actually quite safe - safer in fact then
actual SPF which fails with forwarders.
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 suspect that some errors may happen but very few (fewer then if same
company enters SPF mail-from record with -all). But as I'm going to
introduce typical SPF "+/-/~/?" into this modifier and it'll be possible
to use "~" to identify the intermediate step while roll-over is happening.
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.
There is strong incentive to counter phishing so I believe there is
good momentum to roll this out together with SPF. The bad thing is
Microsoft trying to push its own lot more dangerous solution, so
education and promotion from those involved in SPF community and
especially from large companies that support SPF is necessary to tell
publishers to add this modifier together with their main SPF record.
And obviously it'll be good to see all SPF verifying agents be able
to support this system, so that means it has to be simple and easy to
add without too much extra programming.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/