Build 8594: Spamcheck with RBL/URIBL needs more than 10 Minutes / Mail

Problem reported by Roger - 7/19/2023 at 6:54 AM

Submitted

Hello together

In the latest version incoming mails sometimes need 10 minutes to be checked by the individual spam filters with RBL and URIBL. I even had single mails that needed more than 21 minutes. In previous versions these checks were done within 2 minutes.

From my point of view, all spam checks that take longer than 1-2 minutes are simply not reasonable for customers.

So there must be something wrong here and I hope you find the problem and solve it as soon as possible.

Thanks and greetings

11 Replies

Reply to Thread

Brian Bjerring-Jensen Replied

7/19/2023 at 7:38 AM

We found that its related to DNS and responsetimes from the individual vendors and lists.

kevind Replied

7/19/2023 at 8:26 AM

@Roger, looks like this issue will be fixed in the build coming out later this week.

See this thread for more details:

https://portal.smartertools.com/community/a95419/issue-with-8552-8559-8566-after-update-to-this-releases-uribls-cause-big-delay-mail.aspx

Roger Replied

7/19/2023 at 9:01 AM

the custom build does not solve the problem. I am testing it, same issue

Brian Bjerring-Jensen Replied

7/19/2023 at 10:33 AM

7hrs for one mail in the spool

Kayasidh Kasyapanun Replied

7/24/2023 at 9:55 PM

I'm running build 8601 and still facing extremely slow Spam Check.

Tim Uzzanti Replied

7/25/2023 at 10:49 AM

Employee Post

Brian,

The 11 attempts means it failed to send to a recipient. It doesn't have anything to do with spam checks. Please check your settings for frequencies and number of attempts and change as you see fit. For example, here is ours.

Tim Uzzanti

CEO

SmarterTools Inc.

(877) 357-6278

www.smartertools.com

Roger Replied

7/25/2023 at 11:21 AM

