From: Greg Connor
Sent: Sunday, October 24, 2004 1:31 PM
--Seth Goodman <sethg(_at_)GoodmanAssociates(_dot_)com> wrote:
a) MSA immediately rejects, with explantation, any message where the
highest of From:/Sender:/(newest)Resent-From: does not match
return-path. This would be ideal, though I don't know if all MUA's can
set return-path properly. This approach avoids all ethical and legal
problems. If the explanation returned included web links to clear
instructions on how to correct the setup in each of the common MUA's,
service calls would be reduced, but not eliminated.
Greg Connor <gconnor(_at_)nekodojo(_dot_)org> wrote:
I would suggest modifying this to say "rejects any message where the
domain of the most recent From:/Sender:/(newest)Resent-From: does not
match the domain of the return path." Adding "domain of" allows
things like SES/SRS or VERP to work.
--Ralf Doeblitz <list+spf-discuss(_at_)doeblitz(_dot_)net> wrote:
NACK. Let the MSA sort put which addresses the submitter may use. For
something like VERP ans SES/SRS there should be regular expressions that
match login to allowed adresses.
A very good point, one which I didn't think through completely at first.
In some cases the auth user will own a single email address in the ISP's
domain, and in other cases the auth user owns the whole domain.
I think this underscores the point that the MSA should be able to
sort out
who owns what address, and other MTAs that are not the MSA should not be
trying to match them up. SPF is probably not the best tool for this, and
there are number of other techniques that would work, if ISPs would just
spend the time to correlate return addresses to auth users.
I agree with all of this. Some domains may want to limit a user to the
single identity they authenticated with, down to the local-part, other
domains are a one-person operation where the authenticating user can use any
local-part at that domain.
I'm intrigued by your idea of validating a user's rights for a given foreign
address by requiring them to respond to a confirmation email. This is
potentially a low-maintenance approach. I see this as being done at the
same time as rejecting the original submission with a set of instructions.
The instructions would say to hit the confirmation link in the email sent to
the foreign address and then to re-submit the message. The only additional
piece of the puzzle would be the fact the there is no notice the local ISP
when the user loses the rights to use that address. One possibility would
be to make periodic queries in order to keep the permission up-to-date. The
second issue with doing this is that nowhere was the domain owner involved
in granting permission for the use of their domain address from a foreign
MTA. Perhaps that could be covered by simply notifying the domain owner
based on whois information? One technically more complex solution, but
without any of these limitations, would be some method for the ISP's MTA
contacting the foreign domains MTA (or DNS) requesting if the authenticated
user at the ISP has permission to use a given identity at the foreign
domain. However it is done, I completely agree with you that it is the
MSA's job to determine whether a given user has the rights to use any
particular identity.
Your observation that SPF is not the best tool for this is pretty important.
SPF, or any other LMAP scheme, can only validate anyone's right to use a
particular identity on the first hop. Though most email today is a one-hop
transaction, forwarding does exist, and SPF _cannot_ validate any
originating identity past the first hop. If we put in place protection for
both 2821 and 2822 identities on the first hop only, it's pretty obvious
that spammers will switch to a bogus forward model to get their mail
delivered. One potential solution, though a nightmare for large system
admins, is to explicitly whitelist all forwarders _per user_. A more
practical approach is an end-to-end validation system for anything after the
first hop.
There are a number of different end-to-end protocols available to augment
SPF to make it work after the first hop. While SRS fixes the forwarding
problem of SPF, it does _not_ provide end-to-end authentication. Of the
other solutions available, I prefer SES as it is lightest weight for both
sender and recipient. It works hand-in-glove with SPF or it can be used
independently. The most recent and advanced version of SES puts a message
body digest and a signature in the return-path. This prevents replay by
tying a particular message body, including originating headers, to the
return-path. However, it also _proves_ unequivocally that a given set of
originating headers came from the same MTA that validates the return-path.
A recipient either does a DNS query or a special UDP query to validate the
return-path. After validating the return-path and verifying that the
message headers and body match the digest in the return-path, the recipient
_knows_ for sure that the originating MTA placed those headers in the
message. The recipient knows the message is authentic, unaltered and only
the MSA could have allowed the sender to use the identities in question.
So why should we even care about a published sender policy under these
conditions, since the MSA is the only party who can actually enforce them?
The answer, from the recipients point of view, is for the recipient to
determine if it even wants to consider the message. If the sender policy
is, "we let our customers use any domain name in any address field", a
recipient will probably reject the message, unless the site is whitelisted.
A much more appealing sender policy (to a recipient) is, "we require the
originator identities to be from domains that we can prove the authenticated
user has the rights to use". The sender policy that would give a recipient
the most confidence in the message would be, "we require the originator
identities to be identical to the authenticated user identity".
Whatever it is, if the recipient does find the sender policy satisfies it's
local policy requirements, and the recipient later determines the sender did
not abide by its published policy statement, this will result in a bad
reputation, i.e. blacklisting, for the sending MTA. You can lie about your
sending policy, but your reputation won't hold up long. This is where
real-time systems like GOSSIP, in addition to conventional blacklists, could
come into play to protect recipients from senders who misrepresent their
published sending policy.
This would all be a lot simpler if we could build two simple requirements
into any _future_ authentication standard that go beyond RFC2476:
1) The MSA MUST authenticate all users and MUST NOT accept submissions from
unauthenticated users.
2) The MSA MUST reject any message with an originator identity that the MSA
cannot ascertain the authenticated user has the rights to use.
--
Seth Goodman