ietf
[Top] [All Lists]

Re: Proposal to define a simple architecture to differentiate legitimate bulk email from Spam (UBE)

2003-09-06 22:47:55
On Sun, 07 Sep 2003 12:23:19 +0800, Shelby Moore said:

Interestingly note that Hotmail makes you pay to POP *FROM* hotmail, but no
charge to POP from other accounts *TO* Hotmail.  Does that give you any hint
about their business model??

Yes.  It's *NOT* a business model where they want to be polling a dozen servers
on a regular basis for each of their customers for mail that may or may not be
there, and for the average mailing list, probably is not there at any given
poll.  They want eyeballs, and the last thing they want to do is expend more
effort than needed to get eyeballs. Sure - they can even optimize the 'POP the
list' check by only doing it once for all the subscribers - but they're still
hitting each server for each list on a several-times a day basis.  And under
the current scheme, they can just *catch* one SMTP transaction with all the
RCPT TO's piggybacked *when there's actual mail*.  So they'd have to work a lot
harder under your scheme.

And let's *THINK* for a moment here - what is your proposal *REALLY* going to
change?  We already have many estimates that 50% or so of all e-mail is spam.
Let's take that as a given, and let's make the rash assumption that the rest is
25% mailing list traffic and 25% person-to-person.

So what you want to do is take the 25% of the list traffic that works just fine
on the current infrastructure, and is usually quite easily whitelistable via a
number of different methods - and move it to something totally different.
And what you're left with is a 2-1 mix of spam and personal mail that you
yourself admit things like the DCC and spam filters are unable to perfectly
distinguish.  To quote Douglas Adams: "Many reasons for this unhappiness were
proposed, most of which involved the movement of small green pieces of paper,
which was odd given that on the whole, it wasn't the small green pieces of
paper that were unhappy..."

Having exiled the mailing list traffic,  we would then be able to work on
separating the spam from non-spam - but as you already noted yourself, we don't
know how to do that yet.  And getting rid of the mailing list traffic doesn't
in fact gain us anything at all, since everybody who filters list traffic into
separate folders for each list knows that isn't the problem - it's the
unfiltered stuff that's left in the inbox.

I'll note in passing that the two highest SpamAssassin scores I've ever seen
were both on legitimate postings to mailing lists -  both were humor pieces
about spam....

Quite frankly, given that at least half the spam I get is already in obvious
violation of at least one law (pick one - securities fraud, advance-fee scams,
wire fraud, bogus pharmeceuticals, or hijacking a proxy to send the mail), I
severely doubt that anything the IETF does in regards to standards won't make a
difference. The spammers often don't even bother following RFC822 - why should
they follow your scheme?

The *only* two ways to get rid of spam both involve making it non-profitable.

The first is lowering the generated income.  Given that recently, somebody
hacked the site of a "fertilizer for your body part" scam, and found a list of
6,000 people who had paid $50 a bottle, I have to sadly conclude that Korbluth
and Barnum were both correct, there's one born every minute and the rate is
increasing.  So there's no joy to be found there.

The second is raising the cost to the spammer.  Personally, I like the idea of
taking up a collection among the ISPs and other providers, and hiring some good
ethnic muscle (there's competition in the field, a number of experienced and
ruthless groups are available).  I'm sure the spam problem would change
drastically if the spammer was seriously having to balance the mentioned $300K
for bogus enhancement pills against having their kneecaps broken by one group
or worse by one of the other groups...

Pity that will never work though.  At least not officially (although one 
infamous
New Zealander apparently retired recently...)

Attachment: pgpKgHcMZU3fI.pgp
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>