Re: [courier-users] Beyond USERDB
Bernd Wurst
> I am planning implementing Courier in an environment with over 500 users
> which may eventually grow to almost One thousand so I decided to check what
> kind of authentication to use. I was surprised to see the above because I
> remember someone once said on the list that USERDB is recommended for a
> couple of hundred users.
Databases are overrated. :)
Plain text files are fast enough until they grow up to a huge size.
Parsing a text file is much faster than querying a database except when
reading the file starts to slow down and a cache could help. This won't happen
before you reach several megabytes of a text file.
> I have come to love USERDB because it is simple to implement. However, I
> have one question for you Courier Experts. Is it practically feasible to
> use USERDB with 500 - 1000 users. If not, what do you recommend.?
I would decide this upon the comfort of managing the accounts.
For me, I use MySQL backend because I provide a (third-party) webinterface to
my customers, allowing them to manage their accounts.
This is sort of difficult with userdb backend (need some scripting) because a
PHP web interface cannot write to the userdb file directly but it can write to
a MySQL database.
An example:
I operate about 800 courier accounts and the MySQL-Database for them is still
< 1 MB. To the text file for this would also be < 1 MB and should be easily
parsable.
regards, Bernd
Alessandro Vesely
> I am planning implementing Courier in an environment with over 500
> users which may eventually grow to almost One thousand so I decided to
> check what kind of authentication to use. I was surprised to see the
> above because I remember someone once said on the list that USERDB is
> recommended for a couple of hundred users.
As Joseph has thoroughly explained, the usability limit is reached
because of updates, not the total number of records per se. One may
assume users change their email address every T seconds. Thus, N users
imply an addition or removal every T/(2N) seconds, on average. When
that happens daily or hourly it is going to be a hindrance. For
N=1000, you'd rebuild daily if T is approx. 5.5 years. However, T may
vary so widely, even on average, that variations by a factor of 10 can
be easily justified.
> I have come to love USERDB because it is simple to implement. However, I
> have one question for you Courier Experts. Is it *_practically_*
> feasible to use USERDB with 500 – 1000 users. If not, what do you
> recommend.?
The one you're most familiar with. You may want to use the same
passwords also for other kinds of access to local systems, e.g. web
stuff served by Apache. Making such considerations may also help
making a decision.
Hth
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
courier-users mailing list
courie...@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Bowie Bailey
>
> 3. Password changes. This may have changed, but I don't think so. At the
> moment, you can't use sqwebmail to change mailbox passwords if you use
> userdb. This means unless you provide some other method of password
> change, users won't be able to change it on their own.
Password changes work quite well with sqwebmail and userdb.
--
Bowie
Joseph C. Lininger
Hash: SHA256
> Password changes work quite well with sqwebmail and userdb.
Ok, then I stand corrected. They didn't a few years ago when I used to
use userdb. In fact, that was why I switched to a database backend on
our servers instead of using userdb. Now I've discovered some other
benefits I wasn't getting before, which I like. Userdb is wonderful for
basic setups though.
- - --
Yes means no and no means yes. Delete all files [Y]?
Joseph C. Lininger,
<jb...@pcdesk.net>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
iQEcBAEBCAAGBQJLCxhQAAoJEMh8jNraUiwqMPUH/1l5VaXFTGHeGvEDCQ2F/Zl9
to/LmkXm9nOtvgApbhw/BeU+j04yzDRJpCmwFSjfcD4MvhUMUOS5gQ4r+Sx2BG36
1CEGq4SomoG2UX5KisWL1cBWEwRXBnM683l3lH82a+K9YaTHHBvkFxdjXZlurNo9
Qj+pKEOxrBjFjwaWoFulPw5mhYIRGlGrO74INidSJ1P98UNfw4deYA5tsuI9sZ3M
HPGYw0LkVe5FKViJWxvmjR5K0US4gsEINFYlGp6p0ovXY7LNURsl4qH5sTfMcj78
9hpo0sukgnm5TYMi/0fCkMmT/K9GnVi1hESjh7HNzdHoaupi8Wrrh0aOR9zbgJ4=
=OfCm
-----END PGP SIGNATURE-----