spf-discuss
[Top] [All Lists]

Email Forwarder's Protocol ( EFP )

2005-02-21 16:54:37
The problem with forwarders seems to be a major stumbling block in getting authentication accepted. We need a simple standard for how forwarders should communicate the results of authentication tests to subsequent receivers. That standard should cover just the essential elements needed in any protocol, and leave room for each protocol to add its own information.

Since I can't find any work being done on this, I'm thinking of putting together a proposal for IETF. I think IETF might be the only body with sufficient respect and neutrality to get above the politics, and sufficient technical wisdom to avoid the petty debates that bog down so many efforts to agree on a standard. Here are the requirements for an "Email Forwarder's Protocol":

1) Each forwarder must independently authenticate its immediately connected sender, relying on the IP address in the SMTP session with that sender. 2) The results of the authentication must be pre-pended to the headers of the incoming mail, making it available for all subsequent receivers. 3) Neither the incoming headers nor the body of a message must be disturbed. We don't want to interfere with other protocols that might use a digital signature. 4) The syntax of the authentication header should be simple and well defined, even if that means introducing a whole new header that repeats information in existing headers. There may be a problem with all the currently allowed variations in Received: headers. 5) Bounces and rejects must go back the path they came, not to some header address that might be forged. 6) The protocol must allow for an arbitrary number of forwarders between the sender and the receiver.

Here is my proposed new header to meet these requirements:

Authenticate: SPF1 [<IP Address>] <senders-domain> PASS

The first word is the selected protocol. Next is the actual incoming IP address. Then we have the sender's domain name, determined by whatever method is used in the selected protocol. Finally, we have the results of the authentication test, using keywords defined in the selected protocol. After these four items, we could have any number of non-standardized parameters like a hash code or a time stamp. These might help the forwarder in processing a bounce, but are not needed by any other participant in the transfer.

Please see http://www.ece.arizona.edu/~edatools/etc/Email_Authentication_01.htm for a better explanation, including a diagram.

Comments and suggestions are welcome.  I am not an expert.

-- Dave


*************************************************************     *
* David MacQuigg, PhD              * email:  dmq at gain.com      *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your subscription, please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com