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@xxxxxxxx". > > 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@xxxxxxxx> Delivered-To: rgb@xxxxxxxxxxxx Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mail.phy.duke.edu (Postfix) with ESMTP id C9DACA7836 for <rgb@xxxxxxxxxxxx>; 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@xxxxxxxxxxxxxxx; 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@xxxxxxxxxxxxxxx; 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@xxxxxxxx>; 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@xxxxxxxx; 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@xxxxxxxx; 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@xxxxxxxx; 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@xxxxxxx> X-X-Sender: dean@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxx