David MacQuigg
The email authentication method QR1 is intended to be used by mail-transfer agents ( MTA's ) for a quick reject of forgeries without any transfer of data. Its focus is on minimizing email loads and defending the infrastructure of the Internet, not on 100% reliable authentication. It is designed from the start to be a supplement to other methods. The examples will show how QR1 fits into a typical setup using multiple methods. See draft-authent-IOP-00.htm for more discussion of Inter-Operability and of the fundamental requirements that this method is attempting to meet.
To minimize the number of DNS queries per transfer, QR1 uses a general-purpose record format that will accommodate all methods. That will allow consolidation of DNS information, not only within a domain, but between a domain and its rating services. In most cases, one query will provide all needed information for an entire domain, and that information may be cached by an MTA to avoid further queries on that same domain. This is the way DNS was intended to operate, and the way it can support email authentication without an upgrade to DNS servers worldwide. It is also a good way to avoid any temptation to involve DNS in a Denial-of-Service attack.
The detailed and frequently changing information in an authentication record is normally maintained by each domain, and published using name servers under its control. The rating information, however, must be kept on name servers under the control of the rating services. To avoid two queries from each MTA, rating services should work out efficient procedures for maintaining all information under their own control. For example, the domain could create the initial record, including which rating services it recommends, and publish it in a TXT record at _AUTH.<domain>. The rating services, periodically or on request, could query that record, insert their own ratings, and re-publish the complete record at a place like _AUTH.<domain>.<service>.
Taking this one step further, the entire industry should cooperate in publishing unified authentication records at a place like _AUTH.<domain>.mail. This will avoid duplicate records at the various services, "hunting" to find which services have records on an email identity, and delays while the services query each other for information needed to keep every record up to date. Industry cooperation on a common "one-query" email authentication service could provide the ultimate minimum load on MTA's, the DNS, and the worldwide email system.
In the examples below, we may assume DNS records at any of the
locations above, but the method should work regardless of where the records are
kept.
We propose a general syntax for a "top record" that may be used with any authentication method or domain-rating service. Each method or service may define its own names, syntax, and DNS records, without having to change the syntax of the top-record. The only restriction is that names must be unique within the top record. We cannot have two methods claiming to be SPF1, or a service with the same name as a method.
These are set up as TXT records in the subdomain _AUTH.<domain>, so no new query type is needed, and there is no conflict with other TXT records sharing the same limited space in a DNS packet.
One query to _AUTH.<domain>.mail gets all the authentication information for a domain in summary form, including a list of accreditation services and their ratings of the domain, a list of authentication methods the domain uses, and as many parameters as can be squeezed into approximately 450 bytes, a limit imposed by the 512-byte DNS response format. Links to additional records are provided if necessary.
Here is an example of a 349-byte authentication record for a
large, complex domain, with many subdomains and hundreds of servers all over
the
The record has been formatted here for easy viewing, but in DNS, folding white space would be removed.
svc=S1:A,M2:A,H1+:B dmn=QR1,SPF1+5,DK2
QR1=ip4:?170(24.30.23;24.28.200;24.28.204;24.30.18;24.93.47;24.25.9),
+4(65.24.5.120;24.94.166.28;24.29.109.84;66.75.162.68;24.24.2.12)
DK2=dk:MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAKJ2lzDLZ8XlVambQfMXn3LRGKOD5
o6lMIgulclWjZwP56LRqdg5ZX15bhc/GsvW8xW/R5Sh1NnkJNyL/cqY1a+GzzL47t7
EXzVc+nRLWT1kwTvFNGIoAUsFUq+J6+OprwIDAQAB
Names defined so far include svc for service data, and dmn for domain data. Names starting with x- may be used for experiments. Unknown names should be ignored to allow for later upgrades. These names may be used in name-value pairs if they appear first as a value. Thus QR1 in the dmn list may be used later in the record.
Well-known services have short names, like S1. Others may be listed with a fully-qualified domain name <FQDN>. A query to <domain>.S1.mail or <domain>.<FQDN> returns the rating for that domain by that service. Normally, these extra queries aren't necessary, because the summary above is adequate.
The example domain has A ratings from two services, and a B rating from a third. Service H1 provides one additional record at _H1.<domain>.<service>, probably some notes on the reasons for the B rating, status of cleanup efforts, etc.
This domain uses 3 authentication methods, QR1, SPF1 and DK2. These should be executed in the sequence shown. Parameters for each method are given later in the record, or (if a + follows the method name) in additional records. The SPF1 method in the record above has no parameters within the record, but the +5 after SPF1 means that additional records are available, starting with a query to _SPF1.<domain>, and requiring no more than 5 queries to complete.
The first method QR1 offers a Quick Reject of any IP address outside the specified IP blocks. QR1 will reject the vast majority of forgeries that do not have an IP address anywhere "close" to an authorized address for the domain. If the IP is within one of the blocks, the result is NEUTRAL or PASS, depending on the ? or + in front of the block. NEUTRAL over-rides the initial presumption of FAIL, and PASS over-rides NEUTRAL A NEUTRAL from the entire QR1 test can be over-ridden by a PASS or FAIL from a later test.
In the record above, we see that this domain has isolated its Public Mail Servers to 6 blocks of 170 IPs each and 5 blocks of 4 IPs each. All 4 of the addresses in each of the small blocks are authorized to send mail. These might be small offices around the country with one mail server and a backup. The 6 large blocks might be racks of servers for outgoing customer emails. Not all of the 170 addresses in each block are allowed, hence the ? and the later SPF1 test.
The blocks of 170 IPs could be as large as 256 without changing the starting addresses, but this domain owner chose to exclude the last part of each IP block. This allows those excluded IPs to be allocated to customers without risking the domain's reputation.
For many simple domains, QR1 can be the sole IP authentication method. In the example above, the tradeoff is between a simple test with only one query, vs being able to specify in much more detail which addresses are authorized servers.
The second method SPF1 is described in draft-schlitt-spf-classic-00.
The third and final method DK2 has one parameter dk, a 768-bit "DomainKey", which is completely specified in this record.
Domains setting up their authentication records should specify at least one simple method first. Not all forwarders and receivers will implement all methods.
Domains should minimize the number of DNS queries generated by their authentication requirements. MTA's that are heavily loaded may temporarily reject messages that don't PASS with one DNS query, or they may forward the message with less than a PASS authentication result.
Encoded values are Base64, 6 bits per printable character. Compiled records like the above should never be edited directly. There is too much chance of error. Tools are provided for each method that will convert to and from the compiled format and a simple user-friendly format.
A query to a rating service should get a standardized response. One possible standard is detailed in draft-ietf-marid-csv-dna-02. The ratings
A, B, etc. could have the meanings defined in that draft. One of the ratings, maybe "C"
should have a special meaning "unknown". This will allow rating services to avoid listing
large numbers of spammer-generated domain names.
This section is normative, and any discrepancies with the ABNF fragments in the preceding text are to be resolved in favor of this grammar.
See [RFC2234] for ABNF notation. Please note that as per this ABNF definition, literal text strings (those in quotes) are case-insensitive. Hence, "ip4" matches "ip4", "IP4", "iP4" and "Ip4".
For work-in-progress see draft-qr1-syntax.htm
QR1 is based on the "masks" idea proposed by Radu Hociung in the spf-discuss mailing list, March 2005.
The universal standard query to _AUTH.<identity>.mail is based on the proposal by http://www.spamhaus.org/tld for a top-level .mail domain.
--- End of File