While there's been a lot of discussion on this list about whether
there's value at all in the submitter extension, I haven't received much
feedback about specific changes to the draft itself. Here's what I have
so far. Please let me know ASAP (like within the next 24 hours) if
there are other amendments or corrections required. Please do not
respond on this thread to the question of whether submitter itself is
useful - I expect that discussion to continue for some time. :-)
Section 1: Reword the advantage of deriving the PRA from RFC 2822
headers to be that of basing the validation on the identity that is most
commonly displayed to recipients by existing MUAs as the sender's
identity.
Sounds like a good idea.
Section 4.1 : clean up terminolgy referring to an "emtpy" MAIL FROM to
use the RFC 2821 term "null reverse-path"
I'd be tempted to go even further and make it mandatory for SUBMITTER= to be
used regardless of whether or not it matches the MAIL FROM.
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.
Section 4.1: typo SUMBITTER --> SUBMITTER
Section 4.2: Add note that presence of the SUBMITTER parameter 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.
This also sounds like a good idea.
Ned