Recently I moved my spam filter server to a virtual host and ever since
then approximately 70% of the incoming messages get spam tagged because
of being unable to resolve the mx record.

To make matters more complicated this site is utilizing a satellite
connection and even with a local dns server, name resolution takes much
longer than other sites. for example in a nslookup, for a mx record
that isn't cached I need to set the timeout to 8 seconds before it will
resolve without timing out.

I have used a packet anaylzer and I can not see where spamfilter is
making this resolution query, so I am unable to find out if the DNS
server is sending back a failure, or if the product is failing on its
own.

So all that said... my question is: How can I troubleshoot this issue
and is there a way to increase the timeout for MX record resolution.

The Socket Error # 10054 is a Windows Socket error, and usually
indicates that the remote host has focibly disconnected SpamFilter. The
reference page is at http://msdn.microsoft.com/library/default.asp?url=/library/e n-us/winsock/winsock/windows_sockets_error_codes_2.asp

In short, the error is described as:
WSAECONNRESET 10054

Connection reset by peer.
An existing connection was forcibly closed by the
remote host. This normally results if the peer application on the
remote host is suddenly stopped, the host is rebooted, the host or
remote network interface is disabled, or the remote host uses a hard
close (see setsockopt for more information on the SO_LINGER option on
the remote socket). This error may also result if a connection was
broken due to keep-alive activity detecting a failure while one or more
operations are in progress. Operations that were in progress fail with
WSAENETRESET. Subsequent operations fail with WSAECONNRESET.

While I do not believe the error you are receiving is a dns timeout
issue, the only way to be sure is... to increase the timeout and see if
that helps. The bad news is that SpamFilter has a fixed timeout of 5000
milliseconds that it uses for all DNS queries... The good news is that
we just uploaded in the registered user area a new build (2.6.3.493)
that will allow you to modify the DNS timeout by specifying the
new value in the SpamFilter.ini by using the DNSTimeout option.

The release note for this new build are:

// New to VersionNumber = '2.6.3.493';
{TODO -cNew : Added DNSTimeout option in SpamFilter.ini to customize the DNS timeout for all of SpamFilter's DNS queries}
{TODO -cNew : Added EnableDbgLogs SpamFilter.ini option to enable separate detailed logging for troubleshooting purposes}
{TODO -cNew : Added to SpamFilter.ini several of the optional entries with their default values for users to see}
{TODO -cFix : Clicking on "Check if IP in ORBS" button in GUI could result in Access Violations being logged}

Given that you are not confident that it is really a DNS Timeout issue,
and that this is running inside a VMWare guest, have you had any
experience with their Network Card driver causing this type of issue?
Since the log times between query and error are more on the order of 4
milliseconds apart, my timeout theory maybe off the mark abit..

We have several users who deploy SpamFilter under VMWare, and we use
the product ourself for testing, and fully support the environment.

So far we the only issue we heard of with VMWare are ARP requests with
invalid MAC addresses being sent from a guest. This will cause however
noticeable TCP errors warning of duplicate IPs onthe network, both on
the actual Windows screen and in the Windows system logs. If you're not
having these symptoms, and the server is able to access the network
without problem, I would not think VMWare to be a problem.

If you can please zip us to support at logsat.com a copy of your
SpamFilter activity logfiles we'll try to debug them to see what the
problem is.

I apologize for the delay in responding to your request for my log
files. Last night I sent in a zip of my log files. Please let me know
if you need anything else. If for some reason you did not get it,
please let me know.

I believe that rather
than trying to troubleshoot "why" the VMWare machine is causing the TCP Socket
Error, we may solve this faster by modifying SpamFilter to behave differently if
that error occurs and assume it is a DNS timeout. This will cause the MX test
*not* to fail, as if there are DNS timeouts SpamFilter will not be able to tell
if the test passes or fails, and thus is forced to pass it to avoid false
positives. We'll need a day or two to make the changes and test them, after
which we'll make the new build available on the website. If we have an alpha
build sooner and you're willing to test it, we'll be happy to provide it to
you.

Just incase anyone else runs into this issue. It was resolved by
updating the DNS entry in SpamFilter to point to a valid DNS server.
The socket closed error was because the DNS server I was pointing to no
longer existed.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot delete your posts in this forumYou cannot edit your posts in this forumYou cannot create polls in this forumYou cannot vote in polls in this forum