Installing Dovecot? - please advise...

[nhouse]

Hi Folks... I have been having a BEAR of a time dealing with POP3 mail the last few days and I pray that someone here will be able to give me some guidance. I hope you don't consider this message as "double posting" because it involves some different issues... and I really didn't get much feed back on this post (http://www.directadmin.com/forum/showthread.php?t=17637). Let me give you the general run down on my situation:

vm-pop3d is failing at random times but this seems to be getting worse.
it doesn't "appear" that DA is restarting the service every time
I am getting a TON of entries in my system message log that look like this "Mar 12 15:08:18 webserver PAM_pwdb[5700]: check pass; user unknown" Some sort of attack maybe?
I don't believe that anything major has changed on the system except that I did upgrade DA to the current 1.29.2 version before this started happening... probably a coincidence.


Ok, I have seen lots of posts telling people in my situation to switch to Dovecot... the only question I have with that solution is this... If my issue is with POP3 connectivity is some other issue, well then will Dovecot be my Knight in Shining Armor, so to speak. If you have experienced similar issues as I have AND you switched to Dovecot, were you pleased with the results? I REALLT appreciate your input. Also, as you can see in my signature, I run a modest CentOS 4.3 box and I have vm-Pop3d 1.1.7f-DA-2 and Apache 1.3.37. If I switch to Dovecot, is there anything I should be aware of that could be a "zinger" based upon my system setup?

[skruf]

Hey,

Whether it solves any of your problems or not, Dovecot is the way to go...

Just follow DA's instructions and you should be OK.

They are here if you haven't already seen them:

http://www.directadmin.com/features.php?id=590

David

[nhouse]

Hey, David... thanks... anyone else have some input?

[jlasman]

We were very happy with our switch to Dovecot. We've made the switch on all our servers and on many of the servers we've managed.

The one reason to not switch is if you've got lots of available space in /var and not enough in /home, as Dovecot will start keeping email in /home.

There are some other issues; for example if you have an OS Distribution with quota turned on in /home but not in /var, then suddenly your users' mailboxes will start counting against their system-enforced quotas, and if they run out of space they may not be able to accept email.

Find my other post on Dovecot in the past few days to see more.

But in general, do it if you can.

It may or not solve the problems. If it doesn't, then you'll know they weren't caused by your POP daemon.

Jeff

[nhouse]

Jeff... thanks again for your insight. Is there a simple way to check on the "quotas" thing? I will also review your other posts...

[jlasman]

It depends a lot on what OS Distribution you run (we run CentOS). CentOS and Red Hat Enterprise Linux both by default set up quotas for the /home partition if there is one.

I suppose any distribution will let you run
quota -u <username>
to see the quotas for <username> (replace <username> with the actual username, but without the brackets) for each partition that has quotas turned on.

The resolution is a combination of giving your clients more space if they need it, and a bit of education; letting them know that their email space now comes out of their total space allocation, as it always should have :) .

Jeff

[nhouse]

I agree.... some end users somehow think that their email accounts are an endless bucket. This server is CentOS 4.3.

I ran the command on one of my accounts and it gave the following result:
Disk quotas for user cpcenter (uid 507):
Filesystem blocks quota limit grace files quota limit grace
/dev/mapper/VolGroup00-LogVol00
178860 768000 768000 9190 0 0

Would this mean that quotas are turned off?

[jlasman]

See man quota to learn what it all means :) .

Blocks and files are separate sections. Files are unlimited (generally that's what you want).

Blocks are limited to 768,000. I don't know how large a block is on your filesystem but the easiest way to find out is to compare it with the number you've set for the disk space quota.

Your user is using 178,860 blocks of the 768,000 he's allocated.

I don't know what partition(s) are in /dev/mapper/VolGroup00-LogVol00; you can generally tell by running:
# df -h
Jeff

[nhouse]

The results of that are:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
72G 6.9G 61G 11% /
/dev/hda1 99M 9.0M 85M 10% /boot
none

I'll also look at the man pages

[pucky]

There are some other issues; for example if you have an OS Distribution with quota turned on in /home but not in /var, then suddenly your users' mailboxes will start counting against their system-enforced quotas, and if they run out of space they may not be able to accept email.



Not sure how you do business or what your requiements are but in our world if the user runs out of disk space then we expect, and so do they, that their email will stop functioning. Isnt this the standard?

[nhouse]

Well, yes... we do have expectations as to the space limits of our clients. My intention was to check with other folks here about their experience with switching to Dovecot and potential miscues that could be made. For me personally, there always seems to be a difference between following a set of instructions and the real world result... ;)

[jlasman]

The results of that are:
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
72G 6.9G 61G 11% /
/dev/hda1 99M 9.0M 85M 10% /boot
none
Everything is on one partition.

Jeff

[nhouse]

Ok, a comment and a question...

First, I finally converted to Dovecot via the instructions in the DA knowledgebase and things went smoothly. This seems to have resolved the issues I was experiencing with vm-pop3d and does make mail retrieval MUCH faster for my clients.

Now, for the question... in the tutorial within the DA knowledgebase, the "clean-up procedure says to run the following command:
3) Make sure that dovecot is running. Take a few days to ensure that everything is working correctly. Once satisfied, you can clean the old mbox files by typing:

echo "action=delete&value=mbox" >> /usr/local/directadmin/data/task.queue

Just for clarification, does this clean-up run "one time" from the queue? I assume this must call some command to delete ALL of the old mailboxes (mbox) and this is a one time process. Am I right?

Thanks! So far so good!

[jlasman]

Yes. That's what it does.

Jeff

[nhouse]

Thanks big guy!

[jlasman]

Thanks big guy!
Hmmmm... big guy!

Is that like what my father mean when he always called me young man, even when I was well into my 50s ;) ?

Jeff