|
| TP> When I hit reply I expect to be corresponding with the PRA.
|
|
| MW> That would be funny, because the PRA should be b(_at_)b(_dot_)com,
| MW> which is yourself!
|
|
| TP> No! According to your example I am C(_at_)C(_dot_)com(_dot_)
| TP> You have not addressed the issue.
|
OK, then, if you are c(_at_)c(_dot_)com, who is b(_at_)b(_dot_)com?
I originally said:
In the forwarding case, where
a(_at_)a(_dot_)com sends mail to b(_at_)b(_dot_)com
b(_at_)b(_dot_)com forwards to c(_at_)c(_dot_)com,
When c.com receives the message, it sees
MAIL FROM:<a(_at_)a(_dot_)com> SUBMITTER=<b(_at_)b(_dot_)com>
Due to the nature of the forwarding relationship, b(_at_)b(_dot_)com
and c(_at_)c(_dot_)com can be said to represent the same entity.
==================================
=== RESPONSE FROM TERJE BELOW ====
==================================
Okay so let's see if I understand you correctly.
a represents friend@ hotmail
b represents bob @ work
c represents bob @ home
And the MTA at B talks to the MTA at C as such:-
Eg MAIL FROM: <a(_at_)a(_dot_)com> SUBMITTER=<b(_at_)b(_dot_)com>
Eg MAIL FROM: <friend(_at_)hotmail> SUBMITTER=<bob(_at_)work>
Given that a(_at_)a(_dot_)com is unlikely to have published SPF records
that authorise the MTA at B to make this claim to the MTA at C
then its only going to work if the MTA at C has some rule to bypass
SPF checking for email from the MTA at B. Otherwise such an SPF test
would fail to pass the bounce address.
The MTA at C can do this if it trusts that B has already made the
relevant checks already and is itself trustworthy.
In effect the MTA at C must whitelist email from the MTA at B.
However we could instead constructed a command sequence
such as:-
Eg MAIL FROM:<b(_at_)b(_dot_)com> SUBMITTER=<a(_at_)a(_dot_)com>
Eg MAIL FROM:<bob(_at_)work> SUBMITTER=<friend(_at_)hotmail>
Which would seem altogether more reasonable and logical to me.
And in this case a(_at_)a(_dot_)com is the reply address. Ie REPLYTO.
Am I missing something?