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(_at_)jlc(_dot_)net>
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