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 ....
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-
Alex