Thus spake Alessandro Vesely on Thu, May 02, 2002 at 10:06:36AM CDT
> Yes. However, I still cannot explain to myself why it is not
> the opposite way around. More precisely: one advantage of the
> global filter is that it consists of a compiled program (well,
> then perlfilter will invoke an interpreter in turn, but this
> is a special case, isn't it?). Then one would think that a
> global filter filters all the mail (allfilter) and another
> filters nearly all the mail, leaving alone a few accounts that
> may have special needs. Instead, I should set up every account
> except the one that I want to whitefilter. At least, I have
> to have a script be invoked for every account that must be filtered. 

IMHO your point is well taken.  One rationale comes to mind for this.
Proper operation of global filters is mission-critical to delivery of mail. 
If one or more of the filtering programs crash, then _no_ mail will be
delivered to any account employing global filtering.  So perhaps it's
appropriate to have to be proactive to invoke global filtering.

I would think that in addition to placing the filter socket in
/var/courier/filters or /var/courier/allfilters, a 3rd location might be
appropriate, say /var/courier/deffilters, and if a socket were opened in
this directory, the nonexistence of a local ~/.mailfilters/rcptfilter would
be a sufficient condition to pass email through the global filter stack.  If
~/.mailfilters/rcptfilter exists, _and_ it returns an exit code of 0, then
whitelisting would be in effect.  This would eliminate the dependence global
filtering on the existence of ~/.mailfilters/rcptfilter and remain
compatible with existing installations.  This would be more of an opt-out
solution than the opt-in solution for global filters in
/var/courier/filters, but not as absolute as use of the allfilters facility.

Filters, including perl-based filters, are memory resident, so they're
effectively compiled at run-time and as I understand it, there's no speed
hit involved from invoking an interpreter on the script for every email.  My
experience with writing my couriervirusfilter is that the script is
re-interpreted periodically, but certainly not with every use, so all global
variables have to be properly initialized on each pass.
 
> Why? Is there a rationale that I am missing?
> Anybody feels like telling us how it began?
> And how will it evolve? 

The good Mr. Sam is the alpha and omega on courier, so he's the one that
will have to address this.

-- 
Lindsay Haisley       | "Everything works    |     PGP public key
FMP Computer Services |       if you let it" |      available at
512-259-1190          |    (The Roadie)      | <http://www.fmp.com/pubkeys>
http://www.fmp.com    |                      |

_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to