[EMAIL PROTECTED] wrote:

I am an apps developer for a small company, and I happen to also be the manager
of our IS department, deservingly or not.  I am faced with a fairly important
decision about our email, and being a relative Linux newbie, I feel unqualified
to make it without some additional assistance.

My sys-admin, god love him,
a F/OSS guru, keeps me on my toes. The current proposal is to change our
email server as follows:
<...snipped...>
His rationale...


I'll attempt to address each of these specifically, and provide what insight I can.

"I want to replace OpenLDAP with MySQL for the accounts. Making SQL queries
will be more intuitive for both of us, vastly increasing the amount of control
we may exercise over the system."


Disclaimer: I am not yet quite comfortable with LDAP, and I think a lot of people feel that way. I can set it up, and make it do the base tasks I want, but I honestly don't have my head all the way around it's internals yet (and we use it for the TriLUG servers *blush*). On the other hand, and I think this is true of most people, I get MySQL. Maybe it's just because it's required for other tasks so I have more experience with it, or is fundamentally more transparent, but *most* people are able to do magical tricks with SQL, compared to what *most* people are capable of doing with LDAP. It's always good to leverage that existing knowledge, if your situation permits it.

"The reason I want to use certs is, simply,
to make my life easier on the mail server. Our current SMTP AUTH process
uses SASL ("Simple Authentication and Security Library", although there's
little simple about it). "


This is a misnomer. It's entirely possible to use TLS *and* SASL on the same mail server. In fact, I do it myself. Having both allows you to do interesting things, such as only allowing encrypted (Digest, CramMD5, etc) authentication when your are using an unencrypted channel, and if you do use an encrypted TLS/SSL tunnel, allowing plain-text authentication (PLAIN or LOGIN).

My initial reaction is, if it ain't broke why
fix it. But if this is a better solution, then I'm willing to approve it.


I certainly share this perspective in a lot of respects, but don't forget that systems do require maintenance, and occasionally overhauls, to keep the daily maintenance to a minimum. A real big concern I would have, which you didn't expressly mention in your email, is the ease with which those two systems can be updated. The older RH system is going to require a good bit of care and feeding by hand. It's probably running an older kernel which is not fit for allowing local user-level access (privilege escalation bugs, etc). If it's not running that older kernel, then it's definitely a headache to manage because you've (at some point) had to either roll your own RPMs for a lot of stuff, or move away from the package manager in not-so-small ways. The Debian alternative your admin is proposing will allow for much easier upgrades of individual packages (think security and small features), as well as major distribution upgrades (think not having to make this choice again, in so substantial a way). Debian is much more capable of upgrading from an old Woody or Potato based system, to a modern distribution such as the current testing branch, Sarge, or even SID (not recommended). RedHat and it's derivatives are not so flexible.

To speak to Jason's particular recommendation that local user accounts might be preferable, I'm going to take a guess. You've probably got centralized authentication going either via an Active Directory domain, or something else that ties your various machines together (probably not Kerberos/LDAP or I doubt you'd move away from it). Because of that, it's not likely that you'll be able to implement local user accounts in a reasonable fashion.

Also to touch on another topic that wasn't directly mentioned - the (presumed) change of POP/IMAP server from (probably) UW-IMAP to Courier. You didn't mention what the old system runs, which I'll guess means you're using the default for RH, which was UW-IMAP back in the 7.x days. Courier is a bit more complicated, conceptually, but the benefits are well worth it in my opinion. Courier's benefits shine with virtual users and domains in particular, because it allows you to virtualize accounts entirely. There is no required relationship between a login account, and an email account. Make sure your admin understands how to make the migration work (the mail is stored very differently in the two types of mail systems), and make sure he understands the difference between procmail and Sieve rules (and how to migrate those as well). I imagine if he's proposing this solution, it's been tested at least to some degree - so these issues are probably all covered, but I would be burying my head in the sand if I didn't at least mention it in passing.

Personally, I've been recommending SquirrelMail over Neomail lately - but I wonder if anyone else has any thoughts on that. Anyone on the other side of the coin who prefers Neomail to SquirrelMail?

Aaron S. Joyner
System Administrator
Triangle Linux User's Group
Intrex.net Internet Services
--
TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
TriLUG Organizational FAQ  : http://trilug.org/faq/
TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
TriLUG PGP Keyring         : http://trilug.org/~chrish/trilug.asc

Reply via email to