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

Reply via email to