On Wed, 25 Feb 2004, Dean Anderson wrote:
There are many ways to reasonably accurately identify mail to this list
and distinguish it from all others: It is sent "to: ietf(_at_)ietf(_dot_)org".
I haven't seen very much spam that has that characteristic, so I don't
think such spam is much of a problem, if any problem at all.
--Dean
In fact, if you look at the full header:
Return-Path: <owner-ietf(_at_)ietf(_dot_)org>
Delivered-To: rgb(_at_)phy(_dot_)duke(_dot_)edu
Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40])
by mail.phy.duke.edu (Postfix) with ESMTP id C9DACA7836
for <rgb(_at_)phy(_dot_)duke(_dot_)edu>; Wed, 25 Feb 2004 16:24:55
-0500 (EST)
Received: from majordomo by asgard.ietf.org with local (Exim 4.14)
id 1Aw6QN-0006qR-OK
for ietf-list(_at_)asgard(_dot_)ietf(_dot_)org; Wed, 25 Feb 2004
16:18:35 -0500
Received: from ietf.org ([10.27.2.28])
by asgard.ietf.org with esmtp (Exim 4.14)
id 1Aw6Ot-0006nT-O0
for ietf(_at_)asgard(_dot_)ietf(_dot_)org; Wed, 25 Feb 2004 16:17:03
-0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15076
for <ietf(_at_)ietf(_dot_)org>; Wed, 25 Feb 2004 16:17:01 -0500 (EST)
Received: from ietf-mx ([132.151.6.1])
by ietf-mx with esmtp (Exim 4.12)
id 1Aw6Os-0005Mn-00
for ietf(_at_)ietf(_dot_)org; Wed, 25 Feb 2004 16:17:02 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12)
id 1Aw6Ny-0005Hp-00
for ietf(_at_)ietf(_dot_)org; Wed, 25 Feb 2004 16:16:07 -0500
Received: from cirrus.av8.net ([130.105.36.66])
by ietf-mx with esmtp (Exim 4.12)
id 1Aw6NZ-0005Cg-00
for ietf(_at_)ietf(_dot_)org; Wed, 25 Feb 2004 16:15:42 -0500
Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66])
(authenticated bits=0)
by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id i1PLFBMN028275
(version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168
verify=NO);
Wed, 25 Feb 2004 16:15:12 -0500
Date: Wed, 25 Feb 2004 16:15:11 -0500 (EST)
From: Dean Anderson <dean(_at_)av8(_dot_)com>
X-X-Sender: dean(_at_)cirrus(_dot_)av8(_dot_)net
you'll note that one can really be pretty certain a) that the message is
really from the ietf list; b) that it was originally sent from a
registered host whose IP number agrees with its claim of identity and
whose owner likes the notion of secured mail; c) that email to the list
is generically spam-scanned before being forwarded; d) that the
dean(_at_)cirrus(_dot_)av8(_dot_)net who authored the note is really who he
appears to be
and is accountable and hence is not about to hawk a website purporting
to portray coeds showering and playing with their doggies on webcam.
[Where it is parenthetically amusing to note that "hawk" means both to
sell and to clear one's throat to spit out corrupt and tainted slime...]
This is all BEFORE examining content. Then one can apply content
filters at YOUR end at whatever level of analysis and rejection you are
comfortable with. Obviously too-quick a rejection on simple keywords
like "coeds", "showering" and "doggies" would be a mistake.
This is all technology and protocol that exists now and in fact is in
place now, and doesn't require OTHER people to do a thing. YOU have to
do something -- take charge of your own spam-destiny, so to speak.
Parsing a header isn't horribly difficult, either for a human or for a
piece of software. I routinely do it visually if I have ANY DOUBT about
a message from a stranger or a friend being "really" from the purported
sender (for messages that make it through spamassassin). I also
routinely do it if a personal message from a vendor (sales, but not
spam) makes it through SA and I am considering answering. Messages
without a perfectly formed header and all hosts along the delivery path
both registered and identified correctly are rejected to the bit bucket
pro forma. Spamassassin uses data parsed from the header for several of
its tests, and not just for blacklist checks.
Digitally signing a message to or from ietf adds absolutely nothing to
your ability to determine whether or not it is spam except the necessity
of maintain YET ANOTHER complex mapping between identity and number. We
don't use the DNS-based one that we have as the rigorous basis of a
protocol-level accept/reject decision, in spite of the fact that it is
ubiquitous (and indeed already a critical component of the mail transfer
process), reliable and at least crudely secure. At most lookups are
used to drive blacklists, but we don't automatically blacklist mail from
all unregistered/anonymous sites.
Why in the world does anyone think that digital signature maps with
several orders of magnitude more entities to track, more complexity, and
hence more opportunities for spoofing and finagling are going to succeed
where simple DNS hostname lookup has failed?
IMO a "no anonymous mail" rule (no mail accepted anywhere from
unregistered hosts) coupled with pretty stiff fines and legal penalties
for spam would associate accountability and penalty and cause an
immediate and drastic reduction of the problem. Holding ISPs (and
providers of open relays and proxies) liable for the fines of their
clients if they bolt or "have no assets" would give ISPs a very strong
incentive to police their clients. Obviously, the two would have to
come about together -- it is less useful to have fines and penalties
when the originating hosts have unregistered IP numbers that change
every two days and are nearly impossible to trace.
I think that this is fairly unlikely to come to pass, as lawmakers are
as likely as not to be spammers of a sort in their own right, soliciting
campaign contributions, distributing political "newsletters", using
email in a variety of edgy, mass distribution ways. OTOH, they also get
spammed, as do their families, so one never knows -- some states are
slowly moving to control spam in law.
In the meantime, instead of burning a huge amount of human time and
energy just DISCUSSING the issue of universal keysigned mail (let alone
the hassle of implementing it for just one site), perhaps we can each
(in the words of Candide) "tend our own garden" and use one of the many
excellent filtering mechanisms already available, while teaching our
users to do the same. If the proposal meets this much resistance and
"why bother" attitude here, imagine the resistance it will meet at the
ISP level and out in the real world, where time spent implementing
ANYTHING is pure money and maintenance time down the drain.
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(_at_)phy(_dot_)duke(_dot_)edu