[plug] Sender Policy Framework (SPF)

[James Devenish]

In message <1094630193.6803.6.camel at albert.localnet>
on Wed, Sep 08, 2004 at 03:56:33PM +0800, Craig Ringer wrote:
> On Wed, 2004-09-08 at 13:57, James Devenish wrote:
> > Spammers identify themselves by adding SPF records for their domains. If
> > you receive an e-mail for which there is an SPF pass or failure, discard
> > the message ;-)
> $ dig +short -t TXT @ns1.iinet.net.au postnewspapers.com.au
> "v=spf1 a mx ptr -all"
> *grr* :-P

You know what...immediately after writing that, I thought of you :-P

> It'll at least help with stuff being bounced through countless different
> relays.
[...]
> I hope. I'm sick of getting "you sent me a virus!" messages. I'm really,
> really, sick of replying and explaining what's really going on.

For the purposes of answering Russ' question, perhaps you can give some
guidance about SPF in practice. As I understand it, there are at least
two critical avenues where SPF requires "critical mass" to work:
 (a) domain administration ("sender side")
 (b) mail administration ("receiver side")

SPF will not prevent anyone from spoofing your domain unless you have
published an SPF record for your domain and recipients of spoofed mail
are using SPF-enforcing relays. If your mail domain exists fairly
simply, achieving (a) is merely a matter of personal awareness,
preference and motivation. In comparison, (b) is almost completely out
of your control since both the sender and receiver of spoofed messages
need never interact with your network or your DNS records.

However, if you are a mail administrator, you can at least prevent some
spoofed e-mail from being received by your users. For readers of e-mail
(i.e. all of us), SPF failed mail is usually "rejected" or "filtered".
But mail that is not rejected may have SPF headers that contain advisory
information for "best guess" client filtering. So, for Russ, the answer
to his question is that if he inserts an TXT record with SPF information
in his domain (assuming it is easy to devise the correct record), then
those recipients of mail who are behind relays that enforce SPF will be
unable to receive e-mail that is spoofed as coming from his domain? This
is doing the "(a)" things. There would be "a few" people who would
benefit from this (at the current scale of SPF adoption). The other
thing that he may consider is implementing SPF awareness for incoming
mail. This would mean that he makes use of other people's SPF records,
so that his users do not receive spoofed mail that claims to come from
SPF-enabled domains. This would mean that he is doing the "(b)" things.