record type: PTR, protocol: UDP. Server response: DNS server or domain failure (SERVFAIL, RCODE 2). RSS Back to forum
@jerminate:
The typical reason for SERVFAIL DNS responses is that the authoritative DNS name server for the zone being looked up is down or otherwise non-responsive. There is practically nothing you can do about these, because these are servers belong to other organizations. However, if you receive these SERVFAIL messages for practically all non-whitelisted emails with varied ORF tests, it may be a problem with your DNS server.
It may also appear that the above message causes the email to be delivered, but actually that is not the case. The error handling policy of ORF for blacklists tests is to skip the smallest possible part of a test when an error is encountered and continue with the next test. DNS errors in particular are expected and like all errors, they will be treated this way.
In any case, I recommend reviewing our best practices guide for improving spam filtering performance and DNS configuration: http://vamsoft.com/support/docs/how-tos/best-practices-5.0.
Please let me know if you have any questions.
@Péter Karsai (Vamsoft): I am not receiving these SERVFAIL messages for practically all non-whitelisted email, but I am getting several (10-15) an hour, and the messages do indeed invariably PASS after I receive this message. Users reporting 15+ spams a day alerted me to this issue, and when I check the logs I see the SERVFAIL message, and then immediately after that in the logs is a PASS message where ORF lets it through. These are obvious spam messages - I cut down on them a bit by blocking *@*.in, but they are for things like Cheap Mortgages and the like. I believe this issue began when I upgraded to ORF 5, and our spam detection rates have gone from 91% to 78%.
@Péter Karsai (Vamsoft):
Also, I sometimes get this message, and the spam email passes checks right after as well:
Error checking the SPF policy of domain "netnewsnetworks.net": SPF policy syntax error. Source "netnewsnetworks.net", message "Multiple SPF declarations were found with the same version." at character -1.
Basically, if I look at the logs, any event with Warning severity is immediately followed by a Spam message being delivered, and like I said, there are several warnings an hour.
@jeremy.ward: I am afraid I cannot tell if 10 to 15 is too many or too little without knowing more about your email traffic. Can you please send a few recent ORF log files to for analysis? These can be found in the configured ORF Text Log directory (\Program Files (x86)\ORF Fusion by default) and look like "orf-yyyy-mm-dd.log". In case the log files exceed a few megabytes in size, please use ZIP.
@jeremy.ward:
Well, the warning message is correct, netnewsnetworks.net does have multiple SPF policies, which is considered an SPF error by the SPF standards, but I guess that is not the point.
However, it is not entirely surprising the SPF warnings are usually followed by the email passing through, because it is among the last email tests, so if nothing have caught the email before, there is little chance the rest of the tests will.
Once we receive your logs, we can look for specific error patterns or configuration issues that could explain the poor performance, so please make sure to send these to us.
@jeremy.ward:
The same thing has been happening to me for the past few weeks. It almost seems as if the email is compromising ORF and allowing the email through. Here is one that came through last night. I get about 10 of these per day and all are passed through by ORF. Naturally, I have masked the email address and domain, but in the actual log they are not. Also, which I find very curious is that, I do not have a SURBL: UB-Black in my tests. I only have the original ORF ones from the release.
-------------------------------------------------------------------------------
-- EVENT SUMMARY --
Time: 11/18/2012 3:06:21 AM GMT-0500 Eastern Standard Time
Sender Email:
Recipient Email:
Related IP: 98.138.91.97
Action: (not available)
Email Subject: FOR Alan
-- EVENT MESSAGE --
DNS error. Test: "SURBL: UB-BLACK", server: "10.40.3.10", domain: "SANgeD.cOM.black.uribl.com", record type: A, protocol: UDP. Server response: DNS server or domain failure (SERVFAIL, RCODE 2).
-- EVENT DETAILS --
Filtering Point: On Arrival
Event Class: System Message
Severity: Warning
Server: Exserver.mydomain.net
Event Source: MSEXCHANGE
HELO Domain: (not available)
Message ID: (not available)
Log Mode: Verbose
ORF Version: 5.0 REGISTERED
-------------------------------------------------------------------------------
@Péter Karsai (Vamsoft): I'm sorry Peter, I replied to Jeremy and not you. There is a post in this forum for you.
I am having the same issue on both SPF and DNS lookups. I have checked my DNS setting and everything is good. What I would like to know is why is the message still being delivered if there is a problem with the test being performed? Is there anyway to block a message if the DNS lookup fails?
Thank you for your help.
@jeremy.ward:
Thank you. After analyzing the logs, I have found that these SERVFAIL warnings are mostly caused by spam from certain Romanian and Kazakhstani IP blocks, where the reverse DNS resolution fails with timeout. This is a configuration problem with the email source network and not with your ORF or DNS setup -- these appear to be fine. Please consider that some DNS lookups will always fail, as the Internet DNS infrastructure is subject to hardware failures, configuration issues and such.
Also, I have found at least one instance when the email was blacklisted after a SERVFAIL on the Reverse DNS Test by a DNS Blacklist (206.214.67.<redacted>), which means the error handling policy of ORF works as I have outlined earlier. For blacklists tests, errors are contained and handled at several levels. The largest units of containment are email tests, which means ORF may not skip more than the affected test due to an error. However, DNS lookup errors in particular are expected in ORF, so this is addressed in smaller units. For instance, if a DNS lookup times out, ORF will try to recover by repeating the DNS lookup with the other available DNS servers. If this does not help, the lookup is considered failed. The RDNS test in particular consists of two subtests (sending IP validation, sender domain validation, performed in this order) and a failed sending IP validation will not even affect the sender domain validation - that subtest will be carried out.
As for the original question "How can I stop these from getting through?", I recommend relying on the automatic measures of ORF. As these did not catch the email in this particular case, but the list of offending IPs is rather short, you may want to ban them from the server using the IP Whitelist. Alternatively, if you do not expect emails from Romania or Kazakhstan, you can try our Geo Blacklist Generator at http://vamsoft.com/support/tools/geo-blacklist-generator.
@SKM_Admin: Please refer to my response to Jeremy--emails are definitely not getting "passed" status on (blacklist test) DNS lookups errors, even if that is the appearance. Please consider that SPF is among the lasts tests performed by ORF, so if the email was not stopped before that tests, it is less likely that the rest few will stop it.
@Péter Karsai (Vamsoft):
Thanks Peter. Where does this entry come from? This is where my DNS is failing.
DNS error. Test: "SURBL: UB-BLACK", server:
I don't have a UB-Black surbl.
Thanks Krisztian. However, I'm still getting all these crazy porn emails and I have almost every country blocked. I really don't know what to do at this point. May I send you one of them so perhaps I can get a regex to block them?
@bjanow:
A reliable DNS server is essential if ORF is to function properly. You could try adding manual expressions to block different type of spam, but that is an endless battle and requires you to continuously monitor new spam variants and check blacklisted emails for false positives, etc.
Instead, we suggest using a DNS server for the lookups which meets the requirements (http://vamsoft.com/support/docs/how-tos/best-practices-5.0#bp-get-dns-right) and can query online DNS Blacklists and SURBLs in real time automatically without issues (such as SERVFAIL, RCODE2 errors, which are usually caused by public forwarders).
@Krisztián Fekete (Vamsoft): I made some config changes in ORF and it seems to be helpful. I actually removed the uribl surbl from the checklist since it was always timing out. I did the blacklist from outside the country and that also helped a little. Some are getting keyword blocked but the fact remains that some are still getting past the greylisting and countries.nerd. They must have a huge amount of compromised machines around the world since some resend almost immediately unlike other types of spam. Never ending battle ...
@bjanow: Do you have all recommended DNS Blacklists and SURBLs enabled (http://vamsoft.com/support/docs/knowledge-base/recommended-dnsbls-surbls-agents)? For example, the Spamhaus DBL SURBL is extremely effective, yet most people do not have it enabled according to the anonymous statistics we receive. As you can see, it did not even make it to the top 5: http://vamsoft.com/support/tools/spam-statistics
@Krisztián Fekete (Vamsoft):
Those are the exact ones I had and now along with the countries-nerd I'm catching almost all of them. But once again, they have some very good attack methods. The latest batch came from italy and were blocked by nerd. Here are some of the subject lines that are getting through.
G \ra/nn ,y S+e .x,
A ,DU ~L"T / V,I:D. E .0^S!
M"I L _F#S " P{ORN .
Greylisting does nothing as they are resent within seconds.
@bjanow: You can try blacklisting these subject lines specifically using the Keyword Blacklist of ORF, but it's an uphill struggle. In general, we recommend using the automated tests in ORF to fight spam (see http://vamsoft.com/support/docs/how-tos/best-practices-5.0 for our best practices) as opposed to using the manual lists. This should give you at least 98% spam catch rate, which means 2 out of 100 spam may still get through.
@Péter Karsai (Vamsoft):
They are still coming through fast and furious. Analyzing the email it comes from yahoo, google or hotmail which make the countries.nerd useless. Does anyone have a keyword filter that will help with the above. Here are 2 more from just this morning:
SE {X M 0V I,ES*
P._)s ,s&Y
It's out of control. Only a url in the body of the message. I get at least 2/ day.
@bjanow:
please send us your current configuration file called orfent.ini, a few samples in EML format including the _original_ headers (or the headers as separate TXT files with the same filename as the related EML file, see http://spamcop.net/fom-serve/cache/19.html for instructions), and the related .log files to .
I will look into this.
@Krisztián Fekete (Vamsoft): Sent. I had 2 emails that I hadn't deleted and send the headers along with the requested file.
I get tons of these Servfail, Rcode 2 dns errors daily. They are invariably spam, thankfully most of these emails get caught in other tests. However, a significant portion of them squeak by because these DNS tests don't succeed. I'm assuming the authoritative dns servers for the related ips are purposely slowed or disabled for spamming purposes. It would be fantastic to give us options for what we can do when dns tests fail like a 4.7.1 error until the DNS check succeeds or something. This is probably how most spam enters my email server.
Thanks for a great product overall.
@Graham CB:
the number of reports we receive from customers of SERVFAIL, RCODE2 errors logged for Spamhaus lookups is on the rise, I guess this might be related to the DDOS attacks they were under in Spring 2013. They started using Cloudflare back then (http://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho), we do not know if the SERVFAIL, RCODE2 messages are the result of their new mitigation/load balancing process, or what happens exactly... Only they could tell.
If you see SERVFAIL, RCODE2 errors for lookups other than Spamhaus/SPF/Reverse DNS lookups, it might be caused by a problem with your local DNS server, see http://vamsoft.com/forum/topic/100/spamhaus-win-2008-dns-server#comment-2 for possible solutions.
Temporary rejecting the email if a DNS lookup fails would be problematic for several reasons: a non-responsive blacklist service could hold up emails indefinitely, the senders would give up delivery eventually and the false positive rate would be unacceptably high, not to mention the excessive traffic this would generate.
@Krisztián Fekete (Vamsoft):
Thanks for your response Krisztian. I was suffering from that Spamhaus issue and have had them disabled for some time now. The DNS lookup fails I'm getting now look to be RDNS/PTR and are a minority through my day, so I feel my DNS server is working fine. In my opinion, this seems to be some tactic spammers are using to disable/ddos/or maybe they are running their own DNS servers and purposefully mis-configuring them. Of these DNS error emails, most get caught in other checks performed, but there's still a number that make it through all checks successfully.
I've alleviated much of this problem by implementing a custom countries-nerd blacklist that excludes most of the globe, followed up by using ip blacklists for organizations that pull these shenanigans. I know the IP blacklists aren't a great idea, but I had to stop these somehow. An example of a recent abuser that I've black listed all related subnets is an organization called Eonix. http://whois.arin.net/rest/org/EONIX/nets
example related spam domain: quickaccesstogreatinfo.biz
Before I blacklisted them, I would get lots of emails from them and all would do the Servfail error. It looks like their ips get listed on blacklists frequently, but not all of their IPs all the time.
As for my example solution of doing a temporary reject, that was just me throwing out ideas, I have no idea what would work best. I'm just trying to help improve an already great ORF. It just seems like something is happening to DNS servers associated with incoming spam IPs /domains so we can't reliably get reverse/forward/spf records. This seems to be a very consistent indicator that the email coming in is most likely going to be spam.
As an example, an email that just got through that performed this trick resulted in the following:
From mxtoolbox.com:
ptr:23.89.253.164 Error
Loop detected! We were referred back to '199.231.208.3'
smtp diag blacklist port scan subnet tool
Reported by mxtoolbox.com on 10/3/2013 at 10:27:51 AM,
sender:
related ip: 23.89.253.164
This seems to be an problem initiated by the host itself (Enzu)
http://whois.arin.net/rest/net/NET-199-231-208-0-1/pft
If using Windows 2008R2 DNS Servers this is worth a try: http://support.microsoft.com/kb/2508835/en
HTH
Norbert
@NorbertFe:
We use Windows Server DNS on the Mail Edge/ORF server as our DNS query resolver. We had seen that occasionally it would lock up and stop working for certain domains. (The details are foggy now but it had something to do with long Time To Live on some top level domains like .co.uk or .fr). This caused outbound messages to be stuck in the exchange queue.
We implemented a script we run as a scheduled task that counts messages in the exchange outbound queue, alerts us if the count exceeds a threshold and resets the DNSCache just in case. This has helped us a lot.
I am getting a lot of warnings in the log like this:
DNS error. Test: "RDNS/PTR", server: "192.168.1.4", domain: "213.109.179.151", record type: PTR, protocol: UDP. Server response: DNS server or domain failure (SERVFAIL, RCODE 2).
and then the email that generated the warning goes on to pass checks and be delivered, and it is invariably spam. How can I stop these from getting through?