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 
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 
and 'Blackhole'. We nuke the message but leave most of the headers intact so 
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', 
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 
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 
-> mailq: fatal: -qQ is not implemented

I will re-appraise the options.



> Cheers,
> -aCaB
> _______________________________________________
> Please submit your patches to our Bugzilla:
Please submit your patches to our Bugzilla:

Reply via email to