Hello Mark, thanks for your reply.
On Saturday 12 November 2005 02:01, you wrote: > > 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. Ok > > * 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. You already named a good solution :-) Rebuilding/modifying the mail takes place after content inspection. Why not have a second directory for every mail and temporarily move the files there. Moving files is fast and efficient if the second directory resides on the same filesystem. Also we only have to move the files which should not be seen by the AV scanner, like the source file of a compressed archive. IMHO this can be implemented without huge code changes. > 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. Do you think the sending code could be restructured so that an email can be generate per recipient(-group) if needed? Though that would be truly something for 2.4.0 :-) > 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. That's true for virus mails that are not found by the virus scanner. But think of a company policy to disallow receiving ms office files (because of "active" content). Another case I know of is machine control firmware (e.g. for NC drilling machines). Often the controller is x86 based using dos - so the files are detected as executables and thus denied. The big advantage is that the user knows what's happening without administrator interaction. A banned notify mail is ok, but it's much better to have the original email without the attachment. btw: What do you think of my "warn_banned_offsite" patch? > 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. If we mess up, the original is always stored in the quarantine. There is also a good side to it: We make sure broken MIME never reaches the client. If amavis can't properly inspect the mail because of broken MIME, it's much safer to pass something clean to the client. Or am I wrong on this one? We also don't modify every mail, only the ones with banned attachments. That would of course change with the "append disclaimer" feature. Adding a global config switch to enable mail modification in general would be a good idea. It's documented by "WARNING, if you enable this, amavis may corrupt some of your mail. No warranty, don't complain. You have been warned." I've taken the code productive for one week on a busy mailserver, so far it looks very good and no messed up mail yet. Cheers, Thomas ------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/
