[an error occurred while processing this directive]
|Location: > About Us > RMX Site Map|
The most significant property of RMX records is that they do not break the Internet! The standard email protocol, SMTP, does not change. DNS simply adds a new type of resource record - something it is designed to do both easily and backwards-compatibly. The protocol remains the same. If the sender has not configured RMX records, or the recipient's mail server does not bother to check them, then nothing changes. However, if RMX records have been configured, and the recipient does check them, then forgeries will be detected. What the recipient chooses to do with that information - throwing the message out immediately, passing it on as a special header for use by (for example) spamassassin or procmail, or ignoring it - is up to the recipient. Without breaking the Internet, RMX records make email forgery much more difficult.
RMX records are also attractive because they don't have to be implemented everywhere to be useful. There is a small, incremental advantage to upgrading to RMX-aware software, both for senders and for recipients. Senders get some protection against the illegitimate use of their names, and recipients improve their ability to filter spam and avoid being deceived. This property makes the eventual widespread use of RMX records a realistic goal.
The efficacy of this scheme rests with the security of DNS. That's an important observation - not necessarily a drawback, because the era of secure DNS (DNSSEC) is slowly coming - but it is only fair to note that if the DNS system can be compromised, then RMX records break down. The recipient's mail server must handle inability to access the sender's name server (caused, for example, by a DDOS attack) gracefully, perhaps by placing the message in temporary quarantine until the name server is accessible again.
RMX is not a strong authentication mechanism, but it should be sufficient to stop most forgery. It is not intended to replace stronger mechanisms such as digital signatures. With RMX, the From: address on an email will become exactly as trustworthy as the URL in a web browser, which meshes with user expectation. Things that ought to work, such as "refuse sender," will work.
One particularly nice feature of RMX records is that they add to the technical infrastructure governments will have at their disposal to apply legal and economic pressure to would-be email forgers. Domain names could be forfeited (possibly along with a deposit) if they are used to send misrepresented email. Or perhaps a credit-like system could be established to prevent frequent abusers from registering new domain names.
The management of ---.com is growing tired of spammers using its good name to promote such unsavory products as earlobe enlargement gel, herbal spleen supplements, and sugar-free pizza. To make matters worse, a loosely-knit group of twelve-year-old internet vigilantes has begun peppering ---.com's customers with false safety recall notices for its "productz". Irate customers and primary school spelling teachers have been ringing all day, and the staff is exasperated.
A company-wide meeting is called to address the problem. Early suggestions, such as hiring one secretary's large, muscle-bound nephew to track down the perpetrators, receive widespread support but are ultimately rejected for assorted legal reasons.
Finally, a network administrator pipes up. "What if we post a page on our web site that lists the IP addresses of all of our outbound mail servers?
"Spammers can still forge our company name, but ultimately they're sending the spam from somewhere else. They can't make it appear to come directly from our servers' IP addresses unless they break into our network, which would be a lot harder. So customers will be able to check the source from which their ISP received the message (in the email header), and verify that it's one of the IP addresses on our list."
A dramatic pause ensues, during which the the entire staff contemplates the network administrator's suggestion. One-by-one, the participants seem to light up with understanding. There is a great deal of appreciative nodding and chin-scratching. Finally, the company founder stands up and clears his throat. "What the heck is an IP address?"
Hadmut Danisch's Internet Drafts.
Paul Vixie has written Repudiating MAIL FROM (simular to RMX)>
Meng Weng Wong's hybrid.
RFC 821: Simple Mail Transfer Protocol [describes the protocol used in email]. 1982.
RFC 974: Mail Routing and the Domain System [describes how email and DNS interact]. 1986.
RFC 1035: Domain Names - Implementation and Specification [describes the operation of DNS and RRs]. 1987.
RFC 2505: Anti-Spam Recommendations for SMTP MTA's. 1999. This document is also known as BCP-30 because it documents best current practices.
RFC 2535: Domain Name System Security Extensions [describes DNSSEC]. 1999.
ASRG, the IETF anti-spam research group.