aCaB wrote:
> Chris Moules wrote:
>> As an ISP here in Luxembourg we stand liable if we intercept and remove
>> mail without informing the client. Our current system informs the
>> recipient about filtered Virus mail and delivers UCE tagged (or
>> delivered to a Spam folder).
>
> Hi Chris,
>
> I think the quarantine queue and the x-headers already offer quite a
> good base for postprocessing the infected messages and, standing the
> very peculiar needs of each mail server and deployment environment, I'm
> not very keen to add postprocessing functionalities to the milter unless
> these are extremely generic. Failing that, I'd rather leave the
> postprocessing entirely to the admin.
>
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.
>> I have had a look at the source to the new Milter and have seen that it
>> has simplified the program and made it much simpler. This is great. I
>> looked at the possibility for re-adding the notification possibility and
>> have had initial success with only a small patch. The style of the
>> patch, I believe, stays within the spirit of the re-write.
>
>> Before doing any further development, I wanted to get an idea if this
>> might make it into the upstream code or if something like this would end
>> up being an in-house patch.
>
> The patch is indeed small but it's not really about notifications. In
> fact it destroys the malicious message replacing its content and
> subjects with some static lines (BTW, what if the mail carries let's say
> a mua-specific exploit in its headers?).
The patch was not meant to be complete, just add base functionality along lines that
could lead to a 'proper' option. I just spent a few hours looking at the code and a
Milter programming guide. I kind of thought that this was somewhere between 'Accept'
and 'Blackhole'. We nuke the message but leave most of the headers intact so someone
could look up the source. I would have liked to add the name of the Virus and maybe the
original subject somewhere but this required lots more changes. Also reading the 'notification'
text from a file and supplying replace tags for things like 'From Address', 'Subject'
and 'Virus name'.
> Now I'm pretty sure this works good enough in your very case, but
> frankly I don't see such a feature of much interest for general use.
>
Fair enough, that is why I asked before doing more than a couple of hours.
I will look at the alternate options that you proposed.
> 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.
> 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.
>
> 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
I will re-appraise the options.
Thanks
Chris
>
> Cheers,
> -aCaB
>
> _______________________________________________
> http://lurker.clamav.net/list/clamav-devel.html
> Please submit your patches to our Bugzilla: http://bugs.clamav.net
>
_______________________________________________
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net
(text/plain)