Subject: proposal for built-in spam burden & email privacy protection

From: Ed Gerck <[email-masked]>
Date: Sun, 08 Feb 2004 16:05:24 -0800

Email privacy and spam are such general problems today that I'd 
like to ask the ietf-org list for feedback (private if you wish)
on this suggestion. There are more specific forums where this 
can (and shall) be discussed.

Suppose:

1. I make my public-key available wherever my email address is given;

2. Except for senders in a whitelist (e.g., list mail), I bounce to the sender
any email that is NOT encrypted with my public-key, providing my
public-key and instructions for the sender to resubmit the message
properly encrypted.

This would make spammers pay FOR EACH message sent, as messages
would need to be encrypted FOR EACH recipient. At the same time, it
would promote email privacy protection en route, including at ISPs
and before mail pickup at POP boxes.

The end points would not be  authenticated at this time, making it much
simpler to implement. Sender authentication is also not effective as a
burden mechanism for each message.

The built-in spam burden & email privacy protection afforded by this 
procedure would not be costly to use as there are several free tools 
available for encryption. The whitelist should provide a backward path 
for those who don't want or can't use encryption at this time.

Comments?

Cheers,
Ed Gerck

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 8 Feb 2004 20:21:02 -0600

Hi, Ed,

I don't know everything about e-mail, although I do send and receive
e-mail from time to time.

I would be interested in reading reasons from others why this is a bad
idea. It seems interesting to me.

The only thing I'm wondering about is, since all the press reports
about recent viruses say they set up zombie networks, I'm wondering if
placing a CPU burden on someone who controls 100,000 PCs is harder
than you think...

Spencer

----- Original Message ----- 
From: "Ed Gerck" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, February 08, 2004 6:05 PM
Subject: proposal for built-in spam burden & email privacy protection

> _______________________________________________
> This message was passed through [email-masked],
which is a sublist of [email-masked]. Not all messages are passed.
Decisions on what to pass are made solely by IETF_CENSORED ML
Administrator ([email-masked]).

---

From: Franck Martin <[email-masked]>
Date: 09 Feb 2004 16:53:40 +1200

Ed,

Where is your digital signature in your e-mail?

I wonder if we could add to this list, that non digitally signed e-mails
and invalid digitally signed e-mails get held for approval.

I would be nice that the IETF members of this list show the way by
enabling at least GPG or s/mime for digital signing of all their
messages to the list.

If we use what we preach it will help in real implementation, and may be
reduce SPAM.

Cheers.

> Ed Gerck

----
Franck Martin
[email-masked]
SOPAC, Fiji
GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
"Toute connaissance est une reponse a une question" G.Bachelard

---

From: John C Klensin <[email-masked]>
Date: Mon, 09 Feb 2004 08:35:47 -0500

--On Sunday, 08 February, 2004 20:21 -0600 Spencer Dawkins 
<[email-masked]> wrote:

> Hi, Ed,
>
> I don't know everything about e-mail, although I do send and
> receive e-mail from time to time.
>
> I would be interested in reading reasons from others why this
> is a bad idea. It seems interesting to me.

Let's assume I have a mailing list.  Take the IETF list as a 
handy example.  This technique implies that

(i) The IETF list exploder needs to track several thousand (I'm 
just guessing at the number here) public keys, encrypt each list 
message separately and mail it separately or encrypt each 
message going out for all of the recipients (the latter is 
somewhat less network intensive on some dimensions, and slightly 
less computationally intensive, but not much, and would ensure 
that every message going out, even trivial ones, was 40K-50Kb 
long, minimum).  With current computational capacity at the 
secretariat, I think that would probably throttle the IETF list 
back to a handful of messages a day, total.  That might be a 
good idea, but is probably not the intent :-(

(ii) All a spammer would need to do would be to guess or know 
one of the addresses that is subscribed to the IETF list, or 
subscribe temporarily himself, then post the spam to the list, 
in order to get the list exploder to do that work for him.

Now, Franck's suggestion would work better from a list 
protection standpoint (but not from an expense one, unless the 
two were combined).  For it, the spammer would need to have a 
key pair, and would have to sign every message.   That would 
merely require the list exploder (and perhaps you) to have the 
public keys of everyone who could post to the list (that may 
imply more or less a general solution to the PKI problem, 
including the key revocation piece) and to verify the 
signatures.   And, of course, nothing would prevent a spammer 
from generating a key pair, signing up for the list,...  and 
then doing it again when that key pair/ mail ID was blocked for 
bad behavior.  Remember key generation is cheap, unless we 
require people to go to a source for certificates that charges 
significant money for the service.

Next?

:-(

> The only thing I'm wondering about is, since all the press
> reports about recent viruses say they set up zombie networks,
> I'm wondering if placing a CPU burden on someone who controls
> 100,000 PCs is harder than you think...

That too.  And, of course, the IETF list exploder doesn't 
consist of 100,000 PCs, nor does any other mailing list service 
I know of.

We really need a "things that seems to be good anti-spam ideas 
but aren't" list to be compiled and linked to from the ASRG and 
IMC spam pages.  It would save everyone a lot of time and energy.

    john

---

From: Frank Solensky <[email-masked]>
Date: Mon, 09 Feb 2004 09:06:16 -0500

On Mon, 2004-02-09 at 16:53 +1200, Franck Martin wrote:
> I wonder if we could add to this list, that non digitally signed e-
> mails and invalid digitally signed e-mails get held for approval.

I don't think that will scale too well when the list gets active.  And
white-listing someone once they're been approved gives the spammers a
tidy list of which sender addresses to fake.

"Be liberal in what you accept" should apply to the IETF mail server as
well.
> enabling at least GPG or s/mime for digital signing of all their

Don't get me wrong: encouraging people to use pgp is a good idea, but
making it a requirement before accepting it is a policy decision that
the end user should be making, not the list.

---

From: "Robert G. Brown" <[email-masked]>
Date: Mon, 9 Feb 2004 08:46:16 -0500 (EST)

> placing a CPU burden on someone who controls 100,000 PCs is harder

This would scale terribly in so many ways, and ultimately would be no
more effective than anti-spam methodologies already in place.  A
whitelist is a whitelist, esig or not.  How does this in any way alter
the flow of SPAM or a spambot's operation other than to add a step?

Anything at all that generates a bounce message on a mass-produced
mailing acts as a "damage amplifier" from the basic internet backbone's
point of view -- at least doubling the associated automated traffic and
wasted/misused resources.  These days such a bounce is especially
fruitless, as all viruses and quite a lot of SPAM have forged headers
that the stupid bounce agents cannot or do not parse.

This is pet peeve of mine as it is -- I got (and continue to get) more
bounce messages from mydoom reporting that mail "from me" is
contaminated than I do copies of the virus itself.  No virus for two
years now hasn't forged mail headers -- the From field is totally
irrelevant in all current viruses-- yet all the AV programs in the world
think they are doing you a favor. NOT.

Now imagine that sort of stupidity scaled out so that every MTA in the
world is checking esigs and bouncing improperly signed mail.  Imagine
the loops created when a legacy mailer or improperly configured mailer
bounces the bounce messages back to the bouncer, to be bounced again.
Nightmarish.

   rgb

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:[email-masked]

---

From: Franck Martin <[email-masked]>
Date: 10 Feb 2004 08:58:17 +1200

> good idea, but is probably not the intent :-(

I'm not asking for the list to encrypt the e-mails to each member, but
just to pass along the esig as it does now... see this esig mail. May be
the list can check the esig of the person posting, or each one of us
check it.. I would prefer if the list does it and held anything else for
individual approval by moderators of the list

> in order to get the list exploder to do that work for him.

If he subscribes himself, then we have his e-mail address and then his
provider and may be an IP and time, so we could track him down in the
real world and may be sue him...

----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: Franck Martin <[email-masked]>
Date: 10 Feb 2004 09:01:27 +1200

> tidy list of which sender addresses to fake.

So? They are doing it already... and it is not a whitelist, each message
posted to the list need to be signed and the signature must be valid...
only the sender with his public key can sign... posting under somebody's
fake e-mail won't do...

> the end user should be making, not the list.

I'm not saying to reject non esig mails, but to held them for approval
by moderators... If you want your post to go through quickly, sign it...
It would be a worthwhile incentive...

Cheers

----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: Ed Gerck <[email-masked]>
Date: Mon, 09 Feb 2004 13:49:53 -0800

Thank you all for your comments so far, public and private. This
reply addresses all the points I received. If I left anything out from
anyone, please point it out to me.

There seems to be some confusion between signed versus encrypted
email, as well as listserver traffic handling. Please note:

1. I did NOT suggest using signed email (and explained why).

2. I suggested using encrypted email, using the recipient's public-key.

3. I EXCLUDED signed email for the first phase (for reasons well-
known to anyone who is following PKI).

4. If you forge the From address, you won't know how to reach me
-- which is desirable.

5. If you sub to a list and that list's traffic is not encrypted to your
key, you simply add the list's address to your whitelist (btw, I mentioned
this also as a backward-compatibility mechanism in general).

6. Spammers trying to misuse a list as a proxy encryptor (in the
case the list encrypts traffic for each member) could be stopped
before the act in the same ways that lists currently fend off spammers.
In case a spammer does get around the defenses, the additional encryption
burden should be enough motivation for the list's administrator to be
more diligent -- it hurts at home. And, IMO, this is fair because the list
is allowing itself to become a spammer's tool, with or without encryption.

    NOTE: the proposal WANTS to penalize spammers. If a list becomes
    a spammers' proxy (willingly or not), it is forwarding spam.

7. Large public lists however, such as ietf-org, should probably NOT be
encrypted per member's public-key (because of high list burden, even though
legitimate). Rather, traffic should be signed with the list's private-key,
allowing anyone to verify that the message has  satisfied the list's
posting and routing policies before being forwarded. This would
also prevent ghost messages that seem to be from the listserver but
are not.

8. How about spammers using 100,000 slave PCs to share the burden?
Even if a spammer could control 100,000 PCs, the spammer would
need to set up EACH PC with public-key encryption software AND
the public-key for each targeted email address. Anyone working in PKI
knows that this is an extremely hard task for anything more than a
handful of hosts -- even with cooperating hosts.

9. But... what if I'm still worried that #8 is possible  just for me? Is
there any recourse using the proposal? Yes -- keep your email address and
change your public-key. An automatic reply saying that your public-key
has changed to value XYZ would be useful to legitimate users and make
life harder for spammers.

10. How about which standard to use? S/MIME, PGP/MIME, etc.?
The ensuing market forces should help, finally, consolidate encryption
standards and promote interoperation. Usage drives standardization and
this is a good thing. Imagine  if, as a comparison, we would need to choose
which protocol to use before visiting a web site? Your browser handles it --
HTTP or FTP, for example, it's all transparent to you.

Comments?

Cheers,
Ed Gerck

---

From: Dean Anderson <[email-masked]>
Date: Mon, 9 Feb 2004 18:57:39 -0500 (EST)

> real world and may be sue him...

So instead of using his own email address, the abuser sends a virus to a
bunch of people, and when they get infected, the infected "send" the spam,
and then we just track down an infected user, and disinfect them.  
There's more, see below.

As I've said for some time, most of the junk we are getting is currently
from viruses run by abusers, not from genuine spammers.  Now the
statistics are starting to show this. I just saw some stats on the top 95
real spammers that show that most are complying with the new federal
anti-spam law, and that over half (56%) are fully compliant.  Yet,
checking my own inbox, I find very little spam that is compliant, or even
partially compliant.  Apparently, most of the "spam" doesn't come from
real spammers.

Some might say "so what? it doesn't matter whether the abusers really want
to sell products/services/scams etc".  Actually, it does matter.

When you realign your anti-spam efforts from control of business to
control of techno-terrorists, the problem is quite a bit different, and 
you can see also that things like signing and other things aren't going to 
work.  

Now we have the criminal law tools needed to go after the abusers: That is
road to stopping spam.  You don't need to sue anyone--you need to
prosecute them for criminal violations of the can-spam act, and criminal
violations of the Computer Fraud and Abuse Act (for virus infection).  
Criminal investigations have a much easier time of getting the information
that is needed to identify and prosecute the criminals.

I don't expect that this is going to net spammers.  I expect it will net
anti-spam radicals seeking to annoy people into a ban on spam. Here's why:
A careful review of the history of the spam wars shows that the radicals
have been conducting the abuse from the time of the Internet E-Mail
Marketing Council (IEMMC).

The IEMMC was formed in May of 1997 between Cyberpromotions and AGIS and
some others. Its goal was to encourage voluntary spam labeling and opt-out
lists, and to work out a compromise on spam between the advertising and
technical community.  It truly infuriated anti-spam radicals.

In August 1997, Cyberpromo's web site was hacked, and files and email were
deleted. 

AGIS then came under a large Denial of Service attack, and finally
succumbed and disconnected Cyberpromo and withdrew from the IEMMC, in
September, 1997.  When the IEMMC collapsed the radicals probably thought
their abuse tactics were effective, and were probably encouraged to 
continue their abusive behavior.

One might say this is ancient history, but in fact, the IEMMC position on
spam was practically legislated in the CAN-SPAM act, with the caveat for
criminal violations.  Its also interesting in light of the attacks on
Cyberpromo and AGIS. These attacks are typically associated with groups of
script kiddies.  Vixie has subsequently reported that he is in contact
with the "script-kiddies" and that they are mostly anti-spam. Being
anti-spam is not the same a being anti-mailbombing, which is the
script-kiddie term for their fake spamming.  What the CAN-SPAM act did was
revive the ideas of the IEMMC, and in doing so, it changed genuine spammer
behavior so that genuine spammers can be distinguished from that of the
radicals/abusers.  Now it is just a matter to use the criminal provisions
to track down the abusers, and punish them.

What does this mean?  For one thing, it means that we will be able to use
criminal investigations to identify the abusers. I expect that these are
essentially the same radicals who were attacking cyberpromo with DOS
attacks in 1997; that have been filling email boxes with spam and fake
opt-out links since 1997 in the hope of motivating people to demand the
spam be banned; that have released many viruses that send spam.  But it
will be interesting in any case. Importantly, it will eventually stop the
abuse.

Criminal complaints can also be issued against individuals outside of the
United States with good effect.  It is much more difficult to exercise a
civil suit internationally.

The second thing it means is that you can forget trying to create
technical solutions to spam.  Not only can't such schemes succeed in
preventing techno-terrorism for reasons drawn from information theory as
previously explained, but they are now unnecessary.

		--Dean

---

From: Ed Gerck <[email-masked]>
Date: Mon, 09 Feb 2004 18:40:22 -0800

Dean Anderson wrote:

> ...

Signing doesn't work because it cannot provide a load per recipient,
just per sender. Encryption with the recipient's public-key (as I am
proposing) works because the spammer must encrypt each message
for each recipient. This applies to lawful spammers as well, finally
adding friction to email by creating a mandatory "fee" (burdenwise) to
send messages.

