[Dovecot] system v. virtual mailboxes, was Re: Thunderbird problem

[Phil Howard]

On Tue, Jun 29, 2010 at 16:16, /dev/rob0 <rob0 at 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 at companya.com" and "jsmith at 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 at 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.