From: Frank Ellermann
Sent: Thursday, August 05, 2004 11:11 AM
John Glube wrote:
However, it also allows as Mark suggests non RFC compliant
sender?s to play games and chose the best algorithm to
inspect their message for their own purpose. Tilt.
The only difference between SPF/MAILFROM and the PRA stuff
are the checked headers. So if I'm Phred Phisher in Elbonia
(Mark's example) and phisher.com is my throw-away domain for
today, I simply publish...
"v=spf1 exists:%{ir}.comcast.blackholes.us -all"
LOL. That domain won't last long, but will get very high marks for
creativity.
...and let my zombies fire, MAIL FROM:<admin(_at_)phisher(_dot_)com>
Of course I also use a matching From:, because that really
looks better. But I could then replace v=spf1 by v=marid1,
if this results in a green blinking flag on the MUA of the
unlucky recipient, with a nice onmouseover text "IETF says:
admin(_at_)phisher(_dot_)com is a good phisher, trust us".
What people are forgetting about the whole flawed architecture is that
it is hop-by-hop validation. The PRA extraction only looks for the
_current_ sender, not the original sender. This means that
I.M.Phisher.com can take a throw-away, SPF-compliant domain and
construct a message From:Thomas Moneybuckets<CEO(_at_)BankOfAmerica(_dot_)com>
with
Resent-From:<phishy(_at_)I(_dot_)M(_dot_)Phisher(_dot_)com>. Since the two
most common MUA's
on the planet (built by guess who?) _don't_ display Resent-From: to the
user, even though that's the address PRA will give a "pass" to, anyone
who uses one of those MUA's will only see From:Thomas
Moneybuckets<CEO(_at_)BankOfAmerica(_dot_)com>. Where's the anti-phishing
capability? Only on original, direct-to-MX messages, that's where. So
phishers will simply avoid the direct route.
But hold on a moment. MS can release Outlook2004 which displays the
correct headers used by the PRA algorithm. You can upgrade for only
$99.95! Good thing I'm not into conspiracies, like those creepy Justice
Department lawyers that tried to ruin a good corporate citizen just for
spite. I have to admit, using the Resent-From: header in a way that
contradicts its usage in RFC2821, which then causes all their existing
mail clients to not display forgery clues and thereby creates a large
market for updated mail clients would be a pretty slick business
maneuver. Especially since customers have proven unexpectedly resistant
to upgrading hardware, operating systems _and_ office applications
because they work "well enough". There are two ways to change that
situation and this is one of them.
I'm sure that Microsoft would never do anything that underhanded. This
time, Microsoft's motives are selfless and we shouldn't question them.
They are certainly much more interested in solving the forgery problem
than making money. That's why they put a staff of over four full-time
people on this critical project, which is intended to save the entire
email system from melt-down. They've spared no expense in their fight
against spam.
<...>
Whatever he does, it's not what my v=spf1 sender policy
wants: Get rid of the useless bounces to forged MAIL FROM
addresses, but don't do wild and wonderful things with 2822
headers incompatible with legacy software.
You want SES or something very much like it for that functionality. It
also happens to be an excellent forwarding mechanism, but that's another
story.
PRA with "default Sender:" could work with legacy software,
but so far nobody supports this idea. And there are some
interesting ideas in SPF/FROM-HDR not covered by PRA, and
incompatible with PRA. Sigh.
I've obviously missed something, but what is SPF/FROM-HDR?
--
Seth Goodman