1 files changed, 62 insertions, 0 deletions
diff --git a/e-post/doman.mdwn b/e-post/doman.mdwn
index e1bb123..e48c93a 100644
--- a/e-post/doman.mdwn
+++ b/e-post/doman.mdwn
@@ -134,3 +134,65 @@ might be emphasized by the receiver's mail client (GMail
 instance).  This doesn't really disclose anything as our domain can be
 found in the mail header anyway, but if you prefer to have your own key
 drop us a line, we will find something out.
+
+## Should I publish a SPF (Sender Policy Framework) record for my domain?
+
+The [Wikipedia page](https://en.wikipedia.org/wiki/Sender_policy_framework)
+has a nice introduction to SPF; other references include the
+"official" [SPF page](http://www.openspf.org) and RFCs
+[4408](https://tools.ietf.org/html/rfc4408) and
+[6652](https://tools.ietf.org/html/rfc6652).
+
+`fripost.org` currently uses the following policy:
+
+    $ dig +short fripost.org TXT
+    "v=spf1 redirect=outgoing.fripost.org"
+    $ dig +short outgoing.fripost.org TXT
+    "v=spf1 a ?all"
+
+What it says is that `outgoing.fripost.org` is authorized to send mails
+`@fripost.org` (more precisely, that the authorized sending hosts' IPs
+can be found in the A and AAAA records for `outgoing.fripost.org`).
+This host is used whenever you use our Mail Submission agent or webmail
+for instance; if a message from a `@fripost.org` address is being sent
+from another host, the `?all`
+(aka [NEUTRAL](http://www.openspf.org/SPF_Record_Syntax)) says that we
+don't know whether the host is authorized or not, and that the receiver
+should proceeed as if there wasn't an SPF policy. With that information
+at hand, the recipient may decide to classify the message as SPAM or HAM
+for instance.
+
+If you have your own domain and use Fripost's infrastructure to send
+mails, you can point your domain to our policy, too.  Here are a few
+possible senarios:
+
+    example.org IN TXT "v=spf1 redirect=outgoing.fripost.org"
+
+Here `example.org` is merely copying Fripost's policy.
+
+    example.org IN TXT "v=spf1 include:outgoing.fripost.org -all"
+
+Here the policy says that mails `@example.org` should PASS if they're
+being accepted by Fripost's policy, that is if the sender host is
+`outgoing.fripost.org` and FAIL otherwise (where Fripost's policy would
+return NEUTRAL).  Note however that DNS is spoofable, and as
+unfortunately Fripost doesn't use DNSSEC at the moment, an attacker
+could for instance poison the DNS cache and fake the reply for
+`outgoing.fripost.org`'s TXT record.
+
+    example.org IN TXT "v=spf1 a include:outgoing.fripost.org -all"
+
+Here the policy is similar to the one before, but in addition the A and
+AAAA records for `example.org` are also allowed to send mails for that
+domain.  (For instance you have your own mail server, and use that of
+Fripost as a backup; or vice-versa.)
+
+
+Whichever SPF policy you choose, be sure to test it!  Please read
+OpenSPF's [FAQ](http://www.openspf.org/FAQ),
+[Common Mistakes](http://www.openspf.org/FAQ/Common_mistakes) and
+[Best Practices](http://www.openspf.org/Best_Practices) pages.
+There are e-mail based SPF testers; unfortunately the "official"
+`spf-test@openspf.net` doesn't work anymore, but you can use
+[Port25](http://www.port25.com/support/authentication-center/email-verification/)'s
+for instance.