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