fetchmail-friends
[Top] [All Lists]

Re: [fetchmail]malformed header problem in IMAP fetch

2001-11-08 09:13:09
Paul <paul666(_at_)mailandnews(_dot_)com>:
I've been having an occasional problem with fetchmail, where a "problem"
mail causes fetchmail to abort and causes a backlog. Usually, I solve
the problem by using the web front end to the mail server, reading the
mail and then deleting it. I finally decided to track the problem
down and discovered this:

fetchmail-5.9.3/transact.c:484

            if (!isspace(line[0]) && !strchr(line, ':'))
            {
                headers_ok = TRUE;
                has_nuls = (linelen != strlen(line));
                free(line);
                goto process_headers;
            }

The problem occurs due to the header missing the white space
continuation character(s) required. i.e.
References: foo(_at_)bar foo(_at_)baz
foo(_at_)bim

There seem to be a few problems with handling this anomaly that
I don't think are handled very well:

Is it an oversight that headers_ok is set to TRUE, when the headers
certainly aren't ok?

No. I've looked at the code, and headers_ok==TRUE is not a guarantee that
the headers are RFC822 well-formed.
 
Would it not be better to emit some diagnostic in this case, and also if
readheaders() returns before processing fetchlen characters?

How about a --add-probably-missing-whitespace (or something :) option
if ":" delimiter is missing (which is what I did as a workaround) and
if we haven't read fetchlen yet?

How about an option to skip or delete problem mails?

The generic problem here is that somwhere upstream, part of your mail
chain is generating broken headers.  Fetchmail cannot be expected to deal
with all such cases gracefully, and there is a narrow limit on the amount
of crocks I am willing to put in the code to make it try.  Your proposal, 
I am afraid, exceeds it.  You should fix whatever is broken in your mail chain
instead.
-- 
                <a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>

Our society won't be truly free until "None of the Above" is always an option.


<Prev in Thread] Current Thread [Next in Thread>