SPF answers to the standard list of questions

0.  Assumptions

SPF works best if a few requirements are met:

) invalid envelope senders (non-FQDN, no MX/A domain) and invalid SMTP
  client IPs (no PTR record) are rejected by the MTA before SPF is
  called.

) SPF will be used in conjunction with RHSBLs, to make the policy
  decision which is outside the scope of the SPF protocol.  SPF is an
  authentication mechanism, not a decision maker.

) SMTP receivers take a default stance of wariness; connecting clients
  are not given the benefit of the doubt by default.

On Thu, Oct 02, 2003 at 10:57:40AM -0400, Alan DeKok wrote:
| 
| 	I.1. Proposed design for addressing issues related to EHLO

SPF: Falls back to EHLO/HELO domain name only when envelope sender is
null.  If the EHLO/HELO domain name is not an FQDN, SPF returns
"unknown" and leaves policy decisions to the discretion of components
elsewhere in the MTA.

| 	I.2. Proposed design for addressing issues related to MAIL FROM

Domain owners may specify a variety of lookup mechanisms: they include
"mx", "host", "cidr", "include", and "spf".  These mechanisms provide
different ways for domain owners to designate mailers.  A special lookup
domain such as config._smtp_client.${DOMAINNAME} returns a TXT record
defining the desired mechanisms, which are evaluated in order.

When the lookup mechanism is "mx", a domain's MX servers are designated
as permitted senders for that domain.  This mechanism benefits from
caching.

When the lookup mechanism is "host", the results of an A lookup of the
given hostname are designated as permitted senders.  This mechanism
benefits from caching.

When the lookup mechanism is "cidr", the results of a TXT lookup of the
given hostname are designated as permitted senders in CIDR notation.
Alternatively, the CIDR range may be directly specified.  This mechanism
benefits from caching.

When the lookup mechanism is "include", the lookup recurses into a
new domain.

When the lookup mechanism is "spf", SMTP senders are designated in DNS
for a domain via
${REVERSED_ADDRESS}.${ADDR-TYPE}._smtp_client.${DOMAINNAME}.  SMTP
servers perform SPF lookups based on the domain name of the envelope
sender to determine if the originating MTA is designated by that domain.
This mechanism does not benefit from caching.  However, by requiring
explicit lookups, it does inform domain owners of which hosts are trying
to spoof their domains.

SPF can be read as the name for the lookup mechanism as a whole, or as
the name for the explicit reversed-address lookup.  If the overall
scheme is adopted, I propose we rename the specific mechanism back to
DMP.

| 	II.1. Do (or should) the designs require DNS protocol changes

TXT records are used.  No protocol or server changes are needed.

| 	II.2. What entities in the network have to implement these proposals

Domain owners have to publish SPF records.  Recipient MTAs need to
install SPF-aware modules or apply SPF patches.

| 	II.3. Do we have existing implementations of proposals
| 	      (MTA, MUA, etc)

MTA patches or plugins are available for Sendmail, Postfix, Qmail, and Exim.

About 500 domains currently publish SPF records.

SpamAssassin is building SPF support into its current development version.
ActiveState is building SPF support into its commercial antispam server.

Dyndns.org has agreed to publish SPF records on an experimental basis.

Mail::SPF::Query performs queries.  Mail::SPF::Publish helps publish SPF
records.

A standard C library is available for other MTAs to hook into.

| 	III.1. What is the cost of deploying the proposals
| 	       (time, effort, $$)

There is no monetary cost.

For domain owners, I estimate about 4 hours to learn about SPF and
create and test entries.

For SMTP servers, I estimate about 4 hours to learn about SPF and alter
existing MTAs.

For SMTP recipients, the bandwidth cost of performing the DNS lookup is
miniscule compared to the cost of accepting spam, worms, and viruses.

For domain owners, the bandwidth cost of serving the DNS records is
miniscule compared to the cost of handling bounces for forged senders.

Users of managed DNS services should assume their DNS provider will bear
the brunt of change: DynDNS, for example, has already said they will
publish SPF records automatically to go with the regular set of DynDNS
records.

Providers of forwarding services need to perform sender rewriting.  This
is the biggest cost.  MTAs need to perform sender rewriting to support
.forward, and to perform bounce message tracking in combination with
some kind of authentication / expiry scheme.

| 	III.2. What is the impact of the proposals on mailing lists
| 	       i.e. Does the behaviour of sender or receiver change?

Ditto DMP/RMX.

| 	III.3. What is the impact of the proposals on roaming users
| 	       i.e. Does the behaviour of sender or receiver change?

Roaming users who control their own domains are free to unset SPF when
they are romaing.

Others should use pop-before-smtp or SASL AUTH or other mechanisms to
dial home.

ISP customers who are upset by the authentication requirement are
outnumbered by those who will benefit from it, but a political problem
remains.

| 	IV.1. What part of the spam problem do these proposals address

Ditto DMP/RMX.

| 	IV.2. How can spammers work around these proposals

1) By registering new domains.

2) By discovering return-paths rewritten by forwarding systems, and
   sending forged bounce messages to those return-paths; this creates
   a potential open relay problem.  MTAs will have to start keeping
   databases of sender-rewritten return-paths and tracking abuse.

| 	IV.3. What is the cost to spammers of working around these
| 	      proposals

Low --- domain registration is cheap.

There is a bandwidth cost in accepting bounce messages.

Discovering forwarder return-paths is an order of magnitude more complex
than finding regular email addresses.

IV.3.5 How do the good guys respond?

By building automated reputation schemes that temporarily defer mail
from new and unrecognized domains until a generally-accepted verdict is
reached in the form of RHSBL responses.

| 	IV.4. How much of an impact do these proposals have on spam

Potentially, a lot.  The aim is to tilt the playing field in favour of
legitimate mailers.

First, major domain owners will start publishing SPF records.  SPF
adoption will grow slowly in the receiving-server space.  Those who
perform SPF checks will benefit from less spam.  Those who do not will
continue to get spam.  Some spammers will be satisfied with this new
balance for a time.

Eventually, though, spammers will start forging smaller domains.  When
those smaller domains start getting a huge volume of bounce messages,
they will start publishing SPF records in a hurry.

If everybody starts publishing SPF records, spammers will be forced to
start using their own domain names.  When escalation reaches this point,
RHSBLs will become important.

I do not expect to reach that point in the near future; instead,
spammers will be content to forge smaller and smaller domain names, and
SPF will keep painting them into a smaller and smaller corner.

| 	IV.5. Does the cost the implementing the proposals justify
| 	      the effort?

The cost to forwarding systems is the biggest obstacle.  The other costs
of implementation are miniscule compared to the bandwidth costs of spam.