Mailing List Archive

On Tue, 6 Apr 2021, Eddie via clamav-users wrote:

> A POP3 proxy program I have running on a Debian 10.8 system, uses clamscan to
> check incoming e-mails.  At some point in the very early morning (US West
> Coast time) it suddenly started taking a very long time to scan each mail, 
> So much that the controlling process would time out before clamscan
> finished.  Up to this point it was running fine.
>
> Running a test from the command line, on a very simple 1-line mail took
> around 25 minutes:
>
> root@CleanMail:~# date ; clamscan test.msg -v  --no-summary ; date
> Mon 05 Apr 2021 11:59:10 AM PDT
> Scanning /root/test.msg
> /root/test.msg: OK
> Mon 05 Apr 2021 12:24:06 PM PDT
> root@CleanMail:~#
>
> Looking through the logs, I can't see anything happening in the period
> between the last good scan and the sloooooow ones.
>
> Where should I be going next to track this down.

How much RAM does the machine have ?
Is something else using much RAM ?
Ideally I wouldn't run clamd on a machine with less than 4GB RAM.

If you are running freshclam and clamd, there is a setting which
will stop them using double memory while updating.

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

_______________________________________________

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

On 06.04.21 08:43, Eddie via clamav-users wrote:
>A POP3 proxy program I have running on a Debian 10.8 system, uses
>clamscan to check incoming e-mails.? At some point in the very early
>morning (US West Coast time) it suddenly started taking a very long
>time to scan each mail,? So much that the controlling process would
>time out before clamscan finished.? Up to this point it was running
>fine.
>
>Running a test from the command line, on a very simple 1-line mail
>took around 25 minutes:
>
>root@CleanMail:~# date ; clamscan test.msg -v? --no-summary ; date
>Mon 05 Apr 2021 11:59:10 AM PDT
>Scanning /root/test.msg
>/root/test.msg: OK
>Mon 05 Apr 2021 12:24:06 PM PDT
>root@CleanMail:~#
>
>Looking through the logs, I can't see anything happening in the period
>between the last good scan and the sloooooow ones.
>
>Where should I be going next to track this down.

you should prefer clamdscan, that uses tunning clamd to scan, this way you
skip virus DB initialization at each scan.

Note that the memory question is important. clamd uses >1GB RAM on my
machine. you need at least 2GB of RAM to scan in reasonable time.


--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
The only substitute for good manners is fast reflexes.

_______________________________________________

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

Clamscan can spend a looooong time loading signatures, etc. If you run
your command with strace (or monitor the process with lsof, etc.) you'll
probably see clamscan is busy accessing signature files.

On Tue, Apr 6, 2021 at 5:44 PM Eddie via clamav-users <
clamav-users@lists.clamav.net> wrote:

> A POP3 proxy program I have running on a Debian 10.8 system, uses
> clamscan to check incoming e-mails. At some point in the very early
> morning (US West Coast time) it suddenly started taking a very long time
> to scan each mail, So much that the controlling process would time out
> before clamscan finished. Up to this point it was running fine.
>
> Running a test from the command line, on a very simple 1-line mail took
> around 25 minutes:
>
> root@CleanMail:~# date ; clamscan test.msg -v --no-summary ; date
> Mon 05 Apr 2021 11:59:10 AM PDT
> Scanning /root/test.msg
> /root/test.msg: OK
> Mon 05 Apr 2021 12:24:06 PM PDT
> root@CleanMail:~#
>
> Looking through the logs, I can't see anything happening in the period
> between the last good scan and the sloooooow ones.
>
> Where should I be going next to track this down.
>
> Cheers.
>
> _______________________________________________
>
> 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
>

