Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd)
2004-10-08 22:53:51
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>
|
|