[Mimedefang] An odd problem (for an odd configuration)

[Rajesh Bhandari]

>>> thorn at cc.mcgill.ca 09/08/03 01:12PM >>>
>	We have a mailhost layer of three machines (DNS
>        round-robinned), that run Trend AV and sendmail 8.12.9 in a
>	sandwich configuration. Mail is scanned and handed off to the
>	mailhub layer for delivery.
>
>	The mailhub layer consists of two machine (sendmail 8.12.9)
>	also dns round-robinned. They send mail off to where it is
> <snip>
>
>
>	Unfortunately when it is working mail get s to the mailhub
>	layer and is discarded if it meets the criteria for discard,
>	unfortunate;ly during this time the following messages
>	are building up in the mailhost layer log files:
>
>	   Sep  8 11:20:35 prion sendmail[18135]: [ID 801593
>mail.info] h88ExBH2016783: to=<andrew.hendry at mcgill.ca>,
>delay=00:21:24, xdelay=00:00:00, mailer=relay, pri=120482,
>relay=localhost, dsn=4.0.0, stat=Deferred: Connection reset by
>localhost

Hi r

FYI - I run a TrendMicro sendmail-sandwich as well, but all on the same box.  I run two instances of MD, one hooked into the first Sendmail, and the other hooked into the second Sendmail. I drop attachments in the first MD, and do spam checking in the second MD. I load balance across multiple such machines using a Foundry load balancer.  This infrastructure works like a charm.

If I understand your e-mail correctly, you are scanning and dropping viruses on the first (mailhost) layer, and discarding notification messages on the second (mailhub) layer.  The messages with the 'Deferred ....' are appearing on the first (mailhost) layer.  

Seeing the 'localhost' delivery suggests that this is the first part of the sandwich, and delivery is being attempted through the TrendMicro VirusWall to the second sendmail.  I have seen similar messages before, and it turned out to be a timeout issue between the VirusWall software and Sendmail.  Essentially, if the spam/virus messages had lots of addresses in the mail header, Sendmail would take so long to canonicalise the senders that the VirusWall software would time out.

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
----

Rajesh