[Dovecot] some basic questions
I'm seeking a small IMAP server, and dovecat was recommended by those more savvy than me. (The sign on my monitor is "My programming language is solder..") so I'll be getting help to deploy this, but first...
I've read through the wiki docs but still have questions, ones likely too obvious for most readers....
There will be <100 users, the platform will Debian, and I need IMAP/PO over SSL/TSL and locally-hosted Squirrelmail [unless someone has a better webmail client...]. Other boxes here run postfix, so that is a first choice.
Clients will be Eudora, maybe TBird/Apple mail; no M$ Outlook.
A) I need multi-domain support, with joe@xyz.com and joy@qbc.net being separate users.
B) I have a problem with storage-abusers & really want the carrot-stick quota system my favorite ISP, Panix, has. You get N bytes {or messages, I can live with either/both} and when you get near, you get nagged until you solve it.
When you exceed quota, you get no more incoming mail, just nagging. It's shunted aside until you make room. After D days, if it's still there, the shunted mail is returned.
Regular reports as to who's naughty and nice would be great.
C) Password changes. How can I have user-changable pw's, with crack/sanity checking of the new ones? Do I have to have accessible shell accounts on the box for each user? [argh]
D) Spam: assume I can run spam-assassin and have it move suspected mail into a Junque mailbox; true?
E) Non-guru creation/deletion of accounts: It appears from "Virtual Users" that this is possible via a text file, but I'm not sure...
Comments?
Tere.
I've read through the wiki docs but still have questions, ones likely too obvious for most readers....
There will be <100 users, the platform will Debian, and I need IMAP/PO over SSL/TSL and locally-hosted Squirrelmail [unless someone has a better webmail client...]. Other boxes here run postfix, so that is a first choice.
Dovecot will do fine all this.
Clients will be Eudora, maybe TBird/Apple mail; no M$ Outlook.
No problems with them, just use client workaround -s in conf file.
A) I need multi-domain support, with joe@xyz.com and joy@qbc.net being separate users.
This is MTA, not dovecot question.
B) I have a problem with storage-abusers & really want the carrot-stick quota system my favorite ISP, Panix, has. You get N bytes {or messages, I can live with either/both} and when you get near, you get nagged until you solve it.
When you exceed quota, you get no more incoming mail, just nagging. It's shunted aside until you make room. After D days, if it's still there, the shunted mail is returned.
Regular reports as to who's naughty and nice would be great. Don't know about reporting, but I think this is again MTA question.
C) Password changes. How can I have user-changable pw's, with crack/sanity checking of the new ones? Do I have to have accessible shell accounts on the box for each user? [argh] This is general, not dovecot question.
D) Spam: assume I can run spam-assassin and have it move suspected mail into a Junque mailbox; true? This is MTA, not dovecot question.
E) Non-guru creation/deletion of accounts: It appears from "Virtual Users" that this is possible via a text file, but I'm not sure...
I think, that also this is general, not dovecot question.
-- Sysadmin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
David wrote:
I'm seeking a small IMAP server, and dovecat was recommended by those more savvy than me. (The sign on my monitor is "My programming language is solder..") so I'll be getting help to deploy this, but first...
I've read through the wiki docs but still have questions, ones likely too obvious for most readers....
There will be <100 users, the platform will Debian, and I need IMAP/PO over SSL/TSL and locally-hosted Squirrelmail [unless someone has a better webmail client...]. Other boxes here run postfix, so that is a first choice.
I don't use postfix, but I have basically the same setup using dovecot.
Clients will be Eudora, maybe TBird/Apple mail; no M$ Outlook.
A) I need multi-domain support, with joe@xyz.com and joy@qbc.net being separate users.
although I personally don't do this (for lack of need, really), it should be doable. You'll want to make sure that whatever back-end you're using for postfix to support multi-domains is configured appropriately for dovecot as well. (for example, if you're using LDAP or MySQL backend for virtual user support in postfix, you'll want to use the same for dovecot) someone with more experience in this should probably offer more details.
B) I have a problem with storage-abusers & really want the carrot-stick quota system my favorite ISP, Panix, has. You get N bytes {or messages, I can live with either/both} and when you get near, you get nagged until you solve it.
I personally use filesystem quotas. with this, if the user goes over quota they are no longer able to receive email. my current setup will permfail incoming mail if the system is unable to store it with an error stating "user over quota." this is my preference.
I also wrote a custom script (which is basically just like warnquota, only supports Japanese text) to run twice daily to check users' quota usage and send them email if they're over their soft limit. users over the hard limit or beyond the grace period no longer receive mail and thus don't get those nagging emails either. the script also sends a summary report to my sysadmin account.
(this specifically has nothing to do with dovecot or any other IMAP/POP server however)
When you exceed quota, you get no more incoming mail, just nagging. It's shunted aside until you make room. After D days, if it's still there, the shunted mail is returned.
if you use dovecot LDA (deliver) then this is the default (possibly non-configurable) behavior. deliver returns a TEMPFAIL if it cannot write the new mail to user's storage device. this is at least the case for filesytem quotas. if you're going to have strictly virtual users, you'll need to use something like maildir quotas which may have different behavior.
Regular reports as to who's naughty and nice would be great.
you'll likely need to write your own script(s) to do this, depending on how you implement quotas. this specifically has nothing to do with the IMAP/POP server however.
C) Password changes. How can I have user-changable pw's, with crack/sanity checking of the new ones? Do I have to have accessible shell accounts on the box for each user? [argh]
To my knowledge, dovecot (or rather, most IMAP/POP servers) does not handle password change requests. I know that early versions of Eudora had a "Change Password" option, I'm not sure if that's still there but that option is not common in modern email clients.
You'll need to choose your user management tools properly according to your needs. (i.e. do you use LDAP or MySQL for your backend database? what types of management tools are provided with each? will you have to provide your own tools? etc)
D) Spam: assume I can run spam-assassin and have it move suspected mail into a Junque mailbox; true?
this only applies to dovecot if you're using dovecot-LDA (deliver) as your local delivery agent. and only if you're using its sieve support to do server-side pre-processing of your mail. Otherwise, this is specific to your MTA/LDA
E) Non-guru creation/deletion of accounts: It appears from "Virtual Users" that this is possible via a text file, but I'm not sure...
you can use a passwd style text file as your authentication backend with dovecot, but the question is will your MTA (postfix?) support that for accepting mail? probably not. so you'll need to look at other common options (such as LDAP or MySQL) and what tools they provide for user management.
if you create system "real" users, you could use this passwd style text file solely for IMAP/POP authentication. by doing this you could prevent shell logins by having completely different passwords (or possibly just having the real account disabled while allowing authentication for IMAP/POP access separately)
It's not the cleanest solutions, but I personally just create real user accounts on my system (i don't have the need to distinguish by domains however) with a shell that prevents logins but allows IMAP/POP connections. I then use a plugin to squirrelmail to allow the users to change their passwords. As stated before, i use filesystem quotas and some custom scripts for reporting/nagging.
HTH
Alan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEoyshE2gsBSKjZHQRAjsLAJ4qVDR56asT5oS+L4typ5tH7pgv+QCg5OVj qVyUsxMOZ1HI9bAQU2yECpE= =9xws -----END PGP SIGNATURE-----
On Thursday 29 Jun 2006 02:21, alan premselaar wrote:
I don't use postfix, but I have basically the same setup using dovecot.
I do, and there is a nice how-to for Postfix/Dovecot/MySQL in the Wiki I believe.
A) I need multi-domain support, with joe@xyz.com and joy@qbc.net being separate users.
although I personally don't do this (for lack of need, really), it should be doable. You'll want to make sure that whatever back-end you're using for postfix to support multi-domains is configured appropriately for dovecot as well.
I do -- see the how-to.
I personally use filesystem quotas. with this, if the user goes over quota they are no longer able to receive email. my current setup will permfail incoming mail if the system is unable to store it with an error stating "user over quota." this is my preference.
I think the "over quota then defer temporarily" is a mistake. Since it will queue overquota email in the queue, and no one but the admin will know where it is. Either reject it out right, or deliver it and moan at people who are over quota. Heck if Google can give a couple of Gigabytes to people...
I don't do quota's, it is generally a feature of the mail delivery agent. I think Maildrop can do it with virtual users and Postfix, but I've not done this.
Go for the "we'll delete the oldest mail first if you are over quota" would be my advice.... but go carefully and back it up first ;) This is relatively easy with maildir.
C) Password changes. How can I have user-changable pw's, with crack/sanity checking of the new ones? Do I have to have accessible shell accounts on the box for each user? [argh]
Depends where you store the username/password. I've stuck it in a Postgres database, and would need to write a little web application to allow this.
D) Spam: assume I can run spam-assassin and have it move suspected mail into a Junque mailbox; true?
Please don't do this. "Junk" folders for stuff you aren't sure on will be a place where real email rots, or users waste time. Reject the spam as promptly as possible, and let the sender sort out false positives -- harsh but I think the right thing. The alternative is the sender thinks it is read, and the receiver quietly ignores it, and email is perceived as unreliable.
Try this article I wrote here and see if you still feel the need; http://www.debian-administration.org/articles/168
E) Non-guru creation/deletion of accounts: It appears from "Virtual Users" that this is possible via a text file, but I'm not sure...
you can use a passwd style text file as your authentication backend with dovecot, but the question is will your MTA (postfix?) support that for accepting mail? probably not.
Postfix is very happy making a hash out of simple text files for users or virtual users -- but I'd recommend the database approach myself - far more flexible.
Of course you put stuff in a text file, you likely have to write the tools to do the password change as well in that text file. We have one system where the text files are written from the database - for added complexity ;)
B) I have a problem with storage-abusers & really want the carrot-stick quota system my favorite ISP, Panix, has. You get N bytes {or messages, I can live with either/both} and when you get near, you get nagged until you solve it.
I personally use filesystem quotas. with this, if the user goes over quota they are no longer able to receive email. my current setup will permfail incoming mail if the system is unable to store it with an error stating "user over quota." this is my preference.
Politicaly, this will not fly. The big offender is the PHB.
When you exceed quota, you get no more incoming mail, just nagging. It's shunted aside until you make room. After D days, if it's still there, the shunted mail is returned.
if you use dovecot LDA (deliver) then this is the default (possibly non-configurable) behavior. deliver returns a TEMPFAIL if it cannot write the new mail to user's storage device. this is at least the case for filesytem quotas. if you're going to have strictly virtual users, you'll need to use something like maildir quotas which may have different behavior.
I'm still trying to grok the +/- aspects of virtual users...
C) Password changes. How can I have user-changable pw's, with crack/sanity checking of the new ones? Do I have to have accessible shell accounts on the box for each user? [argh]
To my knowledge, dovecot (or rather, most IMAP/POP servers) does not handle password change requests. I know that early versions of Eudora had a "Change Password" option, I'm not sure if that's still there but that option is not common in modern email clients.
It is there....
You'll need to choose your user management tools properly according to your needs. (i.e. do you use LDAP or MySQL for your backend database? what types of management tools are provided with each? will you have to provide your own tools? etc)
All open questions... One thing that occurs to me a giving them shell accounts, but making the shell 'passwd'
It's not the cleanest solutions, but I personally just create real user accounts on my system (i don't have the need to distinguish by domains however) with a shell that prevents logins but allows IMAP/POP connections. I then use a plugin to squirrelmail to allow the users to change their passwords.
better!!
Thanks...
On Jun 29, 2006, at 6:11 PM, David wrote:
I'm still trying to grok the +/- aspects of virtual users...
I think the whole idea of system vs. virtual users is kind of stupid
and the problem between deciding between them is really only about
lack of proper tools to deal with them. The only two differences
between them are:
Each system user has their own UID in kernel side. With virtual
users they usually share one UID.System users are listed in /etc/passwd, or wherever nsswitch.conf
tells to look for them..
From security point of view the more different UIDs the users have
the better. Then it's also the kernel which guarantees that users
don't go looking into others' mails. The only real downside to this
is that there are only 65536 different UIDs usually, so with large
systems you can run out of them.
Dovecot or the kernel doesn't care about users being in /etc/passwd,
so as long as you have proper tools to allocate UIDs it's simple to
do that from Dovecot's point of view. I think there should be more
tools in this area that can handle the UID allocation easily for
Dovecot's userdb. If you allocate UIDs 2000 and larger to virtual
users you shouldn't have a problem with adding system users either.
participants (5)
-
alan premselaar
-
David
-
Simon Waters
-
Sysadmin
-
Timo Sirainen