DokuWiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Sender Policy Framework ======

''SPF'' is a fairly new technology fighting spam. Domains implementing ''SPF''
records allow other MTAs to verify whether an email originating from an
address inside the domain is being spoofed or not. The ''SPF'' record tells
how to determine this.

===== Setup In Bind =====

Although ''SPF'' records implement a quite mighty syntax, the setup for the
domains ''ifyouseekate.net'' and ''nwl.cc'' is fairly simple.

The domain ''nwl.cc'' uses ''mail.ifyouseekate.net'' as it's single MX,
therefore all ''SPF'' verification should be done inside the
''ifyouseekate.net'' domain, too:
<file>
$ORIGIN nwl.cc.
	IN	TXT	"v=spf1 redirect=ifyouseekate.net"
	IN	SPF	"v=spf1 redirect=ifyouseekate.net"
</file>
as the redirect never returns, there is no need for a final ''-all'' to deny
everything not accepted earlier.

Actual verification is done inside the ''ifyouseekate.net'' domain:
<file>
$ORIGIN ifyouseekate.net.
@	IN	TXT	"v=spf1 ip4:81.169.176.177 ip4:85.214.71.2 ip6:2001:6f8:900:708::2 -all"
@	IN	SPF	"v=spf1 ip4:81.169.176.177 ip4:85.214.71.2 ip6:2001:6f8:900:708::2 -all"
mail	IN	TXT	"v=spf1 ip4:81.169.176.177 ip4:85.214.71.2 ip6:2001:6f8:900:708::2 -all"
mail	IN	SPF	"v=spf1 ip4:81.169.176.177 ip4:85.214.71.2 ip6:2001:6f8:900:708::2 -all"
</file>
the ''ip4'' and ''ip6'' checks are considered the most efficient ones, and
therefore recommended. As mail from ''ifyouseekate.net'' and all it's managed
domains is being allowed only for three sending IPs, these checks are
absolutely sufficient. Note that the ''SPF'' records must exist for the whole
domain as well as for the MX host.

==== Fixing For Broken Relays ====

Regular behaviour is that mail relays must use SRS, else the relayed mails
would get classified as spoof, as they seem to origin from the relay but
having the same, unaltered envelope from address.

If the administrator of the relay is not able to setup SRS himself, one can
work around these broken hosts by using an additional statement in one's own
SPF records, referring to the relay in question.

===== SpamAssassin's SPF Support =====

To enable ''SPF'' verification in ''SpamAssassin'' insert the following line
into the file //init.pre//:
<file>
loadplugin Mail::SpamAssassin::Plugin::SPF
</file>
documentation about configuring ''SPF'' in ''SpamAssassin'' can be viewed using:
<file>
% perldoc Mail::SpamAssassin::Plugin::SPF
</file>

===== Client Setup =====

Like many others, I use a single MX for delivering all my emails. Unlike what
one might guess, this is **not** a problem with ''SPF''. The only thing one
has to make sure is that the local mail client specifies a valid envelope from
address (''-f'' flag to ''sendmail''). The "official" ''From:'' address being
displayed by most mail clients is obtained from within the mail header.

===== Objections =====

The fact, that hardly any mailserver implements SRS, introduces problems one
might not be aware of at first hand. I guess the most common problem comes with
mail being forwarded as requested by a //.forward// file on a remote system.
Imagine the following setup:
<code>
 [sender]----------->[relay]------------->[destination]
</code>
so the host named ''sender'' delivers a mail from a local user to a user on
host ''relay''. The destination user has a //.forward// in his $HOME, stating
an email address on host ''destination''. This causes host ''relay'' to
continue mail delivery to host ''destination'', **without** changing the
envelope sender used for the SMTP protocol.

Now imagine the same setup with all host having SPF RRs in their zone files and
doing SPF checks on incoming connections. In the first step of delivery, the
connection from ''sender'' to ''relay'', everything is fine. The SPF-RR allows
''sender'' to transfer mail for users of its own domain, and ''relay'' accepts
the mail. The problem comes with part two: ''relay'' tries to deliver the mail
to ''destination'', without changing the envelope sender. That means that
''destination'' will take the SPF record of ''sender'''s domain, which of
course denies ''relay'' to transfer mail for ''sender'''s users.

There is only a single real solution to this problem, namely setting up SRS on
''relay''. Or more generally: setting up SRS on any mailserver, just in case
one of the local users wants to have his mail forwarded to another machine.

==== Workarounds ====

After being confronted with exactly the above mentioned problem, I started
searching workarounds, hoping to still be able to do SPF checks on my own
mailserver.

=== Changing the .forward ===

A regular //.forward// on host ''relay'' would look like this:
<file>
user@destination
</file>
To force the mailserver on ''relay'' to initiate a new connection to
''destination'' (and therefore change the envelope sender to the local user's
address), one can use the following syntax:
<file>
"|sendmail user@destination"
</file>

== Problems ==

This workaround is problematic, too:
  * All local users on ''destination'' must be aware of this workaround, and strictly use it on all hosts they want to forward their mails to ''destination''.
  * Many email providers don't allow editing a //.forward//, but offer web interface based solutions instead, which makes it impossible to ensure the altering of the envelope sender.
  * **Bounces will loop!** Since relay forwards the mail giving the local user as envelope sender, any bounces from ''destination'' will be delivered to that user just to be forwarded to ''destination'' again. Finally they will be dropped or remain in the loop forever, but they will for sure never reach their real target, the original sending user on host ''sender''.

===== Links =====
  * [[http://www.zytrax.com/books/dns/ch9/spf.html|Howto - Define an SPF Record]]
  * [[http://rfc.net/rfc4408.html|RFC4408 - Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1]]
  * [[http://www.openspf.org/SRS|Sender Rewriting Scheme Explanation]]