Prospects for a National Email Registry
David MacQuigg
In 2003 Congress asked the FTC to solve the problem of email forgery and spam, expecting something like their earlier success with the Do Not Call Registry. The FTC quickly discovered the critical missing piece - no way to authenticate the sender of an email. They are now expecting the industry to solve that problem first. The industry, via the IETF, appointed a working group, but it was disbanded in September 2004 when the rival methods couldn't agree on a compromise.
Each group is now pursuing its own method, polishing it to perfection, assuming it will be the one and only, and paying no attention to how it will inter-operate with other methods. Talk to the advocates of any method, and they will tell you, "Our method will work, if only everyone would use it.", and they are probably right. The problem is that choosing one excludes the others. There is no simple standard within which all methods can coexist. Such a standard would not be technically difficult. The difficult issues can be solved by each method independently.
The IETF is unable to provide a shared standard because of organizational problems. Any strong and uncompromising minority can block a resolution. There is no way to resolve such disputes. Working groups are open to anyone who cares to join, and any IETF working group involved with the spam problem will be dominated by uncompromising advocates. The long tradition of assuming everyone in a working group can eventually be swayed by the merits of a technical argument seems to have broken down. Perhaps this is part of the general trend as the Internet moves out of a technical sub-culture into mainstream society. The IETF procedures and Internet technology were designed in a time when participants were reasonable, and email was not overrun by criminals.
Progress on selecting a standard authentication method has been slow. The remaining technical problems cannot be evaluated without large-scale deployment. The few domains that have tried enforcing authentication are having little success. That's because the number of domains using each method is so small, that a lack of authentication means nothing. Even when a domain does authenticate, it is likely to be a disposable domain name set up for the sole purpose of spamming. That's because another critical new tool, a domain-reputation service, is also missing. Spam blocking companies won't invest in such services until it is clear that the industry is really going to use it.
"Chicken-and-egg" situation is what frustrated participants are calling it. I think "logjam" is a better analogy. The pressure is building, but the various pieces of the solution are holding each other back. What will it take to reach the "tipping point" where every legitimate domain wanting to operate a Public Mail Server feels the need to authenticate its emails? Will it be necessary for the FTC to move to the next step in their plan, a mandatory authentication method?
The FTC is understandably reluctant to mandate a technical
standard. In addition to difficulty of hard-coding technology into law,
there are major problems of enforcement across international boundaries.
Fortunately, there are many things the FTC can do to accelerate the pace of
adoption, and promote the current experiments without taking sides in the technical
debates. One low-cost and very effective move would be to establish a
Registry of Public Mail Servers. Along with this Registry would be some
simple, neutral standards, like the format of the records to be kept in the
Registry. Establishment of these simple standards does not require that a
final winner be chosen among the competing authentication methods. They
can all coexist within the standards. They can all make use of the
Registry.
The Email Registry anticipated by Congress in 2003 was a
list of recipient addresses. There are a number of differences between
the email system and the phone system that will require a different kind of
registry. The significant differences affecting planning and
implementation are:
1) The Do Not Call Registry is an Opt-out system for recipients,
depending on the government to enforce the law against unwanted callers.
The Registry of Public Mail Servers should be an Opt-in system for senders. Registration is voluntary, so it will require
no new laws or regulations. Enforcement will be done by recipients, who
will reject mail from any domain that isn't in the Registry or doesn't have a
good rating from an acceptable reputation service.
2) The Do Not Call Registry is supported by a small network of computers.
The Email Registry must support a much heavier load, perhaps 100 million
queries per day. Existing DNS technology is perfectly suited for a fast,
efficient, and secure Registry, with servers widely distributed, resistant to
denial-of-service attacks, and not loading any DNS servers performing other
vital functions on the Internet.
3) The Do Not Call Registry is a simple list of phone numbers. The
Email Registry will contain complex information with tricky formats and
frequent changes. To avoid a technical support burden, the Registry
should simply copy and merge information from records that have already been
tested by the domains and the domain-rating services that generate the
information.
4) The Do Not Call Registry uses existing standards for web interfaces
and file transfers. The Email Registry will use existing DNS standards,
perhaps with a few enhancements to improve speed or security.
5) The Do Not Call Registry must be carefully controlled to avoid abuse
of a huge list of private numbers of individuals. The Email Registry will
be a much shorter list of domains that wish to operate Public Mail
Servers. Everything in the Registry is public information, with no need
for privacy. Think of a listing as a license to operate a Public Mail
Server.
6) The Do Not Call Registry uses methods that are not controversial.
To keep any controversy out of the Email Registry, it should not get involved
in the technical debates, or any disputes over domain ratings. Domain
owners should decide which authentication methods they will offer, and
independent rating services should handle all disputes over domain
ratings. The Registry simply provides a merger of the records published
by the domains and the services.
7) The Do Not Call Registry involves the FTC in processing a large number
of consumer complaints. The Email Registry would not have that
burden. Spam bounces go to the recipient's ISP, and from there to the
rating services.
8) The Do Not Call Registry is limited to the
While this list may not be complete, the remaining differences should have
little impact on planning and implementation. In general, it looks like
deployment of a Registry of Public Mail Servers will be much easier than the Do
Not Call Registry.
Many believe that the problems with email are insoluble.
This negativism is strongest among those who don't understand the technology,
and a few who are making money from the status quo. If spam were to
suddenly stop, email carriers would lose 80% of their traffic, and many other
businesses would have to make major adjustments.
The negativism should not stop us from moving forward. Compare the cost of
establishing a Registry of Public Mail Servers, maybe $2 million, to the cost
of email abuse, estimated at $22 billion per year. Even a small chance of
success should be more than enough reason to give it a try.
Email abuse continues because domains that allow the abuse have no incentive to
change. It will stop only when it costs them money, or when the
government steps in with licensing regulations and penalties. We can
avoid the burden of regulations. An effective Registry will allow
blocking by recipients to put some of the cost of abuse back on the domains
that allow it. If spam-tolerant domains had losses from email rejection
even 10% of the cost of spam, it would go away.
A registry by itself will not solve the problems of email authentication, but
it could provide the catalyst necessary to get the industry moving.
Providing this key piece of the solution, a piece that all methods can share,
is a contribution the FTC is uniquely positioned to make.
=== End of Article ===
1a) What if very few email senders volunteer for the Registry? Won't we have the same situation as now, still short of the tipping point?
The information needed for the registry is already publicly available. To start, every sender gets a default record based on their total IP-block allocation. If they don't want to accept responsibility for their entire address space, they can go to the Registry website and make whatever changes they want.
1b) How will you manage security with so many domains making changes in their records via the Registry website?
Most domains will make changes via their own DNS records, and Registry updates will occur by copying those records. For domains that don't have access to their own DNS records, a confirming email to "postmaster@<domain>" should be sufficient to validate a requested change.
4a) A "notify" mechanism should be provided so that domain-rating services can quickly downgrade any domain that starts spamming. This should include a quick update of Registry records and notifications to flush cached records.
8a) Global scaling. Are there practical limits to how
many servers can be distributed worldwide at a single DNS node? For
example, if we need 1000 servers for the .com.mail node,
how will they be listed at the .mail node?
Is it practical to have 1000 NS records at .mail?
What else could be done short of mandatory regulation? A large organization like the FTC could promote a standard format for the ID declaration, and overcome an issue that has been blocking cooperation for over a year. Same with a standard authentication header. Just keep it simple, and leave room for all the optional parameters each of the methods will want to add.w
With a Registry and some simple standards, adoption of authentication should quickly reach the tipping point. If more push is needed, still short of legal mandates, a small amount of funding for upgrades to the most popular MTA programs would help. These could be distributed via a central website with technical support.
Finally, if legal force is really needed, the regulation could be simple. Anyone who wants to operate a Public Mail Server must authenticate, by whatever method they chose, or maybe a list of approved methods. There isn't much opposition to authentication, just a lot of apathy. If they have to do it, they won't be fighting over details of the regulation. They will just pick the easiest method, install the upgrade, and get on with business.
=== End of File ===