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
I think Harry is thinking in terms of dropping that paragraph
entirely since it arguably belongs in a different draft.
--On Friday, August 13, 2004 08:33:10 -0700 ned(_dot_)freed(_at_)mrochek(_dot_)com
| > --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
| headers as defined in section 4 of [SENDER-ID] in order to ensure
| that the purported responsible address determined from the RFC
| headers by the receiving SMTP server will match the SUBMITTER
| This gives a pretty explicit license to modify the header to all
| SMTP clients
| > 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
| 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.