On Thu, Oct 20, 2011 at 04:51:23PM +0200, Krzysztof Krzyżaniak wrote: > On 20.10.2011 16:25, Carlos Carvalho wrote: > > In a 32bit machine one user cannot access his email through popa3d. > > The message in the log is > > > > Oct 19 09:24:31 hoggar popa3d[25622]: Authentication passed for<user> > > Oct 19 09:24:31 hoggar popa3d[25622]: Failed or refused to load > > /var/mail/<user> > > > > Access is fine for the other pop users. This user works fine with > > imap. I suspect it's a file size problem, because his spool is a > > little over 2GiB. > > > > Is popa3d limited to 2GiB file sizes? > > Yes, from params.h > > /* > * Introduce some sane limits on the mailbox size in order to prevent > * a single huge mailbox from stopping the entire POP service. > * > * The defaults are rather large (2 GB filled with messages as small as > * 1 KB each). It is recommended that you decrease MAX_MAILBOX_MESSAGES, > * MAX_MAILBOX_OPEN_BYTES, and MAX_MAILBOX_WORK_BYTES to, say, 100000, > * 100000000 (100 MB), and 150000000 (150 MB), respectively, if that > * would be sufficient for your users. > */ > #define MAX_MAILBOX_MESSAGES 2097152 > #define MAX_MAILBOX_OPEN_BYTES 2147483647 > #define MAX_MAILBOX_WORK_BYTES 2147483647
So reported issue not a bug, just a defined limit. It looks to me that the source code is *not* safe for 64-bit file offsets in 32-bit archs. However, the limit above is a compile-time limit and described by the author as extreme, recommending a shorter maximum be applied downstream. In practice mailboxes this size seem likely to be Maildir, not mbox, and I understand that the upstream author would be considering applying the Maildir patch in any new releases [1]. That said, it would be nice to fix as a code quality/resilience improvement. Shall we reclassify as wishlist? [1] https://github.com/openwall/popa3d/pull/2#issuecomment-3203873730
