From: [EMAIL PROTECTED] > > Giampaolo, > > > > With 2.5.0 yes. > > I want it. No, I need it! :) > > Ok, tomorrow or maybe even today...
Great! > > Oh, by the way. Is it a per-user config, right? > > Which? Enabling defanging, *_lovers, blocking_ccat and such > is per-user, I meant blocking_ccat. > but when defanging strikes it, it still currently > applies the same message modification for all recipients. > Mail header editing is per-user, mail body editing is still per-message. Well, I can stand with it: most of my users have the very same settings. I did a squirrelmail plugin to let them handle their virus/banned/spam settings but, of course, almost nobody did use it... > > Well, I don't see any problem about this with known viri. > > However, one may > > occasionally get some unknown viri too, which may behave as bad as the > > firsts. So, avoiding SA on viri maybe limits the risk, but doesn't avoid > > it. Why not spawn a new child to run SA only on the specific message in > > which a virus or a banned had been detected? Would it reduce the risk? > > Actually the 2.5.0 does allow calling SA in a subprocess and retrieving > results over a pipe from it. Actually even 2.4.5 supports it: > > $sa_spawned = 0; # true: run SA in a subprocess; false: call > SA directly > > although I intended to keep it low-profile. It seems to work just > fine, it adds about 20..30 ms per SA call on our server. Benefits > are separation of potential problems in SA and its external modules > from affecting amavisd, and cleaner timeout aborts. Drawback > is there are more processes now, so worst case (when all child > processes are doing spam checks) memory requirements double. > Try and see, set $sa_spawned=1 in amavisd.conf and that's it. This would spawn a new process even when the mail has no virus nor banned content. Well, no: I'm at short in memory. > > One more question. The defang message is a bit crude and I would like to > > personalize it. 2.5.x supports a defang message template? > > Indeed, defanging is rather crude currently. Its main limitation is > that it does not support per-recipient mail handling, it affects the > whole message and can not split it if different recipients would > require different handling (unlike other header edits, which fully > support per-recipient editing). This is on a to-do list... > > Also there are currently no templates for defanging, modifications > are hard-wired. Something for the future. If someone would like > to work on it, go ahead. I'm not that confident with perl, anyway maybe I'll try to figure out how to do a defang template. > > Also about templating in general. Two or three years ago I > tried to do an > > html template, but amavisd refused to work correctly with it. > At the epoch, > > I was said that custom templating was restricted to a single text/plain > > mime part. Is 2.5.x finally overcaming this limitations? > > No, status quo, still on a to-do list. I never came around to work > on this, there were always some other more pressing needs... Of course. Ok, thank you, Mark. Giampaolo > Mark ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ 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/
