Re: [fetchmail-users] feedback on failed delivery

[Thomas W. <to...@to...>]

About the stdout/stderr merging issue with error messages I made some 
experiments as I had been asked to.
Fetchmail was always invoked without additional option (no verbose 
mode), .fetchmailrc defines "mda false".
With some variations in invoking fetchmail, I got all kinds of order 
of appearance of the 4 messages. Below you find some examples.

Please also note my later remarks on the messages themselves.


-------------------------------------------------------
Local invocation seems to produce a stable result:
>> fetchmail
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets)  (5 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a
>fetchmail: Query status=2 (SOCKET)


With an stdout pipe, it looks quite weird:
>> fetchmail | cat
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets) ...fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a
> (5 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: Query status=2 (SOCKET)


With simple remote fetchmail, I even got 3 different versions:
>> rsh ... fetchmail
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets)  (5 body octets) fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a
>fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: Query status=2 (SOCKET)

>> rsh ... fetchmail
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets)  (5 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: Query status=2 (SOCKET)
>fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a

>> rsh ... fetchmail
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets)  (5 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a
>fetchmail: Query status=2 (SOCKET)


With a remote stdout pipe, it looks quite weird again (like with local pipe):
>> rsh ... "fetchmail | cat"
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets) fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a
> (5 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: Query status=2 (SOCKET)

But not always:
>> rsh ... "fetchmail | cat"
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets)  (5 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: Query status=2 (SOCKET)
>fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a


Joining stderr with stdout can stabilise the result:
>> rsh ... "fetchmail 2>&1"
>1 message for deblnss01a/demsn702 at blnss35a.
>reading message deblnss01a/demsn702@blnss35a:1 of 1 (903 header octets)  (5 body octets) fetchmail: SIGPIPE thrown from an MDA or a stream socket error
>fetchmail: socket error while fetching from deblnss01a/demsn702@blnss35a
>fetchmail: Query status=2 (SOCKET)

So we would have the local appearance again.


-------------------------------------------------------
Some comments about the messages themselves:

They are now (6.2.9-rc9) actually the same as with 6.2.9-rc5, when 
I had commented:
> If you look exactly, you find MDA mentioned and can draw your conclusion, 
> but it's not really while "reading" the message or while "fetching" it 
> (at least it's not in the process of fetching, so this is confusing), 
> and it's not a socket error either, I think.

While with 6.2.9-rc8 there was a much different and better message:
> 1 message for deblnss01a/demsn702 at blnss35a.
> reading message deblnss01a/demsn702@blnss35a:1 of 1 (3257 header octets) ... (2542 body octets) ..fetchmail: MDA returned nonzero status 255
>  not flushed

So why does rc9 revert to the confusing previous messages here?

Also, in either case, the indication of the MDA as the cause is quite 
hidden in the far end of a line. It should really be ensured to be 
a separate line.
In this respect I don't understand your comment:

From: Matthias Andree <mat...@gm...>
> > Now it's:
> > > 1 message for deblnss01a/demsn702 at blnss35a.
> > > reading message deblnss01a/demsn702@blnss35a:1 of 1 (3257 header octets) ... (2542 body octets) ..fetchmail: MDA returned nonzero status 255
> > >  not flushed
> > which is fine. Just make it better visible by putting the error notice 
> > on a new line.
> 
> Well - fetchmail is actually behaving as was originally intended. It
> prints the error message at the earliest possible time, and the "not
> flushed" is a consequence of the error.
The message would not be printed significantly less early if you just 
flush stdout first as there is no noticeable delay and no error situation 
to be expected by that. This flushing would do the safety of the error 
message no harm - it would in contrast ensure its logically correct 
placement and its reliable appearance and thus improve the user feedback.


Kind regards,
Thomas Wolff