BTW, my previous posting provided a rationale for proposing the following
requirement for any current or future mail system:

- Users do not want requirements to pay for sending email or to be
otherwise burdened in any way in order to stop spam. Stoping spam
should not be a user's problem.

The above anti-requirement is attainable, fair to all, and cannot be forged.

Cheers,
Ed Gerck

---

From: Franck Martin <[email-masked]>
Date: 10 Feb 2004 15:21:35 +1200

> adding friction to email by creating a mandatory "fee" (burdenwise) to

I understand you try to add CPU cycles into sending mail, by obliging
people that send to many recipients to encrypt all e-mails... But I
guess computer power is cheap... However that is an idea worth
developing.

What I suggest is to esig mails to list to ensure traceability would be
spammers or people whose machine has been taken over.  As somoene noted
previously esig just ensure that the e-mail and private key met at some
place. It does not mean a user intervention.

I see however the signing of e-mail, to provide traceability, so people
can be located. Most SPAMMERS (legit or not) will think twice if they
know they can be prosecuted... Think about Caller ID for telephones...

Moreover somebody will set a site of bad digital signature, so your mail
system may reject all e-mails coming from these bad signatures...

----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: Ed Gerck <[email-masked]>
Date: Mon, 09 Feb 2004 19:47:19 -0800

Franck Martin wrote:

I see however the signing of e-mail,
to provide traceability, so people can be located.

I can locate all the fax spammers that fill my machine with garbage, I
can

call them and ask to be taken out of their lists, and they just keep
on morphing,

where my fax number goes like a ping-pong ball from spammer to spammer.

Is this the "solution" we want for email? Contrary to fax, I can't
disconnect

my email...

Most SPAMMERS (legit or not) will think
twice if they know they can be prosecuted... Think about Caller ID for
telephones...

Signing email <> Caller ID [1]. Signed email cannot prevent spam and
does not

burden spammers. It may be useful for listservs, however, such as this
one (see

my previous posting with a catch-all reply in this thread).

--------------------

[1]  A signed email with a valid (ie, authenticated by you) signature
provides message

and sender authentication as defined by a CA's CPS (which may not be
much -- see

usual warranty and suitability of purpose  disclaimers). Caller
ID provides terminal

authentication, irrespective of the message or actual sender (user).

---

From: John Kristoff <[email-masked]>
Date: Tue, 10 Feb 2004 06:59:48 -0600

On Mon, 09 Feb 2004 13:49:53 -0800

> 8. How about spammers using 100,000 slave PCs to share the burden?
[...]

Ed,

I'm not sure I see the value in requiring encryption.  To me this does
not seem to really fix anything.

On the one hand, this just forces spammers to  begin collecting public
keys and email addresses as opposed to just addresses.  With the former,
they probably end up with a much more reliable and stable form of contact
since people are not going to want to have throw-away keys, at least not
in the way PGP, for example, is currently used.

On the other hand, this just adds some, but not that much in my opinion
a processing burden for spammers to encrypt messages.  Processing that
can currently be found in compromised hosts (today) or in faster CPUs
(tomorrow).  I think the argument becomes slightly stronger if the delay
is an absolute value that can be enforced per TCP segment, connection
or whatever, but even that is not ideal.

Also note, there is an addition burden placed on end users who rely on
receiving encrypted email in your proposal.  Under your scheme, a user
has to go through the trouble of decrypting the message just to see if
it is spam or not.  This eliminates almost all forms of automated spam
mitigation except those related to the low-level SMTP, DNS or other new
authentication/authorization techniques.

John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 9 Feb 2004 07:36:15 -0800

Ed,

EG> Email privacy and spam are such general problems today that I'd 
EG> like to ask the ietf-org list for feedback (private if you wish)
EG> on this suggestion. There are more specific forums where this 
EG> can (and shall) be discussed.

Indeed there are.  That's why this thread should be moved to the IRTF's
ASRG venue <http://asrg.sp.am/>.

Your proposal is in line with some existing ones, at least one of which
response to the seriously problematic key management issue.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Dave Aronson <[email-masked]>
Date: Tue, 10 Feb 2004 10:20:58 -0500

On Mon February 9 2004 21:40, Ed Gerck wrote:

 > BTW, my previous posting provided a rationale for proposing the
 > following requirement for any current or future mail system:
 >

