fetchmail-friends
[Top] [All Lists]

Re: [fetchmail] fetchmail: incorrect header line found while scanningheaders

2003-09-16 15:56:22
On Tue, Sep 16, 2003 at 12:00:42PM -0400, Mathieu Bouchard wrote:


On Sun, 14 Sep 2003, JoeHill wrote:

On Sun, 14 Sep 2003 22:47:16 -0700
Dragoncrest <dragoncrest(_at_)voyager(_dot_)net> uttered:
         Any idea if this "patch" will become part of the code for the
         next
installment of Fetchmail?  I'd like to get this problem nipped in the
bud once and for all if possible.  I'd do the patch now, but I don't
have the time or patience to fuss with it at the moment.
check the list archives. the problem isn't with Fetchmail, it's with
ISP's using Bad Things, ie. non-compliant header tags or such.

I can't tell what the problem is just by looking at the headers, but in
recent times I've had a dozen non-spam mails that got rejected. Actually
this rejects more non-spam mail than spam mail; and in addition the
non-spam mail seem to come from rather ordinary mailservers, through
mailing-lists run by mailman, with a bunch of linux-based subscribers.

So I wonder where the problem really comes from, but it appears that if
something is to be fixed, it's likely to be fetchmail. I can't comment
very much on that because I have no actual experience with mail standards,
but still, I've had rejected mail from many different places, and so I'm
not convinced that the problem is _all_ of those other servers at once.
(Or can it be related to clients sending the mail? How come all of those
servers let the mail pass through?)

I've used fetchmail for years without problems, until about the beginning
of this summer I think.

FWIW, I've only seen this on spam. From some reason, some mail programs 
(or whatever) are adding headers that don't follow the standards (i.e. 
they aren't valid headers, aren't supposed to be there). What I've often 
seen is that whatever is creating the mail will put in the headers, then 
neglect to put a blank line in, and simply start right in on the message 
itself. This makes any message content below the headers and prior to 
the first blank line appear to be invalid header information.

Paul