Hi there,
On Fri, 18 Oct 2019, Vladislav Kurz via clamav-users wrote:
On 17/10/2019 17:44, G.W. Haywood via clamav-users wrote:
There other ways of dealing with this, as I'm sure you're aware, but
using the patched daemon you only have to worry about the increased
memory consumption during databse reloads.
Well, the only option other than using your patch I know of is to
increase the AV scan timeout in SMTP server. But I'm afraid that the
sender might give up waiting for the final acknowlegement of DATA. ...
In my experience the only senders who give up early are the spammers,
and rather than at the SMTP 'DATA' stage it's usually at a fairly long
greetpause (I don't want to say how long that is in public). You will
probably not be surprised that I don't care about the spammers.
Here are some of the default Sendmail timeouts as distributed with the
latest Sendmail sources. I'm sure *many* installations are using them:
$ grep -C2 confTO_DATA sendmail-8.16.0.41/cf/README
confTO_RCPT Timeout.rcpt [1h] The timeout waiting for a response
to the RCPT command.
confTO_DATAINIT Timeout.datainit
[5m] The timeout waiting for a 354
response from the DATA command.
confTO_DATABLOCK Timeout.datablock
[1h] The timeout waiting for a block
during DATA phase.
confTO_DATAFINAL Timeout.datafinal
[1h] The timeout waiting for a response
to the final "." that terminates a
As you can see, at one hour, the data 'block' and 'final' timeouts
(where any scan will take place) are well in excess of likely database
reload times, so I do not think you have to worry about extending your
timeouts a few minutes longer. Don't forget that electronic mail came
out in the 1970s (I was there at the time:() and it largely replaced
putting a piece of paper in an envelope and licking a stamp. Way back
then, timeouts of around an hour for mail delivery seemed fairly short
to us, and to me they still seem quite reasonable now. Remember that
email is not (and never was supposed to be) Instant Messaging. Don't
forget that very often on a Linux box, the default connection timeout
for the TCP ESTABLISHED state is five days.
You could also run more than one clamd, and reload them on different
schedules; you could just refuse mail connections while reloading; or
(similarly) you could schedule out-of-service periods for SMTP, only
reloading during those out-of-service periods.
As I've maintained for some considerable time, this reload time issue
isn't really a big deal, and in any case it's manageable. Far more
pressing in my opinion are the issues of coverage and accuracy.
... I do not want to accept the message before it is scanned (to
avoid backscatter or silent discard of messages).
Sure, backscatter is a plague.
--
73,
Ged.
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