Unfortunately, requiring that they have a published public-key *is* a 
burden to the average user.  J. Random Luser just wants to sit down at 
his PC, boot up Winders, bring out Lookout, and forward a garish 
HTMLified email full of stale jokes to his buddies, complete with 
pictures, and he wants it to go through, without a hitch, right now.  
He thinks public keys are the ones hanging on the gas station wall, for 
the bathroom.  He thinks crypto is someone from Superman's home planet.  
He thinks the IETF is them guys whut raided David Koresh.  He has no 
clue what the ASRG is, but he thinks it sounds dirty.

Make it worth their while, by coming up with infrastructure such that 
they won't get any spam if they have a public key, and MAYBE they'll 
bother doing it, IF the ISP will hold their hands every step of the way 
(and not charge them too much, including for issuing new keypairs when 
they let the private ones slip out too much).  Of course, this means 
that all their equally technically-enlightened friends have to know how 
to USE his public key....

This sounds very much like the use of extra headerz, or a password on 
the subject line, but on steroids.  In the end, possibly useful, IF you 
can get everybody aboard, but they won't go until everybody ELSE is 
already on board, and meanwhile it's a pain in the proverbial posterior 
to everyone who wants to communicate with the people using it.

-- 
Dave Aronson, Senior Software Engineer, Secure Software Inc.
Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org
(Opinions above NOT those of securesw.com unless so stated!)
WE'RE HIRING developers, auditors, and VP of Prof. Services.

---

From: Dave Aronson <[email-masked]>
Date: Tue, 10 Feb 2004 10:50:00 -0500

On Mon February 9 2004 18:57, Dean Anderson wrote:

 > The IEMMC was formed in May of 1997 between Cyberpromotions and AGIS
 > and some others. Its goal was to encourage voluntary spam labeling
 > and opt-out lists, and to work out a compromise on spam between the
 > advertising and technical community.

...which must necessarily consist of something MUCH better than labeling 
and opt-out, but that was pretty much their limit.  Opt-out is a 
non-starter, so to speak.  It was pretty clear to me that the IEMMC was 
basically a PR ploy, to delay any real action.  IMNSHO, AGIS had no 
intention whatsoever of disconnecting, reining in, imposing conditions 
on, or in any other way not being a haven for spammers, so long as 
being a spamhaven was profitable.

 > One might say this is ancient history, but in fact, the IEMMC
 > position on spam was practically legislated in the CAN-SPAM act,

Yup.  Which means not that SPAM is in the CAN, but that spammers CAN 
SPAM.  They just have to do a few things that the anti-spammers have 
recognized as useless (if not worse) for well over ten years.

Long story short, CAN-SPAM is trying to pull the same wool over the 
public's eyes, that the IEMMC was trying to pull over the anti-spam 
community's.  Unfortunately, John Q. Public can't tell the fine worsted 
wool it's being sold as, from the cheap polyester it really is....

Disclaimer: this doesn't mean that hacking Cyberpromo was "right"!  I'm 
not one of your "radical abusers"....

---

From: Dean Anderson <[email-masked]>
Date: Tue, 10 Feb 2004 14:12:53 -0500 (EST)

> adding friction to email by creating a mandatory "fee" (burdenwise) to

Then using the IETF list as an example, you would need the entire list of
recipients and their public keys, and you would need to send a message
either directly to each of them, one by one, or send a single message with
a session key for each recipient (thousands).  This isn't going to work.

Second, even if the above weren't a problem, one still has the problem
that a virus infected user will still be sending messages, just like
everyone else. 

You can't make it more expensive without shooting yourself in the foot.  
In information theory-speak, you can't prevent a covert channel** unless
you have no channel at all.  Covert-channel detection is a whack-a-mole
game.  The whack-a-mole characteristic can't be avoided, except by having
no channel at all. Then your problem is to be sure that there really isn't
a channel.  But there often is a channel anyway, and it is just unknown.  
Intelligence agencies go to a great deal of expense to make sure there is
no channel through which information can be leaked.  Our problem is much,
much more difficult because we have a channel, but want to make sure it is
only used for certain purposes.

Putting it in different terms, how can the government make sure those
"government use only" stamped envelopes are only used for government
business?  'Government business' includes interacting with the general
public through mail or email, so eliminating the channel over which
non-government business might be conducted is not an option.  Is is
possible to make a stamp so that the envelope cannot be used for a
non-government purpose?  Now take it one step closer: How can they make
sure that government computers are only used for government business?  
Can a computer be built that can only be used for government business?

There is no scheme in which the rules can't be broken by someone intent on
breaking them.  The only path is to detect them, and prosecute them.  In
the case of spam, detection is easy, but not automatic.  Prosecution is
now possible.  Its still a whack-a-mole game. It won't end unless you can
get past the virus infection to the virus operator, and hopefully, there
aren't really too many virus operators.  Of course, we aren't stopping
spam either in a very real sense, but rather abusers who are annoying and
mailbombing people.  But by my count of my inbox, if you stop those
people, I can certainly handle the rest which amounts to maybe 1% of my
current junk mail.

> should not be a user's problem.

The "for pay" idea is just another scam from the people who would love to
get a percentage of the pay. While I'm sure Microsoft and others would
just love to get a cut of this (I know I would), it doesn't do anything to
stop spam, and if implemented, would simply (and wrongly) charge users
whose computers were virus infected.  I doubt that it would be widely
implmented, anyway.  It would also be the end of free services like
hotmail and yahoo, though I'm certain MS would give up hotmail in a hot
second for a cut of probably billions or trillions per year in email fees.
Though, perhaps one could bring a fraud or rackateering case against
Microsoft for profiting from its insecure computers, but I'm doubtful of
that.

		--Dean

** covert channel, sneaky channel, whatever your term--'covert channel' is
a term favored by OS scientists in analysis of Operating Systems--the
information theory part of it is generally applicable, and the concept has
been researched in different fields and applications using slightly
different names.

---

From: Dave Aronson <[email-masked]>
Date: Tue, 10 Feb 2004 14:32:57 -0500

On Tue February 10 2004 14:12, Dean Anderson wrote:

 > The "for pay" idea is just another scam from the people who would
 > love to get a percentage of the pay. While I'm sure Microsoft and
 > others would just love to get a cut of this (I know I would), it
 > doesn't do anything to stop spam, and if implemented, would simply
 > (and wrongly) charge users whose computers were virus infected.

Wrongly?  I'm not so sure.  Something ought to be done to stop the 
Typhoid Marys of the Internet.  Putting them on notice that they WILL 
be held responsible for spreading the infection, or its effects, just 
MIGHT result in them FINALLY taking some responsibility for their 
"computer hygiene".  Sure, there will have to be several well 
publicized example cases before most folk will sit up and take notice, 
but in the long run, it might be effective.

Not that it would be worth all the assorted other hassles associated 
with the protocol changes, collecting and disbursing the money (with a 
cut off the top for the collectors/disbursers, of course), etc.  B-(

---

From: "Robert G. Brown" <[email-masked]>
Date: Tue, 10 Feb 2004 14:48:27 -0500 (EST)

> now possible.  Its still a whack-a-mole game. It won't end unless you can

Hear, hear.  Beautifully said (and I'll have to remember the
whack-a-mole metaphor;-).  There are also lovely biological metaphors --
how long has it taken spamsters to develop "stealth spam" that sneaks
past the rulesets of many filters, often by exploiting very specific
features of those filters such as word count mechanisms?  Viruses (close
kin to spam) are constantly reengineered with better and badder social
engineering, with variable signatures.  Just like real viruses and
pond-scum bacteria, they are changed to be successful in the environment
they operate in as that environment changes to try to eliminate them.
And don't forget, a fraction (possibly large) of spam originates
overseas in countries where they laugh hysterically at the concept of
regulation and prosecution will effectively never work.

So even discussing adding a silly thing like mandatory esigs and
encryption as an antispam measure is a waste of time, except possibly on
a local basis.  If I set up a small mailing list (or generalized group
of individuals) and all of its members agree to do this, there is little
"evolutionary pressure" for spammers to detect and foil our scheme and
we will be "immune" (at the cost of a fair amount of extra work).  If
everybody does it and the automated tools for doing it without so much
work are widely disbursed, they will develop countermeasures in no time
at all and we'll lose our immunity.

It also isn't clear that this is an IETF issue (although I'm fairly new
on the list and could be mistaken:-).  Trying to establish a new mail
standard such that all mail is encrypted in transit -- that seems like a
reasonable issue, spammers or not.  Trying to use its influence to
communicate to e.g. AV companies that bouncing messages to the apparent
source of a virus has long since become counterproductive, that also
seems like a reasonable issue -- both are technical/engineering issues
that affect the quality of service of the internet itself.

The spam problem, like the phone problem, seems more likely to be
resolved by strong legislation and vigorous prosecution.  It is less a
technical problem than a social one and an economic one.

   rgb

---

From: Ed Gerck <[email-masked]>
Date: Thu, 12 Feb 2004 16:46:05 -0800

> a session key for each recipient (thousands).  This isn't going to work.

Let's not mix apples with speedboats. These are some options with the 
proposal:

#1: no encryption is used either way, the list address is in a whitelist 
for each recipient.

#2: each recipient can only send encrypted msgs (possibly, also
signed) to the list, with the list's key, for distribution. The listserver 
verifies and resends the messages in plain text, where #1 applies for 
each recipient.

#3: the list receives messages as in #2 but the listserver sends the
msgs as encrypted mail to each recipient, with each recipient's key.

IETF.ORG, possibly, should be #1.  No problem in using postcards
here. However, to help prevent spam, IETF.ORG can use #2.
 
> that a virus infected user will still be sending messages, just like

