On Fri, 2005-07-08 at 14:56 -0500, Seth Goodman wrote:
Let us assume that the forwarding problem gets solved, because RFC4821
mandates SRS and everyone obeys, and that I start to use SPF.
I was trying to present the ideal SPF deployment scenario, when everyone
can publish records with '-all', and everyone can reject for failure.
I didn't expect you not to like it :)
That's a perfectly dreadful scenario, as it defeats the primary purpose of
SPF. You can validate that the mail came from the forwarder, but you have
no assurance that the originating domain is authentic. Why? Because with
straight SPF, even if you trust this particular forwarder, only the first
forwarder in the delivery chain can validate the originating domain. You
then have a chain of trust that is only as good as its weakest link. Even
if you knew the whole delivery path, do you want to maintain a rating of how
much you trust each potential forwarder? I think not.
You say: "That's a perfectly dreadful scenario, as it defeats the
primary purpose of SPF."
Yes and no.
Yes, when everyone is using SRS and the forwarding problem is solved,
when every MTA has built-in SRS support which is enabled by default,
then the fact that SPF uses the _reverse-path_ will be fairly
superfluous. In every case, you'll actually be checking against some
domain name which was generated at the sending server, not checking
against the domain of the original sender. So you might as well just be
using the name which the sending server gives in HELO, instead of the
domain in the reverse-path.
This basically means that you might as well just have used CSA in the
first place. SPF tries to be more clever than that, but by the time
you've deployed SRS to fix up the cases where that cleverness gets it
wrong, you end up with basically the same result as CSA. Except that
you've introduced all this breakage along the way for no real long-term
gain.
But no, that doesn't defeat the _whole_ purpose of SPF -- as I
understand it. It's been acknowledged right from the start that SPF will
need to work in conjunction with a reputation system for the entities
which are authenticated as being responsible for the mail in question.
If the sending entity is good, you accept the mail; if the sending
entity is bad, you probably reject it.
I thought that the primary purpose of SPF was to allow us to do that; to
authenticate the entity responsible for each incoming mail, such that a
reputation database can be used to decide whether to accept it or not.
The purpose of CSA is similar -- except that CSA uses the HELO name
instead of the domain name of the reverse-path. It's only intended to
authenticate a given mail server.
The fact that SPF, in what seems for many to be its ideal deployment
scenario, is reduced to basically being the same as CSA, doesn't mean
that it isn't useful -- and doesn't mean that it's failed in its primary
purpose.
CSA is useful, and SPF would be _just_ as useful if SRS were to become
ubiquitous and make it reliable enough to publish and obey '-all'.
Yes, they're both hop-by-hop methods and one could argue that their
utility is slightly less than that of the true end-to-end methods which
aren't effectively playing Chinese Whispers with the authenticity of the
mail. But that doesn't mean they're not useful.
There are genuine mail servers, and there are rogue mail 'servers'.
There's not a huge amount of overlap between the two -- it _does_ make a
lot of sense to use a reputation system based solely on the sending
machine; especially as spammers can so easily register throwaway
domains.
--
dwmw2