Menu
▾
▴
#623 POPfile headers in body
The pop file header appeared at the end of the message.
When the message got to Netscape Mail client, the
subject line was blank. I pulled the Netscape msg file up
in word pad, there was no blank line between the header
and the rest of the message. The from:, to:, subject:
where all in one line. The next line had MIMIE Version:,
XMailer: and the message content all on one line.
The problem occured in version 0.18.1 and just upgraded
to 0.20.1a so the attached message was "upgraded"
POPFile\messages\popfile1419=4.msg
Logged In: YES
user_id=640073
Odd. Are you sure this is the same message? The lines I am
seeing are well separated, and there is an extra line after the
headers.
I am beginning to think there is a particular mail server
(CMail?) issue you are encountering that results in messages
that are malformed in a particularly odd way that perhaps
isn't translating well into POPFile's cache.
I am _not_ marking this as a duplicate of bug 772339 as I
think this possible malformation of email is a seperate issue as
seen by the original poster of that bug.
I will look for a pattern that IS translated into CRLF's when
POPFile saves a line to disk but that ISN'T interpreted as a
CRLF by the header insertion code or Netscape (I doubt there
is one though)
Regards,
Sam
Logged In: YES
user_id=640073
I believe I've reproduced this.
When message lines are terminated with a CR instead of a CRLF or LF, POPFile is unable to retrieve the message one line at a time.
I'm not sure how to fix this.
Regards,
Sam
The clasification ended up three lines from the bottom
Logged In: YES
user_id=191346
The attached message 1461=2 got to my netscape client
with a subject line of blank, the first line in the body was the
to: line and the x-text-classification line was three up from
the end, just above the </center>. I an running 20.1a.
Logged In: YES
user_id=640073
Ok, interesting. The message posted is well-formed (as
posted). I can't get it to malform the insertion in my test
harness.
I will try to determine if the netscape client interprets CR's as
CRLF's.
I have verified that acm.org's mail server (CMail, which has a
new version that acm.org may want to consider installing
BTW) does allow CR's to pass in the headers and bodies of
messages.
My suspicion about the cause of this is stronger though still
unconfirmed.
I believe it is time for POPFile to have a small debugging suite
that users can use to get verbatim copies of potentially
troublesome messages. I know my current mail client does
some changes that aren't 100% faithful to the actual data
that travels across the network.
Regards,
Sam
Logged In: YES
user_id=640073
Try the attached version of Bayes.pm. You should be able to
drop it into POPFile's Classifier directory (overwriting the
previous version).
If this bug doesn't re-occur by Saturday with this change, I
think we can consider this fixed.
Regards,
Sam
Modified Bayes.pm
Logged In: YES
user_id=191346
Okay. I will try the new version of Bayes.pm and let you
know what happens.
PS. To confuse matters further, the acm.org server is a
simple forwarder. My pop account is located on one of my
personal machines and is received and served by the
Computalynx Cmail program version 2.4.10
http://www.computalynx.com
Logged In: YES
user_id=191346
The new bayes.pm does not seem to catch the problem. The
attached 1491=14 came in with no subject, the first displayed
line was the TO: line, and the X-Text-Classification: was one
up from the bottom, just before the </html>
There are two files in the zip folder. the 1491=4 from the
popfile msg folder and the spam from the netscape profiles.
I have solved he imediate problem by searcing for the
classification message in either the header or the body. this
get the message to the right folder.
Blank header, X-Text-Classification: at bottom
Logged In: YES
user_id=191346
The new bayes.pm does not seem to catch the problem. The
attached 1491=14 came in with no subject, the first displayed
line was the TO: line, and the X-Text-Classification: was one
up from the bottom, just before the </html>
There are two files in the zip folder. the 1491=4 from the
popfile msg folder and the spam from the netscape profiles.
I have solved he imediate problem by searcing for the
classification message in either the header or the body. this
get the message to the right folder.
Blank header, X-Text-Classification: at bottom
Blank header, X-Text-Classification: at bottom
Logged In: YES
user_id=191346
The new bayes.pm does not seem to catch the problem. The
attached 1491=14 came in with no subject, the first displayed
line was the TO: line, and the X-Text-Classification: was one
up from the bottom, just before the </html>
There are two files in the zip folder. the 1491=4 from the
popfile msg folder and the spam from the netscape profiles.
I have solved he imediate problem by searcing for the
classification message in either the header or the body. this
get the message to the right folder.
Logged In: YES
user_id=640073
Ugh. That was my only idea on this bug.
I think it is a valid fix for some errors of this type, but
obviously not for what you are seeing.
The only way I can think of getting any better debugging
information is if I am able to reproduce the exact transaction
between your client and server.
I will put together an instrumented version of Bayes.pm that
should place some information in the log showing a bit better
where POPFile is getting confused.
Regards,
Sam
Logged In: YES
user_id=640073
Ok, give this instrumented version of Bayes.pm a try, please.
If you are able to post a mis-inserted message and the relevant log portion I would appreciate it!
Regards,
Sam
Instrumented Bayes.pm
Instrumented Bayes.pm
Logged In: YES
user_id=640073
Woops, the instrumented version was derived from our current CVS code, which is incompatible with 0.20.1.
Here's a 0.20.1 compatible version with the current fixes in CVS.
0.20.1 compatible fixed/instrumented Bayes.pm
no toptoo problems
Logged In: YES
user_id=640073
The last version caused some small problems with TOPTOO enabled.
If you use toptoo, this version is fixed.
Regards,
Sam
Logged In: YES
user_id=640073
Can I assume that this problem has not re-occured with the
latest posted version of Bayes.pm?
Regards,
Sam