OK sounds reasonable. Since you are the expert and I am trying to understand. Have you ever seen a legitimate message with a no real end of headers, where the two line terminators designating the end of headers are separated by more than white space, tab or space characters?
Kevin > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > David Franco-Rocha [ Declude ] > Sent: Thursday, November 09, 2006 5: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.
