Empty IMAP inbox

Why did you set up the account initially with a wrong password? If you wanted to avoid Mail connecting to the server until you had set the IMAP Path Prefix, I don’t think it would make a difference, but a better way to accomplish that would be bypassing the Account Setup “Assistant” altogether by holding the Option (Alt) key down when clicking the [+] button in Preferences > Accounts, unless you’re setting Mail anew, in which case the Account Setup “Assistant” cannot be avoided. Is this the only account you have set up in Mail?

The only things I’m aware of that could have a bearing on this is the account being offline or any custom rules you may have. Is the Mailbox > Go Online command enabled or disabled?

Open Window > Activity Viewer and tell Mail to check for mail on this account. What do you see there?

Look for additional information that may be available in the form of error messages written to the Console:

1. Open /Applications/Utilities/Console.

2. From the File menu, choose either Open Console Log, or Open System Log, or both, so that Console displays the contents of both system.log and console.log.

3. Reproduce the problem and look at the bottom of the Console windows for messages that might be written there as a result.

<hr>
Try this to check whether the problem is system-wide:

1. Go to Apple Menu > System Preferences > Accounts and create a new user account for testing purposes.

2. Either log out of your main user account or just quit Mail so that it does not interfere with the other user account.

3. Log in as the newly created user and set up Mail anew there.

4. For spam-related security reasons, go to Preferences > Viewing and disable Display remote images in HTML messages if it’s enabled.

5. Check whether the problem also happens when logged in as another user.

I am perhaps seeing something similar with a POP connection:

I running tiger 10.4.10 on an PPC machine, either a recent uptate from 10.4.9 or the security upgrade 2007-006 has disrupted my Mail.app Version 2.1 (752/752.2)'s ability to download mail from a POP3 server. This is the only account I have now linked to Mail. The connection doctor states that the connection and login to server succeded. Using account info, I can see hundreds of new messages on the server that I cannot download in the inbox, (also webmail access to the same account demonstrates these messages are there in the inbox). There are no freezes or hangs and I am certain that there is no problem on the POP3 server end--I can use the same exact POP settings on my older panther mail.app or my iphone and it new email is retrieved fine.

The one error I have been able to detect is this is the console log with a timestamp that corresponds to every time I try to "get mail":

2007-07-09 18:59:27.345 Mail[312] -[POP3Connection fetchMessages:] failed: NSError Domain=MFMessageErrorDomain Code=1033 UserInfo={NSLocalizedDescription = ""; }

I do not see any error logged to /var/log/mail.log

I have tried all manner of rebooting, and even deleted the com.apple.mail.plist file in my ~/Library/Preferences/ and reset up teh account (I get the same exact behavior and error in the console.log).

This problem first stated after the upgrade to 10.4.10 and the security patch 2007-006 was installed

Any Ideas?

I'm having a very similar problem with Mail.app 2.1.1 (752.3) and IMAP against a Dovecot mail server. All IMAP mail that I've procmail'd off on the server-side into a separate location ~/ImapMail is available, but no message bodies from my Inbox are available (Mail.app does occasionally display a plausible message count for the Inbox). The Inbox is in a separate location from the rest of my IMAP folders -- Dovecot announces both locations to MUAs.

I do not have this problem with mutt or offlineimap against the same Dovecot server (I have two other offlineimap processes running against this same mail store).

In console.log on my MacBook desktop, I see quite a few of these two lines:

2007-07-30 18:08:51.819 Mail[12950] Unhandled response to command SELECT: * NO Mailbox is locked, will abort in 30 seconds

2007-07-30 18:10:50.421 Mail[12950] Unhandled response to command STATUS: * NO Mailbox is locked, will abort in 270 seconds

These messages repeat, counting down every 30 seconds. Googling shows that the "NO ..." messages are coming from Dovecot, I assume in response to the STATUS and SELECT requests by Mail.app. However, I can't confirm or deny that these responses actually pertain to my Inbox (since incoming mail or my other offlineimap processes could just as easily be locking any of my mailboxes).

I've tried moving aside my ~/Library/Mail/IMAP-.../INBOX.imapbox, and the Mailbox -> Rebuild feature, both to no avail. I've also experimented with setting the Accounts -> Advanced -> IMAP Path Prefix, which of course makes all my non-Inbox folders disappear, without putting any mail in my Inbox.

For some reason, the error lines didn't show up in my previous post (maybe it was the leading whitespace?). Trying again w/out date/time stamps, and adding another MUA command attempt:

Mail[12950] Unhandled response to command STATUS: * NO Mailbox is locked, will abort in 270 seconds
Mail[12950] Unhandled response to command SELECT: * NO Mailbox is locked, will abort in 30 seconds
Mail[12950] Unhandled response to command UID FETCH: * NO Mailbox index is locked, will abort in 45 seconds

I seem to have a related problem. I've been using Mail with my IMAP account at work for a few years with no issues. At some point in the last few months (unfortunately, not sure when--perhaps when upgrading to a MacBook Pro from my old Aluminum PowerBook), sending mail has become erratic.

The SMTP server is properly set up, and other email applications have no trouble sending mail with it. But at random times, Mail will suddenly choke and refuse to send email. Console shows the same message over and over again:

2007-07-31 12:51:16.894 Mail[303] Unhandled response to command SELECT: * NO Trying to get mailbox lock from process 27134

Elliot, if those messages are coming from your IMAP server (as they are for me), they're probably unrelated to a failure to send mail.

I recommend examining the mail log file for your outgoing SMTP server (or having your IT department or ISP do so for you), and cross-referencing recent log entries with your outgoing email failures.