--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