[Dovecot] some basic questions
Simon Waters
simonw at zynet.net
Thu Jun 29 10:47:05 EEST 2006
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 at xyz.com> and <joy at 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 ;)
More information about the dovecot
mailing list