Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd)

Thank you William, for taking the time to write and submit this draft.

I like the idea of having a SUBMITTER extension to ESMTP, mostly because it 
allows another alternative for forwarders who don't want to munge the 
return-path ala SRS.
Some quick comments on the draft...



--"william(at)elan.net" <william(_at_)elan(_dot_)net> wrote:
> 4.1 Setting the SUBMITTER Parameter Value
...
>    SMTP servers which are involved in retransmission of the message but
>    which do not cause change in the direction of SMTP transmission
>    SHOULD use SUBMITTER value they received during incoming SMTP
>    transmission as value for outgoing SMTP transmission. If there was
>    no SUBMITTER MAIL parameter during incoming transmission, then SMTP
>    server MUST NOT use SUBMITTER for outgoing transmission unless it
>    can find email address of the entity which last caused introduction
>    of a message into the email delivery system by other means.

Keeping the same Submitter at an intermediate hop might result in a Fail. 
You might consider relaxing this language a bit to allow for cases where 
the message is being passed along at points other than its initial 
injection where Submitter is most likely to Pass.
My suggestion would be to have a given mail server decide whether it is 
acting as an agent for the sender, or an agent for the receiver.  If the 
mailserver doing the sending is authorized to accept any and all mail for 
the recipient (RCPT) regardless of the sender's identity (i.e. if the 
Recipient is considered local) then it is probably an agent for the 
receiver, and it should check the Submitter value, but should probably not 
pass it on.  If the mail server doing the sending is acting as an agent for 
the Submitter, and a check that uses its own IP would result in a Pass, 
then it is OK to pass the Submitter value on.

>    An SMTP client that supports the Responsible Submitter extension and
>    that can set Responsible Submitter value MUST include the SUBMITTER
>    parameter on all messages. This includes messages containing a null
>    reverse-path in the MAIL command.

A couple exceptions might be 1. if the Submitter is the same as the return 
path, maybe it is not needed, or 2. if the client is an agent for the 
receiver, not the sender, and it has already verified Submitter itself 
(because verifying Submitter again at the next hop might fail.)

> 4.2 Processing the SUBMITTER Parameter
Might want to add something like, "It is important to note that the 
Submitter is not intended to bypass or replace other checks, such as return 
path or HELO, *unless* the receiver trusts the sender to substitute an 
alternate return path.  The presence of Submitter alone should not be taken 
as a substitute for other checks.  The receiver should exercise best 
judgement when setting the policy regarding when to bypass other checks."

> 5.1 Publishing DNS Authorization Records
>
>    Domains that are used as part of the Responsible Submitter address
>    SHOULD publish SPF DNS Authorization records that allow to verify
>    ip addresses of hosts that are authorized to use given domain when
>    setting SUBMITTER parameter. SPF records used for publishing this
>    information MUST use "submit" scope identifier.
Do you want to say that a scope of /submit will be used for this check, and 
if not present, then a general-purpose SPF record may be used instead? 
That would allow sites to publish a single record for all scopes, if those 
scopes have the same access characteristics anyway.

> 5.2 Checking DNS Authorization Records
>
>    For an SMTP Server to test authorization of SMTP Client to use
>    certain domain as part of the SUBMITTER parameter, the SMTP Server
>    MUST evaluate the results of check_host() function as defined in
>    [SPF-PROTOCOL] with arguments as follows:
>
>        <scope>   - the "submit" scope identifier
>        <ip>      - the ip address of the SMTP client host
>        <domain>  - the domain portion of the SUBMITTER parameter
>          <sender>  - the full email address in SUBMITTER parameter
>
>    If SMTP Client provided SUBMITTER argument to MAIL command then SMTP
>    Client SHOULD perform authorization check during the time of SMTP
>    transaction. The check can be performed directly at the time of MAIL
>    command or it may be easier to delay the check to later stage of SMTP
>    transmission.

I would include a note here to say that checking the validity of the 
Submitter parameter during the initial submission is a best practice, 
because it allows the receiver to stop the transaction with a 5xx error (or 
4xx for temp fail) and won't result in a bounce message being send to a 
(supposed, unverified) sender.  Checking after the fact can also be 
supported (perhaps as part of a scoring system) but receivers are 
recommended to check during initial receipt if possible.

> 5.3 Interpreting the Results of SPF Verification

Regarding the interpretation section, I think we should probably push for 
SUBMITTER to get a Pass result, or else it should be pretty much ignored. 
It particular, if the Submitter check doesn't result in a Pass, then it 
should not be used as a basis for establishing trust (for example, in order 
to bypass return path checks that would otherwise fail).  Might want to 
state up front that results other than Pass should not be used to extend 
trust.

> 5.3.2  Pass

