Hi David: >> The broken line terminators are not necessarily of the same type in a given message. In addition, they are not necessarily adjacent to each other (with leading whitespace or unprintable characters on a line). What may appear obvious to the eye is often not at all what exists behind the scene. You may look at a message and be certain where the headers end and the body begins (the separating blank line). However, that message may not necessarily contain two consecutive EOL sequences of any type anywhere. <<
I think part of the frustration is, that some of us are in the business of "problem solving" and/or even systems programming and have a hard time relating to the specific difficulties you have encoutered without seeing live samples. After all, if Outlook can show the "intended content" of the message correctly, there IS a way how Outlook was able to determine the "intended" end of header (with Decludes headers appearing at the bottom of the message body in Outlook). Since Microsoft only cooks with water too (and I can't imagine them having put any deep "thought" into dealing with broken headers), it seems somewhat obvious that there is solution out there that just has been escaping whoever is working on it. Dave said in his message that he was asking for "help" / input / suggestions from users. I think some of us would love to step up to the plate and give it a try to devise an algorithm that discards white spaces, detects any newline sequences and then manages to detect the end of header the same way the "human eye" does and/or the same way "Outlook" clearly manages to. It may be unconventional - but if you placed sample text files of your different scenarios into a zip file and upload it somewhere, we all could collaborate - in the same way that we collaborated in the past when defining/devising new rules, filters, etc. Best Regards Andy Schmidt Phone: +1 201 934-3414 x20 (Business) Fax: +1 201 934-9206 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Franco-Rocha [ Declude ] Sent: Thursday, November 09, 2006 08:32 AM To: declude.junkmail@declude.com Subject: Re: [Declude.JunkMail] declude not modifying subject line Kevin, I am very well aware of what byte sequences constitute the end of a line. However, if the problem were this simple it would have been fixed long ago. Contrary to what some have said here, we have seen many instances where IMail likewise appends its headers to the end of the message. The broken line terminators are not necessarily of the same type in a given message. In addition, they are not necessarily adjacent to each other (with leading whitespace or unprintable characters on a line). What may appear obvious to the eye is often not at all what exists behind the scene. You may look at a message and be certain where the headers end and the body begins (the separating blank line). However, that message may not necessarily contain two consecutive EOL sequences of any type anywhere. David Franco-Rocha ----- Original Message ----- From: "Kevin Bilbee" <[EMAIL PROTECTED]> To: <declude.junkmail@declude.com> Sent: Wednesday, November 08, 2006 5:45 PM Subject: RE: [Declude.JunkMail] declude not modifying subject line I do not understand why you need to rewrite the message beyond what you already do? Just determine the end of headers properly then rewrite the message with your headers in the proper location. You already rewrite the message when adding headers so why would it take any longer to properly detect the end of headers. If you have two LF sequences next to each other ignoring the CR then you have the end of headers. For example if you have CRLFCRLF OR LFCRLFCR OR LFLF I have never seen a message use CR alone for an end of line. There are two LF bytes in each sequence ignore the CR bytes. Then when writing out the message with the Declude headers include the original byte sequences for each line. And the Declude lines should have the proper CRLF sequences. My two cents! Kevin Bilbee > > 1. I don't like to keep going in circles on this. If it was as easy as > "just > fix it" there would be no issue. Please understand that this is a lot > more > complex than you may realize, we are considering making the fixing of > line > terminators as an optional feature to be turned on/off because of a > potential performance degradation of rewriting the messages. > --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
