Fight spam with the DNS, not the CIA

64
– by John Fitzgibbon
It seems like spam is in the news every day lately, and frankly, some of the
proposed solutions seem either completely hare-brained or worse than the
problem itself. I’d like to reiterate a relatively modest proposal I first made over a year
ago: Require legitimate DNS MX records for all outbound email servers.

MX records are one component of a domain’s Domain Name System (DNS) information.
They identify IP addresses that accept inbound email for a particular
domain name. To get mail to, say, linux.com, a mail server
picks an MX record from linux.com’s DNS information and attempts to deliver the
mail to that IP address. If the delivery fails because a server is out of action,
the delivering server may work through the domain’s MX records until it finds a
server that can accept the mail. Without at least one MX record, mail cannot be
delivered to a domain.

However, when the DNS was first put in place there was no requirement to be able to trace
the identity of a sending mail server. This means that, as things stand, any IP
address on the Internet can act as a mail server, even though it may be virtually
anonymous and extremely difficult to trace. My proposal aims to close this loophole,
so that only registered mail servers can send email.

Since this proposal depends on the existing DNS structure, it could be enacted
(presumably with a grace period for organizations to get their
mail servers registered) without requiring any initial technological changes
whatsoever.

Over time, mail servers could be configured to reject mail that comes from
other mail servers that have no MX record. Furthermore, since the MX record would
be tied to the legal owner of the domain in question, additional
filtering could be done to reject mail from servers that are owned by known
spammers. In the longer term, this would decrease the complexity and
increase the accuracy of mail filtering software. It also gives spammers
fewer places to hide.

Of course this solution is useful only if the contact information for the
domain in question is reliable, but this is an area that has been tackled already
to some degree. ICANN-accredited domain
registrars are required to include a contractual provision that contact information
for a registered domain must be valid and up-to-date.

A downside to requiring MX records is that a mail server with an MX record is
presumed to be capable of receiving mail. This would create
headaches for organizations that currently depend on a division between
outbound and inbound mail servers. This “headache,” however,
is more palatable than the current “life-threatening illness” that spam has
become. In addition, one of the root causes of much of the spam we receive is
the fact that mail servers can so easily be configured to send millions
of messages without any legitimate mechanism for returning those same
messages to the original sending IP address.

There are a number of steps organizations could take to mitigate the initial
effects of having to register outbound mail servers, if they currently
don’t accept inbound mail on those servers:

  • Give the MX record of an outbound mail server a very low priority. A
    sending mail server is less likely to pick a receiving mail server that has an
    MX record with a low priority.
  • Register a separate domain for “outbound-only” MX records. If inbound
    mail is typically addressed to “someone@someplace.com” and you have outbound
    servers registered under “someplace_outbound_mail.com”, then your outbound
    servers will never be selected for normal inbound mail.

With these mitigating measures in place, it would be safe to keep outbound
mail servers closed to inbound mail. Current mail server technology is
reliable enough to deal with the situation where one (or more) of many listed
mail servers is found to be unavailable.

In the longer term though, it would
be better to discontinue the practice of separating outbound and inbound
mail server IP addresses. That was a legitimate technique when there was no
other practical way to handle load-balancing and security, but today
multi-homing and firewalling products can handle the load and
security issues without requiring a specific division of mail server IP
addresses. Discontinuing this practice would leave spammers sticking out like
a sore thumb.

One final attraction of mail server registration: Enforcement is simple.
No army of “men in black” is needed to chase down the lawbreakers — if you
choose not to register your mail servers, or repeatedly send spam from those
you do, then nobody will accept your mail.

Simple as that.

John Fitzgibbon is a software
engineer who lives and works in San Francisco, Calif. He is employed by
Shenick Software Systems, writing TCP/IP
test software for network test appliances. He spends way too much of his spare
time devising filters for spam.