--On Monday, 30 October, 2006 00:36 -0500 John Leslie
<john(_at_)jlc(_dot_)net> wrote:
I don't agree with Frank's ultimatum-like tone here, but
this is a real issue; and we need a way to talk about it.
Backscatter is sometimes intended as a Denial-of-Service,
though more often simply a way to get spam past folks that
check for a "valid" RFC2821.MailFrom. Regardless, it often
exceeds the volume of useful email, and its volume is growing.
I expect folks will be finding themselves blacklisted for
"generating" too much of it.
The issue lies exactly where Frank says: any MX server that
accepts email which it _may_ not be able to deliver has a
responsibility to evaluate the likelihood that the
2821.MailFrom is useful: no later MTA will be in any better
position to do so.
IMHO, we'll never eliminate backscatter; but there must be
alternatives to blindly accepting millions of probably-false
2821.MailFroms.
If we don't discuss it here, we're doomed to watch email
become even less useful as misguided folks implement
"solutions" which shift "responsibility" even farther from the
point where something reasonable can be done.
For whatever it is worth, there is one important distinction
between the "DoS" theory and the "get spam through" theory
described above. If the problem is the latter, then there is a
remedy that fits the existing model much better than either
Frank's approach or discarding mail. That is to _not_ return
full content but, instead, to return headers only or, perhaps,
headers plus the first few lines of text if the first body part
is text. Done properly and with some obvious restrictions
(e.g., truncation of long subject lines and discarding unknown
headers that seem long enough to be an annoyance), that approach
would make backscatter essentially useless as a means of spam
delivery.
It does mean that we need to be clear about the problem we are
solving, since it wouldn't help with actual DoS attacks. But it
is a lot less drastic than effectively prohibiting NDNs.
john