From_ lines within the message body can confuse the archiver

[Axel Thimm]

This is on mailman 2.1.12 as shipped by Fedora 12.

The following From line in a message body caused the mail to have been properly distributed, but was split in two in the archiving part:

=== Quote start
I think this would be a fairly common set up? Indeed I have three machines
that are setup this way (1 has 2 fans, the other 2 have 3 fans)

>From what I can see, pwmconfig does this:

pwm1_enable=0
pwm2_enable=0
=== Quote end

I'm not sure whether the From line was actually escaped or not when mailman was processing it, as the copy I received went through exim/dovecot-lda, and I think at least exim does fix unescaped From lines.

The mail above was split into the following in the mbox archives (http://lists.lm-sensors.org/pipermail/lm-sensors/2010-August.txt.gz):

=== Quote start
I think this would be a fairly common set up? Indeed I have three
machines that are setup this way (1 board has 2 fans, the other 2 have
3 fans each)

From <email address hidden> Thu Aug 12 18:07:19 2010
From: <email address hidden> ()
Date: Thu, 12 Aug 2010 16:07:19 -0000
Subject: No subject
Message-ID: <email address hidden>

pwm1_enable=3D0
pwm2_enable=3D0
=== Quote end

The html archives are truncated in a similar fashion.

I don't have the original mail, but I suspect that it was missing Lines/Content-Length headers and therefore the possibly unescaped From line was bogus. Still, if mailman was smart enough to ship the mail as a whole it should be properly filing it into the archives as well. Also, why is there an mbox splitting during archiving in the first place?

Thanks!

[Mark Sapiro (msapiro)]

Lines/Content-Length headers mean nothing to Mailman.

Clearly, Mailman received a message with an embedded, unescaped From_. The question is why was the From_ not escaped in the archiver. Standard GNU Mailman 2.1.12 does escape the From_ during archiving.

There is a Debian patch (77_header_folding_in_attachments.patch) which can cause this problem. The issue that the Debian patch addresses was properly addressed upstream in 2.1.13. Perhaps RedHat picked up the bad Debian patch somehow or has its own bad patch?