I'm planning to make the following structural changes. This is the only
chance for someone to talk me out of it.
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.