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.
6 messages in net.sourceforge.lists.courier-users[courier-users] RE: Courier::Filter -...