Again, his would not work well with the proposal, due to the encryption 
being per message. And the hijacked user would tend to notice any heavy 
usage.

> you have no channel at all.  

By the addition of a correction channel (Shannon's 10th theorem),
a covert channel can be detected with a probability as close to 100%
as I wish.

> Covert-channel detection is a whack-a-mole game. 

Not really. It can be modeled, it can be improved.

> business? 

Easy. By applying Shannon's 10th theorem. Sample enough mail at
distribution centers (going back to the source, which is possible
even without a legal mandate to open the  envelopes) and bar the 
culprits from sending govt. mail until the probability that any 
mail is incorrectly using govt. envelopes is a close to zero as desired.

> breaking them. 

This may sound good but is incorrect. Systems can be designed
such that a set of properties remain effective if most or even 
all parts of the system fail (for whatever reason, including
attacks).

> The only path is to detect them, and prosecute them.  

There is no world law, no unified way to prosecute. Even
venue is hard to guarantee (allowing you to  prosecute
the culprit).

> In

When you outlaw spam, only the outlaws spam. So what? The
problem still remains, even if you call them outlaws. Also,
users should not have to sue spammers, or have any other burden,
in order to protect the users' resources. Imagine if I would 
have to manage 300 lawsuits a day (the average spam rate that
my system cannot automatically detect as spam)?

---

From: Franck Martin <[email-masked]>
Date: 13 Feb 2004 14:47:59 +1200

> msgs as encrypted mail to each recipient, with each recipient's key.

#4 (my preferred) the member send a message to the list with his digital
signature. The list checks the digital signature (from keyserver or from
a member database) and post the message if signature is valid. If the
signature is not valid, the message is held for approval.

But yes this scheme does not offer much more than restrict posting to
list members only, which the IETF had to do last year(?).

May be it would provide an avenue to not restrict posting to members
only if a posting is correctly digitally signed...

Yes a user could send digitally signed viruses without his/her
knowledge. Hopefully software that applies digitally signature to
e-mails do not do it blindly without repetitive manual user intervention
(after idle time, you must re-enter your key password). Or a mail cannot
be sent via a script without entering the key password.

> my system cannot automatically detect as spam)?

You can contribute to a pool of reports, like spamcop does or other
systems based on a message signature count. When a threshold is reached,
you know something suspicious is happening. You can then collect the
reports, bundle them and sue on behalf of the users, that's what public
prosecutors do sometime. They do not necessarily need a complaint...

----
Franck Martin
[email-masked]
SOPAC, Fiji

---

From: Dean Anderson <[email-masked]>
Date: Fri, 13 Feb 2004 17:59:39 -0500 (EST)

> a covert channel can be detected with a probability as close to 100%

Err, I think that allows you to correct _errors_ in transmission. It does
not enable detection or prevention of a covert or sneaky channel. While
there have been examples of sneaky channels that used intentional errors
in a channel as the sneaky channel, error correction does not prevent or
detect the covert channel, unless of course, the errors are corrected
before they can be seen by the user of the sneaky channel. Otherwise, you
do not know if the errors are intentional and carry information, or
whether they are just errors. 

What's that?  You say that one could study the errors, and if the bits are
not random, perhaps you have detected a covert channel.  A good encryption
mechanism will assure a random distribution of bits, and so you would be
unable to distinguish from just random errors.  There are other means of
creating covert channels besides introducing errors.

> Not really. It can be modeled, it can be improved.

I agree that it can be modeled, and that we can learn things by the
effort. I've seen some interesting reading on modeling the bandwidth
potentially available to a covert channel.  This doesn't prevent the
existance of a covert channel, nor does it change the whack-a-mole nature
of the problem.  You still have to detect and respond.

But knowing the potential bandwidth in some situations might help you to
harrass the bad guys. Or focus your detection efforts, since the bandwidth
available may put constraints on the bad guys, and knowing those
constraints may yeild some insights.  In this case, I think the bandwidth 
available to a large number of virus-infected computers is quite 
substantial, as is the compute power.

> mail is incorrectly using govt. envelopes is a close to zero as desired.

Unfortunately, you described a detection mechanism:  Whack-a-mole.  
Indeed, I think this is exactly what the government does to detect abuse.  
And it is basically the same thing we do now for email by applying text
analysis.

But we are looking for (and you promised) a mechanism which makes it
impossible for them send it in the first place:  No more whack-a-mole.

Clearly, in the sampling example, they can use invisible ink to fool the
censors, or write their messages in an ordinary looking code that looks
like official business (steganography).  The error correction theroem
doesn't help.  This example isn't nearly as hypothetical as it sounds. The
US [and other governments] really used to open international mail to look
for secret messages. We used to also test letters for the presence of a
number of invisible inks. The Germans invented an invisible ink that was
inpervious to testing for a long time.  The US censors would even re-write
personal letters using slightly different words to preclude the use of
special code words.  Then came micro-dots and so forth.  Each channel
detected led to the creation of new channels (either different people,
same method, or new methods) within the postal mail system.  But it did
not lead to any situation in which sneaky channels were impossible.

> all parts of the system fail (for whatever reason, including

Fault tolerance doesn't seem to be helpful.  To design a system that can't
send spam, you have to first identify the properties of spam in such a way
that a person dedicated to breaking the rules would be prevented from
sending spam.  Information theory tells us that such a goal is impossible
to obtain when it tells us that a covert channel can't be proven not to
exist.

> venue is hard to guarantee (allowing you to  prosecute

This isn't quite true.

> > In the case of spam, detection is easy, but not automatic.  
> > Prosecution is now possible.  Its still a whack-a-mole game. It won't
> > end unless you can get past the virus infection to the virus operator,
> > and hopefully, there aren't really too many virus operators.  Of
> > course, we aren't stopping spam either in a very real sense, but
> > rather abusers who are annoying and mailbombing people.  But by my
> > count of my inbox, if you stop those people, I can certainly handle
> > the rest which amounts to maybe 1% of my current junk mail.
> 
> problem still remains, even if you call them outlaws. 

Actually, genuine spam is not outlawed. Only the spam sent by people who 
are not genuine businesses is outlawed. I expect that this abuse is sent 
by a very small group of people.  Prosecuting this small group should be 
relatively easy.

> Also, users should not have to sue spammers, or have any other burden,
> in order to protect the users' resources. Imagine if I would have to
> manage 300 lawsuits a day (the average spam rate that my system cannot
> automatically detect as spam)?

This is an exaggeration. There aren't 300 unique spammers per internet
user per day.

		--Dean

---

From: Ed Gerck <[email-masked]>
Date: Fri, 13 Feb 2004 18:02:13 -0800

Dean Anderson wrote:
> Err, I think that allows you to correct _errors_ in transmission. 

Shannon distinguished messages --or intended information-- from noise. 
The distinction beween noise and information is that information is
what the sender wants to send or, alternatively, what the receiver
wants to receive. If the channel is a covert channel, it is fair to
assume that either the sender or the receiver (or both) do not intend
it to exist (otherwise, it would not be a covert channel). Thus, a 
covert channel transmits information that can be considered for modeling purposes as a source of noise. Since the 10th theorem applies to any 
source of noise, it also applies here. 

The devil are in the details, though. The 10th theorem does not
tell you how to do it -- just that it is possible and that the
noise (covert channel information) can be detected with a probability
as close to 100% as desired.

> Unfortunately, you described a detection mechanism:  Whack-a-mole.

Actually, I described a detection AND a correction mechanism. The 
correction mechanism uses a correction channel as given by the 10th
theorem. BTW, just sampling 1% of mail might be enough to prevent 
misuse to almost 100% confidence.

> impossible for them send it in the first place:  No more whack-a-mole.

The "impossible" promised by Shannon's 10th theorem is "probability
as close to zero as you wish". That's what I also promised and 
delivered. It should be good enough for you ;-)
 
> like official business (steganography).  

Either can be detected, and corrected. If you are following the whole
DRM and music copyright issue, you have many examples why steganography
is at most a deterrent, not a secure technique.

> This example isn't nearly as hypothetical as it sounds. The

Your examples actually show how a correction channel can work. Your 
argument that a sneaky channel is still possible is also included in
Shannon's 10th theorem -- the correction channel needs to have a larger
capacity than the noise channel. If you have an unaccounted-for 
noise channel (e.g., a covert channel), your system is still not good
enough.

> send spam, 

This is not our goal -- the problem is at the receiving end, since the 
sending end can use anything (even non-conformant systems). The issue 
in the proposal is to design a system where *receiving* spamm can
be made as hard as the recipient wants.

> you have to first identify the properties of spam in such a way

When the recipient detects a spam message, the existence of at least one
covert channel is exposed. As I envision the proposal, the recipient should
be in control of how to react -- since different users will have different
goals. For example, according the number of spam messages received, the 
recipient can be more or less demanding on the sender of ANY message for 
senders without a previous relationship. Thus, the sender can be reduce the 
covert channel's capacity as much as the recipient wants.
 
> Actually, genuine spam is not outlawed. 

It depends how you define spam. Genuine "spammers" would quibble
with you calling them spammers. I'd call them email senders.

> Only the spam sent by people who
> are not genuine businesses is outlawed. 

Not true. If a genuine business continues to send me messages
after I unsub, it is spam. The classification of spam is not
based on who sends the message. 

> I expect that this abuse is sent

It has not been and it will only get worse.

> This is an exaggeration. There aren't 300 unique spammers per internet

Agreed  -- it's an understatement. I believe there are perhaps
1000x 300 unique spammers per day. Some I don't hear from (they're
local -- for example -- for Korean readers), some are in burst mode
and I only hear them once in a while, some morph under different
names and hosts, some I blacklist, some I detect and some I drop.

---

