On Tue, Jul 27, 2004 at 03:42:53PM +1000, Terje Petersen wrote:
|
| 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>
|
Yes, that is the intent of SUBMITTER.
|
| 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.
|
If receivers are explicitly aware of their expected
forwarding, abuse of SUBMITTER can be strongly limited.
In other words, any SUBMITTER not whitelisted can be
rejected, if receiver MTAs know what forwarding
relationships to expect.
|
| 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.
|
OK, can you explain how this is better than the current
SUBMITTER proposal?
Also, I hope you are clear about the difference between the
envelope address used for bounces, and the header address
used to tell an MUA where to reply.