sender authentication whitepaper

8/14/2019 Sender Authentication Whitepaper

1/25

SPF

DomainKeys

SES


2/25

Copyright 2004 Meng Weng Wongis 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 reflect the opinions of or s member organizations.

CIntroduction 3

Audience 3How to Read this White Paper 3

A Vision for Spam-Free Email 4e Problem of Abuse 4e Underlying Concept 4Drivers; or, Whos Buying It 4

Vision Walkthrough 5About Sender Authentication 8

An Example 8History 8How IP-based Authentication Works 9e SPF record 9How SPF Classic Works 9How Sender ID works 9How Cryptographic Techniques Work 0Using Multiple Approaches Reputation Systems

Deployment: For Email Senders 2First, prepare. 2

Audit Your Outbound Mailstreams 2Construct the record 2ink briefly about PRA and Mail-From contexts. 3Test the record, part 3Put the record in DNS 3Test the record, part 4Keep Track of Violations 4Loose Ends: Publishing Records For Hostnames 4Loose Ends: Deferral Relays 5To F or not to F? 5Expect to use DomainKeys or other crypto 5

Deployment: For Email Receivers 6Two Sides of the Coin 6Recording Trusted Senders Who Passed Authentication 6Whitelisting Incoming Forwarders 6What To Do About Forgeries 6

Deployment: For ISPs and Enterprises 7Complementary considerations for ISPs 7

Deployment: For MTA vendors 8Which specification? 8Conformance testing 8Perform SRS and prepend headers when forwarding 8Add ESMTP support for Submitter 8Record authentication and policy results in the headers 8Join the developers mailing list 8

Deployment: For MUA vendors 9Displaying Authentication-Results 9Automatic switching to port 87 9

Deployment: For ESPs 20Dont look like a phisher! 20Delegation 20

Publish Appropriately 20Deployment: For Spammers 2

Two Types of Spammers 2Publish SPF and sign with DomainKeys. 2Stop forging random domains. 2Buy your own domains. 2Reuse an expired domain. 22Try to buy accreditation. 22Try to fake out reputation services. 22Zombies should spam only their friends and family. 22Spread FUD about the edge cases. 22

Deployment Roadmap 23

ISP Best Practices and Code of Conduct24

A White Paper onSender Authentication Deployment

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

Meng Weng [email protected]

Senior Technical AdvisorMessaging Anti-Abuse Working Group

Founder & CTO for Special Projectspobox.com

December 2 2004 release 1


3/25

w Sender Authentication: What To Do

I

saw a great deal of hue and cry about spam. Now thedust is beginning to settle. A number of complementarytechnologies are still standing. ey will be rolled out in. is white paper explains why theyre important, howthey work, and how you can put them to use.

e email infrastructure as originally designed lacks acritical element: sender authentication. Sender authentica-

tion gives computers the ability to tell whether a message isforged or authentic. Without that ability, receiver systemscannot easily detect and block forgeries at SMTP time. Add-ing that ability sets the stage for complementary technolo-gies reputation and accreditation systems. Together, thesetechnologies make it possible to build a spam-free layer ontop of the existing email system.

Sender authentication protocols will be widely deployedin . is 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, admin-istrator, email administrator, or brand manager, you shouldread this paper.

How to Read this White Paper

Part I,A Vision for Spam-Free Email, offers a birds-eye-viewof the antispam landscape and lays out a strategy for reachinga spam-free world. It walks through an end-to-end messagedelivery scenario and shows how authentication, reputation,and accreditation fit together.

Part II, About Sender Authentication, explains the differ-ences between -based and crypto-based authenticationand discusses the most promising technologies.

Part III, Deployment, explains what email senders, receivers,ISPs, MTA vendors, MUA vendors, and volume ESPs need todo, and suggests a schedule for coordinated rollout.

In proportion as our inward life fails, we go more constantlyand desperately to the post-office. You may depend on it, thatthe poor fellow who walks away with the greatest numberof letters, proud of his extensive correspondence, has notheard from himself this long while.

Life Without PrincipleHENRY DV TOREU


4/25

A Vision for Spam-Free Email w Sender Authentication: What To Do

A V S-F E

Content filtering is reaching the end of the road. e AspenFramework will take its place. If you are familiar with theAccountable Net concepts developed at the Aspen Institutein December and with the three-part model of authen-

tication, reputation, and accreditation, you can skip directlyto the next section, About Sender Authentication.

e Problem of Abuse

Anyone can send email to anyone else, within seconds, atzero apparent cost. at is the greatest strength of the Inter-net mail system. It is also its greatest weakness. Because thesystem is biased in favour of delivery, it is prone to abuse inthe form of spam, viruses, and phishing scams. e 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 - attempt to

punish spammers for their trespasses. On a technical level,sender authentication protocols give computers new ways toautomatically distinguish forgeries from authentic messages.

e Underlying Concept

If you step back and squint, every plan for solving spam looksroughly the same.

Senders are asked to do X. Receivers are asked to checkfor X. If X is missing, receivers are to assume the messageis spam. X is meant to be hard for spammers and easy forgood guys.

Approaches mostly differ about what exactly goes into X.e challenge is to make X as lightweight as possible whileremaining robust and secure.

Under the Aspen Framework, X is two things together:authentication and reputation. (e third thing, accredita-tion, is used as a buffer for when the reputation part fails.)

Authentication, in turn, enjoys a surfeit of competing andcomplementary technologies.

e vision described here is actually an amalgam of threerelated visions: the gospel according to Sender ID, the gospelaccording to SPF, and the gospel according to DomainKeys.

Drivers; or, Whos Buying It

Receivers who want to reduce costs and improve their userexperience are expected to embrace the vision. Senders whowant to improve deliverability are also expected to go along.Between the two, network effects will drive both senders andreceivers in the direction of sender authentication.

http://www.aspeninstitute.org/Programt3.asp?bid=38 http://www.edventure.com/conversation/article.cfm?Counter=367986
http://www.aspeninstitute.org/Programt3.asp?bid=13218http://www.edventure.com/conversation/article.cfm?Counter=367986http://www.edventure.com/conversation/article.cfm?Counter=367986http://www.aspeninstitute.org/Programt3.asp?bid=13218


5/25


Vision Walkthrough

e vision for a spam-free email system contains many parts.is walkthrough describes the life cycle of an email messageunder a strong version of the vision. In practice, it may bepossible for you to alter or selectively weaken certain parts of

the model to suit local conditions.

AnMUA submits a message to anMSA usingSMTP

AUTH.

At present, many Mail User Agents (MUAs) are configuredto submit messages to a Mail Submission Agent (MSA) overport . e MSA accepts the message because the addressof the MUA is trusted.

e vision calls for MUAs to authenticate themselveswith a username and password to the MSA over port 87.Armed with that username, the MSA can better implementoutbound anti-abuse policies such as rate limiting. An au-

dit trail is also easier to follow. VPN submission is a goodalternative.

An accountable sender has published authorization

records in DNS.

At present, any host on the net can claim to be a Mail Trans-fer Agent (MTA). Open relays, open proxies, and zombiesare hard to distinguish from official MTAs run by respon-sible entities. Numerous DNS Block Lists (DNSBLs) attemptto identify the offenders, but they are inherently limited toa reactive mode of operation. Furthermore, inaccurate list-

ings oen cause collateral damage, and they can be hard tocorrect. Finally, playing whack-a-mole with . billion IPaddresses is a difficult scaling problem. On the flip side, ISPsmay maintain lists of IP addresses of known good senders.Maintaining those lists is a time-consuming endeavour.

e vision calls for accountable participants in the emailsystem to authorize certain MTAs as designated senders, add cryptographic signatures to outgoing messages, or doboth. -based authentication lets receiver MTAs distinguishaccountable MTAs from hijacked machines. Crypto-basedauthentication lets receivers authenticate message contentwithout reference to the sending . e two approachesare complementary and reinforce each other. Both involve

publishing records in DNS.

An authorized outbound edge MTA transfers a message toan inbound edge MTA.

It takes a fair amount of expertise for a human to extract the client from Received headers and guess whether it is

