On Thu, Jan 29, 2004 at 01:10:40PM -0500, Meng Weng Wong wrote:
|
| The same SPF declarations can be used in service of either kind of
| authentication. Historically, we have focused on the envelope, because
| getting into headers opens a huge can of worms. But an intelligent MUA
| is welcome to apply the test to the headers.
|
| As far as I'm concerned the best place to do SPF tests is still at the
| border MTA and the natural subject of authentication is the envelope.
|
So you can test the envelope and you can test the headers. If the
Caller-ID logic works correctly, it will return an excellent
approximation to the envelope Return-Path 99% of the time, and in some
of the remaining 1%, the header selected by Caller-ID might even be more
correct than the envelope sender.
But there is a sound deployment reason to prefer the envelope over the
header, a reason that I did not fully appreciate until now.
WWSD? What will spammers do?
Suppose foo.com publishes SPF records, and suppose example.com does not.
If we only check the headers, spammers will do this:
Return-Path: joe(_at_)foo(_dot_)com (this is the envelope sender)
Resent-Sender: spf-ignorant(_at_)example(_dot_)com
Resent-From: joe(_at_)foo(_dot_)com
Sender: joe(_at_)foo(_dot_)com
From: joe(_at_)foo(_dot_)com
Because example.com has no SPF, the message is accepted by the border
MTA and enters the recipient's email system. Suppose the recipient
mailbox is over quota; the message would bounce to joe(_at_)foo(_dot_)com(_dot_)
That's your classic joe-job.
It would happen even if foo.com publishes SPF.
Joe will write an angry letter to spf-ignorant(_at_)example(_dot_)com and say
"hey,
doofus, please publish an SPF record so this won't happen again."
spf-ignorant(_at_)example(_dot_)com will say, "whatever, joe, stop spamming me."
* * *
But if we check the envelope sender here is what spammers will do:
(whether or not we also check the headers)
Return-Path: spf-ignorant(_at_)example(_dot_)com (this is the envelope
sender)
Resent-Sender: spf-ignorant(_at_)example(_dot_)com
Resent-From: joe(_at_)foo(_dot_)com
Sender: joe(_at_)foo(_dot_)com
From: joe(_at_)foo(_dot_)com
The message would be accepted by the border MTA because example.com has
no SPF records; it would bounce off an overquota mailbox; and it would
bounce back to spf-ignorant(_at_)example(_dot_)com(_dot_)
That's also a joe-job, only this time it's not against foo.com, but
against example.com. The spammers won't forge foo.com because foo.com
has SPF records. (No, really, foo.com actually does. Go check.)
And this time, spf-ignorant(_at_)example(_dot_)com would yell at the sysadmin
for
example.com saying "help, my mailbox is full of bounces" and the
sysadmin would now have an incentive to publish SPF records for
example.com. That incentive is absent if you don't check the envelope.
* * *
The incentive is the crucial difference.
If you check the envelope from, the adoption dynamic is autocatalytic.
If you only check the header from, the adoption dynamic requires altruism.
This is why we must check the envelope.
If we check only the headers and not the envelope, you can only avoid a
joe-job by not sending bounce messages at all! Do we want that?
* * *
Phishing (impersonation spam) is a hard problem.
Phishing can still happen unless an MUA displays the responsible sender
--- the choice of Resent-Sender / Resent-From / Sender / From that was
used in making the spoof decision.
And even then it would be real hard for the end-user to distinguish
between these four cases:
"Here's a message from my friend Jack, sent from hallmark.com, to me."
"Here's a message from my friend Jack, sent from some random greeting
card site that I don't know about --- fhqwhgads.com --- to me."
"Here's a message from service(_at_)paypal(_dot_)com, sent through my
forwarding
service pobox.com, to me."
"Here's a message from service(_at_)paypal(_dot_)com, sent through some
forwarding
service I don't know about --- fhqwhgads.com --- to me."
Three of them are legitimate. One of them is spam. Can you tell which?
* * *
If you check only the headers, to tell when a message is being spoofed
you need an RHSBL of all the known spoofing domains out there.
If you check the envelope, you can tell a message is being spoofed
without the RHSBL.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.5.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