From: Greg Connor
Sent: Saturday, June 19, 2004 5:55 PM
Not to gang up on Greg, for he has put out some thoughtful analysis, but
I've got to toss my hat into the "skeptical about PRA" ring. I've also got
a couple of thoughts about the layering approach that Greg and others have
suggested. Layering by itself is a sensible and helpful approach to break a
problem into manageable chunks, plus it gives implementers a choice of how
far to go. I have some problems with what the overall scheme, as presently
proposed, does and does not accomplish. I suggest that it could benefit
from some re-focusing on the key things we need to authenticate and at what
point in the SMTP transaction they need to happen.
While there are about a dozen ways to check various IP/domain combinations
from various fields in an email message, my personal synopsis is that there
are three things that are critical to authenticate for everyday use:
1) That the IP of the SMTP-client is properly tied to a domain name via rDNS
and verified by forward DNS, and neither the IP nor the domain are on any
blacklists, local or external. Present best commercial practices (BCP)
handle this well.
2) That MAIL FROM: represents the original sender, or a designated bounce
address for the sender, of the particular message and sending a DSN to it
does not constitute abuse of an innocent third party.
3) That From: and Sender: (if it exists) represent the original sender(s).
If the alternate "resending" behavior described in RFC2822 sec 3.6.6 is to
remain with us, we unfortunately also have to validate the Resent-From:
header. As a separate issue, I would suggest that it would be best for all
if this particular behavior was deprecated, though that is not simple to
achieve. There is no reason that MUA forwards can't be sent as new messages
with the original From:, Sender: and To: headers as part of the body. This
avoids the appearance of forgery, simplifies authentication and thus makes
actual forgery harder through this mechanism. It also makes it clear that
without a strong crypto signature, the original message being manually
forwarded cannot be authenticated, which is an appropriate thing to convey.
This is one of the few places where body validation adds some value.
Automated message forwarding systems are not likely to alter the message
body, where an individual with an agenda would be sorely tempted to do so.
It appears that the proposed layering approach below does not do an adequate
job of validating #2 and leaves the task of validating #3 to DK, PGP or
S/MIME, which are way too large for the job. The effort to do DK, PGP or
S/MIME validation is large enough that many large providers will simply
accept the messages and expect the MUA's to do the validation. This runs
counter to our desire to reject during SMTP whenever possible.
Since we originally identified MAIL FROM: as the first necessary item to
authenticate along with the need to do so before DATA, I feel we have missed
the boat here and put way too much faith in the utility of PRA as an
authentication tool. It's primary value is in assuring that the present hop
Resent-From: header (not the current Received: header) is not forged. While
it still has its place, we need to accomplish the basic authentication tasks
first.
<...>
Layer 0: HELO and PTR
These should bind strongly to IP. Unfortunately there are cases
where the
HELO is a fake name, or the PTR is missing, or both. At this
stage we are
looking for a FAIL, in order to spot obvious forgeries like "HELO
microsoft.com" or HELO with the receiver's domain as many viruses
do. This
catches some of the "low-hanging fruits" of the forgery world.
By itself a
PASS result here doesn't validate the whole email, it's just the
bare minimum
check for an MTA.
FCrDNS is already a BCP and will reject messages from poorly configured,
"rogue" mailers. If that basic check passes, we can then go on to check
DNSBL's and RHSBL's from _all_ domains in the PTR record that were confirmed
by forward DNS.
Checking the HELO string is a natural extension of this and is arguably a
requirement of RFC2821. There is absolutely no reason that we should
tolerate an improper HELO string that does not contain a FQDN or one that is
not verifiable by FCrDNS. If the FCrDNS on the FQDN in the HELO string
points back to the IP of the SMTP-client, we can say with confidence that we
know the domain of the current sender before DATA. This is as good a basis
for an SPF check as anything else and will allow us to reject before DATA.
This obviates the need for SUBMITTER, IHMO. If there is a counter-example
that disproves this, please present it.
Layer 1: PRA and MAIL FROM+SRS (and eventually SUBMITTER)
These should normally bind strongly to IP as well. This
validates the "last
submission" or "last forwarding hop". This tells you *something*
about the
message, even if it's just the identity of the forwarder. (If you have a
forwarding address like gconnor(_at_)pobox(_dot_)com then the PRA is often
your own
address) It may just be the last submission, but at least it's a
domain name,
and a starting point for reporting abuse without IP lookups.
Herein lies a major problem. We have skipped any authentication of MAIL
FROM:, as the current sender may be a forwarding host. In my mind, this is
simply unacceptable. If the message passes all subsequent tests, we have no
idea, in the case of a forward, if MAIL FROM: is a forgery, and therefore we
are in no position to send a DSN later with the knowledge that we are not
abusing an innocent third party.
There are a number of ways to authenticate MAIL FROM:, but we will have
failed in one of our basic requirements if we don't pick one or more of the
available methods. For the record, SRS does _not_ do this, so this is not
an argument to revert back to it. The fact that "many" emails will be
direct and therefore the MAIL FROM: domain will be the same as the current
sender is not good enough. Those senders are not trying to obfuscate
identity. It's the one's that appear to be forwards where we will have
problems. To combat this, the destination gateway MTA _must_ have the means
to independently validate MAIL FROM: and not rely on a chain of assertions
presented by the forwarder.
While PRA is an interesting concept, and has some value in making sure that
the envelope information agrees with the message headers, that is all it
adds. It is not a substitute for authenticating the envelope information.
I also suggest that the SUBMITTER parameter is of limited value and not
worth the complication. Though it is available before DATA, the HELO FQDN
tells us the current sender before DATA just as efficiently and without a
new ESMTP parameter. If this domain passes SPF with respect to the IP of
the SMTP-client, we will still enter DATA and can compare it to the PRA from
the headers to give us some protection against header forgery. Since if
SUBMITTER passes SPF, we always enter the DATA phase and check it against
PRA, there is no gain for a spammer to forge SUBMITTER, unless they are more
interested in wasting our bandwidth than delivering their message. Since
HELO tells us exactly the same information without a new ESMTP extension, I
propose that SUBMITTER be deprecated.
Why do I say that PRA has only _some_ value in preventing header forger
rather than _prevents_ header forgery? The answer is that a message can go
through a number of hops and we have no way of knowing how detailed the
checks a previous site did and what policy they used for acceptance. Even
though we set up our forwarders to operate in our behalf, few of us really
have the access to the forwarders operations to audit in detail both their
implementation and their local policy. Though we are tempted to say, "this
is my forwarder, operating on my behalf, and if I can't trust them, who can
I trust?", this is a naive approach. They are certainly not trying to do a
sloppy job or fool you, but blindly trusting them is unfortunately naive.
Layer 2: From: and Sender:
These bond weakly to IP because the message could have gone
through forwarding
steps to reach you. But, if you do check them and they happen to
PASS, this
is excellent information. (This is sort of the opposite of Layer
0: here we
are looking for a PASS and ignoring FAIL, and for HELO we are
looking for FAIL
and ignoring PASS.) However, the authorization could have other
info that
doesn't require IP, like domainkeys, in which case it is OK to check and
reject.
Here is another serious problem. The present scheme can't authenticate
From: or Sender: in the case of a forward. The first recipient in the mail
chain actually can authenticate the From: and Sender: domains with respect
to the SMTP-client. However, in the presence of a forward, we are again
faced with the problem of accepting a chain of assertions, without any
assurance that the first hop recipient did the appropriate authentications.
I make the same argument for From: and Sender: as for MAIL FROM:, that the
destination gateway MTA _must_ have its own independent means of
authenticating these key fields if we are to have any confidence in them.
What about leaving the task of validating From: and Sender: to DK, PGP or
S/MIME? There are numerous problems with this approach. Both PGP and
S/MIME have been widely available for a number of years with support
available in most mail clients, yet they are used primarily by technical
professionals and not typical email users. The concepts involved are not
easy to understand for the typical user, nor should they have to. DK
appears to be a rework of S/MIME with the public keys stored in DNS instead
of a PKI. The body check it provides is completely unnecessary for the
typical user. That also causes it to break most mailing lists, like this
one, that add trailers to the message bodies. While MUA's _could_ be
altered to deal with this, that is a _huge_ amount of infrastructure change
and will be a long time coming.
I would argue that without authenticating From: and Sender:, we have a
gaping hole in the authentication process and DK, PGP and S/MIME are not the
right solutions for the problem. I suggest that we need to take a second
look at this and come up with something better for this layer, rather than
leave it to others to solve.
Here's another point... In the discussions about PRA/SUBMITTER it was
suggested that we should only accept forwards from places we
trust... after
all, if we set up the forwarding relationship, we already trust
the forwarder
to accept and relay our email. So, in the cases were Layer 1 PRA
does not
equal Layer 2 From:/Sender:, we should be suspicious of PRA's we
don't trust.
Conversely, if it is a PRA that we DO trust, perhaps we can
accept whatever
SPF results THEY recorded when THEY scanned the message (this is what I
described as "Bootstrapping Trust"). For example, if all my mail
is forwarded
and the PRA is always myself (e.g. gconnor(_at_)pobox(_dot_)com) then
perhaps I can set
up my MUA to recognize this and always accept the PRA as
authentic, and then
the next-level authorization becomes available.
I was originally a proponent of the bootstrapped trust model. That is, you
have parties that you explicitly trust, like your forwarders, and you should
be willing to trust anyone they explicitly trust. There are several
problems with this. I gave some reasons above why it is perhaps naive to
explicitly trust a forwarder.
I didn't come to this conclusion lightly or with any malice toward
forwarders, but changed my mind after speaking with individuals who worked
for organizations that did forwarding and said that, as a result of their
experiences, they would not trust the organizations they worked for to
perform all the "due diligence" that this model requires. If experienced
email administrators and software developers feel this way, how are average
end users realistically expected to audit their forwarders and assign them
explicit trust? Reputation systems for forwarders are still pipe dreams and
even if implemented, how does an average end user know whether they want to
trust VeriSign, Thawte, Entrust, Microsoft or any other root CA? These are
just other commercial enterprises, after all, and what do we really know
about them? They are certainly not malicious, but how can we possibly know
how diligent they really are? How do we know if their rating scales for
reputation are meaningful? I think this is clearly beyond most of us, let
alone the typical email end-user.
Therefore, I now suggest that the bootstrapped trust model with explicitly
trusted forwarders is not a viable idea and will likely lead to continued
undetected forgeries. To combat this, I think we need to give destination
gateway MTA's the ability to independently authenticate MAIL FROM:, From:
and Sender:. Since RFC2821 authentication was always our prime focus, we
should address the MAIL FROM: problem first, but I also think it would be a
mistake to leave From: and Sender: to DK simply because it is RFC2822.
Let's fix the unified, layered framework so it authenticates, to the
destination gateway MTA, the types of forgery that we care most about.
--
Seth Goodman