At 10:46 AM -0400 7/19/06, Gerard wrote:
For what its worth, I just had a mbox size of 12M on one account. Not
extremely large by any standards. Using 'qpopper' the download failed as
it usually does with a large mbox size near or over 10M. I immediately
changed to 'popa3d' in the inetd.conf file and restarted it. Now, when I
attempted to download the email messages it proceeded without incident.
I firmly believe that there is an inherent flaw in qpopper that has gone
unfixed for quite some time. It does not effect everyone, or perhaps
every OS, but it is there. Unfortunately, the developers do not seem
interested in getting to the root of the problem. A simple Google search
will turn up others who have experienced the exact same sort of problem
that I have. It is even mentioned in the 'fetchmail' manual.
I'm not aware of any such bugs. I'm very happy to look into them,
but I'd appreciate if anyone who experiences this and suspects a
Qpopper bug could help by reproducing with Qpopper tracing and/or
kernel tracing using truss(1), ktrace(1), or whatever is used on your
platform.
To enable tracing in Qpopper:
1. Do a 'make clean'
2. Re-run ./configure, adding '--enable-debugging'.
3. Edit the inetd.conf line for Qpopper, adding '-d' or '-t <tracefile-path>'.
4. Send inetd (or xinetd) a HUP signal.
(Steps 3 and 4 are only needed if you use inetd (or xinetd). In
standalone mode, you can add '-d' or '-t <tracefile-path>' to the
command line directly.)
(In either standalone or inetd mode, if you use a configuration file
you can add 'set debug' or 'set tracefile = <tracefile>' to either a
global or user-specific configuration file instead of steps 3 and 4.)
This causes detailed tracing to be written to the syslog or to the
file specified as 'tracefile'.
