The IPFire Project is operating a lot of its own infrastructure that is supposed to give us all the resources we need to work on our project. Part of that is our own mail server.
This mail server is responsible for sending all emails – from registration verification mails of the forum, the mailing list or email with notifications from our monitoring system. Sadly we have to fight a lot of spam these days. That has never been an easy task and there will probably never be a proper solution. So it is all about keeping up in the race.
I never believed in techniques like filters that search for keywords or use Bayesian filters to classify unwanted emails. Once you found good heuristics the spammers change little things and you are totally screwed and ready to start over again. Also greylisting is a bad technique because it keeps me from receiving emails. We are living in a fast world. I want my emails instantly.
Sender Policy Framework
Last week a huge bunch of spam mails made me deploying SPF (Sender Policy Framework) support on our mail server, which I was already planning for a long time. You basically add a new SPF record into your DNS zone which grants or forbids certain email servers to send emails that originate from your domain. In the case of ipfire.org, there is only one email server that is allowed to send emails and therefore only this one has got the permission and no other email server else.
The SPF record that you can see for our domain in the shortened output of the dig command below, has a simple syntax which in our case allows all mail servers that have a MX record in this zone to send email (mx). All other mail servers are not permitted to do so (-all).
[ms@rice-oxley ~]$ dig ANY ipfire.org
…
;; ANSWER SECTION:
ipfire.org. 3600 IN MX 10 mail01.ipfire.org.
ipfire.org. 3600 IN SPF “v=spf1 mx -all”
;; ADDITIONAL SECTION:
mail01.ipfire.org. 3600 IN A 178.63.73.247
mail01.ipfire.org. 3600 IN AAAA 2001:470:7183:25::1
The opposite email servers will then evaluate the SPF record if it is configured to do so and reject any email that originates from ipfire.org and is not delivered from our own mail server. One cannot abuse our domain to send a ton of emails to others – that’s a slight improvement.
The more obvious improvement is that our email server (as it now evaluates SPF records, too) does not accept too many spoofed emails any more. There are a lot of cases to deliver spam that cannot be fixed by SPF, but still… SPF makes it much better.
Go ahead and support SPF
SPF only works really good if as many people deploy it as possible. If there is no SPF record in your DNS zone, all SPF-validating mail server will still accept emails from your domain from any email server in the world. So maybe you have the time to deploy SPF, too so that we can fight against spam – just a little bit.
Head over to http://www.openspf.org/ to learn all about how SPF works and how to deploy it on your mail server.
P.S. Please let me know if you are experiencing any trouble receiving/sending emails from/to us.