From: Dean Anderson <[email-masked]>
Date: Sat, 14 Feb 2004 01:01:42 -0500 (EST)

This should be particularly interesting for John Klensin, as it is really
a follow-on to discussion last summer on the topic of information theory
and spam.

On Fri, 13 Feb 2004, Ed Gerck wrote:

> The distinction beween noise and information is that information is what
> the sender wants to send or, alternatively, what the receiver wants to
> receive. If the channel is a covert channel, it is fair to assume that
> either the sender or the receiver (or both) do not intend it to exist
> (otherwise, it would not be a covert channel). Thus, a covert channel
> transmits information that can be considered for modeling purposes as a
> source of noise. Since the 10th theorem applies to any source of noise,
> it also applies here.

You are confusing a covert channel with noise. They aren't the same.  
Antispammers have commonly used an analogy that equates spam with noise
and anti-spam efforts as trying to find a "noise filter".  The analogy
sounds good, but is not accurate, which might suggest a reason why they
have failed to find a "filter".

Spam isn't unwanted until after the fact: You read it, and then you don't
like it.  Some people think AC/DC (or rock music in general) is "noise",
or commercials are "noise", but they aren't noise from the point of view
of information theory, and your real or theoretical radio won't be able
automatically filter them out when the DJ plays them, though it will do a
good job of filtering out noise.

You have to hear/read/see it, decide you don't like it, and complain about
it.  But you can't build a stereo that won't play rock music or won't play
commercials.  Perhaps, like the Janet Jackson Breast Baring (JJBB), the
station operator will agree with your complaint, and a fuss will be made
that won't cost you anthing, except taxes.  Spam is essentially the same
problem as preventing people from exposing themselves on TV. In a sense,
the problem is similar to NP-Complete problems because there are a whole
class of problems that are basically the same, and if you could solve one,
you could solve them all.

Getting back to information theory, Spam is information that the system
operator doesn't intend to be sent. It breaks the rules which say not to
send this kind of information. Spam (per the definition of a covert
channel) is simply a "communication not authorized by the security model".  
I should probably explain that spam is a multiplexed channel and identify
all the necessary parts relevant to information theory, but I think that
is fairly obvious, and unnecessary unless you dispute that spam is a
channel per the definitions of information theory. People have challenged
this, but infrequently. It seems you don't, so I'll skip it.

The definition of "covert channel" and the applicability of information
theory to spam was discussed on another (osf_alums) list last fall, and
some "very smart people" had some things to say about the definition of
covert channels in particular, which as I mentioned previously is a term
specificly used by OS scientists.  Some people thought it inappropriate to
use the term "covert channel" outside the context of operating system
analysis.  There are other terms used in other types of research, but they
all are rooted in information theory, and have the same very general
implications as a result:

On Fri, 8 Aug 2003, Ellis Cohen wrote:

> My 1976 paper on Strong Dependency (abridged in SOSP 5 in 1977) was (as
> far as I know) the first paper that applied classical information theory
> to problems of computer security (see
> http://citeseer.nj.nec.com/context/114449/0) and it contains the term
> "covert information path" (but I can't find "covert channel" used).  I
> might possibly even have been the first to use "covert" in the context
> of computer security, but I don't think so.  It's even possible I heard
> Lampson use it (or maybe it was the other way around ...)
> 
> Leo Rotenberg's excellent MIT thesis, "Making Computers Keep Secrets"
> was published  in Feb 1974.  He talks about "information leakage",   
> "sneaky signalling", "hidden data flows", and talks specifically about
> how communication channels (in particular, accounting channels -- that
> is, commuication channels used for billing) can be used to spy on data,
> but I can't find the word "covert" used anywhere.
>
> So it's possible that Lampson coined "covert channel" in 1978, but I
> suspect he might have used it earlier in his paper "A Note On the   
> Confinerment Problem" published in the CACM in 1973.
> 
> Citations seem to indicate that Lampson's deifnition of a covert channel
> was a channel "not intended for information transfer".  And I beleve I  
> remember that covert channels were used at that time to cover cases in  
> which there was no cooperation.  For example, suppose a spy can observe 
> the CPU usage of all programs on a computer which contains a top secret 
> program which is only run when an important secret event occurs.  Even  
> though there is no cooperation (just sloppy security), a covert channel 
> (access to the CPU usages) provides theinformation about when an
> important secret event occurs.
> 
>   -- Ellis Cohen

On Fri, 8 Aug 2003, Stavros Macrakis wrote:

> "Covert channel" has more than one definition.  In Lampson's original
> article, it referred to channels not intended for information transfer
> at all, and thus did NOT include information leaks via the billing
> system or via steganography.  If I read the NCSC's definition (below)
> correctly, it refers to ANY communication not authorized by the security
> model (which seems overly broad to me, but...).
>
> > I suspect [Lampson] might have used it earlier in his paper
> > "A Note On the Confinerment Problem" published in the CACM in 1973.
>
> A Note on the Confinement Problem
> Butler W. Lampson
> Xerox Palo Alto Research Center
> Comm. ACM 16, 10 (Oct. 1973)
>
> http://citeseer.nj.nec.com/lampson73note.html
>
> Even when all unauthorized access has been prevented,... [a service] may
> leak, i.e. transmit to its owner the input data which the customer gives
> it.
> ...
> The channels [in his examples] fall into three categories:
>
> * Storage of various kinds maintained by the supervisor which can be
> written by the service and read by an unconfined program, either shortly
> after it is written or at some later time.
>
> * Legitimate channels used by the confined service, such as the bill.
>
> * Covert channels, i.e. those not intended for information transfer at
> all, such as the service program's effect on the system load.
>
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
> NATIONAL COMPUTER SECURITY CENTER
> A GUIDE TO UNDERSTANDING COVERT CHANNEL ANALYSIS OF TRUSTED SYSTEMS
> November 1993
> http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-030.html

The only solution so far is "detect and correct". Which, as noted, isn't a
very good solution, and we desire a solution that didn't have this
characteristic.

> misuse to almost 100% confidence.

It is still a "whack-a-mole" or "detect and correct" problem. It is not
impossible for someone to conduct abuse.  What sampling level you need to
have to assure a certain degree of compliance depends greatly on the
deterrence of the correction method. 

> based on who sends the message. 

This is a quibble, or you haven't read the CAN-SPAM act.

> It has not been and it will only get worse.

Until last month, there were no tools to prosecute them, except for virus 
infection. And that isn't taken seriously unless there is fear that the 
virus caused a major power failure. But in that case, the virus sender is 
caught quickly and painlessly.

> 1000x 300 unique spammers per day. 

300,000 unique spammers each day, and only 6 billion people in the world.  
Gee only 20000 days until every one on the planet is a spammer. Yet
everyone on the planet doesn't even have email, telephone, or even TV. I
wonder if there will be anyone without these things in 50 years.  I heard
not too long ago that there are _only_ around 100 million on the net.  
Maybe its now up to 200 or 300 million.  So in 3 years, everyone that's on
the net will be a spammer.  Gee.  Maybe we better get moving on the IPv6.  
;-)

---

From: Ed Gerck <[email-masked]>
Date: Sat, 14 Feb 2004 11:45:37 -0800

> You are confusing a covert channel with noise. They aren't the same.

Of course they aren't -- how could a channel be equal to noise, anyway?

What I said is that the *information* transferred by a covert channel, 
whatever that information might be, is NOT the message (the intended 
information).  Thus, for modeling purposes in terms of Shannon's
information theory, the choice is clear. The *information* transferred 
by a covert channel is noise (the only other possible option).

> have failed to find a "filter".

If you are proposing a different model, fine. There are always many models
that can describe something. However, in the message model used by Shannon, 
there is a clear distinction between messages (or intended information) 
and noise (anything else) that also applies here. In the case of spam,
my mailbox has messages (intended communications) and spam (noise).

Also, note that noise does not have to disrupt communications! Noise is 
simply that which is not the message.

BTW, I often find people who try to say that spam is not noise --
because it can be useful, as advertising. Surely, in terms of a
communication process, you can consider whatever you want as
the *intended message* (i.e., not noise). You can certainly
say that spam is a message that the sender (the spammer) intended
to send. However, from the receiver's viewpoint, spam is usually
considered to be noise and IMO rightly so. 

> like it.  

I strongly disagree -- I don't read spam and I don't even try to 
read the unsubscribe information in it. I try the best I can to detect 
it and delete it as early as possible. If possible, even before it is 
queued in my mail box and causes me further problems (and costs). I 
believe that's also what the majority of email users would like to 
do -- or, do you really think we all have the time to read spam and 
decide after the fact that it is indeed spam? That's why the proposal 
for anti-spam burden does provide a mandatory pre-delivery burden that
can be increased as much as the *recipient* wants. Users should not be 
burdened with reading and sorting out spam -- regardless how the
senders want to classify it!

---

From: Dean Anderson <[email-masked]>
Date: Sun, 15 Feb 2004 14:22:59 -0500 (EST)

On Sat, 14 Feb 2004, Ed Gerck wrote:

> information).  

So, the spammer didn't intend to send you a message about Viagra??  That
somehow "noise" caused the message to be altered to be about Viagra?? I
don't think so.

> Thus, for modeling purposes in terms of Shannon's

Not only isn't it 'the only possible option', but the information carried
by a covert channel is not noise.  The sender sent information and the
receiver recieved the information. It isn't the case that the spammer
intended to send a message about the superbowl, but somehow "noise"
altered the message to a solicitation on viagra. Rather, they intended to
send a message on viagra, and you recieved their message, noise free.  
But seeing the solication for viagra, you became upset, and reported a
complaint about the inappropriate use of the channel. In
information-theory-speak, you report a "communication in violation of the
security model"; a covert or sneaky channel.

