Re: [Asrg] [IP] 4 Rivals Almost United on Ways to Fight Spam

["David Wall" <d.wall at computer.org>]

> I just can't understand all these people that are vehemently against
> authentication.  There are valid arguments on how spammers will work
around
> the authentication barrier, but I just can't imagine in any circumstance
> that authentication would do anything but push us in the right direction.
> What in the world could be wrong with any solution that defeats "mail
from"
> spoofing?  That alone should justify domain level authentication
regardless
> of whether or not it will directly curtail spam or not.

I think some of it will come out in practice.

For the most part, systems like PayPal, for example, will show the FROM line
as the person who sent you money, but because they have the Return-Path
specified as their own system, SPF will likely allow them to be sent.  So
users will still see the "FROM" using a name that they may trust, even if
the actual sending system is not from that person's email domain-allowed
SMTP server.  Also, when this occurs, you also tend to lose the natural
"nice bounce" that you would get if you requested money from someone but put
in the wrong email address.  Today, if you send money (or request money)
from someone and you mistype their name, you get no indication anything has
gone wrong.  You can then click the "resend" button, but that just sends
another email that will also bounce since you don't know anything's gone
wrong.  Under the old model, you'd get a bounce, which was very informative,
since it would tell you things like "undelivered in last 4 hours, keep
trying," "unknown user," "failed to delivery after 5 days; deleted" etc.

Bounces are not standardized, so it's nearly impossible to programmatically
extract bounced emails and then automatically inform the sender that
something has gone wrong.  There's typically no reliable way to link the
bounce with the original email.  Some include the original, some do not, so
it's a real pain to resolve.

Of course, this is not only true of PayPal, but its true of many other
groupware systems, hosted solutions like PayPal in which customers have paid
to belong to a community of one type or another and want to be able to work
with others, typically referencing others via email addresses, but then not
getting any feedback when things bounce.

It's unlikely that many users can add an "INCLUDE: PAYPAL.COM" to their SPF
records since that would mean getting AOL, MSN, Earthlink or others to add
"INCLUDE:" statements for all such groupware systems, and that wouldn't be
practical.

There are also numerous "community web sites" in which a large number of
small companies share a "virtual" community of web sites, all operating on a
single web server and being db-driven.  Those systems (they often support
small law offices, small health clinics, local stores, etc.) also have
"features" that will break, like being able to send out newsletters,
coupons, auto-responders, etc. since they will no longer be able to send
those out using the small businesses's email addresses (they sometimes have
their own domains and could do SPF if they knew how, which they generally
don't, or they have AOL, Earthlink, Yahoo! etc. addresses).

By the way, such groupware systems are not just created by systems like
PayPal, but there are other corporate systems that also use such systems to
send out notes between collaborating parties using the same scheme.
Previously, they just sent out emails FROM the one part TO the other party
and all was okay. Those applications will all have to be modified in some
way, with the most likely being that they'll adjust the Return-Path and
users will lose the "handy bounce" that informed them when they got things
wrong.

Another practical concern are mailing lists that cover non-techie topics and
are usually run by sysadmins who aren't technical, have no money or time to
learn about new stuff, threw up a discussion forum mailing list using older
software, and they won't have the capability to upgrade their systems.  So a
working system will just stop working and that non-techie community will
suffer.

None of those are spam, but they all have this characteristic of a single
systemt that sends out emails on behalf of a large population of users.
Getting bounces was useful because it let you know that you no longer had a
good email address, but that's lost with SFP forcing a common Return-Path.

Then others have real concerns about "slippery slope" arguments.  Each form
of additional authentication comes in slowly and surely until email has lost
one of its nice aspects of being someone anonymous, or perhaps more
accurately, pseudononymous, much like what happens in AA meetings or when
discussing issues that are politically sensitive.  When someone goes out as
Pizza1234 at aol.com he's not truly anonymous, but he is pseudononymous, and of
course users can resort to hotmail/yahoo/gmail for their more anonymous
needs (as long as free email accounts are allowed by law).  SPF doesn't
really have this problem, but the argument is that SPF won't stop spam
either, so the "next step" will be taken and more and more authentication
will be required until people are forced to identify themselves to send
email, in which anonymous "free" email is outlawed.  This tendency seems to
be happening even when these people aren't forced to do so to send plain old
mail.  Sure, it may not come to pass, but maybe it'll be worse.

Most of us who are concerned about such liberties wish the world would
instead focus on prosecuting existing spammers.  It's like giving up on
justice and just saying we'll hunker down harder rather than stop criminal
behavior in the first place. (By the way, this is certainly not
unreasonable, just sad.  After all, we lock our doors and many in cities put
iron bars over their windows despite the obvious fire hazard and ugliness
because law enforcement failed them too.)

David


_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg