Pan-Am Internet Services

Designated Mailers Protocol FAQ

Courtesy of Steve Atkins, who frequently asked these questions.

Where's the Current Draft and Mailing List?

The current draft may be found here. The mailing list is hosted by and you may subscribe to the list here:

I've pretty much finished DMP's design. The mailing list should be geared toward implementations of the Protocol, but other discussions are encouraged.

Got source code?

Yes, but it's not tested to be thread-safe. The application used to generate the test information below may be downloaded. (51 KB) The archive includes source code.

The test application uses a function hacked from an older Winsock MX lookup example. There are better resolver libraries such as GNU ADNS.

Why Authenticate Outgoing E-mail?

From the DMP draft:

2. Why Identify Sending Hosts as well as Receiving Hosts

   You want to identify your outgoing SMTP hosts so you can effectively
   audit e-mail sent in the name of your domain.  While it is still
   possible to send authorized e-mail and still be abusive, it becomes
   far easier to audit the abuse and identify the senders.

DMP is about restoring accountability. As much as that might scare those who use anonymous re-mailers and similar resources, restoring accountability will do more to stop junk e-mail than any filtering technology.

A participating site can set terms for its use, including ensuring privacy. DMP only restores accountability per domain. It would then be up to the domain's administrators to enforce their own rules. DMP does allow for easier domain-wide blocking, however.

I've always worked to improve e-mail accountability. With accountability and strong terms of service, junk e-mailers either have to stop sending junk e-mail or risk being accountable for their abuse.

Why am I going to deploy it?

DMP lets you control who sends e-mail in the name of your domain. You will want to create DMP records to establish this control. You will want your mail servers to look up DMP records so you can refuse e-mail with forged envelopes, and save on bandwidth.

What's the advantage to me?

Testing with mail server log information spanning eighteen months suggests bandwidth savings of 20% or more. This could cut your costs by 1/5th. Bandwidth savings vary, and depend on the popularity of domains being forged.

You can also spare yourself the support e-mail and embarrassment coming from a third party sending junk e-mail, viruses, etc in your domain's name. You can at least be assured e-mail regarding your domain actually originated from one of your users or servers.

What's the advantage to the 'net at large?

SMTP needs replacing to prevent this kind of abuse, but DMP will support SMTP long enough to create a viable replacement. Servers and domains using DMP allow existing software to work while restoring e-mail accountability.

What will it break?

Earlier incarnations of DMP broke .forward - a mechanism to forward mail from one mailbox to another. The current incarnation no longer stops mail forwarded from another domain's mailbox. However, accountability shifts from the domain's administrators to the forwarder's administrators.

People operating Mail Transfer Agents from dynamic IPs are badly affected, but they have two workarounds. The first is to use a fixed IP MTA as a "smart host" and designate it as a sender for their domain. The second is to use dynamically generated DMP records, which could appear at the same time as the dynamic IP computer registers a new Address (A) record with its domain's DNS server. The former is simplest and works immediately, where the latter requires a DNS server capable of dynamically changing other records besides A RR records.

Aside from this, DMP does not "break" any other SMTP functionality. Null reverse paths (MAIL FROM:<>) are supported, forwarding is supported, sending mail on behalf of another is supported.

Why do the benefits exceed the breakage?

If the only "breakage" we're referring to is breaking dynamic IP MTAs, having a permanent fixed IP MTA as a relay solves a lot of auditing and resource problems. Chances are, you have a fixed IP mail server acting as a backup for your domain anyway.

There is also a matter of most Internet providers disallowing MTAs as part of their terms of service.

Even with this, the bandwidth savings alone justifies modifying the behaviour of a dynamic IP MTA, or providing dynamic DMP records for it. Being able to protect your domain against spoofing alone also outweighs the minor inconvenience of gating mail through a fixed server or providing a dynamic DMP record.

How does it scale?

Domains with more SMTP traffic will benefit more from DMP than domains with less traffic. Testing over nineteen-thousand domains over an eighteen month period (June 2002 to November 2003) showed an average increase in bandwidth of 4.15%, not including Time-to-live caching supported by most DNS server software, with roughly 33% of those domains only experiencing less than 1% of an increase. That increase also did not take into account the bandwidth saved by refusing forged e-mail.

With a typical TTL of 24 hours, a busy sender domain would only be queried directly once per day, per recipient domain and per sender IP, further improving these numbers.

Here are some of the more favourable numbers for some more popular domains, taken over an eighteen month period (June 2002 to November 2003). Again, these do not take TTL into account.

Domain          Msgsize     Dmpsize    Totalsize     PercentDiff     104283339     1923494     84708036     81.23%        98541811     1029857     89774170     91.10%   119297701     1621395     94342602     79.08%     101711       10792        55134     54.21%
              286849696     4948214    291797910    101.73%

This suggests savings from ten to twenty percent in bandwidth even with the bandwidth used for lookups with a correct set of DMP records. itself isn't forged often, if at all.

By comparison, a smaller domain with lower amounts of traffic will experience a higher bandwidth usage, with 63% of tested domains using 4.15% or less additional bandwidth. Given the infrequency of SMTP traffic, however, a smaller domain is not likely to feel this impact.

A copy of the database (18 MB - please mirror this!) in Microsoft Access 97 format, along with a copy of the DNS zone used in this testing, is available. Thanks to members of the IMS Users mailing list for gathering and supplying this information.

What responses will spammers make?

Junk e-mailers, not being able to send mail in the name of another's domain, will likely send mail in the name of a domain not yet registered, or in the name of a fictitious sub-domain of a popular domain, such as "" or some such thing. In an attempt to continue using insecure systems or trojaned systems, spammers may designate the entire Internet as a sender for such a domain. Recipients could then block by domain.

Systems using DMP can use other methods to verify if a sender domain exists. For example, a mail system can search the sender domain for Mail Exchange records (MX) since the domain has to be capable of receiving mail to receive Delivery Status Notification messages.

A domain using wildcard MX records (so mail to "" still goes to an mail server) can defend itself from "sub-domain spoofing" by inserting a wildcard DMP record alongside their wildcard MX records in their DNS zone:

* MX 50
* MX 100
* TXT "dmp="

This would identify all subdomains not explicitly defined under as being DMP participants. However, DMP-aware MTAs will then refuse mail from "" unless that host has an explicitly defined DMP record for its host and IP address, not very likely unless the spammer's hacked your DNS server to add it. All other DMP records will take precedence over this one.

Pan-Am Home Page