[CentOS] Reject Action For SPF

Wed May 9 14:16:18 UTC 2012
Asymmetrics Webmaster <webmaster at asymmetrics.com>

While is a bad idea to reject mail without SPF records, its a good idea to
reject email if the SPF record is present and incorrectly set or not
authorized for the sender (hardfail). 

SA works after the email gets in the queue, but the most efficient way,
whenever possible, is to reject it (not bounce it) before it gets in the
queue, as there is a chance the admin of the sender mail server gets a
notice sooner and take the necessary steps to identify compromised systems,
fix the problems etc.

-----Original Message-----
From: centos-bounces at centos.org [mailto:centos-bounces at centos.org] On Behalf
Of Giles Coochey
Sent: Wednesday, May 09, 2012 12:28 PM
To: centos at centos.org
Subject: Re: [CentOS] Reject Action For SPF

On 03/05/2012 18:07, John Hinton wrote:
> On 5/3/2012 12:40 PM, Prabhpal S. Mavi wrote:
> A couple of notes.
>
> 1. SPF was not designed to be used this way. It is doubtful that 
> anyone has written anything that even remotely considered this option in
use.
> You will likely have to write it yourself.
Correct, I will echo this:

First, you really don't want to do this (reject domains without a SPF
record). I would technically challenge anyone who thinks this is a good
idea.

Having said that, spamassassin with a milter will allow you to set a high
scoring rule for SPF checks, enough to blanket block them with a rejection.
If you go that far, try checking whether spamassassin's score based method
is better suited to fixing your problem.

(a) You save yourself having to really code your own solution.
(b) You end up with a better anti-spam solution overall.

>
> 2. SPF is still in RFC testing, so it is not yet a full internet 
> standard. And once it is, the standard still does not condone using it 
> the way you intend. IOW, there is nothing in the standard that states 
> you must have a SPF record to be a legit email domain. Basically, 
> you'll have a broken mailserver. We are actually stuck with having to 
> take ours off for the moment as one 'service' we use demands sending 
> email from their mailservers using our email address and they still have
no SPF record.
>
> If you do this, most likely you will not get around 90% of the good 
> email as SPF is not widely used as of yet. But I guess if you are only 
> interested in receiving email from a few 'known' domains... it could 
> work. Seems it would be easier to just blacklist all and whitelist the 
> few? If it is just for internal... perhaps a webmail system with no 
> outside email ability would be the way to go?
>