A note of caution: The intent of the senders and receivers is irrelevant
to information theory channels.  Covert channels can exist with or without
intent, and with or without cooperation. Information theory is concerned
with the movement of information through a transmitter to a reciever. The
intent or cooperation in that transfer is irrelevent, except that a
channel used for information not intended for transmission is called
covert or sneaky.

For example, when a remote SSL attacker uses timing information to obtain
the secret key of the server, the server isn't cooperating, nor does it
intend to provide the secret key.  Information theory looks at the actual
value of the key, and whether that was transmitted to the reciever with or
without noise. In the case of the SSL timing attack, there is a lot of
noise, but information theory tells us, and practice confirms, that the
noise can be corrected, until the key is successfully transmitted to the
receiver error free.

In the case of spam though, we safely assume the intent of sender to get a
spam message to the recipient, and can couch our descriptions accordingly,
but we need to exercise some caution.  With regard to noise, what we are
really be concerned with is the message before it is transmitted, and the
message after it is received.  In our case, the transmission is usually
noise free thanks to the function of TCP.

> If you are proposing a different model, fine. 

I'm not proposing a different model. The model of "spam is noise" that you
are using is inaccurate and wrong. I'm explaining the correct way to model
spam in information theory.  This will help explain why many anti-spam
proposals are unworkable, and why previous attempts have failed.

> queued in my mail box and causes me further problems (and costs). 

You don't _want_ to read it. You don't _want_ to spend time reading it.
It's the fact that one doesn't have time to read all the junk that many
people find annoying about spam, as well as objectionable content.  But
those who don't have email aren't annoyed by spam.  You have to receive
spam to be annoyed by it and not want it.

> I believe that's also what the majority of email users would like to do
> -- or, do you really think we all have the time to read spam and decide
> after the fact that it is indeed spam?

What users want is constrained by what's possible. I want
faster-than-light travel for free.  Many people want that, which explains
its popularity in science fiction.  But we are constrained by physics and
technology.  Quite obviously, in the case of spam we are trying to find
ways so that we don't have to read/sort/delete spam, or spend less time
doing so. You have promised that your scheme will eliminate the
whack-a-mole nature of spam. I'm saying that it is impossible to eliminate
this charactistic from spam, based on what we know from information theory
about covert or sneaky channels.  This tells us that your scheme cannot
deliver what you have promised. 

The prevalence of anti-spam schemes that claim to make spam just disappear
are much like the perpetual motion machines proposed at the turn of the
last century.  Eventually, we started to use thermodynamics to analyze
these schemes before they were built. When we see perpertual motion, we
dismiss the idea as a "perpetual motion scheme". We do not need to
prototype perpetual motion schemes to know they won't work.  Likewise, we
do not need to prototype communication systems that claim to be free of
covert channels to know that they won't be free of covert channels.  
Information theory tells us that one can never be free of covert channels.

> That's why the proposal for anti-spam burden does provide a mandatory
> pre-delivery burden that can be increased as much as the *recipient*
> wants. Users should not be burdened with reading and sorting out spam --
> regardless how the senders want to classify it!

I think you also need to consider the causality constraints on a
"Pre-delivery burden that can be increased as much as the *recipient*
wants".  You cannot make an uneven playing field for the spammer. You can
increase the pre-delivery burden on everyone. Yet the spammer using
virus-stolen computer and bandwidth resources won't care.  You can't
change the pre-delivery burden after you receive the spam because of
causality.

		--Dean

---

From: "Robert G. Brown" <[email-masked]>
Date: Sun, 15 Feb 2004 15:12:22 -0500 (EST)

> by a covert channel is not noise.  The sender sent information and the

Once again, what Dean is saying is dead on correct.  Information theory
deals with corruption of bits, with the degradation of "ordered"
information.  In physics, entropy is the log of the missing information,
where information has a very precise meaning, and with this definition
much of statistical mechanics can be more or less derived from Shannon's
theorem and a proper analysis of conditional probabilities.

An alternative view of SPAM where it isn't a "covert channel" (which
sounds a bit too much like spy thriller stuff, although I understand
perfectly well what is meant) but rather considers it merely to be an
undesireable communication clarifies things a great deal.  What is
undesirable is clearly a matter of opinion and requires the solution of
a serious (largely unsolved) problem in predictive modeling or
artificial intelligence in order to mechanically filter.

I'd like to make a suggestion.  There are several parts of this
discussion that are quite distinct, and by mixing them (often out of
context) the discussion is being perpetuated well beyond sane
boundaries.

First of all, there is the issue of whether or not email should
routinely and USER TRANSPARENTLY be encrypted, at least during the
transit phase between MTA's.  This really deserves an entirely separate
discussion, as I think one might well build up a consensus that ALL
network traffic should be routinely encrypted at this point and that
email in general is a glaring legacy exception in a world where SSL and
ssh have largely dealt with encrypting the rest, at least where it most
matters.  This, in my opinion, is very much an IETF issue as it would
require the development of an open protocol and the supported
engineering of retrofitting MTA's everywhere to use it.  This in turn
may well hinge on broader issues of host registration and
authentication.

After all, most users of web browsers and ssh are not deeply aware of
the key manipulations that take place in order to secure those channels
EXCEPT when they are being attacked and threaten to fail.  Surely
something could be done with mail as well.

Second, there is the issue of whether adding a "cost" to email would
deter spam.  I note that no one (Ed in particular) has yet attempted to
rebut by assertion that doing the actual arithmetic it is clear that
individuals emailing SPAM in excess of the legal limits triggered by
e.g. the new Virginia anti-SPAM law (10K pieces a day, 100K per month)
could care less if the COMPUTATIONAL cost per message were 8 whole
seconds per mailing, so delays up to that level are irrelevant.  8
seconds is some 20 to 30 billion instructions on a modern CPU, and
nothing restricts spammers to using just one.  I think that it is
absolutely clear that adding an encryption step as a "cost" to deter
spammers is simply ridiculous as it will do no such thing.

Adding a "cost" to an email message to all users (instituting
per-message costs onto the internet backbone) is a cure so much worse
than the disease that I, for one, will vehemently oppose it, as will
nearly all old Internet hands.  That way madness lies.  And in any
event, per message costs will simply shift the cost plateau around and
make sending spam legitimate business with more than a handful of
individuals making a profit from it.  The moment spam is viewed the way
TV advertisements are, as a perfectly reasonable adjunct to a medium, we
are all doomed.

