[SOLVED] Implementing SPF into Postfix

BAcidEvil · 06-08-2020, 10:08 AM

Hello everyone.

So I ran one of those "how secure is my email server" and it came back 85% and I failed for 2 reasons; 1 was apparently my Reverse DNS/MX records are not the same, though I have verified over and over again and see absolutely no issues with forward/reverse dns and 2nd I do not have SPF integrated/utilized in my Postfix setup.

I have indeed done my google searches and I have learned a lot about it but am still lacking the confidence and clarity.

I see on Slackbuilds.org there is a perl-Mail-SPF package which I can use but there are layers of dependencies upon dependencies I would need as well, which I am fine with, but I wanted to make sure that was the appropriate path.
If that is my solution then I can run with it and comply but I was also wondering if there was a different legitimate path to take with implementing SPF into my Postfix.

Thank you !

Ser Olmy · 06-08-2020, 10:45 AM

I don't know which testing service you used, but it may in fact be complaining about two very different issues:

Your domain may not have an SPF DNS record
Your mail server may not be checking the SPF records of other domains when accepting incoming mail

The first issue is resolved by adding an SPF TXT record to your domain, which you absolutely should do. It's a simple TXT record that looks something like this:

Code:

v=spf1 mx ~all

This means "accept mail from the server(s) listed as Mail Exchanger(s) for the domain and soft-fail all others".

You can add other parameters to the SPF record, such as IP addresses, references to other domains etc. The Wikipedia article on SPF is quite decent and goes into considerable detail regarding the SPF record syntax.

The second issue is addressed by adding SPF checking functionality to Postfix. I'm not all that familiar with Postfix, and I was a bit surprised to learn that apparently, SPF checking is done by a separate daemon called "policyd-spf", which is written in Python for some reason. I haven't checked in which Slackware or SlackBuilds package, if any, this component can be found.

Anyway, the daemon is started by Postfix itself rather than by the regular init scripts; it seems one has to add a few lines in master.cf to accomplish this. From this page:

Code:

policyd-spf  unix  -       n       n       -       0       spawn
    user=policyd-spf argv=/usr/bin/policyd-spf

I may be wrong, but I believe the "user=" parameter is a reference to a local user account used to run the service. In other words, a user by that name must exist.

Once the daemon is up and running, a reference in main.cf tells Postfix to do SPF verification. From the same site as above:

Code:

policyd-spf_time_limit = 3600
smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   check_policy_service unix:private/policyd-spf

The final line is the one that makes the difference here, the others may or may not be present in your file. The important point is to add it as the last entry in the list of "smtpd_recipient_restrictions".

BAcidEvil · 06-08-2020, 10:57 AM

Quote:

Originally Posted by Ser Olmy

I don't know which testing service you used, but it may in fact be complaining about two very different issues:

Your domain may not have an SPF DNS record
Your mail server may not be checking the SPF records of other domains when accepting incoming mail

The first issue is resolved by adding an SPF TXT record to your domain, which you absolutely should do. It's a simple TXT record that looks something like this:

Code:

v=spf1 mx ~all

This means "accept mail from the server(s) listed as Mail Exchanger(s) for the domain and soft-fail all others".

You can add other parameters to the SPF record, such as IP addresses, references to other domains etc. The Wikipedia article on SPF is quite decent and goes into considerable detail regarding the SPF record syntax.

The second issue is addressed by adding SPF checking functionality to Postfix. I'm not all that familiar with Postfix, and I was a bit surprised to learn that apparently, SPF checking is done by a separate daemon called "policyd-spf", which is written in Python for some reason. I haven't checked in which Slackware or SlackBuilds package, if any, this component can be found.

Anyway, the daemon is started by Postfix itself rather than by the regular init scripts; it seems one has to add a few lines in master.cf to accomplish this. From this page:

Code:

policyd-spf  unix  -       n       n       -       0       spawn
    user=policyd-spf argv=/usr/bin/policyd-spf

I may be wrong, but I believe the "user=" parameter is a reference to a local user account used to run the service. In other words, a user by that name must exist.

Once the daemon is up and running, a reference in main.cf tells Postfix to do SPF verification. From the same site as above:

Code:

policyd-spf_time_limit = 3600
smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   check_policy_service unix:private/policyd-spf

The final line is the one that makes the difference here, the others may or may not be present in your file. The important point is to add it as the last entry in the list of "smtpd_recipient_restrictions".

Hello and thank you for the response. When I get home I will look into what you have mentioned and linked.
I did mention 2 separate incidents but really only concerned about the SPF;

I have used several various tests and overall where it matters my Server is indeed secure but on the current test by emailsecuritygrader.com came back with a Reverse DNS Test failure which is a different issue but also SPF Client Test which was not a "fail" but was inconclusive. I figured after days abd days trying to figure out my Reverse DNS issue I would submit and try to attack this SPF issue for knowledge sake.

