Bug#1710: popclient can't read my mail box

[Ian Jackson <ian@chiark.chu.cam.ac.uk>]

Andrew Howell writes ("Bug#1710: popclient can't read my mail box"):
> popclient fails to read my mailbox whether the following error
>
> [kryten:/home/andrew] popclient -u andrew localhost
> Enter mailserver password:
> kryten POP3 Server (Version 1.004) ready.
> cannot open mailbox /var/spool/mail/andrew

This would appear to imply that popclient has been compiled to dump
mail in the standard incoming mailbox by default.  However, I see from
the manpage:

       The retrieved  messages  are  normally  appended  to  your
       default  system mailbox on the local disk, using the local
       Mail Delivery Agent (MDA),  usually  /usr/bin/mail(1),  so
       that  when  you  invoke your mail reader it can manipulate
       the retrieved messages like any other mail you receive  on
       the client machine.

       Using  the  -o  option,  you  can specify a different mail
       folder to which the retrieved messages will  be  appended.
       If  you  prefer, for example, to have your POP mail from a
       machine called 'mailgrunt' stored in the mbox file in your
       home directory, you would start popclient as follows:

              popclient -o $HOME/mbox mailgrunt

       Note  that  the  folder specified with -o is not locked or
       otherwise protected from other  processes  writing  to  it
       while popclient is writing to it.

I don't find this reassuring.  Could the popclient maintainer please
check that the correct locking *is* done for the system mailbox (it
doesn't imply that it isn't, but it doesn't say that it is), and then
document this ?

If it does lock the mailbox correctly you may well find that the
problem with `popclient localhost' is that popclient and in.pop3d are
clashing over the lock on the mailbox.  `popclient localhost' is an
inherently silly thing to do.

Furthermore, the manpage coontains the following example, which
purports to describe how to use the `-c' (squirt to stdout) option
safely:
              popclient   -k   -c   mailgrunt   |   myfilter
                  > $HOME/filtered.mail
       followed by
              popclient -c mailgrunt > /dev/null

This won't work correctly, because it has a race condition.  It would
appear that there is no safe way to use the -c option except in
conjunction with the -k option.  Could this fact be documented,
please ?

I'm pleased to see, though, that popclient appears to spot write
errors on the output file.

Thanks,
Ian.