SPAM Prevention Using DNS Solutions

Implementing reverse domain name services

(rDNS) and planning for SPF Classic

Presented by: Ed Horley

Date: May 2005

Overview

SPAM prevention is the primary reason that rDNS and SPF Classic will
become de jure within approximately 1-2 years (IETF ratified)

Current methods for SPAM prevention are de facto solutions filtering,

black/white lists, etc

Reverse DNS (rDNS) is a great quick check to determine if an MTA is

being run and maintained correctly but it can be spoofed

Sender Policy Framework (SPF v1) or SPF Classic is being used by

service providers to confirm that the mail servers they are receiving
mail from are authorized to do so on behalf of the sending domain,
these records are published by the sending domain

Overview Continued
Future additional solutions for SPAM prevention are Yahoos
DomainKeys, Sender Verification and perhaps Microsofts
Puzzle Solution (unlikely)
Sender ID has been rejected by the IETF as a proposed
standard (de jure) due to inclusion of patented technology by
Microsoft and Microsoft has modified it and resubmitted. It may
or may not make it through this time depending on the
dependencies the working committee see on the patented or
protected intellectual property

Current Solutions Overview

Current de facto solutions
Blacklists (IP and DNS based)
rDNS (optional see RFC2505 2.5)
Anti-spam filtering (Bayesian and others)
Anti-spam services (Brightmail, Postini, Commtouch, etc)
Hardware appliance filters / services
Custom built scripts and applications
Sender Verification (Several different formats exist)
Whitelists (IP and DNS based)
SPF Classic (optional)

Solutions Used Today

Blacklists
SpamCop
MAPS
ORDB
SPAMhaus
Spews
SURBL
Mail-abuse
DSBL
DNSBL
DNSRBL

Client filters
Audiotrieve InBoxer
Cloudmark SpamNet
Lyris MailShield
McAfee SpamKiller
Aladdin SpamCatcher
Sunbelt IHateSpam
SpamBayes (open source)
Spam Bully
MailFrontier Matador
Cloudmark Spamnet

Solutions Used Today

Server filters
Exchange IMF (comes bundled
with Exchange)
XWall
Vircom modusGate
Sophos PureMessage
Proofpoint Protection
SurfControl
Symantec
Trend Micro
GFI MailEssentials
Sybari Antigen (Microsoft Aquired
Feb 2005)
Network Associates / Mcafee
SpamAssassin (open source)
Declude JunkMail

Hardware Appliances

Subscription Services

Barracuda 300
BorderWare MXtreme
CypherTrust IronMail
IronPort C60
Mail Foundry
Sendio ICE Box
Tumbleweed

Brightmail
Commtouch
Greenview Data
Katharion
Postini
PUREmail

The Proposed Solutions

Short term solutions:
Internet Engineering Task Force (IETF) draft rfcs
Sender Policy Framework (SPF Classic)
Sender ID (SPF Classic + PRA) Microsoft draft rfc
(maybe?)
DomainKeys (Google and Yahoo have implemented)
Long term solutions:
Internet Research Task Force (IRTF)
New version / next generation of SMTP?

What to do now?
SMTP mail gateway filters (hardware or software)
Consider a commercial service (depends on the amount and
type of traffic you except to see for your environment)
Software e-mail client filters (Small business accounts)
Blacklists / Whitelists (Enterprise and Service Providers)
rDNS (anyone running an MTA that sends traffic to the Internet)
SPF Classic (anyone running an MTA that sends traffic to the
Internet)
DomainKeys (Service Providers)

What is rDNS?
rDNS is an acronym for reverse DNS
It is a method of name resolution in which an IP address is
resolved into a domain name
It is the opposite of the typical resolution method of DNS which
resolves domain names into IP addresses
It utilizes the existing DNS infrastructure by using a special
reserved domain name: in-addr.arpa.
IP addresses are more specific left to right and domain names
are more specific right to left, therefore the rDNS IP listings are
reversed
Example: 63.251.192.20 would have a reverse entry of
20.192.251.63.in-addr.arpa.

Why you should do rDNS now

