Menu
▾
▴
#767 POPFile concatenating headers
I asked in the Help forum, and was directed to submit
this to the bug tracking.
POPFile is concatenating headers onto a single line,
rather than appending them properly. Not all the time,
but often enough to be a problem. This breaks my mail
client's filtering as it is filtering on a header that
now does not exist.
The attached zip file contains two mbox/mailspool files
of the same messages. 'popfile-spam.mbx' are the
messages exported from the server before they were
downloaded, 'popfile-post-spam.mbx' are the same
messages exported from my mail client after they passed
through POPFile, so you can compare the originals to
what I actually get.
-Jeffrey
Logged In: YES
user_id=784160
It happened again. This time, I used the 'msgdump' script:
'perl message_dump.pl <host:[port]> <username> <password>
index/uidl > filename.ext'. The attached ZIP contains three
files: pre-spam.mbx is the file created by msgdump,
mid-spam.mbx is a copy&paste of the message from POPFile's
UI, and post-spam.mbx is the message as viewed and exported
from my mail client.
As you can see, the message is being mangled post-download
and pre-analysis.
This appears to be happening only to spams, I have not
noticed this mangling on any of my legitimate email.
Logged In: YES
user_id=663087
Sorry, I didn't realize this never got looked into any
further. I just tried your messages and could not reproduce
the problem.
I know it has been a long time, but are you sure you
attached the right files? The pre-spam.mbx seems to have
mail client headers in it:
Status: RO
X-Status:
X-Keywords:
X-UID: 604
I don't really recognize the X- headers, but they are not in
the other copies, and the Status one is usually added by the
mail server during download (I think) but not at the bottom
of the headers.
Of course, those headers could be the spammer's doing. And
maybe they are not appearing in the post copies of the
message due to this bug. If it is, then that means this is
more than concatenating lines.
Was this problem still happening with 0.22.3? Are you still
getting any of these? It doesn't look like the ones we have
will help figure this out so trying to get some new ones
might help.
If you happen to still have any of these in POPFile's
history (that would have to be a pretty big history), that
might be useful too. The copy and paste versions are good
at showing the result, but won't contain any odd characters
or formatting that might be causing this. Msgdump is
designed specifically to do that, but whatever is odd about
this message, I don't see it in the attached messages.
Maybe it has been fixed already.
Logged In: YES
user_id=372164
Originator: NO
In Japanese forum a user reported the similar problem.
The attached file (split-header.zip) contains a sample mail file.
(It's downloaded using message_dump.pl and I edited it.)
This mail has extra <CR>s in its header.
X-Spam-Status header line ends with <CR><CR><LF>.
POPFile treats it as the end of the header, so the left of the header
flows into the mail body.
If mail clients don't treat <CR> as a line break, the inserted
X-Text-Classification header will concatenated with the previous
header (X-Spam-Status).
Here is the explanation how this problem occurs:
--- Original e-mail ---
<snip>
X-Spam-Status: ....<CR><CR><LF>
Next-Header: ...<CR><LF>
<snip>
--- POPFile's thought ---
<snip>
X-Spam-Status: ...<CR> <--- line break
<CR><LF> <--- line break : blank line -> end of the header
Next-Header: <--- start of the body
<snip>
--- after POPFile ---
<snip>
X-Spam-Status: ...<CR>
X-Text-Classification: ...<CR><LF>
X-POPFile-Link: ...<CR><LF>
<CR><LF>
Next-Header<CR><LF>
<snip>
Naoki
File Added: split_header.zip
mail sample
Logged In: YES
user_id=372164
Originator: NO
I've committed a workaround patch to svn.
This problem may be fixed.