From: gep2@terabites.com
Date: Mon, 01 Mar 2004 12:57:12 -0600

Cc: asrg@ietf.org, wishlist@microsoft.com
Subject: [Asrg] [IP] CNN covers Meng's SPF

> NEW YORK (AP) -- With a simple adjustment in your e-mail software, you 
>can pretend to be anyone. You can send messages marked as coming from
>BillGates@microsoft.com.

Surprise surprise!!!  This should have been common knowledge for a long 
time.

> The trick, known as spoofing, is a popular method for spammers to hide
>their tracks -- you'd blame Microsoft Corp. chairman Bill Gates and not
>the actual perpetrator of junk mail.

> To close that loophole, Microsoft and Yahoo! Inc. are each developing
>systems aimed at authenticating senders of e-mail. America Online Inc. is
>testing a third.

Funny thing that each of these folks are ISPs... and each is trying to 
make sure you use THEM for everything you do. :-((  

> "Having e-mail come in, and not really being able to identify where it
>comes from, this is a huge security hole," Gates said this week in
>announcing specifications for his proposal.

Actually, the "Received" headers give one a pretty decent trace of "where 
it comes from", at least once it leaves the hands of those who counterfeit 
headers or otherwise attempt to deceive.  And one could certainly imagine a system 
whereby mail recipients systems could go back to the claimed originating 
system of the E-mail message and ask for confirmation that the specific E-mail 
message actually originated at that system.

> Many software engineers are concerned, however, that these systems could
>end up causing more problems than they solve.

And, in fact, that is precisely the problem.  Many of these systems, 
SPECFICALLY INCLUDING Wong's SPF (and as a member of the IETF's Anti-Spam Research 
Group was on Wong's SPF mailing list for a while, before I concluded that it was 
probably fatally flawed), have a number of very serious problems in them if they 
were ever to be widely adopted.

> Microsoft's proposal, known as Caller ID for E-mail, calls for Internet
>service providers to submit lists of unique numeric addresses for their
>mail servers. On the receiving end, software would check a database to
>verify that a message said to come from an e-mail provider actually
>originated at one of its registered machines.

The problem with this one of course is that not all E-mail messages 
originate at mail servers run by ISPs.  Some of the more sophisticated business 
customers (and indeed, some of the more sophisticated USERS, myself among them) 
actually use their own outgoing E-mail servers... for a whole variety of perfectly 
valid reasons.  It's outrageous and offensive that ISPs are trying to prevent 
users from being able to bypass the ISP's (hoped-for) monopoly provision of 
(sometimes unwanted and often gotcha-laden) "ISP services".

> In January, AOL began testing a similar system called Sender Policy
>Framework, or SPF, which checks a different part of the message.

> Yahoo's proposed solution is a different animal. It would use encryption
>to digitally sign messages. If the sender or message content is altered,
>the signature gets rejected. Yahoo announced its proposal, DomainKeys, in
>December but has yet to make details public.

There are a lot of such systems and most of them work at least in the 
scenario they are designed for.  Unfortunately, when you start looking at the less 
obvious but still HIGHLY important situations... such as personally-owned 
domains, mailing lists, corporate "vanity domains", roaming use (mailing 
from cruise ships, airport waiting lounge kiosks, etc)... not even to mention 
"anonymous remailers" required by whistleblowers etc... you usually find 
that these proposals have very serious flaws that have terrible implications to 
many customers with legitimate needs and concerns.

> The big three e-mail providers are not alone in trying to tackle address
>spoofing. Leading e-mail software vendor Sendmail Inc., spam-filtering
>company Brightmail Inc. and frequent e-mailer Amazon.com are also at it,
>each planning to test one or more systems.

> All these competing proposals are enough to get the Internet's
>standards-setting bodies in a lather.

> One of them, the Internet Engineering Task Force, has scheduled a 
>session on authentication next Thursday in South Korea. Experts predict some
>combination of the techniques will be ready for use later this year,
>though formal standards will take longer.

> There's much work to be done in the meantime, including proving the
>systems can actually work beyond controlled, laboratory environments.

> Caller ID and SPF, at least, are likely to disrupt mail-forwarding
>services that colleges and companies offer to let alumni and subscribers
>route e-mail through a domain name other than their own service
>provider's.

> They also could break "send to a friend" features in which someone 
>clicks on a Web link to pass an interesting item to someone else.

THOSE *need* to be broken.  They are often more just a pleasant-looking 
ruse to collect an E-mail address of the "someone else" victim and later use that 
for spamming or other unwelcome purpose.  (Electronic "greeting cards" of 
course suffer from the same fault.)

> Issues to be worked out for all three systems include how to properly 
>send e-mail from cybercafes, hotels and public Wi-Fi hotspots...

Indeed, and (as mentioned) airport waiting lounge kiosks, cruise ships, 
and other "temporary/away" situations.  Mailing lists are another such serious 
problem.

> and how to preserve privacy when using anonymous re-mailers, which are 
>used by whistleblowers and others to intentionally mask the origin of messages.

Absolutely.

> "A lot of people have said that e-mail today is broken, and now we're
>going to break it a little more," Meng Weng Wong, lead developer of SPF,
>acknowledged. "Some of the things people are used to doing, they won't be
>able to do it in quite the same way."

In fact, Wong (based on E-mail exchanges he and I have had) basically just 
doesn't care about the important flaws in his approach, he is fully aware 
of them and has been forging ahead with it regardless.  I consider his 
approach and attitude to be irresponsible and objectionable.

> But the gain in fighting spam outweighs any pain from change, Wong argues.

Except that it doesn't.  NOTHING in SPF in any way prevents spam 
whatsoever... all it does is to authenticate the sender.  Spammer-friendly ISPs, 
new "vanity" domains (and spammers are creating "disposable" vanity domains with 
seemingly randomly generated domain names at a breathtaking rate... sometimes 
using the domain name just once for a single mass mailing and figuring the 
less-than-$50 domain registration fee just a small part of the cost of doing their 
spamming business.)

Spammers can also continue hijacking (with viruses and worms) the systems 
of legitimate (if naive or careless) users and use those to generate spam 
E-mails using absolutely "legitimate" (if inadvertent) and authenticated users and 
valid sender ISPs.  This of course is one of the problems with the 
"cyberpayments" schemes for E-mails, too (quite apart from that being a slippery slope to 
the "pay for each E-mail" scheme that monopoly ISPs would LOVE to see become 
the norm).  In each case, the spammer simply shifts the costs to an 
inadvertent third-party victim.

So in fact, Wong's system creates MUCH pain, requires changes to systems 
literally everywhere in the world, hugely inconveniences (or even disables 
entirely) many types of users with highly legitimate needs, and still 
doesn't really do much of anything to actually solve the problem.  It still leaves 
people sending and receiving spam, with about the only improvement being 
that you maybe know who to send complaints about it to (usually an ISP, whose 
user is themself an unwitting and usually unwilling victim).  So what is the ISP 
supposed to do, punish the victim?  And even if they throw the victimized 
user off their system, eventually ALL such users will have been victimized, and 
NOBODY is left still on the Net.  :-(

> Authentication also can help limit the spread of e-mail viruses...

Again, NO IT DOESN'T.  It only helps identify where they actually came 
from.  Maybe.  (And often, that trail will end up leading back to someone who is 
a pathetic and beleaguered victim themselves).  This ultimately is NOT very helpful.

A **far** better approach... simpler, easier, rapid to implement, hard to 
disable or to evade... and one which IMMEDIATELY benefits the folks who 
INDIVIDUALLY put it in place, without requiring literally worldwide 
changes and consensus to be effective... is for E-mail client software companies to 
simply discard ALL incoming attachments (including alternative HTML-burdened ones) 
unless the recipient had previously whitelisted the sender and authorized 
THAT sender to send THAT recipient attachments of THAT specified type.  
(Example: Your Aunt Gertrude *might* actually send you an electronic photo JPG of 
her adorable poodle Fifi, but she probably NEVER needs to send you an .EXE, 
script, PIF, or other type of executable file.)  Likewise, even if you're some 
kind of consumer products company (say, Proctor and Gamble) that needs to receive 
unsolicited messages from previously-unknown users, it's very hard to 
argue that people need to send *attachments* (at least not as an initial contact 
message) rather than simply safe, plain ASCII text.

So E-MAIL CLIENT SOFTWARE SHOULD STRIP ALL ATTACHMENTS UNLESS THE 
RECIPIENT HAS SPECIFICALLY WHITELISTED THE INDIVIDUAL SENDER TO SEND THEM THAT SPECIFIC 
TYPE OR CLASS OF ATTACHMENT.

That single, simple, highly effective strategy would OVERNIGHT result in a 
near-total-elimination of 85-95% (maybe more) of all viruses and worms.  
The GREAT majority of them would find their propagation rate reduced to well 
below the minimum "survival" rate.

> and, with Caller ID and DomainKeys, help flag fraudulent "phishing" messages 
>that try to trick people into revealing passwords and credit card information.

A far more effective strategy THERE, TOO, is to STRIP ALL HTML CONTENT OUT 
OF MESSAGES unless the recipient has specifically authorized (by 
whitelisting) the specific sender in question to send the recipient HTML-burdened E-mail.

The great majority of spam and fraudulent "phishing" messages use tricks 
based on HTML to deceive, obscure, and defraud.  This can include obscured URLs, 
links that claim to be one thing but in fact point somewhere else (e.g. claim to 
be "http://security.ebay.com" but in fact when you click on them they point 
to a rogue server in Romania or somewhere), Web bugs, malicious scripting, 
malicious ActiveX content, text-as-image in order to evade antispam content filters, 
and so forth.  

If ONLY AUTHORIZED WHITELISTED-BY-EACH-RECIPIENT SENDERS were able to send 
them HTML-burdened E-mail content, then (and in conjunction with good antispam 
content filters, which would then be HUGELY more effective) we'd also get 
rid of the great majority of spam and other fraudulent E-mail, too.

Again, this doesn't require any great worldwide consensus, doesn't require 
any sweeping and disruptive change to the world's online systems, and doesn't 
needlessly or seriously disrupt legitimate users.  Moreover, IT IS 
EFFECTIVE FROM DAY ONE AND TO THE VERY FIRST ADOPTERS, which means that people are 
immediately gratified by the change they make to THEIR systems.  This 
ought to result in a rapid adoption rate, and minimize the long time it takes to 
move complex and ultimately unsatisfactory standards through worldwide 
standards organizations.

Note also that BOTH the changes I propose... simply whitelisting 
attachments and HTML at the recipient end, on a sender-by-sender basis... are 
SINGLE-ENDED schemes which do not require ANY changes at the sender ends at all 
(other than implying that they cannot send attachments or HTML-burdened mail 
unsolicited or unwanted, and expect to actually get it through!).  And, once 
whitelisted, EVERYTHING we can do today (vanity domains, roaming, mailing lists, 
send-from-cruise-ship, and so forth) all still work, too.

> The proposals require no changes to existing protocols for e-mail or the
>domain name system, and developers of all three pledge to eventually seek
>standards status (Wong has already submitted SPF for review).

Actually, almost all of these other approaches (INCLUDING Wong's) DO 
involve the need for worldwide changes and consensus, they prevent legitimate users 
from doing things they sometimes truly NEED to do, most DO involve changes to 
the DNS system (or else the construction of a wasteful parallel to it), and in 
fact NONE of them seem to ACTUALLY solve the problem.  They do NOT prevent the 
sending of Spam, they do NOT prevent the propagation of viruses, they do NOT prevent 
"phishing" and similar deceptions.  They only inconvenience people 
everywhere and disable exceedingly useful and important features.

> For now, the three can coexist, although adoption could be limited until 
>a consensus emerges around one or a combination.

The reason there has not been (and is not LIKELY to be) a consensus around 
these proposals anytime soon is because they each have very nasty problems that 
many people strongly dislike, and generally the payback even upon widespread 
implementation simply isn't worth the implmentation costs and other 
disadvantages.

> But these solutions alone will not stop spammers.

ABSOLUTELY, and that is at the root of the delay and dissatisfaction with 
all of them.  Nobody that seriously looks at these proposals is truly convinced 
that any of them ACTUALLY solve the problem.  It only makes folks (arguably) 
identifiable or traceable, and while that sounds good on the surface, it 
simply doesn't achieve much in the end analysis.  I don't think it makes much 
sense to uproot and mess up the entire Internet worldwide, just to give the bogus 
APPEARANCE of "we have to [appear to] do SOMETHING".

Meanwhile, the simple single-ended solution I propose (in conjunction with 
a suitable content filter at the recipient end) would be cheap and fast, 
HIGHLY effective against worms, viruses, spams, and "phishing" spoofs, is rapidly 
implementable, and would have negligible negative impact on legitimate, 
responsible users (both senders and recipients).  It moreover requires 
**no** changes whatsoever to the critical underlying Internet infrastructure.

>Systems will have to be established to evaluate the reputation of 
>domains that relay e-mail, and that raises questions about who would develop such
>lists and who would arbitrate disputes.

Again, that's simply NOT NECESSARY.  All that does is to establish 
trackability, it does **nothing** to actually prevent the sending (or receipt!) of 
spam, viruses, worms, and the like.

> In the short term, authentication will be useful mostly for verifying
>newsletters and other bulk mailings that are often misidentified as spam
>today, said Margaret Olson, co-chairman of the Email Service Provider
>Coalition's technology committee.

This can easily enough be handled, if necessary, with normal public-key 
signature technology.  Again, no infrastructure changes are required or 
even indicated.

> Once enough service and software providers adopt the technology, 
>"getting unauthenticated mail delivered will be extremely difficult," she said.

And that's part of the problem with such changes.  They require worldwide 
consensus to work effectively, and the earliest adopters gain little or 
nothing from making the changes.  They are expensive (because they have to be done 
EVERYWHERE) and in the end, when all is said and done, THEY DON'T SOLVE 
THE PROBLEM!

> And that could hurt e-mailers in other countries where adoption of
>English-language specifications tend to lag, and smaller service providers
>may be forced to accept whatever the giants decide, critics warn.

Right, it could take years or even decades, and many Net users (including 
businesses with embedded mail handlers built into their related 
applications) might in some cases not even *ever* be able to adhere to the 
changed specifications.

> At EarthLink Inc., which is experimenting with authentication, chief
>architect Robert Sanders said no service provider wants to suddenly stop
>e-mail from non-participants.

Right.  The authentication approach isn't really very effective unless and 
until EVERYONE is "authenticated", and the way the schemes are generally 
conceived, that mythical state of eternal bliss is NEVER in practice achieved.  And 
again, even after EVERYONE is authenticated, that STILL doesn't prevent them 
being a victim and sending out "fully authenticated" viruses, worms, and "my 
system was hijacked" spams!

> But he likened the technology to telephone's caller ID: "You may still 
>get a phone call with caller ID, but you may not choose to answer it."

There are a LOT of ways we can potentially "break" the world's E-mail system.  
My position is that we shouldn't do that unless the actual payback we'd 
achieve by doing so is truly compelling.  I still feel that the approach I'm 
proposing has the fastest payback to adopters, the lowest worldwide cost, the best 
effectiveness against worms, viruses, spams, spoofing, and "phishing", and 
the least unwanted and undesired downside costs to existing users, systems and 
applications.

Gordon Peterson                  http://personal.terabites.com/
1977-2002  Twenty-fifth anniversary year of Local Area Networking!
Support free and fair US elections!  http://stickers.defend-democracy.org
12/19/98: Partisan Republicans scornfully ignore the voters they "represent".
12/09/00: the date the Republican Party took down democracy in America.