Ralf Hildebrandt Ralf.Hildebrandt@charite.de (Mo 12 Apr 2010 19:17:57 CEST): …

...

3. I think it's slow and I dont't know howto measure.
4. I thint it's slow.
5. I think it's slow.
6. I like a "Plan B"

Try it. The hardest part is to only scan mails younger than "last scan".

Virus database may have changed. A new scan with a new database could be a nice to have.

-- Heiko

Frank Elsner frank@moltke28.B.Shuttle.DE (Mo 12 Apr 2010 19:18:53 CEST):

On Sun, 11 Apr 2010 20:06:34 +0200 Andreas Schulze wrote:

...

Hello list,

I use currently a non-dovecot pop3 proxy which has the ability to scan all passing mails for viruses. And I like dovecot.

I like dovecot too. But I think virus-scanning is for the MTA.

IMAP allows for other ways „into“ the mail storage than via the MTA.

Heiko

Noel Butler schrieb:

On Mon, 2010-04-12 at 22:07 +0200, Heiko Schlittermann wrote:

...

Frank Elsner frank@moltke28.B.Shuttle.DE (Mo 12 Apr 2010 19:18:53 CEST):

...

On Sun, 11 Apr 2010 20:06:34 +0200 Andreas Schulze wrote:

...

Hello list,

I use currently a non-dovecot pop3 proxy which has the ability to scan all passing mails for viruses. And I like dovecot.

I like dovecot too. But I think virus-scanning is for the MTA.

IMAP allows for other ways „into“ the mail storage than via the MTA.

I agree with Frank, virus scanning, and IMHO spam filtering is the job for the MTA side of things, reject it before it gets near the mail storage.

Hi guys, I agree with Heiko. In my current setup it is _wanted_ to store/move mails via IMAP for usability reasons. So i am looking for at least virus scanning at the delivery point. postfix and dovecot use deliver, so it should be done at this point.

Greets, Sven

Am 13.04.2010 20:37 schrieb Noel Butler:

So, you want postfix to accept the virus, send it to dovecot's deliver which then calls a virus scanner and finds it infected and deletes it, that makes absolutely no sense ACK.

but imagine:

MTA delivers a mail where the virusscanner finds nothing. Mail gets delivered. Some time later there is a scannerupdate. Now the scanner would find a malicious content.

So I may instantly scan the complete mailstore each time a new pattern arrives or scan only each accessed mail with the latest pattern. This seems smarter to me.

For this scenario I would like to see a concept for datainspection/datamodification in dovecot. What about when dovecot would act as a milter client? Sounds strange but the problems are the same, why not use existing solutions ?

-- Andreas Schulze Internetdienste | P532

DATEV eG 90329 Nürnberg | Telefon +49 911 319-0 | Telefax +49 911 319-3196 E-Mail info @datev.de | Internet www.datev.de Sitz: 90429 Nürnberg, Paumgartnerstr. 6-14 | Registergericht Nürnberg, GenReg Nr.70 Vorstand Prof. Dieter Kempf (Vorsitzender) Dipl.-Kfm. Wolfgang Stegmann (stellvertretender Vorsitzender) Dipl.-Kfm. Michael Leistenschneider Jörg Rabe v. Pappenheim Dipl.-Vw. Eckhard Schwarzer Vorsitzender des Aufsichtsrates: Reinhard Verholen

...

MTA delivers a mail where the virusscanner finds nothing. Mail gets delivered. Some time later there is a scannerupdate. Now the scanner would find a malicious content. So I may instantly scan the complete mailstore each time a new pattern arrives or scan only each accessed mail with the latest pattern. This seems smarter to me. For this scenario I would like to see a concept for datainspection/datamodification in dovecot. What about when dovecot would act as a milter client? Sounds strange but the problems are the same, why not use existing solutions ?

The problems are the same, but a milter has the duty to filter incoming mail. It's not a general mail-(content)-only filter. You want a IMAP/POP3 mail inspector, well, that's fine. There are in-between firewall inspecting the contents of the routed connections. They understand POP3 and IMAP, as long as it is not encrypted. Some can act as proxy themselves, decrypt the connection. They work transparently. To solve the problem in Dovecot one need to create an "iilter" (IMAP filter), aka Dovecot plugin. Which hands over the contents to the virus scanner and replaces the malicous part with a dummy value. However, because of caching in IMAP clients doing so may not work as expected. That plugin could be derived from the zlib plugin, as it also has the duty to inspect the data on its flow from the disk to client and around. This won't work in Dovecot proxy mode, however, I guess.

I see a leakage with on-access virus scanning while using IMAP. Imagine users are sharing mailboxes, one uploading malware via imap, others downloading it via imap. Another one is the above mentioned virus scanner update. Scanning in the MUA is nice but can't deliver 99% sureness. I can't control every client. In my next setup there will be a SSL/SASL only configuration. So proxies will have problems and are one more possible point of failure (and need maintenance).

