At 04:44 PM 2/18/2005 -0600, you wrote:
<http://advogato.org/article/816.html>http://advogato.org/article/816.html
I think apenwarr makes a good argument, but he says that SPF is only a
whitelist. It seems to me that SPF is a whitelist (+) and a beigelist (?)
and a greylist (~) and a blacklist (-).
This article seems like the same old emotional tirade we have been hearing
for a year. "SPF breaks the world!!" "It's incompatible with everything."
<http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-spf-is-harmful.html>http://homepages.tesco.net./~J.deBoynePollard/FGA/smtp-spf-is-harmful.html
The rhetoric is amazing, the techno-speak is mind boggling, but can anyone
understand the substance of the arguments? Why is it so hard to find a
simple explanation.
The only thing I have been able to pick out of it is there is a problem
with email forwarders. Here is my understanding of the problem, and a
simple solution. Am I missing something? Can it be this simple? Do we
really need something more complex, like SRS?
====
This is a picture of the key players in an email transaction when a
forwarder is involved. Normally authentication works directly between the
sender and receiver. The IP address on the incoming packets cannot be
faked, or they won't move across the Internet. To see if the message is
coming from the domain that it claims in its headers, that domain is sent
in a query to a DNS Server. That server queries lower-level servers until
it gets to the sender's DNS Server where it finds the records on what IP
addresses are allowed as senders for that domain. If the actual address on
the incoming packets matches the DNS records, the domain name is authentic.
+--- DNS Server <---+
| |
V |
author --> sender --> forwarder ----------> receiver --> recipient
^
|
spammer -----+
Use of a forwarder prevents the receiver from directly seeing the sender's
IP Address. The incoming IP packets have only the forwarder's IP
Address. You can stop the spammer from pretending to be the forwarder, but
what if he pretends to be the sender, and tries to fool the forwarder? Two
solutions are possible. Either you trust the forwarder to authenticate the
sender, or you trust the forwarder to at least accurately record the
incoming IP Address and pass it on, so you can do your own
authentication. This could be an added header in a simple, standard
format, easily parsed by a receiver, e.g.:
Verified: [<IP Address>] <senders-domain>
The placement of this header line is critical. It cannot be anywhere below
the forwarder's Received: line, as those lines could be forged by a
spammer. Forwarders must also be careful not to modify either the body of
the message or any header lines below their own Received: line. Such
modifications could interfere with authentication methods using digital
signatures.
Forwarders have one other responsibility, and that is to properly route the
bounce when a message is not accepted. These bounces must go back by the
same path they came, and not to some header address that may be
forged. The receiver must not alter the header information needed to route
the bounce. The forwarder must not alter the header information that it
originally received. This will allow for a series of forwarders to
properly route a bounce.
====
See http://en.wikipedia.org/wiki/Email_Authentication for a more complete
description.
-- Dave
-------
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