--Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:
Maybe I didn't quite see if this is "implied" in SUBMITTER proposal. If
not, then the following may add some strength to the proposal.
o Suggestion to improve SUBMITTER proposal: Persistent User Account (PUA)
Actually, that is very close to the original intent of PRA I think... Your
explanation of what Persistent User Account would mean sounds almost
exactly like what I think "Sender:" is supposed to mean and how it is used.
This is probably the reason Sender: was included as a part of the PRA spec.
I think everything you suggested here is consistent with the SUBMITTER
draft, though it's probably a good idea to improve the draft with a couple
of use cases so that this is more clear.
More info on Sender: and return path follows...
RFC2476 went into some detail about Sender:, saying for example that if the
local user is known on initial submission (MUA to MSA) then MSA may put in
Sender: based on what it knows.
8.1. Add 'Sender'
The MSA MAY add or replace the 'Sender' field, if the identity of the
sender is known and this is not given in the 'From' field.
The MSA MUST ensure that any address it places in a 'Sender' field is
in fact a valid mail address.
So there is already a precedent that says MSA should put in the user's
information and make sure Sender: is right... but unfortunately RFC2476 is
not followed as often as it should be.
Perhaps the best thing we can do in this case is to remind users (and
sysadmins and support people) that if their From: address is not local to
the network they are currently on, at least Sender: should be.
We *could* do this in the document that defines PRA and refer people to
RFC2476 to lend strength to our assertion that the MSA should add Sender:
if the locally-known user is different from the claimed From: address.
Based on this, I think your explanation of PUA is consistent with the way
PRA and SUBMITTER are already described. PRA is a formula to determine
"who injected this message into the mail stream" in a way that lends itself
well to IP-based checking. Forwarding is one example of this, but when
From: != Sender: this also applies. SUBMITTER augments PRA by saying if
PRA != MAIL FROM, use SUBMITTER to tell who the PRA is.
Therefore ISPs have a choice - either force outgoing mail to have a local
account in MAIL FROM, or use PRA and SUBMITTER by way of setting Sender: to
the local account. I believe this is almost exactly what you are proposing
with PUA.
RFC2476 also talks about "return path" - and this is interesting in the
case where ISP allows users to specify any MAIL FROM they want.
If an MSA is not able to determine a return path to the submitting
user, from a valid MAIL FROM, a valid source IP address, or based on
authenticated identity, then the MSA SHOULD immediately reject the
message.
It goes on to say that an MSA can deal with problems by rejecting inline
with SMTP, or by accepting and sending a bounce message, but it
specifically says that bounce messages are not acceptable in the case where
it can't correlate the return path to the submitting user. I think this is
a key difference between MSA and MTA, but unfortunately a lot of ISPs don't
follow RFC2476 closely enough. (I think if more ISPs would take this part
seriously there would be a lot less forgery going around.)
So, how does an ISP "determine a return path to the submitting user"? ISPs
could easily do this by asking users what other email addresses they would
like to use, even non-local ones, and sending a verification email to the
claimed address to ensure it really belongs to the user. (If they want to
use any localpart in their entire domain, the verification email could be
sent to postmaster(_at_)domain(_dot_)) This would allow users to use return addresses
not local to their ISP, and keep the ISP compliant... If the return path
is non-local they would still need Sender: or SUBMITTER or PUA or
something, so that the receiver has something to check besides the
non-local name.
Anyway this is yet another way that RFC2476 has given us some ammunition we
can use -- we just need point people at it and remind them that this has
been expected of them for 5.5 years and what we are proposing is not that
dramatic.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>