Not wanting to miss my chance ;-)

Not sure if this is the appropriate time to consider a few issues or not - and
maybe they have been addressed elsewhere while I wasn't looking - if so, forgive
me. I handle these parameters in my user database, and assume if that's where
they are, they might be retrieved through the auth lib...

1) As one other responder mentioned, use of authentication fields within
maildrop is often useful. Although we can write custom queries, we can't pass
any additional fields into courier for maildrop or filters to consider during
the run.

e.g. does a user want a global filter enforced, or does a user want spam moved
to a subfolder.

Currently I address this with a maildrop wrapper, which makes a second query to
the user database, fetching all the extra config values and storing them in the
environment, then calls the original maildrop. Not efficient, but it works.

2) As someone with a lot of domains (by my standards anyways) I have been trying
to segregate users mail to their appropriate IP's. That means ma...@domain1.com
should not be accepted through domain2.com's ip, and ideally, should not be sent
through the default system ip, but rather the ip appropriate for that domain
name. Currently no way of working around that, the result being that a few high
volume users have tried (sucessfully) to put their usage on another users bill
by using their ip. This is just an extension of the code existing that serves to
restrict operational services - yes?

3) SSL services per IP - connection to auth here is more tenuous, just that the
user-ip link is in my auth tables.

I've mentioned these things before, and realize they may not be mainstream, or
easy, but thought that as this was the "only chance" it was worth mentioning in
case others have the same needs.

Thanks again for the awesome tool.

m/