Graham Murray wrote:
In these circumstances, would it not be possible for the MUA
to add the Sender: header before passing the mail to the MSA?
Yes. But unfortuately my MUA doesn't know that I created the
outbound mail (waiting in file "outbox") with "my" 2822-From
for my favourite ISP. In theory the MUA could add a matching
Sender, same procedure as at the MSA. But in practice nobody
does it, probably because the different MAIL FROM is obvious.
Now I'm really guessing: The implementor of the MSA software
never considered it, because it's only a MAY in RfC 2476, and
as you said the MUA could do it. Don't touch the DATA in a
mail unless it's really necessary. Adding an almost redundant
Sender is not really necessary, and if you try to do it, what
about mail with an existing Sender header ? Check it and
maybe reject it, you can't have two Sender headers. Too much
trouble for the MSA.
For the implementor of my MUA (Mozilla 3, about 1996) it was
also irrelevant, really different users would use different
"outbox" files. One user with one "outbox" for more than one
mail provider wasn't in the specification. And otherwise the
problems are exactly the same as for the MSA.
Or is the problem that you do not know which MSA will be used
(and hence what the Sender: header should contain) at the
time you compose the mail?
Yes, I don't know which MSA will be used. It's either the MTA
of my ISP, and then the RHS of the MAIL FROM matches the RHS
of the 2822-From, complete with v=spf1 sender policy. Or it's
the MSA of hamburg.de, and then there's no Sender matching the
MAIL FROM:<m-e(_at_)hamburg(_dot_)de>
No problem with spf2.0/mailfrom, but it would FAIL in a PRA
test. For unknown reasons PRA refuses to handle this trivial
case. It's either because they don't like the Return-Path, or
because improving the PRA-algorithm would break their "patent".
Bye, Frank