Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Although I marked my previous thread as solved (assuming I was now more in the realms of problems with the iphone itself), I don't seem to be able to resolve this one.
My Phone keeps reporting
Cannot Get Mail
The connection to the server failed
My phone does seem to show (all?) the contents of my home directory so must have received some data but no actual mail.
In debug.txt, this keeps repeating over and over:
Found 0 message changes
Initializing message diff engine
1 messages in state
This looks like a problem of imapd using the old mailbox format, instead of the more recent mbx that supports simultaneous access.
Read this to see how to create an mbx, or transform existing mailbox to mbx.
And of course you need to configure procmail, or whatever program you use to deliver mail to users, to deliver in mbx format (I guess you need to configure it to use dmail as in FAQ)
Once again, you could spare yourself a lot of frustration if you install a recent distro, with courier-imap or dovecot for imap server and postfix (that natively supports maildir format) as the smtp server.
You've been and continue to be a big help but, are you quite sure about this? I LIKE traditional unix mailboxes where I can vi any problems etc. out and, as I said, there are no other imap clients accessing the mail.
As you can tell, I'm a little nervous about risking breaking anything that is currently working well.
I've googled "imapd lost mailbox lock" and came out that the mailbox format is the problem. I guess your device is trying to access multiple times the mailbox resulting in this error.
If you're afraid breaking your system, you can create a new account with a mbx mailbox and try to use your device on this account.
Note: if you're using (the Slackware default) sendmail, you'll need a ~/.procmailrc calling dmail to deliver mail.
Many thanks. I tried converting one mailbox to mbx (after having saved a copy of it) and outlook (using imap) couldn't find any mail. I'm sure I did what the hyperlin (and man page) suggest. So I.ve reverted back to the copy.
I tried the default as per the suggestion i.e. creates a file called INBOX as that didn't work, I tired again telling it to create a file called mbox. Neither worked with outlook/imap.
I also saw a suggestion to make imap look in a sub folder (Mail) but I cant see where that is an option anywhere.
I've told you a couple of times, that you need to configure procmail (I assume you use sendmail to get mail and procmail to deliver it to users, as it's the default for Slackware) to use dmail, so it can deliver mail to a user's mbx formatted mailbox.
Sorry. Please excuse my misunderstanding. I did see you say that but I assumed a CONVERTED mbox would contain all the original email (It's certainly big enough to) and that Outlook using imap would thereore still be able to see the mail. Had that been the case, I would have had more confidence to proceed with the conversion.
As I (thought) I was testing existing rather than new email, I didn't realise I needed to change sendmail at that stage.
From what I've read about uw-imapd, I think that you first need to create INBOX, running as the user you want:
Code:
imapd
1 create #driver.mbx:INBOX
2 logout
Note that you need to type the numbers in front of the imap commands.
Then to transfer the existing mailbox into INBOX, you'll need "mailutil append" to copy mail from old to new mailbox. Again as that user, run:
From what I've read about uw-imapd, I think that you first need to create INBOX, running as the user you want:
Code:
imapd
1 create #driver.mbx:INBOX
2 logout
Note that you need to type the numbers in front of the imap commands.
Then to transfer the existing mailbox into INBOX, you'll need "mailutil append" to copy mail from old to new mailbox. Again as that user, run:
Code:
mailutil append /var/mail/USERNAME INBOX
This is really spooky. After all this time, today my email clients suddenly started reporting that my mailboxes were all empty!
Remembering this thread, I ran the mailutil command above (except I told it to append my mbox contents) and, guess what. I now have all my read email back!
I think I just need to complete the last step - getting new mail in var/spool/mail to be delivered to the INBOX file. I'm not all that clear on how to do that. I know it needs something like a ~.procmailrc to call dmail (as suggested above - can't see that whilst writing this) but, what does it have to contain? I seem to recall configuring sendmail is a bit of a nightmare.
I seem to be stuck with going down this approach now so any help would be much appreciated.
I think I just need to complete the last step - getting new mail in var/spool/mail to be delivered to the INBOX file.
If you're using the appropriate client it should be done automatically. Quoting from the link above:
Quote:
f you create an mbx-format INBOX, by creating "#driver.mbx/INBOX" (note that "INBOX" must be all uppercase), then subsequent access to INBOX by any c-client based application will use the mbx-format INBOX. Any mail delivered to the traditional format mailbox in the spool directory (e.g. /var/spool/mail/$USER) will automatically be copied into the mbx-format INBOX and the spool directory copy removed.
In fact I can confirm this behavior with pine.
If your client cannot do this, you need a ~/.procmail (or /etc/procmailrc if you want to do this for all users) containing:
Code:
:0
*
| /path/to/dmail +INBOX
Change the /path/to/dmail accordingly
Normally you don't need to mess with sendmail, if you're using the stock sendmail that comes with Slackware, as it's already configured to use procmail to deliver mail.
Note that you can also use tmail instead of dmail. In this case delivery to INBOX is done for all users and you need to edit sendmail.cf. Read tmail manpage for details.
If you're using the appropriate client it should be done automatically. Quoting from the link above:
In fact I can confirm this behavior with pine.
If your client cannot do this, you need a ~/.procmail (or /etc/procmailrc if you want to do this for all users) containing:
Code:
:0
*
| /path/to/dmail +INBOX
Change the /path/to/dmail accordingly
Normally you don't need to mess with sendmail, if you're using the stock sendmail that comes with Slackware, as it's already configured to use procmail to deliver mail.
Note that you can also use tmail instead of dmail. In this case delivery to INBOX is done for all users and you need to edit sendmail.cf. Read tmail manpage for details.
Thanks so much.
I did read that somewhere. However, I did actually work out what the .procmailrc file should contain (almost identical to what you have suggested). I am getting some strange behaviour. LOCAL mail from the server does indeed get delivered to the INBOX file (but only when the .procmailrc file is present), external email still goes to the old /var/spool/mail/USER file and stays there.
It should be the same regardless of internal or external mail. Unless you use something else to get external mail (like getmail, fetchmail etc).
You may enable procmail logging in ~/.procmailrc. To do so, add before anything else the following:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.