Volker Kuhlmann followed up,
| Yes, I am positive that procmail does not work as procmailrc.1 says.
| DEFAULT=$MAILDIR/inbox #completely optional
| [...]
| :0:
| $DEFAULT
|
| Delivers to $MAILDIR/inbox. Commenting out the last recipe, causing a
| fall off the end delivers to the system mailbox.
I truly swear to you that the documented behavior is what I have seen in
every version of procmail I've used since the 2.7x days. There's something
anomalous happening to you there.
| I have never changed ORGMAIL. The file $DEFAULT is writable or delivery
| to it would file with an explicit last recipe.
You mean fail?
When you deliver explicitly to $DEFAULT like that, procmail probably doesn't
stop to think that the variable it is expanding to get the name of the folder
is $DEFAULT; it just sees it as text. It's only when procmail knows that it
is delivering to $DEFAULT that it refuses. Is $DEFAULT a symlink, perchance,
or a plain file with more than one hard link? Those are supposed to be unac-
ceptable as $ORGMAIL, so perhaps they are also unacceptable for a fall-off-
the-end save to $DEFAULT.
| This behaviour is the same in procmail 3.10.
And it worked as advertised for me in 3.10 as well.
| Setting both ORGMAIL and DEFAULT to a file other than the system mailbox
| still delivers to the system mailbox.
Is it either an existing plain file that is not a symlink and has only one
hard link or a nonexistent name in a writable directory?
| I do not think this is a problem, but it would be nice if the man pages
| could be corrected.
I *do* think it is a problem. Something is awry. Er, you aren't invoking
procmail with the -m option, are you? That might explain some of the
trouble (it would leave ORGMAIL unset).