Slashdot Mirror
The Anti-Spam Research Group's Plan for Spam
egoff writes "Speaking of standards, the ASRG, a member of the IETF, has a plan for "consent-based communications." Among the suggestions, according to Internet Week, are authentication services for falsified addresses, trusted senders, reputation systems (karma?), opt-out tools, best practices for challenge/response, and even a proposal for micropayments on unwanted mail. Instead of defining spam, the ASRG wants to provide administrators and users the tools necessary to avoid what they consider to be unwanted. One of the tools, Reverse MX, is expected to be in place in several months. It would allow the receiving mail server to query a domain to determine if the sending server is allowed to send on its behalf."
Great write-up on RMX, brought to you by the same guy who came up with an easy way to snapshot.
The RMX record can return any IP addresses that it wants, the receiving machine just does a DNS lookup on the originating address and makes sure that IP is authorized to send mail. Read the RFC for more details.
The original discussion on Nanog can be found here or perhaps here. He originally had the proposal on his site (dead link) but he seems to have taken the page down, and I don't see any reference to him contributing to this draft.
The RMX approach is certainly very interesting. Although not based on DNS I had previously asked an AOL postmaster for similar information about what servers could legitimately send mail from any aol.com domains. That simple step has allowed me to block almost 100% of all spam reporting to come from joerandomuser@aol.com. I've been looking for similar information from the other big ISPs that spammers love to forge but with little luck.
Of course there may be a few things that this breaks (not that they shouldn't be fixed to work a different way). One is email intermediaries. SMTP was originally designed to be store and forward, and it used to be quite common that mail took many sometimes unpredictable hops along its way...direct end-to-end connections were not nearly as unbiqutious as they are now. But there still are cases where an SMTP intermediate hop may exist for legitimate reasons, but which may be unknown to the sender; thus they would not be listed in the RMX access list.
Another "questionable" practice that would be affected are services like monster.com, which send mail (usually resumes) to subscribers (companies hunting employees), but forge the sender address as being the real address of the individual, not of monster.com itself. Thus monster.com forges mail from almost any domain all the time; even though that mail can hardly be described as "spam" since the individual being forged has authorized monster to do it, and the recipient is paying monster to recieve them... But that kind of practice would still be affected without some workaround.
Oh, and if you want end-to-end authentication why don't more SMTP servers use the STARTTLS (aka SSL) mechanism with REAL certificates just like web servers do? If this became standard practice then it would be much easier to do SMTP server authentication with existing technology, and in a way that is completely transparent to the users (MTAs).I do like it as a partial solution (there aren't going to be any good total solutions in this affair). The benefits would probably accrue mainly to the big email services (Yahoo, Hotmail) whose domains are most often forged onto spam. Many people arbitrarily thow away mail purporting to come from there, which must be hurting them in some fashion. Since no one's going to reject mail on the basis of a missing RMX record, spammers will start forging mail from domains having no RMX records at all (or possibly a few serving 0.0.0.0/0 records). So probably not a strong benefit, but it'd help restore the viability of the major email services somewhat.
I do rather suspect that if RMX authentication were widely deployed we'll see DNS cache poisoning attacks come into vogue again. And if there's a set-in-stone system with an even larger deployed base than SMTP, it's DNS.