My apologies for this message. This discussion is winding down. Iljitsch
makes some interesting points, to which I have tried to respond
thoughtfully.
--Dean
On Tue, 9 Sep 2003, Iljitsch van Beijnum wrote:
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?
I don't think our email protocols have any holes at all. They can be
abused. But mere abuse is not a "hole".
"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.
Well, I think the goal has been stated: Create an abuse-free email
protocol. That goal is impossible. Thus, we have abusable protocols.
Perhaps you have a different goal in mind, but it doesn't sound like you
accept the premise that it impossible to create an abuse-free protocol.
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 NCSC's definition refers to ANY communication not authorized by the
security model. Note that the term "Covert Channel" is frequently
associated with Multilevel Secure Operating Systems. The liturature uses
other terms to describe the same concept: "information leakage", "sneaky
signalling", "hidden data flows", "side channels". So you must not get too
caught up in the peculiarities of operating systems. The concept is quite
general.
It is immediately obvious that covert channels have 3 characteristics: It
is a CHANNEL, it is COVERT, and it VIOLATES SECURITY POLICY. (Caps for
emphasis of definition, not loudness.)
CHANNEL: Spam is a type of Email. Email is a channel transfering signals
from A to B. Email is really a subchannel of the internet, which is a
subchannel of the PSTN, public and private fiber networks, etc.
COVERT: Spam is hidden in so far as possible from the system operators. It
is an unintended communication in that the system operators intended that
only non-broadcast, solicited commercial communication flow. This not an
exclusive list of what is permitted, but illustrates that spam isn't
permitted.
VIOLATES SECURITY POLICY: System Operators specified an acceptable use
policy that outlines what is permitted and what is not permitted. UCE is
not permitted. Various methods have been implemented to enforce this
policy.
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.
Input to the first mailserver is output to the mail client. There may be
many input/output connections. For every input, there is an equal and
opposite output. (Seems that perpetual motion may have some analog after
all ;-)
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.
Speak for yourself.
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.
Spammers can _always_ do whatever regular users can do. There is no way to
authenticate regular users and not authenticate spammers. This is why SMTP
AUTH has no effect on spam. If regular users can inject arbitrary
addresses, then so can spammers. Regular users can always inject
arbitrary addresses. Ordinarilly, this is desired.
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 point being that the persons sending most of the spam will do anything
to annoy people. It has no grounding in commercial motivation, nor can
regulation of commercial activity have any effect. In other words,
protocols that require cooperation of the spammer aren't likely to
succeed.
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.)
You miss the point. Most of the "little" spam is sent by virus infected
computers as well as email containing the virus itself.
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.
Has this ever happened in 8+ years? No. Will it ever happen? No: ISPs
aren't ever going to terminate accounts immediately on someone elses
say-so. First, it wouldn't be good business not to investigate
accusations, second, it wouldn't be legal, and third, the blacklists have
a terrible record of abuse, themselves.
The spammer already has authentication, however it was acquired: Stolen,
disposable, etc. Email authentication will always be equivalent to that
authentication. The user either has both, or they have neither. If they
lose their account, they lose both. It is unnecessary to add more
authentication. An engineer should know that two variables that always
have the same value can be replaced by one variable.
The notion of authentication in email comes from the fallacy that spammers
are somehow outsiders getting in. They are not outsiders. They will never
be outsiders. It is impossible to construct a protocol that makes them
outsiders, any more than it is possible to make a protocol that keeps out,
say, democrats.
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.
You can only win by detection and suppression. Suppression has to happen
faster than account termination. The only way that can happen is by
filtering the recievers email.
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.
People find it unacceptable that fertilizer explodes. However, it is
impossible to make fertilizer that doesn't explode. Only those ignorant of
chemistry call for such things.
Or maybe we should just go ahead and move the "From: " header to
historic and be done with it.
Might as well add all the other headers than can be forged as well. Might
as well take the From Address off postal mail as well, since that can be
forged, too. It is a mistake to think that just because something can be
abused, that it should be removed.
--Dean