On 5/3/2012 12:40 PM, Prabhpal S. Mavi wrote:

...

are you sure you want to do this? It will definitely result in lots of legitimate mail being blocked, because SPF is by no means ubiquitous.

You can set up your mail server to block mail if the SPF record suggests it, but I would never filter mail originating from domains having no SPF record at all.

Best regards,

Peter.

Dear Peter,

Thanks for your response. it is true what you are saying. but we want to set that way.

Prabh S. Mavi

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.

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?

On 5/3/2012 1:16 PM, Prabhpal S. Mavi wrote:

...

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.

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?

Dear Hilton. J

Thanks for your advice, i actually know this. what would you say about those who put there efforts to implement SPF. why they do it?

I have been on the SPF list since before Microsoft just about killed it. SPF is perhaps the most misunderstood function in the email world. It is not a spam filter. The SPF website will tell you that very early on. It is quite simply this. It is to battle domain spoofing. Or, to battle the use of a legit domain in a from address sent by a spammer woh has no rights to use that domain name. It is and always will be voluntary, as some domains simply cannot implement it. Their systems are too complex and the TXT record in bind won't allow enough characters. There are some other good reasons to not use it... or good situations where you are forced to not use it. Either way, it is simply a statement to the world that email from my domain should be coming from these IP addresses and that is all it is. The receiving end can choose what to do with that information. There is a gray area between it being called a spam filter or not... The SPF folks won't let you call it a spam filter.

It can do a really good job of avoiding finding your mailbox full of bounce messages, but that will only be reduced by the number of systems which did SPF checks. Ultimately, I think it will be a great thing, much like RevDNS is now, but we couldn't really get hard core on RevDNS until most of the major providers did. If you can't send email to AOL, Comcast, Netscape, Gmail and so on, then why should you be able to send to me?

If you are planning to run a legit world facing email server, planning to use SPF as you are will make it a very broken system and it will not be anywhere near RFC compliant.

Best, John Hinton

Thanks / Regards Prabh S. Mavi

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Hi Prabh,

Thanks for your advice, i actually know this. what would you say about those who put there efforts to implement SPF. why they do it?

*if* someone sets up SPF for their domain, SPF works. Among other things, it can greatly reduce the amount of backscatter you receive due to spammers using your address to send mail. So it's not futile at all, it's just not planned to be used the way you intend to do it.

Which SPF implementation are you using? And on which CentOS release?

Best regards,

Peter.

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@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Giles Coochey Sent: Wednesday, May 09, 2012 12:28 PM To: centos@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?