Courtesy of Steve Atkins, who frequently asked these questions.
The current draft may be found here. The mailing list is hosted by spamresource.com and you may subscribe to the list here: http://www.spamresource.com/mailman/listinfo/dmp.
I've pretty much finished DMP's design. The mailing list should be geared toward implementations of the Protocol, but other discussions are encouraged.
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.
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.
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.
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.
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.
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.
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.
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 yahoo.com 104283339 1923494 84708036 81.23% aol.com 98541811 1029857 89774170 91.10% hotmail.com 119297701 1621395 94342602 79.08% yahoo.com.tw 101711 10792 55134 54.21% returns.groups.yahoo.com 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. returns.groups.yahoo.com 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.
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 "spammerdomain.hotmail.com" 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 "infabulated.gonkulator.example.com" still goes to an example.com mail server) can defend itself from "sub-domain spoofing" by inserting a wildcard DMP record alongside their wildcard MX records in their DNS zone:
$ORIGIN example.com. * MX 50 server1.example.com. * MX 100 server2.otherdomain.example.com. * TXT "dmp="
This would identify all subdomains not explicitly defined under example.com as being DMP participants. However, DMP-aware MTAs will then refuse mail from "infabulated.gonkulator.example.com" 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.