On 4/6/2021 8:56 AM, Matus UHLAR - fantomas wrote:
> On 06.04.21 08:43, Eddie via clamav-users wrote:
>> A POP3 proxy program I have running on a Debian 10.8 system, uses
>> clamscan to check incoming e-mails.? At some point in the very early
>> morning (US West Coast time) it suddenly started taking a very long
>> time to scan each mail,? So much that the controlling process would
>> time out before clamscan finished.? Up to this point it was running
>> fine.
>>
>> Running a test from the command line, on a very simple 1-line mail
>> took around 25 minutes:
>>
>> root@CleanMail:~# date ; clamscan test.msg -v? --no-summary ; date
>> Mon 05 Apr 2021 11:59:10 AM PDT
>> Scanning /root/test.msg
>> /root/test.msg: OK
>> Mon 05 Apr 2021 12:24:06 PM PDT
>> root@CleanMail:~#
>>
>> Looking through the logs, I can't see anything happening in the
>> period between the last good scan and the sloooooow ones.
>>
>> Where should I be going next to track this down.
>
> you should prefer clamdscan, that uses tunning clamd to scan, this way
> you
> skip virus DB initialization at each scan.
>
> Note that the memory question is important. clamd uses >1GB RAM on my
> machine. you need at least 2GB of RAM to scan in reasonable time

Watching via "top" while it's scanning, I do see it's taking a chunk of
memory, but it's not overly excessive.? swap space is basically unused.

I'm looking at moving over to clamdscan.

Cheers.

_______________________________________________

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

Understood, which is why I'm looking to move to clamdscan.

But I'd like to understand why, on Sunday morning, the scan time which
had been under a minute per mail, for over 4 months, suddenly jumped to
25 minutes per mail and has remained at that.

Cheers.

On 4/6/2021 10:39 AM, Richard Graham wrote:
> Clamscan can spend a looooong time loading signatures, etc.  If you
> run your command with strace (or monitor the process with lsof, etc.)
> you'll probably see clamscan is busy accessing signature files.
>
> On Tue, Apr 6, 2021 at 5:44 PM Eddie via clamav-users
> <clamav-users@lists.clamav.net <mailto:clamav-users@lists.clamav.net>>
> wrote:
>
> A POP3 proxy program I have running on a Debian 10.8 system, uses
> clamscan to check incoming e-mails.  At some point in the very early
> morning (US West Coast time) it suddenly started taking a very
> long time
> to scan each mail,  So much that the controlling process would
> time out
> before clamscan finished.  Up to this point it was running fine.
>
> Running a test from the command line, on a very simple 1-line mail
> took
> around 25 minutes:
>
> root@CleanMail:~# date ; clamscan test.msg -v  --no-summary ; date
> Mon 05 Apr 2021 11:59:10 AM PDT
> Scanning /root/test.msg
> /root/test.msg: OK
> Mon 05 Apr 2021 12:24:06 PM PDT
> root@CleanMail:~#
>
> Looking through the logs, I can't see anything happening in the
> period
> between the last good scan and the sloooooow ones.
>
> Where should I be going next to track this down.
>
> Cheers.
>
> _______________________________________________
>
> clamav-users mailing list
> clamav-users@lists.clamav.net <mailto:clamav-users@lists.clamav.net>
> https://lists.clamav.net/mailman/listinfo/clamav-users
> <https://lists.clamav.net/mailman/listinfo/clamav-users>
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
> <https://github.com/vrtadmin/clamav-faq>
>
> http://www.clamav.net/contact.html#ml
> <http://www.clamav.net/contact.html#ml>
>

>
> But I'd like to understand why, on Sunday morning, the scan time which had
> been under a minute per mail, for over 4 months, suddenly jumped to 25
> minutes per mail and has remained at that.


It's a good question. Is there any way to reproduce what was happening on
Sunday morning? ... and then compare it to what is happening today?

Has the size/location/access method to clamscan's signatures changed? Is
your system (drives, network, etc.) healthy?

On Tue, Apr 6, 2021 at 8:31 PM Eddie <stunnel@attglobal.net> wrote:

> Understood, which is why I'm looking to move to clamdscan.
>
> But I'd like to understand why, on Sunday morning, the scan time which had
> been under a minute per mail, for over 4 months, suddenly jumped to 25
> minutes per mail and has remained at that.
>
> Cheers.
>
> On 4/6/2021 10:39 AM, Richard Graham wrote:
>
> Clamscan can spend a looooong time loading signatures, etc. If you run
> your command with strace (or monitor the process with lsof, etc.) you'll
> probably see clamscan is busy accessing signature files.
>
> On Tue, Apr 6, 2021 at 5:44 PM Eddie via clamav-users <
> clamav-users@lists.clamav.net> wrote:
>
>> A POP3 proxy program I have running on a Debian 10.8 system, uses
>> clamscan to check incoming e-mails. At some point in the very early
>> morning (US West Coast time) it suddenly started taking a very long time
>> to scan each mail, So much that the controlling process would time out
>> before clamscan finished. Up to this point it was running fine.
>>
>> Running a test from the command line, on a very simple 1-line mail took
>> around 25 minutes:
>>
>> root@CleanMail:~# date ; clamscan test.msg -v --no-summary ; date
>> Mon 05 Apr 2021 11:59:10 AM PDT
>> Scanning /root/test.msg
>> /root/test.msg: OK
>> Mon 05 Apr 2021 12:24:06 PM PDT
>> root@CleanMail:~#
>>
>> Looking through the logs, I can't see anything happening in the period
>> between the last good scan and the sloooooow ones.
>>
>> Where should I be going next to track this down.
>>
>> Cheers.
>>
>> _______________________________________________
>>
>> 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
>>
>
>

I can go back to bed and sleep.  :-)

The only thing that runs on this server is the POP3 proxy code, nothing
else.  And freshclam didn't pull any new signatures until after the
slowdown started.  And take this with the same grain of salt I used to,
when I worked support:  No, nothing was changed and the VM is healthy.

Running --debug and tail'ing the output, these are the 2 points that
seem to account for almost all the 25 minutes:

--- Big snip ---

LibClamAV debug: Matcher[13]: INTERNAL: AC sigs: 0 (reloff: 0, absoff:
0) BM sigs: 0 (reloff: 0, absoff: 0) PCREs: 0 (reloff: 0, absoff: 0)
maxpatlen 0 (ac_only mode)
LibClamAV debug: Matcher[14]: OTHER: AC sigs: 0 (reloff: 0, absoff: 0)
BM sigs: 0 (reloff: 0, absoff: 0) PCREs: 0 (reloff: 0, absoff: 0)
maxpatlen 0 (ac_only mode)

---Very long wait here ---

LibClamAV debug: Building regex list
LibClamAV debug: Using filter for trie 0
LibClamAV debug: hashtab: Freeing hashset, elements: 0, capacity: 0
LibClamAV debug: Building regex list
LibClamAV debug: Using filter for trie 0
LibClamAV debug: hashtab: Freeing hashset, elements: 0, capacity: 0

--- More big snip ---

LibClamAV debug: hashtab: Freeing hashset, elements: 0, capacity: 0
LibClamAV debug: cli_magic_scandesc: returning 0  at line 3202
LibClamAV debug: cache_add: 2e27d1964afc50a27f3b833a85047d8f (level 0)
/root/test.msg: OK

---Very long wait here ---

LibClamAV debug: Cleaning up phishcheck
LibClamAV debug: Freeing phishcheck struct
LibClamAV debug: Phishcheck cleaned up


Cheers.


On 4/6/2021 11:46 AM, Richard Graham wrote:
>
> But I'd like to understand why, on Sunday morning, the scan time
> which had been under a minute per mail, for over 4 months,
> suddenly jumped to 25 minutes per mail and has remained at that.
>
>
> It's a good question.  Is there any way to reproduce what was
> happening on Sunday morning?  ... and then compare it to what is
> happening today?
>
> Has the size/location/access method to clamscan's signatures changed? 
> Is your system (drives, network, etc.) healthy?
>
> On Tue, Apr 6, 2021 at 8:31 PM Eddie <stunnel@attglobal.net
> <mailto:stunnel@attglobal.net>> wrote:
>
> Understood, which is why I'm looking to move to clamdscan.
>
> But I'd like to understand why, on Sunday morning, the scan time
> which had been under a minute per mail, for over 4 months,
> suddenly jumped to 25 minutes per mail and has remained at that.
>
> Cheers.
>
> On 4/6/2021 10:39 AM, Richard Graham wrote:
>> Clamscan can spend a looooong time loading signatures, etc.  If
>> you run your command with strace (or monitor the process with
>> lsof, etc.) you'll probably see clamscan is busy accessing
>> signature files.
>>
>> On Tue, Apr 6, 2021 at 5:44 PM Eddie via clamav-users
>> <clamav-users@lists.clamav.net
>> <mailto:clamav-users@lists.clamav.net>> wrote:
>>
>> A POP3 proxy program I have running on a Debian 10.8 system,
>> uses
>> clamscan to check incoming e-mails.  At some point in the
>> very early
>> morning (US West Coast time) it suddenly started taking a
>> very long time
>> to scan each mail,  So much that the controlling process
>> would time out
>> before clamscan finished.  Up to this point it was running fine.
>>
>> Running a test from the command line, on a very simple 1-line
>> mail took
>> around 25 minutes:
>>
>> root@CleanMail:~# date ; clamscan test.msg -v --no-summary ; date
>> Mon 05 Apr 2021 11:59:10 AM PDT
>> Scanning /root/test.msg
>> /root/test.msg: OK
>> Mon 05 Apr 2021 12:24:06 PM PDT
>> root@CleanMail:~#
>>
>> Looking through the logs, I can't see anything happening in
>> the period
>> between the last good scan and the sloooooow ones.
>>
>> Where should I be going next to track this down.
>>
>> Cheers.
>>
>> _______________________________________________
>>
>> clamav-users mailing list
>> clamav-users@lists.clamav.net
>> <mailto:clamav-users@lists.clamav.net>
>> https://lists.clamav.net/mailman/listinfo/clamav-users
>> <https://lists.clamav.net/mailman/listinfo/clamav-users>
>>
>>
>> Help us build a comprehensive ClamAV guide:
>> https://github.com/vrtadmin/clamav-faq
>> <https://github.com/vrtadmin/clamav-faq>
>>
>> http://www.clamav.net/contact.html#ml
>> <http://www.clamav.net/contact.html#ml>
>>
>

After setting up clamav-daemon, I suspect it's having the same issue,
based on the 11 minute "stall" part way through the initialisation.

Tue Apr  6 16:26:14 2021 -> +++ Started at Tue Apr  6 16:26:14 2021
Tue Apr  6 16:26:14 2021 -> Received 0 file descriptor(s) from systemd.
Tue Apr  6 16:26:14 2021 -> clamd daemon 0.102.4 (OS: linux-gnu, ARCH:
i386, CPU: i686)
Tue Apr  6 16:26:14 2021 -> Running as user clamav (UID 108, GID 114)
Tue Apr  6 16:26:14 2021 -> Log file size limited to 4294967295 bytes.
Tue Apr  6 16:26:14 2021 -> Reading databases from /var/lib/clamav
Tue Apr  6 16:26:14 2021 -> Not loading PUA signatures.
Tue Apr  6 16:26:14 2021 -> Bytecode: Security mode set to "TrustSigned".
Tue Apr  6 16:27:56 2021 -> Loaded 8518548 signatures.
Tue Apr  6 16:39:22 2021 -> LOCAL: Removing stale socket file
/var/run/clamav/clamd.ctl
Tue Apr  6 16:39:22 2021 -> LOCAL: Unix socket file
/var/run/clamav/clamd.ctl
Tue Apr  6 16:39:22 2021 -> LOCAL: Setting connection queue length to 15
Tue Apr  6 16:39:22 2021 -> Limits: Global time limit set to 120000
milliseconds.
... ... ...

