From: Alex van den Bogaerdt
[mailto:alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net]
Sent: Saturday, September 10, 2005 7:23 AM
<...>
I don't agree with the scheme that David posted, but I'm more concerned with
this list of required functions that don't even exist today. In evaluating
any authentication scheme, some of the things listed below are not good
benchmark requirements.
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
cannot send bounce messages back through the internet, it has no business
accepting responsibility for delivering messages as a gateway for another
transport environment. The internet has been fully interconnected for a
number of years. I don't buy the argument of poor connectivity of a
destination gateway MTA. That may have been the case in 1982 when RFC822
was written, but it not anymore.
#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.
Not really arguable. If P accepts a message and the final recipient's
mailbox is over quota for a long time, it will indeed send a bounce message
back to S. Unless P is blacklisted or has a poor reputation, S will accept
the DSN. The same could actually happen to F. Incoming and outgoing
blacklists are generally not the same, and certainly vary over time, so S
might happily send mail to F but refuse to accept a DSN from F at a later
time. No system today can only accept DSN's from hosts that it directly
sent mail to, since forwarding is under the control of the recipient.
Anyone who does that is knowingly dropping DSN's.
#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?
"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?
#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_)"
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.
--
Seth Goodman
-------
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