[Mimedefang] Sendmail errors and caching DNS

[Rajesh Bhandari]

>>> lanz at pangea.Stanford.EDU 10/07/03 08:55PM >>>
>
>Hi Rajesh,
>
>Back in July you posted a response to the mailing list with the subject
>"[Mimedefang] dsn=4.0.0, stat=I/O error: I/O error" in which you wrote:
>
>> I think I've found the problem.  I run a caching DNS locally on the 
>> same box, and that seems to be having problems.  Taking it out of 
>> resolv.conf and using sendmail -v -qf seems to be clearing the queue 
>> nicely.
>
>We're seeing the same symptoms -- stat=I/O error from sendmail when our
>caching nameserver is running.  The errors stop occurring if I go back
>to the old remote-nameserver type of DNS.  Did you ever find out what 
>the problem was?  Is there a fix that will let us run our local, 
>caching-only DNS and sendmail both, without conflict?
>
>Thanks very much for any help you can offer.
>
>-- Kai

I did not find out what the problem was with the caching nameserver.  Or rather, I am not sure about the connection between the caching nameserver and the problem I -did- find.

Are you running the Interscan VirusWall sendmail-sandwich configuration?  If you are, this may apply.

The error appears in the first sendmail in the sandwich i.e. the one -before- the VirusWall.  Essentially, if the spam/virus messages had lots of addresses in the mail header (not envelope), Sendmail would take a really long time to canonicalise the senders, often more than the data_intval_time timeout used by the VirusWall software.  The VirusWall software would timeout and close the connection during the DATA phase of the SMTP conversation, and the result would be the 'stat=I/O error'.  

You can check the canonicalization using the -d8.2 debug switch with sendmail.

To solve the problem, I had to increase the timeout for the following in /etc/iscan/intscan.ini
----
# Send "NOOP" command to prevent original sendmail timeout when be receiving
# SMTP data part.
data_intval_time=600
-----

I changed these as well, just to be consistent, though I don't know if it made a difference.
----
# Client Timeout
cli_timeout=400

# Server Timeout: at least, this value should be longer than client timeout
srv_timeout=600
----

The problem is compounded by hoststat.  This is a list of hosts and their connectivity status maintained by sendmail.  You can see this using the hoststat command.  When one of the stat=I/O errors above occured, the host would be marked as having a problem.  All the other mail for that host would get queued behind the offending e-mail, and mail would quickly queue up.

I have not yet put the caching nameserver back on the sendmail/MD boxes.  I'll wait to see if you have any luck :-)

Rajesh