On Tuesday 14 November 2006 15:43, Alex van den Bogaerdt wrote:
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.
I'm not denying bounces happen. Just can't see how what I propose would cause
them.
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?!?
Which problem am I denying?
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.
Yes, but the typo means my ISP won't recognise it as bound for my mailbox, and
therefore won't apply the policies I have set on my mailbox, so the SPF check
will continue as before, and the mail will be rejected according to the ISP's
standard SPF policy.
"forwarder" cannot deliver, thus sends the bounce message to
"victim_of_forgery(_at_)unrelated_domain_that_cannot_fix_petrie's_setup".
True, but if I weren't using a forwarder, the sending MTA (which obviously
hasn't done an SPF check either) would have bounced it. So how is what I'm
proposing generating more bounces than would happen anyway?
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.
What difference has the forwarder made? As I said above, the sending MTA has
not SPF checked the mail, so would bounce it anyway. That's the only place an
SPF-based reject won't produce a bounce. It's also where the forger gets no
doubt s/he's going nowhere.
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.
If that is a design feature of SPF, what use is it? If the forwarder performs
SRS, all messages will pass SPF, even the forged ones. If the forwarder does
not, all messages (for which SPF has been set up) will fail. Neither of these
detects the forgeries. So it's pointless doing an SPF check at that stage. Of
course, if the forwarder has set up SRS, we might hope they would set up SPF
on their incoming mail as well, but there's no guarantee. Even if they do,
the mail will just be bounced by the previous hop, as described above.
So this doesn't seem to be a useful feature, and I'm inclined to suspect it's
more likely to be an unwanted side effect, for which SRS was devised as a
workaround. But it's not the best solution. If the MAIL FROM: wasn't forged
before SRS, it will be after, if forgery is viewed as changing what the
originator intended rather than preserving it! More seriously, it expects
someone who is free not to implement SPF, and therefore is not covered by the
standard, to fix an incompatibility introduced by the adoption of SFP
elsewhere. That's a pretty daft expectation in a voluntary standard. It's
simply not realistic.
The SPF standard (section 9.5) suggests that SPF should not be performed on
internal transfers, and I would argue that, since my MX record points to the
forwarder, anything beyond that is, for Domain (and therefore SPF) purposes,
internal. I just need a means of applying that SPF "internal" concept to a
real-world forwarding situation. I want the means to comply with the
standard. Then the forwarding issue would not arise.
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.
But I abandoned the RPF concept many posts ago. My current proposal is to
replace the final sentence of 9.3.3 with:
"In such cases, whitelists of generally-recognized forwarding services could
be employed, or users could be provided with facilities to manage the inbound
SPF policies on their own mailboxes. If a user's policies mean mail will be
treated the same irrespective of the SPF result, the domain owner may choose
to save overhead by not running check_hosts for mail bound for that account."
Some have argued whitelists are dangerous, so maybe the reference to them
could be deleted if people think my proposal is better, but I'm not in the
best position to judge the merits of that.
Are we at crossed purposes? Have you missed my current proposal?
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.
ditto
Overriding SPF is _not_ the solution. It is like sticking your head
in the sand, pretending the problem isn't there.
Complying with the standard is not overriding SPF. In any case, why should
anyone else tell me what mail to accept? What I accept is my business. It
doesn't affect anyone else.
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.
Possibly.
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.
Personally, if someone is defaming my domain, I like to know. But the
experience of over 300 bounced messages in my mailbox one morning wasn't a
pleasant one, and it's what caused me to seek out SPF in the first place. I
just think people are more likely to adopt SPF if they are in total control
of it, and the current SPF/SRS mix doesn't put the user (whether MTA, MUA
[sorry I muddled that with MRU in an earlier post] or domain owner) in full
control, and that creates a barrier to adopting it.
I hope this answers your concerns. I really can't see how my proposal would
cause any of the problems you raise, and I think I've answered everything
fairly thoroughly, as you deserve. If there is anything I've missed, or
you're unsure of, please let me know, and I'll be happy to consider it again.
KJP
-------
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