Subject: Changes in the queue for marid-submitter-03

From: "Harry Katz" <[email-masked]>
Date: Wed, 11 Aug 2004 16:59:59 -0700

With a working group deadline of 8/13 for revised drafts rapidly
approaching, I'm preparing the -03 version of the submitter
specification. 
 
While there's been a lot of discussion on this list about whether
there's value at all in the submitter extension, I haven't received much
feedback about specific changes to the draft itself.  Here's what I have
so far.  Please let me know ASAP (like within the next 24 hours) if
there are other amendments or corrections required.  Please do not
respond on this thread to the question of whether submitter itself is
useful - I expect that discussion to continue for some time.  :-) 
 
Section 1:  Reword the advantage of deriving the PRA from RFC 2822
headers to be that of basing the validation on the identity that is most
commonly displayed to recipients by existing MUAs as the sender's
identity.
 
Section 4.1 :  clean up terminolgy referring to an "emtpy" MAIL FROM to
use the RFC 2821 term "null reverse-path"  
 
Section 4.1:  typo SUMBITTER --> SUBMITTER
 
Section 4.2:  Add note that presence of the SUBMITTER parameter MUST NOT
change the effective reverse-path of a message.  Any delivery status
notifications must be sent to the reverse-path, if one exists, as per
RFC 2821 section 3.7 regardless of the presence of a SUBMITTER address.
If the reverse-path is null, delivery status notifications MUST NOT be
sent to the SUBMITTER address.

---

From: [email-masked]
Date: Wed, 11 Aug 2004 18:14:06 -0700 (PDT)

> commonly displayed to recipients by existing MUAs as the sender's
 
Sounds like a good idea.

> use the RFC 2821 term "null reverse-path"
 
I'd be tempted to go even further and make it mandatory for SUBMITTER= to be
used regardless of whether or not it matches the MAIL FROM.

I'm also not comfortable with the bit about modifying the RFC 2822 header to
match the SUBMITTER field. I understand the rationale for having this, but I
think giving license to piddle with the headers to an SMTP client goes a bit
too far. How about saying that the SMTP client can only do this sort of thing
if the SUBMITTER value on hand is found not to match the header and the
SUBMITTER value is known to be more "accurate" than what's in the header. If
the header is more definitive, the right thing to do is set the SUBMITTER to
match it, not the other way around.

> sent to the SUBMITTER address.
 
This also sounds like a good idea.

				Ned

---

From: Eric Allman <[email-masked]>
Date: Thu, 12 Aug 2004 17:15:45 -0700

--On Wednesday, August 11, 2004 6:14 PM -0700 [email-masked] 
wrote:
[regarding section 4.1]
| I'm also not comfortable with the bit about modifying the RFC 2822
| header to match the SUBMITTER field. I understand the rationale for
| having this, but I think giving license to piddle with the headers
| to an SMTP client goes a bit too far. How about saying that the
| SMTP client can only do this sort of thing if the SUBMITTER value
| on hand is found not to match the header and the SUBMITTER value is
| known to be more "accurate" than what's in the header. If the
| header is more definitive, the right thing to do is set the
| SUBMITTER to match it, not the other way around.

Ned, I don't see where it says this -- in fact, it seems to say the 
opposite (the SUBMITTER must match the RFC 2822 header).  It does say 
that the _clients_ (not the SMTP servers) MUST make sure they match 
by adding a 2822 header if necessary, and that servers SHOULD verify 
that the SUBMITTER matches the PRA from the header (section 4.2).

eric

---

From: [email-masked]
Date: Fri, 13 Aug 2004 08:33:10 -0700 (PDT)

> opposite (the SUBMITTER must match the RFC 2822 header).

The last paragraph of section 4.1:

   Furthermore, SMTP clients MUST, if necessary, insert such RFC 2822
   headers as defined in section 4 of [SENDER-ID] in order to ensure
   that the purported responsible address determined from the RFC 2822
   headers by the receiving SMTP server will match the SUBMITTER
   address.

This gives a pretty explicit license to modify the header to all SMTP clients
IMO.

> It does say

Which is exactly what I said. Note my use of the term "SMTP client", not once
but twice. I note, however, that the distinction between the actions taken by
the SMTP client and server on a relay MTA is blurry at best.

I guess another way to address this would be to only allow this during initial
submission. But I worry that this doesn't catch the intended case for this
action.

The real concern is that we don't want relay MTAs making MARID "work" by
blithely patching the header to match the SUBMITTER value they received. The
reasons why this would be bad should be obvious.

				Ned

