Hi there
I'm the author of Qmail-Scanner - an Email scanning harness that can be used
to block attachments, scan for viruses, etc. It's hooked in as a replacement
for qmail-queue.
The installation of a rather slow virus scanner on my own systems had lead
me to realise a rare error condition I hadn't expected. This virus scanner
didn't like scanning a 90Mb zip'ped AVI file (ahem) - whereas another vendor
scanner took 1.5minutes to scan it, this one took nearly two hours...
The sending SMTP server's qmail-remote timed out the SMTP session after 20
minutes - as being in error - as it had waited "too long" for the final "OK".
However, STDOUT on the receiving box still received the "mail from|rcpt to"
envelope headers, so after 2 hours Qmail-Scanner happily delivered it back
to the real qmail-queue for real delivery.
However... back on the sending host, it tried to send it again...
I had a little loop going there - quite nasty. Can you say "busy system"? :-)
Anyhoo, the virus scanner is the real culprit here - and that's something
that can be fixed (i.e. get another). The problem is WHY did the recipient
qmail-smtpd send through the envelope headers via STDOUT to
qmail-queue/Qmail-Scanner? Upon noticing the sender going away, shouldn't it
have recognised that as an error condition?
I'm gonna have to alarm Qmail-Scanner so it also spits the dummy before 20
minutes (I hope other MTAs don't have shorter timeouts). That way it'll
always be telling the sender MTA it's in trouble.
Another solution would be to just accept the message before scanning it, and
scan it after the sending server has gone away - but then I'd have to write
an entire requeuing infrastructure to handle transient errors too (not
bl**dy likely ;-)
Oh yeah - and please don't say "limit the size" - we LIKE sending large
things here :-) [we just don't appear to like receiving them ;-)]
Am I missing something here? This seems to imply that if you had
/var/qmail/queue on a VERY slow (but otherwise reliable) disk, that you
would see this problem too. I hope I'm just been stupid and missed
something obvious...
--
Cheers
Jason Haar
Unix/Special Projects, Trimble NZ
Phone: +64 3 9635 377 Fax: +64 3 9635 417