A Pass result alone should not be considered sufficient to bypass other 
checks.  For example, a forwarder may use Submitter to signal that it is 
forwarding a message with a return path that it is not normally allowed to 
use, and that the receiver is requested to check Submitter and not check 
return path.  The receiver in this case should only bypass the return path 
check if it trusts the forwarder to forward mail and assert an alternate 
return path.
Or, a receiver may choose to note the submitter and return path and allow 
the MUA to decide which submitters are trusted.

> 5.4.1 Displaying Verification Results in MUA
>
>    When displaying a received message, an MUA SHOULD check message for
>    Authentication-Results headers and if last entered such header is
>    proceeded only by Received and Return-Path trace headers which appear
>    to have been added by MDA or by other MTAs which are known to be on
>    the same network as MUA, then MUA should display the value of
>    Responsible Submitter as found in "envelope-submitter" as well as
>    display to the user the results of SPF verification.
>
>    If email address of Responsible Submitter is the same as address in
>    one of the "From:" headers, then MUA should show that email address
>    as email origin and indicate by some means that it has been SPF-
>    verified based on submitter identity. If header "From:" address is
>    not the same, then origin of the email should be indicated as being
>    that of Responsible Submitter with email listed as having been sent
>    on behalf of the party listed in "From:" header. It should be made
>    clear that only Responsible Submitter part of the email origin has
>    been SPF-verified and not the header "From:" address part.
>
>    MUA may also want to find envelope-submitter values from all
>    "Authentication-Results:" headers as well as "Sender:" and all
>    "From:" headers and display them as addresses responsible for
>    transmission of the message.

Optionally, a MUA may choose to keep a list of which submitter values are 
"trusted" (such as the users own forwarding address).  If the submitter is 
trusted, *and* a previous/second Authentication Results header exists (in 
proper order to have been added by the trusted forwarder), the MUA may 
choose to display this authentication result instead.
(In other words, if a mail is claimed to be forwarded, then the submitter 
should be displayed and attributed as the sender, unless the MUA knows that 
the submitter is really a forwarding account that I have assigned as 
trusted, in which case the message can be safely attributed to whatever 
submitter came right before.  If the MUA doesn't allow users to set trust 
levels, then anyone who uses a forwarding address will see his own address 
as the Submitter for pretty much every message.)

> 6.1 Mail Submission
>
>    Under normal circumstances, Alice would configure her MUA to submit
>    her message to the mail system using the SUBMIT protocol [SUBMIT].
>    The MUA would transmit the message without the SUBMITTER parameter.
>    The SUBMIT server would validate that the MUA is allowed to submit a
>    message through some external scheme, perhaps SMTP Authentication
>    [SMTPAUTH].  The SUBMIT server would then extract her address from the
>    RFC 2822 header "Sender" or if it missing then out of first "From:"
>    header and it would set SUBMITTER parameter to this address for
>    subsequent transmissions of the message.
>
>    Note that setting SUBMITTER parameter based on values of "Sender" and
>    "From" header should be done ONLY if SMTP Server is certain that mail
>    submission is taking place, i.e. if either SUBMIT protocol is used or
>    if SMTP protocol with SMTP authentication [SMTPAUTH] is used.

Might want to refer readers to RFC 2476 and remind them that it is the 
responsibility of the SUBMIT server to verify that the person submitting 
the message is really authorized to use the claimed return-path.  It is 
legal to assert a different return path (for example if Alice would like to 
send from the current location but would like any bounces or delivery 
reports sent to her other address) BUT with two caveats.  1. The server 
accepting the initial submission SHOULD reject any message with a return 
path that cannot be verified as belonging to the submitting user (we are 
not making this part up, refer to RFC2476) and 2. the user submitting the 
message should make sure that the guest/mobile location is permitted as 
part of the return path domain's policy, because many sites will check 
return path anyway even if Submitter passes (because they don't trust 
Submitter as a forwarder of otherwise-unacceptable return paths.)
One way to satisfy 1. (verification of return path) is to keep a list of 
"alternate addresses" the sender may use, and if the sender wants to add to 
the list, send him a test message at that address and ask the user to 
verify receipt by replying or clicking a link containing a secret cookie. 
(This would be similar to signing up for a mailing list.)  Once the address 
is verified, the sending user may use it as one of his alternate return 
paths.  (The page where you add more "alternate" addresses for your ISP to 
verify is also a good place to explain to the user that he or the owner of 
his other domain should add us as an authorized sender.)
If the forwarder is not implicitly trusted by the receiver, or if the 
conditions 1-2 are not met, then the Submit servers should substitute a 
return path that it CAN verify (like the user's local address instead of 
the remote address).  The user is free to set From: and Reply-To: but the 
Sender: and return path should be either local or verified-remote addresses 
and should be tied to the user by SMTP AUTH or some other method (static 
IP, pop-before-smtp, whatever)

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>