Wed Apr 10 00:24:35 UTC 2002
On Tue, Apr 09, 2002 at 03:11:00PM -0700, Earl Killian wrote: > Has anyone out there gotten Courier (yet another MTA) to use DCC > filtering? I'm in the process of moving from qmail to courier, and will be doing this. Courier has several powerful filtering options, which is a major reason for me to switch. Here's what I've been considering for the DCC with Courier: - courierfilter is an API that allows you to write your own (globla) filters to process e-mail during the SMTP conversation. An interface to perl filters is also provided, so it should be fairly easy to create a filter that will pipe the mail through dccproc before accepting it, and even possibly reject it based on the dccproc output. courierfilter can't modify the message, however, so DCC headers can't be added here. I'm considering using this interface to checksum all mail accepted at my mailservers. - localmailfilter provides for user-configured mailfilters that are executed during the SMTP conversation. By default it works maildrop (the Courier MDA) in 'embedded mode', which means it will refuse to do external program executions (among other stuff), _unless_ the sysadmin provides pre-defined filters in a special place. Calling dccproc through maildropfilters 'xfilter' looks like the best option. The filters are executed as the recipient who owns the filter, so $HOME/.whiteclnt will be accessible. The filters are executed during the smtp-conversation, and can only accept or reject a message, not change it (so no headers). Good stuff if you want to provide users with a choice of e.g. accept/reject based on DCC, or 'just' checksum and have them do their own processing later. Localmailfilter can override courierfilter, so users can opt-out of your sitewide rejection policy (if you have one). - Courier comes with an MDA (maildrop) with its own filtering language, which is completely user-configurable. You could choose one of the options above and have users put dccproc -Q in their mailfilter to add headers for (further) filtering, or you could provide _no_ DCC services at the server-wide level and simply have users call dccproc from their mailfilters (using xfilter). Because any particular configuration could have _all_ of these layers of filtering in place, avoiding reporting the same message to the DCC server multiple times would be the only major problem I see, mostly because of the inability to add headers during the smtp-conversation. If you want to protect your users from themselves _and_ use either or both of the SMTP-level options, perhaps a cripled query-only version of dccproc available to users would be useful. There was some public discussion (in nanae, I think) between the authors of Courier and DCC respectively that would indicate that there's not much chance of extensive support for DCC in Courie. I think it'd be very cool to have a dcc client that implements the courierfilter interface, though, so if anyone is going to write one, I'll volunteer as a tester :) > (I'm using DCC with smtpd, but I'm asking for a friend who is bringing > up Courier, a fairly nice MTA/imap/pop3/webmail package.) I'll be happy to work with your friend on the various options on my pre-production Courier-server here. Feel free to (have them) contact me off-list. Vince.
More information about the DCC