ietf-asrg
[Top] [All Lists]

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

2004-03-01 12:47:45
gep2(_at_)terabites(_dot_)com 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
actually originated at that system.

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 <sethb(_at_)panix(_dot_)com> 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.

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.

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.

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.  

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 
and disable exceedingly useful and important features.

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
me(_at_)my(_dot_)company, 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 me(_at_)my(_dot_)company 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
"security(_at_)yourbank(_dot_)com" 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.

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.

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.

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

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.

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

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.

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
E-mail system.

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

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg