0% found this document useful (0 votes)

70 views

Sender Authentication Whitepaper

This document discusses strategies for building a spam-free email system using sender authentication technologies. It explains the concepts of IP-based and cryptographic sender authentication, and how they can work together with reputation and accreditation systems. The paper provides guidance on deploying authentication protocols for various stakeholders, including email senders, receivers, ISPs, and software vendors.

Uploaded by

Oleksiy Kovyrin

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

70 views

Sender Authentication Whitepaper

Uploaded by

Oleksiy Kovyrin

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 25

SES

��
��
��
DomainKeys
��

SPF

��
��

��

��
Contents
Introduction 3 Deployment: For Email Receivers 6
Audience 3 Two Sides of the Coin 6
How to Read this White Paper 3 Recording Trusted Senders Who Passed Authentication 6
A Vision for Spam-Free Email 4 Whitelisting Incoming Forwarders 6
The Problem of Abuse 4 What To Do About Forgeries 6
The Underlying Concept 4 Deployment: For ISPs and Enterprises 7
Drivers; or, Who’s Buying It 4 Complementary considerations for ISPs 7
Vision Walkthrough 5 Deployment: For MTA vendors 8
About Sender Authentication 8 Which speciﬁcation? 8
An Example 8 Conformance testing 8
History 8 Perform SRS and prepend headers when forwarding 8
How IP-based Authentication Works 9 Add ESMTP support for Submitter 8
The SPF record 9 Record authentication and policy results in the headers 8
How SPF Classic Works 9 Join the developers mailing list 8
How Sender ID works 9 Deployment: For MUA vendors 9
How Cryptographic Techniques Work 0 Displaying Authentication-Results 9
Using Multiple Approaches  Automatic switching to port 587 9
Reputation Systems  Deployment: For ESPs 20
Deployment: For Email Senders 2 Don’t look like a phisher! 20
First, prepare. 2 Delegation 20
Audit Your Outbound Mailstreams 2 Publish Appropriately 20
Construct the record 2 Deployment: For Spammers 2
Think brieﬂy about PRA and Mail-From contexts. 3 Two Types of Spammers 2
Test the record, part  3 Publish SPF and sign with DomainKeys. 2
Put the record in DNS 3 Stop forging random domains. 2
Test the record, part 2 4 Buy your own domains. 2
Keep Track of Violations 4 Reuse an expired domain. 22
Loose Ends: Publishing Records For Hostnames 4 Try to buy accreditation. 22
Loose Ends: Deferral Relays 5 Try to fake out reputation services. 22
To Fail or not to Fail? 5 Zombies should spam only their friends and family. 22
Expect to use DomainKeys or other crypto 5 Spread FUD about the edge cases. 22
Deployment Roadmap 23
ISP Best Practices and Code of Conduct 24

A maawg White Paper on

Sender Authentication Deployment

http://spf.pobox.com/whitepaper.pdf

Meng Weng Wong

[email protected]

Senior Technical Advisor

Messaging Anti-Abuse Working Group

Founder & CTO for Special Projects

pobox.com

December 2 2004 . release 1

Copyright © 2004 Meng Weng Wong

This work is released under a Creative Commons License.
Trademarks that appear in this document are property of their respective owners.
Sender ID has been asserted as a trademark in the US and other countries. ��
SPF is not known to be a registered trademark or service mark in the US.
Opinions expressed in this white paper are those of the author and
do not necessarily reﬂect the opinions of maawg or maawg’s member organizations.
In proportion as our inward life fails, we go more constantly
and desperately to the post-oﬃce. You may depend on it, that
the poor fellow who walks away with the greatest number
of letters, proud of his extensive correspondence, has not
heard from himself this long while.
Life Without Principle
HENRY DAVID THOREAU

Introduction

2004 saw a great deal of hue and cry about spam. Now the
dust is beginning to settle. A number of complementary ��
technologies are still standing. They will be rolled out in ��
2005. This white paper explains why they’re important, how
they work, and how you can put them to use. ��
The email infrastructure as originally designed lacks a ��
critical element: sender authentication. Sender authentica- ��
tion gives computers the ability to tell whether a message is
forged or authentic. Without that ability, receiver systems ��
cannot easily detect and block forgeries at SMTP time. Add- ��
ing that ability sets the stage for complementary technolo-
gies — reputation and accreditation systems. Together, these ��
technologies make it possible to build a spam-free layer on ��
top of the existing email system.
Sender authentication protocols will be widely deployed ��
in 2005. This document explains why they are important, ��
how they work, and how you can deploy them. It pays par-
ticular attention to SPF, Sender ID, and DomainKeys.

Audience

If you are a domain owner, systems manager, dns admin-

istrator, email administrator, or brand manager, you should
read this paper.

How to Read this White Paper

Part I, A Vision for Spam-Free Email, oﬀers a birds-eye-view

of the antispam landscape and lays out a strategy for reaching
a spam-free world. It walks through an end-to-end message
delivery scenario and shows how authentication, reputation,
and accreditation ﬁt together.

Part II, About Sender Authentication, explains the diﬀer-

ences between ip-based and crypto-based authentication
and discusses the most promising technologies.

Part III, Deployment, explains what email senders, receivers,

ISPs, MTA vendors, MUA vendors, and volume ESPs need to
do, and suggests a schedule for coordinated rollout.

maawg · Sender Authentication: What To Do 3

A Vision for Spam-Free Email

Content ﬁltering is reaching the end of the road. The Aspen

Framework will take its place. If you are familiar with the
Accountable Net concepts developed at the Aspen Institute http://www.aspeninstitute.org/Programt3.asp?bid=328
http://www.edventure.com/conversation/article.cfm?Counter=367986
in December 2003 and with the three-part model of authen-
tication, reputation, and accreditation, you can skip directly
to the next section, “About Sender Authentication.”

��

��
The Problem of Abuse

��

��
Anyone can send email to anyone else, within seconds, at

��
��
zero apparent cost. That is the greatest strength of the Inter-

��
net mail system. It is also its greatest weakness. Because the

��
system is biased in favour of delivery, it is prone to abuse in

��
the form of spam, viruses, and phishing scams. The very fea-
tures that made email successful now threaten its viability.

��

��
To combat abuse we must add accountability. On a so-

��
cial level, legislative approaches such as can-spam attempt to
punish spammers for their trespasses. On a technical level,

��
sender authentication protocols give computers new ways to
automatically distinguish forgeries from authentic messages.

��
��

��
��
The Underlying Concept

��

��
If you step back and squint, every plan for solving spam looks
roughly the same.
Senders are asked to do X. Receivers are asked to check
for X. If X is missing, receivers are to assume the message
is spam. X is meant to be hard for spammers and easy for
good guys.
Approaches mostly diﬀer about what exactly goes into X.
The challenge is to make X as lightweight as possible while
��
��

��

��
��
remaining robust and secure.
Under the Aspen Framework, X is two things together:
authentication and reputation. (The third thing, accredita-
tion, is used as a buﬀer for when the reputation part fails.)
Authentication, in turn, enjoys a surfeit of competing and
complementary technologies.
The vision described here is actually an amalgam of three
related visions: the gospel according to Sender ID, the gospel
according to SPF, and the gospel according to DomainKeys.

Drivers; or, Who’s Buying It

Receivers who want to reduce costs and improve their user

experience are expected to embrace the vision. Senders who
want to improve deliverability are also expected to go along.
Between the two, network eﬀects will drive both senders and
receivers in the direction of sender authentication.

maawg · Sender Authentication: What To Do A Vision for Spam-Free Email 4

Vision Walkthrough

The vision for a spam-free email system contains many parts. … All experience hath shewn, that mankind are more
This walkthrough describes the life cycle of an email message disposed to suffer, while evils are sufferable, than to
under a strong version of the vision. In practice, it may be right themselves by abolishing the forms to which they
possible for you to alter or selectively weaken certain parts of are accustomed. […] it is their right, it is their duty,
the model to suit local conditions. to throw off such Government, and to provide new
Guards for their future security.
An MUA submits a message to an MSA using SMTP
AUTH. DECLARATION OF INDEPENDENCE

At present, many Mail User Agents (MUAs) are conﬁgured MUA: (n) Mail User Agent. What the end-user thinks of as “my email program” and
what ISPs think of as “the email client”. Popular MUAs include Eudora, the Outlook
to submit messages to a Mail Submission Agent (MSA) over family, and Mac Mail. Determines what the end-user sees of an email message. The
port 25. The MSA accepts the message because the ip address entity responsible for signing and verifying S/MIME cryptographic authentication.
of the MUA is trusted. Possibly also the entity responsible for verifying Sender ID (PRA) authentication.

The vision calls for MUAs to authenticate themselves

with a username and password to the MSA over port 587.
Armed with that username, the MSA can better implement ��
outbound anti-abuse policies such as rate limiting. An au- ��
��
dit trail is also easier to follow. VPN submission is a good ��
alternative.
��
An accountable sender has published authorization ��
records in DNS.

At present, any host on the net can claim to be a Mail Trans- MTA: (n) Message Transfer Agent. What ISPs think of as “the email server” and what
end-users often don’t think of at all. Popular opensource MTAs include Sendmail,
fer Agent (MTA). Open relays, open proxies, and zombies Postﬁx, Qmail, and Exim. Popular commercial MTA vendors include Sendmail,
are hard to distinguish from “oﬃcial” MTAs run by respon- Openwave, Ironport, Microsoft Exchange, and others. Can operate as a sender or as a
sible entities. Numerous DNS Block Lists (DNSBLs) attempt receiver. When receiving, responsible for verifying SPF and other authentication.

to identify the oﬀenders, but they are inherently limited to MSA: (n) Message Submission Agent. What an MUA thinks of as an “SMTP server”.
Usually set up by an ISP to receive mail from end-users. Often whitelists the dialup/
a reactive mode of operation. Furthermore, inaccurate list- broadband range. May also be the outbound edge MTA. Unlike a receiving MTA,
ings often cause “collateral damage,” and they can be hard to must require SMTP AUTH when accepting connections from outside trusted network.
correct. Finally, playing “whack-a-mole” with 4.3 billion IP See RFC2476.

addresses is a diﬃcult scaling problem. On the ﬂip side, ISPs Zombie: (n) An end-user machine under the control of a virus, often used to send
spam. It is estimated that up to one in three machines might be infected with worms
may maintain lists of IP addresses of known good senders. and viruses. Zombies can send spam direct-to-MX or routed through an ISP MSA.
Maintaining those lists is a time-consuming endeavour.
The vision calls for accountable participants in the email
system to • authorize certain MTAs as designated senders,
��
• add cryptographic signatures to outgoing messages, or • do ��
both. ip-based authentication lets receiver MTAs distinguish ��
��
accountable MTAs from hijacked machines. Crypto-based ��
authentication lets receivers authenticate message content ��
��
without reference to the sending mta. The two approaches ��
��
��
��
��
are complementary and reinforce each other. Both involve ��
publishing records in DNS.

An authorized outbound edge MTA transfers a message to Edge MTA: (n) On the sending side, an MTA which takes the role of an SMTP client to
the public Internet. On the receiving side, a server MTA which accepts connections
an inbound edge MTA. from the public Internet from sending MTAs.

It takes a fair amount of expertise for a human to extract the

smtp client from “Received” headers and guess whether it is

maawg · Sender Authentication: What To Do A Vision for Spam-Free Email 5

authorized to send mail on behalf of the purported sender.
At present, there is no easy way for computers to do the same
thing.
Also, while it is possible to say that a given message, if
signed, is authentic, it is not currently possible for computers
to conclude that a message not signed is a forgery.
The vision calls for receiving MTAs to automatically veri-
fy incoming smtp sessions against the information published ��
��
in dns by senders. This constitutes the sender authentication ��
step. There are three main classes of results: pass, fail, and ��
��
unknown. ��
��
��
The receiving MTA also makes a receiver policy decision ��

about senders.

All senders can authenticate themselves. Spammers will too. Today, many ISPs keep local whitelists and blacklists.
These lists are not shared with their peers, and so
Therefore authentication checks alone are not suﬃcient. their utility is limited. Many ISPs also use public
The vision calls for the receiving MTA to also decide if it whitelists and blacklists.
likes or dislikes the sender. This decision can be based on
a purely local opinion. It can also be informed by opinions
from third parties.

The end-user addressbook can be an input to that deci-

sion.

If you are in my addressbook, I would probably be happy to In fact, if you’re in my best friend’s addressbook, I
would probably be happy to read mail from you.
read mail from you. Emerging technologies such as LOAF (http://loaf.
The vision calls for the receiver’s mua to help distinguish cantbedone.org) and http://www.web-o-trust.org/
wanted mail that passes authentication from unwanted mail are good examples of experiments in this space.

that also passes authentication. If the mta happens to know

what’s in the end-user’s addressbook, then that decision can
be optimized up into smtp time.

Reputation and accreditation services record assertions

about senders.

At present, reputation services exist in the form of DNSBLs. A useful review of many blacklists can be found at
http://www.sdsc.edu/~jeff/spam/Blacklists_Compared.html
They are based on IP address and generally assert an opin-
ion that a given IP address should be blocked. Accreditation
services also exist in the form of DNSWLs. They vouch for Reputation service: (n) offers opinions about senders, usually based on
empirical observation of past behaviour. Operates on behalf of receivers.
assertions made by legitimate senders who care very much May be expressed as spamtrap counts, a binary vote, a ratio of complaints to
about deliverability. They may be backed by some kind of total message volume, etc. Receivers need to decide for themselves what
financial bond. opinions mean.
Examples: movie reviews, DNSBLs (Spamhaus, Spamcop).
The vision calls for these services to also • keep track of
senders by domain name and to • indicate if, and why, certain Accreditation service: (n) offers assertions about senders, usually based on
representations made by senders. Operates on behalf of senders. May be
domains should be considered good. This makes it possible expressed as a list of reasons for predicting future behaviour.
for receivers to recognize known good senders and confer a Example: “rated R”, Bonded Sender, Habeas, Verisign VDL.
sort of “first-class” status to their messages. Messages that How to tell the difference? Very crudely: follow the money! If the sender
pass the joint test of authentication and reputation can then pays to be listed, it’s accreditation. If the receiver pays them for their
choose to bypass other more expensive and potentially error- opinions, it’s reputation.

prone content-based antispam tests.

maawg · Sender Authentication: What To Do A Vision for Spam-Free Email 6

The receiving MTA records the results of the joint tests in
the message headers.

At present, MTAs do not generally record the results of DNS-

BL lookups in a user-visible form. If a sender is found on a
DNSBL, the message is simply blocked or dropped. Other- ��
��
wise it is let through. The reasons for accepting or rejecting a ��
message are generally not exposed to end-users. ��
��

The vision calls for receiving MTAs to record attach au- ��
��
thentication and reputation metadata to messages. The most ��
natural place to put that data is in the headers. Spammers ��

will try to spoof those headers, but that problem can be

solved because communications between a receiver mta, a
message store, and an end-user mua occur within a conﬁned
space.

The receiving end-user’s MUA displays a conﬁdence

mark.

At present, muas lack a consistent, industrywide, visual lan-

guage for describing the confidence an end-user should place
in a message. We need the equivalent of the https padlock
icon.
The vision calls for receiver muas to add an explanatory
visual element to displayed messages. That element can help ��
fight forgeries by warning of authentication fails. This helps ��
��
combat phishing and spoofing. Muas should also distinguish ��
a dual-pass result (where both authentication and receiver ��
��
policy tests approve the sender) to help fight false positives ��
��
and improve deliverability of legitimate mail. ��
��
��
When the mua is actively involved in analyzing and clas-
sifying the message, it has all the information it needs to do
this. When the mua is operating passively downstream from
the point where that decision is made, it can simply display
the information recorded in the message headers.

“Not Junk”: The opposite of the Junk Mail folder.

At present, muas may ﬁle suspected spams into a Junk Mail

folder based on Bayesian filtering and other logic.
The vision calls for muas to file dual-pass messages into
the semantic opposite of the Junk Mail folder – “spamproof ”,
“first-class”, or “Not Junk”.
At present, the default user expectation for an email inbox
is that it will accept all messages by default, unless a set of
complex heuristics intervenes and identifies some messages
as spam.
The vision calls for the market to move toward a default-
reject orientation. Once the “Not Junk” folder gains wide ac- It is rumoured that 0 to 5% of AOL and
Earthlink’s userbase have switched to
ceptance, the next step is to think about simply rejecting any whitelisting-only spam filtering.
messages that would not make it into that folder.

maawg · Sender Authentication: What To Do A Vision for Spam-Free Email 7

About Sender Authentication

ip-based authentication validates the channel that transport-

ed the message, and tends to focus on the sender. Crypto-
based authentication focuses on the original author.

An Example

Google Mail (gmail.com) is an early and enthusiastic adopt- Sendmail, Inc is another enthusiastic pioneer in sender authentication. See
http://www.sendmail.net/ for details on the Messaging Integrity Pilot Program.
er of sender authentication technologies. They publish spf
records and sign messages with DomainKeys. Here are some
headers from a message they sent from mengwong@gmail to
[email protected]:
Delivered-To: [email protected]
Received-SPF: pass (dumbo.pobox.com: domain of [email protected] designates 64.233.170.199 as permitted sender)
Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199])
by dumbo.pobox.com (Postfix) with ESMTP id 9C02E198
for <[email protected]>; Wed, 27 Oct 2004 23:09:16 -0400 (EDT)
Received: by rproxy.gmail.com with SMTP id 80so309rnk
for <[email protected]>; Wed, 27 Oct 2004 20:09:12 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
s=beta; d=gmail.com;
h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding;
b=Vlj/++WbtRXfAdBGd+9GjE2ggK8e5Fwe2H68kpHOh7yFu9NHrRwjAeWpcar84+s+UWEsTWLLBdwGnabOfLeGOlOLSdxeUbrQ4ibPO
QUOF10ZkalycNmrpG3tIvuE5ta9w1+kLEwJs1d7PJU24XyBsqp+mdyMWT6mroXi0GXzBps=
Received: by 10.38.98.18 with SMTP id v18mr773189rnb;
Wed, 27 Oct 2004 20:09:12 -0700 (PDT)
Received: by 10.38.8.32 with HTTP; Wed, 27 Oct 2004 20:09:12 -0700 (PDT)

Note the Received-SPF and DomainKey-Signature lines.

History

In 998 Jim Miller had the idea of designating outbound There was another bookish lad in the town, John
mailers. In 2002 Paul Vixie wrote up the idea in a paper Collins by name, with whom I was intimately
titled “Repudiating Mail-From”. In 2003 Hadmut Dan- acquainted. We sometimes disputed, and very fond we
isch independently authored a specification called “Reverse were of argument, and very desirous of confuting one
MX” (RMX). Around the same time, Gordon Fecyk wrote another, which disputatious turn, by the way, is apt to
a similar specification called “Designated Mailer Protocol”
become a very bad habit, making people often extremely
(DMP). Later that year Meng Weng Wong combined some
features of RMX and DMP into SPF. SPF originally stood disagreeable in company by the contradiction that is
for Sender Permitted From, but changed its name to Sender necessary to bring it into practice; and thence, besides
Policy Framework. Microsoft® also wrote a specification, souring and spoiling the conversation, is productive of
“Caller-ID for Email” (CID), as part of a Coordinated Spam disgusts and, perhaps enmities where you may have
Reduction Initiative proposal (CSRI). While they differed in occasion for friendship. I had caught it by reading my
a number of ways, all of these proposals shared the concept father’s books of dispute about religion. Persons of good
of using dns records to authorize smtp clients to be mtas. sense, I have since observed, seldom fall into it, except
While all this was going on, Yahoo!® was developing a lawyers, university men, and men of all sorts that have
crypto-based approach, called DomainKeys (DK). In early been bred at Edinborough.
2004 rough consensus appeared in the email industry to
Autobiography
proceed with both ip-based and crypto-based approaches.
To make things easier, Microsoft® and Meng worked to BENJAMIN FRANKLIN
merge cid and spf into a single proposal in the marid work-
ing group of the ietf. Work began in earnest in May and a
converged specification was concluded in October under the
name Sender ID™.

maawg · Sender Authentication: What To Do About Sender Authentication 8

This forces spammers to have their own
domains and DNS servers, which means
How IP-based Authentication Works ��
we can identify them more easily.
��
This is a big win!
��
Most legitimate mail from a given domain enters the Internet ��
– JONATHAN CURTIS, Georgia Voter

from a relatively small set of servers. If we can identify those

servers and list them in machine-readable form in dns, re- ��
ceivers can easily check incoming messages against that list. ��
Messages that come from an approved server are considered ��
��
authenticated. Messages that don’t come from an approved ��
server may be considered forgeries. Exactly how a receiver ��
treats suspected forgeries depends partly on what the sender ��
has speciﬁed as a default in such cases. ��

The SPF record

SPF records use a simple syntax which any dns administra- SPF features a “best-guess” technology which basically says: if a
domain does not publish SPF records, try “a/24 mx/24 ptr” anyway.
tor should find intuitively familiar. Records are easy to set up If that returns a PASS, consider that PASS a useful first approximation.
by hand. Here is an example record: v=spf1 mx This technique significantly reduces the deployment burden for
It means that the mx servers for the domain are explicitly technologically unsavvy senders who are lucky enough to obtain a
PASS using best-guess alone.
permitted to send mail from that domain.
SPF Check: (n) a test of the validity of an IP address against a domain name. If the
domain name comes from the return path, you’re doing an SPF Classic or SPFv1 check.
How SPF Classic Works If it comes from the PRA, you’re doing a PRA check.

Every smtp transaction begins with a mail from command. If the MAIL FROM is empty, SPF Classic falls SPF record: (n) a v=spf1 record.
back to the HELO argument. This is useful for spf2.0 records are for special cases
SPF Classic examines the return-path identity given in the handling bounce scenarios and closes a only. (Caller-ID records using the
mail from command. It tests the client ip against the spf re- loophole whereby spammers could just send XML format are no longer used.)
cord for the domain in the return-path. As it focuses on the mail with a null MAIL FROM.

return-path, SPF Classic is most obviously useful for helping Bottom Line: The SPF records that you create need to work in
both MAIL FROM and HELO contexts. Someone might be
ﬁght bounce ﬂoods caused by undeliverable forgeries. But it looking at your SPF record because your domain showed up in
is also useful in cases where the recipient of a forgery is deliv- a MAIL FROM, or because the MAIL FROM was blank and your
erable. Even though the forgery may not result in a bounce, domain showed up in the HELO. If none of your servers
HELOS using a given domain name, then you only have to
some harm can still be prevented. worry about MAIL FROM use of that name. If you’re setting up
an SPF record for a hostname, you probably do want to ensure
the record will work for HELO. You can do this easily by
How Sender ID works adding an “a” mechanism.

When an mua displays a message, it shows who sent the Politics. Some have characterized Sender ID as “SPF with PRA bolted on.” The IETF
community has roundly criticized the PRA on both technical and licensing grounds.
message, usually by extracting the From: header. Every well- Some members of the technical community assert that the very idea of using PRA for
formed email message contains a From: header. But a mes- header validation is flawed. Other observers comment that the patent license which
sage may also contain a Sender: header. In that case, an mua surrounds PRA makes it unpalatable to implement.
A potential security vulnerability may occur if an MTA validates a PRA address which
may say to the end-user “From Sender on behalf of From”. is not actually displayed to the end-user. If an upstream MTA validates the PRA and
The PRA is Microsoft took this concept one step further and defined the records the authentication results in a header, and if an MUA displays that authentica-
drawn not just tion result as a mark of confidence, that MUA must be very careful to also display the
from the From
Purported Responsible Address (PRA). A Sender ID com- validated address to the end-user. Until more MUAs display the PRA, the author expects
and Sender pliant mua displays: “From PRA on behalf of From”. Sender few MTA software engines to implement PRA checking. Commercial MUA software,
however, will probably find it useful, at least until cryptographic solutions designed
headers, but ID as originally conceived runs an spf test, but uses the PRA expressly for 2822 content checking mature.
from the
Resent-From instead of the mail from. At least one major commercial MUA vendor has publicly stated it will proceed with
and Resent- Sender ID was recently resubmitted to the IETF. It now PRA checking. Microsoft appears to be preparing to turn on Sender ID checking in
Sender Hotmail, Outlook, and Exchange. The latest versions of Outlook are expected to display
headers as well.
specifies that both the return-path and the PRA may be used. the PRA where available, rather than just the Sender header.
See the Sender Software that implements only SPF Classic can therefore be Sendmail, Inc. has released experimental milters for Sender-ID that check both the
ID specifica- MAIL FROM (SPF Classic) and the PRA. Other commercial MTA vendors have done the
tion for details.
called Sender ID compliant. In practice, most people associ- same. Generally, however, SPF Classic is more widely supported than PRA at this time.
ate Sender ID with the PRA, and SPF Classic with the mail
from, or return-path. The Patent Situation. Microsoft has two patents pending on Sender ID. While the
patent license offers Royalty Free terms, according to Lawrence Rosen Esq., the
The author recommends that mua software implement sublicensing provision of the patent license makes PRA incompatible with GPL free
Sender ID with pra checking. The author recommends that software such as Exim. Apache SpamAssassin, for example, have stated that they will
mta software implement Sender ID with mail from check- not implement PRA checking, and will stick to SPF Classic in version 3.0 and above.
Note that the patents only cover the PRA and do not restrict SPF Classic in any way.
ing, aka SPF Classic. The author also recommends watching Some individuals are planning to work with http://www.pubpat.org/ to challenge the
to see how crypto develops. patent on grounds of prior art and obviousness.

maawg · Sender Authentication: What To Do About Sender Authentication 9

How Cryptographic Techniques Work

All cryptographic approaches to authentication agree on the ��
��
basic concept: sign some portion of the message content and ��
��
��
present that signature for veriﬁcation. The approaches dis- ��
agree about what gets signed, where the signature goes, and ��
��
��
how veriﬁcation is done. ��
PGP and GPG sign the message body only and put the
��
signature directly in the body. Keys are stored in end-user
��
keyrings or in public keyservers; key management uses a
peer-to-peer web-of-trust architecture. The signature in- ��
cludes a description of the signing entity, but muas tend not
��
to use that author data from the signature to override the ��
��

From: header. ��

S/MIME signs the message body also, but presents the ��
signature in a logically distinct mime part. Keys are signed ��
��
by a certificate authority, so key management follows a hier- ��
archical model similar to ssl. Signatures that do not match ��
��
the From: header tend to result in some sort of mua user in- ��
terface warning.
DomainKeys, originally championed by Yahoo!, signs
the body and some message headers. It puts the signature PGP and S/MIME have been around for a long time, but they are not widely used.
While most MUAs today support S/MIME natively, the vast majority of mail sent is not
in a DomainKey-Signature header. Keys can be self-signed, signed. Why not? I don’t know. Maybe the average end-user doesn’t sign their
as in PGP, and published in dns following a decentralized, outbound mail because they find it inconvenient to manage keys and enter
opportunistic encryption model. If a message fails signature passphrases. But why don’t the bulk mailers, even the well-organized volume ESPs,
sign their mail? Maybe they perceive a significant population of MUAs that don’t
verification, it should be rejected by the receiving mta dur- support S/MIME, and fear customer complaints. I am not aware of any published
ing smtp time, but in practice will probably result in some results that give a basis for this fear.
sort of warning sign in the mua. In 999, the US Department of Defense published a policy mandating future use of
BATV signs the return-path only and places the signature PKI technologies. They chose S/MIME over PGP because they rejected the PGP web of
trust model in preference for the hierarchical Certificate Authority model. Use of
in the return-path. If a sender always batv signs its return PKI certificates to access DoD restricted access web sites became mandatory October
paths, any bounces that come to a non-batv-signed address , 2004. The DoD may similarly mandate S/MIME for email in the future.
must be bogus. Though there is provision for a public mode,
BATV primarily uses a private-secret key scheme because See http://mipassoc.org/batv
only the signing system absolutely needs to authenticate its
signatures. BATV is a lot like VERP, but with a signature. Mailing lists use Variable Envelope Return Path to track bouncing subscribers.
The latest evolution of SES also places the signature in See http://ses.codeshare.ca/
the return-path, but signs the message headers and body as
well, much like DomainKeys. SES also uses a private-secret
key scheme, but validation can occur at smtp time! How?
The sender system publishes an exists mechanism using Bottom line: cryptographic signing is performed by the MTA. In IP-based protocols,
senders have to go fiddle with DNS. With crypto, senders have to put their public keys
SPF; that mechanism instructs receivers to include the full in DNS, and also have to upgrade to an MTA that supports signing.
localpart in a dns query against the sender. When the send-
er’s dns server gets a query, it validates the signature. If a
sender system signs all outgoing mail with SES and runs a
custom SES-enabled dns server which can validate localpart
queries, it no longer needs to worry about forwarding false
positives.
Jim Fenton’s Identified Internet Mail is similar to DK. IIM repeats the signed headers within the headers. This is better for mailing lists. It
also includes the public key with every message. DK and IIM are similar enough that
Microsoft’s Email Postmarks is essentially mta-to-mta many industry insiders hope and expect them to merge in early 2005.
S/MIME which may be easier to implement in Exchange.
The IETF MASS SIG has engaged the above proposals. See http://www.imc.org/ietf-mailsig/index.html and
http://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatrix.htm

maawg · Sender Authentication: What To Do About Sender Authentication 10

Using Multiple Approaches

The Achilles’ Heel of ip-based schemes is forwarding: unless

the forwarder rewrites the return-path, the final receiver will
consider the message a forgery because it doesn’t come di- Verbatim forwarding Mailing lists
…is a common practice: anyone who …tend to append text to the body of a
rectly from the original sender. has seen an /etc/aliases or .forward message. This is a problem for
The Achilles’ Heel of cryptographic schemes is content file knows what it is. Messages sent to a DomainKeys because content munging
munging: many mailing lists alter the message content during forwarding alias are remailed to the final invalidates the signature. DomainKeys
destination. Unfortunately, those expects mailing list managers (MLMs) to
transit. Unless the mailing list manager re-signs the message, messages are often reinjected without any re-sign messages and claim authorship
“To unsub- the final receiver may consider the message a forgery because indication that forwarding occurred: the after any content munging. This is not
scribe, send a return-path remains unchanged, and no convenient for mailing lists.
message to ...”
the content has changed since the signature was created. special headers are added to the message. Mailing lists reset the return-path so
SPF Classic, an ip-based scheme, works well with mailing Forwarding is a problem for SPF that bounces go back to the MLM, not the
Classic and Sender ID because forwarded original author. This is good for SPF
lists, because mailing lists always change the return-path to messages are difficult to distinguish from Classic.
be the mailing list bounce handler. DomainKeys, a crypto- forgeries! Under SPF Classic, forwarders While any mailing list worthy of the
based scheme, works well with forwarding, because forward- can help by implementing SRS – Sender name resets the return-path, only some
Rewriting Scheme. Under Sender ID, mailing lists add a Sender: header.
ing doesn’t usually change message content. forwarders are expected to prepend a EzMLM, a widely-used MLM, does not.
Because one scheme’s meat is another scheme’s poison, it Resent-From header. Neither is Yahoo!Groups doesn’t add Sender: either,
convenient for forwarders. Receivers can though in theory that can be fixed easily
seems only prudent to use multiple schemes: that way, the also help by simply whitelisting known … if Yahoo! cooperates.
CSV is one strengths cancel out the weaknesses. This is the basic idea forwarders by IP address or PTR name. Sender ID asks all mailing lists to add a
proposal that Forwarding is better under Domain- Sender: header. This is not convenient
focuses on the
behind Unified SPF. Unified SPF is a syncretist theory that Keys because forwarding generally for the installed base of mailing lists who
HELO or EHLO also admits helo, ip, ptr, and pra checking. doesn’t munge content. do not add Sender:.
hostname The author recommends that prudent senders do at least Bottom line: good for DK, bad for SPF. Bottom line: good for SPF, bad for DK.
argument as the
identity for two things: they should publish spf records and eventual-
verification. ly sign messages with DomainKeys. Prudent receiver isps So let’s do DK … and let’s do SPF!
Imagine this: v=spf1 a mx dk -all
should check SPF Classic and DomainKeys at the mta.

Reputation Systems ��

��
Authentication alone is not enough. Reputation systems are
��
a key component of the Aspen Framework. They help receiv-
ers decide if a mail from an authenticated sender is desirable �
or undesirable. Just as banks rely on credit rating agencies,
��

�
receivers rely on reputation systems. ��
A detailed discussion of reputation systems is outside the
scope of this white paper. But here is the main point: ﬁrst-
��
generation reputation systems tried to enumerate all the ip

�
��
addresses which they considered bad. Next-generation rep-
��
utations will try to enumerate all the domain names which
they consider good. There are many ways to do this. All of �
them are interesting.
What if a domain has no reputation? If it is patient, it can ��
��
gradually acquire one simply by sending enough good mail ��
to be noticed over time. After all, sensible receivers should
not reject outright mail from senders without a reputation; ��
receivers might just graylist or filter more aggressively. But if
the domain is impatient or wishes to refute a bad reputation, ��
it may choose to sign up with an accreditation service.
�
��
The Karma Project is an aggregation BondedSender.com and Habeas are ��
service which reduces the burden on examples of services which vouch on ��
receivers. Instead of talking to N behalf of senders.
services to get N results, receivers can
talk to a single service to get N results. If a sender domain publishes and signs
Please contact the author for details �� using both IP-based and crypto-based ��
on feeding into and reading from the methods, and if a receiving domain finds
Karma system. that neither method passes, it can be very
confident that the message is a forgery.

maawg · Sender Authentication: What To Do About Sender Authentication 11

Deployment: For Email Senders

All senders and receivers of email — from the largest ISP to

the smallest personal domain — should deploy one or more Under DomainKeys: you need to do diﬀerent things for DomainKeys.
These sidenotes brieﬂy describe what to expect under DK. DK is still
forms of sender authentication in 2005. You can deploy SPF under development and may incorporate features from IIM. When the
and Sender ID today. This section tells you how. Comments crypto approaches settle, expect a future version of this whitepaper to
on DomainKeys are also provided for comparison. include detailed deployment instructions. Meanwhile, keep in mind that
when people say DomainKeys, they may mean a future, more mature
In this example, you are sender.com. version.

First, prepare.

Stopping forgery means stopping all forgery: good and bad.

Over the years people may have gotten used to the lax nature
of email, and your security-minded efforts to close loopholes ��
may encounter resistance from some people who find those
loopholes quite comfortable and you quite annoying. You
��
are not alone: this is a classic change management problem.
Sooner or later every computer professional encounters the
eternal tension between security and convenience. If you
want to prevent bad guys from forging your identity, and if
you want to do it by limiting the approved routes for out-
bound mail, your end-users are going to have to use those
routes or risk being classified as one of the bad guys.

Audit Your Outbound Mailstreams Under DomainKeys: you need to audit your outbound mailstreams too.

To begin, you need to identify all the ways in which legiti-

mate mail from sender.com goes out onto the Internet. Out- corporate user MUA
bound mail usually comes from two sources: humans and
corporate user MUA
machines.
Mail from humans. Suppose end-users with addresses automated process
corp.sender.com
like [email protected] set the smtp server in their mua The Net
smtp.sender.com
to smtp.sender.com. That is one mailstream: you need to customer MUA
ﬁnd out how mail submitted to smtp.sender.com appears to
customer MUA
the outside world. In the simple case, smtp.sender.com has
public dns records that identify its outbound ip addresses. customer MUA

Mail from machines. Machine-generated processes may

also originate mail from addresses at sender.com – for exam- Under DomainKeys: you upgrade your MTAs to sign all outbound mail,
and you publish public keys in DNS. Upgrading MTAs is generally
ple, [email protected]. You need to identify regarded to be more work. Still, this approach is worth the eﬀort.
all such processes and the servers through which they inject
messages into the Internet. In the simple case, a corporate
system corp.sender.com may be responsible for customer If both corp and smtp.sender.com send mail that looks like this:
service and automated billing. MAIL FROM:<[email protected]>
From: Some Sender <[email protected]>

Construct the record Assuming the following existing DNS entries:

sender.com A 192.0.2.222
sender.com MX 10 smtp.sender.com
You’ve enumerated all the servers that originate mail from smtp.sender.com A 192.0.2.2
sender.com. Now you’re ready to describe them in spf syn- corp.sender.com A 192.0.2.222

tax. A number of wizards are available online to help you Here are some examples of how sender.com’s SPF record might look:
create your spf record. If you have a complex conﬁguration, sender.com TXT “v=spf1 a:corp.sender.com a:smtp.sender.com ?all”
sender.com TXT “v=spf1 a mx ~all”
you should see the SPF protocol speciﬁcation for full details. sender.com TXT “v=spf1 ip4:192.0.2.0/24 -all”

maawg · Sender Authentication: What To Do Deployment: For Email Senders 12

Think briefly about PRA and Mail-From contexts. Bottom Line: Unless you’re an outsourced Email Service
Provider, you probably don’t need to worry about
customizing your record for the PRA. Getting it right for
You’ve identified and described the servers that send mail MAIL FROM should be your first concern. But if for
from sender.com. But there are actually two identities in- whatever reason you want to explicitly disable PRA checks,
just add a blank record: sender.com TXT “spf2.0/pra”
volved: the mail from return path in the rfc282 envelope,
and the pra identity extracted from the rfc2822 headers. In PRA: The Purported Responsible Address FAQ: Do I need to publish an spf2.0/pra
is used primarily by Microsoft MUA record if it contains the same data as my
the vast majority of cases, when you compose a mail mes- software. Opensource and MTA software v=spf1 record? No. Software that operates
sage, the return-path and the pra are the same, and you only generally prefer to examine the MAIL FROM in PRA context will grok v=spf1 records just
need to create a single v=spf1 record. But if your situation return path. fine. Use spf2.0/pra only to override.

is complex and you routinely create messages whose mail Under DomainKeys: DK deals only with 2822 information, and
with only the From: and Sender: headers. It leaves 282
from and pra diﬀer, you may need to create an spf2.0/pra validation to SPF. One might say that DomainKeys attempts to
record as well. In that case, your record might look like: validate authorship, and SPF Classic attempts to validate the last
v=spf1 a:corp.sender.com a:smtp.sender.com ~all hop sender.
spf2.0/pra ip4:192.0.2.0/24 ~all

Together, these records mean:

• if the smtp client is corp.sender.com, then sender.com may legitimately appear in the return-path.
• if the smtp client is smtp.sender.com, then sender.com may legitimately appear in the return-path.
• if the smtp client is anything else, sender.com should not appear in the return-path.
• if the smtp client is in the 192.0.2.0/24 subnet, then sender.com may legitimately appear in the pra headers.
• Otherwise, sender.com should not appear in the pra headers.

Test the record, part 

Figuring out your spf record is the ﬁrst step, but how do you
know it’s doing what you want? There are a number of spf
validation tools on the web. You paste your proposed spf Some validation tools are listed at
http://spf.pobox.com/certification.html
record into the tool, and it tells you whether it’s syntactically
correct.

Put the record in DNS

SPF records are published in dns as txt records. There are A new Resource Record type is being assigned, but
adoption of new RR types is generally held to be a
two common scenarios: domain hosting and direct control. slow process. So SPF records make do with TXT,
If your domain is hosted, your hosting provider should which is widely supported and not explicitly reserved
oﬀer a web interface. Most hosting providers have started for anything else.

offering a txt option so customers can publish spf records. A list of hosting providers which support TXT records can be found
at http://www.spf.idimo.com/txt-supporters.html
If your domain hosting provider does not, you may want to
transfer management of your domain to another provider,
or petition them to add support for txt.
If you run the nameservers for your domain, you ought There is no central registry for publishing SPF
information. Your SPF record is published directly in
to be familiar with editing zone files. Common nameserv- the DNS for your domain, which ultimately you
ers include bind and djb’s tinydns. An spf record in a bind control.
zonefile might look like this:
sender.com. IN TXT “v=spf1 ip4:192.0.2.0/24 a mx ~all” Under DomainKeys: messages acquire an
additional header that signs the message content.
The equivalent record in tinydns might look like this: For the example on p 9, the corresponding public
ʼsender.com:v=spf1 ip4\072192.0.2.0/24 a mx ~all:300 key appears in DNS:
You can confirm that the record appears in dns by using ns- beta._domainkey.gmail.com. IN TXT
“t=y; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC69TURXN3oNfz+G/m
lookup or dig. Until you’re comfortable with the record, 3g5rt4P6nsKmVgU1D6cw2X6BnxKJNlQKm10f8tMx6P6bN7juTR1BeD8ubaGqtzm2rWK4Li
you should keep the ttl low, so you can change it quickly MJqhoQcwQziGbK1zp/MkdXZEWMCflLY6oUITrivK7JNOLXtZbdxJG2y/
RAHGswKKyVhSP9niRsZF/IBr5p8uQIDAQAB”
if you need to.

maawg · Sender Authentication: What To Do Deployment: For Email Senders 13

Test the record, part 2

Getting your spf record into dns is a big step. Now every-
body can read it! Again, you should use a validation tool to You should also register your newly SPF-enabled domain at
the online registry. Go to http://www.spftools.net/ where
check it. But this time, instead of pasting your record into over 200,000 other domains have self-registered. By some
the validator, you just give it the name of your domain. The estimates, the true number of SPF-enabled domains has
validator fetches the record from your dns directly and con- already crossed the one million mark.

ﬁrms that it makes sense.

Keep Track of Violations

SPF-enabled receivers should now be able to read your re-

cord and test incoming mail against it. On today’s Internet,
we can assume that our domains are being routinely spoofed
by malware. If you want to ﬁnd out who’s spooﬁng your do-
main, you can add a mechanism to log any spoof attempts
seen by spf-enabled receivers. You’ll need a nameserver that
logs all queries made against it; and you’ll need to set up a
domain that causes queries to hit that nameserver. Suppose
that domain is logger.sender.com. You can add an exists
mechanism before the terminal all so your spf record looks
like this:
v=spf1 a mx exists:%{s}.S.%{i}.I.logger.sender.com ~all

The macros %{s} and %{i} expand to the sender address and Macros: the macro feature lets you insert data into the
domain arguments for mechanisms. %{i} expands to the
the client ip address, respectively. client IP address. %{s} expands to the full sender email
You may find that you have legitimate end-users using an address. See the Protocol Specification.
outbound gateway you had not previously identified: maybe
they’re using some third-party smtp server, or maybe you If you don’t want to set up DNS logging yourself, you can
use a third-party logging service.
didn’t know about a legal outbound route. Setting up a log- See http://spf.pobox.com/certification.html
ging exists helps you discover these cases. In the first case,
where an end-user is using an unapproved smtp server, your Dear Customer,
isp.com prides itself on keeping up to date with the latest security
job is easy: tell the end-user that for security reasons he now practices. As part of our work with our peers and partners to help fight
needs to use sender.com’s smtp gateways to send sender. spam, we are strengthening our security policies. We appreciate your
com mail. In the second case, you can just add the new out- cooperation in making the following changes:
– please ensure that your SMTP server is set to smtp.isp.com port 587…
bound gateway to your spf record. – please run Windows Update…
When you send mail from your [email protected] address, it is important
that you send it through isp.com’s SMTP servers. This helps authenticate
Loose Ends: Publishing Records For Hostnames your messages and ensure that they are correctly delivered. If you send mail
through any other SMTP servers, antispam software on the receiving end
may classify your messages as spam.
This example has demonstrated how to publish an spf record
for sender.com that works for both SPF Classic and Sender
ID. That’s an excellent start, but it doesn’t end there! Your
primary domain name is certainly the first thing you should
take care of. But to be really thorough, you should put spf
records on the hostnames under sender.com.
In this example we’ve seen two hosts: corp.sender.com
and smtp.sender.com. Both are used for outbound relaying:
they send mail from addresses at sender.com. But they may
also send non-delivery notifications (NDNs) directly. Mes-
sages from mailer-daemon are typically addressed from the
hosts themselves, and look like this:

maawg · Sender Authentication: What To Do Deployment: For Email Senders 14

HELO smtp.sender.com
MAIL FROM:<>
If corp.sender.com sends mail that looks like this:
From: <[email protected]>
HELO corp.sender.com
MAIL FROM:<>
To accommodate cases like that, you should publish spf re- From: Mail Delivery Subsystem <[email protected]>
cords for smtp.sender.com and corp.sender.com. They’ll
Here is how your record might look:
be much simpler than the record for sender.com. In fact, all
they have to say is this: corp.sender.com TXT “v=spf1 a -all”

smtp.sender.com IN TXT “v=spf1 a -all”

corp.sender.com IN TXT “v=spf1 a -all”

That means: only corp and smtp.sender.com, respectively,

are allowed to send mail from corp and smtp.sender.com.

Loose Ends: Deferral Relays

If a message cannot be delivered, it is queued for later re- Deferral Relaying: when a message is not immediately deliverable, queue it on a
dedicated retry server instead of on your main sending server.
try. All sane senders do this. But some sites practice deferral
relaying: instead of queuing undeliverable messages on the
sending server, they move messages to a diﬀerent machine. If deferrals.sender.com also sends mail that looks like this:
This is done for performance reasons. The main sending MAIL FROM:<[email protected]>
From: Some User <[email protected]>
servers don’t get clogged with queued messages, and the de-
ferral servers can focus on retrying messages at a more lei- Or like this:
surely pace. MAIL FROM:<>
From: Mail Delivery Subsystem <[email protected]>
If sender.com practices deferral relaying, you should add
its deferral relays to its spf record. We could update the previous examples to say:
corp.sender.com TXT “v=spf1 a a:deferrals.sender.com -all”
smtp.sender.com TXT “v=spf1 a a:deferrals.sender.com -all”
To Fail or not to Fail? sender.com TXT “v=spf1 a mx a:deferrals.%{d2} ~all”

If you look at other sites with spf records, you’ll ﬁnd that
some of them end in ?all, some of them end in ~all, and
some end in -all. What should you do? If… then set
It depends. This is a tradeoﬀ situation: you have to bal- Deliverability is mission critical… ?all
ance competing concerns. Conservative publishers might Phishing is a major concern… –all
start with a ?all, move through ~all as conditions change, Your users are still using 3rd party SMTP servers… ?all
and (if all goes well) stabilize at -all. (“Conditions change” All users are known to be compliant… –all
means users switch to the approved outbound smtp relay, You are worried about non-SRS forwarders… ?all
forwarders start prepending headers and implementing srs, “Enough” forwarders have adopted SRS… –all
and you start signing with DomainKeys.) If you are very con- (or you want to encourage them to)
cerned about phishing, publish a –all right away and accept The domain never sends mail… –all
that there may be some false positives due to noncompliant You need something in between ?all and -all… ~all
forwarders who are slow to upgrade. Otherwise, use a ~all. Yes, this is yucky. I’m sorry. I wish it weren’t. –Meng

Expect to use DomainKeys or other crypto

Cryptographic authentication is following in the footsteps of

ip-based authentication. When it becomes possible for your
mtas to sign outbound messages with DK or a similar cryp- gmail.com and yahoo.com have started signing outbound mail with DomainKeys.
Other ISPs and email providers are poised to follow suit.
tographic application, you should do so. Solutions like SES
and BATV are also maturing rapidly, and offer comparable
functionality but with a different cost/benefit structure. A http://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatrix.htm
compares a number of cryptographic signature schemes.
later version of this whitepaper will describe cryptographic
solutions when they mature.

maawg · Sender Authentication: What To Do Deployment: For Email Senders 15

Deployment: For Email Receivers

Two Sides of the Coin

Sender authentication can be put to two uses. Messages from

trusted senders that pass authentication can be saved straight
to end-user inboxes, bypassing expensive and potentially er-
roneous content filtering. Messages that fail authentication In the case of a false positive, the argument for
system integrity weighs in favour of rejection at
can be identified as forgeries and rejected at smtp time, si- SMTP time. Legitimate senders deserve to know
lently discarded, or filed to a junk folder. when their mail isn’t getting through.

Recording Trusted Senders Who Passed Authentication

If a joint test shows that the sender is trusted and the message The industry hasn’t yet standardized on a way to do
this. Murray Kucherawy of Sendmail has drafted a
is authentic, a receiving system should communicate that fact speciﬁcation for an Authentication-Results:
to end-users. A receiving mta should record the test results header. I haven’t heard any complaints to date.
in a header for consumption by a downstream mua.

Whitelisting Incoming Forwarders

There are lots of forwarding services out there. Perhaps the

best known forwarders among the technical community are
acm.org and pobox.com. Similar alumni forwarding ad-
dresses are offered by universities. Domain hosting services
quietly offer email forwarding as part of their standard ser-
vice set. And uncounted more ad hoc setups exist, running
out of a .forward file set up by an end-user who may have One school of thought says that because this sort of forwarding operates on
behalf of the receiver, it is the duty of the receiver system to whitelist the
forgotten all about it. intermediate forwarder. Another school of thought contends that it is the
It is difficult to comprehensively whitelist all incoming for- responsibility of forwarders to accept responsibility for reinjecting messages
warders. An isp has no a priori knowledge of its end-users’ into the mailstream, and therefore forwarders should be prepending headers
and doing SRS. Either way the situation is messy, and nobody wants the hot
third-party .forward files. But it can whitelist well-known potato. Both schools are right to some degree. The pragmatist asks: what
forwarders en masse thanks to trusted-forwarder.org. That can we do if the other side is obstinate?
Progressive forwarders will prepend headers and do SRS voluntarily,
domain is both a dnswl and an rhswl of well-known for- without taking the position that receivers should whitelist them; they will
warding systems. It includes acm.org, pobox.com, and many also publish SPF records for their HELO domain names to make whitelisting
easier.
major alumni forwarding and domain hosting services. It Progressive receivers will whitelist forwarders voluntarily by IP address or
attempts to factor out the tractable parts of the forwarding by validated HELO domain name, without taking the position that
problem, and leaves only the ad hoc, unpredictable .forward forwarders should do SRS.
If the entire Internet were this progressive and polite, we’d have solved
scenarios. spam a long time ago.
Trusted-forwarder.org has been in existence for over a Note that whitelisting means different things to different people. A
conscientious forwarder may aggressively spam filter, and only let through
year. It is well maintained by Wayne Schlitt, a core mem- good mail; in that case, it would be safe to give them a free pass. But a
ber of the spf project. All spf implementations are strongly forwarder that doesn’t filter should be subject to the same content filtering
as any other untrusted sender.
encouraged to use it until cryptographic solutions solve for-
warding for good.

What To Do About Forgeries

If the authentication test returns a fail result, what should

you do? A receiving mta can reject the smtp session or use
the fail as a part of a spam scoring scheme. If the message
is not rejected at smtp time, the receiving mta should record
the test results in an Authentication-Results header for
consumption by a downstream mua.

maawg · Sender Authentication: What To Do Deployment: For Email Receivers 16

Deployment: For ISPs and Enterprises

The preceding sections “for Senders” and “for Receivers” ap-

ply to ISPs and enterprises as well.

Complementary considerations for ISPs

��
While a detailed deployment discussion of complementary ��
technologies is outside the scope of this document, ISPs are ��
��
strongly encouraged to adopt them as part of a balanced an-
tispam strategy. ��

��
Outbound Port 25 blocking restricts direct-to-mx spam ��
��
��
from zombies. isps should block port 25 outbound on con- ��
sumer-class connections by default. (Customer churn is
always less than feared.) If a customer needs the port un-
blocked, isps can do so on a case-by-case basis or oﬀer a dif-
��
ferent class of service. Business-class connections should
leave port 25 unblocked by default under the assumption ��
��
that customer organizations – acting as isps themselves – run ��
their own mtas and internally block port 25. ��
��
��
Inbound Port 25 blocking is also strongly recomended to ��
counter asymmetric ip routing attacks. ��

��
Offering smtp auth is essential for roaming customers
who, in the stricter world of sender authentication, need to
connect back to their home isp to send mail. smtp auth
should be oﬀered on port 587 because a roaming user might
not be able to reach port 25. Encryption should be manda-
tory: the starttls option is widely supported. cram-md5
and port 465 are good alternatives.

Consistent Reverse DNS Naming gives receivers a way If the IP address appears in the hostname, together with a Some common
distinctive subdomain name, lots of people will recognize subdomains:
to guess if a host is a zombie or a legitimate outbound mta. that as a consumer-class broadband machine that should dsl · adsl
Consumer-grade machines should reside under a speciﬁc not send mail. Conversely business-class accounts should cable · cablemodem
subdomain. Production mxes should never contain their ip get their choice of reverse DNS naming, and the PTR cust · customer
hostname should resolve back to the actual IP. dial · dialup
address in the hostname and must have consistent forward dyn · dynamic
and reverse dns. Some ﬁlters are unable to cope with embedded wildcards ppp · pppoe
so the distinctive tag should appear on the right hand side. broadband

Spam-filtering outbound mail and Rate-Limiting con- Good: 192-0-2-2.adsl.isp.com

Bad: 2-2.adsl.192-0.isp.com
sumer-grade senders to a reasonable volume (perhaps 00
messages per day by default) would be an eﬀective way to
stem the ﬂow of spam from zombies. With smtp auth, you
can do this based on username instead of ip address.

Detecting Outbound Return-path Forgery can be an

eﬀective optimization: if a customer node is sending mail
with a wide variety of sender addresses, some of which
would fail spf tests, then it is highly likely that that node is
compromised. ISPs should match return-paths to authen-
ticated user identities (e.g. the smtp auth username): this
prevents cross-customer forgery and limits damage to the
aﬀected user.

maawg · Sender Authentication: What To Do Deployment: For ISPs and Enterprises 17

Deployment: For MTA vendors

Which specification? The nice thing about standards is that there are so many
to choose from. Furthermore, if you do not like any of
One half of Sender ID is SPF Classic. The original SPF Clas- them, you can just wait for next year’s model.
sic specification was frozen in early January 2004. It has ANDREW S. TANENBAUM
evolved in only minor details since then. It was submitted
to the IETF in October 2004 and is expected to be published
as an experimental rfc. When it is published, mta vendors
are encouraged to update their implementations to match it. See http://spf.pobox.com/rfcs.html
Vendors who implement SPF Classic can indicate that they
are Sender ID compliant.
The other half of Sender ID is the PRA check. MTA ven- See http://www.microsoft.com/senderid
dors may also wish to implement that half. Specifications
describing the PRA and how it fits into Sender ID were sub-
mitted to the IETF in October 2004 as well.

Conformance testing

The easiest way to ensure that an implementation is confor-

mant, of course, is to run it through an industry-standard in-
teroperability test suite. Certiﬁcation programs for SPF and
Sender ID are in the works and will be announced publicly
when they are ready.

Perform SRS and prepend headers when forwarding

When automatically forwarding mail, mtas should do two See http://spf.pobox.com/srs.html and http://www.libsrs2.org/
things: rewrite the return-path using srs, and prepend a Re-
sent-From header.

Add ESMTP support for Submitter

In server mode, advertise and accept the submitter param-

eter. In client mode, if the server supports it, send it.

Record authentication and policy results in the headers

It is the job of the MUA to signal trustworthiness to the end-

user. It is the job of the MTA to help them do this. MTAs
should record authentication results in as much detail as pos-
sible into headers. MTAs should, of course, be sensitive to
header spooﬁng. They can do this by renaming or removing
preexisting headers. See the sender-auth-header internet-
draft by M. Kucherawy for more details. It describes the pro-
posed header, “Authentication-Results”.

Join the developers mailing list

SPF and Sender ID developers are strongly encouraged to See also http://spf.pobox.com/developers-guide.html
send mail to [email protected].

maawg · Sender Authentication: What To Do Deployment: For MTA Vendors 18

Deployment: For MUA vendors

Displaying Authentication-Results

MUAs need the email equivalent of the https padlock icon.

An mua can rely on an upstream mta to produce an Authen-
tication-Results header. It can also perform authentica-
tion checks directly: if the message was cryptographically
signed this is easy. If the message was not signed, and the
mua needs to use Sender ID techniques, this is a little more
diﬃcult. ��
MUAs should visually distinguish messages that are con- ��
sidered trustworthy from messages that lack an authentica-
tion status or that failed authentication. Note that a message
should be considered trustworthy only if it passed both tests: ��
��
J¸L
authentication and local receiver policy. MUAs can contrib-
ute to the “local receiver policy” decision: if a message was
��
K L J ¸ K L

authenticated, and the sender appears in the end-user’s ad-

dressbook, that might add up to a dual-pass. MUAs should
��
LLL J ¸ K L

add a clearly visible warning to messages that fail authen-

tication and could refrain from displaying inline images by
��
LLL
default. Some possibilities for MUA displays.
MUAs should also consider adding a “Not Junk” folder
and automatically ﬁle trusted messages into that folder. The
obvious idea is to give good messages attention priority. The
subversive idea is for end-users to one day say “hey, I don’t
even look at my Junk Folder any more, so I’ll just set that to
auto-delete (or reject); and now that I think about it, that’s
true for the regular inbox too!” The “Not Junk” folder will
be all that remains.

Automatic switching to port 587

The ISP industry is moving toward the practice of blocking

outbound port 25 from consumer-grade dialup and broad-
band nodes.
This means that roaming users will increasingly find
themselves in need of an alternative port for message sub-
mission. That port is port 587, as defined in rfc2476.
At present, users need to hunt down the configuration
dialog which lets them change their submission port from
25 to 587. This can be challenging: muas sometimes hide that
configuration point in esoteric places.
MUAs should automatically probe port 587 when submit-
ting mail. Since they already possess the end-user’s user-
name and password for message retrieval, they should have
no problem performing authenticated submission with smtp
auth. If the 587 attempt fails they can fall back to port 25.
All of this can occur behind the scenes without user inter-
vention – which is the way it should be.

maawg · Sender Authentication: What To Do Deployment: For MUA Vendors 19

Deployment: For ESPs

When a big brand wants to mail many, many customers, it

often contracts the job to an Email Service Provider (ESP).
ESPs handle the mail merge, bounce management, and un-
subscription functions for the brand.

For the most current version of this page, see

http://spf.pobox.com/esps.html

Don’t look like a phisher!

In the last few years, the chaotic world of volume-mailing

outsourcing has shot itself in the foot: the standard conﬁgu-
ration for an outsourced campaign now looks practically in-
distinguishable from a phishing attack. ESPs need to make
their relationship with their clients a little more obvious.

Delegation

DNS comes with a delegation feature. Use it! Suppose your In the example below, bigbox.com’s DNS admins have delegated esp.bigbox.com to
esp.com, so esp.com’s nameservers are the ones that actually answer authoritatively
client is bigbox.com, and you’re esp.com. You should try to for esp.bigbox.com. This makes it easier for esp.com to ﬁddle with esp.bigbox.
get the client to set up esp.bigbox.com which delegates to com’s SPF records and whatever else. The alternative to delegation is the infrequent
you; you can then use esp.bigbox.com in your mailings with and troublesome need for ESP to call BigBox once every eighteen months or so
when the DNS details change.
full control of the dns.
If your client is too small or too unsophisticated to set up
delegation, and if they just want you to use their name direct-
ly in their mailings, you’ll need to get them to “include:”
you in their spf record.

Publish Appropriately

ESPs are the one sector who might need to distinguish pra
and mail from scopes. We’ll walk through an example.
Suppose an ESP, esp.com, has been contracted by a cli- The author recommends that ESPs set up their mailings to look like this:
ent, bigbox.com. The ESP sends mail using through a server, MAIL FROM:<[email protected]>
From: Big Box Stores <[email protected]>
outmta.esp.com. Bounces and unsubscribes are directed to
Sender: <[email protected]>
bounces.esp.com. Reply-To: <[email protected]>
If you wanted to distinguish PRA from mail from scope, The PRA algorithm selects the Sender header.
you might use the following records:
1 bounces.esp.com Line 2 is for the MAIL FROM. The default is “?all” because for this mailing campaign and
2 “v=spf1 a:outmta.esp.com ?all” this domain, bounces.esp.com, we’re more concerned about mail getting through than
3 “spf2.0/pra -all” about preventing forgeries. Line 3 is for the PRA. It states: we’ll never use the domain
bounces.esp.com in a From: or Sender: header, only in the envelope.

4 bigbox.com Line 4 is for the client, bigbox.com, which outsources all of its marketing mailings and
5 “v=spf1 a:corp.bigbox.com -all” only uses bigbox.com for corporate accounts. it is more concerned about phishing than
false positives due to forwarding, so it sets -all.

6 esp.bigbox.com Lines 7 and 8 are for the outsourced relationship domain esp.bigbox.com. it indicates
7 “v=spf1 -all” that ESP is a contractor for bigbox.com. esp.bigbox.com is never used in the return-
8 “spf2.0/pra a:outmta.esp.com” path so the v=spf1 record is -all. But it is used in the Sender header, so the spf2.0/pra
record overrides it to allow outmta.esp.com. The PRA record does not end in a -all
ESPs who feel in need of further guidance are because, again, for this mailing we’re more concerned about mail getting through than
about forgery prevention.
welcome to contact [email protected] directly.

maawg · Sender Authentication: What To Do Deployment: For ESPs 20

Deployment: For Spammers

Spammers are some of the most responsive players in the

industry. They have been enthusiastic early adopters of au-
thentication technologies. The “Devil’s Advocate” deploy-
ment advice in this section forecasts the next few moves in
the game and predicts the ﬁnal steady-state scenario. It is
meant to show how spammers will adapt and how the good
guys can respond.

Two Types of Spammers

There are two major types of spammers in operation today.

(Legitimate ESPs are not considered spammers.)
Organized crime is largely responsible for the phishing
and identity-theft fraud scams we see today. Many of these
criminal gangs work across international boundaries.
Commercial spammers are responsible for the less obvi-
ously criminal junk mail – they actually try to sell a product.
The product may be held up in shipping, or it may not actu-
ally deliver the advertised results, but some kind of sale is
usually promised.

Publish SPF and sign with DomainKeys.

In the relatively near future, a sea change will occur so that Note to civil libertarians: you can be accountable and anonymous at the same time.
We’re interested in getting identities on the Internet to persist long enough to attract a
mail from senders who are not accountable will be widely stable reputation. We’re not quite as interested in tying online identities to real-world
relegated to third-class status. identities, because support for whistleblowing is an important social value. But we want
Some receivers may look down on messages from senders to give receivers the ability, when faced with a range of messages from senders they
don’t know, to apply an ordering to those messages so that senders who have taken
who do not have SPF or DomainKeys. To be on the safe side, steps to distinguish themselves from spammers get some kind of priority over senders
spammers should publish and sign. who have not taken those steps. A sender might voluntarily choose to tie their online
identity to their real-world identity in the hopes of improving their deliverability;
however, that decision should be entirely up to senders, and there should be ways for
Stop forging random domains. senders to distinguish themselves from spammers without requiring real-world
identiﬁcation.

Sure, you could forge domains that don’t have SPF records,
but after a while receivers will adapt by simply third-classing
mail that doesn’t authenticate. So this is only a temporary
measure.

Buy your own domains.

There are two main strategies. You could buy a domain, According to some reports, over a thousand domains are registered each week and used
to spam.
bring it online, and immediately spam with it. This works
because reputation service won’t know anything about those
new domains, so if the receiver has a default-accept orienta-
tion, the mail might still get through. As this strategy evolves,
receivers might learn not to accept mail from brand new do-
mains. This leads to the second strategy: buy a domain, leave
it mostly dormant for some time, and then spam with it in
hopes that it’ll now look more reputable than a brand-new
domain. Because most new spam domains are bought with
stolen credit cards, this strategy may be more costly unless

maawg · Sender Authentication: What To Do Deployment: For Spammers 21

you can ﬁnd a sloppy dns registrar who’ll leave up domains
that were registered with stolen cards. But then, using such a
registrar might negatively aﬀect your reputation. The author
recommends that you experiment and see how it works out.

Reuse an expired domain.

You can eﬀectively hijack someone else’s good reputation by

ﬁnding a respected domain that is recently expired, and send
mail using that name. But reputation systems are likely to
pay attention to domain expirations and transfers, and null
out the reputation on a domain that has changed hands.

Try to buy accreditation.

Accreditation schemes may become widespread. The essen-

tial ruse is to look like a good guy whose domain is simply
new to the Internet, so you can try to sign up with accredita-
tion services that don’t do very good due diligence. But ac-
creditation services that don’t do very good due diligence are
likely to attract a poor reputation themselves.

Try to fake out reputation services.

Reputation services that depend on end-users are subject to

attack, because you can pretend to be an end-user, and vote
your spam as ham. In fact, you can pretend to be several
thousand end-users. But as reputation systems grow more
sophisticated, voters will be themselves subject to reputa-
tion, so an attack may not succeed unless you can completely
overwhelm a reputation service’s population.

Zombies should spam only their friends and family.

Botnets of infected zombies are your major asset today. In

the future, you will need to upgrade your zombies to ﬁgure
out smtp auth credentials, label the spam as being from the
actual zombie user, route it through the isp’s mta, and only
direct it to people in the end-user’s addressbook and mail-
box. Spam sent through other routes and to unrecognized
recipients will be unlikely to be delivered or read. Good isps
will counter with rate-limiting and outbound ﬁltering.

Spread FUD about the edge cases. FUD: (n) Fear, Uncertainty, and Doubt.

None of the approaches are perfect. A message could be for-

warded through a site that does not perform srs and does
not prepend Resent headers; that message could then pass
through an mta that munges the content for perfectly good
reasons. This corner case is a favourite of technical perfec-
tionists who use it to argue that one can never reliably reject
a message based on sender authentication. If this point of
view gains widespread public acceptance, you will be able to
continue to spoof messages.

maawg · Sender Authentication: What To Do Deployment: For Spammers 22

Deployment Roadmap

Publishing SPF: At the maawg First General meeting on Q4 2004 Senders and isps publish spf records.
November 2 2004, a majority of members voluntarily agreed
Q1 2005 maawg spf testing continues.
to publish spf records by the end of December 2004. It is up
dns hosters support txt records.
to each member to decide which default to use. Most con-
servative members may wish to use ?all (neutral) at first; Q2 2005 Forwarders do srs and prepend Resent-From.
that’s fine. More aggressive members may wish to use ~all muas display confidence to end-users with
(softfail). See the tradeoffs on p 5. foldering to first-class and business-class.
isps offer 587 smtp auth for roaming users,
Support for TXT: Managed dns providers should support tell new subscribers to configure that way by
txt entries by the end of q 2005. Providers should link to a default. Cryptographic solutions mature.
well-known third party wizard instead of offering their own. Q3 2005 spf results widely used in spam scoring.
Senders start signing outbound mail and
Crypto Signing: Some members are planning to sign mes- transition spf records to ~all or –all.
sages with DomainKeys on an experimental basis in 2005 as Receivers check inbound signatures and
their mta software develops this capability. honour fails by rejecting.
Q4 2005 isps offer default-reject mailboxes.
Checking SPF and DomainKeys: A testing and evaluation Spam ends. Bill Gates gets credit.
program is underway. maawg members expect to start spf
testing incoming mail in q 2005 and to incorporate the re-
sult into spam scoring decisions in q2 2005. DomainKeys Note: the above deployment dates are the author’s
checking should occur close to that timeframe also. recommendations. They are still incomplete, subject
to further development and discussion, and have not
Forwarder SRS: Forwarders should perform SRS on for- been ratified by any industry standards body. How-
warded mail and prepend headers by the end of q2 2005. ever, if you wait for industry standards bodies to ratify
things, you may be waiting a really long time. That
Honoring Authentication Failures: If a sender domain uses said, you should consider joining maawg, which is a
a –all default, and if a receiver domain obtains a fail result, forum for collaboration and standards deployment in
that receiver may reject the message during the smtp trans- the messaging space. (http://www.maawg.org)
action. It should not generate a bounce message. In q3 2005,
senders should set –all defaults, and receivers should move To stay current on these issues, join the deployment
to begin to honour –all by rejecting. Senders who are par- mailing list by sending mail to subscribe-spf-
ticularly concerned about noncompliant users or forwarding [email protected].
false positives can define a ~all default.

Displaying conﬁdence to end-users: ISPs should start re-

cording Authentication-Results by the end of q2 2005.
MUAs sold after that date should display a conﬁdence mark
distinguishing good senders from bad.

Requiring Authentication Passes: Spammers are expected

to start registering their own domains and churning through
them. The weak way to answer this is to start keeping lists of
domain names to block, but that is a reactive mode of opera-
tion akin to today’s ip-based blacklists. The strong answer Contact the author for details on the Karma Project,
which aggregates and multiplexes reputation feeds for
is to only accept mail that passes authentication and repu- convenient lookup.
tation/accreditation tests. ISPs should • start oﬀering a de-
fault-reject type of mailbox in q4 2005 or sooner, • make that
the default oﬀering for new signups, and • give existing users
the option to convert to default-reject.

maawg · Sender Authentication: What To Do Deployment Roadmap 23

ISP Best Practices and Code of Conduct

See also the maawg Code of Conduct document and the Code of Conduct document currently being revised.
ASTA Technical Recommendations document. ASTA doc available at http://docs.yahoo.com/docs/pr/pdf/asta_soi.pdf

. Noncompliance with rfc282 and rfc2822 constitutes suf-

ﬁcient cause to reject a message.

2. When an outbound edge mta sends a domain name in

the helo argument, that hostname must be a Fully Quali-
ﬁed Domain Name (FQDN) that resolves to the ip address
of the mta.

3.. Every outbound edge mta must have a reverse DNS

(ptr) record that resolves to a hostname that in turn resolves
back to the ip address of that mta. To avoid looking like a
consumer-grade machine, it should not contain more than
one octet of its ip address in its hostname.

3.2 Conversely, dynamically assigned consumer-grade ips IP addresses may be encoded in decimal or in hex.
For example, 192-0-2-2.adsl.example.com or
should obviously contain two or more octets of their ip ad- c0000202.adsl.example.com
dresses in their ptr hostname. See p 7.

4.. A dynamically assigned consumer-grade dialup or broad-

band node should not expect to be able to send mail directly
to unrelated receiver mtas over port 25. ISPs should block
outbound port 25 either at the network routers or inside the
customer broadband modem. ISPs should oﬀer a message
submission server for end-users to use as an outbound mail
relay.

4.2. As a corollary for home users: unsecured wireless rout-

ers can be conﬁgured to block port 25 too. Meng personally
submits mail over 587, so blocking port 25 in his little Linksys
gizmo (a) doesn’t disrupt anything, and (b) makes him feel
better about leaving it unsecured and open to the public.

5. If an smtp client appears to be a consumer-grade dialup

or broadband node, and if that smtp client does not demon- Clients demonstrate accountability by publishing SPF records
or signing with DomainKeys.
strate accountability, receivers may reject the connection.

maawg · Sender Authentication: What To Do Best Practices 24

Spam is not a problem to be solved.
It is a phase to be outgrown.

Business Email Compromise Response Playbook
No ratings yet
Business Email Compromise Response Playbook
7 pages
MySQL Cluster Tutorial
100% (3)
MySQL Cluster Tutorial
64 pages
Interview With Stana Katic
No ratings yet
Interview With Stana Katic
5 pages
Analyzing Network and Content Using Honeypots
No ratings yet
Analyzing Network and Content Using Honeypots
9 pages
CYBERSECURITY
0% (1)
CYBERSECURITY
7 pages
TMA2020 Maroofi
No ratings yet
TMA2020 Maroofi
9 pages
Spam Traps Cheat Sheet 1
No ratings yet
Spam Traps Cheat Sheet 1
4 pages
3 Secrets Email Deliverability Us
No ratings yet
3 Secrets Email Deliverability Us
12 pages
D2-S1-Cybersecurity in Banking Threats, Challenges and Solutions
100% (1)
D2-S1-Cybersecurity in Banking Threats, Challenges and Solutions
67 pages
Module 3: Securing Exchange Server 2003
No ratings yet
Module 3: Securing Exchange Server 2003
41 pages
Allman E-Mail Authentication
No ratings yet
Allman E-Mail Authentication
5 pages
Major_Project_BharathUniversity
No ratings yet
Major_Project_BharathUniversity
5 pages
Search Engine Link Spam: Search Engine Link Spam: Risks, Threats, Solution
No ratings yet
Search Engine Link Spam: Search Engine Link Spam: Risks, Threats, Solution
10 pages
Atharva Nivalkar - IEEE - 2019 - DMARCBox-Corporate Email Security and Analytics Using DMARC
No ratings yet
Atharva Nivalkar - IEEE - 2019 - DMARCBox-Corporate Email Security and Analytics Using DMARC
5 pages
Cyber Security Long Type Pdf000-1
No ratings yet
Cyber Security Long Type Pdf000-1
14 pages
Phishing Analysis Training
No ratings yet
Phishing Analysis Training
8 pages
Sample Report Email Risk Assessment
No ratings yet
Sample Report Email Risk Assessment
10 pages
Newsletter
No ratings yet
Newsletter
2 pages
Vipul s Razor
No ratings yet
Vipul s Razor
3 pages
O365 Interview Questiones & Answers
No ratings yet
O365 Interview Questiones & Answers
16 pages
Understanding The Time-Series Behavioral Characteristics of Evolutionally Advanced Email Spammers
No ratings yet
Understanding The Time-Series Behavioral Characteristics of Evolutionally Advanced Email Spammers
9 pages
Detection of Spams Using Extended ICA & Neural Networks
No ratings yet
Detection of Spams Using Extended ICA & Neural Networks
6 pages
Kami Export - Lab 8.4.2 Exfilitration with Eternal Blue
No ratings yet
Kami Export - Lab 8.4.2 Exfilitration with Eternal Blue
4 pages
SPAMBOT
100% (1)
SPAMBOT
57 pages
1-Advanced Social Engineering
No ratings yet
1-Advanced Social Engineering
318 pages
Security Plus Notes
100% (1)
Security Plus Notes
21 pages
Ransomware Prevention Recommendations
No ratings yet
Ransomware Prevention Recommendations
2 pages
How To Send Fake Mail Using SMTP Servers
No ratings yet
How To Send Fake Mail Using SMTP Servers
5 pages
SpamAssassin: A practical guide to integration and configuration
From Everand
SpamAssassin: A practical guide to integration and configuration
Alistair McDonald
No ratings yet
Email Sender Authentication Development and Deployment (Project Cheeseplate)
No ratings yet
Email Sender Authentication Development and Deployment (Project Cheeseplate)
24 pages
How Hackers Breach Your Networks
No ratings yet
How Hackers Breach Your Networks
11 pages
50 Email Security Best Practices
No ratings yet
50 Email Security Best Practices
17 pages
Threat Intelligence Report Maze Ransomware Campaign Spoofs Italian Revenue Agency Correspondence
No ratings yet
Threat Intelligence Report Maze Ransomware Campaign Spoofs Italian Revenue Agency Correspondence
2 pages
InterScan Messaging Security Suite
No ratings yet
InterScan Messaging Security Suite
24 pages
Installing A SMTP System
No ratings yet
Installing A SMTP System
11 pages
Inbox Formula
No ratings yet
Inbox Formula
24 pages
Ebook AVG
No ratings yet
Ebook AVG
10 pages
Implementing Zero Knowledge Encryption
No ratings yet
Implementing Zero Knowledge Encryption
19 pages
NS Assignment
No ratings yet
NS Assignment
8 pages
2402.18093v1
No ratings yet
2402.18093v1
20 pages
Sample Report Email Risk Assessment
No ratings yet
Sample Report Email Risk Assessment
10 pages
Optimizing Third Party Risk in The Enterprise
No ratings yet
Optimizing Third Party Risk in The Enterprise
16 pages
Anti Phishing Attacks
No ratings yet
Anti Phishing Attacks
58 pages
White Paper Smime Benefits and Best Practices
No ratings yet
White Paper Smime Benefits and Best Practices
10 pages
Transposition Encryption Cybercash Verisign Key Distribution Center Zombie Blind Carbon Copy & Carbon Copy Modem E-Mail
No ratings yet
Transposition Encryption Cybercash Verisign Key Distribution Center Zombie Blind Carbon Copy & Carbon Copy Modem E-Mail
8 pages
Student Assignments
No ratings yet
Student Assignments
61 pages
Anti Phishing Attacks
0% (1)
Anti Phishing Attacks
58 pages
Becoming The Hacker - Adrian Pruteanu
0% (1)
Becoming The Hacker - Adrian Pruteanu
524 pages
Chapter 4 Set
No ratings yet
Chapter 4 Set
5 pages
Preparation Preparation: Containment
No ratings yet
Preparation Preparation: Containment
2 pages
Intern
No ratings yet
Intern
12 pages
Using Dkim With Mdaemon
No ratings yet
Using Dkim With Mdaemon
14 pages
FortiMail Encriptacion
No ratings yet
FortiMail Encriptacion
12 pages
Security Issues Unit 2
No ratings yet
Security Issues Unit 2
10 pages
CS507 04 Assignment Idea Solution
No ratings yet
CS507 04 Assignment Idea Solution
4 pages
Defending Against Ransomware With Zscaler Workload Segmentation
No ratings yet
Defending Against Ransomware With Zscaler Workload Segmentation
6 pages
Crypto
No ratings yet
Crypto
10 pages
Submitted To: Submitted By:: Ms. Komal Arora Arshiya Sethi Registration No-11010501 Section-K1006
No ratings yet
Submitted To: Submitted By:: Ms. Komal Arora Arshiya Sethi Registration No-11010501 Section-K1006
15 pages
althobaiti2021chi
No ratings yet
althobaiti2021chi
17 pages
Email Spoofing
No ratings yet
Email Spoofing
3 pages
Keystroke With Data Leakage Detection For Secure Email Authentication
No ratings yet
Keystroke With Data Leakage Detection For Secure Email Authentication
3 pages
Experiment 06: WWW - Oxid.it/cain - HTML
No ratings yet
Experiment 06: WWW - Oxid.it/cain - HTML
8 pages
Deploying IP Unicast
No ratings yet
Deploying IP Unicast
83 pages
MySQL and Linux Tuning - Better Together
100% (1)
MySQL and Linux Tuning - Better Together
26 pages
MySQL and SSD: Usage Patterns
No ratings yet
MySQL and SSD: Usage Patterns
29 pages
Large Datasets in MySQL On Amazon EC2
No ratings yet
Large Datasets in MySQL On Amazon EC2
30 pages
Metadata Locking and Deadlock Detection in MySQL 5.5
No ratings yet
Metadata Locking and Deadlock Detection in MySQL 5.5
14 pages
Dynamic Columns
No ratings yet
Dynamic Columns
18 pages
Lessons Learned: Scaling A Social Network
No ratings yet
Lessons Learned: Scaling A Social Network
52 pages
Bottom-Up Database Benchmarking
No ratings yet
Bottom-Up Database Benchmarking
43 pages
Forecasting MySQL Performance and Scalability
100% (1)
Forecasting MySQL Performance and Scalability
41 pages
Granular Archival and Nearline Storage Using MySQL, S3 and SQS Presentation
No ratings yet
Granular Archival and Nearline Storage Using MySQL, S3 and SQS Presentation
28 pages
Data in The Cloud Presentation
No ratings yet
Data in The Cloud Presentation
13 pages
Automated, Non-Stop MySQL Operations and Failover Presentation
100% (1)
Automated, Non-Stop MySQL Operations and Failover Presentation
46 pages
A Beginner's Guide To MariaDB Presentation
67% (3)
A Beginner's Guide To MariaDB Presentation
26 pages
Advanced Replication Monitoring Presentation
100% (1)
Advanced Replication Monitoring Presentation
13 pages
Book Upload
100% (20)
Book Upload
270 pages
Zipcar Incident Report
No ratings yet
Zipcar Incident Report
2 pages
A Code Stub Generator For MySQL and Drizzle Plugins Presentation
No ratings yet
A Code Stub Generator For MySQL and Drizzle Plugins Presentation
29 pages
Linux and H/W Optimizations For MySQL
100% (2)
Linux and H/W Optimizations For MySQL
160 pages
Top 10 Lessons Learned From Deploying Hadoop in A Private Cloud
No ratings yet
Top 10 Lessons Learned From Deploying Hadoop in A Private Cloud
33 pages
Search Analytics With Flume and HBase
No ratings yet
Search Analytics With Flume and HBase
24 pages
CSDD_L6
No ratings yet
CSDD_L6
22 pages
Email - Wikipedia
No ratings yet
Email - Wikipedia
1 page
Filtering Out Spam
No ratings yet
Filtering Out Spam
64 pages
Chapter 2
No ratings yet
Chapter 2
139 pages
Applied Crypto Hardening
No ratings yet
Applied Crypto Hardening
94 pages
Network Security UNIT 4
No ratings yet
Network Security UNIT 4
27 pages
Cissp 4
No ratings yet
Cissp 4
63 pages
Symantec DLP 15.0 Email Prevent MTA Integration Guide
0% (1)
Symantec DLP 15.0 Email Prevent MTA Integration Guide
59 pages
Mail Server
No ratings yet
Mail Server
14 pages
SMTP
No ratings yet
SMTP
7 pages
Chapter 6 Email System
No ratings yet
Chapter 6 Email System
22 pages
Applied Crypto Hardening
No ratings yet
Applied Crypto Hardening
86 pages
VTU Network and Cyber Security Module-2 (15ec835, 17ec835) .
80% (5)
VTU Network and Cyber Security Module-2 (15ec835, 17ec835) .
36 pages
Email Gateway Security Reference Architecture v1 0
No ratings yet
Email Gateway Security Reference Architecture v1 0
41 pages
Web Based Surveillance System Using A Snapshot Model: Yuvraj Saini, N. C. Bajia, Abhinandan Jain, Meenu Bhati
No ratings yet
Web Based Surveillance System Using A Snapshot Model: Yuvraj Saini, N. C. Bajia, Abhinandan Jain, Meenu Bhati
6 pages
Exchange Server Fundamentals
No ratings yet
Exchange Server Fundamentals
22 pages
How To Create MSA and gMSA Accounts 1.1-1
No ratings yet
How To Create MSA and gMSA Accounts 1.1-1
10 pages
Network
No ratings yet
Network
29 pages
Domain Keys Identified Mail
No ratings yet
Domain Keys Identified Mail
6 pages
Email History and Facts
No ratings yet
Email History and Facts
19 pages
Linux System Administration Part-3
No ratings yet
Linux System Administration Part-3
1 page
E Mailforensics 161124053030
No ratings yet
E Mailforensics 161124053030
22 pages
If You Are Preparing For Interviews For Linux Admin Jobs You Should Be Familiar With Below Concepts.
83% (6)
If You Are Preparing For Interviews For Linux Admin Jobs You Should Be Familiar With Below Concepts.
54 pages
Techniques and Tools For Forensic Investigation of E-Mail
No ratings yet
Techniques and Tools For Forensic Investigation of E-Mail
15 pages
Computer Applications
No ratings yet
Computer Applications
202 pages

Sender Authentication Whitepaper

Uploaded by

Sender Authentication Whitepaper

Uploaded by

SES

A maawg White Paper on

Meng Weng Wong

Senior Technical Advisor

Founder & CTO for Special Projects

December 2 2004 . release 1

Copyright © 2004 Meng Weng Wong

If you are a domain owner, systems manager, dns admin-

How to Read this White Paper

Part I, A Vision for Spam-Free Email, oﬀers a birds-eye-view

Part II, About Sender Authentication, explains the diﬀer-

Part III, Deployment, explains what email senders, receivers,

maawg · Sender Authentication: What To Do 3

Content ﬁltering is reaching the end of the road. The Aspen

Drivers; or, Who’s Buying It

Receivers who want to reduce costs and improve their user

maawg · Sender Authentication: What To Do A Vision for Spam-Free Email 4

The vision calls for MUAs to authenticate themselves

It takes a fair amount of expertise for a human to extract the

maawg · Sender Authentication: What To Do A Vision for Spam-Free Email 5

The end-user addressbook can be an input to that deci-

that also passes authentication. If the mta happens to know

Reputation and accreditation services record assertions

prone content-based antispam tests.

maawg · Sender Authentication: What To Do A Vision for Spam-Free Email 6

At present, MTAs do not generally record the results of DNS-

will try to spoof those headers, but that problem can be

The receiving end-user’s MUA displays a conﬁdence

At present, muas lack a consistent, industrywide, visual lan-

“Not Junk”: The opposite of the Junk Mail folder.

At present, muas may ﬁle suspected spams into a Junk Mail

maawg · Sender Authentication: What To Do A Vision for Spam-Free Email 7

ip-based authentication validates the channel that transport-

Note the Received-SPF and DomainKey-Signature lines.

maawg · Sender Authentication: What To Do About Sender Authentication 8

from a relatively small set of servers. If we can identify those

The SPF record

maawg · Sender Authentication: What To Do About Sender Authentication 9

From: header. ���������������� �������������

maawg · Sender Authentication: What To Do About Sender Authentication 10

The Achilles’ Heel of ip-based schemes is forwarding: unless

Reputation Systems �����������

maawg · Sender Authentication: What To Do About Sender Authentication 11

All senders and receivers of email — from the largest ISP to

Stopping forgery means stopping all forgery: good and bad.

To begin, you need to identify all the ways in which legiti-

Mail from machines. Machine-generated processes may

Construct the record Assuming the following existing DNS entries:

maawg · Sender Authentication: What To Do Deployment: For Email Senders 12

Together, these records mean:

Test the record, part 

Put the record in DNS

maawg · Sender Authentication: What To Do Deployment: For Email Senders 13

ﬁrms that it makes sense.

Keep Track of Violations

SPF-enabled receivers should now be able to read your re-

maawg · Sender Authentication: What To Do Deployment: For Email Senders 14

smtp.sender.com IN TXT “v=spf1 a -all”

That means: only corp and smtp.sender.com, respectively,

Loose Ends: Deferral Relays

Expect to use DomainKeys or other crypto

Cryptographic authentication is following in the footsteps of

maawg · Sender Authentication: What To Do Deployment: For Email Senders 15

Two Sides of the Coin

Sender authentication can be put to two uses. Messages from

Recording Trusted Senders Who Passed Authentication

Whitelisting Incoming Forwarders

There are lots of forwarding services out there. Perhaps the

What To Do About Forgeries

If the authentication test returns a fail result, what should

maawg · Sender Authentication: What To Do Deployment: For Email Receivers 16

The preceding sections “for Senders” and “for Receivers” ap-

Complementary considerations for ISPs

Spam-filtering outbound mail and Rate-Limiting con- Good: 192-0-2-2.adsl.isp.com

Detecting Outbound Return-path Forgery can be an

maawg · Sender Authentication: What To Do Deployment: For ISPs and Enterprises 17

From: header. ��

Reputation Systems ��