Seth Goodman wrote:
If there are cases where you can't control the MAIL FROM,
but at least know the MTAs sending mail with your 2822-From,
then PRA could be relevant.
[...]
The sender really should not be able to control MAIL FROM:.
No problem with that. It results in some mail sent with "my"
2822-From and a different MAIL FROM. Because nobody fixed a
matching Sender header PRA won't work for me. If it would be
really "my" 2822-From I could add the MSA in question to the
sender policy, and then PRA would work. But of course it's
not really "my" From, it's only a catch-all vanity host, and
so PRA doesn't work for me.
Unless I'd stop to use "my" 2822-From with this 3rd party MSA.
Or my MUA could add a Sender matching my MAIL FROM at this MSA.
Or this MSA could do it for me, after all RfC 2476 explicitly
says "MAY add a Sender". But nothing of this will happen, and
therefore I won't use PRA (as defined at the moment).
But in theory it's possible to make PRA work, and for users
where the PRA always matches the MAIL FROM (at the first hop)
the different scopes are irrelevant.
It's relevant for users controlling the sender policy of their
own domain. They could add the IPs of MSAs where they intend
to use their 2822-From (with a different MAIL FROM) to the PRA
scope. Hm... unless it's one of the 2476-MAY-add-Sender MSAs,
because then the Sender is the PRA, and that's not more their
domain, but only their user address at this MSA.
Okay, PRA is really weird. Let's hope that MARID somehow gets
rid of it. Skipping the forwarding stuff, as long as no third
parties (including the first hop recipient) use my MAIL FROM
they can do whatever they want.
Bye, Frank