On Monday 25 November 2002 12:02, Sunil Shetye wrote:
Quoting from Gerd v. Egidy's mail on Sun, Nov 24, 2002 at 02:41:23AM +0100:
fetchmail: POP3> RETR 1
fetchmail: POP3< +OK 62984 octets
fetchmail: reading message XXX:1 of 3 (62984 octets)
fetchmail: message delimiter found while scanning headers
fetchmail: message XXX:1 was not the expected length (1122 actual !=
fetchmail: SMTP>. (EOM)
fetchmail: smtp listener protocol errorfetchmail: not flushed
fetchmail: POP3> RETR 2
fetchmail: POP3< Content-Type: text/plain; charset=iso-8859-1
This means that the previous claim of message delimiter found is
yes, that is correct. That message header contained the MIME-boundary which is
without a colon.
2) If there is a header line without a colon, fetchmail sets the
headers_ok flag to FALSE, does not continue reading, and returns
PS_TRUNCATED. Thus, the remaining header and body is not read at all.
As I understand that, your patch is orthogonal to mine.
If we return PS_TRUNCATED and have a protocol that cannot differentiate
between header & body, we have to get the whole message - even if we don't
want to. That is what my patch does.
Your patch improves detecting the actual message delimiter.
So both patches should be applied. Is that correct?
Kind regards & thanks for your patch,