Folks,
Section 4.1 : clean up terminolgy referring to an "emtpy" MAIL FROM to
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:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>