5) If the message is forwarded, the results of authentication must be made
available to all subsequent Receiving MTAs. The format should be simple and
standardized to facilitate later blocking and filtering.
6) A Forwarder must not alter either the incoming headers nor the body of a
message. Prepending of headers is acceptable.
5b) Authentication results must be communicated as a separate header line,
the first header prepended to an email arriving at a Border MTA.
6a) A Forwarder that needs to alter a message must act as a new Originator,
using an Identity for which it is authorized. Handling of Delivery Status
Notifications and Spam Bounces is then at the Forwarder's sole discretion.
Authent: <IP Address> <Senders-ID> SPF1 PASS
This header is prepended by the Border MTA which first sees the message from <Senders-ID>. It appears just below the Received header from that same MTA. The order of these headers thus follows the exact order of events, authentication then reception.
All information appearing in an Authent header has been verified by the authenticating domain. None is hearsay.
SPF1 is the authentication method. UNVERIFIED means no authentication was attempted.
<IP Address> contains the sender's IP address. This is the minimum information which may appear in an authentication header.
<Senders-ID> is determined by the sender's declaration. NO-ID means there was no valid declaration.
PASS is the result of the authentication test, using a keyword defined by the selected method. Three of these keywords are standard for all methods – PASS, FAIL, and NEUTRAL.
After these four positional items, we could have any number of keyword=value pairs. These could be additional test results, or method-unique parameters like a hash code. These might help a forwarder in processing a bounce, but are not needed by any other participant in the transfer.
The order of the first four items is such that they always have the same position, even if not all are present. The <IP Address> is always present, even if the sender doesn't declare an ID. The <Senders ID> is present if the sender declares an ID, even if the receiver does not authenticate that ID.
Where there is a trust relationship between the sender and a forwarder, the forwarder can skip the authentication check and state the method as VOUCH. This does not mean the forwarder accepts responsibility for content, only that it accepts the normal responsibility of a forwarder for all information in the authentication header. If the sender provides a fake ID, it is still the forwarder's responsibility. The forwarder must trust that the sender has its servers under control, or it must do an authentication check using an accepted method.
Here are some typical headers, starting with the minimum possible information, and showing the use of various keywords.
Authent: <IP Address> NO-ID
Authent: <IP Address> <Senders-ID> UNVERIFIED
Authent: <IP Address> <Senders-ID> VOUCH
Authent: <IP Address> <Senders-ID> SPF1 PASS key1=value1 key2=value2 ...
See Scenario D in Spam Scenarios.htm for an example of how this header might be used.
Unlike Received headers, an authentication header is an affirmative statement – "I authenticated this ID, using this method, and got this result. Furthermore, the content of this email, and all the headers below this line are exactly as I received them." False information here is evidence of a serious problem, not just forgivable errors in processing a complex pile of headers. This will greatly reduce the administrative burden in deciding to downgrade an ID.
A simple standard format for authentication headers makes it easy for spam filters and reputation tools to skip past trusted forwarders and get straight to the ID that needs to be filtered or rated.
Two items in this header are a repeat of what is in a Received header. However, there is a benefit to having it one place, and no cost. The extra characters are not likely to require another line. The number and complexity of Received headers makes extracting these items difficult.
See [draft-kucherawy-sender-auth-header-01] for an alternative proposal.
Here are some typical headers, starting with the minimum possible information:
Authent: <IP Address> NO-ID
Sender didn't declare an ID, but we did capture his IP address.
Authent: 192.168.0.1 <Senders-ID> UNVERIFIED
Sender declared an ID, but receiver didn't check it.
Authent: 192.168.0.1 example.com VOUCH
Receiver is vouching for sender's ID. This may be common practice for forwarders hired by the sender.
Authent: 192.168.0.1 example.com SPF1 PASS key1=value1 key2=value2 ...
Receiver did an SPF check and got a PASS result. Additional key-value pairs are optional.
Authent: 192.168.0.1 example.com CSV1 PASS bounce=vcNAQEBBQADa
svc=S1:A,M2:A,H1:B
Receiver added a secret code to prevent bounce forgery, and ratings from three services on the domain example.com.
An authentication header must be placed by the Border MTA on all messages as they first come into an administrative domain. This must be the first header added within an administrative domain, and should be above all incoming headers and below all subsequently added headers.
Authent: 192.0.2.1 NO-ID (No record in Registry for example.com)
From: accounts@smithbarney.com
Warning: This message did not come directly from smithbarney.com
Authent: 192.168.0.1 pobox.com CSV1 PASS bounce=vcNAQEBBQADa svc=S1:A,M2:A,H1:B
Authent: 192.168.0.1 smithbarney.com SPF1 PASS svc=S1:A,M2:A,H1:B
I can see that my local MTA received the message from pobox.com. That's my own forwarder, and he received it directly from smithbarney.com. I trust pobox to do a proper SPF authentication, so I trust that the message really is from my broker, Smith Barney.
The warning appears whenever the From: domain differs from that in the first Authent: header. The MUA then lists all the Authent: headers in exactly the order they were received.
Generally, a bank or brokerage will not use forwarders on messages like this, so the only forwarder you are likely to see on a legitimate message will be your own.
Note: Even though this display is quite a bit simpler than the entire list of headers, we could simplify it further by dropping info not relevant to the "chain of trust" the user must see.
Authent: pobox.com CSV1 PASS
Authent: smithbarney.com SPF1 PASS
Implementation Notes: A nicely formatted pop-up display will have to be provided by the vendor of each MUA, but one thing we could do is run a simple script to extract the Authent headers and generate the above text block. This could be pre-pended to the message just before delivery, so it could be displayed by any MUA that can show the raw headers.
Another example from what appears to be a phishing scam (Warning and Authent lines added):
Date: Sat,
To: "" <dmquigg-august@yahoo.com>
From: "American Red Cross" AmericanRedCross@redcross-email.org
Warning: This
message did not come directly from redcross-email.org
Authent:
pobox.com CSV1 PASS
Authent:
advertising.com SPF1 PASS
Subject: Katrina Relief Update
Alternative to multiple Authent lines, depending on ID check:
Warning: Sender advertising.com offers no authentication.
Warning: Authenticated Sender advertising_.com, domain rating C(unknown)
Authenticated Sender: advertising.com (domain rating A - proven trustworthy)
It seems unlikely any bank or charity will want even the last header appearing on their emails. If their domain name is trusted, they will at least get their own IP address and authorize their own mailouts, using a name that matches their From line. Then the recipient will not be bothered by any strange warnings or Authent lines. If the recipient uses a forwarder, that line will be familiar, and not raise any suspicion about the sender. There could also be an option in the MUA to suppress warnings about the recipient's forwarder.