Your goal is to reduce the number of spam messages visible to end
users.
That's part of it, but only a part. Let's not confuse spam QUANTITY
(number of messages) with spam VOLUME (number of messages * average
size of a spam message).
I don't see how you are arguing for any reduction of volume at ISPs,
since you want to accept all messages presented via SMTP, analyze them
and perhaps reject afterwards. What that represents is a reduction in
quantity visible to the end user only.
You missed the (a?) key point,. One spammers realize that (bulky) attachments
and (bulky) HTML (or large E-mails!) are the kiss of death for the spam they're
sending, and will make it FAR less likely that their spam will be read, they'll
be motivated to send smaller E-mails with neither spam nor attachments. Thus,
the reduction in overall, aggregate spam bulk.
That's a good goal, but has nothing to do with reducing the
amount of data processed by ISPs who operate SMTP server farms for
their customers. Let's not mix up the issues.
I disagree.
First, if we were ever to reach the state where ZERO (or near zero)
spam messages reached end recipients, then spamming would be 100%
without profitable return to the spammers... it wouldn't continue
for long under such conditions.
That isn't the issue discussed.
It ABSOLUTELY is.. since that is ULTIMATELY the way we want to reduce spam
volume. :-)
Long before your client side solution hopefully blocks 100% of spam for all
users,
1) It doesn't have to be 100% to have a substantial impact.
2) A client-side solution can be implemented FASTER since it doesn't require a
globsl concurrence, and doesn't require reworking the whole Internet.
...ISPs must address increasing volume or change their offerings.
They clearly have a vested interest in helping make sure that their customers
solve this problem (much like the way AOL has started providing free antivirus
software to all of their customers).
By the same token, AOL could similarly make a BIG impact by updating their
E-mail client software to include a fine-grained, by-sender permissions list
approach such as I propose. This would by itself make a huge impact on
spamming
profitability, and could be done quickly.
Moreover, I am far from convinced that spammers will stop sending mail
just because near zero messages reach the recipients.
Some people still aren't convinced we really landed men on the moon in 1969,
either. The fact that some people will always be skeptical isn't a good reason
to stick with the status quo,
Given unlimited resources for free,
That's why the permissions list idea makes a MAJOR strike against E-mail
transmission of worms and viruses. This will shut the door (at least regarding
E-mail) on zombie recruitment. SPF and other DNS-based approaches do
**NOTHING** to control zombie recruitment, which is a big reason why those
approaches are doomed to failure.
the correct response to dwindling success rate is
to increase quantity.
"If at first you don't succeed, try, try again." But it goes on to "...but
eventually, quit... there's no point being a damned fool about it." :-)
The cost of spamming (while small) is NOT zero. At some point, as the return
to
be earned from spamming shrinks, it is no longer profitable to do it. There
are
also increasing dangers of successful lawsuits (as in the recent case of $1B
being levied against the first three spammers in a group of 300...)
Whether people actually see spams in their
inboxes is irrelevant for ISPs, as they still have to find a way to
deal with the spams sent to them.
Right, but spams have no value if people don't see them. If people don't see
them, eventually spammers will stop sending them, and thus ISPs will benefit
(and greatly) by reduced success rate from spamming.
Second, if spammers get the message that spam containing
attachments or that is HTML-burdened has GREATLY REDUCED chances of
being delivered and read, then they're likely to stop using those
approaches (and those approaches hugely inflate the size of most
spam messages). Thus, a likely HUGE reduction in spam volume
(including, in particular, that which ISPs receive and process).
No. Spam volume isn't controlled by HTML, you'd have to outlaw the
MIME standard, otherwise people and spammers can send image
attachments, Word attachments etc.
HTML-burdened e-mails are typically 3-5x bulkier than non-HTML-burdened e-mails
with the same content.
Yes, attachments are also bulky, and the permissions-list approach would (by
default) block or quarantine E-mails containing attachments (images, Word
documents, etc) from unknown senders, too. So those would cease to be a useful
plan for spammers wanting to get their E-mails read.
But outlawing MIME won't help anyway, as people can fall back on uuencode
type
methods, which are plain text.
Note that we're not talking about 'outlawing MIME', but it WOULD involve only
allowing MIME attachments from senders you trust (and even then, only the TYPES
of attachments that you trust them to send you). And I wouldn't have a problem
with considering UUENCODED (or similar) content as an "inline attachment" and
thus not allowing it (by default) from untrusted senders, even if it is
supposedly represented as being "plain text".
The huge reduction in volume you're hoping for based on
message structure will never happen.
Back in 1977 (December 1st, in fact), when we publicly announced the ARC
System,
my friends told me, "Gordon, you're crazy... big business is never going to
give
up their mainframes and run their processing on networks of little computers!"
My answer at the time was "...YOU JUST WATCH!!!" And time, I think, has borne
me out.
I've had skeptics before. As the old saying goes, "he who laughs last, laughs
best."
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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg