atom feed15 messages in net.sourceforge.lists.courier-usersRE: [courier-users] Planned changes t...
FromSent OnAttachments
Sam VarshavchikSep 20, 2004 6:32 pm 
Jim HornerSep 20, 2004 8:03 pm 
Arturo "Buanzo" BusleimanSep 20, 2004 8:07 pm 
Mitch (WebCob)Sep 20, 2004 11:21 pm 
Scott SharkeySep 21, 2004 6:23 am 
MikeMSep 21, 2004 8:00 am 
Randy SmithSep 21, 2004 9:51 am 
Alexei Batyr'Sep 21, 2004 11:15 am 
Alessandro VeselySep 21, 2004 6:16 pm 
Sam VarshavchikSep 21, 2004 7:07 pm 
Sam VarshavchikSep 22, 2004 3:42 pm 
Michael CarmackSep 22, 2004 6:34 pm 
Johannes ErdfeltSep 22, 2004 8:47 pm 
Stefan HornburgSep 23, 2004 1:21 am 
Alessandro VeselySep 23, 2004 8:11 am 
Subject:RE: [courier-users] Planned changes to Courier's authentication library.
From:Mitch (WebCob) (mit@webcob.com)
Date:Sep 20, 2004 11:21:01 pm
List:net.sourceforge.lists.courier-users

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.

Thanks again for the awesome tool.

m/