As the world becomes increasingly overrun by spam, it's clear that we need to take some kind of measures to prevent vast numbers of mail servers and network connections, worldwide, from keeling over under the sheer weight of unsolicited mail. In its document Caller ID for Email Microsoft outlines a means of applying a concept to email rather like the Caller ID feature on many telephones.

Who's allowed to send?
On the surface, the idea is a good one - to add a "sending mailer" type entry to the Internet Domain Name Service (DNS) system records for each domain. This would enable a recipient mailer to look up the sender domain from the ‘From’ address of each message, check the DNS for that domain and only agree to deliver the message as long as the results from the DNS conform with the domain in the sender's address.

In fact, this is pretty much how the Sender Policy Framework mechanism works - Microsoft has simply gone some way further down the road and considered some of the more intricate issues of applying spam prevention to email transport.

The Microsoft spec is well thought out and goes to great efforts to define an anti-spam mechanism that is based to a great extent on standards (notably the DNS protocol and the RFCs that relate to SMTP and email message formatting). Furthermore, the decision has been made to attempt to base the Caller ID process on existing DNS record types, most notably the TXT (general descriptive text) record.

Do we care about extending the standards?
On the surface, the logic is sound. To add a new record type to the DNS - or to extend the SMTP protocol itself - would require changes to established standards. New features in implementations of SMTP and DNS technologies would have a long lead time. One can't help thinking, though, that the problem of spam is just so enormous that, in fact, the software vendors would jump at the chance to implement changes quickly and that system managers would upgrade willingly to the new versions as it would save them effort, and cost, immediately.

This idea is borne out by the observation that's made in the Microsoft document that the only way to completely protect against determined spammers (who could exploit connection hijacking or sequence number prediction attacks) is to consider adding functionality to SMTP servers (albeit using an existing SMTP command, thus removing the need to alter the actual specification) to do some simple key exchange. Even without this key exchange, the use of a reverse MX record requires changes to the SMTP server software - it's just the DNS implementation that remains unaltered.

The alternatives
It's clear that some kind of "reverse MX record" (as the SPF documentation terms it) is an absolute necessity. Why not, then, extend the DNS specification to add a new type of resource record, instead of mucking about trying to squeeze an email policy into the existing (and heavily limited) TXT record structure? The reason is probably that inventing a new protocol would be a major design and implementation task but adding another resource record type to an existing one wouldn’t be.

At least one organisation ( SenderID ) has considered taking the sender authentication a step further by using identifying certificates - rather as you do with a secure HTTP connection. This is a much more involved approach than a simple DNS lookup, since it requires the addition of some potentially complex certificate lookup functionality on each email server (not to mention the construction of some heavy-duty, reliable certificate servers by nominated certification authorities). As with secure HTTP, it provides a nigh unbreakable guarantee that if you can look up a certificate, the sender is who he or she claims to be.

After all, even if you have a "reverse MX" lookup all a spammer has to do is find someone with an open SMTP relay and they can still chuck zillions of messages around the world. It’s true that anyone with sense will have configured their mail server to check incoming messages against an Internet-based open relay list but the option is still there for the spammer. Think about it: register a domain, find an open relay, set the reverse MX record for your domain to that relay's address and you're sorted. To prevent this, in addition to having a "which mail servers service this domain" record, you'd need the opposite as well - a record for each mail server saying which domains that server services.

Summary
There's no doubt that the concept of a "reverse MX" DNS record will be a great help to the anti-spam brigade. The problem is so severe, though, that it seems a shame to try to shoe-horn the solution into existing DNS records just so there isn't a need to define a new record type. Let's do the job properly and let's also consider the more involved "sender certificate" approach too, for those willing to take the time to adopt such additional protection.