La norme de vérification Sender Policy Framework (SPF) permet de vérifier qu'un email est bien envoyé d'un serveur gérant le nom de domaine en question. Ce mémo aide à la mise en place d'un enregistrement DNS de type TXT pour le SPF.
Mail-in-a-Box lets you become your own mail service provider in a few easy steps. It’s sort of like making your own gmail, but one you control from top to bottom.
SPF est une des solutions techniques qui permet d'identifier un serveur comme légitime pour envoyer un email avec un nom de domaine précis. On s'appuie sur les DNS pour effectuer cette configuration. Pour plus d'informations, je vous invite à consulter l'article SPF sur Wikipedia.
La syntaxe n'est pas très compliquée mais il a quelques subtilités qui nécessitent de regarder de la doc avant de valider les modifications. Par conséquent, j'ai écrit un script shell qui permet de générer facilement une entrée SPF.
Mass electronic surveillance by governments revealed over the last year has spurred a new movement to re-decentralize the web, that is, to empower netizens to be their own service providers again. SMTP, the protocol of email, is decentralized in principle but highly centralized in practice due to the high cost of implementing all of the modern protocols that surround it. As a result, most individuals trade their independence for access to a “free” email service. Mail-in-a-Box helps individuals take back control of their email by defining a one-click, easy-to-deploy SMTP+everything else server: a mail server in a box.
================================================================================
Edit:
Mail-in-a-Box only supports being installed on Ubuntu 14.04
cf https://github.com/JoshData/mailinabox/blob/master/scripts/start.sh
=> rm -rf
Ajouter une entrée SPF
Il vous faut simplement éditer vos zones DNS chez votre registrar, pour y ajouter une entrée de type TXT. L'instruction pour la cas décrit précédemment est :
v=spf1 a mx ip4:
Paramètres :
spf1 : la version de SPF
a : s'applique au A-record courant
mx : s'applique à l'entre MX courante
ip4<IP> : n'accepte que l'IP spécifiée (IP du serveur)
-all : refuse tous les autres
marche à suivre pour un serveur mail auto-hebergé
DKIM, and SPF are great ways for securing that your domain is not being used for spoof mails.
The Problem: Sender Address Forgery
Today, nearly all abusive e-mail messages carry fake sender addresses. The victims whose addresses are being abused often suffer from the consequences, because their reputation gets diminished and they have to disclaim liability for the abuse, or waste their time sorting out misdirected bounce messages.
You probably have experienced one kind of abuse or another of your e-mail address yourself in the past, e.g. when you received an error message saying that a message allegedly sent by you could not be delivered to the recipient, although you never sent a message to that address.
Sender address forgery is a threat to users and companies alike, and it even undermines the e-mail medium as a whole because it erodes people's confidence in its reliability. That is why your bank never sends you information about your account by e-mail and keeps making a point of that fact.
But it does not have to be this way!
The Solution: SPF
The Sender Policy Framework (SPF) is an open standard specifying a technical method to prevent sender address forgery. More precisely, the current version of SPF — called SPFv1 or SPF Classic — protects the envelope sender address, which is used for the delivery of messages. See the box on the right for a quick explanation of the different types of sender addresses in e-mails.
(There are other solutions that protect the header sender address or that do not care at all about who sent the message, only who originally wrote it.)
Even more precisely, SPFv1 allows the owner of a domain to specify their mail sending policy, e.g. which mail servers they use to send mail from their domain. The technology requires two sides to play together: (1) the domain owner publishes this information in an SPF record in the domain's DNS zone, and when someone else's mail server receives a message claiming to come from that domain, then (2) the receiving server can check whether the message complies with the domain's stated policy. If, e.g., the message comes from an unknown server, it can be considered a fake.
Once you are confident about the authenticity of the sender address, you can finally "take it for real" and attach reputation to it. While IP-address-based reputation systems like Spamhaus or SpamCop have prevailed so far, reputation will increasingly be based on domains and even individual e-mail addresses in the future, too. Furthermore, additional kinds of policies are planned for a future version of SPF, such as asserting that all of a domain's outgoing mail is S/MIME or PGP signed.
This new gem is from the SMTP Gmail FAQ at https://support.google.com/mail/answer/81126?hl=en
(Fun note: they call it the “Bulk Senders Guidelines”… hence apparently anyone running their own personal mail server falls in that category…)
“Additional guidelines for IPv6
The sending IP must have a PTR record (i.e., a reverse DNS of the sending IP) and it should match the IP obtained via the forward DNS resolution of the hostname specified in the PTR record. Otherwise, mail will be marked as spam or possibly rejected.
The sending domain should pass either SPF check or DKIM check. Otherwise, mail might be marked as spam.”