ES 10.0.6 Fails To Identify SPF Record (SPF Not Found)
Halon5
Enthusiast ✭✭
Hiyas,
Has anyone seen this? Message Logs - "SPF Not Found" (MxToolbox "Analyze Headers" checks out with full readout).
Looks like we have this occurring in some specific situations (not good when a bank has specified -all or HARD FAIL) and we cant even see it to test it.
---Steph
Category: Email Security Appliances
0
Comments
@Halon5 ,
Can you please verify if the option"Enable SPF validation for incoming messages" is enabled under Manage>Anti-spoofing" inbound page?
Also, would request you to contact support for more details
Nevyaditha P
Technical Support Advisor, Premier Services
Hi Nevyaditha,
Thanks for following through here. Yes, enabled. I am interested to know if there are any others here seeing such behavior.
I am seeing mail (including from SonicWALL but not in all cases - there is a pattern that can be seen by SW sender ) that fails the SPF lookup (No SPF Record) and I am trying to get to the bottom of it.
I have already opened a case 43428904 and it is with Gailand (who is awesome) but I want to try and understand if its just my appliance or if others may be seeing this for 10.0.6
Kindly, Steph.
Hi @Halon5
do you mean the "No SPF Record" entries in the message log?
Despite the fact that there is a SPF record?
sonicwall.com. 3599 IN TXT "v=spf1 include:_spf.corp.sonicwall.com include:_spf.salesforce.sonicwall.com include:_spf.eloqua.sonicwall.com include:_spf.aws.sonicwall.com include:gh-mail.sonicwall.com include:spf.protection.outlook.com -all"
--Michael@BWC
Hi @BWC ,
yep. that's exactly what I mean. I had just furnished a similar example to @Nevyaditha . ie. from SonicWALL
** Thanks for YOUR sample! ** I guess that's CONFIRMED.
This needs to be fixed FAST.
Best & Regards --Steph
P.S. Do i get a trophy cup thingy for my discovery? LOL.
@Halon5 ,
I am on it and will provide an update as soon as possible.
Nevyaditha P
Technical Support Advisor, Premier Services
Hi @Nevyaditha ,
This stuff should be reported properly.
-S.
@Halon5 ,
I apologize for the delay in responding back to you on this.
I am closely monitoring the Case 43428904 and checking with SME from Email Security for the reason behind the issue.
I did get below information to investigate about the issue:
-We need to check if Email Security queries the same DNS server as set in the UI.
-We must check messages and check it’s contacting IP and query there DNS server for the response.
Also, there are some instances where attachment scanning by Capture could play a role in the result since there are 2 passes in the plugin chain when Capture is used.
I would request you to update the information requested in the case as this needs real-time investigation. I will keep you posted on the thread.
Thanks for your patience.
Regards,
Nevyaditha P
Technical Support Advisor, Premier Services
Hi @Nevyaditha ,
Spent the afternoon on this with Gailand in (he is always awesome). Lots of traces and Wireshark diags.
We both ran out of juice but we can clearly see from Wireshark that for certain DNS requests nothing is received (empty).
Convinced that it was an ISP(DNS) issue the DNS server was moved to Google.. (SAME RESULT).
We see a clear pattern (audit log illustrates) where for the same domain only certain source IP addresses have this issue but they are consistent. Some "SPF Pass" but others "No SPF Record".
My probably somewhat naive questions are :-
What module is making the request? Is it up to date? How does it ask?
We see good results from NSLOOKUP every time.
Bottom line. We need SPF, DKIM, DMARC to be totally reliable.
Lets see what happens today. I am running up a trial VM so we have a sandbox to play in.
--Steph.
@Halon5 Hi, This issue really needs to be tracked and documented in the case.
There wouldn't be any specific details that would be suitable for here at this time.
I will work with Gailand and see if we can get more specific information for you on the case.
Thanks
David Wilbur
Technical Support Senior Advisor, Premier Services , SME Email Security
Well we have already seen that this is happening elsewhere through the post from @BWC .
That is the value that this forum provides.
I also have this problem, I believe it's a bug in Email Security.
When a domain has many or long TXT records the UDP DNS reply could grow larger than the default 512 bytes originally set in the DNS standard. The resolving client can work around this by either using EDNS to indicate to the server that it can handle UDP responses larger than 512 bytes, or fallback to TCP after it receives an empty response from the server with the "truncated" flag set.
Email Security doesn't do either when it handles incoming mail. But it actually does fallback to TCP when using the system diagnostics page's SPF query test.
Gailand has this information and is advancing this on their end. Hopefully we'll get a fix soon.
Thanks @SonicAdmin80 ,
Your post is clearly and absolutely correct and is in line with what @BWC and I have also seen.
I think this will help to "put to bed" the "your DNS may be broken" line of questioning.
I completely agree:-
ES is incapable of handling an extended response. So the response appears to be VOID.
This is not a case for an RFE as has been suggested to me. ES is failing to do the job it is expected to do which is to handle SPF, DKIM and DMARC correctly. It is Email Security basics 101 in my mind at least. It requires TOP PRIORITY work. Which would no doubt be better than wasting time on TOC which only successfully broke DKIM.
And yes, like you, I want it fixed so we can "get on with OUR jobs".
S.
@Halon5 Yes, packet capture clearly shows the DNS server responding with an empty response with truncated flag set but ES not reacting to it properly by sending another query over TCP.
Seems like a simple misconfiguration issue on the resolver used, like using the dig command with +ignore and +noedns options which I used to replicate the issue. Or a logic error where a null response with truncated flag doesn't cause another query to be sent.
Should be quite easy to fix I think either by enabling EDNS or reacting properly to the flag set in the response. Might even be possible to fix without a patch, but probably requires root access by support if the virtual appliance is used.
I wonder how long this problem has been in ES. At least a couple of months at least, perhaps even longer but it wasn't noticed until 10.0.6.
We have clients who are receiving spam / phishing mail from their own domains because SPF doesn't work.
We even have a specific filter rule to drop SPF Hard Fails.. Which doesn't work because SW ES cant even figure that out.
@Halon5 SPF checks are always done against the mail from header and not the from address itself.
Can you please open a new support case for the issue so a tech can review it with you.
There is a diag page option to return it to use the PRA instead of the mail from but that effectively disables the use of DKIM and DMARC.
As far as support for EDNS we are working on this and it would be covered some time after 10.0.9.
David Wilbur
Technical Support Senior Advisor, Premier Services , SME Email Security
@Halon5 Can you please open a new support case for the issue so a tech can review it with you.
Engineering always follow the RFC's according to how they are written.
David Wilbur
Technical Support Senior Advisor, Premier Services , SME Email Security
Hi all,
@David W : "SPF checks are always done against the mail from header and not the from address itself."
Hopefully we're not talking about the header, because SPF checks should be performed before the message (containg the headers) got transfered and checking is based on the SMTP envelope (HELO and MAIL FROM).
I had some off-forum exchanges with @Halon5 about this SPF dilemma, and it clearly shows that the system is doing DNS resolving just wrong by not honoring the TC-flag and switching from UDP to TCP (RFC 1123) when the response is larger than 512 bytes. We tested this over and over again with different resolvers and I was under the impression that this bug is confirmed to Steph and addressed for 10.0.8.
Is this not the case and no fixes are scheduled to get this right?
--Michael@BWC
I heard they are working on implementing EDNS but it might be pushed back to 10.0.9.
Well, with EDNS they can stick with UDP, maybe this does the trick 😉
@BWC Yes, we are talking about the SMTP envelope (HELO and MAIL FROM) as being how checks are performed.
EDNS was the original problem here not how the SPF checks were being done.
If EDNS is not supported, than an empty reply would be seen where it was used.
When we have long periods of time between releases I can understand how there may be some frustration with waiting.
When new things are added to the roadmap it can take some time for them to be added depending on where they fit in.
@Halon5 The case you mention is the same case we originally discussed here and any fixes related to that build are not available until it it posted. Some related issues may be resolved in 10.0.8 however EDNS will not be available until sometime later which is why you have had the issues you have seen. If you have some sort of new issue I would like to have you open a new case for it so it can be reviewed by a tech. If they find it is related to the original case then they can mark it as such or open a new engineering ticket should they find that it is something new. We do not want to mix issues together here and assume it is the same problem.
I appreciate the patience you have both had with this problem.
David Wilbur
Technical Support Senior Advisor, Premier Services , SME Email Security
@David W , @SonicAdmin80 , @BWC
Well the other part of this problem is that SPF checking is not done in the proper place.
SPF (Sender Policy Framework) has an IMPERATIVE in the form of " -all " .
Since SPF is no longer tested "Up Front" as it used to be many releases ago, it is rendered IMPOTENT by ES. (SPF i understand is now at the end of ES testing which is questionable).
We had added a FILTER RULE (the first) to try and fix this but the broken EDNS also makes this useless.
Indeed the ES dialog's around SPF Settings have no hope of being effective. ie. senderAuth_config.html
Curiously, the SPF policy query in the system diagnostics page works by falling back to TCP. So ES is capable of correct queries, they are just not implemented in the inbound MTA path.
SPF checks do not happen in the MTA that is done in the SMTP Proxy.
The MTA does not make any judgement on any aspect of a message.
David Wilbur
Technical Support Senior Advisor, Premier Services , SME Email Security
Has anyone tried the recent 10.0.9 yet? No mention of this issue in either resolved or known issues.
I'll take a pass, because they broke LDAP for me (Zimbra), until this gets fixed any update higher than 10.0.6 is useless for me :(
Is it downloadable in your account? I saw it in the notifications, but no download for my ESA 5000, still 10.0.8.
--Michael@BWC
@SonicAdmin80 the issue in this thread is not an included fix in 10.0.9
And if you use openLDAP I do not advise any upgrade until we release 10.0.10
David Wilbur
Technical Support Senior Advisor, Premier Services , SME Email Security
@BWC Yes I see it for virtual appliance and Windows. But since there isn't really anything that relevant in the fixes for me, I'll probably stick to the current version for now.
@SonicAdmin80 that's weird, double checked, no 10.0.9 for any ESA appliance or Windows, maybe it's the way how MSW shows me that I can't use it anyways :)
--Michael@BWC
We are still on 10.0.6 .. too scared to go to 10.0.9..
Still no action on 10.0.10 .. Hopefully they fix this EDNS issue on that release and SPF works properly.