I am by no means convinced that spam control is in any way the business
of the IETF.  If it is, it must be at the detailed engineering level,
and the discussion is very, very far away from that so far (where people
are routinely making statements like "implementing this will result in
that" without any sort of quantitative analysis or basis.  Engineering
is about numbers, not just "ideas".  At the very least, ideas supported
by actual numbers.

In fact, before making ANY sort of proposal concerning spam, it would
behoove the primary participants to study and use themselves on an
active basis a wide range of the existing anti-spam tools.  Second, in
at least the open source world where a lot of similar crack discussion
can easily occur, the rule is "build a prototype and demonstrate it
before you waste three months of discussion on whether or not it will
work".  I'd say that this too is entirely appropriate.

In this case, BUILD your proposed anti-spam measures into a whole chain
of open source tools.  Mailman, for example, which already has a lot of
anti-spam stuff in it.  Add a db field for keys, hook together all the
logic for their automated implementation so that mailman-based mailing
lists can use keys for all members.  See if anyone buys it, likes it,
uses it.  See where and why it fails.

THIS is the appropriate path of engineering -- prototyping and
real-world trials.  Then we don't have to argue about how much work it
would be or if it would work, and that way we ALSO don't have to publish
a "bare standard" with no actual implementations and expect everybody
ELSE to invest all the work and energy in implementing it without even a
working prototype to test against.

    rgb

---

From: Ed Gerck <[email-masked]>
Date: Sun, 15 Feb 2004 17:45:56 -0800

Dean Anderson wrote:
> 
>It isn't the case that the spammer

I guess we agree that if the message can be read by the intended recipient 
then it's not in a covert channel. A covert channel is one that can't even 
be detected by the intended recipient. But, you may ask, "who" is the 
intended recipient? 

In anti-spam email systems, we can usually recognize three "whos":

#1: My MTA
#2: My MUA
#3: Myself

The spammer's strategy is to send the spam message in such a  way
that it is undetectable by my MTA-MUA, while it is detectable and 
readable by me. In short, it needs to use a covert channel through my 
MTA-MUA, but not to me.

An example of such a covert channel is if a spammer hides information 
in the subject line by using wrongly spelled forms of "viagra", 
information which my MTA-MUA cannot detect. It's not a covert channel 
for me but it is for my defenses. But, once that message passes 
through to me, it becomes detectable, readable and I call it spam.

Does this mean that spam is defined by the rule

	"I (only) Know It When I See It!" 

and we have to accept a large failure rate in preventing spam, that 
can only be solved by laws and law enforcement? 

I want to emphasize that it does not have to be. Suppose a user can make
email senders pay a burden at their MTA or even at their MUA (e.g., a 
bounce requesting encryption and solution to a puzzle). In addition, using a 
selective scale defined by the user (so that selected mail senders have 
less burden) at their MTA and MUA, the user can make the spammer pay a 
price *as high as desired* by the user (not limited by R. Brown's comments).
In such case, the covert channel cannot even be established unless
the spammer pays a price -- a price that can be *as high as desired* by 
the *user*. This is the essence of the proposal (the devil is in details).

I take the example of the front door of your house. If you leave it open, 
so that a thief has no burden getting in, a thief probably will steal 
something from you -- even though the law says that theft is illegal.
What we need is to put a lock into our email communications door. A lock
that can be as hard to pick as the user wants, and yet easy to use
as the user wants it to be used.

Spammers are thiefs -- they steal time and resources, they make us
reject legitimate email. They cost a lot of  money to all of us. 
They have not been and will not be deterred by law alone. There
is also no "world law" and spammers are often hidding behind
legitimate users that change all the time. We can't lock the
spammers' doors everywhere, we have to lock our door at our house. 

BTW, to propose something simple, "running code" helps before any 
discussion.  In a system as complex as email, however, one would 
have to be naive to even think about "running code" before "running 
comments." I thank you all for the public discussion on this topic, 
through which I have learned a great deal, including people's first
barriers to change.

---

From: Ed Gerck <[email-masked]>
Date: Sun, 15 Feb 2004 17:47:32 -0800

---

From: Ed Gerck <[email-masked]>
Date: Sun, 15 Feb 2004 18:11:41 -0800

[resending due to formatting error in previous msg]

#1: My MTA
#2: My MUA
#3: Myself

---

From: "Robert G. Brown" <[email-masked]>
Date: Sun, 15 Feb 2004 23:30:25 -0500 (EST)

> as the user wants it to be used.

No, this is an incorrect analogy.  You want to put a lock on your
mailbox.  If you put a lock on your mailbox, you might as well not have
one.  The postman will no longer be able to deliver mail.

And the notion that there will be more than one "class" of mail so that
people will be able to send you "postcards" but not "real mail" is
spurious.  Unless you go through your postcard-class mail, you won't
know if there is anything important in there.  If you go through your
postcard class mail, you have to visually filter and reject all of the
spam and other unwanted mail that might be in it.

I have this problem now as it is.  I use spam assassin and set the spam
level pretty high -- 5 -- and bounce all of the rejects into a file
where I COULD check it.  However, I get roughly 5 MB/week in this file
so I don't, as a rule.

Because I set it so high, VERY FEW legitimate messages are lost, but a
fair bit of spam gets through, including various classes of stealth spam
with vi@gra lines (note that just using this line in this email will
guarantee its unviewed rejection by certain silly clients with much
LOWER spam thresholds, set so that they dump a lot of real mail along
with the spam).  This is a personal choice -- the lower the threshold
the more I reject and the greater the chance that real messages will be
rejected along with the spam.  If I have to review the rejected spam I
lose -- I might as well not reject at all.  If I lose an important
message I also lose.

THIS IS NOT A MATTER OF PROTOCOL!  This is not the business of the IETF!
Tools exist to help you filter spam.  Some, like spam assassin, are very
good and quite sophisticated.  However, there is ALWAYS a tradeoff with
using this sort of tool -- too narrow a criterion for acceptance and you
lose real mail, too broad and you get all the spam anyway.  I can choose
my level of tradeoff, and be fully aware of the risks.

> spammers' doors everywhere, we have to lock our door at our house. 

No, what we can do is the same thing we do with our real mail box.  Make
it illegal to send certain classes of mail, for example letter bombs and
envelopes containing anthrax, and prosecute the hell out of anybody we
catch who does so.  We cannot arrange it so that whoever sends us mail
that for any reason we don't want to accept has to "solve a puzzle of
indeterminate difficulty" in order to send it to us.

And no, I don't WANT to "solve a puzzle" (I presume, a human level
puzzle) in order to send somebody email.  I WON'T solve a puzzle to send
somebody email -- anybody that silly will just not get email from me.
I've already pointed out that any extra step involving e.g. encryption
or a machine solveable puzzle is trivially manageable and trivially
automateable at effectively zero cost to any spammer and backed it up
with numbers -- cycles are available by the billion (literally) --
millions of cycles can be burned PER LETTER of the message and it's no
skin off a spammer's bottom line.

I reiterate -- most of what you propose is possible now.  If you want to
send only encrypted mail, you can.  If you insist on signing all mail,
you can.  If you want to only accept signed, encrypted mail, you can.
What you can't do is make everybody else go to all of that effort for
no benefit that could even THEORETICALLY ensue.  If you make it easy for
everybody to send signed, encrypted mail, you make it easy for spammers
to send signed, encrypted mail and you're back where you started.  If
you don't, then your cure is worse than the disease.

> through which I have learned a great deal, including people's first

This is true only if you want to LISTEN to what other people say.  What
is at issue here isn't my "barrier to change".  It is that this is (in
my opinion) a foolish idea.  I get just as irritated at spam as the next
person (more so, since as I noted I get some 5 MB a week that is
rejected by my filters of spam and identifiable viruses combined).
However, I also spend a fair bit of time explaining to users why it
isn't possible or wise to filter out all mail that might contain the
word "viagra" as if that alone is the basis for something being SPAM.

I also spend a fair bit of my time working with information theory,
statistical mechanics, predictive modeling, and networks.  AND I write a
lot of code, including code for networks and simulations.  AND I've been
doing systems administration and programming for a long time now.

There is the good old apocryphal saying: "The Internet perceives control
as damage and routes around it."

You are attempting to institute a new level of control over something
that has to be filtered and accepted/rejected at a very high level.  It
is NOT easy to identify spam automatically or there would be no problem,
would there?  procmail alone would suffice, with a few keywords.
Instead spam assassin, with a complex weighting system and key phrase
identification process STILL makes mistakes, in both directions, and one
can visibly identify spam that has "evolved" to get past its defenses.
SPAM is a DYNAMIC problem, not a static one.  Whatever barrier you raise
at the technical level (especially an effectively static one), it will
route around it OR act as a barrier to messages you want to receive, and
hence diminish the value of the network to you by making it even harder
to get your work done than it would have been if you were only dealing
with spam.

   rgb

---

From: John Leslie <[email-masked]>
Date: Mon, 16 Feb 2004 10:19:35 -0500

> my level of tradeoff, and be fully aware of the risks.

   While the parameters of individual spam-filtering _should_ not be
the business of IETF, there is a very real issue raised by filtering
_after_ the SMTP session:

   During the SMTP session, it is quite possible to give an error which
is likely to reach the right person; after the SMTP session, you have
to "trust" the various header fields -- which are routinely forged by
spammers.

   In fact, we are now facing a _second_ denial-of-service problem
(the first being spam itself clogging your mailbox): excessive bounce
messages automatically directed to mailboxes forged by spammers. And
this by its nature is a distributed-denial-of-service problem, even
harder to protect against.

   Spam-filtering _after_ the SMTP session _should_ be deprecated by
IETF, IMHO. While there is no question that any recipient has the
right to ignore any message, SMTP was intended to either deliver the
message or send back an error; and the loss of this feature reduces
the utility of e-mail.

--
John Leslie <[email-masked]>

---

From: "Robert G. Brown" <[email-masked]>
Date: Mon, 16 Feb 2004 11:03:32 -0500 (EST)

> harder to protect against.

I agree, and in fact pointed out that bounce messages from AV programs
are similar problem a week ago.  So perhaps the discussion should
separate into three different threads:

  a) Encryption and host authentication on the smtp channel.  This might
embrace open mail programs used as forwarding agents by both spammers
and viruses.

  b) What to do about bounces in general.  Bounce messages are
useful or even essential in many contexts, but they are a source of both
intentional and unintentional abuse in a world where headers are
routinely forged.

  c) Spam, what (if anything) to do about it at the IETF level.

It may be that good solutions to a) and b) may, together with some
support in the form of laws, suffice to greatly ameliorate both spam and
header-forged viruses by increasing the accountability of the enabling
networks.  Most of this traffic is ALREADY in violation of corporate
acceptable use agreements -- part of the problem is that many ISP's have
been very lax in enforcing acceptable use and tracking down violators.
Part of THAT problem is that the networks selling access to the ISP's
have in turn turned a blind eye to the ISP's.

Perhaps a header-level/protocol-level solution would be a generalization
of the postmaster address that points to a HUMAN responsible for
policing the network(s) where spam/viruses originate.  Yes, one could
argue that postmaster already is such an address, but many of the
smaller originating networks are run by amateurs and have no real
postmaster.  One really needs to be able to hit a recursive list of
postmasters along the message's delivery route with warnings about
violations of acceptable use.

> message or send back an error; and the loss of this feature reduces

I agree.  However, all of the observations made so far regarding
spam/virus filtering in general still apply to filtering at the SMTP
level.  I would say that NO keyword filtering could take place.  The
best that one could do at the protocol level would be to reject messages
that fail to meet a tighter criterion than is currently required.
Perhaps:

  a) All hosts must resolve with DNS.
  b) All hosts must support an encryption key registered with DNS that
permits all message hops to occur between registered hosts encrypted
with the destination host public key.
  c) The header autogenerate a postmaster-recursive email address for
reporting abuse to the entire delivery path.  This would put a rather
large burden on the main network backbone administrators -- they'd need
automated tools to help handle it.  OTOH, it would REALLY give them an
incentive to shut down networks that are a primary source of abuse until
they manage to police themselves.  Automated tools at the highest level
might just generate an "abuse histogram" that triggers a human response
only when levels rise above that which might be identified as
"reasonable" for a network participating in the eternal battle with the
bad guys.
  d) With keyed host registration, tools that can QUICKLY isolate an
originating host and bop its (ab)user (minimally get them off the
network, ideally "instantly" fine them or charge them money such as a
reconnection fee AFTER getting them off the network).  This would give
end users a strong incentive to police their own systems against viruses
and would give spammers additional costs to pay or additional charges to
be brought against them, should they try to skip out.

I personally would ALSO like it if AV vendors STOPPED bounce messages
altogether.  SMTP bounce messages have a point and are even necessary;
AV bounce messages are a joke, a waste of time, and a potential source
of serious abuse.  NO viruses currently exist that don't forge the
header, it is just that most viruses nowadays use random forged headers
out of the infected host's address books.  They could, however, all
claim to be from e.g. SCO or Microsoft (some already exist that do the
latter, but more for social engineering reasons than DDOS, I think).

  rgb

