[no subject]

G> ------------------------------------------------
G> To enable tracing in Qpopper:
G> 1. Do a 'make clean'
G> 2. Re-run ./configure, adding '--enable-debugging'.
G> 3. Edit the inetd.conf line for Qpopper, adding '-d' or '-t tracefile'.
G> 4. Send inetd a HUP signal.
G> This causes detailed tracing to be written to the syslog (if you used '-d') 
G> or to the file specified as 'tracefile'.

G> You might want to put this Qpopper on a different port, and configure the 
G> receiving Eudora to use that port.
G> ------------------------------------------------

This is a very viable solution.  Grab the source from
http://www.eudora.com/qpopper/, read the included docs, and compile it
with debugging turned on.

To use the debugging version, one way would be to run it over the spop
port through inetd (unless you're already running spop).  Stuff a line
like the following into inetd.conf:

spop3 stream  tcp  nowait  root  /path/to/debug_popper  qpopper -f /path/to/debug_qpopper.conf
(above should be all on one line)

Modify the /path/to/debug_qpopper.conf to (optionally) include:

set    debug        =true
set    tracefile    =/path/to/tracefile

Restart inetd and tell your client that's having problems to switch
their MUA to pull mail from port 995.  Then inspect both the maillog
and the tracefile.

Alternatively, you can run qpopper as a standalone daemon if you so wish.
Instructions are included with the source.

G> Does anyone know if Qpopper was originally configured with debugging turned 
G> on?

I wouldn't think so.  Whenever you run a daemon in a "production"
environment, you usually don't want debugging due to unnecessary
overhead.  You would see additional output by qpopper every time
someone connected to port 110 if debugging was compiled in, even if
it's not being triggered by the necessary switches or config options.

G> Anyone having any thoughts or suggestions?

See first paragraph.

-- 
Best regards,
 Brian Curtis