From clamav-devel-bounces@lists.clamav.net Tue Mar 3 16:28:46 2009 Return-Path: X-Original-To: list@tad.clamav.net Delivered-To: list@tad.clamav.net X-Virus-Scanned: Debian amavisd-new at tad.clamav.net Received: from tad.clamav.net ([127.0.0.1]) by localhost (tad.clamav.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MivS3uPx8jFR; Tue, 3 Mar 2009 16:28:46 +0100 (CET) Received: from tad.clamav.net (localhost.localdomain [127.0.0.1]) by tad.clamav.net (Postfix) with ESMTP id 4ABFF31C163; Tue, 3 Mar 2009 16:28:45 +0100 (CET) X-Original-To: clamav-devel@tad.clamav.net Delivered-To: clamav-devel@tad.clamav.net X-Virus-Scanned: Debian amavisd-new at tad.clamav.net Received: from tad.clamav.net ([127.0.0.1]) by localhost (tad.clamav.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldGr0sLy8GMq for ; Tue, 3 Mar 2009 16:28:43 +0100 (CET) Received: from cupid.digitalfuture.it (static-217-133-237-204.clienti.tiscali.it [217.133.237.204]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by tad.clamav.net (Postfix) with ESMTP id C98C816C087 for ; Tue, 3 Mar 2009 16:28:42 +0100 (CET) Message-ID: <49AD4CA3.7020305@digitalfuture.it> Date: Tue, 03 Mar 2009 16:28:35 +0100 From: aCaB User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: ClamAV Development References: <49AC0389.1000409@gms.lu> <49ACB22F.6050606@digitalfuture.it> <49ACEDEC.7060105@gms.lu> In-Reply-To: <49ACEDEC.7060105@gms.lu> Subject: Re: [Clamav-devel] New ClamAV Milter + Patch X-BeenThere: clamav-devel@lists.clamav.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ClamAV Development List-Id: ClamAV Development List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: clamav-devel-bounces@lists.clamav.net Errors-To: clamav-devel-bounces@lists.clamav.net Chris Moules wrote: > Thanks for the feedback. I am using Postfix as MTA. Postfix does not have a > 'quarantine queue' as such, it places messages on hold in the main queue. > > This is my first ever work with a Milter and I am more sys-admin than developer. Good job then! >> OTOH, a generic notification system possibly together with blackholing >> (as in your case), 5xx'ing or tagging, would benefit much more users... > That was the idea. I initally thought of options like "NotifyReject" or "NotifyBlackhole". > Never having anything to do with a Milter before, I hacked the most un-hack like solution > that I could with a Clam-like feel to the implementation on a Friday afternoon. The NotifyReject and NotifyBlackhole options would be something worth looking into, imho. But the approach in your patch is unfortunately not suited to handle them. I say unfortunately because it's so minimal that it doesn't requre much code nor to break a lot of stuff. The problem is that in such a way you can basically generate a notices only at eom time and only when blackholing. Even earlier (than eom) blackholing cannot result in a notification being sent as we've got no mail to rewrite yet. >> Except the milter interface is not really designed with such things in >> mind, which re-introduces a series of issues like determining if the >> recipient is to be notified (e.g. local vs remote), assembling the >> message, forking, invoking sendmail, etc... > I noted that, I was looking for a neat way of getting information to the > destination without invoking an external call. If you ask me, the milter interface is horrible. IIRC the old milter had to inwoke sendmail twice to generate notices: once to determine if the recipient is local, once to send the actual notice. In many scenarios this requires the milter to be running as a privileged/trusted process. >> But again, if you consider that the very same effect can be achieved >> with about 3 lines of code in a sitewide procmail recipe or in a cronned >> shell/perl "mailq -qQ" parser, you would probably agree that doing it in >> the milter is not the way to go. > I am not a procmail fanboy and as said, Postfix does not have a 'quarantine queue'. > -> mailq: fatal: -qQ is not implemented As a debian user and casual postfix admin I assumed procmail was the default dropper anyway, but I see this is not the case. And yes, it's unfortunate that postfix cannot yet handle the quarantine properly. -aCaB _______________________________________________ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net