-----Original Message-----
From: Meng Weng Wong [mailto:mengwong(_at_)dumbo(_dot_)pobox(_dot_)com]
Sent: Tuesday, 27 July 2004 11:37 PM
To: Terje Petersen
Cc: IETF MARID WG
Subject: Re: alternate submitter syntax
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.
=================================================
=== Terje's Detailed Responds Below ===
=================================================
I believe that I am clear on the difference between the bounce address
and the header address used for reply.
What your example suggests to me is that you want SUBMITTER to work
differently to what I understand.
It seems to me that you want the MAIL FROM parameter to be the bounce
address only if there is no SUBMITTER parameter. If there is a SUBMITTER
parameter then the bounce address is specified by SUBMITTER.
You want the meaning of MAIL FROM to change to being equivalent to the
RFC.2822 FROM address.
So we have two scenarios:-
SCENERIO-A: SUBMITTER parameter NOT supported.
MAIL FROM -> BOUNCE ADDRESS
SUBMITTER -> NOT APPLICABLE
RFC.2822.FROM -> REPLY ADDRESS
SCENERIO-B: SUBMITTER parameter IS supported.
MAIL FROM -> must equal RFC.2822
SUBMITTER -> BOUNCE ADDRESS
RFC.2822.FROM -> REPLY ADDRESS
In other words the location of the BOUNCE ADDRESS moves in the syntax.
And we could have had a parameter called BOUNCETO instead of SUBMITTER.
Eg MAIL FROM:<friend(_at_)hotmail> BOUNCETO=<bob(_at_)work>
Is this a correct interpretation of what you are suggesting?