Suppose you have just set up a medium sized vhost mail system, using Courier / maildrop, spamc / spamd, assorted helper tools and your choice of AV software.
Everything works fine, even those brain-dead bash snippets you are using to move mail from outside-world IMAP domains to the local servers: spam is spam, viruses are viruses, ESMTP doesn't leak.
The world is all rainbows and green fields of grass.
Then, drip. Drip. DRIP.

Checking the logs you find an enlightening (what?) message:

maildrop: Unable to create temporary file

You also notice that messages get deferred.
You call up mailq who says 17 messages are queued.
Ah, ok, I know your tricks - you think.
You check for the usual dot-lock stuff, mailfilter errors. None to be found.
You go command line and send a quick-test mail:

$ mailx -s “Whattafsck” user@domain
Why oh why you do not move on?
Unqueue yourself, please.
.

And now, at this point, things go colourful crazy.
The log says that delivery succeeded. The message is there in the maildir.
You call up mailq again: now there are 19 messages in the queue, but not that one, obviously.

You turn to Google, but searches provide no meaningful clue. You check Sourceforge.
Everybody knows about dot-lock. Everybody has temporary failures.
Everybody has a maildrop horror-story but nobody nowhere never ever had problems with maildrop being unable to create temporary file.

This is where the fun begins. The queue tide rises. Keeps rising and rising.
Since there is no time to patch, you are left wondering on one of those great mysteries of coding: what insights was unable to create temporary file supposed to provide to those in trouble?
What file? Where file?
It looks like sticking a name and location in that log entry was so damn un-l33t. Usability what?

And, since bitterness comes up itself like a bad tide, please, why there is no (apparent, I'll concede) mention of default directories either in maildrop's or Courier's documentation or faqs?

Resourceful as you are, you try logging. You learn quite fast that logging is absolutely useless.
One message goes through, ten stop by. Deferred. The queue keeps rising.
Damn. Think. Damn. This can't be random, there has to be a pattern. Unseen. Giggling. Think.
Fiddling with Courier configuration files in search of some obscure TRAPMAILDROP variable, it suddenly occurs to you to use those old blessed Unix tricks-of -the-trade.
Aren't we piping messages to maildrop? Ok, so let's put something equally useless but meaningful in between. And catch the little bastard.
You change the maildir directive in the courierd file to output to /tmp/whatfsck.log, and there you go. The solution is there, clear as the first light on a summer sunrise:

Cannot write to /tmp/whatfsck.log: permission denied.

Beg your pardon?
Quick check: /tmp/ is owned by root and is rwx-------. Whatthefsck?

So: everything small enough to be handled the RAM-path got delivered. Everything else took the disk path and got stuck. Dandy.

The point here is: whoever installed the base system had some weird ideas as regards the use of the /tmp/ directory, or installation got screwed up some way; plus, checking even the obvious sometimes pays off.
But: more meaningful messages (on maildrop's part) and some more information on defaults (in Courier's docs) would have resulted in half the struggle and half the mess.