Hello David,
----- Nachricht von David Pottage via dovecot <dovecot at dovecot.org>
---------
Datum: Wed, 20 Feb 2019 14:56:51 +0000
Von: David Pottage via dovecot <dovecot at dovecot.org>
Antwort an: David Pottage <david at chrestomanci.org>
Betreff: Re: Virus scan + removal on a mdbox mail storage
An: dovecot at dovecot.org
> 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
mdbox-storage.
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 dovecot.org> -----
Cheers
Christoph.
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:
<https://dovecot.org/pipermail/dovecot/attachments/20190220/ba40ad9f/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 821 bytes
Desc: Digitale PGP-Signatur
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20190220/ba40ad9f/attachment.sig>