On Mon, 2004-09-13 at 19:25 -0500, Gordon Fecyk wrote:
There, just so it's clear what I'm thinking, in case it wasn't clear every
other time I've used the word "accountability" or "accountable" in an e-mail.
Yes, this means knowing who to point fingers at for mail abuse. It would
also mean fingering a domain administration who, wittingly or otherwise,
allows a compromised system to send abusive mail on its behalf (and,
hopefully, would correct that compromise somehow.)
Right. SPF and SenderID provide that accountability only for a single
hop at a time. They do not provide end-to-end validation of a given
email address.
I could quite happily forge mail which appears to be from you by using
an SRS reverse-path at my own domain containing your address, and a
Resent-From: header with your username at my own domain despite the
From: header still containing your normal address. Most users are naïve
enough not to notice, and those who _would_ notice are mostly the same
people who'd notice it without SenderID due to the Received: headers
anyway.
Of course, if I did that a lot my domain name would end up in a
blacklist -- my mail servers would be considered untrustworthy.
That's the point -- it's a hop-by-hop scheme. It's _all_ about how much
you trust the one mail server which is sending you mail. Where before we
had IP-based blacklists, now there are domain-based blacklists, without
which SPF/SenderID is largely not useful.
Since mail servers in the Brave New World are expected to modify the
outgoing mail to add their 'domain', and since they can arbitrarily
choose _any_ 'domain' which has a record permitting their IP address,
it's clear that the 'domain' used for the check has essentially become
just an arbitrary key into the blacklist/whitelist/trustdb. And that
trust database isn't optional -- it's a required part of the scheme if
the SenderID information is to be useful.
So why are we looking at only mailfrom and pra scopes? There are many
other arbitrary keys which we could use for the database -- all we need
is some means of checking that the presenting mail host really is
authorised to claim allegiance with whichever entity is represented by
the key.
One suggestion would be to use the signer of a TLS certificate. Every
mail server in an administrative domain would present its TLS cert, and
each cert signed to show that it legitimately belongs to that domain.
Then your whitelist/blacklist/trustdb is keyed on the signing
certificates. Note that 'administrative domain' isn't necessarily
equivalent to DNS domain. And that self-signed certs are fine -- there's
no need to pay anyone for a cert.
Using the HELO scope is another possibility which makes some sense.
Unlike the mailfrom or pra scopes, limiting the use of a given HELO name
to certain IP addresses does actually have some basis in the real world
today.
Other alternatives might include a new SMTP extension for the client to
provide its 'identity', which can be verified either by IP address or
perhaps other means. The possibilities are endless -- there are many
options which would not have the deployment and accuracy problems of the
mailfrom and pra scopes.
However, the mailfrom and pra scopes are not workable in today's
Internet because they are based on the fundamentally flawed assumption
that forwarding hosts will be upgraded to behave in strange and
controversial new ways. Deployment of new standards in email is
_extremely_ slow even when they are clearly a good thing, and the new
world required to make the mailfrom and pra scopes actually workable
would, in my opinion, _never_ be reached.
I propose that we should abandon the mailfrom and pra scopes which abuse
the RFC2821 and RFC2822 source addresses as a trust-database key, and
instead look for alternative keys for our trust database -- such as the
TLS certificate or the HELO name -- which do not break existing
practice.
Separate work is ongoing to provide end-to-end solutions for assuring
that RFC2821 and RFC2822 sender addresses really are valid. A hop-by-hop
scheme cannot reliably guarantee that _anyway_; SenderID and SPF are
useful for assigning trust to individual (or groups of) mail hosts only,
and there are _better_ ways of doing that than abusing the sender
identities in a way which requires us to 'upgrade' all existing mail
installations to cope.
--
dwmw2