---

From: Eric Allman <[email-masked]>
Date: Fri, 13 Aug 2004 09:18:27 -0700

OK, I think I understand what you're getting at now.  It's clear to 
me that _mail_ clients (in this case, either an MUA, a SUBMISSION 
server, or a forwarder) needs to be prepared to modify the header. 
But clearly a vanilla MTA can't do this, because to do so would break 
the underlying assumption that SUBMITTER must reflect the header; if 
you changed the header to match SUBMITTER then there would be nothing 
to prevent forgery.  The intended behavior is described in section 
4.2.

I think Harry is thinking in terms of dropping that paragraph 
entirely since it arguably belongs in a different draft.

eric

--On Friday, August 13, 2004 08:33:10 -0700 [email-masked] 
wrote:

|
| > --On Wednesday, August 11, 2004 6:14 PM -0700
| > [email-masked] wrote:
| > [regarding section 4.1]
| > | I'm also not comfortable with the bit about modifying the RFC
| > | 2822 header to match the SUBMITTER field. I understand the
| > | rationale for having this, but I think giving license to piddle
| > | with the headers to an SMTP client goes a bit too far. How
| > | about saying that the SMTP client can only do this sort of
| > | thing if the SUBMITTER value on hand is found not to match the
| > | header and the SUBMITTER value is known to be more "accurate"
| > | than what's in the header. If the header is more definitive,
| > | the right thing to do is set the SUBMITTER to match it, not the
| > | other way around.
|
| > Ned, I don't see where it says this -- in fact, it seems to say
| > the opposite (the SUBMITTER must match the RFC 2822 header).
|
| The last paragraph of section 4.1:
|
|    Furthermore, SMTP clients MUST, if necessary, insert such RFC
| 2822
|    headers as defined in section 4 of [SENDER-ID] in order to ensure
|    that the purported responsible address determined from the RFC
| 2822
|    headers by the receiving SMTP server will match the SUBMITTER
|    address.
|
| This gives a pretty explicit license to modify the header to all
| SMTP clients
| IMO.
|
| > It does say
| > that the _clients_ (not the SMTP servers) MUST make sure they
| > match by adding a 2822 header if necessary, and that servers
| > SHOULD verify that the SUBMITTER matches the PRA from the header
| > (section 4.2).
|
| Which is exactly what I said. Note my use of the term "SMTP
| client", not once
| but twice. I note, however, that the distinction between the
| actions taken by
| the SMTP client and server on a relay MTA is blurry at best.
|
| I guess another way to address this would be to only allow this
| during initial
| submission. But I worry that this doesn't catch the intended case
| for this
| action.
|
| The real concern is that we don't want relay MTAs making MARID
| "work" by
| blithely patching the header to match the SUBMITTER value they
| received. The
| reasons why this would be bad should be obvious.
|
| 				Ned
|
|

---

From: Dave Crocker <[email-masked]>
Date: Fri, 13 Aug 2004 09:12:30 -0700

Folks,

>> use the RFC 2821 term "null reverse-path"
 
nfmc> I'd be tempted to go even further and make it mandatory for SUBMITTER= to be
nfmc> used regardless of whether or not it matches the MAIL FROM.

I strongly urge that this change be made.  It simplifies the algorithm
and eliminates an ambiguity that Meng cited.

nfmc> I'm also not comfortable with the bit about modifying the RFC 2822 header to
nfmc> match the SUBMITTER field. I understand the rationale for having this, but I
nfmc> think giving license to piddle with the headers to an SMTP client goes a bit
nfmc> too far.

right.

nfmc>  How about saying that the SMTP client can only do this sort of thing
nfmc> if the SUBMITTER value on hand is found not to match the header and the
nfmc> SUBMITTER value is known to be more "accurate" than what's in the header.

I am trying to imagine a situation in which a random SMTP client would
satisfy these criteria.

My concern is that the restrictions will be less important than the fact
that there is language giving smtp clients permission to make the
change.  Since the restrictions are necessarily worded vaguely, any
client smtp operator wishing to make the changes will claim that they
satisfied the criteria.

nfmc>  If
nfmc> the header is more definitive, the right thing to do is set the SUBMITTER to
nfmc> match it, not the other way around.

Currently, SMTP relays do not alter the contents of RCPT-TO or MAILFROM,
other than using subsets of Rcpt-to.

MTAs should not go around changing Submitter.  If submitter is set
wrong, then the message should be rejected.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>