On Sun, 15 Feb 2004, Dean Anderson wrote:
> On Sat, 14 Feb 2004, Ed Gerck wrote:
>
> > Dean Anderson wrote:
> >
> > > 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).
>
> 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
> > information theory, the choice is clear. The *information* transferred
> > by a covert channel is noise (the only other possible option).
>
> 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
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
--
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:rgb@xxxxxxxxxxxx