ietf-mxcomp
[Top] [All Lists]

Comments on draft-ietf-marid-submitter-02

2004-07-19 14:30:39
Greetings,
 
I've got no big technical issues here.  Just a couple of suggested wording
changes.
 
On page 2: "Deriving the purported responsible domain from RFC 2822 headers
has the advantage of basing the sender validation on an identity that can be
made visible to the end recipient of the message."  I think this needs to be
restated.  Isn't the advantage here based on an assumption that we don't
expect many MUAs to be changed to display the RFC 2821 sender as well as the
RFC 2822 sender?  I suggest that the sentence should be modified to explain
that deriving the PRD from the RFC 2822 headers has the advantage of basing
the validation on the identity that is most commonly displayed to recipients
by existing MUAs as the sender's identity.
 
On page 4: "This includes messages where the MAIL FROM address is empty or
"<>"."  The language in RFC 2821 refers to this as a "null reverse-path",
not an empty address.  I think it would be helpful to be consistent with
that language.
 
One final comment: Even though its obvious to everyone who participates in
the MARID WG, I think it would be a good idea to add text advising
implementers that the presence of the SUBMITTER parameter to the MAIL
command 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.
 
Regards,
Daryl Odnert
Tumbleweed Communications
Redwood City, California
daryl(_dot_)odnert(_at_)tumbleweed(_dot_)com 
<mailto:daryl(_dot_)odnert(_at_)tumbleweed(_dot_)com> 
 
<Prev in Thread] Current Thread [Next in Thread>