With a working group deadline of 8/13 for revised drafts rapidly
approaching, I'm preparing the -03 version of the submitter
specification.
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.
Section 4.1 : clean up terminolgy referring to an "emtpy" MAIL FROM to
use the RFC 2821 term "null reverse-path"
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.