BAcidEvil · 06-09-2020, 10:37 AM

Quote:

Originally Posted by Ser Olmy

I don't know which testing service you used, but it may in fact be complaining about two very different issues:

Your domain may not have an SPF DNS record
Your mail server may not be checking the SPF records of other domains when accepting incoming mail

The first issue is resolved by adding an SPF TXT record to your domain, which you absolutely should do. It's a simple TXT record that looks something like this:

Code:

v=spf1 mx ~all

This means "accept mail from the server(s) listed as Mail Exchanger(s) for the domain and soft-fail all others".

You can add other parameters to the SPF record, such as IP addresses, references to other domains etc. The Wikipedia article on SPF is quite decent and goes into considerable detail regarding the SPF record syntax.

The second issue is addressed by adding SPF checking functionality to Postfix. I'm not all that familiar with Postfix, and I was a bit surprised to learn that apparently, SPF checking is done by a separate daemon called "policyd-spf", which is written in Python for some reason. I haven't checked in which Slackware or SlackBuilds package, if any, this component can be found.

Anyway, the daemon is started by Postfix itself rather than by the regular init scripts; it seems one has to add a few lines in master.cf to accomplish this. From this page:

Code:

policyd-spf  unix  -       n       n       -       0       spawn
    user=policyd-spf argv=/usr/bin/policyd-spf

I may be wrong, but I believe the "user=" parameter is a reference to a local user account used to run the service. In other words, a user by that name must exist.

Once the daemon is up and running, a reference in main.cf tells Postfix to do SPF verification. From the same site as above:

Code:

policyd-spf_time_limit = 3600
smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   check_policy_service unix:private/policyd-spf

The final line is the one that makes the difference here, the others may or may not be present in your file. The important point is to add it as the last entry in the list of "smtpd_recipient_restrictions".

Hello

I was looking over what you mentioned to add to my SPF TXT Record.. I own my Domains through Dotster and have all my DNS records through them and can also modify my TXT Record there. I see your format v=spf1 mx ~all and understand its purpose and meaning.

My current TXT, from Dotster, by default was set as v=spf1 ip4:66.96.128.0/18 ?all which is google.com so maybe that is their default.
I will change it to what you recommended... I thank you again. That link and your help have been awesome.

BAcidEvil · 06-09-2020, 09:15 PM

Quote:

Originally Posted by Ser Olmy

I don't know which testing service you used, but it may in fact be complaining about two very different issues:

Your domain may not have an SPF DNS record
Your mail server may not be checking the SPF records of other domains when accepting incoming mail

The first issue is resolved by adding an SPF TXT record to your domain, which you absolutely should do. It's a simple TXT record that looks something like this:

Code:

v=spf1 mx ~all

This means "accept mail from the server(s) listed as Mail Exchanger(s) for the domain and soft-fail all others".

You can add other parameters to the SPF record, such as IP addresses, references to other domains etc. The Wikipedia article on SPF is quite decent and goes into considerable detail regarding the SPF record syntax.

The second issue is addressed by adding SPF checking functionality to Postfix. I'm not all that familiar with Postfix, and I was a bit surprised to learn that apparently, SPF checking is done by a separate daemon called "policyd-spf", which is written in Python for some reason. I haven't checked in which Slackware or SlackBuilds package, if any, this component can be found.

Anyway, the daemon is started by Postfix itself rather than by the regular init scripts; it seems one has to add a few lines in master.cf to accomplish this. From this page:

Code:

policyd-spf  unix  -       n       n       -       0       spawn
    user=policyd-spf argv=/usr/bin/policyd-spf

I may be wrong, but I believe the "user=" parameter is a reference to a local user account used to run the service. In other words, a user by that name must exist.

Once the daemon is up and running, a reference in main.cf tells Postfix to do SPF verification. From the same site as above:

Code:

policyd-spf_time_limit = 3600
smtpd_recipient_restrictions =
   permit_mynetworks,
   permit_sasl_authenticated,
   reject_unauth_destination,
   check_policy_service unix:private/policyd-spf

The final line is the one that makes the difference here, the others may or may not be present in your file. The important point is to add it as the last entry in the list of "smtpd_recipient_restrictions".

Got it set up and verified. Still need a DMARC and a DKIM but that’ll be next. Thank you

BAcidEvil · 06-15-2020, 10:23 AM

Though the issue in regards to the topic is indeed rectified and I am greatly thankful I was curious about something; I noticed there is SERVER and CLIENT SPF Verification and I indeed resolved the Server verification but what steps are taken, if different, to verify the Client/incoming SPF or is this really generally a no concern issue.