> >> Although conceptually easier than I thought, a milter compatibility > >> layer still requires a good deal of coding, though. It would result in > >> duplicating many existing functionalities, e.g. header parsing...
> Matus UHLAR - fantomas wrote: > > functionalities existing where? On 01.11.09 15:53, Alessandro Vesely wrote: > For headers, each filter, as well as the MTA software itself, has > its own functions. In addition, there may be a number of assumptions > at both linkage and command execution layers, e.g. DNS lookups and > the sendmail executable. That is to say, it should be checked that > those milters don't rely on further peculiarities of sendmail than > the milter interface proper. we could check if those milters work with postfix (some do) and if they have changes towards postfix compatibility in ChangeLog ,,, > > incorporating milter would ease much of work since milter interface is > > available for sendmail and postfix and there are many milters available. I > > haven't checked if there are already available alternatives for courier but > > there are many milters available already... > > I haven't actually tried to run the configure script of a milter. I > could only try to guess where one could find a break-even between > porting each of N given milters versus porting the milter interface. > For N <= 2, I'd still guess it's easier to port each milter... for me, the N is currently 3-4 :-) (SA, clamav, DKIM, maybe DCC greylist) > >> For example, if one wanted to add DKIM support in C, it would seem > >> easier and safer to write a courier global filter using libopendkim > >> than write a milter compatibility layer for using the opendkim milter > >> module. > > > > does the same apply for multiple filters like spamassassin etc? All they may > > need modifying of the e-mail. > > SpamAssassin is a different thing. It is commonly run from maildrop > recipes for a number of reasons, including using personal Bayes data > for each recipient, and concealing filtering results from the sender. > > At any rate, to close files before invoking global filters, so as to > allow them to alter the message, was done in October 2007. See > http://markmail.org/message/7clmkipmcvaw4ini If there's only one recipient, SA can use his rules too. If there are more of them, a special recipient with safe options can be defined and mail can be re-scored in users' maildrop/procmail. Rejecting spam at SMTP level is better than saving to spam folder... -- Matus UHLAR - fantomas, [email protected] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I intend to live forever - so far so good. ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
