May I publish it on www.openspf.net (with suitable credits ;-) ?
Slainte,
JohnP.
johnp(_at_)idimo(_dot_)com
ICQ 313355492
----- Original Message -----
From: "Andrew W.Donoho" <awd(_at_)DDG(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Cc: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Tuesday, November 02, 2004 8:05 PM
Subject: [spf-discuss] SPF for Dummies...
Anne,
Here it is with a few more technical edits and some expansion of the
text.
Andrew
____________________________________
Andrew W. Donoho
awd(_at_)DDG(_dot_)com, PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)
HOWTO: Setting up SPF for my Home Office EMail Server.
SPF (Sender Policy Framework, <http://spf.pobox.com/>) is an effective
and simple mechanism for combatting forgery of your domain name in the
email system. As a positive, intended side effect of this forgery
prevention, you help anti-spam systems throughout the world start
restricting email to legitimate senders. It is easier to identify and
ignore "bad" email when a responsible party (you) tells the email
system who is allowed to send mail on your behalf. That is what SPF
allows.
Let's look at two scenarios for a small office/home office mail system
- one with a permanent IP address and one with an IP address with a
blocked SMTP port (port 25). The latter case occurs with some ISPs
because they are trying to limit the effect of "zombie" mailhosts
(compromised PCs). They do this by blocking the SMTP port, port 25.
This forces all legitimate mail to go through the ISPs mailhosts where
the ISP can stop spam spews from zombies.
SOHO Mailhost with Unblocked Ports:
SPF implements a three body security pattern:
sender-receiver-authorizer. The authorizer is consulted by the receiver
to verify that the sender is authorized to send mail on its behalf.
This is identical to the three body security pattern used by the credit
card industry for millions of financial transactions daily. In the
credit card case, the buyer is the sender. The merchant is the
receiver. And the card vendor is the authorizer. In SPF's case, the
sending MTA's IP address (message transport agent) is the sending
agent. Since the sender MTA IP address is the only required,
non-forgeable piece of information necessary to complete a mail
transaction, this is what the receiving MTA checks via SPF. Just like a
credit card number is the key piece of data necessary to complete a
purchase and is what a merchant checks with the card vendor. In SPF's
case, you, the owner of a domain name, are the authorizer. SPF is the
protocol you use to tell the world of receivers (the internet universe)
who can send on your behalf. That announcement is done using the same
domain name system (DNS) that you already use to announce your domain's
name to the world. DNS is simple, deployed and already a key technology
used in the email system.
Since SPF works via DNS, we are going to have to look at DNS records.
You may be using a DNS provider that has an automatic web site for
managing these records. If so, you will still need to know some details
about how SPF works and setting up your policy. I will identify the
records you need to communicate with your DNS provider.
Here is a sample DNS file for Example.com using the permanent test
address, 192.0.2.2.
; Example.com. External Zone File
$TTL 24h
@ IN SOA NS postmaster (
2004101701 ; serial
4h ; refresh
2h ; retry
1w ; expire
1h ; negative caching ttl
)
IN NS FW.Example.com. ; Firewall relays name
service inside.
IN NS NS.DNSProvider.com ; DNS Authoritative
host backup.
IN A 192.0.2.2 ; Example.com points at
the firewall.
IN TXT "v=spf1 ip4:192.0.2.2 -all"
IN MX 10 Mail.Example.com.
; Disallow all other hosts from sending email via SPF
* IN TXT "v=spf1 -all"
FW IN A 192.0.2.2 ; ISP Permanent Address
IN TXT "v=spf1 ip4:192.0.2.2 -all"
WWW IN A 192.0.2.2 ; Role name points at
the Firewall.
IN TXT "v=spf1 ip4:192.0.2.2 -all"
NS IN A 192.0.2.2 ; Role name points at
the Firewall.
IN TXT "v=spf1 ip4:192.0.2.2 -all"
Mail IN A 192.0.2.2 ; Role name points at
the Firewall.
IN TXT "v=spf1 ip4:192.0.2.2 -all"
IN MX 10 Mail.Example.com.
SMTP IN A 192.0.2.2 ; Role name points at
the Firewall.
IN TXT "v=spf1 ip4:192.0.2.2 -all"
IN MX 10 Mail.Example.com. ; SMTP is an MX
peer.
This file declares a domain and useful aliases along with the SPF
record. In this case the domain owner owns just one permanent IP
address, 192.0.2.2, which she has assigned to her firewall. Since all
of her permanent internet services reside behind this firewall, all of
the public domain names point at the firewall. (How to configure a
firewall to accept all of these services is a subject that is widely
covered in other HOWTO's.)
Where is SPF in all of this? SPF records occur seven times in this DNS
zone file. They are the text records that contain the string "v=spf1".
Let's examine both of these strings in detail:
IN TXT "v=spf1 ip4:192.0.2.2 -all"
This record says that it implements SPF version1 (v=spf1). That the
IPv4 address, 192.0.2.2, is allowed to send email on its behalf
(ip4:192.0.2.2). And that no other IP addresses are allowed to send
mail for this domain (-all). That last assertion needs some discussion.
Many small businesses do all of their electronic business from a single
site. If so, then you probably want the strictest possible anti-forgery
support from SPF. That is why the above record denies all other sources
from being authorized for sending email on your behalf. If you are
unsure about whether some of your employees may be sending mail on your
behalf from their home email addresses, then change the last string to
"?all". The "?all" is telling the world that they should interpret your
SPF record in a neutral way. This allows you to start to advertise SPF
as you start to take more control of your email infrastructure. If you
are mostly sure that all email comes from your mail servers, then you
could use "~all". The "~all" is a "soft-fail". In other words, the
recipient should regard other email addresses with suspicion. Each of
those less stringent forms of SPF do give you some anti-forgery
support. As with many things on the internet, you will need to change
your infrastructure as we make the email system better and less subject
to abuse. You should plan on moving from "?all" to "~all" to "-all" in
the coming two years (2006-07).
The other, blanket/wildcard denial record is even simpler:
; Disallow all other hosts from sending email via SPF
* IN TXT "v=spf1 -all"
It says all other hosts in your domain are not allowed to send on your
behalf. If you use a weaker form of denial in your main record, then
you should probably do so here too.
SOHO Mailhost with Blocked Port 25 (SMTP):
In the case that your ISP gives you a great deal on connectivity but
doesn't want you running unmanaged mailservers, you can make a simple
addition to your SPF record that will tell the world that you route
your outgoing mail through your ISPs mailhosts. In the below record,
"ISP.net" is the main domain name of your ISP.
IN TXT "v=spf1 include:ISP.net ip4:192.0.2.2
?a:ISP.net -all"
This is a more complex record than above because it has to deal with a
world where your ISP may or may not yet be supporting SPF. This record
should work both before and after the ISP's support begins. Also, if
the ISP starts allowing you to send mail directly (i.e. he unblocks
your SMTP port), then this record will allow you to start sending
email. As you saw above, you read SPF records from left to right. The
new mechanism "include" tells the receiver to include the SPF record
from the following domain name, ISP.net in this case. That way your ISP
tells the world what are its outgoing mail servers which you also use
for your email. By doing this, we allow the ISP to grow and change his
mail infrastructure without having to change any of our SPF records.
The second mechanism, "ip4" is our friend from above. It is here for
the case that, after we have proved to our ISP that we are not spammers
or, more likely, paid him more money, our ISP might relax his rules and
start allowing us to deliver our own mail. The third mechanism, "?a"
tells the receiver to neutrally treat mail from this ISP as having come
from us. And finally, "-all" disallows all other mail servers from
sending mail on our behalf. If your ISP already supports SPF, then you
should drop the "?a:ISP.net" part of the SPF record.
Summary:
SPF is simple to deploy and starts to harden the email system against
abuse. You can easily help make your email more reliable by supporting
SPF. The net will take care of the rest.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta
features SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com