On Sat, Sep 10, 2005 at 01:51:54PM +0200, David wrote:
The problem: forwarders abuse other people's names.
forwarders just do forwarding, they do not abuse anything.
According to "v=spf1 a -all" they do. That's what the policy
dictates.
A workaround: don't verify SPF when you receive a message from this
forwarder
yes, still, how do you know if the message comes from a forwarder or is
just a forgery ? in other words, this opens a big door for forgeries.
If the forwarder has address 172.16.1.2, and if you receive a message
from a connection from address 172.16.1.2, do not check SPF.
The operator of a mailserver (the provider) can make this configurable
per receiving mailbox. Yes, that's work to do.
The sender cannot know about forwarders (sometimes that's why a forward
is setup, to hide an address). Forwarders do know about themselves.
Receivers do know about their forwarders. From this you should be able
to understand why forwarders and/or receivers should setup a mechanism
and not senders. But there's more:
Consider this:
Receiver "R" at provider "P" doesn't want the world to know about
his address. He uses forwarder "F" and publishes that address to
the world. The setup at "P" is as follows: A receiving host "P1"
does some checking, then sends the message further to "P2" where users
can read those messages.
Sender "S" wants to contact "R". All he knows is address "R(_at_)F". He
sends a message to R(_at_)F, this is received (!) by F and then F sends a
new message to "R(_at_)P". Host P1 receives this message, checks for
spam/virus/other crap. P1 then tries to send this message to P2, but
this fails (for whatever reason).
Now, does P1 send the message "back" to "S" ? There are multiple problems:
#1 Maybe "P" is not well-connected. Maybe it's in blackholed IP space,
whatever. The problem is: this non-delivery-notification (NDN) cannot
be sent to "S" and the message gets lost. BAD.
#2 "S" didn't send a message to "P". It therefore doesn't accept NDNs
from "P". The NDN gets lost. Arguable but nevertheless bad.
#3 "S" doesn't understand which message cannot be delivered. There's not
enough information in the NDN to correlate the message to "F" and the
NDN from "P".
"Hello, this is P1. I tried to deliver your message to R(_at_)P but failed
to do so. Please try again later."
S's reaction: "Wtf? I didn't send to R(_at_)P". (consider the case where
both left-hand-side and right-hand-side are changed)
#4 "S" does understand that "R(_at_)F" and "R(_at_)P" are the same. Next time
"S"
will send directly to "P", something that defeats the purpose of setting
up forwarder "F".
"Hello, this is P1. I tried to deliver your message to R(_at_)P (original
recipient was R(_at_)F) but failed. Please try again later."
S's reaction: "Ah!!! So R's secret address is R(_at_)P(_dot_)"
As you can see, it is quite easy to come up with reasons why "F" should
not fake an originator address. If not for technical reasons, consider
at least #4 .
Alex
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
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