On Wed, 17 Mar 2004, Robert G. Brown wrote: > 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. This is true now. Many people don't know how to parse the headers, but it obeys a specific syntax and is machine parseable. > 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. This is possible now, and SpamCop does this. The problem with SpamCop is that they alter the message, making it useless. SpamCop complaints are routinely deleted as a result. I usually forward them on to customers with an FYI that we don't consider such to be a valid complaint, but they may want to be aware of what someone said. > 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. Relays don't add ficticious headers, nor do they add evil content. They may place their (true) headers on top of ficticious headers. They cannot verify that the headers given are accurate. This is true of all relays, open or closed. Proxies are another story. I don't know of any genuine reasons to run open proxies, though closed proxies (web caches) are clearly useful. I don't know of anyone claiming they are useful. But neither does that mean they have no use. However, as a service provider, I would say this much: If a customer found a useful reason to have an open proxy, then I would only insist that they keep logs of its use. This is easy to place in a contract or AUP. > d) Take steps to ensure that SPs run a postmaster address, and maybe There is already a BCP for this. Rarely is this a problem. > 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. How would you define "responsiveness"? Does it mean getting an auto-responder message? Does it mean getting a message saying something had been done? You cannot give out certain information about customers. Basically, all you can do is send an auto-responder message and a notice that the ticket was closed. That doesn't indicate what happened, nor does it indicate who the spammer was, or if the ISP agreed they were a spammer. Sometimes the action is obvious if, say, a website disappears. But how do you know they took action against a dialup customer? You can't. "Continuous measurement" is the same as a DOS attack. A ping flood is a continous measurement of the bandwidth available and its responsiveness. That's why there is a -f option to ping. Unauthorized measurements are illegal. > 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. ??? I'm not sure what you mean. By the time you -read- a spam, it is delivered, and the SMTP protocol has long since finished. Spam isn't the only kind of abuse that an ISP responds to. The abuse@<isp> works pretty well, since you can forward the complained-of message. There are some things I'd like MUA's to do, such as include the whole headers(some MUA's do, some MUA's don't), but that isn't an RFC issue, either. > 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. Yes, it would be good to send the entire headers. But users should know that the from: header can be forged. They should also know some other things about email and the internet, such as don't open attachments you aren't expecting. If you get an unexpected attachment, ask the person if they sent it. This is an education problem. --Dean