From: william(at)elan.net
Sent: Saturday, October 23, 2004 6:00 AM
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.
I need to review the latest BATV draft, but last time I looked they had a
protocol identifier and separators between the identifier, signature, and
mailbox address. However, I need to verify this when I get more time. As
for SES, it is trivial to strip off the signature and get the plain mailbox
address, including the local-part. Here are two different SES formats (for
different purposes), that you can see are trivial to strip off:
MAIL FROM:<S=XXXXXXXXXXXXX=local-part(_at_)domain>
MAIL FROM:<S=XXXXX(_dot_)DDDDDDD=local-part(_at_)domain>
Just remove everything from the starting "S=" through the next occurrence of
"=" and you have the original mailbox address. This is much easier than
undoing an SRS address.
<...>
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.
Correct.
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).
Yes, they may not appear to accept it, but if you reject spam at the end of
data, you may as well consider the matter done. If they are using trojaned
PC's, it doesn't matter. If they are using an open relay that is not yet
blacklisted, it is likely a normal mail setup that will properly deal with a
reject at the end of data.
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.
The main thing preventing it from happening is the need to upgrade all MUA
software to do this test. I don't think that is terribly likely, since
there is no reason it needs to be done in the MUA. It's very different from
an S/MIME or PGP signature. Since there is no protocol for an MUA to
request a bounce for a message that already has been delivered to it (we
would be asking the MTA to "un-deliver" the message), even if the required
MUA software existed, how could the MUA initiate a bounce?. I don't think
it is a good idea to permit MUA's to compose and send null-sender messages,
as the abuse potential is incredibly high. Bounces are for non-delivery.
If the MUA already has the message it has been delivered. This is creating
a new class of delivery notification saying, "the message has been
delivered, but the end user doesn't want it". It's certainly outside the
scope of the RFC's, at least as far as I am aware.
Since this test is so easy to do in the MTA, why not do it there and prevent
the user from seeing the forgery in the first place? You can't have
phishing if the message is never delivered to the user's inbox. That would
require zero changes to MUA software, and thus be much more easily deployed.
Email signatures are going to happen, most likely, and MTA's will have to
look at headers, one way or the other.
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.
Why would we want to go back to the "bad old days" of store and forward when
we can reject at SMTP time? Rejecting at the end of data is still better
than sending a bounce after-the-fact.
<...>
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.
An excellent argument as to why it belongs in the MTA rather than the MUA.
--
Seth Goodman