DNSxL Email Authentication Method Extension

One of the many checks that mail servers carry out is to query DNS white and black lists (DNSxL, ). The semantics of DNSWL is similar to that of Vouch By Reference (VBR, ); that is, an external organization, trusted by the receiving mail transfer agent (MTA), vouches for the sender. Differently from VBR, the lookup is based on the IP address. That allows it to occur very early in an SMTP transaction, and thus it can be used to counterweight policies that typically occur at those early stages too, such as the Sender Policy Framework (SPF, ). Nevertheless, the result of a DNSWL lookup is likely used at later stages as well; for example, a delivery agent can use it to estimate the spamminess of an email message. Reusing the previously obtained result is more consistent than issuing multiple queries, and saves resources. The semantics of DNSBL often implies blocking any attempt to send mail, or even outright blocking any routing or peering from listed addresses. However, in some cases mail is accepted despite a positive blacklist lookup. In such cases, it is useful to record the result of the lookup, which can be done symmetrically, using the method described in this document.

In this document, the acronyms DNSWL and DNSBL are used both to refer to a generic organization that publishes a DNS list, and to indicate the list itself. The organization defines the DNS zone and the record type(s) to be queried, as well as the meaning of the listings and the procedures to maintain them. DNSxL is used to indicate either or both those two, while dnsxl (lowercase) is the name of the method being defined here. As explained in "Combined IP Address DNSxL" (Section 2.3 of ), DNSxLs encode taxonomical details about the mail sender as bit masks of type A records. The receiving MTA needs to determine whether the data returned is applicable. In that case, it uses a uniformized rendering of that data as an outsourced extension of its local policy. The properties, uniform across DNSxLs, that this document provides for are listed below: The name of the DNSxL, where the result is obtained from. This is a number in the range [-100, 100]. Zero (0.0) is for neutral, non-listed senders. Positive values are for black lists. Negative values are for white lists, with meaning roughly defined as: only avoid outright blocking (e.g. free mail providers), reduce chance of false positives, make sure to avoid false positives but allow override for clear cases, highly trusted sender, avoid override. This is either a domain name or an abuse reporting address, which can be used as described in "Where to Send Reports" (Section 5.3 of ). The result proper of the dnsxl method is defined as follows: A query to a DNSWL completed, and a reply was returned, meaning the IP address is whitelisted. A query to a DNSBL completed, and a reply was returned, meaning the IP is blacklisted. A query to a DNSBL completed, and a reply containing no answers was returned, meaning the IP is not listed. The DNS evaluation could not be completed due to some error that is likely transient in nature, such as a temporary DNS error, e.g., a DNS RCODE of 2, commonly known as SERVFAIL, or other error condition resulted. A later attempt might produce a final result. The DNS evaluation could not be completed because of some kind of misconfiguration, e.g., a DNS RCODE of 3, commonly known as NXDOMAIN. A later attempt is unlikely to produce a final result.

There is a registry of Email Authentication Methods created by RFC5451. The method described in this document is referred by , it has three ptype.Property values detailed in .

Method Defined version dnsxl [this rfc] 1 ptype Property Value Status policy dnszone The origin of the results active policy score sender trustworthiness active policy contact abuse reporting active In addition, this method reuses five of the values already defined in the Email Authentication Result Names associated registry. They are listed in .

Code Meaning Status pass active fail active neutral active temperror active permerror active Finally, if at all possible, this document reserves the name dnswl, as detailed in . Method Defined version Status dnswl [this rfc] 1 reserved

[Note to RFC Editor: please remove this entire section before publication.] This section records the status of a known implementation of the method described in this document at the time of writing, based on a proposal described in "Improving Awareness of Running Code: The Implementation Status Section" (). See that document for further boilerplate that should have been copied here. OpenDKIM has optional DNSxL query support, and plans to implement this. Courier-MTA is a full-featured, mature mail server, first publicly released in May 2000. A beta release in February 2013 introduced Authentication-Results in combination with DNS-based whitelists. It made it to production in release 0.71, after one month testing, using the reserved method name. End-user documentation of that feature is available online at http://www.courier-mta.org/couriertcpd.html#idp5867072 In prior releases, only the -block option was present, and the Authentication-Results header field was handled by add-ons, not by the core implementation. The -allow option was added so that black and white lists can be configured using mostly symmetrical syntax. Finally, an option was added to inhibit SPF reject-on-fail for whitelisted senders. It is not possible to know how many installations of Courier-MTA have enabled these new features. However, no questions have been asked about them on the mailing list, yet. Despite the amount of spam, there seems to be little traction for this kind of development. The only DNSWL known to have been used for this purpose is dnswl.org. See http://www.dnswl.org/. With nearly 150K entries, it can make the email messages that get at least one authentication "pass" overreach a critical mass: It seems that subscribing to that list is easier, for some mail admins, than implementing other authentication methods.

All of the considerations described in Section 8 of apply. In addition, the usual caveats apply about importing text from external online sources. Although queried DNSWLs are well known, trusted entities, it is suggested that TXT records be reported only if, upon inspection, their content is deemed actually actionable.