Easy to implement
Because spammers often use invalid IP addresses (bogons) to
send e-mails, rDNS will determine the authenticity of a domain
name compared to the IP address from which it is originating
It is used as one of several de facto methods to determine the
likelihood of a server being a SPAM relay
Most Internet Service Providers are using this to determine
legitimate mail sources
Reduces probability of legitimate mail servers being added to a
Blacklist

What is SPF Classic?

SPF Classic is used to identify mail servers that are explicitly permitted
to send mail for a particular domain (think outgoing)
Domain owners identify permitted sending mail servers in DNS using
TXT records
SMTP receivers verify the envelope sender address against the DNS
information and can distinguish legitimate mail servers before any
message data is transmitted
It is backward compatible with MTAs that are not patched with SPF
filters or libraries (well, actually the old MTA just ignore it if that is
considered backward compatible!)
Remember MX records publish which IPs are to receive mail
(incoming) destined for your domain, SPF records says which IPs are
allowed to send mail (outgoing) on behalf of your domain

Why you should do SPF now

Easy to implement (publish TXT records in DNS)
It is used by AOL, Symantec, EarthLink, Google and more as
one of several de facto methods to determine trustworthiness of
the mail sources
Most Internet Service Providers are currently or starting to use
this to determine legitimate mail sources
Will move your mail to priority queues for processing for many
providers including AOL, you can also submit to be added to the
Whitelist for AOL
Reduces probability of being added to a Blacklist
Oct 1st ,2004 Microsoft, MSN and Hotmail will all start using
Sender ID to prioritize incoming e-mail! (Sender ID is backward
compatible with SPF Classic)

What to know about SPF Classic

Meng Wong created SPF Classic. It used to be called Sender Permitted From
and was changed to Sender Policy Framework
SPF v1 (Classic) designates specific SMTP servers as being authorized to send
for a FQDN
Uses the TXT fields in DNS to publish relevant information
Each sub-domain must be configured specifically
SPF will become de jure within approximately 1-2 years most popular filters
are flagging this already
Most MTAs support SPF Classic or have plug-ins available
Backward compatible with existing technology
It breaks e-mail forwarding! You'll have to switch from forwarding, where the
envelope sender is preserved, to remailing, where the envelope sender is
changed your MTA will have to support this

What to know about Sender ID

SPF Classic + PRA = Sender ID (basically now the MTA (think

Exchange) checks SPF AND the MUA (think Outlook) check the PRA
or Purported Responsible Address)
Meng Wong and Microsoft submitted a draft rfc merging both solutions
and called it Sender ID was just turned down as a standard by the
IETF due to Microsoft patent issues it is back on the table again!
Uses the TXT fields in DNS to publish relevant information same as
SPF but uses a new version number
Each sub-domain must be configured specifically just like SPF
Microsoft will be updating the MTA/MUAs to support PRA (or Sender
ID) think Outlook, Outlook Express and Exchange
Backward compatible with existing technology
It breaks e-mail forwarding! You'll have to switch from forwarding,
where the envelope sender is preserved, to remailing, where the
envelope sender is changed just like SPF
SPF v2

What to know about PRA *

A purported responsible address is determined as the first from the

following list of items:
the first Resent-Sender header in the message, unless (per the
rules of RFC2822) it is preceded by a Resent-From header and one
or more Received or Return-Path headers occur after said ResentFrom header and before the Resent-Sender header (see 3.6.6. of
RFC2822 for further information on Resent headers),
the first mailbox in the first Resent-From header in the message,
the Sender header in the message, and
the first mailbox in the From header in the message
The purported responsible domain of a message is defined to be the
domain part of the messages purported responsible address.

What is coming in a few years

DomainKeys
A Yahoo! submitted draft rfc
http://www.ietf.org/internet-drafts/draft-delany-domainkeysbase-00.txt
Basically public/private keys for authenticating client mail and the
servers along the path
Acts as a chain of custody from the source client machine to the
destination client machine
Will require a major re-write of all MTAs to work 5 to 10 years if at
all?
Backward compatible with existing technology
Google and Yahoo have already deployed!
Has promise to be a great standard if adoption is quick enough

What is coming continued *

Puzzle Solution
Microsoft proposal
Assumed for small businesses that cannot afford certificate
services
Sending mail server has to perform time consuming calculation for
each mail sent
Assumes spammers cannot afford the computational costs to send
out large bulk mailings or the cost of the bulk certificate services
Will require a major re-write of all MTAs to work 5 to 10 years if at
all?
Backward compatible with existing technology
Solution has serious shortcomings
Microsoft has little published on this solution

