On Fri, Feb 11, 2005 at 01:43:46PM -0500, Scott Kitterman wrote:
Example:
-1- bad(_at_)badguy(_dot_)example(_dot_)com pretends to be
good(_at_)goodguy(_dot_)example(_dot_)org
message is sent to someone(_at_)forwarder(_dot_)example(_dot_)net and no
SPF is
checked.
-2- forwarder.example.net sends the message to
someone(_at_)other(_dot_)example(_dot_)net
and pretends to be good(_at_)goodguy(_dot_)example(_dot_)org
-3- other.example.net does check SPF, finds a -all and rejects.
forwarder.example.net bounces the message to ....
Wouldn't be a problem if you followed the suggestion that I posted in my
first message in this thread:
"SPF verifiers MUST only check SPF at the boundary of the receiver's
network. Since forwarding is under control of the reciever, not the sender,
the forwarder is the boundary. SPF verifiers should whitelist known non-SRS
forwarders (using trusted-forwarder.org or some local policy)."
In this case, you should not be checking SPF against that message when you
receive it. It has to be done at the boundary.
"you" and "the one in control" are not the same. Suppose hotmail
would do SPF checking (not sure if they do but for argument's sake
let's assume they do please) then how am I going to convince them
to make an exception ? Maybe in time, when your proposal makes it
as an RFC, they do implement it. Until then: No chance.
I shouldn't be forwarding to hotmail in this case. Fine. Do you
really think everybody knows that?
The forwarder shouldn't be using _your_ name as sender. _That_ is
what your policy describes. I don't think you are correct when you
say the path between the forwarder and the final recipient is an
"internal" path (which is what you are describing). The difference
is that internal forwarding, such as is often happening at providers
and/or companies, is under control of one entity/group whereas this
is not the case with forwarders.
Of course, the ISP where the forwarder lives should be checking
SPF and then this problem goes away. For now, we have to live
with the fact that this is not yet the case.
Example 2:
-1- bad(_at_)badguy(_dot_)example(_dot_)com pretends to be
good(_at_)goodguy(_dot_)example(_dot_)org
and connects its machine to some dial-this-expensive-number-and-
get-ip-connectivity provider. It sends its spam to the SMTP
gateway of this provider. No spf checking is done.
-2- This provider tries sending the message, using
good(_at_)goodguy(_dot_)example(_dot_)org as sender address.
Reject, bounce, see -3-
But reject and bounce have two different affects. If you bounce it, that's
bad. If you can't deal with it during the SMTP session, then you have to
deliver it (even if to a spam folder).
It is the middle man bouncing here.
A is the real sender at home, B is the dial up ISP, C checks SPF
and rejects, D is the victim because B bounces the message.
A--->B--x-->C
B--->D
Are you implying that B should deliver undeliverable mail to
a local spam folder ?
cheers,
alex