"Frank Ellermann" commented:
Chris Haynes wrote:
SPF should not otherwise concern itself with the problems of
forwarding.
I'd still like a better answer for Hannah, and for Meng's idea
(local whitelist + SPF HELO PASS = bypass SPF) a separate text
defining best common practice maybe using an SPF modifier could
make sense. It's our job, Meng can't promote his idea, because
it's incompatible with "Sender ID".
I was too terse.
What I really intended to say was that the SPF protocol itself should not (need
to?) concern itself with forwarding.
Of course it is in the communities interests to be extremely helpful and
informative to people trying to solve their forwarding problems, both
individually and via BCPs.
Perhaps, in my attempt to give a robust, terse, unambiguous expression of what I
believe the SMTP architecture _requires_ in this situation, the tone of my
proposal is a bit 'Stalinist'.
( .. and I don't seriously expect the description of SRS as an 'abomination' to
pass through into an approved policy ;-))
Another point after further reflection (and it hurts me to point this out): I
suggested that forwarders could use an SRS-like scheme to encode the address to
which problem notifications could be sent, and I suggested that the 2822 Sender
is the address that should be thus used. When you work this through in detail
you realize that its the PRA algorithm you need to work out the correct address
to reply to. So we might start hearing that forwarders are signing M$ contracts
in order to build SPF-compatible forwarding :-((
Re: Hannah's problem.
I presume you refer to the mail whose time stamp (in my time zone) is
Sent: Monday, November 22, 2004 4:58 PM.
In that mail he says:
Semantically, for automatic forwards it makes more sense that the
original sender gets the error messages. For manual forwards, it makes
sense that the one who did the forward gets the error message. And the
current state of affairs reflects that.
and he then expresses the concern:
How do you deal with automatic forwarding? And with the bounce loop
described?
In my newly-thought-through position I would disagree with him that "the
original sender should get the error messages" where he procedes to equate this
error message with the bounce from the forwarded message.
Error messages about message 2 should be dealt with by the forwarder who
initiated that message. The problem is usually to do with a bad end-address. Now
that address was given to him by the end-recipient who has asked him to do the
forwarding. They have to sort out the problem between themselves.
The original sender knows nothing of the forwarding arrangement. And indeed,
the end-recipient may not wish the originator to know the forwarded address, for
privacy reasons.
I think the error handling should be done in two steps:
1) The forwarder who receives the 'bounce' should attempt to rectify the problem
himself.
2) If he cannot, he should send a _normal_ message (not a bounce) back to the
2822-Sender explaining the problem and (preferably) enclosing a copy of the
original (pre-forwarding) message, but not revealing any details of the
forwarding arrangements.
I hope this avoids the 'bounce loop' which Hanna was concerned about, but I've
not thought it through in detail.
Work remaing to be done:
- How are non-bounce DSNs to be handled when forwarding is in use?
Chris