Future potential SPAM problems

Disposable domain names, certificates and registrars

Country Sanctioned Activity (Governments allowing for profit activity or

turning a blind eye to problem spammers) in order to generate $s

Large Zombie Farms controlling clients with legit relay access (Think
large University or poorly managed corporate environments)

Spyware agents that provide relay capabilities similar to Zombie

configurations

IPv6 and Mobile IP devices becoming more prevalent

Potential exploits that could turn large peer-to-peer networks into relays

How rDNS works

MX: mx1.ispA.net ->1.1.1.1

MX: mx1.ispB.net -> 2.2.2.2

Public ISP SMTP servers

send e-mail to destination

Public SMTP servers receive

e-mail and check rDNS
ISP A

Internet

3
Internal SMTP servers
forwarding e-mail to
public ISP SMTP servers

ISP B

Public DNS servers supply

reverse entries
PTR: 1.1.1.1 -> mx1.ispA.net
PTR: 2.2.2.2 -> mx1.ispB.net

Internal SMTP servers

take client e-mail

1
Worker sends e-mail
to colleague

Colleague receives e-mail from

Public SMTP servers

How to request rDNS for sub /24

address blocks

You will have to contact your ISP to request rDNS delegation do this
via e-mail so you have a written trail of correspondence

You will likely have to talk to several departments to figure out who can
actually do this for you, first contact your account manager

Typically, the DNS group handles the sub-delegation but not always
sometimes it is the networking group

You will need to be patient but firm inform them that you need it for
Anti-SPAM reasons for your mail server, to be RFC 2505 compliant

RFC 2317 describes standard methods for rDNS sub /24 delegation
formats, there is also the DeGroot hack from the book "DNS & Bind"
both work fine

Setting up RFC 2317 rDNS Delegation

Example of 64.94.106.40/29 configuration in the providers servers:

$ORIGIN 106.94.64.in-addr.arpa.
; zone delegation of 64.94.106.40/29
;
40-47.
IN
NS
40-47.
IN
NS
;
40.
IN
CNAME
41.
IN
CNAME
42.
IN
CNAME
43.
IN
CNAME
44.
IN
CNAME
45.
IN
CNAME
46.
IN
CNAME
47.
IN
CNAME

ns1.j2global.com.
ns2.j2global.com.
40.40-47.106.94.64.in-addr.arpa.
41.40-47.106.94.64.in-addr.arpa.
42.40-47.106.94.64.in-addr.arpa.
43.40-47.106.94.64.in-addr.arpa.
44.40-47.106.94.64.in-addr.arpa.
45.40-47.106.94.64.in-addr.arpa.
46.40-47.106.94.64.in-addr.arpa.
47.40-47.106.94.64.in-addr.arpa.

Setting up the rDNS Zone

Example of 64.94.106.40/29 configuration in your servers:

$ORIGIN 40-47.106.94.64.in-addr.arpa.
; zone delegation of 64.94.106.40/29
;
@
IN
NS
@
IN
NS
;
@
IN
TXT
;
40
IN
PTR
41
IN
PTR
42
IN
PTR
43
IN
PTR
44
IN
PTR
45
IN
PTR
46
IN
PTR
47
IN
PTR

ns1.j2global.com.
ns2.j2global.com.
"j2 Global Communications, Inc."
64.94.106.40.efax.com.
64.94.106.41.efax.com.
64.94.106.42.efax.com.
64.94.106.43.efax.com.
64.94.106.44.efax.com.
64.94.106.45.efax.com.
64.94.106.46.efax.com.
64.94.106.47.efax.com.

Checking the rDNS Zone

Example of checking the 64.94.106.40/29 configuration:

; <<>> DiG 2.1 <<>> @206.13.31.12 40.106.94.64.in-addr.arpa. PTR

; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr rd ra; Ques: 1, Ans: 2, Auth: 2, Addit: 0
;; QUESTIONS:
;; 40.106.94.64.in-addr.arpa, type = PTR, class = IN
;; ANSWERS:
40.106.94.64.in-addr.arpa.
43200
CNAME 40.40-47.106.94.64.in-addr.arpa.
40.40-47.106.94.64.in-addr.arpa. 86400
PTR
64.94.106.40.efax.com.
;; AUTHORITY RECORDS:
40-47.106.94.64.in-addr.arpa.
86400
NS
ns2.j2global.com.
40-47.106.94.64.in-addr.arpa.
86400
NS
ns1.j2global.com.
;; Total query time: 48 msec
;; FROM: us.mirror.menandmice.com to SERVER: 206.13.31.12
;; WHEN: Tue Jul 20 01:20:09 2004
;; MSG SIZE sent: 43 rcvd: 146

MX: mx1.ispA.net ->1.1.1.1

TXT: "v=spf1 a mx -all"
Public ISP SMTP servers
send e-mail to destination

How SPF Classic works

ISP A

Internet

TXT: "v=spf1 a mx -all"

Public SMTP servers receive
e-mail - checks SPF info

ISP B

3
Internal SMTP servers
forwarding e-mail to
public ISP SMTP servers

Public DNS servers supply TXT,

MX and A records

MX: mx1.ispA.net

Internal SMTP servers

take client e-mail

1
Worker sends e-mail
to colleague

TXT: v=spf1 a mx all

A: mx1.ispA.net -> 1.1.1.1

MX: mx1.ispB.net -> 2.2.2.2

Colleague receives e-mail from

Public SMTP servers

SPF Classic Syntax *

Some common SPF options in the TXT field
a = the A record entry for example.com sends e-mail on behalf of example.com
mx = the published MX record entries for example.com do not only receive e-mail on behalf of
example.com but send e-mail also
ptr = approve any host that ends in example.com as part of its FQDN
a: = a list of A record entries that are permitted to send e-mail on behalf of example.com
mx: = a list of mx record entries that are permitted to send e-mail on behalf of example.com
ip4: = a list of ip addresses that are permitted to send e-mail on behalf of example.com (CIDR)
include: = a different domain that may send e-mail on behalf of example.com (relay through your
service provider)
-all: = (fail) everything in the SPF record are the ONLY hosts/networks permitted to send
(strictest policy dont do unless you know all the ramifications)
~all: = (soft fail) everything in the SPF record are the ONLY hosts/networks permitted to send
(middle ground)
?all: = not sure (technically neutral) if everything in the SPF record are the ONLY hosts/networks
permitted to send (start publishing with this one first as it is the most liberal policy)
Please see http://spf.pobox.com/mechanisms.html for a more detailed description and see
http://spf.pobox.com/whitepaper.pdf for an excellent whitepaper

Setting up SPF Classic

Configuration of example.com SPF
$ORIGIN example.com.
; Leaving out the SOA info for space reasons
; NS records
@
IN
NS
@
IN
NS
; MX records
@
IN
MX 10
@
IN
MX 20
; A records
mx1
IN
A
mx2
IN
A
; TXT SPF records
@
IN
TXT
mx1
IN
TXT
mx2
IN
TXT

ns1.example.com.
ns2.example.com.
mx1.example.com.
mx2.example.com.
1.1.1.1
2.2.2.2
"v=spf1 a mx -all"
"v=spf1 a -all"
"v=spf1 a -all"

Register your SPF domain

Once you have configured SPF for your domain you should
confirm your configuration at:
www.dnsstuff.com
Then put the logo on your site!

Testing SPF Classic

Testing of example.com SPF
http://www.dnsstuff.com/pages/spf.htm
Dummy Sample Output from dnsstuff:
SPF lookup of sender droid@example.com. from IP 1.1.1.1:
SPF string used: v=spf1 mx -all. Obtained the TXT record via DNS for example.com
Processing SPF string: v=spf1 mx -all. Checking against the TXT record
Testing 'mx' on IP=1.1.1.1, target domain example.com, CIDR 32, default=PASS. MATCH!
Testing 'all' on IP=1.1.1.1, target domain example.com, CIDR 32, default=FAIL.
Result: PASS

Impact on the Internet

These solutions will help reduce overall architecture problems of
Authentication, Authorization, and Accounting with e-mail (back
to AAA)
68B e-mails daily of which approx. 42.8B are spam or 69%
1
spam!
Estimated $1,400 annual savings per employee from lost
2
productivity currently due to spam
1 The Radicati Group and Brightmail
2 - Vircom

Resource Links

rDNS:
http://www.ietf.org/rfc/rfc2317.txt
http://www.ietf.org/rfc/rfc2505.txt
http://www.arin.net/registration/lame_delegations/index.html
http://kbase.menandmice.com/view.html?rec=31
http://www.microsoft.com/windows2000/techinfo/reskit/enus/default.asp?url=/windows2000/techinfo/reskit/en-us/cnet/cncf_imp_dewg.asp
http://dedicated.pacbell.net/custcare/dns_worksheet.html

DNS tools:
http://www.dnsstuff.com/
http://us.mirror.menandmice.com/cgi-bin/DoDig
http://network-tools.com/
http://www.squish.net/dnscheck/
http://www.dns.net/dnsrd/tools.html
http://www.dnsreport.com/
http://www.samspade.org/t/

General references:
http://www.spamanatomy.com/
http://www.declude.com/Articles.asp?ID=97

Resource Links

SPF:
http://spf.pobox.com/howworks.html
http://spf.pobox.com/rfcs.html
http://spf.pobox.com/wizard.html
http://www.ietf.org/internet-drafts/draft-mengwong-spf-01.txt
http://www.dnsstuff.com/pages/spf.htm

Microsofts PRA (E-mail Caller ID):

http://www.microsoft.com/downloads/details.aspx?FamilyID=9a9e8a28-3e85-4d07-9d0f6daeabd3b71b&displaylang=en

Sender ID the merged PRA and SPF:

http://www.microsoft.com/presspass/press/2004/may04/05-25SPFCallerIDPR.asp
http://www.microsoft.com/presspass/press/2004/jun04/06-24SIDSpecIETFPR.asp
http://www.microsoft.com/mscorp/twc/privacy/spam_senderid.mspx

Yahoo! DomainKeys:
http://antispam.yahoo.com/domainkeys
http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-00.txt
http://boycott-email-caller-id.org/

A look at some Service Providers records

aol.com.
300 IN
TXT "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24
ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24
ptr:mx.aol.com ?all
aol.com.
300 IN
TXT "spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24
ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24
ptr:mx.aol.com ?all

cisco.com.

86400 IN

earthlink.net.
?all

1800

efax.com.

86400 IN

google.com.

hotmail.com.
3600 IN
TXT "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com
include:spf-c.hotmail.com include:spf-d.hotmail.com ~all

microsoft.com.

msn.com.
900 IN
TXT "v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com
include:spf-c.hotmail.com include:spf-d.hotmail.com ~all

netzero.net.

symantec.com.
?all

300

3600

600

TXT

IN

TXT

IN

IN

IN

"v=spf1 ptr"
"v=spf1 ip4:207.217.120.0/23 ip4:207.69.200.0/24 ip4:209.86.89.0/24

TXT

"v=spf1 ptr ?all"

TXT

"v=spf1 ptr ?all

TXT

TXT

18000 IN

"v=spf1 mx redirect=_spf.microsoft.com"

"v=spf1 ptr:untd.com ptr:netzero.net ptr:juno.com ?all

TXT

"v=spf1 ip4:198.6.49.0/24 ip4:65.125.29.0/25 ip4:206.204.57.47

Questions and Answers

About Ed Horley

Ed Horley is a Sr. Network Engineer for j2 Global Communications, better

known as eFax. Ed currently designs, supports and maintains j2's 58+
international and domestic collocation sites along with j2's core data center IP
infrastructure. He is experienced in e-commerce web content delivery, large
scale e-mail delivery, firewalls, IPSec VPN's, and specializes in routing and
switching and DNS issues.

Ed is a Cisco Certified Network Professional (CCNP), a Microsoft Certified

Professional (MCP) and a Microsoft Most Valuable Professional (MVP). Ed
graduated from the University of the Pacific in 1992 with a BS in Civil
Engineering.

When he is not playing on network gear you can find him out on the lacrosse
field as an Umpire for Women's Lacrosse. He is currently married to his
wonderful wife Krys and has two children, Briana and Aisha. He lives and works
in Walnut Creek, CA.

Contact Info

Ed Horley

ehorley@gmail.com