RE: [Declude.JunkMail] End of headers {was - declude not modifying subject line}

2006-11-09 Thread Kevin Bilbee
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.



Re: [Declude.JunkMail] End of headers {was - declude not modifying subject line}

2006-11-09 Thread Herb Guenther




What about a brute force rule "I am appending a header more than x
characters from the beginning of a y length message so this cannot be a
correctly formatted message" and you have set the
"deletebadforematmail" switch to "Yes" so delete.

Herb

Kevin Bilbee wrote:

  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.

  


-- 
Herb Guenther
Lanex, LLC
www.lanex.com
(262)789-0966x102 Office
(262)780-0424 Direct


This e-mail is confidential and is for the use of the intended recipient(s)only. If you are not an intended recipient please advise us of our error by return e-mail then delete this e-mail and any attached files. You may not copy, disclose or use the contents in any way.



---This E-mail came from the Declude.JunkMail mailing list.  Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail".  The archives can be foundat http://www.mail-archive.com.

Re: [Declude.JunkMail] End of headers {was - declude not modifying subject line}

2006-11-09 Thread Mike N



I've seen some messages with dozens of Kbytes of CC 
and TO E-mail lists that would fail this test.

  - Original Message - 
  From: 
  Herb Guenther 
  To: declude.junkmail@declude.com 
  
  Sent: Thursday, November 09, 2006 3:30 
  PM
  Subject: Re: [Declude.JunkMail] End of 
  headers {was - declude not modifying subject line}
  What about a brute force rule "I am appending a header more 
  than x characters from the beginning of a y length message so this cannot be a 
  correctly formatted message" and you have set the "deletebadforematmail" 
  switch to "Yes" so delete.HerbKevin Bilbee wrote: 
  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.

  -- 
Herb Guenther
Lanex, LLC
www.lanex.com
(262)789-0966x102 Office
(262)780-0424 Direct


This e-mail is confidential and is for the use of the intended recipient(s)only. If you are not an intended recipient please advise us of our error by return e-mail then delete this e-mail and any attached files. You may not copy, disclose or use the contents in any way.---This 
  E-mail came from the Declude.JunkMail mailing list. Tounsubscribe, just 
  send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe 
  Declude.JunkMail". The archives can be foundat 
http://www.mail-archive.com.

---This E-mail came from the Declude.JunkMail mailing list.  Tounsubscribe, just send an E-mail to [EMAIL PROTECTED], andtype "unsubscribe Declude.JunkMail".  The archives can be foundat http://www.mail-archive.com.


Re: [Declude.JunkMail] End of headers {was - declude not modifying subject line}

2006-11-09 Thread Herb Guenther




Hi Mike;

I'm sure that you are correct, but it would have to be both malformed
and have the large header.  Right now there are hundreds of messages a
day slipping thru that are not being addressed at all.  This MAY be a
way to get the vast majority of them without the apparent difficulty of
finding the end of the header so that it can by modified.  So far the
ones I have seen have been image spam that are do not have a large
number of to addresses.

Thanks for your feedback.

Herb

Mike N wrote:

  
  
  
  
  I've seen some messages with dozens
of Kbytes of CC and TO E-mail lists that would fail this test.
  
-
Original Message - 
From:
Herb Guenther

To:
declude.junkmail@declude.com

Sent:
Thursday, November 09, 2006 3:30 PM
Subject:
Re: [Declude.JunkMail] End of headers {was - declude not modifying
subject line}


What about a brute force rule "I am appending a header more than x
characters from the beginning of a y length message so this cannot be a
correctly formatted message" and you have set the
"deletebadforematmail" switch to "Yes" so delete.

Herb

Kevin Bilbee wrote:

  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.

  


-- 
Herb Guenther
Lanex, LLC
www.lanex.com
(262)789-0966x102 Office
(262)780-0424 Direct


This e-mail is confidential and is for the use of the intended recipient(s)only. If you are not an intended recipient please advise us of our error by return e-mail