---

From: Ed Gerck <[email-masked]>
Date: Mon, 16 Feb 2004 10:45:14 -0800

"Robert G. Brown" wrote:
> > We can't lock the
> catch who does so.  

On the flip side, this is a good example of how the anthrax threat was 
not handled. The solution was not to rely on the illegality of sending 
anthrax (which, obviously, wasn't enough of a deterrent) or the probability 
of prosecuting the sender (which we have not yet done), but on a "lock" 
that was put on all mail coming in. Mail that came from unknown senders 
was more carefully verified and even sterilized, some was backtraced and 
the sender was verified. 

But postal mail, contrary to email, cannot put a burden on the 
sender that is higher than the postage cost. Email, rather than 
being cost-free for all senders, can be made expensive to senders 
we don't know. And the way to do it mandatorily is by using code -- 
not law.

This is useful because our email is laced with the "anthrax" called 
spam. Filtering by subject line, email headers and body text is not 
enough, and frequently backfires by making us delay and even not 
read what would otherwise  be a message of interest.

BTW, the technique of imposing a task that burdens the sender in 
order to reduce interference due to rogue senders has a parallel
in spread-spectrum technology, for example. By only receiving messages
that are frequency-keyed as expected, my receiver can withstand
jamming (i.e., noise messages that are in-band -- "spam"). This
is in addition to other filters I have for post-processing.

---

From: Ed Gerck <[email-masked]>
Date: Mon, 16 Feb 2004 11:13:38 -0800

>   a) All hosts must resolve with DNS.

If you list why this isn't used today perhaps you
will change "must" to "may".

> with the destination host public key.

Mail privacy can only be guaranteed with an end-to-end encryption.
Securing email in message hops does nothing to prevent monitoring
at each host in the hop -- with some hosts not even advertised in
the header.

> they manage to police themselves.  

This would create a huge liability for the backbone administrators --
for example, one false abuse report and they could be sued for disrupting 
lawful communications. Human supervision actually increases the liability
-- it can't be blamed on a software glitch.

> reconnection fee AFTER getting them off the network).

Machines running amok, quickly killing off other machines without
recourse, without explanation. A kangaroo court for email, penalizing
the users.

>  This would give

Again, what you propose is to penalize the victim -- the user. That's
exactly what we should stop doing.
 
> altogether.

Free speech, good luck.

---

From: Ed Gerck <[email-masked]>
Date: Mon, 16 Feb 2004 11:31:16 -0800

Free speech, good luck.

---

From: Dean Anderson <[email-masked]>
Date: Mon, 16 Feb 2004 17:55:32 -0500 (EST)

On Sun, 15 Feb 2004, Ed Gerck wrote:

> Dean Anderson wrote:
> > 
> > It isn't the case that the spammer intended to send a message about
> > the superbowl, but somehow "noise" altered the message to a
> > solicitation on viagra. Rather, they intended to send a message on
> > viagra, and you recieved their message, noise free. But seeing the
> > solication for viagra, you became upset, and reported a complaint
> > about the inappropriate use of the channel. In
> > information-theory-speak, you report a "communication in violation of
> > the security model"; a covert or sneaky channel.
> 

Err, we do not agree on that. You still misunderstand the nature of a
covert channel.  I suggest you re-read the definitions and references in
the reposted messages from Ellis Cohen and Stavros Macrackis.

A covert or sneaky channel is merely one in which the communication is
//not authorized by the security model// It has nothing to do with
readability or detectability.  There is no theorem that says covert
channels cannot be detected. Quite obviously, they are detected, and some
action might be taken.  Theory just says that you cannot prove they aren't
there.  Let me put it another way:  A "null" reading on your "covert
channel detector" does not mean there aren't any covert channels--Just
that you haven't detected any.  This is a subtle, yet significant
difference.

In yet other words: you whack-a-mole when you find one, but you can't say
that there aren't any moles. It is not a game you can win.  You have to
keep looking and keep whacking, so long as there are moles to pop up. The
arcade whack-a-mole game stops when you run out of time, but our game only
stops when no one wants to spam or conduct abuse or government
intervention prevents them from playing.

We now have a legal process to use against abusers who are not
commercial--most, if not all, genuine commercial spammers will simply
comply with the law.  That leaves those who aren't genuinely commercial,
and whose intent it is to annoy people.

> in the subject line by using wrongly spelled forms of "viagra", 

This could be a covert channel. But its also possible that the whole spam
message even with a correctly spelled viagra would be a covert or sneaky
channel if it is not //authorized by the security model//, and the
"security model" is simply an Acceptable Use Policy statement not to do
that.  In this case, you may have a very weak "covert channel detection"  
process. But extreme weakness in the process is irrelvent to the theory.  
What, if anything, has to be done to get past the detection process and
the security model and into your mailbox is irrelevant.  The security
model can be made quite extensive, such as with Mandatory Access Controls
as implemented in secure operating systems.  Even so, one cannot say that
there aren't covert channels.  One can say other things about them, but
not that thing.

Information theory has proved itself useful to the analysis of anti-spam
schemes. Besides being able to rule out a number of schemes which promise
to be complete technical solutions to spam, we also see what range of
solutions can be implemented about spam and what results we can expect to
see from that range.

Consider the case of Mandatory Access Controls (MAC) for operating
systems.  We see that if we tighten up the controls on the flow of
information, that we improve our chances of detection. Particularly, we
hope to detect people trying to find covert channels before they succeed
in finding one.  This is very expensive, both in supervision costs, and in
the difficulty of training workers to use such systems.  In the case of
classified government information, the cost is justified.  Having a
potential spy create a denied MAC security event while probing for a
covert channel is well worth the effort, even if you can't be sure that
they will be caught.  The spy, or even potential spy or stupid user, is
then removed from the secured areas. Even honest, but stupid users are
removed, and this can be rationalized because they don't have the capacity
to be trusted with sensitive information.  It works because the same
'mole' doesn't get repeated chances to find the channel that will be
successful, and there are legal processes to make that happen. You cannot
lie on a security clearance application when it asks your identity, and if
you've ever had a clearance revoked or denied.  Expensive checks are made
to ensure that your answers are truthful.

But the same can't be said about spammers/abusers.  We can't escort them
out, and we can't even be sure of their identity in a civil context.  
Frequently, they are using someone else's identity or computer.  We
already detect them quite easily. But there is little that can be done.
Once positively detected, we can block some spam for a while.  We improve
filters, and spammers/abusers eventually adapt.  This basic process cannot
be stopped, unless the spammers/abusers stop of their own accord or some
legal process is brought to bear to force them to stop.  We can probably
apply bayesian filters, and I think AI, text summarization, etc to the
problem to help automate the task. Of course, spammers can use automatic
inverse methods to automate the task of finding channels that aren't
blocked.  However automated, the fundamental governing process described
by information theory isn't altered.

		--Dean

---

From: Ed Gerck <[email-masked]>
Date: Wed, 18 Feb 2004 17:10:13 -0800

Dean Anderson wrote:
> readability or detectability. 

To be useful for its covert purposes, a covert channel should not be easily 
detectable as a covert channel -- in our case, spam should not be easily
detectable as spam.  Thus, it has to do with readability and detectability. 

That's why, as a matter of logic, we should agree that if the message can 
be detected/read by the intended recipient then it's not in a covert 
channel (anymore). This does not imply that if the message can NOT be detected/read by the intended recipient then there is NO covert channel.

> that there aren't any moles. It is not a game you can win. 

That's where we disagree -- if I can make it harder/slower for the other 
side to set up moles than it is for me to find them, I will win.

> We now have a legal process to use against abusers

someone must have said the same for anything we have a law for...
including theft...and yet we do find it useful to lock our cars, no?

In many residence areas, mailboxes have no key and anyone can open
them and insert rogue mail, bombs, etc. This is the same way that your
email address works today. Anyone can put email in your emailbox and,
if they're clever enough, spam filtering in your personal MUA or at the 
MTA will not help. You will receive spam. You say this is not a game
you can win... "there is little that can be done."

In some residence areas, however, mailboxes have no mail slot. The mailman 
has a key to the mailbox and needs to use it in order to insert mail. The 
box owner has another key and uses it to retrieve mail. This still does
not prevent you from receiving a letter laced with anthrax, but it
gives us a good metaphor for improving email: We need to be able to control 
receiving what is posted to us based on the trust/authorization we associate 
with the poster AND the message. In other words, if we have no reason to trust
the poster or the message, we should be able to impose a burden as high as we 
desire on the poster (including no burden).

The decision what to accept or reject should happen at the recipient's MTA 
(preferably) or MUA in interaction with the purported sender's MTA and MUA. Also, to be effective, this should not depend on a user's list of current  
v****a-like words. Providing a barrier for accepting email (i.e., a putting
a selective lock in your email box) is neither a legal issue nor an user 
issue -- is an IETF issue. By using suitable PK encryption for end-to-end 
email privacy (including crypto-puzzles), I suggested we can offer such 
spam burden at no added cost to the user.

I advance that in the old DARPANET days, spam protection was provided
by DARPA, because DARPA could locate and disconnect any user who abused 
the system, and everyone knew it. That's why there was no need to design
email in any other way than what is today, with open mail addresses. 
However, today, the Internet is an open system and there is no way to 
locate and effectively disconnect abusers. The abusers will just continue 
to route around, seeking zero friction to posting, until we put in place 
a better system just like the postal mail had to do, laws notwithstanding.

Cheers,
Ed Gerck