Bill Taroli wrote: > Sounds intriguing... but begs an obvious (if naive) question... What is > the apparent advantage of switch these to run via a perlfilter versus an > existing maildrop implementation that calls daemons for spamd and > clamavd? Performance? Additional functionality, such as automatic > *outbound* mail processing? Potential to bounce virus-laden or spam > emails during MTA dialog?
You cannot exactly compare global mail filtering (i.e. a courierfilter) to local mail filtering (i.e. maildrop or other dot-courier delivery instructions). Global filtering takes place during the SMTP transaction phase, and thus is able to directly *reject* messages. Local filtering takes place after the SMTP transaction phase has completed, so it cannot directly reject messages, but only generate concrete *bounce* messages. On the other hand, local filtering can manipulate the message at hand, which global filtering cannot do. Courier::Filter currently does global filtering only, and cannot modify messages. So, you can't generally replace maildrop or other dot-courier delivery instructions with Courier::Filter. Yes, Courier::Filter can do outbound mail filtering. It has been explicitly designed to support that. And, yes, Courier::Filter can (and should!) be used to reject virm or spam during the SMTP transaction phase. ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id56&alloc_id438&op=click _______________________________________________ courier-users mailing list [EMAIL PROTECTED] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
