> 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. 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. > > 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. 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 > > -- > John Leslie <john@xxxxxxx> > 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