Default SPF configuration?
- Daniel Beardsmore
- Posts: 28
- Joined: 06 Jan 2016 18:54
- Location: Hertfordshire, UK
- Contact:
Default SPF configuration?
Hello
[TL;DR]
What I'd like to know is, what is the default configuration that makes SPF actually work in EFA (by whatever means it does so)?
I'm trying to diagnose the behaviour of a feature that appears not to be configured, and lies about its functionality when tested directly.
[/TL;DR]
Back story:
Some time back, I set up two EFA servers, supposedly identically.
I've realised today that one of them is performing SPF checks just fine (I get hits for both SPF_ and SPF_HELO_ rules), and the other is not (I only get SPF_HELO_ rule hits).
Now, I've never configured SPF on either server, so this would suggest that it works out of the box. As such, I've never knowingly seen whatever configuration makes it work (or if I ever did, I've forgotten). The plugin is being loaded, though:
foosrv:/ $ grep SPF -r /etc/MailScanner/* /etc/mail/spamassassin/*
…
/etc/mail/spamassassin/init.pre:# SPF - perform SPF verification.
/etc/mail/spamassassin/init.pre:loadplugin Mail::SpamAssassin::Plugin::SPF
…
[ Edit: the envelope sender header is, of course, being added as expected ]
A manual spamassassin -D < /path/to/message check reports "cannot get Envelope-From, cannot use SPF" on both servers. I took a copy of the message file, added the missing X-foo-MailScanner-EFA-From header, and re-tested it, and it reported SPF_FAIL.
I don't think there's a configuration difference between the servers. Yet, SPF checking doesn't occur during actual message processing on just one of the servers. Instead of having to assemble and redact configuration files (and inadvertently omit whichever one is actually relevant) I'd like to know what's actually meant to be set. If that proves to be correct, then there must be something else wrong.
Incidentally, one server has EFA 3.0.0.8; both did, but I've upgraded the naughty one to 3.0.1.1 and all that seems to have happened is that Postfix keeps telling me that it is "running with backwards-compatible default settings", which I guess is a good thing.
[ Edited with updated information ]
[TL;DR]
What I'd like to know is, what is the default configuration that makes SPF actually work in EFA (by whatever means it does so)?
I'm trying to diagnose the behaviour of a feature that appears not to be configured, and lies about its functionality when tested directly.
[/TL;DR]
Back story:
Some time back, I set up two EFA servers, supposedly identically.
I've realised today that one of them is performing SPF checks just fine (I get hits for both SPF_ and SPF_HELO_ rules), and the other is not (I only get SPF_HELO_ rule hits).
Now, I've never configured SPF on either server, so this would suggest that it works out of the box. As such, I've never knowingly seen whatever configuration makes it work (or if I ever did, I've forgotten). The plugin is being loaded, though:
foosrv:/ $ grep SPF -r /etc/MailScanner/* /etc/mail/spamassassin/*
…
/etc/mail/spamassassin/init.pre:# SPF - perform SPF verification.
/etc/mail/spamassassin/init.pre:loadplugin Mail::SpamAssassin::Plugin::SPF
…
[ Edit: the envelope sender header is, of course, being added as expected ]
A manual spamassassin -D < /path/to/message check reports "cannot get Envelope-From, cannot use SPF" on both servers. I took a copy of the message file, added the missing X-foo-MailScanner-EFA-From header, and re-tested it, and it reported SPF_FAIL.
I don't think there's a configuration difference between the servers. Yet, SPF checking doesn't occur during actual message processing on just one of the servers. Instead of having to assemble and redact configuration files (and inadvertently omit whichever one is actually relevant) I'd like to know what's actually meant to be set. If that proves to be correct, then there must be something else wrong.
Incidentally, one server has EFA 3.0.0.8; both did, but I've upgraded the naughty one to 3.0.1.1 and all that seems to have happened is that Postfix keeps telling me that it is "running with backwards-compatible default settings", which I guess is a good thing.
[ Edited with updated information ]
Re: Default SPF configuration?
just guessing but I am pretty sure SPF gets checked through some DNS module of spamassassin so the obvious question is are both EFA instances setup as running their own local DNS? Maybe one is using a public service like Google#s 8.8.8.8 and thus the DNS checks for SPF won't work?
- Daniel Beardsmore
- Posts: 28
- Joined: 06 Jan 2016 18:54
- Location: Hertfordshire, UK
- Contact:
Re: Default SPF configuration?
What makes you believe that Google DNS doesn't support SPF lookups? I've never seen any evidence of that.
Re: Default SPF configuration?
that is not what I said. sorry for not having had the time to post a full explanation. I was referring to DNS recurision using public DNS, read this thread it should explain things in more detail. viewtopic.php?t=934
How is your EFA setup?
Go to EFA console, 4) IP Settings => 4) DNS recursion?
How is your EFA setup?
Go to EFA console, 4) IP Settings => 4) DNS recursion?
- Daniel Beardsmore
- Posts: 28
- Joined: 06 Jan 2016 18:54
- Location: Hertfordshire, UK
- Contact:
Re: Default SPF configuration?
It's Google DNS with recursion disabled. Actually, it should be updated to use our own DNS servers now.
Re: Default SPF configuration?
What are the actual differences between the two servers? Start with that and then you should find your problem.
Re: Default SPF configuration?
that should fix your problem. let us know if it did.Daniel Beardsmore wrote:It's Google DNS with recursion disabled. Actually, it should be updated to use our own DNS servers now.
- Daniel Beardsmore
- Posts: 28
- Joined: 06 Jan 2016 18:54
- Location: Hertfordshire, UK
- Contact:
Re: Default SPF configuration?
I've set that one server to use our own DNS servers, and that's not had any effect.
pdwalker: unfortunately, I believe that you were actually being serious …
pdwalker: unfortunately, I believe that you were actually being serious …
Re: Default SPF configuration?
Of course I am being serious.
You have a problem and you don't know where the problem is. So go back to basics. What are the differences? Obviously there is a difference or you would not be having a problem.
Otherwise, you're asking us to guess for you an answer for your problem from information we don't have.
So, what are the differences? Does the efa boxes serve the same domains? Who configured the boxes? Were they configured at the same time? Different times? By the same person? Different people?
When I have two "identical" systems that have a problem like yours, I go back and check all my steps to find out where the difference is, and then I inevitably find the cause of the problem.
If you want help, then you have to be helpful
You have a problem and you don't know where the problem is. So go back to basics. What are the differences? Obviously there is a difference or you would not be having a problem.
Otherwise, you're asking us to guess for you an answer for your problem from information we don't have.
So, what are the differences? Does the efa boxes serve the same domains? Who configured the boxes? Were they configured at the same time? Different times? By the same person? Different people?
When I have two "identical" systems that have a problem like yours, I go back and check all my steps to find out where the difference is, and then I inevitably find the cause of the problem.
If you want help, then you have to be helpful
- Daniel Beardsmore
- Posts: 28
- Joined: 06 Jan 2016 18:54
- Location: Hertfordshire, UK
- Contact:
Re: Default SPF configuration?
That was never my question. I want to know what makes the SPF checking work, and then verify that SPF checking is configured correctly. If I am satisfied that SPF checking is correctly configured, then clearly the problem lies elsewhere.
Re: Default SPF configuration?
I have a few more minutes to spare so I wanted to correct myself:
the issue with the recursive DNS only applies to spamassassin's DNSBL checks so it should not affect your SPF checks.
the issue with the recursive DNS only applies to spamassassin's DNSBL checks so it should not affect your SPF checks.
- Daniel Beardsmore
- Posts: 28
- Joined: 06 Jan 2016 18:54
- Location: Hertfordshire, UK
- Contact:
Re: Default SPF configuration?
They want to be on our DNS servers anyway, so that was worth changing!
Re: Default SPF configuration?
SPF checking requires a valid SPF _TXT entry in your DNS.
Do you have that configured properly? Have you tested your spf records for the related domains?
http://mxtoolbox.com/SuperTool.aspx
Do you have that configured properly? Have you tested your spf records for the related domains?
http://mxtoolbox.com/SuperTool.aspx
- Daniel Beardsmore
- Posts: 28
- Joined: 06 Jan 2016 18:54
- Location: Hertfordshire, UK
- Contact:
Re: Default SPF configuration?
I'm referring solely to EFA configuration. If you don't actually EFA's internal configuration, I would suggest that you leave someone who does know to provide the correct answer.
Besides, the SPF records to be checked belong to whatever domain the envelope sender purports to belong to.
Besides, the SPF records to be checked belong to whatever domain the envelope sender purports to belong to.
Re: Default SPF configuration?
spf records are checked by spamassassin as part of the spamassassin checks.
given your rudeness, I'll let you work out the rest for yourself.
given your rudeness, I'll let you work out the rest for yourself.
- Daniel Beardsmore
- Posts: 28
- Joined: 06 Jan 2016 18:54
- Location: Hertfordshire, UK
- Contact:
Re: Default SPF configuration?
My mistake was in providing any details besides a simple question, as it allows people to answer any question other than than one I wanted answering. It's obvious that something is different, but since EFA itself configured the server, I had no part in configuring SPF checking or pretty much any other aspect of it, and it's left as a reader exercise to determine what EFA ships with and how each component relates to each other component. So far as I am to believe, SPF checking should simply work, and if DNS is functional, there should be no reason for it to fail.
It seems reasonable to assume that the single loadplugin line I found originally is the single point where SPF checking is enabled, which would mean that it's running but broken, as opposed to not running at all.
Since any server is filled with red herrings, it's important to establish a base point to allow some of them to be excluded, leaving you with a smaller number of them to sink time into ruling out. If you don't know what makes something function, then it's much harder to establish what unrecognised factors may be playing a part in the matter at hand, and which of them are completely unrelated.
It seems reasonable to assume that the single loadplugin line I found originally is the single point where SPF checking is enabled, which would mean that it's running but broken, as opposed to not running at all.
Since any server is filled with red herrings, it's important to establish a base point to allow some of them to be excluded, leaving you with a smaller number of them to sink time into ruling out. If you don't know what makes something function, then it's much harder to establish what unrecognised factors may be playing a part in the matter at hand, and which of them are completely unrelated.
Re: Default SPF configuration?
that is correct.Daniel Beardsmore wrote:So far as I am to believe, SPF checking should simply work, and if DNS is functional, there should be no reason for it to fail.
It seems reasonable to assume that the single loadplugin line I found originally is the single point where SPF checking is enabled,
All I can contribute from this point forward is general advice to help you figure out on your own where the problem is:
- https://spamassassin.apache.org/full/3. ... n_SPF.html
- /var/lib/spamassassin/3.004001/updates_spamassassin_org/60_whitelist_spf.cf:
- /var/lib/spamassassin/3.004001/updates_spamassassin_org/25_spf.cf
Can you confirm that I got this right:
So if you are sending an email from user@domain1.tld to user@domain2.tld (hosted on EFA1) and from user@domain1.tld to user@domain3.tld (hosted on EFA2) you see different SPF checks and results? If yes, can you please do such a test and post the results here?
- Daniel Beardsmore
- Posts: 28
- Joined: 06 Jan 2016 18:54
- Location: Hertfordshire, UK
- Contact:
Re: Default SPF configuration?
When you view a message in MailWatch, you get a readout of rules triggered. The SPF rules simply don't appear, as though SPF checking simply isn't running. So far as I know, it's not DNS, as I get a correct response from running spamassassin -D manually, having added the custom Return-Path header that it's looking for (testing an offending message, SPF_FAIL was reported as expected).
OK, thank you, that's all I wanted to check.
OK, thank you, that's all I wanted to check.
- Daniel Beardsmore
- Posts: 28
- Joined: 06 Jan 2016 18:54
- Location: Hertfordshire, UK
- Contact:
Re: Default SPF configuration?
Interesting. org-name had changed at some stage, but X-foo-MailScanner-EFA had not, so the server wasn't consistent with itself.
I decided to simply alter the Perl module to log directly:
Mail::SpamAssassin::Logger::add_facilities('spf');
Mail::SpamAssassin::Logger::add(method => 'file', filename => '/var/log/spammy');
This indicated immediately that it was a problem with the header that holds the Return-Path address.
I'm quite surprised that there's apparently no way to achieve the above within any configuration file, since being able to generate a debug log is so useful, especially considering that SpamAssassin is 99% of the way there. In theory, it should be possible to create a simple plugin (Mail::SpamAssassin::DebugLogging) that reads configuration lines to achieve the above without having to rummage in Perl.
With that said, the first line appears redundant (I thought it was necessary as nothing seemed to get logged, but then I was getting logs from all facilities). In which case, the module would want to start with "noall" I suppose.
I decided to simply alter the Perl module to log directly:
Mail::SpamAssassin::Logger::add_facilities('spf');
Mail::SpamAssassin::Logger::add(method => 'file', filename => '/var/log/spammy');
This indicated immediately that it was a problem with the header that holds the Return-Path address.
I'm quite surprised that there's apparently no way to achieve the above within any configuration file, since being able to generate a debug log is so useful, especially considering that SpamAssassin is 99% of the way there. In theory, it should be possible to create a simple plugin (Mail::SpamAssassin::DebugLogging) that reads configuration lines to achieve the above without having to rummage in Perl.
With that said, the first line appears redundant (I thought it was necessary as nothing seemed to get logged, but then I was getting logs from all facilities). In which case, the module would want to start with "noall" I suppose.