Subject: pkg/31836: popa3d can cause mailbox corruption
To: None <,,>
From: Pavel Cahyna <>
List: pkgsrc-bugs
Date: 10/16/2005 16:06:00
>Number:         31836
>Category:       pkg
>Synopsis:       popa3d can cause mailbox corruption
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Oct 16 16:06:00 +0000 2005
>Originator:     Pavel Cahyna
>Release:        NetBSD 3.0_BETA
System: NetBSD beta 3.0_BETA NetBSD 3.0_BETA (BETA) #4: Fri Oct 7 21:20:07 CEST 2005 root@beta:/usr/src/sys/arch/alpha/compile/BETA alpha
Architecture: alpha
Machine: alpha
popa3d doesn not use lockfiles to lock mailboxes, it relies on flock()
call. This is a design decision: see, section Locking.

Unfortunately, many other mail software don't use flock() call. For
example the default "mail" command on some systems, or mutt compiled
from pkgsrc with default options.

The situation is especially bad on IRIX, where sendmail as distributed
by SGI or compiled from source does not use its own mail.local command
for mail delivery, but the system /bin/mail, which relies on lockfiles
only. This lead to a mailbox corruption in less than one week after we
started using popa3d on IRIX.

We didn't use popa3d from pkgsrc, it was locally compiled, but pkgsrc
should have the same problem, as it does not contain any patch or

To add insult to the injury, the short description says:

"Secure, reliable, performant, and small pop3 server"

The reliability claim is bogus, as in the referenced design document,
the upstream author clearly states: 
"This is where I choose security over either functionality or reliability."

Install popa3d on a busy IRIX mail/POP server. Wait.
I think that the problem is serious enough to remove popa3d from
pkgsrc. If it is not desired, at least, it should be marked as only
for platforms where the default MTA uses flock(). This won't fix
interaction with mail readers, but people usually don't read mail with
local MUA and POP simultaneously. This would still be quite fragile,
because if you compile another MTA which does not use flock(), the
problem will reappear, so some big warning should be added to
MESSAGE. The reliability claim should be removed from the package's