Proposed Government Regulations on Email Security
11 July 2005
These Regulations apply to all operators of Public Email Servers doing business in <this country> or any territories over which it has jurisdiction. A non-public server that connects with both related and unrelated parties is subject to these regulations only in sending to Unrelated Parties.
1) A Public Email Server is an MTA ( Mail Transfer Agent ) that sends or receives email by connecting with Unrelated Parties over the Public Internet.
2) Unrelated Parties include customers or other members of the general public, but not employees within one organization, or within a group of organizations that have a contractual relationship authorizing a deviation from these regulations.
3) An Administrative Domain may include any number of MTAs working together under a shared domain name, but not involving Unrelated Parties.
4) An Email Sender's Identity is a unique name in the DNS ( Domain Name System ), designating an organization or individual willing to assume responsibility for email from that domain.
5) The Public Internet is the world-wide network that shares a common set of IP addresses, not the internal networks within an organization.
1) Each Sending MTA, at the start of every mail-transfer session, and before any data transfer, must declare an Identity responsible for the transfer. The syntax for this declaration is shown in Exhibit A. Forwarding MTAs must also declare an Identity, even if they only forward messages from other MTAs.
2) Each owner of an Email Sender's Identity must provide a public Authentication Record allowing receivers to verify the authorization of any Sending MTA attempting to use that Identity. Mutliple methods may be provided, but at least one must be from the Approved Authentication Methods list in Exhibit B. The syntax of each record is defined by the method to which it applies.
3) Each owner of an Email Sender's Identity must maintain working email addresses - postmaster@<Identity> for technical problems, and abuse@<Identity> for abuse reports.
4) Each Receiving MTA, if accepting mail from the declared Identity, must verify that the Identity authorizes the Sending MTA to act as its Public Mail Sender. The Receiving MTA may chose any method offered by the Identity in its Authentication Record.
5) If a message is forwarded to an unrelated party, the forwarder must authenticate its sender, and prepend to the message the results of that authentication in a standard Authentication Header. The format and placement of this header is specified in Exhibit C.
6) A Forwarder must not alter either the incoming headers nor the body of a message. Prepending of headers is the standard.
7) Forwarders must be prepared, for at least 24 hours after forwarding a message, to accept abuse reports and bounce those reports to the immediately prior sender. The forwarder must ensure that the message was recently forwarded, and the bounce address has not been forged.
Forwarders who abide by these requirements should not be held responsible for the content of messages. Mailing lists and others that alter messages should be treated as new senders.
ID bigforwarder.com
SPF, SenderID, CSV
Note: Signature authentication methods are recommended in addtion to these IP-based authentication methods, but they are outside the scope of this regulation.
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 CSV 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.