All experience hath shewn, that mankind are moredisposed to suffer, while evils are sufferable, than toright themselves by abolishing the forms to which theyare accustomed. [] it is their right, it is their duty,to throw off such Government, and to provide newGuards for their future security.

DECLRON O INEPENENCE

MUA: (n) Mail User Agent. What the end-user thinks of as my email program andwhat ISPs think of as the email client. Popular MUAs include Eudora, the Outlookfamily, and Mac Mail. Determines what the end-user sees of an email message. eentity responsible for signing and verifying S/MIME cryptographic authentication.Possibly also the entity responsible for verifying Sender ID (PRA) authentication.

MTA: (n) Message Transfer Agent. What ISPs think of as the email server and whatend-users oen dont think of at all. Popular opensource MTAs include Sendmail,Postfix, Qmail, and Exim. Popular commercial MTA vendors include Sendmail,Openwave, Ironport, Microso Exchange, and others. Can operate as a sender or as areceiver. When receiving, responsible for verifying SPF and other authentication.

Edge MTA: (n) On the sending side, an MTA which takes the role of an client tothe public Internet. On the receiving side, a server MTA which accepts connectionsfrom the public Internet from sending MTAs.

MSA: (n) Message Submission Agent. What an MUA thinks of as an server.Usually set up by an ISP to receive mail from end-users. Oen whitelists the dialup/broadband range. May also be the outbound edge MTA. Unlike a receiving MTA,

must require when accepting connections from outside trusted network.See 476.

Zombie: (n) An end-user machine under the control of a virus, oen used to sendspam. It is estimated that up to one in three machines might be infected with wormsand viruses. Zombies can send spam direct-to-X or routed through an ISP MSA.


6/25


authorized to send mail on behalf of the purported sender.At present, there is no easy way for computers to do the samething.

Also, while it is possible to say that a given message, ifsigned, is authentic, it is not currently possible for computersto conclude that a message not signed is a forgery.

e vision calls for receiving MTAs to automatically veri-fy incoming sessions against the information publishedin by senders. is constitutes the sender authenticationstep. ere are three main classes of results: , , and.

e receiving MTA also makes a receiver policy decisionabout senders.

All senders can authenticate themselves. Spammers will too.erefore authentication checks alone are not sufficient.

e vision calls for the receiving MTA to also decide if itlikes or dislikes the sender. is decision can be based on

a purely local opinion. It can also be informed by opinionsfrom third parties.

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

sion.

If you are in my addressbook, I would probably be happy toread mail from you.

e vision calls for the receivers to help distinguishwanted mail that passes authentication from unwanted mailthat also passes authentication. If the happens to knowwhats in the end-users addressbook, then that decision can

be optimized up into time.

Reputation and accreditation services record assertionsabout senders.

At present, reputation services exist in the form of DNSBLs.ey are based on IP address and generally assert an opin-ion that a given IP address should be blocked. Accreditationservices also exist in the form of DNSWLs. ey vouch forassertions made by legitimate senders who care very muchabout deliverability. ey may be backed by some kind offinancial bond.

e vision calls for these services to also keep track of

senders by domain name and to indicate if, and why, certaindomains should be considered good. is makes it possiblefor receivers to recognize known good senders and confer asort of first-class status to their messages. Messages thatpass the joint test of authentication and reputation can thenchoose to bypass other more expensive and potentially error-prone content-based antispam tests.

