Subject: [Asrg] [IP] CNN covers Meng's SPF

From: [email-masked]
Date: Mon, 01 Mar 2004 12:57:12 -0600

> 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
[email-masked].

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.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Seth Breidbart <[email-masked]>
Date: Mon, 1 Mar 2004 14:41:36 -0500 (EST)

[email-masked] wrote:

> 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

Which is better than SPF exactly how?

> 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.

You're confusing a news article with reality.  In the actual
proposals, any domain owner gets to specify which IP addresses can
send mail "from" that domain.

> 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.

You need to be specific.  Anonymous remailers claim that the mail came
 from them, and they will certify that fact, so what's the problem?

Mailing list hosts will claim that the mail came from them and certify
that fact.

Personally-owned and corporate domains will likewise certify that the
mail came from them.

Roaming users who get random IP addresses will have several options.
One is to use the mailserver of whatever domain they _claim_ to be
sending from.  Another is to register their current IP with the domain
owner so that the domain will certify it (for some time period).

If I'm at an airport lounge kiosk and I send email, it can either
admit that it came from airportloungekiosk.wherever, or I can connect
to Panix and send mail from there.  Otherwise, if _I_ can send mail
claiming to be from <[email-masked]> from the kiosk, so could you (or
a spammer), and I don't want that.

The actual problem is "requested remailers" (such as acm.org, or many
colleges that forward email for graduates).  That fails under many
current implementations, so either the remailer has to be specially
trusted, or it will have to rewrite headers in a specific way.

> all it does is to authenticate the sender.

Spammers forge, so rejecting mail from anti-authenticated senders will
reject spam.

>  Spammer-friendly ISPs,

Can be blocked by _name_ if they can't forge.

> 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.)

