Re: [fetchmail] fetchmail: incorrect header line found while scanningheaders
2003-09-16 17:02:02
Paul M Foster wrote:
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.
If we're still talking about the same problem that I posted the patch for:
I suddenly started seeing this happen with messages forwarded from my
Intel work account some time in August (not spam). My assumption is that
these invalid header lines result from a configuration change to Intel's
MS Exchange servers.
Rather than engage in a futile effort to get Intel IT to investigate and
change their configuration, I thought it more productive to change
fetchmail to tolerate the message format.
MS Exchange, with all its quirks, is a fact of life, and we just have to
live with it.
I'd appreciate it if someone who understands that section of code better
than I, could come up with a more solid solution.
Philip J. Tait
|
|