-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Alex
van den
Bogaerdt
Sent: Friday, February 11, 2005 1:20 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Handling of -all
On Fri, Feb 11, 2005 at 10:49:51AM -0500, Scott Kitterman wrote:
I stand by my original comment: It is, IMHO, too soon to actually
start blocking based on what could very well be a simple mistake.
cheers,
alex
And that's your receiver policy. You are welcome to it, but
that's not what
I intended when I wrote my sender policy.
The beauty of the whole system is that if you reject during the SMTP
session, undesireable rejections will get reported back to the actual
originator of the message and things can get fixed. That's how progress
gets made. I don't have a strong preference for rejection or
delivery. The
one thing I would strongly object to is bouncing post-SMTP.
The problem of the early adopters is that your sender policy
combined with me blocking "your" message, will actually send
the message to the faked sender, not the real originator, when
a message is being relayed by
- a forwarder
- an ISPs outgoing mail relay
and maybe more.
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.
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).
If you reject it, and it came from a zombie, then it dies there. If it came
from a real, but forgery friendly SMTP server, then you are right, I'll get
the rejection notification. I'll also know where to complain too. IIRC, I
don't think I've ever gotten one of these. This scenario could happen.
This will always be true though. What will change in the future to remove
this risk. I think this is just an inherent risk of the system. If I
really wanted know bounces/rejections from forged e-mail, I'd set up my own
mail server and do SES. As it stands, since I've published a -all record,
bounces due to forgery have almost stopped (I don't think SPF is this
effective technically, I think that my personal spammers have mostly move on
because of the the -all record).
Scott K