Re: Failure to POP mail

At 6:48 PM -0400 6/19/06, Gerard E. Seibert wrote:

>  OS: FreeBSD 6.1 Stable
>
>  I am not sure if this is a qpopper problem or not. I have several 
> accounts that I use 'fetchmail' to gather for me. One of these 
> accounts can grow quite large. All too frequently, when I attempt 
> to POP mail from this account from another computer on my network, 
> the action fails. This is the message I find in the 
> /var/log/messages file:
>
>  Jun 19 18:21:50 seibercom qpopper[2839]: I/O error flushing output 
> to client spamcop at boss [192.168.0.3]: Operation not permitted (1)

I think that generally means the client has disconnected, often 
because it timed out, and Qpopper never got a SIGHUP.  Are you 
running the latest Qpopper?  There were some bugs fixed that closed 
some situations in which Qpopper didn't get the signal.

>
>  'spamcop' is the name of the account and 'Boss' is one of the 
> computers on the network.
>
>  If I attempt to open the file with 'pico' I receive an error 
> message that the file has a long line.

You normally wouldn't expect a spool to have lines that long.  That 
does suggest some sort of corruption.

>
>  Does anyone have any suggestions as to what is happening here and 
> how to rectify it?

You could enable Qpopper tracing and/or use truss(1), ktrace(1), or 
similar tool on the popper process, to try and see what is going on.


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'.