Definitions and Notes DRAFT 11-Jan-09
There is great confusion over terminology in discussions of email systems, even over the meaning of simple words like sender, receiver, and forwarder. Please see MHS Models for the definitions we use.
This is a DNS record providing information to authenticate an Identity used in an email. There are many such records,in different locations, using different syntax, depending on what authentication method the Identity owner offers. The record needed by the Registry of Internet Transmitters is a text record located at _auth.<Identity>, and is a supplement to, not a replacement for, other authentication records. Typically, Identity owners will use this record to let us know what methods they offer, and to tell us the IP addresses authorized to use their Identity in a HELO command.
A typical record might look like:
_auth.example.com. TXT "method=SPF,DKIM helo=192.168.92.16/30"
This tells us that the domain example.com offers authentication using methods SPF and DKIM, and that there is only one block of addresses authorized for use by Transmitters in that domain.
The Registry record derived from this _auth record might look like:
example.com.xmid.net. TXT "mth=spf+5,dkim+3 ip4=192.168.92.16-9 svc=X1:A,S2:A"
The Registry is located at xmid.net. The numbers attached to each method are the maximum number of DNS queries needed to run the method. The A ratings were obtained from services X1 and S2. See Registry Records for more.
Copy this block to put it in alphabetical order with the others. Then add your text.
Don't forget to edit the HTML in front of the heading above when you change the name from Sample. The name="Sample" attribute in the <a> tag needs to be changed to make the new heading available as a link target (bookmark).
- check links
- add more definitions
The Domain Name System (DNS) is a fast, reliable and secure way for domain owners to provide small chunks of information on their domain. They can publish whatever authentication data they want in various records on their own name server. We copy that information, validate it, add some data from rating services, and make the combined record available on our servers. Instead of numerous queries, hunting for whatever data might be available on a domain, the Registry does all that work up front, and provides the results in a single, convenient text record.
See Authentication Record and Registry Records for more details.
Let's say your mail server gets a request for an email session: HELO, this is mx1.open-mail.org connecting to you from 220.127.116.11. This is nothing but an unverified claim that the transmitter at IP Address 18.104.22.168 is authorized to send mail for the domain open-mail.org. Your mail server would then request the Registry record for open-mail.org. In less than a second, you get a response: "ip4=22.214.171.124-9 svc=X1:A,S2:A,H1:A". This tells you that the transmitter on the other end of the connection is authorized as claimed. It also tells you that open-mail.org has A ratings from services X1, S2, and H1.
Here is more complex example: HELO, this is mx17.dallas.texas.rr.com connecting to you from 126.96.36.199. Because rr.com sends a lot of mail, their record is already in your local cache:
This is a huge domain with 12 large blocks of IP addresses authorized to send mail from all over the planet. These blocks don't include the IP address that is attempting to send mail to us, so the name is probably a forgery. We can't reject the connection, however, because this is a default record (opt=df:6). RoadRunner does not have an explicit policy allowing us to reject forgeries, so we accept the mail, and run it through our spam filter.
The purpose of this default record is to allow most of the legitimate mail from rr.com to be authenticated, and give our recipients who will accept B-rated senders an opportunity to whitelist this domain. The mail that does not authenticate is not lost, it just has to go through the same gauntlet of IP blacklists and statistical filters as it would anyway. Spam zombies tend to have random IP addresses, and the chances of hitting even the large blocks above are very small, so the default record should be fairly good at separating zombies from legitimate senders.
This is the name used by a sender in the HELO command at the start of every email session. It is supposed to be the fully-qualified name of the machine requesting the connection. Many senders are not compliant with this Internet Standard. Our requirement is less strict than the standard. The HELO name must end in the domain name that is being used as the Sender's Identity. So "HELO this is hotmail.com" is OK with us, even if it is not the full name of the sending machine. "HELO this is Jupiter" is not OK. We will handle mail from Jupiter the same way as mail from any transmitter that refuses to identify itself.
Email is transferred over the Internet in small data packets, each of which has both the transmitter's and the receiver's numerical address. These Internet Protocol (IP) addresses must be correct, or the transfer will fail. That is what makes them so important in tracing the origin of an email. When an unknown sender requests a connection, saying HELO this is hotmail.com, but the IP address is not one of Hotmail's authorized addresses, the attempted forgery can be detected.
Public Email Transmitter
A Public Email Transmitter is an MTA ( Mail Transfer Agent ) that sends email by connecting with Unrelated Parties over the Public Internet. Unrelated Parties include anyone with whom there is no prior arrangement to exchange email. Reliable communications between Unrelated Parties is an essential feature of Internet mail. Preservation of this reliability is the essential goal of email authentication.
Our Email Sender's Identity is extracted from the rightmost parts of the HELO name which every MTA is required to send when it requests an email session with another MTA. Most MTAs will have their Sender's Identity at level 2 of their heloname, e.g. if the heloname is mta278.mail.mud.yahoo.com, the Sender's Identity is yahoo.com.
For some top level domains, like country codes .us and .uk, we keep records one level lower. So mta15.deq.pima.az.us would have its Sender's Identity recognized as 'pima.az.us'. The entire state of Arizona is too large to establish a useful reputation for email abuse. Pima County is a more realistic level of authority for this purpose.
Level 3 is as far down as we go for now. If the Department of Environmental Quality at deq.pima.az.us really must have an Identity separate from pima.az.us, it can simply make up a new name at level 3, maybe deq-pima.az.us. This is not a name the public sees, so it really doesn't matter if they change a dot to a dash. The tradeoff for a domain owner is getting a large enough mail flow to earn a solid reputation, but keeping the domain small enough that a security policy can be enforced for the whole domain.
In general, we will try to follow the delegation of authority recognized by the top-level-domain name servers. The servers for .us have no delegation to az.us, so we will not treat that as a Sender's ID. We do see a delegation of authority to tucson.az.us, however, so that is the name we will use as an ID for any hostname ending in that name.
Not all names in .us are delegated to level 3. 'mailsystem'.us is an example of a level-2 name in the .us registry. If the owner of mailsystem.us asserts his right to use that name as his Sender's Identity, then no level-3 names under that can be used as separate IDs.
There are many other identities related to email, and some have well-established authentication methods. Registry records include lists of methods offered by the sender, but the Registry does not favor any method over another. Receivers may chose any method the sender offers.
The Border is the interface between the last MTA on the Sender's side, and the first MTA on the Receiver's side of a mail transfer. There is one and only one Border in a normal mail transfer between unrelated parties on the open Internet. All MTA's should be related to one side or the other. Open Relays, associated with neither Sender nor Receiver are blacklisted.
Actors and Roles in a Typical Email System
|--- Sender's Network ---| |-------- Recipient's Network ---------|
Author ==> MSA/Transmitter --> / --> Receiver/Forwarder ~~> MDA ==> Recipient
Actors include Users and Agents. The system above has two Users and three Agents (a Sender, a Receiver, and an MDA (Mail Delivery Agent). The Sender plays the roles of MSA (Mail Submission Agent) and Transmitter. The Receiver also plays the role of Forwarder. The Border is the only place where the Agents in an exchange have no prior relationship. See MHS Models for more examples and discussion of these Mail Handling Systems.
MTA (Mail Transfer Agent) is a commonly-used term for a mail-handling program, not an Agent. A typical mail system involves mutliple MTAs for each Agent. We will use "Agent" to mean an individual or organization, and "MTA" to mean a machine, program or process.
Basic MTA functions include Submission, Transmission, Reception, Filtering, and Delivery. A Mail Submission Agent (MSA) provides a method to submit email (POP+SMTP, port 587, etc.), authenticates the Author, attaches headers, and prepares the message for its journey across the Internet. A Transmitter ( last MTA on the Sender's side of the Border ) has a special role in limiting spam and abuse in outgoing mail, and in ensuring valid identities associated with that mail. A Receiving MTA (the first MTA on the Receiver's side) has a special role in rejecting mail with forged identities. Filtering to reject spam is often done by a dedicated MTA running as a separate process on the same machine. The final hop is to a Mail Delivery Agent (MDA), which maintains user mailboxes, and offers various ways to access those boxes (POP, IMAP, Webmail).
Email security requires authenticating an Identity authorizing the Transmitter. Passwords and pre-arranged IP addresses work only between related MTAs. Authentication between unrelated MTAs across the Border between sending and receiving networks requires a public authentication method.
Authentication is a two-step process. First a claimed Identity is extracted either from the "envelope" information in the SMTP commands sent by the Transmitter, or from the "header" information in each message. Then the claimed Identity is checked against information in an Authentication Record. This information can be either the sender's Public Key, which can be used to verity a digital signature in the message, or a list of the sender's authorized transmitting addresses.
IP-based (SPF, SenderID, CSV, PTR)
- check the IP address of the transmitter
- fast, minimum mail-transfer overhead
- cryptographically verify the entire message including headers and body
- end-to-end protocol allows arbitrary forwarding
- high security
Envelope Addresses: (used by mail system)
Header Addresses: (for users' convenience)
The Helo Name identifies an MTA requesting a mail session. The identity of the Agent responsible for this session is usually the last few parts of the Helo Name. This should be a registered domain name.
HELO this is server7.dallas.texas.mailsystem.us
The Return Address identifies the Author of each message in the session.
I have mail from email@example.com
The From Address is how the author would like his address to be seen by the Recipient.
The Reply-To Address allows the author to designate a different address for replies.
Normally, the Return Address and the From Address are the same, and there is no Reply-To Address.
These are just the well-established identities. There are many others that might be used, but it may be difficult to establish their proper role in email authentication.
Some Email programs, like Eudora, don't have any way to set a separate Reply-To Address, and use the Return Address for that purpose. Many forwarders don't check the Return Address when they forward a message, allowing spammers to easily forge that address. Common practices like these are not forbidden by the standards, but do cause difficulties for authentication methods that try to correlate the Return Address with the Transmitter's IP address.
The name found in a PTR record by a "reverse DNS" lookup on an IP Address. These records are kept in a section of DNS controlled by network providers.