I 'm guessing the problem might have to do with improper recognition of the
EOM (End of Message) string during communication between Fetchmail and the
MTA. What I suspect is that the binary stream of the pictures just happens
to have a string of characters in it that looks like an EOM, fooling the MTA
into thinking the message is fully transferred.
I have noticed this same problem with 6.2.2 (no info about 6.2.3 yet),
and I was also unable to determine a clear cause of the problem.
In my case the message contained several image attachments, and the
received message was also about 82 KB. It seems a bit unlikely that
our two instances would truncate at about the same point, if the cause
was just some random sequence of bytes in the input ????
=S.Coffin
GV Computing
scoffin(_at_)comcast(_dot_)net