The only solution i see for this is a general AV-daemon or something like dazuko to scan whole disk activity. Weekly scans of the whole filesystem are usefull anyway. Or some dovecot filter plugin.

Sven

On Tue, 13 Apr 2010 13:21:28 +0200, Andreas Schulze andreas.schulze@datev.de articulated:

MTA delivers a mail where the virusscanner finds nothing. Mail gets delivered. Some time later there is a scannerupdate. Now the scanner would find a malicious content.

DEFINE: "Some time later". Are you referring to today, tomorrow, next {week,month,year}? Depending on your AV solution, you should all ready have the capabilities to run a virus scan on the directory(s) involved.

So I may instantly scan the complete mailstore each time a new pattern arrives or scan only each accessed mail with the latest pattern. This seems smarter to me.

All ready possible using ClamAV.

Doesn't your MUA offer any AV scanning? If not, then perhaps it is time to investigate the possibility of using a new MUA.

For this scenario I would like to see a concept for datainspection/datamodification in dovecot. What about when dovecot would act as a milter client? Sounds strange but the problems are the same, why not use existing solutions ?

This would just lead to redundancy with no applicable favorable results. Scanning the message when it arrives and then rescanning the INBOX at preset intervals is about as good as it is going to get. Using an MUA that has its own scanning engine would also be a plus. You could even engage multiple AV engines. A really bad idea IMHO; however, you pay your dues, you take your chances.

If Postfix is set up correctly with the proper checks, etc, SPAM and AV problems are reduced dramatically. I have not had a VIRUS get through to my system in years. An occasional SPAM, but then again, no system is fool proof. Besides, nothing is fool proof to the sufficiently motivate fool.

In any case, I worry more about some nefarious individual breaching my firewall than I do about contracting a VIRUS.

-- Jerry Dovecot.user@seibercom.net

Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header.

Aquadextrous, adj.: Possessing the ability to turn the bathtub faucet on and off with your toes.

Rich Hall, "Sniglets"

On Tue, 2010-04-13 at 13:21 +0200, Andreas Schulze wrote:

Am 13.04.2010 20:37 schrieb Noel Butler:

...

So, you want postfix to accept the virus, send it to dovecot's deliver which then calls a virus scanner and finds it infected and deletes it, that makes absolutely no sense ACK.

but imagine:

MTA delivers a mail where the virusscanner finds nothing. Mail gets delivered. Some time later there is a scannerupdate. Now the scanner would find a malicious content.

The same applies to your scenario, the chances of a 0 day virus getting in past the AV at MTA level and being found by the time the recipient checks mail is going to be so negligible, that said, the mailstore is additionally scanned every night regardless , without adding the massive resource hogging in having dovecot call AV everytime someone access mail, also, what about those who only do pop3? the same mail storage everywhere I've worked in past near 20 years is used to serve both, only the front ends differ, and in this part of the woods, there might be one imap user to every 5K pop3 user, if you use imap only, I still seeing it being a negative for resource reasons.

I may instantly scan the complete mailstore each time a new pattern arrives or scan only each accessed mail with the latest pattern. This seems smarter to me.

For this scenario I would like to see a concept for datainspection/datamodification in dovecot. What about when dovecot would act as a milter client? Sounds strange but the problems are the same, why not use existing solutions ?

I think your expecting dovecot to be more than what it is, it is not m$ exchange :) Cheers

On Tue, 2010-04-13 at 07:27 -0400, Jerry wrote:

On Tue, 13 Apr 2010 20:37:04 +1000, Noel Butler noel.butler@ausics.net articulated:

...

So, you want postfix to accept the virus, send it to dovecot's deliver which then calls a virus scanner and finds it infected and deletes it, that makes absolutely no sense to me, when postfix could have had its call to amavisd or mailscanner or some milter and delete it before it gets to dovecot, in other words deleting it closer to acceptance point which makes the most sense.

While I certainly would not recommend mailscanner with Postfix (it is not supported), amavised works fine, however. You could just use the

I certainly would recommend it, there are ample people on the mailscanner lists who will go out of their way to help anyone with this combination, as you very well know, but you are correct in as much as Wietse and the postfix community doesn't, and those who have been around long enough know why (this isn't the place for that discussion either for those who don't), however there are many large organisations happily using that combo and that number has grown over the years as postfix becomes more widespread use over sendmail etc.

'clamav-milter' if you so desired. That also delivers excellent results, especially when used in conjunction with the options third party signatures. See:

Yes, I have setup this milter on memory constrained VPS's for clients where neither MailScanner or amavisd-new will work without the kernel killing off stuff for out of memory on the entry class VPS offerings. I do recommend it.