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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On maandag, sep 8, 2003, at 17:30 Europe/Amsterdam, Dean Anderson wrote:

Nobody cares. Making a roof 100.000000% impervious to water molecules
may be impossible, but that doesn't mean we have to resign to getting
wet every time it rains.

People care because when someone comes around saying "you can have a 100%
impervious roof if only you jump through these inconvenient hoops", we
know that they are wrong, and don't need to waste time considering how
inconvenient the hoops are.

Your analogy doesn't fly. Our email protocols have holes big enough to drive a truck through. Is it unreasonable when people ask the IETF leadership for a place to work on this?


"We", meaning the IETF, care, because this is very useful aid to deciding
what to work on. We know that we need to focus on leak stoppage, not
trying to invent leak-proof protocols. There is no point researching
something that is impossible.

Let's first define our goal before declaring it impossible to reach.


After I first posted this on IETF a while back, someone suggested that
covert channels require cooperation, and that spam therefore isn't a
covert channel.

Where does this covert channel stuff come from anyway?

What do you mean?

The jump from "spam" to "covert channel" isn't immediately obvious. And if any proof of why spam is a covert channel has been offered, I've managed to miss it.


the spammer's achilles heel
is that they need to send out incredible amounts of email in order to
fulfill their objectives, whichever those are. Detecting bulk mail is
doable, and it shouldn't be too hard to come up with something to
differentiate legitimate bulk emailing from spam. For instance, we can
reverse the burden of proof here and only allow know bulk emailers.

"Detecting abuse" is quite different from making a protocol that can't be
abused.

If you can detect abuse on input rather than on output, detecting abuse is exactly what enables you to make an abuse-free protocol. And again: just because there are situations that you can't do something doesn't mean it's automatically useless to perform the action under other circumstances too.


But that is my point: You have to focus on detection. This
doesn't require any protocol changes whatsover.

Do you mean first accepting the message, then searching for anatomical, pharmaceutical or financial terms and subsequently discarding the message? This is useless as it only makes the spammers spam more, not less.


We are already "only allowing known bulk emailers".

Untrue.


Unfortunately, that doesn't prevent spam.

It should help if used together with some kind of authentication (for which, I'm happy to see, there are several independently submitted proposals on the table) so that spammers can't inject arbitrary from addresses.


Indeed, it seems most of the spam isn't commercial:
Most of the spam seems to come from viruses, and isn't really selling
anything.

The point being?


The viruses can use the credentials of the infected user. That is "legitimate", until someone reading the email realizes its not and
complains. These send 40-50 messages per IP, and is hard to detect as
bulk. But when added up over a lot of IP addresses, is quite obviously
annoying.

Not as annoying as "real" spam. (Although the size of email worms is unpleasant. Fortunately, regular spam is usually pretty small.)


Fixable with authentication.

No, that's the point. It isn't _fixable_ with authentication.  It isn't
fixable at all.  It is only "fixed" when the spammer loses his account.
Then the spammer gets a new account.  So it isn't really fixed.

It is when they lose their accounts faster than they can acquire new ones.


So we are always going to be playing a game of whack-a-mole.

So? I don't mind doing that if I can win. Having to play and then be forced to lose is much harder to swallow.


That cannot be avoided
by altering the protocol or the authentication scheme (information theory
proves this). So it is useful, then, to work on ways of detection, and
improve our whack-a-mole skills. Altering protocols and authentication is
a waste of time.

I find it unacceptable that my email software lets people bombard me with crap while at the same time faking the headers such that said crap seems to come from an innocent bystander. I can't understand how any reasonable person can think this is ok.


Or maybe we should just go ahead and move the "From: " header to historic and be done with it.



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]