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
