RE: I hate to interrupt all this for something practical, but.... we nee

For blocked port 25 systems..

2 issues:

My ISP does not list the outgoing SMTP systems.  I and others had to send
test emails to generate the list.  We found 10 of them.  My ISP does not do
SPF yet.  Your example is correct, but for me it was not easy.

The "a:SMTP.ISP.net" tells the world to trust SMTP.ISP.net (since the
default is "+").  But this is not correct.  Everyone that has access to the
SMTP server can forge your email address.  You should use "~a" which is
neutral, but neutral is what you get if you have no SPF record.  This is
stupid.  I should be able to indicate my ISPs SMTP servers can be trusted
more than any other SMTP server on the Internet, but I can't trust it 100%.
So, I use +, which is wrong.  Oh, I have read that some ISPs fail on
neutral.  You could use "include:ISP.net" if your ISP has SPF records.
Still the same neutral issue.

Guy

________________________________________
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Andrew 
W.Donoho
Sent: Wednesday, October 27, 2004 4:22 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Cc: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] I hate to interrupt all this for something
practical, but.... we need a concise, easy-to-follow set of SPF instructions
in file format - anyone able to help?

Anne,

Oops, I left a sentence out just before the SOHO with blocked ports.

I've edited it in below.

Andrew

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 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-forged
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 on 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 emails, then
change the last string to "?all". If you are mostly sure that all email
comes from your mail servers, then you could use "~all". Each of those less
stringent forms of SPF do give you some anti-forgery support. As with many
things on the internet, the protocols evolve.

The other, blanket denial record is even simpler:

; Disallow all other hosts from sending email via SPF
* IN TXT "v=spf1 -all"

It says all other domain hosts 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 TXT "v=spf1 a:SMTP.ISP.net -all"

"SMTP.ISP.net" is the name of the server your ISP gave you to send mail
through. That is all there is to it.

Summary:

SPF is simple to deploy. You can easily help make your email more reliable
by supporting SPF. The net will take care of the rest.


____________________________________
Andrew W. Donoho
awd(_at_)DDG(_dot_)com, PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)