In fact, if youre in my best friends addressbook, Iwould probably be happy to read mail from you.Emerging technologies such as LOAF (http://loaf.cantbedone.org)and http://www.web-o-trust.org/are good examples of experiments in this space.

A useful review of many blacklists can be found athttp://www.sdsc.edu/~jeff/spam/Blacklists_Compared.html

Today, many s keep local whitelists and blacklists.ese lists are not shared with their peers, and sotheir utility is limited. Many s also use publicwhitelists and blacklists.

Reputation service:(n) offers opinions about senders, usually based onempirical observation ofpast behaviour. Operates on behalf of receivers.May be expressed as spamtrap counts, a binary vote, a ratio of complaints tototal message volume, etc. Receivers need to decide for themselves whatopinions mean.Examples: movie reviews, s (Spamhaus, Spamcop).

Accreditation serv ice: (n) offers assertions about senders, usually based onrepresentations made by senders. Operates on behalf of senders. May beexpressed as a list of reasons for predictingfuture behaviour.Example: rated R, Bonded Sender, Habeas, Verisign VDL.

How to tell the difference? Very crudely: follow the money! If the senderpays to be listed, its accreditation. If the receiver pays them for theiropinions, its reputation.
http://loaf.cantbedone.org/http://loaf.cantbedone.org/http://www.web-o-trust.org/http://www.sdsc.edu/~jeff/spam/Blacklists_Compared.htmlhttp://www.sdsc.edu/~jeff/spam/Blacklists_Compared.htmlhttp://www.sdsc.edu/~jeff/spam/Blacklists_Compared.htmlhttp://www.sdsc.edu/~jeff/spam/Blacklists_Compared.htmlhttp://www.web-o-trust.org/http://loaf.cantbedone.org/http://loaf.cantbedone.org/


7/25


e receiving MTA records the results of the joint tests inthe 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 aDNSBL, the message is simply blocked or dropped. Other-

wise it is let through. e reasons for accepting or rejecting amessage are generally not exposed to end-users.

e vision calls for receiving MTAs to record attach au-thentication and reputation metadata to messages. e mostnatural place to put that data is in the headers. Spammerswill try to spoof those headers, but that problem can besolved because communications between a receiver , amessage store, and an end-user occur within a confinedspace.

e receiving end-users MUA displays a confidencemark.

At present, s lack a consistent, industrywide, visual lan-guage for describing the confidence an end-user should placein a message. We need the equivalent of the padlockicon.

e vision calls for receiver s to add an explanatoryvisual element to displayed messages. at element can helpfight forgeries by warning of authentication . is helpscombat phishing and spoofing. Ms should also distinguisha dual- result (where both authentication and receiverpolicy tests approve the sender) to help fight false positivesand improve deliverability of legitimate mail.

When the is actively involved in analyzing and clas-

sifying the message, it has all the information it needs to dothis. When the is operating passively downstream fromthe point where that decision is made, it can simply displaythe information recorded in the message headers.

Not Junk: e opposite of the Junk Mail folder.

At present, s may file suspected spams into a Junk Mailfolder based on Bayesian filtering and other logic.

e vision calls for s to file dual- messages intothe 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 ofcomplex heuristics intervenes and identifies some messagesas spam.

e vision calls for the market to move toward a default-reject orientation. Once the Not Junk folder gains wide ac-ceptance, the next step is to think about simply rejecting anymessages that would not make it into that folder.

It is rumoured that 0 to 5% of AOL andEarthlinks userbase have switched towhitelisting-only spam filtering.


8/25

About Sender Authentication w Sender Authentication: What To Do

A S A

-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-er of sender authentication technologies. ey publish records and sign messages with DomainKeys. Here are someheaders from a message they sent from mengwong@gmail [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 ; Wed, 27 Oct 2004 23:09:16 -0400 (EDT)

Received: by rproxy.gmail.com with SMTP id 80so309rnk

for ; 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 outboundmailers. In Paul Vixie wrote up the idea in a papertitled Repudiating M-F. In Hadmut Dan-

isch independently authored a specification called ReverseMX (RMX). Around the same time, Gordon Fecyk wrotea similar specification called Designated Mailer Protocol(DMP). Later that year Meng Weng Wong combined somefeatures of RMX and DMP into SPF. SPF originally stoodfor Sender Permitted From, but changed its name to SenderPolicy Framework. Microso also wrote a specification,Caller-ID for Email (CID), as part of a Coordinated SpamReduction Initiative proposal (CSRI). While they differed ina number of ways, all of these proposals shared the conceptof using records to authorize clients to be s.

While all this was going on, Yahoo! was developing acrypto-based approach, called DomainKeys (DK). In early

rough consensus appeared in the email industry toproceed with both -based and crypto-based approaches.To make things easier, Microso and Meng worked tomerge and into a single proposal in the work-ing group of the . Work began in earnest in May and aconverged specification was concluded in October under thename S ID.

There was another bookish lad in the town, JohnCollins by name, with whom I was intimatelyacquainted. We sometimes disputed, and very fond we

were of argument, and very desirous of confuting oneanother, which disputatious turn, by the way, is apt tobecome a very bad habit, making people often extremelydisagreeable in company by the contradiction that isnecessary to bring it into practice; and thence, besidessouring and spoiling the conversation, is productive ofdisgusts and, perhaps enmities where you may haveoccasion for friendship. I had caught it by reading my

fathers books of dispute about religion. Persons of goodsense, I have since observed, seldom fall into it, exceptlawyers, university men, and men of all sorts that havebeen bred at Edinborough.

AutobiographyBENJMN FRNKLN

Sendmail, Inc is another enthusiastic pioneer in sender authentication. Seehttp://www.sendmail.net/ for details on the Messaging Integrity Pilot Program.
http://www.sendmail.net/http://www.sendmail.net/http://www.sendmail.net/http://www.sendmail.net/


9/25

About Sender Authentication w Sender Authentication: What To Do

How IP-based Authentication Works

Most legitimate mail from a given domain enters the Internetfrom a relatively small set of servers. If we can identify thoseservers and list them in machine-readable form in , re-ceivers can easily check incoming messages against that list.

Messages that come from an approved server are consideredauthenticated. Messages that dont come from an approvedserver may be considered forgeries. Exactly how a receivertreats suspected forgeries depends partly on what the senderhas specified as a default in such cases.

e SPF record

SPF records use a simple syntax which any administra-tor should find intuitively familiar. Records are easy to set upby hand. Here is an example record: v=spf1 mx

It means that the servers for the domain are explicitlypermitted to send mail from that domain.

How SPF Classic Works

Every transaction begins with a command.SPF Classic examines the return-path identity given in the command. It tests the client against the re-cord for the domain in the return-path. As it focuses on thereturn-path, SPF Classic is most obviously useful for helpingfight bounce floods caused by undeliverable forgeries. But itis also useful in cases where the recipient of a forgery is deliv-erable. Even though the forgery may not result in a bounce,some harm can still be prevented.

How Sender ID works

When an displays a message, it shows who sent themessage, usually by extracting the From: header. Every well-formed email message contains a From: header. But a mes-sage may also contain a Sender: header. In that case, an may say to the end-user From Senderon behalf ofFrom.Microso took this concept one step further and defined thePurported Responsible Address (PRA). A Sender ID com-pliant displays: From PRA on behalf ofFrom. SenderID as originally conceived runs an test, but uses the PRAinstead of the .

Sender ID was recently resubmitted to the IETF. It nowspecifies that both the return-path and the PRA may be used.Soware that implements only SPF Classic can therefore becalled Sender ID compliant. In practice, most people associ-ate Sender ID with the PRA, and SPF Classic with the , or return-path.

e author recommends that soware implementSender ID with checking. e author recommends that soware implement Sender ID with check-ing, aka SPF Classic. e author also recommends watchingto see how crypto develops.

If the is empty, SPF Classic fallsback to the argument. is is useful forhandling bounce scenarios and closes aloophole whereby spammers could just sendmail with a null .

Bottom Line: e records that you create need to work inboth and contexts. Someone might belooking at your record because your domain showed up ina , or because the was blank and yourdomain showed up in the . If none of your servers using a given domain name, then you only have toworry about use of that name. If youre setting upan record for a hostname, you probably do want to ensure

the record will work for . You can do this easily byadding an a mechanism.

Politics. Some have characterized Sender ID as SPF with PRA bolted on. e IETFcommunity has roundly criticized the PRA on both technical and licensing grounds.Some members of the technical community assert that the very idea of using PRA forheader validation is flawed. Other observers comment that the patent license whichsurrounds PRA makes it unpalatable to implement.

A potential security vulnerability may occur if an validates a address whichis not actually displayed to the end-user. If an upstream validates the andrecords the authentication results in a header, and if an displays that authentica-tion result as a mark of confidence, that must be very careful to also display thevalidated address to the end-user. Until more s display the , the author expectsfew soware engines to implement checking. Commercial soware,however, will probably find it useful, at least until cryptographic solutions designedexpressly for 8 content checking mature.

At least one major commercial vendor has publicly stated it will proceed with

PRA checking. Microso appears to be preparing to turn on Sender ID checking inHotmail, Outlook, and Exchange. e latest versions of Outlook are expected to displaythe PRA where available, rather than just the Sender header.

Sendmail, Inc. has released experimental milters for Sender-ID that check both the (SPF Classic) and the PRA. Other commercial vendors have done thesame. Generally, however, SPF Classic is more widely supported than PRA at this time.

SPF features a best-guess technology which basically says: if adomain does not publish records, try a/24 mx/24 ptr anyway.If that returns a , consider that a useful first approximation.is technique significantly reduces the deployment burden fortechnologically unsavvy senders who are lucky enough to obtain a using best-guess alone.

e PRA israwn not justrom the From

and Senderheaders, but

from theResent-From

and Resent-Senderaders as well.ee the SenderID specifica-

on for details.

e Patent Situation. Microso has two patents pending on Sender ID. While thepatent license offers Royalty Free terms, according to Lawrence Rosen Esq., thesublicensing provision of the patent license makes PRA incompatible with GPL freesoware such as Exim. Apache SpamAssassin, for example, have stated that they willnot 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.Some individuals are planning to work with http://www.pubpat.org/ to challenge thepatent on grounds of prior art and obviousness.

SPF Check: (n) a test of the validity of an address against a domain name. If thedomain name comes from the return path, youre doing an SPF Classic or SPFv1 check.If it comes from the PRA, youre doing a PRA check.

SPF record:(n) a v=spf1 record.spf2.0 records are for special casesonly. (Caller-ID records using theX format are no longer used.)

Tis forces spammers to have their owndomains and DNS servers, which meanswe can identify them more easily.

Tis is a big win!

J C, Georgia Voter
http://www.pubpat.org/http://www.pubpat.org/


10/25

About Sender Authentication 1w Sender Authentication: What To Do

How Cryptographic Techniques Work

All cryptographic approaches to authentication agree on thebasic concept: sign some portion of the message content andpresent that signature for verification. e approaches dis-agree about what gets signed, where the signature goes, and

how verification is done.PGP and GPG sign the message body only and put the

signature directly in the body. Keys are stored in end-userkeyrings or in public keyservers; key management uses apeer-to-peer web-of-trust architecture. e signature in-cludes a description of the signing entity, but s tend notto use that author data from the signature to override theFrom: header.

S/MIME signs the message body also, but presents thesignature in a logically distinct part. Keys are signedby a certificate authority, so key management follows a hier-archical model similar to . Signatures that do not matchthe From: header tend to result in some sort of user in-

terface warning.DomainKeys, originally championed by Yahoo!, signs

the body and some message headers. It puts the signaturein a DomainKey-Signature header. Keys can be self-signed,as in PGP, and published in following a decentralized,opportunistic encryption model. If a message fails signature

verification, it should be rejected by the receiving dur-ing time, but in practice will probably result in somesort of warning sign in the .

BATV signs the return-path only and places the signaturein the return-path. If a sender always signs its returnpaths, any bounces that come to a non--signed address

must be bogus. ough there is provision for a public mode,BATV primarily uses a private-secret key scheme becauseonly the signing system absolutely needs to authenticate itssignatures. BATV is a lot like VERP, but with a signature.

e latest evolution of SES also places the signature inthe return-path, but signs the message headers and body aswell, much like DomainKeys. SES also uses a private-secretkey scheme, but validation can occur at time! How?e sender system publishes an exists mechanism usingSPF; that mechanism instructs receivers to include the fulllocalpart in a query against the sender. When the send-ers server gets a query, it validates the signature. If asender system signs all outgoing mail with SES and runs a

custom SES-enabled server which can validate localpartqueries, it no longer needs to worry about forwarding falsepositives.

Jim Fentons Identified Internet Mail is similar to DK.Microsos Email Postmarks is essentially -to-

S/MIME which may be easier to implement in Exchange.e IETF MASS SIG has engaged the above proposals.

PGP and S/MIME have been around for a long time, but they are not widely used.While most s today support / natively, the vast majority of mail sent is notsigned. Why not? I dont know. Maybe the average end-user doesnt sign theiroutbound mail because they find it inconvenient to manage keys and enterpassphrases. But why dont the bulk mailers, even the well-organized volume s,sign their mail? Maybe they perceive a significant population of s that dontsupport /, and fear customer complaints. I am not aware of any publishedresults that give a basis for this fear.

In 999, the US Department of Defense published a policy mandating future use ofPKI technologies. ey chose / over because they rejected the web oftrust model in preference for the hierarchical Certificate Authority model. Use ofPKI certificates to access DoD restricted access web sites became mandatory October, 004. e DoD may similarly mandate / for email in the future.

See http://mipassoc.org/batv

See http://www.imc.org/ietf-mailsig/index.html andhttp://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatrix.htm

See http://ses.codeshare.ca/

IIM repeats the signed headers within the headers. is is better for mailing lists. Italso includes the public key with every message. DK and IIM are similar enough thamany industry insiders hope and expect them to merge in early 005.

Bottom line: cryptographic signing is performed by the . In -based protocols,senders have to go fiddle with . With crypto, senders have to put their public keyin , and also have to upgrade to an that supports signing.

Mailing lists use Variable Envelope Return Path to track bouncing subscribers.
http://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.html


11/25

About Sender Authentication 11w Sender Authentication: What To Do

Using Multiple Approaches

e Achilles Heel of -based schemes is forwarding: unlessthe forwarder rewrites the return-path, the final receiver willconsider the message a forgery because it doesnt come di-rectly from the original sender.

e Achilles Heel of cryptographic schemes is contentmunging: many mailing lists alter the message content duringtransit. Unless the mailing list manager re-signs the message,the final receiver may consider the message a forgery becausethe content has changed since the signature was created.

SPF Classic, an -based scheme, works well with mailinglists, because mailing lists always change the return-path tobe the mailing list bounce handler. DomainKeys, a crypto-based scheme, works well with forwarding, because forward-ing doesnt usually change message content.

Because one schemes meat is another schemes poison, itseems only prudent to use multiple schemes: that way, thestrengths cancel out the weaknesses. is is the basic idea

behind Unified SPF. Unified SPF is a syncretist theory thatalso admits , , , and checking.

e author recommends that prudent senders do at leasttwo things: they should publish records and eventual-ly sign messages with DomainKeys. Prudent receiver sshould check SPF Classic and DomainKeys at the .

Reputation Systems

Authentication alone is not enough. Reputation systems area key component of the Aspen Framework. ey 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: first-generation reputation systems tried to enumerate all the addresses which they considered bad. Next-generation rep-utations will try to enumerate all the domain names whichthey consider good. ere are many ways to do this. All ofthem are interesting.

What if a domain has no reputation? If it is patient, it cangradually acquire one simply by sending enough good mailto be noticed over time. Aer all, sensible receivers shouldnot reject outright mail from senders without a reputation;

receivers might just graylist or filter more aggressively. But ifthe domain is impatient or wishes to refute a bad reputation,it may choose to sign up with an accreditation service.

To unsub-scribe, send amessage to ...

Verbatim forwardingis a common practice: anyone who

has seen an /etc/aliasesor .forward

file knows what it is. Messages sent to aforwarding alias are remailed to the finaldestination. Unfortunately, thosemessages are oen reinjected without anyindication that forwarding occurred: thereturn-path remains unchanged, and nospecial headers are added to the message.

Forwarding is a problem for SPFClassic and Sender ID because forwardedmessages are difficult to distinguish fromforgeries! Under SPF Classic, forwarderscan help by implementing SRS SenderRewriting Scheme. Under Sender ID,forwarders are expected to prepend aResent-Fromheader. Neither isconvenient for forwarders. Receivers canalso help by simply whitelisting knownforwarders by address or name.

Forwarding is better under Domain-Keys because forwarding generallydoesnt munge content.

Bottom line: good for DK, bad for SPF.

Mailing liststend to append text to the body of a

message. is is a problem for

DomainKeys because content munginginvalidates the signature. DomainKeysexpects mailing list managers (MLMs) tore-sign messages and claim authorshipaer any content munging. is is notconvenient for mailing lists.

Mailing lists reset the return-path sothat bounces go back to the , not theoriginal author. is is good for SPFClassic.

While any mailing list worthy of thename resets the return-path, only somemailing lists add a Sender: header.EzMLM, a widely-used , does not.Yahoo!Groups doesnt add Sender: either,though in theory that can be fixed easily if Yahoo! cooperates.

Sender ID asks all mailing lists to add a

Sender: header. is is not convenientfor the installed base of mailing lists whodo not add Sender:.

Bottom line: good for SPF, bad for DK.

So lets do DK and lets do SPF!Imagine this: v=spf1 a mx dk -all

e Karma Project is an aggregationservice which reduces the burden onreceivers. Instead of talking to Nservices to get N results, receivers cantalk to a single service to get N results.Please contact the author for detailson feeding into and reading from theKarma system.

BondedSender.com and Habeas areexamples of services which vouch onbehalf of senders.

CSV is one

proposal thatfocuses on the or

hostnamegument as the

identity forverification.

If a sender domain publishes and signsusing both -based and crypto-basedmethods, and if a receiving domain findsthat neither method passes, it can be veryconfident that the message is a forgery.
http://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.htmlhttp://www.imc.org/ietf-mailsig/index.html


12/25

Deployment: For Email Senders 1w Sender Authentication: What To Do

D: F E S

All senders and receivers of email from the largest ISP tothe smallest personal domain should deploy one or moreforms of sender authentication in . You can deploy SPFand Sender ID today. is section tells you how. Comments

on DomainKeys are also provided for comparison.In this example, you are sender.com.

First, prepare.

Stopping forgery means stopping allforgery: good and bad.Over the years people may have gotten used to the lax natureof email, and your security-minded efforts to close loopholesmay encounter resistance from some people who find thoseloopholes quite comfortable and you quite annoying. Youare not alone: this is a classic change management problem.Sooner or later every computer professional encounters theeternal tension between security and convenience. If you

want to prevent bad guys from forging your identity, and ifyou want to do it by limiting the approved routes for out-bound mail, your end-users are going to have to use thoseroutes or risk being classified as one of the bad guys.

Audit Your Outbound Mailstreams

To begin, you need to identify all the ways in which legiti-mate mail from sender.com goes out onto the Internet. Out-bound mail usually comes from two sources: humans andmachines.

Mail from humans. Suppose end-users with addresses

[email protected]

set the server in their to smtp.sender.com. at is one mailstream: you need tofind out how mail submitted to smtp.sender.com appears tothe outside world. In the simple case, smtp.sender.com haspublic records that identify its outbound addresses.

Mail from machines. Machine-generated processes mayalso originate mail from addresses at sender.com for exam-ple, [email protected] . You need to identifyall such processes and the servers through which they injectmessages into the Internet. In the simple case, a corporatesystem corp.sender.com may be responsible for customerservice and automated billing.

Construct the record

Youve enumerated all the servers that originate mail fromsender.com. Now youre ready to describe them in syn-tax. A number of wizards are available online to help youcreate your record. If you have a complex configuration,you should see the SPF protocol specification for full details.

Under DomainKeys: you need to audit your outbound mailstreams too.

Under DomainKeys: you need to do different things for DomainKeys.ese sidenotes briefly describe what to expect under DK. DK is stillunder development and may incorporate features from IIM. When thecrypto approaches settle, expect a future version of this whitepaper to

include detailed deployment instructions. Meanwhile, keep in mind thatwhen people say DomainKeys, they may mean a future, more matureversion.

corp.sender.com

smtp.sender.com

corporate user MUA

automated process

corporate user MUA

customer MUA

customer MUA

customer MUA

The Net

Under DomainKeys: you upgrade your s to sign all outbound mail,and you publish public keys in . Upgrading s is generallyregarded to be more work. St ill, this approach is worth the effort.

If both corp and smtp.sender.comsend mail that looks like this:

MAIL FROM:

From: Some Sender

Assuming the following existing entries:sender.com A 192.0.2.222

sender.com MX 10 smtp.sender.com

smtp.sender.com A 192.0.2.2

corp.sender.com A 192.0.2.222

Here are some examples of how sender.coms record might look:

sender.com TXT v=spf1 a:corp.sender.com a:smtp.sender.com ?all

sender.com TXT v=spf1 a mx ~all

sender.com TXT v=spf1 ip4:192.0.2.0/24 -all


13/25


ink briefly about PRA and Mail-From contexts.

Youve identified and described the servers that send mailfrom sender.com. But there are actually two identities in-

volved: the return path in the 8 envelope,and the identity extracted from the 8 headers. In

the vast majority of cases, when you compose a mail mes-sage, the return-path and the are the same, and you onlyneed to create a single v=spf1 record. But if your situationis complex and you routinely create messages whose and differ, you may need to create an spf2.0/prarecord as well. In that case, your record might look like:

v=spf1 a:corp.sender.com a:smtp.sender.com ~all

spf2.0/pra ip4:192.0.2.0/24 ~all

Together, these records mean: if the client is corp.sender.com , then sender.com may legitimately appear in the return-path. if the client is smtp.sender.com , then sender.com may legitimately appear in the return-path. if the client is anything else, sender.com should not appear in the return-path. if the client is in the 192.0.2.0/24 subnet, then sender.com may legitimately appear in the headers.

Otherwise, sender.com should not appear in the headers.

Test the record, part

Figuring out your record is the first step, but how do youknow its doing what you want? ere are a number of

validation tools on the web. You paste your proposed record into the tool, and it tells you whether its syntacticallycorrect.

Put the record in DNS

SPF records are published in as records. ere aretwo common scenarios: domain hosting and direct control.If your domain is hosted, your hosting provider should

offer a web interface. Most hosting providers have startedoffering a option so customers can publish records.If your domain hosting provider does not, you may want totransfer management of your domain to another provider,or petition them to add support for .

If you run the nameservers for your domain, you oughtto be familiar with editing zone files. Common nameserv-ers include and djbs tinydns. An record in a zonefile might look like this:

sender.com. IN TXT v=spf1 ip4:192.0.2.0/24 a mx ~all

e equivalent record in tinydns might look like this:sender.com:v=spf1 ip4\072192.0.2.0/24 a mx ~all:300

You can confirm that the record appears in by using ns-lookup or dig. Until youre comfortable with the record,you should keep the low, so you can change it quicklyif you need to.

Under DomainKeys: DK deals only with 8 information, andwith only the From: and Sender: headers. It leaves 8validation to SPF. One might say that DomainKeys attempts tovalidate authorship, and SPF Classic attempts to validate the lasthop sender.

PRA: e Purported Responsible Address

is used primarily by Microso soware. Opensource and sowaregenerally prefer to examine the return path.

Bottom Line: Unless youre an outsourced Email ServiceProvider, you probably dont need to worry aboutcustomizing your record for the PRA. Getting it right for should be your first concern. But if forwhatever reason you want to explicitly disable PRA checks,

just add a blank record: sender.com TXT spf2.0/pra

Some validation tools are listed athttp://spf.pobox.com/certification.html

A new Resource Record type is being assigned, butadoption of new types is generally held to be aslow process. So records make do with X,which is widely supported and not explicitly reservedfor anything else.

ere is no central registry for publishing information. Your record is published directly inthe for your domain, which ultimately youcontrol.

A list of hosting providers which support X records can be foundathttp://www.spf.idimo.com/txt-supporters.html

Under DomainKeys: messages acquire anadditional header that signs the message content.For the example on p 9, the corresponding publickey appears in :

beta._domainkey.gmail.com. IN TXTt=y; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC69TURXN3oNfz+G/m3g5rt4P6nsKmVgU1D6cw2X6BnxKJNlQKm10f8tMx6P6bN7juTR1BeD8ubaGqtzm2rWK4LiMJqhoQcwQziGbK1zp/MkdXZEWMCflLY6oUITrivK7JNOLXtZbdxJG2y/RAHGswKKyVhSP9niRsZF/IBr5p8uQIDAQAB

FAQ:Do I need to publish an spf2.0/pr

record if it contains the same data as myv=spf1 record? No. Soware that operatin context will grokv=spf1 records fine. Use spf2.0/pra only to override.
http://spf.pobox.com/certification.htmlhttp://www.spf.idimo.com/txt-supporters.htmlhttp://www.spf.idimo.com/txt-supporters.htmlhttp://www.spf.idimo.com/txt-supporters.htmlhttp://spf.pobox.com/certification.html


14/25


Test the record, part

Getting your record into is a big step. Now every-body can read it! Again, you should use a validation tool tocheck it. But this time, instead of pasting your record intothe validator, you just give it the name of your domain. e

validator fetches the record from your directly and con-firms 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 todays Internet,we can assume that our domains are being routinely spoofedby malware. If you want to find out whos spoofing your do-main, you can add a mechanism to log any spoof attemptsseen by -enabled receivers. Youll need a nameserver thatlogs all queries made against it; and youll need to set up adomain that causes queries to hit that nameserver. Suppose

that domain is logger.sender.com. You can add an existsmechanism before the terminal all so your record lookslike this:

v=spf1 a mx exists:%{s}.S.%{i}.I.logger.sender.com ~all

e macros %{s} and %{i} expand to the sender address andthe client address, respectively.

You may find that you have legitimate end-users using anoutbound gateway you had not previously identified: maybetheyre using some third-party server, or maybe youdidnt know about a legal outbound route. Setting up a log-ging exists helps you discover these cases. In the first case,where an end-user is using an unapproved server, your

job is easy: tell the end-user that for security reasons he nowneeds to use sender.coms gateways to send sender.com mail. In the second case, you can just add the new out-bound gateway to your record.

Loose Ends: Publishing Records For Hostnames

is example has demonstrated how to publish an recordfor sender.com that works for both SPF Classic and SenderID. ats an excellent start, but it doesnt end there! Yourprimary domain name is certainly the first thing you shouldtake care of. But to be really thorough, you should put records on the hostnames under sender.com.

In this example weve 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 mayalso send non-delivery notifications (NDNs) directly. Mes-sages from mailer-daemon are typically addressed from thehosts themselves, and look like this:

Macros: the macro feature lets you insert data into thedomain arguments for mechanisms. %{i} expands to theclient address. %{s} expands to the full sender emailaddress. See the Protocol Specification.

If you dont want to set up logging yourself, you canuse a third-party logging service.See http://spf.pobox.com/certification.html

Dear Customer,isp.com prides itself on keeping up to date with the latest security

practices. As part of our work with our peers and partners to help fightspam, we are strengthening our security policies. We appreciate yourcooperation in making the following changes:

please ensure that your server is set to smtp.isp.comport 587 please run Windows Update

When you send mail from your [email protected], it is importantthat you send it through isp.coms servers. is helps authenticateyour messages and ensure that they are correctly delivered. If you send mailthrough any other servers, antispam soware on the receiving endmay classify your messages as spam.

You should also register your newly -enabled domain atthe online registry. Go to http://www.spools.net/ whereover 00,000 other domains have self-registered. By someestimates, the true number of -enabled domains has

already crossed the one million mark.
http://spf.pobox.com/certification.htmlhttp://spf.pobox.com/certification.html


15/25


HELO smtp.sender.com

MAIL FROM:

From:

To accommodate cases like that, you should publish re-cords for smtp.sender.com and corp.sender.com. eyllbe much simpler than the record for sender.com. In fact, all

they have to say is this:smtp.sender.com IN TXT v=spf1 a -all

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

at means: onlycorp 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-try. All sane senders do this. But some sites practice deferralrelaying: instead of queuing undeliverable messages on thesending server, they move messages to a different machine.is is done for performance reasons. e main sending

servers dont get clogged with queued messages, and the de-ferral servers can focus on retrying messages at a more lei-surely pace.

Ifsender.com practices deferral relaying, you should addits deferral relays to its record.

To F or not to F?

If you look at other sites with records, youll find thatsome of them end in ?all, some of them end in ~all, andsome end in -all. What should you do?

It depends. is is a tradeoff situation: you have to bal-

ance competing concerns. Conservative publishers mightstart with a ?all, move through ~all as conditions change,and (if all goes well) stabilize at -all. (Conditions changemeans users switch to the approved outbound relay,forwarders start prepending headers and implementing ,and you start signing with DomainKeys.) If you are very con-cerned about phishing, publish a all right away and acceptthat there may be some false positives due to noncompliantforwarders who are slow to upgrade. Otherwise, use a ~all.

Expect to use DomainKeys or other crypto

Cryptographic authentication is following in the footsteps of

-based authentication. When it becomes possible for yours to sign outbound messages with DK or a similar cryp-tographic application, you should do so. Solutions like SESand BATV are also maturing rapidly, and offer comparablefunctionality but with a different cost/benefit structure. Alater version of this whitepaper will describe cryptographicsolutions when they mature.

If

Deliverability is mission critical

Phishing is a major concern

Your users are still using 3rd party SMTP servers

All users are known to be compliant

You are worried about non-SRS forwarders

Enough forwarders have adopted SRS

(or you want to encourage them to)

The domain never sends mail

You need something in between ?all and -all

then set

?all

all

?all

all

?all

all

all

~all

Deferral Relaying: when a message is not immediately deliverable, queue it on adedicated retry server instead of on your main sending server.

Ifcorp.sender.com sends mail that looks like this:

HELO corp.sender.comMAIL FROM:

From: Mail Delivery Subsystem

Here is how your record might look:

corp.sender.com TXT v=spf1 a -all

Ifdeferrals.sender.comalso sends mail that looks like this:

MAIL FROM:

From: Some User

Or like this:

MAIL FROM:

From: Mail Delivery Subsystem

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

sender.com TXT v=spf1 a mx a:deferrals.%{d2} ~all

gmail.com and yahoo.com have started signing outbound mail with DomainKeys.Other s and email providers are poised to follow suit.

http://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatrix.htmcompares a number of cryptographic signature schemes.

Yes, this is yucky. Im sorry. I wish it werent. Meng
http://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatrix.htmhttp://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatrix.htmhttp://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatrix.htmhttp://www.elan.net/~william/emailsecurity/emailsignatures-comparisonmatrix.htm


16/25

Deployment: For Email Receivers 1w Sender Authentication: What To Do

D: F E R

Two Sides of the Coin

Sender authentication can be put to two uses. Messages fromtrusted senders that pass authentication can be saved straight

to end-user inboxes, bypassing expensive and potentially er-roneous content filtering. Messages that fail authenticationcan be identified as forgeries and rejected at time, si-lently discarded, or filed to a junk folder.

Recording Trusted Senders Who Passed Authentication

If a joint test shows that the sender is trusted and the messageis authentic, a receiving system should communicate that factto end-users. A receiving should record the test resultsin a header for consumption by a downstream .

Whitelisting Incoming Forwarders

ere are lots of forwarding services out there. Perhaps thebest known forwarders among the technical community areacm.org and pobox.com. Similar alumni forwarding ad-dresses are offered by universities. Domain hosting servicesquietly offer email forwarding as part of their standard ser-

vice set. And uncounted more ad hoc setups exist, runningout of a .forward file set up by an end-user who may haveforgotten all about it.

It is difficult to comprehensively whitelist all incoming for-warders. An has no a priori knowledge of its end-usersthird-party.forward files. But it can whitelist well-known

forwarders en masse thanks to trusted-forwarder.org. atdomain is both a and an of well-known for-warding systems. It includes acm.org, pobox.com, and manymajor alumni forwarding and domain hosting services. Itattempts to factor out the tractable parts of the forwardingproblem, and leaves only the ad hoc, unpredictable .forwardscenarios.

Trusted-forwarder.org has been in existence for over ayear. It is well maintained by Wayne Schlitt, a core mem-ber of the project. All implementations are stronglyencouraged to use it until cryptographic solutions solve for-warding for good.

What To Do About Forgeries

If the authentication test returns a result, what shouldyou do? A receiving can reject the session or usethe as a part of a spam scoring scheme. If the messageis not rejected at time, the receiving should recordthe test results in an Authentication-Results header forconsumption by a downstream .

e industry hasnt yet standardized on a way to dothis. Murray Kucherawy of Sendmail has draed aspecification for an Authentication-Results:header. I havent heard any complaints to date.

One school of thought says that because this sort of forwarding operates onbehalf of the receiver, it is the duty of the receiver system to whitelist theintermediate forwarder. Another school of thought contends that it is theresponsibility of forwarders to accept responsibility for reinjecting messagesinto the mailstream, and therefore forwarders should be prepending headersand doing . Either way the situation is messy, and nobody wants the hotpotato. Both schools are right to some degree. e pragmatist asks: whatcan we do if the other side is obstinate?

Progressive forwarders will prepend headers and do voluntarily,without taking the position that receivers should whitelist them; they willalso publish records for their domain names to make whitelistingeasier.

Progressive receivers will whitelist forwarders voluntarily by address orby validated domain name, without taking the position thatforwarders should do .

If the entire Internet were this progressive and polite, wed have solvedspam a long time ago.

Note that whitelisting means different things to different people. Aconscientious forwarder may aggressively spam filter, and only let throughgood mail; in that case, it would be safe to give them a free pass. But aforwarder that doesnt filter should be subject to the same content filteringas any other untrusted sender.

In the case of a false positive, the argument forsystem integrity weighs in favour of rejection at time. Legitimate senders deserve to knowwhen their mail isnt getting through.
http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txt


17/25

Deployment: For ISPs and Enterprises 1w Sender Authentication: What To Do

D: F ISP E

e 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 complementarytechnologies is outside the scope of this document, ISPs arestrongly encouraged to adopt them as part of a balanced an-tispam strategy.

O P restricts direct-to- spamfrom zombies. s should block port outbound on con-sumer-class connections by default. (Customer churn isalways less than feared.) If a customer needs the port un-blocked, s can do so on a case-by-case basis or offer a dif-ferent class of service. Business-class connections shouldleave port unblocked by default under the assumption

that customer organizations acting as s themselves runtheir own s and internally block port .

I P is also strongly recomended tocounter asymmetric routing attacks.

O is essential for roaming customerswho, in the stricter world of sender authentication, need toconnect back to their home to send mail. should be offered on port 87 because a roaming user mightnot be able to reach port . Encryption should be manda-tory: the option is widely supported. -

and port 6 are good alternatives.

C R DNS N gives receivers a wayto guess if a host is a zombie or a legitimate outbound .Consumer-grade machines should reside under a specificsubdomain. Production es should never contain their address in the hostname and must have consistent forwardand reverse .

S- R-L con-sumer-grade senders to a reasonable volume (perhaps messages per day by default) would be an effective way tostem the flow of spam from zombies. With , you

can do this based on username instead of address.

D O R- F can be aneffective optimization: if a customer node is sending mailwith a wide variety of sender addresses, some of whichwould fail tests, then it is highly likely that that node iscompromised. ISPs should match return-paths to authen-ticated user identities (e.g. the username): thisprevents cross-customer forgery and limits damage to theaffected user.

If the address appears in the hostname, together with adistinctive subdomain name, lots of people will recognizethat as a consumer-class broadband machine that shouldnot send mail. Conversely business-c lass accounts shouldget their choice of reverse naming, and the hostname should resolve back to the actual .

Some filters are unable to cope with embedded wildcardsso the distinctive tag should appear on the right hand side.

Good: 192-0-2-2.adsl.isp.comBad: 2-2.adsl.192-0.isp.com

Some commonsubdomains:dsl adslcable cablemodemcust customerdial dialupdyn dynamicppp pppoebroadband


18/25

Deployment: For MTA Vendors 1w Sender Authentication: What To Do

D: F MTA

Which specification?

One half of Sender ID is SPF Classic. e original SPF Clas-sic specification was frozen in early January . It has

evolved in only minor details since then. It was submittedto the IETF in October and is expected to be publishedas an experimental . When it is published, vendorsare encouraged to update their implementations to match it.Vendors who implement SPF Classic can indicate that theyare Sender ID compliant.

e other half of Sender ID is the PRA check. MTA ven-dors may also wish to implement that half. Specificationsdescribing the PRA and how it fits into Sender ID were sub-mitted to the IETF in October as well.

Conformance testing

e easiest way to ensure that an implementation is confor-mant, of course, is to run it through an industry-standard in-teroperability test suite. Certification programs for SPF andSender ID are in the works and will be announced publiclywhen they are ready.

Perform SRS and prepend headers when forwarding

When automatically forwarding mail, s should do twothings: rewrite the return-path using , and prepend a Re-sent-From header.

Add ESMTP support for Submitter

In server mode, advertise and accept the 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. MTAsshould record authentication results in as much detail as pos-sible into headers. MTAs should, of course, be sensitive toheader spoofing. ey can do this by renaming or removingpreexisting headers. See the sender-auth-header internet-

dra 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 tosend mail to [email protected].

See also http://spf.pobox.com/developers-guide.html

See http://www.microso.com/senderid

See http://spf.pobox.com/rfcs.html

See http://spf.pobox.com/srs.html and http://www.libsrs2.org/

The nice thing about standards is that there are so manyto choose from. Furthermore, if you do not like any ofthem, you can just wait for next years model.

ANREW S. TNENUM
http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://spf.pobox.com/developers-guide.htmlhttp://www.microsoft.com/senderidhttp://spf.pobox.com/rfcs.htmlhttp://spf.pobox.com/srs.htmlhttp://www.libsrs2.org/http://www.libsrs2.org/http://spf.pobox.com/srs.htmlhttp://spf.pobox.com/rfcs.htmlhttp://www.microsoft.com/senderidhttp://spf.pobox.com/developers-guide.htmlhttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txt


19/25

Deployment: For MUA Vendors 1w Sender Authentication: What To Do

D: F MUA

Displaying Authentication-Results

MUAs need the email equivalent of the padlock icon.An can rely on an upstream to produce an Authen-

tication-Results header. It can also perform authentica-tion checks directly: if the message was cryptographicallysigned this is easy. If the message was not signed, and the needs to use Sender ID techniques, this is a little moredifficult.

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 messageshould be considered trustworthy only if it passed both tests:authentication and local receiver policy. MUAs can contrib-ute to the local receiver policy decision: if a message wasauthenticated, and the sender appears in the end-users ad-dressbook, that might add up to a dual-. MUAs should

add a clearly visible warning to messages that fail authen-tication and could refrain from displaying inline images bydefault.

MUAs should also consider adding a Not Junk folderand automatically file trusted messages into that folder. eobvious idea is to give good messages attention priority. esubversive idea is for end-users to one day say hey, I donteven look at my Junk Folder any more, so Ill just set that toauto-delete (or reject); and now that I think about it, thatstrue for the regular inbox too! e Not Junk folder willbe all that remains.

Automatic switching to port 87

e ISP industry is moving toward the practice of blockingoutbound port from consumer-grade dialup and broad-band nodes.

is means that roaming users will increasingly findthemselves in need of an alternative port for message sub-mission. at port is port 87, as defined in 76.

At present, users need to hunt down the configurationdialog which lets them change their submission port from to 87. is can be challenging: s sometimes hide thatconfiguration point in esoteric places.

MUAs should automatically probe port 87 when submit-

ting mail. Since they already possess the end-users user-name and password for message retrieval, they should haveno problem performing authenticated submission with . If the 87 attempt fails they can fall back to port .All of this can occur behind the scenes without user inter-

vention which is the way it should be.

J

K

LL L

LLL

L

L

Some possibilities for MUA displays.
http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txthttp://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-00.txt


20/25

Deployment: For ESPs w Sender Authentication: What To Do

D: F ESP

When a big brand wants to mail many, many customers, itoen 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, seehttp://spf.pobox.com/esps.html

Dont look like a phisher!

In the last few years, the chaotic world of volume-mailingoutsourcing has shot itself in the foot: the standard configu-ration for an outsourced campaign now looks practically in-distinguishable from a phishing attack. ESPs need to maketheir relationship with their clients a little more obvious.

Delegation

DNS comes with a delegation feature. Use it! Suppose yourclient is bigbox.com, and youre esp.com. You should try toget the client to set up esp.bigbox.com which delegates toyou; you can then use esp.bigbox.com in your mailings withfull control of the .

If your client is too small or too unsophisticated to set updelegation, and if they just want you to use their name direct-ly in their mailings, youll need to get them to include:you in their record.

Publish Appropriately

ESPs are the one sector who might need to distinguish and scopes. Well walk through an example.

Suppose an ESP, esp.com, has been contracted by a cli-ent, bigbox.com. e ESP sends mail using through a server,outmta.esp.com. Bounces and unsubscribes are directed tobounces.esp.com .

If you wanted to distinguish PRA from scope,you might use the following records:

1 bounces.esp.com2 v=spf1 a:outmta.esp.com ?all3 spf2.0/pra -all

4 bigbox.com5 v=spf1 a:corp.bigbox.com -all

6 esp.bigbox.com7 v=spf1 -all8 spf2.0/pra a:outmta.esp.com

ESPs who feel in need of further guidance arewelcome to contact [email protected] directly.

e author recommends that ESPs set up their mailings to look like this:

MAIL FROM:From: Big Box Stores Sender: Reply-To:

e PRA algorithm selects the Sender header.

Line is for the . e default is ?all because for this mailing campaign andthis domain, bounces.esp.com, were more concerned about mail getting through thanabout preventing forgeries. Line 3 is for the PRA. It states: well never use the domainbounces.esp.com in a From: or Sender: header, only in the envelope.

Line 4 is for the client,bigbox.com , which outsources all of its marketing mailings andonly uses bigbox.com for corporate accounts. it is more concerned about phishing thanfalse positives due to forwarding, so it sets -all.

Lines 7 and 8 are for the outsourced relationship domain esp.bigbox.com. it indicatesthat ESP is a contractor for bigbox.com . esp.bigbox.com is never used in the return-path so the v=spf1 record is -all. But it is used in the Sender header, so the spf2.0/prarecord overrides it to allowoutmta.esp.com. e record does not end in a-allbecause, again, for this mailing were more concerned about mail getting through thanabout forgery prevention.

In the example below, bigbox.coms admins have delegated esp.bigbox.com toesp.com, soesp.coms nameservers are the ones that actually answer authoritativelyfor esp.bigbox.com. is makes it easier for esp.com to fiddle with esp.bigbox.coms records and whatever else. e alternative to delegation is the infrequentand troublesome need for ESP to call BigBox once every eighteen months or sowhen the details change.
http://spf.pobox.com/esps.htmlhttp://spf.pobox.com/esps.html


21/25

Deployment: For Spammers 1w Sender Authentication: What To Do

D: F S

Spammers are some of the most responsive players in theindustry. ey have been enthusiastic early adopters of au-thentication technologies. e Devils Advocate deploy-ment advice in this section forecasts the next few moves in

the game and predicts the final steady-state scenario. It ismeant to show how spammers will adapt and how the goodguys can respond.

Two Types of Spammers

ere are two major types of spammers in operation today.(Legitimate ESPs are not considered spammers.)

O is largely responsible for the phishingand identity-the fraud scams we see today. Many of thesecriminal gangs work across international boundaries.

C are responsible for the less obvi-ously criminal junk mail they actually try to sell a product.

e product may be held up in shipping, or it may not actu-ally deliver the advertised results, but some kind of sale isusually promised.

Publish SPF and sign with DomainKeys.

In the relatively near future, a sea change will occur so thatmail from senders who are not accountable will be widelyrelegated to third-class status.

Some receivers may look down on messages from senderswho do not have SPF or DomainKeys. To be on the safe side,spammers should publish and sign.

Stop forging random domains.

Sure, you could forge domains that dont have SPF records,but aer a while receivers will adapt by simply third-classingmail that doesnt authenticate. So this is only a temporarymeasure.

Buy your own domains.

ere are two main strategies. You could buy a domain,bring it online, and immediately spam with it. is worksbecause reputation service wont 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. is leads to the second strategy: buy a domain, leaveit mostly dormant for some time, and then spam with it inhopes that itll now look more reputable than a brand-newdomain. Because most new spam domains are bought withstolen credit cards, this strategy may be more costly unless

Note to civil libertarians: you can be accountable and anonymous at the same time.Were interested in getting identities on the Internet to persist long enough to attract astable reputation. Were not quite as interested in tying online identities to real-worldidentities, because support for whistleblowing is an important social value. But we wantto give receivers the ability, when faced with a range of messages from senders theydont know, to apply an ordering to those messages so that senders who have takensteps to distinguish themselves from spammers get some kind of priority over senderswho have not taken those steps. A sender might voluntarily choose to tie their onlineidentity 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 forsenders to distinguish themselves from spammers without requiring real-worldidentification.

According to some reports, over a thousand domains are registered each week and usedto spam.


22/25

Deployment: For Spammers w Sender Authentication: What To Do

you can find a sloppy registrar wholl leave up domainsthat were registered with stolen cards. But then, using such aregistrar might negatively affect your reputation. e authorrecommends that you experiment and see how it works out.

Reuse an expired domain.

You can effectively hijack someone elses good reputation byfinding a respected domain that is recently expired, and sendmail using that name. But reputation systems are likely topay attention to domain expirations and transfers, and nullout the reputation on a domain that has changed hands.

Try to buy accreditation.

Accreditation schemes may become widespread. e essen-tial ruse is to look like a good guy whose domain is simplynew to the Internet, so you can try to sign up with accredita-tion services that dont do very good due diligence. But ac-

creditation services that dont do very good due diligence arelikely to attract a poor reputation themselves.

Try to fake out reputation services.

Reputation services that depend on end-users are subject toattack, because you can pretend to be an end-user, and voteyour spam as ham. In fact, you can pretend to be severalthousand end-users. But as reputation systems grow moresophisticated, voters will be themselves subject to reputa-tion, so an attack may not succeed unless you can completelyoverwhelm a reputation services population.

Zombies should spam only their friends and family.

Botnets of infected zombies are your major asset today. Inthe future, you will need to upgrade your zombies to figureout credentials, label the spam as being from theactual zombie user, route it through the s , and onlydirect it to people in the end-users addressbook and mail-box. Spam sent through other routes and to unrecognizedrecipients will be unlikely to be delivered or read. Good swill counter with rate-limiting and outbound filtering.

Spread FUD about the edge cases.

None of the approaches are perfect. A message could be for-warded through a site that does not perform and doesnot prepend Resent headers; that message could then passthrough an that munges the content for perfectly goodreasons. is corner case is a favourite of technical perfec-tionists who use it to argue that one can never reliably rejecta message based on sender authentication. If this point of

view gains widespread public acceptance, you will be able tocontinue to spoof messages.

FUD: (n) Fear, Uncertainty, and Doubt.


23/25

Deployment Roadmap w Sender Authentication: What To Do

D R

Publishing SPF: At the First General meeting onNovember , a majority of members voluntarily agreedto publish records by the end of December . It is upto each member to decide which default to use. Most con-

servative members may wish to use ?all (neutral) at first;thats fine. More aggressive members may wish to use ~all(sofail). See the tradeoffs on p .

Support for TXT: Managed providers should support entries by the end of . Providers should link to awell-known third party wizard instead of offering their own.

Crypto Signing: Some members are planning to sign mes-sages with DomainKeys on an experimental basis in astheir soware develops this capability.

Checking SPF and DomainKeys: A testing and evaluation

program is underway. members expect to start testing incoming mail in and to incorporate the re-sult into spam scoring decisions in . DomainKeyschecking should occur close to that timeframe also.

Forwarder SRS: Forwarders should perform SRS on for-warded mail and prepend headers by the end of .

Honoring Authentication Failures: If a sender domain usesa all default, and if a receiver domain obtains a result,that receiver may reject the message during the trans-action. It should not generate a bounce message. In ,

senders should setall

defaults, and receivers should moveto begin to honour all by rejecting. Senders who are par-ticularly concerned about noncompliant users or forwardingfalse positives can define a ~all default.

Displaying confidence to end-users: ISPs should start re-cording Authentication-Results by the end of .MUAs sold aer that date should display a confidence markdistinguishing good senders from bad.

Requiring Authentication Passes: Spammers are expectedto start registering their own domains and churning throughthem. e 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 todays -based blacklists. e strong answeris to only accept mail that passes authentication and repu-tation/accreditation tests. ISPs should start offering a de-fault-reject type of mailbox in or sooner, make thatthe default offering for new signups, and give existing usersthe option to convert to default-reject.

Q4 2004 Senders and s publish records.

Q1 2005 testing continues. hosters support records.

Q2 2005 Forwarders do and prepend Resent-From.s display confidence to end-users withfoldering to first-class and business-class.s offer 87 for roaming users,tell new subscribers to configure that way bydefault. Cryptographic solutions mature.

Q3 2005 results widely used in spam scoring.Senders start signing outbound mail andtransition records to ~all or all.Receivers check inbound signatures andhonour s by rejecting.

Q4 2005 s offer default-reject mailboxes.

Spam ends. Bill Gates gets credit.

Note: the above deployment dates are the authorsrecommendations. ey are still incomplete, subjectto further development and discussion, and have notbeen ratified by any industry standards body. How-ever, if you wait for industry standards bodies to ratifythings, you may be waiting a really long time. atsaid, you should consider joining , which is aforum for collaboration and standards deployment inthe messaging space. (http://www.maawg.org)

To stay current on these issues, join the deploymentmailing list by sending mail to [email protected].

Contact the author for details on the Karma Project,which aggregates and multiplexes reputation feeds forconvenient lookup.
http://www.maawg.org/http://www.maawg.org/


24/25

Best Practices w Sender Authentication: What To Do

ISP B P C C

See also the Code of Conduct document and theASTA Technical Recommendations document.

. Noncompliance with 8 and 8 constitutes suf-

ficient cause to reject a message.

. When an outbound edge sends a domain name inthe argument, that hostname must be a Fully Quali-fied Domain Name (FQDN) that resolves to the addressof the .

.. Every outbound edge must have a reverse DNS() record that resolves to a hostname that in turn resolvesback to the address of that . To avoid looking like aconsumer-grade machine, it should not contain more thanone octet of its address in its hostname.

. Conversely, dynamically assigned consumer-grade sshould obviously contain two or more octets of their ad-dresses in their hostname. See p 7.

.. A dynamically assigned consumer-grade dialup or broad-band node should not expect to be able to send mail directlyto unrelated receiver s over port . ISPs should blockoutbound port either at the network routers or inside thecustomer broadband modem. ISPs should offer a messagesubmission server for end-users to use as an outbound mailrelay.

.. As a corollary for home users: unsecured wireless rout-ers can be configured to block port too. Meng personallysubmits mail over 87, so blocking port in his little Linksysgizmo () doesnt disrupt anything, and () makes him feelbetter about leaving it unsecured and open to the public.

. If an client appears to be a consumer-grade dialupor broadband node, and if that client does not demon-strate accountability, receivers may reject the connection.

Clients demonstrate accountability by publishing recordsor signing with DomainKeys.

IP addresses may be encoded in decimal or in hex.For example, 192-0-2-2.adsl.example.comorc0000202.adsl.example.com

Code of Conduct document currently being revised.

ASTA doc available at http://docs.yahoo.com/docs/pr/pdf/asta_soi.pdf
http://docs.yahoo.com/docs/pr/pdf/asta_soi.pdfhttp://docs.yahoo.com/docs/pr/pdf/asta_soi.pdf


25/25

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

sender authentication whitepaper

Documents