Re: [fetchmail-users] feedback on failed delivery

[Matthias A. <mat...@gm...>]

Thomas Wolff <to...@to...> writes:

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

That is exactly what happens: fetchmail builds up the line, prints the
sizes of header and body, flushes the line so that --showdots can work,
and then encounters a problem shipping the fetched message out to the
MDA. This error message triggers the flush of a line without LF, then
the error message. There is no easy way to figure if LF needs to be
printed before the problem message, and this is not the time for
sweeping changes. I looked into the problem, and more than 100 code
lines need to change. That is a full days work for a cosmetic change,
I'm not ready to do that now.

Please file your --mda /bin/false example with a stripped-down set of
output examples (one for each of the two error messages is probably
sufficient, SIGPIPE vs. MDA exit) to the bug tracker at BerliOS.de so we
don't forget about the bug.

-- 
Matthias Andree