[2023.07.25] 20:16:26.080 [TXT]:default._bimi. | Time: 9998, Exception: Query 50262 => default._bimi. IN TXT on 8.8.4.4:53 timed out or is a transient error.
[2023.07.25] Stack:    bei DnsClient.LookupClient.<ResolveQueryAsync>d__103.MoveNext()
[2023.07.25] --- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
[2023.07.25]    bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
[2023.07.25]    bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
[2023.07.25]    bei DnsClient.LookupClient.<QueryInternalAsync>d__101.MoveNext()
[2023.07.25] --- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
[2023.07.25]    bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
[2023.07.25]    bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
[2023.07.25]    bei SmarterMail.Common.DNS.DnsManager.<DnsClientQuery>d__24.MoveNext()
[2023.07.25] --- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
[2023.07.25]    bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
[2023.07.25]    bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
[2023.07.25]    bei SmarterMail.Common.DNS.DnsClientProxy.DnsClientTXTLookup.<Lookup>d__0.MoveNext()
[2023.07.25] Inner Exception: System.OperationCanceledException: Der Vorgang wurde abgebrochen.
[2023.07.25]    bei System.Threading.CancellationToken.ThrowOperationCanceledException()
[2023.07.25]    bei System.Threading.ManualResetEventSlim.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
[2023.07.25]    bei System.Threading.Tasks.Task.SpinThenBlockingWait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
[2023.07.25]    bei System.Threading.Tasks.Task.InternalWait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
[2023.07.25]    bei System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken)
[2023.07.25]    bei DnsClient.DnsUdpMessageHandler.<QueryAsync>d__11.MoveNext()
[2023.07.25] --- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
[2023.07.25]    bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
[2023.07.25]    bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
[2023.07.25]    bei System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
[2023.07.25]    bei System.Threading.Tasks.TaskExtensions.<WithCancellation>d__0`1.MoveNext()
[2023.07.25] --- Ende der Stapelüberwachung vom vorhergehenden Ort, an dem die Ausnahme ausgelöst wurde ---
[2023.07.25]    bei System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
[2023.07.25]    bei System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
[2023.07.25]    bei DnsClient.LookupClient.<ResolveQueryAsync>d__103.MoveNext()

Brian Bjerring-Jensen Replied

7/25/2023 at 11:44 AM

What shall I change Tim??

Tim Uzzanti Replied

7/25/2023 at 1:06 PM

Employee Post

Brian,

This is unrelated to the RBL and DNS conversations.

In your case, this is normal mail delivery and there is nothing to change. SmarterMail is attempting to send a message to a recipient based on the number and frequencies you have configured. Mail attempts span large timeframes because mail servers can go down for extended periods or DNS or MX changes can take time to propagate through the internet.

Tim Uzzanti

CEO

SmarterTools Inc.

(877) 357-6278

www.smartertools.com

Roger Replied

7/26/2023 at 10:04 AM

i still have timeouts now and then according to SmarterMail logs 80085. when i check this locally on the server with nslookup it works super fast and flawless.

Also I have now used all possible known nameservers like 9.9.9.9, 8.8.8.8, 8.8.4.4, 1.1.1.1, 1.0.0.1 etc. and with all of them this error occurs.

On the server I have also uninstalled the GlassWire tool which means it can no longer have any influence. But the problem remains sporadically.

Here is an extract of a few such errors according to the log

[2023.07.26] 18:05:50.511 [A]:w3.org.uribl.swinog.ch | Time: 10001, Exception: Query 1316 => w3.org.uribl.swinog.ch IN A on 8.8.4.4:53 timed out or is a transient error.

[2023.07.26] 18:05:50.714 [A]:www.cg24.com.in.dnsbl.org | Time: 10001, Exception: Query 38995 => www.cg24.com.in.dnsbl.org IN A on 8.8.8.8:53 timed out or is a transient error.

[2023.07.26] 18:06:00.527 [A]:www.cg24.com.in.dnsbl.org | Time: 10015, Exception: Query 48107 => www.cg24.com.in.dnsbl.org IN A on 8.8.4.4:53 timed out or is a transient error.

[2023.07.26] 18:06:00.730 [A]:cg24.com.in.dnsbl.org | Time: 10015, Exception: Query 56783 => cg24.com.in.dnsbl.org IN A on 8.8.8.8:53 timed out or is a transient error.

[2023.07.26] 18:13:11.493 [TXT]:mail49.suw11.mcdlv.net | Time: 19999, Exception: Query 63461 => mail49.suw11.mcdlv.net IN TXT on 8.8.4.4:53 timed out or is a transient error.

Tim Uzzanti Replied

7/26/2023 at 11:54 AM

Employee Post

Roger,

DNS is built on the UDP protocol. UDP is "fire and forget", which makes it inherently unreliable. When you make a UDP request, there is no constant connection or session to the server you made the request to. The reason for that is, a server can't have a million connections sitting idle because DNS requests can take awhile. In addition, DNS requests often require that the initial DNS server you are accessing to make another request to yet another DNS server for the latest information. The speed with which a result gets back to your server make things very unpredictable. However, that is how DNS is architected. For this reason, a good application like SmarterMail realizes that and will make multiple attempts if we get a failure and why we will try the backup DNS servers that you configured. What you see in your logs is normal, especially for the one request that failed a few times.

With regards to RBL and URIBL servers (which is not what you're referencing), these DNS servers hold data a different way so that it can be used for SPAM checks. These RBL and URIBL servers often are under heavy load and get overwhelmed with requests. They can take a long time to return results which isn't great because it can slow down your spool. So, we have timeouts based on these requests which are a bit different from more important requests like MX or Reverse DNS, etc. We also don't do follow-up checks to RBLs and URIBLs in an effort to not stall your spool.

The issues with our DNS requests for RBLs and URIBLs were resolved. We left some code in that delayed some results but now everyone is questioning ALL results, and its getting kind of messy. We know things are in a solid place and things are working as normal now.

When we looked at your server, the GlassWire tool was definitely closing and not accepting good connections to and from your server which made things sketchy! I'm glad you removed that, not sure if there were settings to adjust in that tool to make it work better but it was a cause of problems for you.

If you have additional requests or concerns, please work with support. But what you showed is normal and the more work your server does, the more you're going to see that. Hope all this helps.

Tim Uzzanti

CEO

SmarterTools Inc.

(877) 357-6278

www.smartertools.com

Back to Community Threads

Please leave this box unchecked

11 Replies

Reply to Thread

Tags

Related Knowledge Base Articles