I am trying to set up mutt with fetchmail and procmail on server space that's not mine. I have access to /home/myusername but not to /var/spool/myusername. Everything seems to work well, but I
have no idea where fetchmail (or procmail) is dropping off my mail. If
I use this .fetchmailrc file:

then fetchmail doesn't complain at all but I can't find the mbox that
my mail's been downloaded to. If I use this .fetchmailrc file:

fetchmail complains:

having lines such as these in my .procmailrc file didn't help at all:

As far as the black-holing of mail, have a look at the output of the 'env' command and look for: MAIL=/
Caveat, look for any .forward files in the home directory that are forwarding your mail 'elsewhere'. You may not be able to change the path as you want, but you should be able to find where it's going with that.

I've had a similar issue today myself with 'vanishing' mail. For a moment it reminded me of Exchange...... chuckle...

It doesn't help. I've tried to change MAIL to /home/myusername/mail, but procmail still tries to create /var/spool/mail/myusername, but it doesn't have permission to do so (I am not the superuser). env reads MAIL correctly as /home/myusername/mail, but the complaint

persists, and my mail is nowhere to be found. No .forward files.

When I had my issue this is how I debugged it and the notes I made to 'self' - they may help you.

First thing to note, if mail is trying to be delivered to the wrong place, either your .procmailrc file is missing (not in the right place - /home/user/.procmailrc), not named correctly (missing . at the start), has incorrect directives that stop it doing what you want or is not being read for some reason.

The first thing I would do is backup your current .procmailrc and create a fresh test version containing the correct directives for your system.

First make a note of your shell:
Next we want the system default mail directory. I've noticed myself that some systems have the mail directory listed in the environment variable '$MAILDIR', others don't have that variable but instead have '$MAIL'. Using the wrong one in .procmailrc will fail. You can find it like this:

Next, for ease and testing, say we want to redirect all mail to /home/user/newmailbox. We need to make sure that directory exists or it will fail:

With this information and the directory in place to take our mail, create a fresh .procmailrc file with debbuging enabled:
Rather than wait for mail to come in, create a simple text file test message called 'message.test'....


The cat or less it through procmail for 'user' and see what happens:

*assuming your procmail is in /usr/bin/procmail - find it with 'which procmail' if not.

The debug info should help if things go wrong, but you will hopefully see something like 'You have new mail...' pop up on the cli. Check the contents of /home/user/newmailbox looking for the test message:

I hope that helps, or gets you closer to a fix.