fetchmail-friends
[Top] [All Lists]

Re: [fetchmail] SIGPIPE on an extraordinarily big e-mail

2002-10-27 22:25:10
Quoting from Peter Grace's mail on Fri, Oct 25, 2002 at 11:44:00AM -0400:

I think the best thing to do would be to ltrace fetchmail. And the
smtp server!

fetchmail: SMTP> DATA
fetchmail: SMTP< 354 Enter message, ending with "." on a line by
itself
fetchmail: SMTP>. (EOM)

This is weird. There is no response from the smtp server to EOM. This
means that there is a read error here. smtp_response must be "",
smtperr must be 0.

fetchmail: SMTP> RSET

RSET is sent by fetchmail only on errors. I think handle_smtp_report()
must have been called just before sending RSET with the empty
smtp_response.

Again, there is no response from the smtp server to RSET.

This is probably a fetchmail bug. handle_smtp_report() should not be
called if there is a read error from the smtp server.

 not flushed

handle_smtp_report() must have returned PS_TRANSIENT which is the
default return value.

fetchmail: POP3> TOP 2 99999999
fetchmail: POP3< +OK 45753 octets
reading message username(_at_)mail1(_dot_)netreach(_dot_)net:2 of 3 (45753 
octets)
fetchmail: SIGPIPE thrown from an MDA or a stream socket error

SIGPIPE has been delivered at this point even though there is no smtp
transaction going here. This is probably some delayed signal!

In short, there seems to be some mismatch between the closing of the
smtp socket and the delivery of the SIGPIPE signal. Why this could be
happening is unclear.

Attached is a patch which might fix this.

Sunil Shetye.

Attachment: fetchmail-6.1.1-smtpreaderror.patch
Description: Text document