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.


Please submit your patches to our Bugzilla:

Reply via email to