On Wed, 17 Mar 2004, Vernon Schryver wrote:
(A bunch of beautifully said things that I agree with fully)
If you believe that "reputation" or "trust" systems might help the
spam problem, then the only room for improvement is in the trust query
protocol. DNS is a screw driver being used as a hammer in DNS blacklists.
However, this is merely a matter of optimization or elegance.
The one other place that I think there COULD be room for improvement is
to make the process of identifying sites that are originating spam or
viruses more rapid and automatic, and to create a better/more formal set
of rules responding to a site (or an entire SP subnetwork) postmaster.
Such work might actually spell out all the steps between reporting and
being blacklisted.
Right now I think it is safe to say that "most users" don't know
anything about "postmaster" addresses. Nor do they know how to read a
mail header (or they may be using a MUA that doesn't present the full
header even as an option). Finally, complaining about spam takes time,
especially when you have a lot and have to write an actual message about
each one one at a time. Consequently 99+% of all users are effectively
prevented from reporting spam to the hosting SP of the originator by a
mix of inertia, ignorance, and inability.
No wonder the SPs feel that they can ignore the problem -- instead of a
million pieces of spam generating a million complaints and burying the
poor postmaster admins of the enabling SP in an emergency consisting of
rapidly filling mail spool files and writing procmail rules to handle
them all so they can extract real communications from all the spam
complaints, they get ten reports of spam, maybe, from ten hardnosed old
timers who can read a mail header and care enough to report them (maybe
because they make it through their filters). I no longer bother -- if I
have to generate a complaint message per piece that my filters identify,
I'll never get ANY work done.
If every ten pieces of spam sent out of an SPs network -- even every 100
pieces -- generated a complaint message to postmaster with headers laid
out that clearly identified the offending host/client, I think that it
would provide SPs with a real incentive, AND the tools, to address the
problem.
I don't know if this is a problem that could be addressed in protocol,
but it might be. I can think of several things that an MTA (or MUA)
might do to facilitate a spam-bounce.
a) Preparse the header so that the entire delivery path is the primary
content of the message, with the message itself added (header intact) as
an attachment.
b) Return the complaint as mail to postmaster of the originating
network with a special error code that would allow it to be counted and
digested easily. One doesn't want to create a new kind of DoS attack on
postmaster, and making it easy and automatic to return a complaint COUNT
of some sort on otherwise identical content can help prevent that while
making it easier for SP admins to deal with mounting complaint levels.
c) Work out what to do about relays and proxies, again to prevent
man-in-the-middle DoS more than anything else. One site should not be
able to generate mail that it "forwards" with fictitious headers and
evil content so that it appears to come from some hapless but innocent
network.
d) Take steps to ensure that SPs run a postmaster address, and maybe
come up with things like Jeff Chase was proposing to continuously
measure their responsiveness to spam/virus-class bounce messages and
globally blacklist the worst (least responsive) offending SPs. Etc.
Right now enabling SPs are insulated from any kind of RFC-based
responses or complaints about spam because MUA's and MTA's have no
predefined protocol for generating such a response in a constructive
way. Most complaints/bounces that are automatically generated by
antivirus software or reported by humans (I've read plenty of both:-(
are hopeless and de facto useless without several rounds of
communications, and sometimes not even then: the humans don't even know
what a mail header IS and often have no way of knowing or suspecting
that the From address is bogus or sending in the real header so it can
be parsed by the SP postmaster. Antivirus software developers should
know better (damn it!) but even THEY don't bother to parse the header or
include the header in the stupid bounces they generate, or validate
any sort of correspondance between originating host and From address.
So even though one could argue that adding a real protocol layer for a
preformatted, standardized, spam/virus bounce is not strictly necessary
because all the information is already IN the header, doing it anyway
might codify and standardize a complaint so that the complaint "always"
contains the essential information and so that a complaint to the right
target is "easy" to generate (can even be generated automatically). It
could then guide the development of compliant tools that can deal with
this for ignorant humans using stupid MUAs and maybe even (presumably)
smarter AV programmer humans as well.
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