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. > 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?). 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. OTOH, a generic notification system possibly together with blackholing (as in your case), 5xx'ing or tagging, would benefit much more users... 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... 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. Cheers, -aCaB _______________________________________________ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
