update: ORGMAIL sanity check doesn't take MAILSPOOLSUFFIX into account

Yesterday I posted this to the procmail users' list, and I had a couple more
thoughts about it:

> My main email account has just been restructured by the ISP.  It now is
> a maildir structure on a different partition from my home directory; a
> symlink in my home directory points to the physical location.  As the
> physical location may be moved at the ISP's whim (and they'd accordingly
> update the symlink), I am supposed to access it through the symlink.
> 
> If I recompile procmail so that MAILSPOOLHOME is "/symlink" or
> "/symlink/", then no matter what the value of MAILSPOOLSUFFIX, the
> sanity check on $ORGMAIL finds the symlink, dislikes it, renames it to
> BOGUSsomething, and creates a brand new maildir by that name, residing
> physically under my $HOME and not pointing to my real maildirs.  Then I
> have to put things back manually.  If I recompile procmail with
> MAILSPOOLHOME set to "/symlink/./", then it works, and MAILSPOOLSUFFIX
> can be null, but then procmail -v and lockfile -v have funny output with
> "/./" where you'd expect just "/" instead.

> I've not yet tried MAILSPOOLHOME="/.maildir/." with MAILSPOOLSUFFIX="/",
> in part because I'm concerned that $ORGMAIL wouldn't pick up the suffix
> and would, unless redefined in /etc/procmailrc or ~/.procmailrc, act as
> an MH-style directory.

Since then, I did.  It also renamed the symlink and re-created the 
directory, and moreover lockfile -ml created ~/symlink/..lock with two 
dots.  However, for deliveries procmail did honor MAILSPOOLSUFFIX and 
treat the new directory as a maildir.

> Apparently things work only when MAILSPOOLHOME points to the physical
> path to the directory, or at least its last element does.
> 
> I guess I could call procmail with -m and set ORGMAIL in ~/.procmailrc,
> but that's not a great solution either.
> 
> Any suggestions?

It occurs to me that a patch to the code (which I don't know how to 
write) would fix it: if $ORGMAIL is a symlink that resolves to an 
existing directory where the process can create files, declare the 
sanity check successful, don't rename anything to BOGUSwhatever, and 
don't create a new directory under $ORGMAIL's name.  If it is a symlink 
to a file or to an unwritable directory, or if it is a hard link to a 
file with any othe hard links, by all means rename it and create a new 
$ORGMAIL.