Mark Lentczner wrote:
To recap --
1) There is concern that since the proposed use of SPF format records
is changing from envelope MAIL FROM checking to PRA checking, that the
difference in semantics might cause problems for some domains: Older
implementations of SPF will use records intended for PRA against
envelope MAIL FROM; Newer implementations will use older records
intended for envelope MAIL FROM against PRA.
2) The 'null' mechanism is a very simple and clean solution to the
first of these to problems.
3) While one can construct cases that show the technical difference in
the semantics, I still cannot find one that demonstrates a practical
need for distinguishing a host between them.
Maybe I've found a case where this is very important: me ;-)
At the moment I use From: nobody(_at_)xyzzy(_dot_)claranet(_dot_)de everywhere.
Including the trivial case where I submit my mail at clara.net
with a corresponding MAIL FROM:<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
Please note that xyzzy.claranet.de is a vanity host, it has a
simple "v=spf1 redirect=claranet.de" sender policy, and I'm
not in the position to modify this (wildcard) policy.
I also use other providers with the same From: address. In
fact I and my MUA don't know which MSA I'll use at the moment
when I write a message. The outbound mail waits in a file
"outbound" until I start "send now". And then my MUA uses a
MAIL FROM corresponding to the selected provider, but it does
_not_ add a Sender: header.
Actually my 2nd SMTP provider insists on a correct MAIL FROM:
<me(_at_)2nd(_dot_)provider(_dot_)example> like any well behaved MSA. It won't
modify my message in any way, it does _not_ add a Sender:.
Now if I've understood [Sender-Id] correctly the recipient
tries to find a Sender: in step 3, and a From: in step 4, and
this results in From: nobody(_at_)xyzzy(_dot_)claranet(_dot_)de with an IP of
2nd.provider.example => Sender-Id FAIL.
In theory you could say that my MUA or the MSA should add a
Sender: header reflecting MAIL FROM:<me(_at_)2nd(_dot_)provider(_dot_)example>.
But in practice this won't happen (my MUA is old, and the MSA
isn't interested in MARID oddities, it's already good enough
that it enforces a MAIL FROM matching the identified user).
Why is the PRA determined by the 2822 From: address in step 4
instead of the existing and valid MAIL FROM ? For recipients
trying to be compatible with classic SPF and RfC 2476 that
could be an obvious solution, use MAIL FROM as default Sender:
Bye, Frank