I've got a 10.0.10 private build which failed for some reason on my ESA 5000 and after that a 10.0.9.5627 for adressing the OpenLDAP issue (finally after 6+ months).
I can't tell if this build does cover any more enhancements but SPF is still a no no, showing No SPF Record for webex.com for example, which clearly has a SPF record (a large one) configured.
X-Mlf-SPF: No SPF Record (result=none;action=none;identity=MAILFROM;domain=webex.com;source=64.68.103.154;details:allowedlist=consider;)
Call Direction: Internal Status Update Caller/Contact Name: Stephan Gladiadis Product/Model: Product Version/Firmware: 10.0.6 Problem/Situation: ES Fails to identify SPF record RFE for EDNS Action/Analysis/Troubleshooting: We take all the customer reported enhancements and issues seriously. The EDNS Support enhancement is currently in development and engineering is actively working on it. It is definitely on our priority list. The scope of work is high and we have factored this into our next major release i.e. ES 10.1. ES 10.1 is targeted for release in second half of the year. Before any release, we test the release for all features on all platforms supported. Thus any release needs to take its due Dev and testing cycles. We appreciate our customers patience. Please stay assured that this has our attention and is being taken up with priority. If it helps, we can provide early beta builds to our customers for testing purpose. We will have more precise dates when the build moves from Development to Testing phase. Since this case is for a RFE we cannot keep this case open indefinitely and the fix is already setup for 10.1 once that comes out we will update our customers. Business Impact: unable to process on time SPF record Data Collected: none Plan/Next Steps: putting case in pending close do to the RFE has been approved and setup in the roadmap to 10.1.
@Halon5 there is not much left to say, I went from Disappointment via Anger straight to Frustration. I'am now in the State of Acceptance knowingly it'll get no better. It's time to let go.
This Issue should be fixed right away, but I guess the fear of breaking more stuff is just to big, considering the fact that even less drastic Updates caused huge trouble. Dev and testing cycle, OpenLDAP is all I can say here.
A lot of members in the Community raised concerns on various fronts and some of us got warned to be expelled for speaking out. But it does not seem to make any difference, so why bother.
It's great to see this on the Roadmap, but it's getting harder and harder to follow this map and maybe at the next Crossroads some will take a different turn.
Kind of critical feature for a spam filter so odd that it hasn't been implemented earlier. The first RFC for EDNS is from 1999 and the second from 2013.
Let's be generous and say that EDNS became critical only after RFC 7208 for SPF which came out in 2014. That's still 7 years to implement a feature which when missing breaks SPF evaluation.
Sorry guys. If a feature is not in a product it is an RFE.
I know some of you have the Product Managers contact and can contact him if you want but as far as support and the community goes this is not something we can further discuss here.
Trying to discuss it further here in the community would be pointless as I would give you the same answer.
David Wilbur
Technical Support Senior Advisor, Premier Services , SME Email Security
just to get this right, because I lost track a bit. Last year I did some digging about SPF problems and came to the conclusion that the DNS resolver part of the SonicWall Email Security Appliance isn't honoring DNS Messages bigger than 512 Bytes. According to RFC1035 Section 4.2.1, DNS Messages larger than 512 Bytes sent over UDP are truncated and the TC bit is set, which tells the Client to switch over to TCP to get the whole DNS Response.
EDNS is a another story, but IMHO not related to the initial problem?
Am I totally wrong on this, is the Appliance doing the DNS (over TCP) correctly and my findings are wrong? If my findings are correct, how could there be any reason to not fix it right away?
@BWC You are right that EDNS is not the same thing as DNS over TCP, but rather they are different solutions for overcoming the same problem.
RFC2181 (1997) also has clarifications to the TC bit functioning and later RFC5966 (2010). Email Security might be using some sort of stub resolver which doesn't support TCP mode or EDNS.
Email Security was acquired from MailFrontier in 2006 and the core seems to still be the at least partly the same as many of the CLI commands still have "Mlf" in the command name.
One would assume that the function for DNS queries would just be returning the result to another process and it would be easy to replace that function with an extended one. But perhaps there is some other hurdle. Maybe the function is wrapped in a larger function and they need to replace a larger portion of the code. Or some of the original source code is missing. Whatever it is it must be quite a big hurdle as this thread is almost a year old and who knows how long it has been there before that and known.
@BWC I'll let you be my beta tester. 🤣 They seem to break more things these days than they fix so I'm not very confident it actually works out of the box.
But at least with 10.0.11 the ES is sending DNS Queries with an OPT record. I'am still capturing DNS packets, maybe I can see larger UDP/TCP answers over time.
@BWC@Halon5 I'm also thinking about moving domains to CAS as it's much easier to manage and seems to be a bit better at catching new phishing messages. On-premise multi-tenant ES can be tricky and Microsoft keeps throttling the IPs intermittently.
Comments
Me too, still on 10.0.6. Hopefully not too long until there is a fix.
Hi guys,
I've got a 10.0.10 private build which failed for some reason on my ESA 5000 and after that a 10.0.9.5627 for adressing the OpenLDAP issue (finally after 6+ months).
I can't tell if this build does cover any more enhancements but SPF is still a no no, showing No SPF Record for webex.com for example, which clearly has a SPF record (a large one) configured.
X-Mlf-SPF: No SPF Record (result=none;action=none;identity=MAILFROM;domain=webex.com;source=64.68.103.154;details:allowedlist=consider;)
Hope for the best, but expect ....
--Michael@BWC
@SonicAdmin80 , @BWC ,
just another : Pending Close
Call Direction: Internal Status Update Caller/Contact Name: Stephan Gladiadis Product/Model: Product Version/Firmware: 10.0.6 Problem/Situation: ES Fails to identify SPF record RFE for EDNS Action/Analysis/Troubleshooting: We take all the customer reported enhancements and issues seriously. The EDNS Support enhancement is currently in development and engineering is actively working on it. It is definitely on our priority list. The scope of work is high and we have factored this into our next major release i.e. ES 10.1. ES 10.1 is targeted for release in second half of the year. Before any release, we test the release for all features on all platforms supported. Thus any release needs to take its due Dev and testing cycles. We appreciate our customers patience. Please stay assured that this has our attention and is being taken up with priority. If it helps, we can provide early beta builds to our customers for testing purpose. We will have more precise dates when the build moves from Development to Testing phase. Since this case is for a RFE we cannot keep this case open indefinitely and the fix is already setup for 10.1 once that comes out we will update our customers. Business Impact: unable to process on time SPF record Data Collected: none Plan/Next Steps: putting case in pending close do to the RFE has been approved and setup in the roadmap to 10.1.
So not fixed for over a year.... ?
@Halon5 there is not much left to say, I went from Disappointment via Anger straight to Frustration. I'am now in the State of Acceptance knowingly it'll get no better. It's time to let go.
This Issue should be fixed right away, but I guess the fear of breaking more stuff is just to big, considering the fact that even less drastic Updates caused huge trouble. Dev and testing cycle, OpenLDAP is all I can say here.
A lot of members in the Community raised concerns on various fronts and some of us got warned to be expelled for speaking out. But it does not seem to make any difference, so why bother.
It's great to see this on the Roadmap, but it's getting harder and harder to follow this map and maybe at the next Crossroads some will take a different turn.
--Michael@BWC
@BWC , @SonicAdmin80 ,
My ticket got closed * UNRESOLVED *. :(
Apparently that's OK because they are going to do something...? - Yeah Right.
Guys, Your cases were closed because we do not leave cases open for Feature enhancements.
EDNS has never been a part of the product thus it needs to be carefully assessed and tested.
David Wilbur
Technical Support Senior Advisor, Premier Services , SME Email Security
Kind of critical feature for a spam filter so odd that it hasn't been implemented earlier. The first RFC for EDNS is from 1999 and the second from 2013.
Let's be generous and say that EDNS became critical only after RFC 7208 for SPF which came out in 2014. That's still 7 years to implement a feature which when missing breaks SPF evaluation.
@David W , @SonicAdmin80 , Ditto. You cant pull the feature request card on us David, Sorry. Go directly to jail. do not collect $200.
Sorry guys. If a feature is not in a product it is an RFE.
I know some of you have the Product Managers contact and can contact him if you want but as far as support and the community goes this is not something we can further discuss here.
Trying to discuss it further here in the community would be pointless as I would give you the same answer.
David Wilbur
Technical Support Senior Advisor, Premier Services , SME Email Security
@David W , @SonicAdmin80
Nah. Can't pass GO on this one.
DNS lookups are not a feature. They are a requirement.
the RFE thing is just silly.
@David W , @Halon5 , @SonicAdmin80
just to get this right, because I lost track a bit. Last year I did some digging about SPF problems and came to the conclusion that the DNS resolver part of the SonicWall Email Security Appliance isn't honoring DNS Messages bigger than 512 Bytes. According to RFC1035 Section 4.2.1, DNS Messages larger than 512 Bytes sent over UDP are truncated and the TC bit is set, which tells the Client to switch over to TCP to get the whole DNS Response.
EDNS is a another story, but IMHO not related to the initial problem?
Am I totally wrong on this, is the Appliance doing the DNS (over TCP) correctly and my findings are wrong? If my findings are correct, how could there be any reason to not fix it right away?
--Michael@BWC
@BWC You are right that EDNS is not the same thing as DNS over TCP, but rather they are different solutions for overcoming the same problem.
RFC2181 (1997) also has clarifications to the TC bit functioning and later RFC5966 (2010). Email Security might be using some sort of stub resolver which doesn't support TCP mode or EDNS.
Email Security was acquired from MailFrontier in 2006 and the core seems to still be the at least partly the same as many of the CLI commands still have "Mlf" in the command name.
One would assume that the function for DNS queries would just be returning the result to another process and it would be easy to replace that function with an extended one. But perhaps there is some other hurdle. Maybe the function is wrapped in a larger function and they need to replace a larger portion of the code. Or some of the original source code is missing. Whatever it is it must be quite a big hurdle as this thread is almost a year old and who knows how long it has been there before that and known.
@SonicAdmin80, old components in a SNWL product,? Nah, that can't be right 🤣
I had my philosophis take on this last year, will pass on this one.
--Michael@BWC
@SonicAdmin80 @Halon5 downloading 10.0.11 right away, the one and only new Feature mentioned: "Support for EDNS".
Is there some light at the end of the Tunnel? It better be not a Train full of new bugs.
--Michael@BWC
@BWC I'll let you be my beta tester. 🤣 They seem to break more things these days than they fix so I'm not very confident it actually works out of the box.
@SonicAdmin80 I'am still struggling with some weird SPF results and trying to make some sense out of it, but sadly no response so far over her:
But at least with 10.0.11 the ES is sending DNS Queries with an OPT record. I'am still capturing DNS packets, maybe I can see larger UDP/TCP answers over time.
--Michael@BWC
@BWC @SonicAdmin80 ,
Would love to be able to chip in but we have moved our client base off and our licensing has run out.
They weren't interested in reactivating it for us to test and I don't want to pay for it right now anyway..
The ticket has been marked to close. (would have been nice if someone actually phoned us). Only took a year +.
Good luck i guess....
@BWC @Halon5 I'm also thinking about moving domains to CAS as it's much easier to manage and seems to be a bit better at catching new phishing messages. On-premise multi-tenant ES can be tricky and Microsoft keeps throttling the IPs intermittently.