Subject: RE: alternate submitter syntax

From: "Terje Petersen" <[email-masked]>
Date: Tue, 27 Jul 2004 15:42:53 +1000

|  
| TP> When I hit reply I expect to be corresponding with the PRA. 
| 
| 
| MW> That would be funny, because the PRA should be [email-masked],
| MW> which is yourself!
| 
| 
| TP> No! According to your example I am [email-masked]. 
| TP> You have not addressed the issue. 
| 

OK, then, if you are [email-masked], who is [email-masked]?

I originally said:

  In the forwarding case, where

    [email-masked] sends mail to [email-masked]
			  [email-masked] forwards to [email-masked],

  When c.com receives the message, it sees

    MAIL FROM:<[email-masked]> SUBMITTER=<[email-masked]>

  Due to the nature of the forwarding relationship, [email-masked]
  and [email-masked] 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: <[email-masked]> SUBMITTER=<[email-masked]>

  Eg MAIL FROM: <friend@hotmail> SUBMITTER=<bob@work>

Given that [email-masked] 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:<[email-masked]> SUBMITTER=<[email-masked]>

  Eg MAIL FROM:<bob@work> SUBMITTER=<friend@hotmail>

Which would seem altogether more reasonable and logical to me. 

And in this case [email-masked] is the reply address. Ie REPLYTO.

Am I missing something?

---

From: Meng Weng Wong <[email-masked]>
Date: Tue, 27 Jul 2004 09:37:05 -0400

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: <[email-masked]> SUBMITTER=<[email-masked]>
| 
|   Eg MAIL FROM: <friend@hotmail> SUBMITTER=<bob@work>
| 

Yes, that is the intent of SUBMITTER.

| 
| Given that [email-masked] 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:<[email-masked]> SUBMITTER=<[email-masked]>
| 
|   Eg MAIL FROM:<bob@work> SUBMITTER=<friend@hotmail>
| 
| Which would seem altogether more reasonable and logical to me. 
| 
| And in this case [email-masked] 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.