Virus scan + removal on a mdbox mail storage

Christoph Haas christoph+dovecot at
Wed Feb 20 21:02:02 EET 2019

Hello David,

----- Nachricht von David Pottage via dovecot <dovecot at> ---------
      Datum: Wed, 20 Feb 2019 14:56:51 +0000
        Von: David Pottage via dovecot <dovecot at>
Antwort an: David Pottage <david at>
    Betreff: Re: Virus scan + removal on a mdbox mail storage
         An: dovecot at

> On 2019-02-20 01:46, Christoph Haas via dovecot wrote:
>> I need advice on how virus scan and removal can be done on a _mdbox_
>> mail storage?
>> On a maildir storage the virus scanner (e.g. clamav etc.) can detect
>> and remove a email that is infected, since every email and attachment
>> are stored in separate files.
>> But in mdbox the emails and attachments are compressed together in one
>> ore more mdbox-files ...
>> I am anxious to convert my mail storage for virus scanning into
>> maildir format, since I don't know if a virus or crypto trojan con be
>> activated with this converting action =:-o
> To clarify: You want to convert your mail storage from mdbox to  
> maildir, but you want to scan for viruses first?

NO! My mail storage is mdbox. And at the moment I have no intention to  
convert it to Maildir!

But I know, that virus detection and deletion is much easier with  
Maildir, since every mail is represented by a file. So if there is one  
mail infected, the file can easily deleted - also by external  
antivirus tools. Also there are no indices with Maildir.

On the opposite in the mdbox mail storage several mails are  
represented by one mdbox-file, so I'm looking for a way to detect and  
if necessary remove infected mails without damaging my mdbox storage  
or the indices.

One idea was to convert the mdbox storage for virus scanning on the  
fly to Maildir do the antivirus stuff and then vice versa. But this  
produces quite a lot of overhead ...

--> so I need a better way

> You are doing things in the wrong order.
> Firstly converting mail storage format is very unlikely to trigger a  
> virus. For that to happen the virus author would need to find and  
> write an exploit for dovecot that will trick it into treating email  
> as executable code. While not impossible that is quite unlikely  
> because there is no normal situation where dovecot will execute  
> email as code. Also it is unlikely that a virus writer will target  
> dovecot when Microsoft exchange is much more common and would be a  
> higher value target.
> Secondly, as a rule you want to scan email for viruses as it arrives  
> and leaves, not when it is at rest in user mailboxes, again it is  
> possible that a new virus will be discovered some time after the  
> email arrives so a retrospective scan would find it, but that won't  
> help you much because most users read their email and open  
> attachments soon after the email arrives.

I'm completely with you! I have of course configured my postfix with  
Amavisd-new and all that stuff. But viruses evolve quite faster than  
detection patterns of e.g. Clam-AV.

So it is likely, that Clam-AV didn't detect a virus when scanning the  
mail-traffic on arrival and the malware now resides in the  

For this situation an afterward virus scan of the existing mail  
storage on a regular basis seems to me an appropriate method to get  
rid of viruses, trojans etc. that were not detected on arrival and  
reside like a time bomb in my mail storage...

Btw.: what virus scanners besides Clam-AV are the people on this list  
using? And how is the virus scanner implemented: via Amavisd-new or  
e.g. rspamd or ...?
- I hope this question is not too offtopic for the dovecot list!

> So my advice is to do the conversion to maildir now, then scan all  
> the files as a one off, and going forward you should configure your  
> email transport daemon (postfix, exim etc) to pass incoming (and  
> possibly outgoing) email through clamav.
> -- 
> David Pottage

----- Ende der Nachricht von David Pottage via dovecot  
<dovecot at> -----


P.S.: excuse my English - I'm no native speaker ...

Christoph Haas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 3178 bytes
Desc: ?ffentlicher PGP-Schl?ssel
URL: <>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 821 bytes
Desc: Digitale PGP-Signatur
URL: <>

More information about the dovecot mailing list