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@xxxxxxxxxxxx