On Tue, Nov 14, 2006 at 02:08:50PM +0000, K.J. Petrie wrote:
Maybe if there were a little less heat and a little more light I could see
your point. Please explain the scenario which you think would cause bounces,
and I will see whether my proposal needs modifying. As you have already
experienced, I am quite prepared to change if someone can show me a good
reason for it.
The last week alone there have been several examples of how mail
will bounce, under what circumstances, why it happens, and more.
Different opinions on how SPF is involved, if bounces are or are
not caused by SPF, etc., but all agree: bounces do happen.
All, but one: you.
This topic has been discussed over and over again on this list for
the past several years.
How on earth do you think you can solve this problem, yet you deny
there is a problem in the first place?!?
You may not like the heat but IMHO you are causing it yourself.
But OK, here it comes, again:
Any system that is going to accept email, but is not the system
where a user will access his email (pop3, imap, mutt, and so on),
will try to deliver the message to "the next hop" (such as your
other address).
If delivery to this next hop fails, for whatever reason, the first
system is stuck with the message. It cannot deliver it to where
it thinks it belongs. So, it is going to send it back to what it
thinks is the sender.
Let's call this system a "forwarder". It receives mail sent to
"petrie(_at_)forwarder(_dot_)example".
Let's call the next hop "petrie(_at_)home(_dot_)address".
"forwarder" is going to send a message to "petrei(_at_)home(_dot_)address"
but this fails because >>petrie<< has made an error. Please do
pay attention to the (deliberate) typo I made in this address.
"forwarder" cannot deliver, thus sends the bounce message to
"victim_of_forgery(_at_)unrelated_domain_that_cannot_fix_petrie's_setup".
The problem is the forwarder, and fixes need to happen at the forwarder,
not at the next hop and also not at the original sending domain.
SPF is designed so that "forwarder" is no longer allowed to use
other people's names. Your proposal undo's this work. What you
want is that mail from "forwarder" is no longer SPF verified.
I tried to explain this to you before: if you take this to the
extreme, we will live in a world where every email address uses
a forwarder, and (should your proposal make it) all SPF checks
are overridden by RPF, meaning SPF is rendered useless.
Worse, as I also tried to explain before, RPF opens up a hole where
a spammer can create a scenario where RPF-receivers think the mail
is coming via a forwarder, and thus override SPF as well.
Overriding SPF is _not_ the solution. It is like sticking your head
in the sand, pretending the problem isn't there.
Forwarders not changing the way they operate should go away, just
like open relays are (mostly) gone. They may have been useful in
the past but are a hazzard in today's environment.
The only viable scenario is where a forwarder does check SPF itself,
rewrites the address, and sends the message to the next hop using
its own domain name. It does not need to use SRS, any protocol will
do as long as it is using its own address and as long as it will
receive and process bounces itself without risc of processing forged
bounces and relaying these to a victim.
Alex
-------
Sender Policy Framework: http://www.openspf.org/
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/?list_id=735