[fetchmail]"Message delimiter found while scanning headers" bug analyzed

Hello,

I, like a previous poster
(see http://lists.ccil.org/pipermail/fetchmail-friends/2002-May/002055.html),
have hit the bug that occurs when the POP termination string occurs
just after the headers. Now, I don't know whether it's legal for an
MDA to store body-less messages in mailboxes (but since such messages
are permitted in RFC 2822, it probably is), but for a POP3 client
it's not unusual to terminate such messages after the last header has
been transmitted, without the following CRLF (which simply isn't
there, as per RFC 2822).

Now, fetchmail has the following two pieces of code.

In readheader():

            /*
             * Check for end of message immediately.  If one of your folders
             * has been mangled, the delimiter may occur directly after the
             * header.
             */
            if (protocol->delimited && line[0] == '.' && EMPTYLINE(line+1))
            {
                has_nuls = (linelen != strlen(line));
                free(line);
                goto process_headers;
            }

here, headers_ok should be assigned FALSE for clarity, but it's
FALSE anyway, so that it results in the PS_TRUNCATED error code
and the warning message.

But then, in fetch_messages():

            /* 
             * Read the message headers and ship them to the
             * output sink.  
             */
            err = readheaders(mailserver_socket, len, msgsizes[num-1],
                             ctl, num);
            if (err == PS_RETAINED)
                suppress_forward = retained = TRUE;
            else if (err == PS_TRANSIENT)
                suppress_delete = suppress_forward = TRUE;
            else if (err == PS_REFUSED)
                suppress_forward = TRUE;
#if 0
            /* 
             * readheaders does not read the body when it
             * hits a non-header. It has been recently
             * fixed to return PS_TRUNCATED (properly) when
             * that happens, but apparently fixing that bug
             * opened this one here (which looks like an 
             * inproper fix from some ancient thinko)
             */
            else if (err == PS_TRUNCATED)
                suppress_readbody = TRUE;
            else if (err)
                return(err);
#else
            else if (err && err != PS_TRUNCATED)
                return(err);
#endif

(eek, a switch() would probably be optimized better)

Why the suppress_readbody flag is itself suppressed here?
Can somebody unravel the sloppy code (you advocate for
open source with THIS?) for me?

-- 
Stay tuned,
  MhZ                                     JID: mookid(_at_)jabber(_dot_)org
___________
You have an ambitious nature and may make a name for yourself.