ietf-mxcomp
[Top] [All Lists]

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

2004-08-13 09:18:32

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 ned(_dot_)freed(_at_)mrochek(_dot_)com wrote:

|
| > --On Wednesday, August 11, 2004 6:14 PM -0700
| > ned(_dot_)freed(_at_)mrochek(_dot_)com 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
|
|