Courier and DCC

Vincent Schonau
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

- 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


More information about the DCC mailing list

Contact by mail or use the form.