Thomas, > here is a patch to replace banned attachments with a text notice. > Guess a lot of people are going to be happy :-)
Thanks for your effort, I'm sure some people would like to use it. > Features: > * Replace banned attachments with notice of your choice > * Bans root/source attachment for compressed archives > * Original message gets quarantined for later reinjection > * Doesn't alter the email if no banned attachments are found > * Works on nested messages > * Bans root/source attachment for compressed archives This last one sounds more like a limitation than a feature, but it is clear that better can not be offered without a major effort. > Limitations: > * Doesn't work on a per recipient basis, if a banned attachment > is found for one recipient, it get's banned for all. This one is quite a serious one, it makes mail delivery inconsistent. It would be cleaner if the setting were only global, not per-recipient. > * All original files need to be retained (needed for reconstructing the > email), so effectivly compressed archives get passed twice to the virus > scanner. > Mark: Maybe this step can be automatated or even modified that all files > are kept on disc, but not passed to the virus scanner. I know, this is one of the reasons why I never truly embarked on that project, despite moving into this direction by making the output routines capable or sending a MIME::Entity object, in addition to being able to send a file. A proper solution would require a changed approach of storing mail parts, which must not be at the expense or unnecessary extra file creations (entering hard links, moves to another directory or duplicating files), as these operations can be quite expensive. I'm sure a reasonable solution can be found, although I don't yet see it. > Modify this existing variable to retain all attachments: > @keep_decoded_original_maps = (new_RE( qr '.' )); keep it simple, use 'a constant' (pseudo) lookup table (if we know the outcome of new_RE( qr '.' ) is always true, why re-evaluate it every time): @keep_decoded_original_maps = (1); > I gave the patch extensive testing for several hours, so far it's not > causing any trouble. As simple as the patch may look now, it took more than > 20 hours to cook this one up. Please test it before putting it in > productive usage. I didn't try it, but it appears sensible, it's probably the best that can be done without reorganizing the unpacked mail representation. In order to get it into the baseline code I would very much prefer to offer more general capabilities. Once a Pandora's box is opened, there are all kinds of interesting transformations possible, see MIMEdefang, and think of all these folks which clamour for a capability to properly append disclaimers without breaking MIME. There are two remaining point in my reservations: is it really useful to remove banned parts? In most cases whatever remains of the mail is not worth forwarding. An finally, taking mail apart and reassembling it bears a non-marginal chance of breaking it. A little-broken mail can end up as an unrecognizable mess. For the moment I can claim without much doubt that if somebody complains about a mail corruption during mail processing and delivery, that it is not amavisd-new who can be blamed, and not Postfix. On the other hand, messing with MIME has a great chance of making amavisd-new the guilty part for inappropriate or incorrect mail transformation. I'm not sure how to preserve your effort and still cater for my concerns. Mark ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
