> > If people feel so strongly about not doing this thinking it's a bad idea,
> > why does exim even support sql at all? Surely having users, aliases, etc
> > in sql is a performance hit as well (and according to some people should not
> > be done).
>
> Personally, I've never been very happy about it for optimum performance,[*]
> but some sites have low load and today's computers are so fast that it
> doesn't seem unreasonable for those who are not worried by performance
> issues.
I don't disagree about performance. At work, we have around 215 users all
in SQL. I did this mainly because of ease of configuration. I alone
maintain the mailserver. I am also the only one there that knows alot about
linux. One of the other guys is learning, but I've had way more expereince
than him and can use a text editor to do configuration where he'd need some
gui to do the work for him. Using MySQL and MySQLcc has made some of the
maintenance easier for the others. They can check someone's password,
aliases, etc with out ever touching the mailserver. The users don't seem to
notice if it takes 2-3 seconds longer per email, the server is more loaded
on the pop3 side than the smtp side. One of the reasons I thought about
having the hints in the db is so that I could easily view the information
there through the sql just like everything else. I don't feel strongly
enough about doing it to write a patch for it.
> --------------------
> [*] For myself, I'd always go for a two-stage scheme, for instance,
> extracting aliases from a database into a "live" cdb file for Exim to
> use.
>
> --
> Philip Hazel University of Cambridge Computing Service,
> ph10@??? Cambridge, England. Phone: +44 1223 334714.
> Get the Exim 4 book: http://www.uit.co.uk/exim-book
>
>
> --
>
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim details at http://www.exim.org/ ##
>
--
Lab tests show that use of micro$oft causes cancer in lab animals