Cheers.

On 4/6/2021 12:40 PM, Eddie via clamav-users wrote:
> I can go back to bed and sleep.  :-)
>
> The only thing that runs on this server is the POP3 proxy code,
> nothing else.  And freshclam didn't pull any new signatures until
> after the slowdown started.  And take this with the same grain of salt
> I used to, when I worked support:  No, nothing was changed and the VM
> is healthy.
>
> Running --debug and tail'ing the output, these are the 2 points that
> seem to account for almost all the 25 minutes:
>
> --- Big snip ---
>
> LibClamAV debug: Matcher[13]: INTERNAL: AC sigs: 0 (reloff: 0, absoff:
> 0) BM sigs: 0 (reloff: 0, absoff: 0) PCREs: 0 (reloff: 0, absoff: 0)
> maxpatlen 0 (ac_only mode)
> LibClamAV debug: Matcher[14]: OTHER: AC sigs: 0 (reloff: 0, absoff: 0)
> BM sigs: 0 (reloff: 0, absoff: 0) PCREs: 0 (reloff: 0, absoff: 0)
> maxpatlen 0 (ac_only mode)
>
> ---Very long wait here ---
>
> LibClamAV debug: Building regex list
> LibClamAV debug: Using filter for trie 0
> LibClamAV debug: hashtab: Freeing hashset, elements: 0, capacity: 0
> LibClamAV debug: Building regex list
> LibClamAV debug: Using filter for trie 0
> LibClamAV debug: hashtab: Freeing hashset, elements: 0, capacity: 0
>
> --- More big snip ---
>
> LibClamAV debug: hashtab: Freeing hashset, elements: 0, capacity: 0
> LibClamAV debug: cli_magic_scandesc: returning 0  at line 3202
> LibClamAV debug: cache_add: 2e27d1964afc50a27f3b833a85047d8f (level 0)
> /root/test.msg: OK
>
> ---Very long wait here ---
>
> LibClamAV debug: Cleaning up phishcheck
> LibClamAV debug: Freeing phishcheck struct
> LibClamAV debug: Phishcheck cleaned up
>
>
> Cheers.
>
>
> On 4/6/2021 11:46 AM, Richard Graham wrote:
>>
>> But I'd like to understand why, on Sunday morning, the scan time
>> which had been under a minute per mail, for over 4 months,
>> suddenly jumped to 25 minutes per mail and has remained at that.
>>
>>
>> It's a good question.  Is there any way to reproduce what was
>> happening on Sunday morning?  ... and then compare it to what is
>> happening today?
>>
>> Has the size/location/access method to clamscan's signatures
>> changed?  Is your system (drives, network, etc.) healthy?
>>
>> On Tue, Apr 6, 2021 at 8:31 PM Eddie <stunnel@attglobal.net
>> <mailto:stunnel@attglobal.net>> wrote:
>>
>> Understood, which is why I'm looking to move to clamdscan.
>>
>> But I'd like to understand why, on Sunday morning, the scan time
>> which had been under a minute per mail, for over 4 months,
>> suddenly jumped to 25 minutes per mail and has remained at that.
>>
>> Cheers.
>>
>> On 4/6/2021 10:39 AM, Richard Graham wrote:
>>> Clamscan can spend a looooong time loading signatures, etc.  If
>>> you run your command with strace (or monitor the process with
>>> lsof, etc.) you'll probably see clamscan is busy accessing
>>> signature files.
>>>
>>> On Tue, Apr 6, 2021 at 5:44 PM Eddie via clamav-users
>>> <clamav-users@lists.clamav.net
>>> <mailto:clamav-users@lists.clamav.net>> wrote:
>>>
>>> A POP3 proxy program I have running on a Debian 10.8 system,
>>> uses
>>> clamscan to check incoming e-mails.  At some point in the
>>> very early
>>> morning (US West Coast time) it suddenly started taking a
>>> very long time
>>> to scan each mail,  So much that the controlling process
>>> would time out
>>> before clamscan finished.  Up to this point it was running fine.
>>>
>>> Running a test from the command line, on a very simple
>>> 1-line mail took
>>> around 25 minutes:
>>>
>>> root@CleanMail:~# date ; clamscan test.msg -v --no-summary ;
>>> date
>>> Mon 05 Apr 2021 11:59:10 AM PDT
>>> Scanning /root/test.msg
>>> /root/test.msg: OK
>>> Mon 05 Apr 2021 12:24:06 PM PDT
>>> root@CleanMail:~#
>>>
>>> Looking through the logs, I can't see anything happening in
>>> the period
>>> between the last good scan and the sloooooow ones.
>>>
>>> Where should I be going next to track this down.
>>>
>>> Cheers.
>>>
>>> _______________________________________________
>>>
>>> clamav-users mailing list
>>> clamav-users@lists.clamav.net
>>> <mailto:clamav-users@lists.clamav.net>
>>> https://lists.clamav.net/mailman/listinfo/clamav-users
>>> <https://lists.clamav.net/mailman/listinfo/clamav-users>
>>>
>>>
>>> Help us build a comprehensive ClamAV guide:
>>> https://github.com/vrtadmin/clamav-faq
>>> <https://github.com/vrtadmin/clamav-faq>
>>>
>>> http://www.clamav.net/contact.html#ml
>>> <http://www.clamav.net/contact.html#ml>
>>>
>>
>
>
> _______________________________________________
>
> 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

