From: Alex van den Bogaerdt
[mailto:alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net]
Sent: Tuesday, September 13, 2005 8:58 PM
On Tue, Sep 13, 2005 at 04:47:58PM -0500, Seth Goodman wrote:
Sorry for the long quote, but this is relevant.
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.
Yes, that is the nature of email where forwarding is under the control of
the recipient. Conventional forwarding may not be an ideal method to
redirect email, but SPF was not conceived as a vehicle to advance that
agenda. In fact, if we tie SPF's fate to getting rid of conventional
forwarding, we might as well give up right now.
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.
This doesn't even make it to my list of things that would be nice to solve.
How many actual problems like this are you having? If someone sends mail to
China and their incoming MX rejects all mail from China, they are either not
interested in the reply or they will make arrangements to whitelist the
recipient. If the recipient uses forwarding, the sender must learn about
this and whitelist the forwarder, too. That's just common sense. This is
not a pressing problem that begs for a solution, it is a corner case created
by an overly restrictive local incoming policy. If the sender only blocked
known spam sources in China, there would be no problem. The problem is not
in forwarding, but in the poor choice of local incoming policy by the
sender.
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.
Permit me to rephrase my comment. If a receiving system has the ability to
be an SMTP server for hosts that it cannot reach through the internet as an
SMTP client, _and_ that receiving system accepts mail for delivery from the
SMTP client that it can't establish a reciprocal connection with, there will
be problems if it cannot make final delivery of the message. None of this
is the sender's problem. I don't think that the SPF community should even
concern itself with a system in such a predicament. The only likely cause
of this situation is that the recipient site is blacklisted and no one will
accept its outgoing mail. If you send mail to such systems, it should be no
surprise that you may reject any replies. In general, sending mail to
systems that can't send DSN's is not a good idea.
As I pointed out previously, the internet is fully connected, unlike in 1982
when RFC822 was written. Let's be reasonable and assume that hosts that can
receive mail can also send it. Another reasonable assumption is that a
packet can be routed from anywhere on the internet to anywhere else. If
local systems decide not to accept traffic from certain hosts, sites,
routes, ASN's, providers or geographic regions, that is a local policy
decision. Email authentication systems have no business trying to "fix"
what local sites do in their receiving policy.
[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?
I don't know all of anything! I think I do know that dropping legitimate
DSN's is poor policy, but sites that disagree are free to do so. That's a
local decision, just a bad one :)
Again, if the world was perfect, we wouldn't be having this discussion.
Nothing's perfect. Adopting a policy that will drop valid DSN's is more
imperfect that most, however.
#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 misunderstood the scenario, sorry. This problem is created by P sending
an inadequate DSN. If P included the original message it was bouncing,
there would be no question when it arrived at S. Recipients should send
enough information in a DSN for the sender to identify the message,
otherwise there is no point in sending a DSN at all. If they don't care
enough to send out reasonable DSN's, that's their problem, not the sender's.
<...>
What good is it if you receive a message saying "your message to
ab(_at_)example(_dot_)com" could not be delivered?
If that is a forwarded address and that is all that comes back, it is
obviously useless information. Too bad the recipient sent such a poor DSN.
The recipient must not care very much about their mail.
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.
That depends on what you send me in the DSN. If you send me enough
information, I can tell what message it was even a year later.
The point is: forwarder-old-style is bad, even without SPF.
Sorry, this list is to discuss SPF, not to criticize RFC821 and 2821. While
I agree that "forwarder-old-style" may not be the best system we could have
come up with, it is ubiquitous and it is not going away. If your goal is to
construct an argument that forwarding is bad and therefore SPF breaking
forwarding is really not a bad thing, I should point out that it is not in
the interest of the SPF community to adopt that agenda. As our chances of
forcing a change to longstanding forwarding practice are between slim and
none, we would doom SPF to failure.
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.
I can only repeat that this is a separate issue. Forwarding is part of
email today, whether we like it or not. None of us can really do anything
about that. Demanding that the world adopt SRS, or discover and whitelist
all of their forwarders, has been the single biggest adoption hurdle for
SPF. It is, IMHO, a much bigger problem than SID and the political problems
inside the IETF. I suggest that if forwarders, by and large, had indicated
even a meager level of willingness to adopt SRS, SPF would already be a de
facto standard. The fact that most forwarders have, in fact, resisted
adopting SRS, shows that our taking the position that changes to existing
forwarding practice are _required_ would be a serious mistake.
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.
That depends on your definition of "solved". I personally don't see a
system that rejects my forwards unless I explicitly whitelist them as a
"solution". I consider it a problem.
--
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