On Thu, Jul 08, 2004 at 12:16:07PM -0700, Greg Connor wrote:
|
| >The forwarding problem means that we can only ever validate the last
| >link in the chain and that as a result it is only ever possible
| >to know with certainty that a message is genuine, it is not possible
| >using the information from Sender-ID ALONE to know that a message is
| >defnitively fake if it purports to be forwarded.
|
| Agreed. The message should be shown as "from the forwarder" because that
| is the only step we are able to verify by IP. (If the receiver is not
| using a forwarding service, he will probably see the actual sender's
| verification, in which case LMAP has done its job and all is well.)
I would like to suggest we keep in mind:
Where the mass majority of normal email is concerned,
forwarding is an edge case.
Failure of SenderID due to noncompliant forwarding is a
corner case.
Therefore the failure scenario should be noted in detail and
announced to the industry so that troubleshooters can
recognize it when it happens. But it is not big enough a
problem to keep us from moving forward.
We should also keep in mind the positive scenario for SenderID:
If the mail is sent directly from Citibank to enduser,
then SenderID returns an authentication PASS, and
the reputation system returns a thumbs up,
so the message gets a positive overall result,
and the MUA displays a little green light or whatever.
The positive scenario is the scenario we are trying to enable.
At the highest levels, this is also true:
we're moving toward a paradigm of "assumed guilty until
proven innocent" (AGUPI).
In the AGUPI paradigm, the positive scenario becomes the
goal, and anything that falls short is deemed to be in the
YMMV zone. Legitimate senders are assumed to have the
means, motive, and the opportunity to do what it takes to
get themselves into the positive scenario. Legitimate
forwarders are also assumed to have the means, motive, and
opportunity to do their part, which is to say, prepend a
header and add SUBMITTER.
* * *
I also want to point out that SUBMITTER:
- should appear rarely,
- is more flexible than it seems, and
- is amenable to AGUPI practices, which is to say
unrecognized SUBMITTERs can be safely rejected.
I will explain each of these points.
* SUBMITTER should appear rarely.
SUBMITTER need not be used when the MAIL-FROM is identical
to the Sender. This is a very common case.
* SUBMITTER is more flexible than it seems.
Even if the MAIL-FROM is different from the Sender,
SUBMITTER may still not need to be provided by the sender
MTA. Why?
SenderID stipulates that the PRA must match the SUBMITTER; a
transaction in which PRA does not match SUBMITTER is deemed
to be noncompliant.
In discussion with Daniel Quinlan, he asked if that means an
MDA needs to have access to SUBMITTER. This is when it
dawned on me that in practice, PRA doesn't always need to
match SUBMITTER. After all, it's meant as an optimization.
If it isn't there, the PRA algorithm still works.
A receiver need test only two of the following three:
- The PRA in the headers authenticates and passes reputation.
- The SUBMITTER in the envelope authenticates and passes reputation.
- The PRA must match the SUBMITTER.
This opens the door to a disconnect between PRA and
SUBMITTER. Is this exploitable? I don't think so, because
for anti-phishing purposes, we really only want the
end-user-visible address (the PRA) to authenticate and pass
reputation. SUBMITTER is an optimization. If the SUBMITTER
authenticates, and the PRA authenticates, then they're
really both okay. They don't have to be the same!
Example:
MAIL FROM:<original(_at_)sender(_dot_)com>
SUBMITTER=<anonymous(_at_)pobox(_dot_)com>
Resent-Sender: <real-alias(_at_)pobox(_dot_)com>
From: <original(_at_)sender(_dot_)com>
The PRA is real-alias(_at_)pobox(_dot_)com(_dot_)
SUBMITTER is anonymous(_at_)pobox(_dot_)com(_dot_)
But both will pass authentication!
But anyway, this is a distraction.
* SUBMITTER can be safely rejected when it is not
recognized.
When does SUBMITTER occur? In forwarding. What is the
difference between legitimate forwarding and spam trying to
masquerade as a forwarder? In legitimate forwarding, I know
that mengwong(_at_)pobox(_dot_)com forwards to me; it is my alias, and
I am responsible for setting up that relationship. If I see
mail that says
MAIL FROM:<original(_at_)sender(_dot_)com>
SUBMITTER=<mengwong(_at_)pobox(_dot_)com>
I know that it's good.
If I see
MAIL FROM:<original(_at_)sender(_dot_)com>
SUBMITTER=<somebody(_at_)i-dont-know(_dot_)com>
then maybe it's a spammer trying to joe-job
original(_at_)sender(_dot_)com(_dot_)
If the above is true, we can apply AGUPI. We can simply
construct a per-recipient whitelist of recognized SUBMITTER
addresses. And we can reject everything else.
So I hope the above discussion has illuminated the role of
SUBMITTER in more detail.