Hi there,

On Tue, 6 Apr 2021, Eddie via clamav-users wrote:

> After setting up clamav-daemon, I suspect it's having the same issue, based
> on the 11 minute "stall" part way through the initialisation.
>
> Tue Apr  6 16:26:14 2021 -> +++ Started at Tue Apr  6 16:26:14 2021
> Tue Apr  6 16:26:14 2021 -> Received 0 file descriptor(s) from systemd.
> Tue Apr  6 16:26:14 2021 -> clamd daemon 0.102.4 (OS: linux-gnu, ARCH: i386, CPU: i686)
> Tue Apr  6 16:26:14 2021 -> Running as user clamav (UID 108, GID 114)
> Tue Apr  6 16:26:14 2021 -> Log file size limited to 4294967295 bytes.
> Tue Apr  6 16:26:14 2021 -> Reading databases from /var/lib/clamav
> Tue Apr  6 16:26:14 2021 -> Not loading PUA signatures.
> Tue Apr  6 16:26:14 2021 -> Bytecode: Security mode set to "TrustSigned".
> Tue Apr  6 16:27:56 2021 -> Loaded 8518548 signatures.
> Tue Apr  6 16:39:22 2021 -> LOCAL: Removing stale socket file /var/run/clamav/clamd.ctl
> Tue Apr  6 16:39:22 2021 -> LOCAL: Unix socket file /var/run/clamav/clamd.ctl
> Tue Apr  6 16:39:22 2021 -> LOCAL: Setting connection queue length to 15
> Tue Apr  6 16:39:22 2021 -> Limits: Global time limit set to 120000 milliseconds.

I wonder if the problem is that you're suddenly leaving stale sockets
lying around and something is waiting for a timeout? My clamd server
doesn't usually log as verbosely as this, but when it does this is a
typical log extract:

Sat Nov 28 01:17:28 2020 -> Bytecode: Security mode set to "TrustSigned".
Sat Nov 28 01:18:27 2020 -> Loaded 11344270 signatures.
Sat Nov 28 01:18:37 2020 -> TCP: Bound to [192.168.0.1]:3313
Sat Nov 28 01:18:37 2020 -> TCP: Setting connection queue length to 200
Sat Nov 28 01:18:37 2020 -> Limits: Global time limit set to 120000 milliseconds.

This is a Raspberry Pi4B.

--

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