On Tue, Jun 29, 2010 at 16:16, /dev/rob0 <rob0@gmx.co.uk> wrote:
On Tue, Jun 29, 2010 at 07:28:52AM -0400, Charles Marcus wrote:
On 2010-06-28 9:05 PM, Stan Hoeppner wrote:
I guess this is different with virtual users than with system users? Are you using virtual or system users Charles?
Virtual of course... doesn't everyone? ;)
Virtual mailboxes have their place, of course, but they're overused, especially at small sites. I suppose this might be in part because most HOWTOs are for virtual.
I recently saw someone asking for help, having set up a "simple" server with virtual mailbox (yes, singular) and mysql! The querent was trying to add a SECOND account and did not know how!
And what do the MySQL proponents say about that?
I started into mail on a very small scale, and that approach served me well. I set up Postfix by reading the comments in main.cf; later when I got the idea that I might want POP3 or IMAP, I uncommented lines in inetd.conf (popa3d I think, and uw-imap), and they worked. When kids got old enough to use email, adduser[1] and there they go.
It's nice you had that. Most of the mail servers I did in the past didn't even have POP (users logged into a shell account to read mail). Only recently did I even get into IMAP. IMAP was new to me, as was Dovecot (obviously). Not so with Postfix (or Sendmail, for that matter ... but I won't go back there). Oh, and I tried Qmail for a short stint.
I didn't get into virtual mailboxes until later, on a job, and when I did, I knew enough to question the wisdom of it. Why did we need this additional authentication database? All our users were using Samba via system accounts too. It could have been all integrated! The "advantages" I was told of doing it the virtual way were all based on misunderstandings. (One common one: "I don't want mail users to have shell access." Giving them a shell of /bin/false and/or setting sshd_config(5) access controls does the job.)
If there is one domain, and each user has an email name matching shell names, that's fine. Use system accounts and shells of /bin/false or whatever. But once you have more than one domain, it is possible to have collisions. This can happen with company mergers. User "jsmith@companya.com" and "jsmith@companyb.com" could be two different people who need to continue working with their original email addresses, while the former companies operate as business units under a single merged mail server.
There are two (or more) different kinds of virtual, too. One involves mapping multiple users of different domains into distinct system usernames which are not necessarily the same as the LHS of their email address. Now a mapping has to be made, and IMAP logins aren't as straight forward for users (one user logs in as "jsmith" and the other logs in as "jsmith2" ... and what if the 2nd J. Smith is the one that takes the reins as CEO).
The other is usually called virtual, but I personally don't, since I consider it to be real. I have:
mail_location = maildir:/home/mail/%Ld/%Ln/mail
I don't see that as any more or less virtual than where every user has a shell account and the config reads:
mail_location = maildir:/var/spool/maildir/%Ln
I don't think of that as virtual because the user names and domains are unchanged (I'm now counting lower casing the names).
I think many if not most of the questions we see on these lists are from people who have made a bad choice of using virtual mailboxes, often as a direct consequence of that choice.
Are you referring to all kinds of virtual? Or just some? Which sets of terminology are you using?
Personally, I consider it a bad choice when email addresses are mapped to system users, where LHS doesn't always match the shell user name. I consider it bad because of the confusing maintenance involved. The other two methods (username@justonedomain with mailboxes literally owned in the filesystem by the user ... or the way I do it now with multiple domains and the mailboxes literally owned in the filesystem by a designated role system user) I consider to be OK.
Email grew up with Unix, so it's no accident that Unix shell usage has very nice integration with email. Probably a lot of the folks reading this list would not even need an IMAPd if they knew more about these things.
And it also grew up working with either one domain, or multiple domains having a completely joint user set.
But mail can also function just fine when the MAIL USERS are completely isolated from the SYSTEM USERS. That doesn't mean doing this makes sense for everyone. But it can make sense for many (multiple domains and disjoint username sets).
I often encounter frustrated newbies who tried to do the whole thing all at once. It makes much more sense to start off small, throw in the relational databases later, learning the finer points of how to manage your OS along the way. The secret is that you can have a fully-functional mail server with very little bother, using system accounts. Postfix (or other MTA) and Dovecot will pretty much Just Work, right out of the box.
For learning mail servers, that might make sense. For setting up a mail system for a business with multiple disjoint domains (merged businesses, ISPs), it usually doesn't. OTOH, such a setup shouldn't be done by a beginner, either.
[1] adduser is a Slackware-specific frontend wrapper script for useradd(8) and other tools from the shadow package.
And, Slackware is, IMHO, a better choice (or FreeBSD or OpenBSD ... Gentoo might be OK, too). I used Ubuntu on mine most recent one due to it being a complete business startup and many other servers were being set up at the same time and which server would do what hadn't been established. I've already begun the plans to migrate to Slackware64 for the mail server and web server, with the core service software (Apache, Dovecot, PHP, Pike, Postfix, Python, and a few others) built from the latest source.