There are ways to catch those, too, which I don't want to reveal in an
open mailing list.  I will suggest greylisting a new domain (new="I
haven't seen much email from it yet") as a start.

> 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.

Then pressure will be put on their ISPs (partly by being blocked for
emitting spam).  Note that the spam will have to come through the
ISP's mailserver, because the ISP won't certify random cable modem IP
addresses as authorized senders.

> So in fact, Wong's system creates MUCH pain,

and avoids more

> requires changes to systems literally everywhere in the world,

Only those that do authorized forwarding, or their receivers.

> hugely inconveniences (or even disables 
> entirely) many types of users with highly legitimate needs,

You may consider their "needs" to be "highly legitimate" but I don't
have to, and if there's nothing preventing a spammer from acting just
like one of them, I don't want to, either.

> and still doesn't really do much of anything to actually solve the
> problem.

It would cut way down on the spam I receive.  That's a good thing.

>  It still leaves people sending and receiving spam,

Sending yes, receiving no.

>  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.  :-(

Except the clueful and those with good ISPs (that can prevent their
victims from actually getting spam out).  I don't see a problem with
that.

> Again, NO IT DOESN'T.  It only helps identify where they actually came from.  

Which means it's easier to disinfect, limiting the spread.

> 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.

Earlier, you were objecting to things that required changes all over
the world.  There are a lot more clients than servers, and they change
more slowly.

Besides, there's plenty of plaintext spam, and if that were the only
sort that got through, spammers would just switch to it.

> 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.

For a value of "OVERNIGHT" that includes the multiple years before a
majority of client software is upgraded.

It also does absolutely nothing to stop non-email viruses and worms,
such as those spread directly through flaws in operating systems.

> 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.

So why don't you just do it and stop yelling about it?

>  And, once whitelisted, EVERYTHING we can do today (vanity domains,
> roaming, mailing lists, send-from-cruise-ship, and so forth) all
> still work, too.

So if a spammer can figure out or guess somebody you have whitelisted,
he can still get your machine infected by forging that sender's
address.  In fact, this becomes _more_ likely to work, due to the
false belief that only safe attachments can get through.

> Actually, almost all of these other approaches (INCLUDING Wong's) DO
> involve the need for worldwide changes and consensus,

They help those who use them, and have no effect on those who don't.

> they prevent legitimate users from 
> doing things they sometimes truly NEED to do,

Those are things that spammers want to do, and in your world there's
no way to tell the spammers from the legitimate users.  (They also
don't prevent the needed things, as I've shown above.)

> most DO involve changes to the DNS 
> system (or else the construction of a wasteful parallel to it),

You mean adding a few records?  Big deal.

> 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.

Neither does your proposal.

>  They only inconvenience people everywhere 

Those "useful and important features" are that way primarily to
spammers, others have easy workarounds.

If I'm travelling and need to send email claiming to be from
[email-masked], I should connect back to my.company's mailserver to
send it; otherwise, what prevents the guy in the next hotel room from
claiming to be [email-masked] in his forged email?

> 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 would likewise have little impact on spammers.  It is not at all
effective against phishing spoofs (since spammers could forge
"[email-masked]" as the sender and put the URL to go to in
plaintext, coding it in a way that will fool enough people into
thinking it's real).  It is not at all effective against plaintext
spam.  It works a little against email-borne viruses and worms, but
not against others.

> signature technology.  Again, no infrastructure changes are required or even 

Strange how "normal public-key signature technology" is "easy" when
you want it to be, but even simpler techniques are infeasible when
they aren't your proposal.

> from making the changes.

They don't require consensus, just enough adoption.  The earliest
adopters apparently do think it's worth doing, that's why so many
large email senders are publishing SPF records _now_.  Some of the
large (and, for that matter, tiny) receivers are checking them, too.

>  They are expensive (because they have to be done EVERYWHERE)

They're providing benefit now, even when not done everywhere.

> and in the end, when all is said and done, THEY DON'T SOLVE THE
> PROBLEM!

It has been suggested that nothing short of hangings will do that,
although others believe that public floggings may suffice.

> might in some cases not even *ever* be able to adhere to the changed 

If you can't distinguish yourself from a spammer, that's not my
problem.

> that mythical state of eternal bliss is NEVER in practice achieved.

Look up the word "suddenly".  There are many effective partial
solutions (including such things as rate-limiting unauthenticated
email to increase the pressure to authenticate, without blocking it
entirely).

> There are a LOT of ways we can potentially "break" the world's

My toys, my rules.  If you don't abide by the requirements I set for
sending email to me, then your email won't get through to me.

>  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.

How much has it benefited you so far?

Seth

---

From: "Roger B.A. Klorese" <[email-masked]>
Date: Mon, 1 Mar 2004 11:48:15 -0800

> a spammer), and I don't want that.

Um, why?

If I authenticate to Panix.com, you should trust that I'm sending legit mail
through you, whatever domain I'm using to send it, or you should revoke my
ability to authenticate. 

Trust the people you contract service for.  Don't contract service for the
untrustworthy.

---

From: Seth Breidbart <[email-masked]>
Date: Mon, 1 Mar 2004 14:54:45 -0500 (EST)

> through you, whatever domain I'm using to send it, or you should revoke my

I'm a user here, not speaking for Panix.

I meant if I can send email to a random recipient (e.g. hotmail)
claiming to be <[email-masked]> but I don't authenticate myself to
Panix in the process, then you can do the same.  (There's no way for
me to authenticate to hotmail, because they don't know anything about
me.)

If I authenticate myself to Panix, then I can either send email
through them (in which case SPF works fine, Panix's outbound
mailservers are listed) or I can persuade them to temporarily list the
IP I'm using (if their software works that way) so hotmail will
believe me.

Seth

---

From: "joe" <[email-masked]>
Date: Thu, 4 Mar 2004 11:37:03 -0500

I fully concur with Gordon's analysis and suggestions. 
I would argue that another single ended solution could be used to
further dramatically reduce spam. i.e. disposable email addresses or
DEA.
With DEA you no longer advertise your email by giving it away when you
sign up to web sites.

I specifically like Protecteer's product SignupShield which integrates
DEA with form filling for automatic sign-up to Web sites.

No single solution is going to do it!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, March 01, 2004 1:57 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Asrg] [IP] CNN covers Meng's SPF

> NEW YORK (AP) -- With a simple adjustment in your e-mail software, you

> can

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

> 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. :-((  

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.

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.

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".

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.

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.)

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

Absolutely.

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 

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.

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" 
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 
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.

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

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 
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.

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

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.

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

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.