On Tue, Sep 13, 2005 at 04:47:58PM -0500, Seth Goodman wrote:
Let's compare this as it is today, without SPF. That's how 99.9% of the
recipients operate, so it is what we have to compare any argument of loss of
function.
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.
Today, if P is well-connected enough to get the message from F, they can
send a bounce back to S. In fact, that's exactly how it works today. If P
F can be setup just to circumvent problems at P. Or maybe P is in china,
and the original sender will never send to china because it knows it will
not allow china to send back. Does the forwarder know? No. But it is
the forwarder telling the final recipient to send messages back to the
original sender. It is thus the forwarder causing the problem.
Note that this problem can also occur as a result of internal forwarding.
Too bad, we're not solving every problem in the world here.
cannot send bounce messages back through the internet, it has no business
accepting responsibility for delivering messages as a gateway for another
transport environment.
If the world was perfect, we weren't talking on spf-discuss.
[snip]
Anyone who does that is knowingly dropping DSN's.
Anyone receiving thousands of fake DSNs at least considers it at one point.
And people try to fight the problem. Some choose SES or similar, others
make other choices. You know them all?
Again, if the world was perfect, we wouldn't be having this discussion.
#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".
DSN's go back to the return-path. If the return-path is non-functional,
who's problem is that?
Why do you talk about non-functional return paths? I certainly didn't here.
I'm talking about a pointless message, not providing information. This
message is then sent to the return path. It is received so the return path
obviously works.
"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)
Senders don't generally keep track of the state of each message delivery.
In processing a DSN, the sender doesn't know if the local address in the
return-path actually sent a message to P or not. In today's world where
forwarding is not under the sender's control, what good would that do
anyway?
What good is it if you receive a message saying "your message to
ab(_at_)example(_dot_)com"
could not be delivered? Would you be able to correlate your message (sent to
alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net) and the return address >>after
it was modified by my
forwarder<< ? Maybe if you send a message or two a day. Otherwise: no.
The point is: forwarder-old-style is bad, even without SPF.
S's reaction: "Ah!!! So R's secret address is R(_at_)P(_dot_)"
Yes, that's exactly what happens today, every time a "secret" recipient
address rejects a message that was forwarded. Conventional forwarding
destroys this anonymity by precisely this mechanism. If you need a truly
secret address, you need to do something other than conventional forwarding.
Indeed. The point is: forwarder-old-style is bad, even without SPF.
Now add SPF in the mix, where a domain owner explicitly forbids the use of
his name. The problem doesn't get worse. It just becomes more clear and
becomes, in certain cases (-all), even less. If that receiver at P does
check SPF records it will not accept the message. Problem solved.
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