Emails werent going through to POP accounts on our webserver. I checked the queue with qmail-qread and there were lots of emails queued. How do I get them from the queue to their respective mailboxes? and why would this happen?
Thanks
Off-topic. It should be posted to Mail Server forum instead.
>> Emails werent going through to POP accounts on our webserver
Your concept doesn't make sense. Message not delivering has nothing to do with POP. qmail is mail server, not a webserver.
>> How do I get them from the queue to their respective mailboxes?
So that's a local mail delivery problem.
>> and why would this happen?
Because you either haven't told qmail which deliver method to use or the mailbox format or its permission was incorrect.
To fix this problem, you need to make sure your /var/qmail/rc file matches your local delivery method. Say you have:
that is to tell qmail to deliver to /home/username/Maildir/new directory.
Since I don't know which local delivery method you have chosen, if you haven't created your /var/qmail/rc file, you need to select one from /var/qmail/boot, then copy it to /var/qmail/rc.
Anyway, you better fix this ASAP or all your messages will be bounced when its queuelifetime is reached.
There also is a maildirmake command to create the /home/username/Maildir directory automatically.
Sorry that didn't make much sense did it:
I am running a SUSE linux box, with qmail, and vpopmail. It has been working fine up until yesterday, and has just stopped delivering to the mailboxes now. They all exist etc, and I havent chagned the config, so do I still need to look at what you mention above?
Thanks
qmail is highly configurable, so without sufficient info from you, there is no way to figure out what the problem was.
1) How many domains do you have?
2) Have you specified --enable-default-domain when compiling vpopmail?
3) What dirs can you see in /home/vopmail/domains right now? If you don't see your domain dir there, you need to run /home/vpopmail/bin/vadddomain to create a domain dir structure, then vadduser for each user.
>> It has been working fine up until yesterday
Then your /var/qmail/rc part should probably be okay.
>> so do I still need to look at what you mention above?
Yes. To troubleshoot problem, you should start from scratch. For local delivery problem, start from what I told you to do previously.
Then check /home/vpopmail/domains/domain.com structures, make sure the permissions are correct.
You also need to make sure your /home/vpopmail/domains/domain.com/vpasswd.cdb file is not corrupted. Try to add a new user and see if its coredump.
Ok, the rc file is as follows:
#!/bin/sh
# Using stdout for logging
# Using control/defaultdelivery from qmail-local to deliver messages by default
2) Unfortunately I did not compile vpopmail so I don't know, sorry.
3) All the domains are there, and were working fine previously. What should the permissions be set to in the /home/vpopmail directory (this could be the cause as we had some permission problems yesterday, and these may have been inadvertently reset)? Also if I reset these, will the mail then be delivered or do I have to force it somehow?
Thanks
Your rc file should be fine, since vpopmail supports Maildir only.
>> 2) Unfortunately I did not compile vpopmail so I don't know, sorry.
You still can find out the configur options by checking /home/vpopmail/include/vpopmail.h and vpopmail_config.h files. Check and see if #define DEFAULT_DOMAIN "domain.com" is defined.
>> What should the permissions be set
Owner should be vpopmail and group should be vchkpw, except symlinks dir such as mail.domain.com from domain.com dir at /home/vpopmail/domains/*
Here is the directory layout + permission for /home/vpopmail:
drwx------ for all dirs
-rw------- for all hidden files
If the permissions were correct, then rebuild vpasswd.cdb from vpasswd for each domains.
BTW, is it a problem to all domains or just particular domain?
>> if I reset these, will the mail then be delivered or do I have to force it somehow?
Yes and automatically immediately. Do it sooner or else, as I said, they will be bounced back to envelope sender.
Firstly, yes it is a problem for all pop domains, no mail is being delivered, all remains in the queue. Sending mail is fine, but it is the local delivery of the mail that is failing.
Ok I have changed all the permissions and checked the mail queue again and it remains the same. I don't think I need to reset passwords as when you collect mail with a MUA it connects fine but collects nothing (as there is nothing in the mailbox).
Starting to get a bit worried now, because as you say it will soon be deleted!
My define default domains in /vpopmail_config.h reads as follows:
#define DEFAULT_DOMAIN ""
So I guess not defined then.
Any other ideas??? Can I not somehow push the mail into the correct boxes? (I'm getting despeate here!)
Cheers
>> Ok I have changed all the permissions
So they weren't correct earlier?
>> checked the mail queue again and it remains the same
Send ALRM signal to qmail or restart it.
>> Can I not somehow push the mail into the correct boxes?
You can't. Don't even attempt to mess with the queue manually or qmail may break and all messages will be /dev/null plus you need to recompile qmail from scratch.
If you are trying to remove certain messages in the queue or to repair it, there are many scripts to do such cleanup task (go to http://www.qmail.org/top.html).
>> #define DEFAULT_DOMAIN ""
Then the username you enter to check mails with MUA is the email address, not just username. But that's not the issue since messages are being stuck in queue.
If after sending ALRM signal doesn't help still, check another file: /var/qmail/users/assign, then rebuild it so it refreshes your cdb file. Basically these all cover local mail delivery topics in qmail.
Still no joy, but thanks anyway.
One last thing:
"You also need to make sure your /home/vpopmail/domains/domain.com/vpasswd.cdb file is not corrupted. Try to add a new user and see if its coredump."
I will add a new user but I don't understand "see if its coredump" - what does this mean?
Thanks again.
ok, got it moving now!
I believe it was a combination of privileges problems, then I restarted qmail and qmail-injected. Left it injecting for a long time and it seems to have done the trick.