Re: [Declude.JunkMail] Headers showing up in the body on 3.05.10
Testing thus far has not yet returned any errors in determining the actual end of the headers. The resolution of this issue was not as simple as it may have appeared to some. The search for cr/lf/cr/lf or lf/lf was not sufficient because of the nature of these messages. Some lf sequences, even within the same message, may have been preceded by cr and others not. In addition, only by looking at hexdumps of actual messages did the culprit sequences become clearer. One of the more recent was a cr/lf/space/lf and /cr/lf/tab/lf or a string of invisible characters between the unreliable line terminators. Sometimes there are mixes of spaces and tabs or multiples of each. We anticipate including this fix in the next interim release. David Franco-Rocha Declude Technical / Engineering - Original Message - From: "Mark Smith" <[EMAIL PROTECTED]> To: Sent: Friday, October 28, 2005 7:55 AM Subject: FW: [Declude.JunkMail] Headers showing up in the body on 3.05.10 David, Just for follow-up. As I posted earlier we reverted back to 2.6 from 3.6.11 and 99% of these "headers in the body" messages are gone. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Smith Sent: Tuesday, October 25, 2005 4:54 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Headers showing up in the body on 3.05.10 David, Thanks for the explanation! However, I have yet to see a message with SMTP headers in the body if I remove Declude and send mail directly into Exchange. Maybe Exchange will just not deliver? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David Barker > Sent: Tuesday, October 25, 2005 3:27 PM > To: Declude.JunkMail@declude.com > Subject: RE: [Declude.JunkMail] Headers showing up in the body on > 3.05.10 > > In every instance that we have observed so far the headers in the body > are caused by broken mail clients. This is not only an issue for > Declude but for mail servers as well. To illustrates the difficulty > coming up with a single algorithm that will detect all instances of > these broken emails to prevent headers from appearing at the end of a > message or within the body of a message. > > RFC dictates all lines must end with a CR/LF sequence, with a double > sequence CR/LF/CR/LF separating the headers from the body. > Technically, that would be a 0D 0A 0D 0A sequence. > > In the byte sequence below, the sixth line contains: > > 22 0A 20 0D 0A 49 20 73-74 61 72 74 65 64 20 68 > > where a single 0A is followed by a space and then the required 0D 0A > sequence. When this problem was first reported, changes were made in > the source to detect a simple 0A as a line terminator, followed by > another line terminator sequence. > > However, this example would not get detected because they inserted a > space, which is invisible, between the two line termination sequences. > They could have inserted a tab (09) also, so checking only for a space > would not have caught all possibilities. > > In addition, checking only for spaces at the beginning of a line would > not solve the problem because certain header lines can be continued on > the next line, which requires spaces and then non-blank characters > prior to the next line termination sequence. > > 30 38 3A 35 37 3A 31 33-20 2D 30 35 30 30 0D 0A 4D 49 4D 45 2D 56 65 > 72-73 69 6F 6E 3A 20 31 2E 30 0D 0A 43 6F 6E 74 65-6E 74 2D 54 79 70 > 65 3A 20 74 65 78 74 2F 70 6C-61 69 6E 3B 0D 0A 09 63 > 68 61 72 73 65 74 3D 22-75 73 2D 61 73 63 69 69 > 22 0A 20 0D 0A 49 20 73-74 61 72 74 65 64 20 68 > 61 76 69 6E 67 20 61 6E-20 61 66 66 61 69 72 20 > 77 69 74 68 20 61 20 79-6F 75 6E 67 65 72 2C 20 > > Often from the outset these issues look extremely simple. > However, because all eventualities that have to be covered it becomes > quite complex. I am providing this example because things are rarely > as simple as they may at first appear. > > With all that said we are looking into providing a solution for this > problem. > > David B > www.declude.com > > -Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Matt > Sent: Monday, October 24, 2005 9:07 PM > To: Declude.JunkMail@declude.com > Subject: Re: [Declude.JunkMail] Headers showing up in the body on > 3.05.10 > > This looks like Declude was expecting to see an occurrence of Blank > Folding, but it is making the mistake of detecting headers in the MIME > segments or the body as a continuation of the real headers, either > that or they changed the code that detects where to throw in the > Declude generated headers in order to handle Blank Folding. IMO, > Declude should just throw the headers just before the location of the &g
FW: [Declude.JunkMail] Headers showing up in the body on 3.05.10
David, Just for follow-up. As I posted earlier we reverted back to 2.6 from 3.6.11 and 99% of these "headers in the body" messages are gone. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Mark Smith > Sent: Tuesday, October 25, 2005 4:54 PM > To: Declude.JunkMail@declude.com > Subject: RE: [Declude.JunkMail] Headers showing up in the body on > 3.05.10 > > David, > Thanks for the explanation! > > However, I have yet to see a message with SMTP headers in the body if > I remove Declude and send mail directly into Exchange. > Maybe Exchange will just not deliver? > > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > David Barker > > Sent: Tuesday, October 25, 2005 3:27 PM > > To: Declude.JunkMail@declude.com > > Subject: RE: [Declude.JunkMail] Headers showing up in the body on > > 3.05.10 > > > > In every instance that we have observed so far the headers > in the body > > are caused by broken mail clients. This is not only an issue for > > Declude but for mail servers as well. To illustrates the difficulty > > coming up with a single algorithm that will detect all instances of > > these broken emails to prevent headers from appearing at > the end of a > > message or within the body of a message. > > > > RFC dictates all lines must end with a CR/LF sequence, with > a double > > sequence CR/LF/CR/LF separating the headers from the body. > > Technically, that would be a 0D 0A 0D 0A sequence. > > > > In the byte sequence below, the sixth line contains: > > > > 22 0A 20 0D 0A 49 20 73-74 61 72 74 65 64 20 68 > > > > where a single 0A is followed by a space and then the > required 0D 0A > > sequence. When this problem was first reported, changes > were made in > > the source to detect a simple 0A as a line terminator, followed by > > another line terminator sequence. > > > > However, this example would not get detected because they > inserted a > > space, which is invisible, between the two line termination > sequences. > > They could have inserted a tab (09) also, so checking only > for a space > > would not have caught all possibilities. > > > > In addition, checking only for spaces at the beginning of a > line would > > not solve the problem because certain header lines can be > continued on > > the next line, which requires spaces and then non-blank characters > > prior to the next line termination sequence. > > > > 30 38 3A 35 37 3A 31 33-20 2D 30 35 30 30 0D 0A 4D 49 4D 45 > 2D 56 65 > > 72-73 69 6F 6E 3A 20 31 2E 30 0D 0A 43 6F 6E 74 65-6E 74 2D > 54 79 70 > > 65 3A 20 74 65 78 74 2F 70 6C-61 69 6E 3B 0D 0A 09 63 > > 68 61 72 73 65 74 3D 22-75 73 2D 61 73 63 69 69 > > 22 0A 20 0D 0A 49 20 73-74 61 72 74 65 64 20 68 > > 61 76 69 6E 67 20 61 6E-20 61 66 66 61 69 72 20 > > 77 69 74 68 20 61 20 79-6F 75 6E 67 65 72 2C 20 > > > > Often from the outset these issues look extremely simple. > > However, because all eventualities that have to be covered > it becomes > > quite complex. I am providing this example because things > are rarely > > as simple as they may at first appear. > > > > With all that said we are looking into providing a solution > for this > > problem. > > > > David B > > www.declude.com > > > > -Original Message- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Matt > > Sent: Monday, October 24, 2005 9:07 PM > > To: Declude.JunkMail@declude.com > > Subject: Re: [Declude.JunkMail] Headers showing up in the body on > > 3.05.10 > > > > This looks like Declude was expecting to see an occurrence of Blank > > Folding, but it is making the mistake of detecting headers > in the MIME > > segments or the body as a continuation of the real headers, either > > that or they changed the code that detects where to throw in the > > Declude generated headers in order to handle Blank Folding. IMO, > > Declude should just throw the headers just before the > location of the > > first or possibly following a mistaken . > > > > I haven't seen any Declude headers in the body using 2.0.6.16 and > > earlier. > > > > Matt > > > > > > > > Robert Grosshandler wrote: > > > > >This has been a problem for awhile (happened with the move > > to the new > > >architecture, but Declude says it's not connected.) > > > > > >The headers are &quo
RE: [Declude.JunkMail] Headers showing up in the body on 3.05.10
David, Thanks for the explanation! However, I have yet to see a message with SMTP headers in the body if I remove Declude and send mail directly into Exchange. Maybe Exchange will just not deliver? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of David Barker > Sent: Tuesday, October 25, 2005 3:27 PM > To: Declude.JunkMail@declude.com > Subject: RE: [Declude.JunkMail] Headers showing up in the > body on 3.05.10 > > In every instance that we have observed so far the headers in > the body are caused by broken mail clients. This is not only > an issue for Declude but for mail servers as well. To > illustrates the difficulty coming up with a single algorithm > that will detect all instances of these broken emails to > prevent headers from appearing at the end of a message or > within the body of a message. > > RFC dictates all lines must end with a CR/LF sequence, with a > double sequence CR/LF/CR/LF separating the headers from the > body. Technically, that would be a 0D 0A 0D 0A sequence. > > In the byte sequence below, the sixth line contains: > > 22 0A 20 0D 0A 49 20 73-74 61 72 74 65 64 20 68 > > where a single 0A is followed by a space and then the > required 0D 0A sequence. When this problem was first > reported, changes were made in the source to detect a simple > 0A as a line terminator, followed by another line terminator > sequence. > > However, this example would not get detected because they > inserted a space, which is invisible, between the two line > termination sequences. They could have inserted a tab (09) > also, so checking only for a space would not have caught all > possibilities. > > In addition, checking only for spaces at the beginning of a > line would not solve the problem because certain header lines > can be continued on the next line, which requires spaces and > then non-blank characters prior to the next line termination sequence. > > 30 38 3A 35 37 3A 31 33-20 2D 30 35 30 30 0D 0A 4D 49 4D 45 > 2D 56 65 72-73 69 6F 6E 3A 20 31 2E 30 0D 0A 43 6F 6E 74 > 65-6E 74 2D 54 79 70 65 3A 20 74 65 78 74 2F 70 6C-61 69 6E > 3B 0D 0A 09 63 > 68 61 72 73 65 74 3D 22-75 73 2D 61 73 63 69 69 > 22 0A 20 0D 0A 49 20 73-74 61 72 74 65 64 20 68 > 61 76 69 6E 67 20 61 6E-20 61 66 66 61 69 72 20 > 77 69 74 68 20 61 20 79-6F 75 6E 67 65 72 2C 20 > > Often from the outset these issues look extremely simple. > However, because all eventualities that have to be covered it > becomes quite complex. I am providing this example because > things are rarely as simple as they may at first appear. > > With all that said we are looking into providing a solution > for this problem. > > David B > www.declude.com > > -Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Matt > Sent: Monday, October 24, 2005 9:07 PM > To: Declude.JunkMail@declude.com > Subject: Re: [Declude.JunkMail] Headers showing up in the > body on 3.05.10 > > This looks like Declude was expecting to see an occurrence of > Blank Folding, but it is making the mistake of detecting > headers in the MIME segments or the body as a continuation of > the real headers, either that or they changed the code that > detects where to throw in the Declude generated headers in > order to handle Blank Folding. IMO, Declude should just > throw the headers just before the location of the first > or possibly following a mistaken . > > I haven't seen any Declude headers in the body using 2.0.6.16 > and earlier. > > Matt > > > > Robert Grosshandler wrote: > > >This has been a problem for awhile (happened with the move > to the new > >architecture, but Declude says it's not connected.) > > > >The headers are "bad" when they make it to Declude, and > Declude doesn't > >handle them right. > > > >Fortunately, in our setup, they all still get treated as > very heavily > >weighted spam, so they never make it to users. > > > >Rob > > > >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of Mark Smith > >Sent: Monday, October 24, 2005 6:17 PM > >To: Declude.JunkMail@declude.com > >Subject: [Declude.JunkMail] Headers showing up in the body on 3.05.10 > > > >Ever since I went to 3.05.10 (now on 3.05.11) I've been receiving > >hundreds of complaints of spam making it to my users. > >After inspection, Declude is subject line marking the > messages but it's > >moving the SMTP headers to the body of the email. This results in > >user's Outlook rules not firing on the subject line keywords. > > >
RE: [Declude.JunkMail] Headers showing up in the body on 3.05.10
At 02:47 PM 10/25/2005 -0500, you wrote: >Something changed at the time the new architecture came out. Either folks >started using a lot of new / broken clients, or Declude became more >sensitive. In my opinion a lot of broken clients started happening. Whereas I beta tested the new version on my backup server I have never changed to the new version on my old server and I am seeing large numbers of the broken clients with no changes in my old declude setup. Jay [This E-mail scanned for viruses by F-Prot] --- 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] Headers showing up in the body on 3.05.10
There has been a rash of new spam/virus content with broken headers... starting last month. We're on IMail 8.05 and Declude 1.82 and we've seen them. Darin. - Original Message - From: "Robert Grosshandler" <[EMAIL PROTECTED]> To: Sent: Tuesday, October 25, 2005 3:47 PM Subject: RE: [Declude.JunkMail] Headers showing up in the body on 3.05.10 Something changed at the time the new architecture came out. Either folks started using a lot of new / broken clients, or Declude became more sensitive. I say that based upon observation. We NEVER noticed the issue prior to installing the beta of the latest version. Heck, it is possible that both are true ... More broken clients AND Declude became more sensitive. In any case, as a practical matter, Declude is still routing properly based upon the weight assigned to the offending mail. Since all of the mail has weights that are extremely high, they never make it to our users, and therefore we don't rely on altering the Subject line or headers for further processing. Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Tuesday, October 25, 2005 2:27 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Headers showing up in the body on 3.05.10 In every instance that we have observed so far the headers in the body are caused by broken mail clients. This is not only an issue for Declude but for mail servers as well. To illustrates the difficulty coming up with a single algorithm that will detect all instances of these broken emails to prevent headers from appearing at the end of a message or within the body of a message. RFC dictates all lines must end with a CR/LF sequence, with a double sequence CR/LF/CR/LF separating the headers from the body. Technically, that would be a 0D 0A 0D 0A sequence. In the byte sequence below, the sixth line contains: 22 0A 20 0D 0A 49 20 73-74 61 72 74 65 64 20 68 where a single 0A is followed by a space and then the required 0D 0A sequence. When this problem was first reported, changes were made in the source to detect a simple 0A as a line terminator, followed by another line terminator sequence. However, this example would not get detected because they inserted a space, which is invisible, between the two line termination sequences. They could have inserted a tab (09) also, so checking only for a space would not have caught all possibilities. In addition, checking only for spaces at the beginning of a line would not solve the problem because certain header lines can be continued on the next line, which requires spaces and then non-blank characters prior to the next line termination sequence. 30 38 3A 35 37 3A 31 33-20 2D 30 35 30 30 0D 0A 4D 49 4D 45 2D 56 65 72-73 69 6F 6E 3A 20 31 2E 30 0D 0A 43 6F 6E 74 65-6E 74 2D 54 79 70 65 3A 20 74 65 78 74 2F 70 6C-61 69 6E 3B 0D 0A 09 63 68 61 72 73 65 74 3D 22-75 73 2D 61 73 63 69 69 22 0A 20 0D 0A 49 20 73-74 61 72 74 65 64 20 68 61 76 69 6E 67 20 61 6E-20 61 66 66 61 69 72 20 77 69 74 68 20 61 20 79-6F 75 6E 67 65 72 2C 20 Often from the outset these issues look extremely simple. However, because all eventualities that have to be covered it becomes quite complex. I am providing this example because things are rarely as simple as they may at first appear. With all that said we are looking into providing a solution for this problem. David B www.declude.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Monday, October 24, 2005 9:07 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Headers showing up in the body on 3.05.10 This looks like Declude was expecting to see an occurrence of Blank Folding, but it is making the mistake of detecting headers in the MIME segments or the body as a continuation of the real headers, either that or they changed the code that detects where to throw in the Declude generated headers in order to handle Blank Folding. IMO, Declude should just throw the headers just before the location of the first or possibly following a mistaken . I haven't seen any Declude headers in the body using 2.0.6.16 and earlier. Matt Robert Grosshandler wrote: >This has been a problem for awhile (happened with the move to the new >architecture, but Declude says it's not connected.) > >The headers are "bad" when they make it to Declude, and Declude doesn't >handle them right. > >Fortunately, in our setup, they all still get treated as very heavily >weighted spam, so they never make it to users. > >Rob > >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Mark Smith >Sent: Monday, October 24, 2005 6:17 PM >To: Declude.JunkMail@declude.com >Subject: [Declude.JunkMail] Headers showing up in the body on 3.05.10 > >Ever since I went to 3.05.10 (now on
RE: [Declude.JunkMail] Headers showing up in the body on 3.05.10
Something changed at the time the new architecture came out. Either folks started using a lot of new / broken clients, or Declude became more sensitive. I say that based upon observation. We NEVER noticed the issue prior to installing the beta of the latest version. Heck, it is possible that both are true ... More broken clients AND Declude became more sensitive. In any case, as a practical matter, Declude is still routing properly based upon the weight assigned to the offending mail. Since all of the mail has weights that are extremely high, they never make it to our users, and therefore we don't rely on altering the Subject line or headers for further processing. Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Barker Sent: Tuesday, October 25, 2005 2:27 PM To: Declude.JunkMail@declude.com Subject: RE: [Declude.JunkMail] Headers showing up in the body on 3.05.10 In every instance that we have observed so far the headers in the body are caused by broken mail clients. This is not only an issue for Declude but for mail servers as well. To illustrates the difficulty coming up with a single algorithm that will detect all instances of these broken emails to prevent headers from appearing at the end of a message or within the body of a message. RFC dictates all lines must end with a CR/LF sequence, with a double sequence CR/LF/CR/LF separating the headers from the body. Technically, that would be a 0D 0A 0D 0A sequence. In the byte sequence below, the sixth line contains: 22 0A 20 0D 0A 49 20 73-74 61 72 74 65 64 20 68 where a single 0A is followed by a space and then the required 0D 0A sequence. When this problem was first reported, changes were made in the source to detect a simple 0A as a line terminator, followed by another line terminator sequence. However, this example would not get detected because they inserted a space, which is invisible, between the two line termination sequences. They could have inserted a tab (09) also, so checking only for a space would not have caught all possibilities. In addition, checking only for spaces at the beginning of a line would not solve the problem because certain header lines can be continued on the next line, which requires spaces and then non-blank characters prior to the next line termination sequence. 30 38 3A 35 37 3A 31 33-20 2D 30 35 30 30 0D 0A 4D 49 4D 45 2D 56 65 72-73 69 6F 6E 3A 20 31 2E 30 0D 0A 43 6F 6E 74 65-6E 74 2D 54 79 70 65 3A 20 74 65 78 74 2F 70 6C-61 69 6E 3B 0D 0A 09 63 68 61 72 73 65 74 3D 22-75 73 2D 61 73 63 69 69 22 0A 20 0D 0A 49 20 73-74 61 72 74 65 64 20 68 61 76 69 6E 67 20 61 6E-20 61 66 66 61 69 72 20 77 69 74 68 20 61 20 79-6F 75 6E 67 65 72 2C 20 Often from the outset these issues look extremely simple. However, because all eventualities that have to be covered it becomes quite complex. I am providing this example because things are rarely as simple as they may at first appear. With all that said we are looking into providing a solution for this problem. David B www.declude.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Monday, October 24, 2005 9:07 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Headers showing up in the body on 3.05.10 This looks like Declude was expecting to see an occurrence of Blank Folding, but it is making the mistake of detecting headers in the MIME segments or the body as a continuation of the real headers, either that or they changed the code that detects where to throw in the Declude generated headers in order to handle Blank Folding. IMO, Declude should just throw the headers just before the location of the first or possibly following a mistaken . I haven't seen any Declude headers in the body using 2.0.6.16 and earlier. Matt Robert Grosshandler wrote: >This has been a problem for awhile (happened with the move to the new >architecture, but Declude says it's not connected.) > >The headers are "bad" when they make it to Declude, and Declude doesn't >handle them right. > >Fortunately, in our setup, they all still get treated as very heavily >weighted spam, so they never make it to users. > >Rob > >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Mark Smith >Sent: Monday, October 24, 2005 6:17 PM >To: Declude.JunkMail@declude.com >Subject: [Declude.JunkMail] Headers showing up in the body on 3.05.10 > >Ever since I went to 3.05.10 (now on 3.05.11) I've been receiving >hundreds of complaints of spam making it to my users. >After inspection, Declude is subject line marking the messages but it's >moving the SMTP headers to the body of the email. This results in >user's Outlook rules not firing on the subject line keywords. > >Here's an example of the ACTUAL MESSAGE BODY.
RE: [Declude.JunkMail] Headers showing up in the body on 3.05.10
In every instance that we have observed so far the headers in the body are caused by broken mail clients. This is not only an issue for Declude but for mail servers as well. To illustrates the difficulty coming up with a single algorithm that will detect all instances of these broken emails to prevent headers from appearing at the end of a message or within the body of a message. RFC dictates all lines must end with a CR/LF sequence, with a double sequence CR/LF/CR/LF separating the headers from the body. Technically, that would be a 0D 0A 0D 0A sequence. In the byte sequence below, the sixth line contains: 22 0A 20 0D 0A 49 20 73-74 61 72 74 65 64 20 68 where a single 0A is followed by a space and then the required 0D 0A sequence. When this problem was first reported, changes were made in the source to detect a simple 0A as a line terminator, followed by another line terminator sequence. However, this example would not get detected because they inserted a space, which is invisible, between the two line termination sequences. They could have inserted a tab (09) also, so checking only for a space would not have caught all possibilities. In addition, checking only for spaces at the beginning of a line would not solve the problem because certain header lines can be continued on the next line, which requires spaces and then non-blank characters prior to the next line termination sequence. 30 38 3A 35 37 3A 31 33-20 2D 30 35 30 30 0D 0A 4D 49 4D 45 2D 56 65 72-73 69 6F 6E 3A 20 31 2E 30 0D 0A 43 6F 6E 74 65-6E 74 2D 54 79 70 65 3A 20 74 65 78 74 2F 70 6C-61 69 6E 3B 0D 0A 09 63 68 61 72 73 65 74 3D 22-75 73 2D 61 73 63 69 69 22 0A 20 0D 0A 49 20 73-74 61 72 74 65 64 20 68 61 76 69 6E 67 20 61 6E-20 61 66 66 61 69 72 20 77 69 74 68 20 61 20 79-6F 75 6E 67 65 72 2C 20 Often from the outset these issues look extremely simple. However, because all eventualities that have to be covered it becomes quite complex. I am providing this example because things are rarely as simple as they may at first appear. With all that said we are looking into providing a solution for this problem. David B www.declude.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Sent: Monday, October 24, 2005 9:07 PM To: Declude.JunkMail@declude.com Subject: Re: [Declude.JunkMail] Headers showing up in the body on 3.05.10 This looks like Declude was expecting to see an occurrence of Blank Folding, but it is making the mistake of detecting headers in the MIME segments or the body as a continuation of the real headers, either that or they changed the code that detects where to throw in the Declude generated headers in order to handle Blank Folding. IMO, Declude should just throw the headers just before the location of the first or possibly following a mistaken . I haven't seen any Declude headers in the body using 2.0.6.16 and earlier. Matt Robert Grosshandler wrote: >This has been a problem for awhile (happened with the move to the new >architecture, but Declude says it's not connected.) > >The headers are "bad" when they make it to Declude, and Declude doesn't >handle them right. > >Fortunately, in our setup, they all still get treated as very heavily >weighted spam, so they never make it to users. > >Rob > >-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Mark Smith >Sent: Monday, October 24, 2005 6:17 PM >To: Declude.JunkMail@declude.com >Subject: [Declude.JunkMail] Headers showing up in the body on 3.05.10 > >Ever since I went to 3.05.10 (now on 3.05.11) I've been receiving >hundreds of complaints of spam making it to my users. >After inspection, Declude is subject line marking the messages but it's >moving the SMTP headers to the body of the email. This results in >user's Outlook rules not firing on the subject line keywords. > >Here's an example of the ACTUAL MESSAGE BODY. > >Anyone else seeing this? > >-0- > > >-Original Message- >From: Jon Addison [mailto:[EMAIL PROTECTED] >Sent: Monday, October 24, 2005 6:06 AM >To: Smith, Mark E. >Subject: Re: Hello. > >You've seen it on "60 Minutes" and read the BBC News report -- now find >out just what everyone is talking about. >Message-Id: <[EMAIL PROTECTED]> >Subject: [WARNING-SPAM]:[333]: >X-RBL-Warning: CATCHALLMAILS: >X-RBL-Warning: FIVETEN-SPAM: 225.72.226.221.blackholes.five-ten-sg.com. >X-RBL-Warning: NOABUSE: "Not supporting [EMAIL PROTECTED]" >X-RBL-Warning: SORBS-DUL: "Dynamic IP Addresses See: >http://www.sorbs.net/lookup.shtml?221.226.72.225"; >X-RBL-Warning: IPNOTINMX: >X-RBL-Warning: NOLEGITCONTENT: No content unique to legitimate E-mail >detected. >X-RBL-Warning: REVDNS: This E-mail was sent from a MUA/MTA >22
Re: [Declude.JunkMail] Headers showing up in the body on 3.05.10
This looks like Declude was expecting to see an occurrence of Blank Folding, but it is making the mistake of detecting headers in the MIME segments or the body as a continuation of the real headers, either that or they changed the code that detects where to throw in the Declude generated headers in order to handle Blank Folding. IMO, Declude should just throw the headers just before the location of the first or possibly following a mistaken . I haven't seen any Declude headers in the body using 2.0.6.16 and earlier. Matt Robert Grosshandler wrote: This has been a problem for awhile (happened with the move to the new architecture, but Declude says it's not connected.) The headers are "bad" when they make it to Declude, and Declude doesn't handle them right. Fortunately, in our setup, they all still get treated as very heavily weighted spam, so they never make it to users. Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Smith Sent: Monday, October 24, 2005 6:17 PM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] Headers showing up in the body on 3.05.10 Ever since I went to 3.05.10 (now on 3.05.11) I've been receiving hundreds of complaints of spam making it to my users. After inspection, Declude is subject line marking the messages but it's moving the SMTP headers to the body of the email. This results in user's Outlook rules not firing on the subject line keywords. Here's an example of the ACTUAL MESSAGE BODY. Anyone else seeing this? -0- -Original Message- From: Jon Addison [mailto:[EMAIL PROTECTED] Sent: Monday, October 24, 2005 6:06 AM To: Smith, Mark E. Subject: Re: Hello. You've seen it on "60 Minutes" and read the BBC News report -- now find out just what everyone is talking about. Message-Id: <[EMAIL PROTECTED]> Subject: [WARNING-SPAM]:[333]: X-RBL-Warning: CATCHALLMAILS: X-RBL-Warning: FIVETEN-SPAM: 225.72.226.221.blackholes.five-ten-sg.com. X-RBL-Warning: NOABUSE: "Not supporting [EMAIL PROTECTED]" X-RBL-Warning: SORBS-DUL: "Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?221.226.72.225"; X-RBL-Warning: IPNOTINMX: X-RBL-Warning: NOLEGITCONTENT: No content unique to legitimate E-mail detected. X-RBL-Warning: REVDNS: This E-mail was sent from a MUA/MTA 221.226.72.225 with no reverse DNS entry. X-RBL-Warning: MS-SNAKEOIL: Message failed MS-SNAKEOIL: 52. X-RBL-Warning: SPAMCHK: Message failed SPAMCHK: 3. X-RBL-Warning: SPAMDOMAINS: Spamdomain '@yahoo.' found: Address of [EMAIL PROTECTED] sent from invalid [No Reverse DNS]. X-RBL-Warning: FALSE-YAHOO: Message failed FALSE-YAHOO test (line 2, weight 30) X-RBL-Warning: WEIGHT120349CP: Total weight between 120 and 349. X-Declude-Sender: [EMAIL PROTECTED] [221.226.72.225] X-Declude-Spoolname: Ddba001ae99e2.smd X-Note: X-Note: == X-Note: Spam Score: 333 [SUBJECT STRING ON 120-349 & DELETED ON 350+] X-Note: Scan Time: 09:03:36 on 24 Oct 2005 X-Note: Spool File: Ddba001ae99e2.smd X-Note: Server Name: netrends.com X-Note: SMTP Sender: [EMAIL PROTECTED] X-Note: Reverse DNS & IP: [No Reverse DNS] [221.226.72.225] X-Note: Organization: popmail.netrends.com X-Note: Recipient(s): [EMAIL PROTECTED] X-Note: Country Chain: CHINA->destination X-Note: Tests Failed: CATCHALLMAILS [0], FIVETEN-SPAM [30], NOABUSE [10], SORBS-DUL [50], IPNOTINMX [0], NOLEGITCONTENT [0], REVDNS [40], MS-SNAKEOIL [150], SPAMCHK [3], SPAMDOMAINS [20], FALSE-YAHOO [30], WEIGHT120349 [120], WEIGHT120349CP [120] X-Note: In or Out: outgoing X-Note: == X-Note: This E-mail was scanned & filtered X-Note: filter [3.0.5.10] for SPAM & virus. X-Note: == X-Note: # Suppress your appetite and feel full and satisfied all day long # Increase your energy levels # Lose excess weight # Increase your metabolism # Burn body fat # Burn calories # Attack obesity And more.. http://coolhoodia.com/ # Suitable for vegetarians and vegans # MAINTAIN your weight loss # Make losing weight a sure guarantee # Look your best during the summer months http://coolhoodia.com/ Regards, Dr. Jon Addison --- 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 scanned for viruses by Declude Virus] --- [This E-mail scanned for viruses by Declude Virus] --- 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] Headers showing up in the body on 3.05.10
Ever since I went to 3.05.10 (on Friday) I've been receiving hundreds of complaints of spam making it to my users. After inspection, Declude is subject line marking the messages but it's moving the SMTP headers to the body of the email. This results in user's Outlook rules not firing on the subject line keywords. Here's an example of the ACTUAL MESSAGE BODY. Anyone else seeing this? -0- > -Original Message- > From: Jon Addison [mailto:[EMAIL PROTECTED] > Sent: Monday, October 24, 2005 6:06 AM > To: Smith, Mark E. > Subject: Re: Hello. > > You've seen it on "60 Minutes" and read the BBC News report > -- now find out just what everyone is talking about. > Message-Id: <[EMAIL PROTECTED]> > Subject: [WARNING-SPAM]:[333]: > X-RBL-Warning: CATCHALLMAILS: > X-RBL-Warning: FIVETEN-SPAM: > 225.72.226.221.blackholes.five-ten-sg.com. > X-RBL-Warning: NOABUSE: "Not supporting [EMAIL PROTECTED]" > X-RBL-Warning: SORBS-DUL: "Dynamic IP Addresses See: > http://www.sorbs.net/lookup.shtml?221.226.72.225"; > X-RBL-Warning: IPNOTINMX: > X-RBL-Warning: NOLEGITCONTENT: No content unique to > legitimate E-mail detected. > X-RBL-Warning: REVDNS: This E-mail was sent from a MUA/MTA > 221.226.72.225 with no reverse DNS entry. > X-RBL-Warning: MS-SNAKEOIL: Message failed MS-SNAKEOIL: 52. > X-RBL-Warning: SPAMCHK: Message failed SPAMCHK: 3. > X-RBL-Warning: SPAMDOMAINS: Spamdomain '@yahoo.' found: > Address of [EMAIL PROTECTED] sent from invalid [No Reverse DNS]. > X-RBL-Warning: FALSE-YAHOO: Message failed FALSE-YAHOO test > (line 2, weight 30) > X-RBL-Warning: WEIGHT120349CP: Total weight between 120 and 349. > X-Declude-Sender: [EMAIL PROTECTED] [221.226.72.225] > X-Declude-Spoolname: Ddba001ae99e2.smd > X-Note: > X-Note: > == > X-Note: Spam Score: 333 [SUBJECT STRING ON 120-349 & DELETED ON 350+] > X-Note: Scan Time: 09:03:36 on 24 Oct 2005 > X-Note: Spool File: Ddba001ae99e2.smd > X-Note: Server Name: netrends.com > X-Note: SMTP Sender: [EMAIL PROTECTED] > X-Note: Reverse DNS & IP: [No Reverse DNS] [221.226.72.225] > X-Note: Organization: popmail.netrends.com > X-Note: Recipient(s): [EMAIL PROTECTED] > X-Note: Country Chain: CHINA->destination > X-Note: Tests Failed: CATCHALLMAILS [0], FIVETEN-SPAM [30], > NOABUSE [10], SORBS-DUL [50], IPNOTINMX [0], NOLEGITCONTENT > [0], REVDNS [40], MS-SNAKEOIL [150], SPAMCHK [3], SPAMDOMAINS > [20], FALSE-YAHOO [30], WEIGHT120349 [120], WEIGHT120349CP [120] > X-Note: In or Out: outgoing > X-Note: > == > X-Note: This E-mail was scanned & filtered > X-Note: filter [3.0.5.10] for SPAM & virus. > X-Note: > == > X-Note: > > # Suppress your appetite and feel full and satisfied all day > long # Increase your energy levels # Lose excess weight # > Increase your metabolism # Burn body fat # Burn calories # > Attack obesity And more.. > > http://coolhoodia.com/ > > # Suitable for vegetarians and vegans > # MAINTAIN your weight loss > # Make losing weight a sure guarantee > # Look your best during the summer months > > http://coolhoodia.com/ > > Regards, > Dr. Jon Addison > > > --- 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.
[Declude.JunkMail] Headers showing up in the body on 3.05.10
Ever since I went to 3.05.10 I've been receiving hundreds of complaints of spam making it to my users. After inspection, Declude is subject line marking the messages but it's moving the SMTP headers to the body of the email. This results in user's Outlook rules not firing on the subject line keywords. Here's an example of the ACTUAL MESSAGE BODY. -0- -Original Message- From: Jon Addison [mailto:[EMAIL PROTECTED] Sent: Monday, October 24, 2005 6:06 AM To: Smith, Mark E. Subject: Re: Hello. You've seen it on "60 Minutes" and read the BBC News report -- now find out just what everyone is talking about. Message-Id: <[EMAIL PROTECTED]> Subject: [WARNING-SPAM]:[333]: X-RBL-Warning: CATCHALLMAILS: X-RBL-Warning: FIVETEN-SPAM: 225.72.226.221.blackholes.five-ten-sg.com. X-RBL-Warning: NOABUSE: "Not supporting [EMAIL PROTECTED]" X-RBL-Warning: SORBS-DUL: "Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?221.226.72.225"; X-RBL-Warning: IPNOTINMX: X-RBL-Warning: NOLEGITCONTENT: No content unique to legitimate E-mail detected. X-RBL-Warning: REVDNS: This E-mail was sent from a MUA/MTA 221.226.72.225 with no reverse DNS entry. X-RBL-Warning: MS-SNAKEOIL: Message failed MS-SNAKEOIL: 52. X-RBL-Warning: SPAMCHK: Message failed SPAMCHK: 3. X-RBL-Warning: SPAMDOMAINS: Spamdomain '@yahoo.' found: Address of [EMAIL PROTECTED] sent from invalid [No Reverse DNS]. X-RBL-Warning: FALSE-YAHOO: Message failed FALSE-YAHOO test (line 2, weight 30) X-RBL-Warning: WEIGHT120349CP: Total weight between 120 and 349. X-Declude-Sender: [EMAIL PROTECTED] [221.226.72.225] X-Declude-Spoolname: Ddba001ae99e2.smd X-Note: X-Note: == X-Note: Spam Score: 333 [SUBJECT STRING ON 120-349 & DELETED ON 350+] X-Note: Scan Time: 09:03:36 on 24 Oct 2005 X-Note: Spool File: Ddba001ae99e2.smd X-Note: Server Name: netrends.com X-Note: SMTP Sender: [EMAIL PROTECTED] X-Note: Reverse DNS & IP: [No Reverse DNS] [221.226.72.225] X-Note: Organization: popmail.netrends.com X-Note: Recipient(s): [EMAIL PROTECTED] X-Note: Country Chain: CHINA->destination X-Note: Tests Failed: CATCHALLMAILS [0], FIVETEN-SPAM [30], NOABUSE [10], SORBS-DUL [50], IPNOTINMX [0], NOLEGITCONTENT [0], REVDNS [40], MS-SNAKEOIL [150], SPAMCHK [3], SPAMDOMAINS [20], FALSE-YAHOO [30], WEIGHT120349 [120], WEIGHT120349CP [120] X-Note: In or Out: outgoing X-Note: == X-Note: This E-mail was scanned & filtered X-Note: filter [3.0.5.10] for SPAM & virus. X-Note: == X-Note: # Suppress your appetite and feel full and satisfied all day long # Increase your energy levels # Lose excess weight # Increase your metabolism # Burn body fat # Burn calories # Attack obesity And more.. http://coolhoodia.com/ # Suitable for vegetarians and vegans # MAINTAIN your weight loss # Make losing weight a sure guarantee # Look your best during the summer months http://coolhoodia.com/ Regards, Dr. Jon Addison --- 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.
[Declude.JunkMail] Headers showing up in the body on 3.05.10
Ever since I went to 3.05.10 (on Friday) I've been receiving hundreds of complaints of spam making it to my users. After inspection, Declude is subject line marking the messages but it's moving the SMTP headers to the body of the email. This results in user's Outlook rules not firing on the subject line keywords. Here's an example of the ACTUAL MESSAGE BODY. Anyone else seeing this? -0- -Original Message- From: Jon Addison [mailto:[EMAIL PROTECTED] Sent: Monday, October 24, 2005 6:06 AM To: Smith, Mark E. Subject: Re: Hello. You've seen it on "60 Minutes" and read the BBC News report -- now find out just what everyone is talking about. Message-Id: <[EMAIL PROTECTED]> Subject: [WARNING-SPAM]:[333]: X-RBL-Warning: CATCHALLMAILS: X-RBL-Warning: FIVETEN-SPAM: 225.72.226.221.blackholes.five-ten-sg.com. X-RBL-Warning: NOABUSE: "Not supporting [EMAIL PROTECTED]" X-RBL-Warning: SORBS-DUL: "Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?221.226.72.225"; X-RBL-Warning: IPNOTINMX: X-RBL-Warning: NOLEGITCONTENT: No content unique to legitimate E-mail detected. X-RBL-Warning: REVDNS: This E-mail was sent from a MUA/MTA 221.226.72.225 with no reverse DNS entry. X-RBL-Warning: MS-SNAKEOIL: Message failed MS-SNAKEOIL: 52. X-RBL-Warning: SPAMCHK: Message failed SPAMCHK: 3. X-RBL-Warning: SPAMDOMAINS: Spamdomain '@yahoo.' found: Address of [EMAIL PROTECTED] sent from invalid [No Reverse DNS]. X-RBL-Warning: FALSE-YAHOO: Message failed FALSE-YAHOO test (line 2, weight 30) X-RBL-Warning: WEIGHT120349CP: Total weight between 120 and 349. X-Declude-Sender: [EMAIL PROTECTED] [221.226.72.225] X-Declude-Spoolname: Ddba001ae99e2.smd X-Note: X-Note: == X-Note: Spam Score: 333 [SUBJECT STRING ON 120-349 & DELETED ON 350+] X-Note: Scan Time: 09:03:36 on 24 Oct 2005 X-Note: Spool File: Ddba001ae99e2.smd X-Note: Server Name: netrends.com X-Note: SMTP Sender: [EMAIL PROTECTED] X-Note: Reverse DNS & IP: [No Reverse DNS] [221.226.72.225] X-Note: Organization: popmail.netrends.com X-Note: Recipient(s): [EMAIL PROTECTED] X-Note: Country Chain: CHINA->destination X-Note: Tests Failed: CATCHALLMAILS [0], FIVETEN-SPAM [30], NOABUSE [10], SORBS-DUL [50], IPNOTINMX [0], NOLEGITCONTENT [0], REVDNS [40], MS-SNAKEOIL [150], SPAMCHK [3], SPAMDOMAINS [20], FALSE-YAHOO [30], WEIGHT120349 [120], WEIGHT120349CP [120] X-Note: In or Out: outgoing X-Note: == X-Note: This E-mail was scanned & filtered X-Note: filter [3.0.5.10] for SPAM & virus. X-Note: == X-Note: # Suppress your appetite and feel full and satisfied all day long # Increase your energy levels # Lose excess weight # Increase your metabolism # Burn body fat # Burn calories # Attack obesity And more.. http://coolhoodia.com/ # Suitable for vegetarians and vegans # MAINTAIN your weight loss # Make losing weight a sure guarantee # Look your best during the summer months http://coolhoodia.com/ Regards, Dr. Jon Addison --- 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] Headers showing up in the body on 3.05.10
This has been a problem for awhile (happened with the move to the new architecture, but Declude says it's not connected.) The headers are "bad" when they make it to Declude, and Declude doesn't handle them right. Fortunately, in our setup, they all still get treated as very heavily weighted spam, so they never make it to users. Rob -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Smith Sent: Monday, October 24, 2005 6:17 PM To: Declude.JunkMail@declude.com Subject: [Declude.JunkMail] Headers showing up in the body on 3.05.10 Ever since I went to 3.05.10 (now on 3.05.11) I've been receiving hundreds of complaints of spam making it to my users. After inspection, Declude is subject line marking the messages but it's moving the SMTP headers to the body of the email. This results in user's Outlook rules not firing on the subject line keywords. Here's an example of the ACTUAL MESSAGE BODY. Anyone else seeing this? -0- -Original Message- From: Jon Addison [mailto:[EMAIL PROTECTED] Sent: Monday, October 24, 2005 6:06 AM To: Smith, Mark E. Subject: Re: Hello. You've seen it on "60 Minutes" and read the BBC News report -- now find out just what everyone is talking about. Message-Id: <[EMAIL PROTECTED]> Subject: [WARNING-SPAM]:[333]: X-RBL-Warning: CATCHALLMAILS: X-RBL-Warning: FIVETEN-SPAM: 225.72.226.221.blackholes.five-ten-sg.com. X-RBL-Warning: NOABUSE: "Not supporting [EMAIL PROTECTED]" X-RBL-Warning: SORBS-DUL: "Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?221.226.72.225"; X-RBL-Warning: IPNOTINMX: X-RBL-Warning: NOLEGITCONTENT: No content unique to legitimate E-mail detected. X-RBL-Warning: REVDNS: This E-mail was sent from a MUA/MTA 221.226.72.225 with no reverse DNS entry. X-RBL-Warning: MS-SNAKEOIL: Message failed MS-SNAKEOIL: 52. X-RBL-Warning: SPAMCHK: Message failed SPAMCHK: 3. X-RBL-Warning: SPAMDOMAINS: Spamdomain '@yahoo.' found: Address of [EMAIL PROTECTED] sent from invalid [No Reverse DNS]. X-RBL-Warning: FALSE-YAHOO: Message failed FALSE-YAHOO test (line 2, weight 30) X-RBL-Warning: WEIGHT120349CP: Total weight between 120 and 349. X-Declude-Sender: [EMAIL PROTECTED] [221.226.72.225] X-Declude-Spoolname: Ddba001ae99e2.smd X-Note: X-Note: == X-Note: Spam Score: 333 [SUBJECT STRING ON 120-349 & DELETED ON 350+] X-Note: Scan Time: 09:03:36 on 24 Oct 2005 X-Note: Spool File: Ddba001ae99e2.smd X-Note: Server Name: netrends.com X-Note: SMTP Sender: [EMAIL PROTECTED] X-Note: Reverse DNS & IP: [No Reverse DNS] [221.226.72.225] X-Note: Organization: popmail.netrends.com X-Note: Recipient(s): [EMAIL PROTECTED] X-Note: Country Chain: CHINA->destination X-Note: Tests Failed: CATCHALLMAILS [0], FIVETEN-SPAM [30], NOABUSE [10], SORBS-DUL [50], IPNOTINMX [0], NOLEGITCONTENT [0], REVDNS [40], MS-SNAKEOIL [150], SPAMCHK [3], SPAMDOMAINS [20], FALSE-YAHOO [30], WEIGHT120349 [120], WEIGHT120349CP [120] X-Note: In or Out: outgoing X-Note: == X-Note: This E-mail was scanned & filtered X-Note: filter [3.0.5.10] for SPAM & virus. X-Note: == X-Note: # Suppress your appetite and feel full and satisfied all day long # Increase your energy levels # Lose excess weight # Increase your metabolism # Burn body fat # Burn calories # Attack obesity And more.. http://coolhoodia.com/ # Suitable for vegetarians and vegans # MAINTAIN your weight loss # Make losing weight a sure guarantee # Look your best during the summer months http://coolhoodia.com/ Regards, Dr. Jon Addison --- 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 scanned for viruses by Declude Virus] --- [This E-mail scanned for viruses by Declude Virus] --- 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.
[Declude.JunkMail] Headers showing up in the body on 3.05.10
Ever since I went to 3.05.10 (now on 3.05.11) I've been receiving hundreds of complaints of spam making it to my users. After inspection, Declude is subject line marking the messages but it's moving the SMTP headers to the body of the email. This results in user's Outlook rules not firing on the subject line keywords. Here's an example of the ACTUAL MESSAGE BODY. Anyone else seeing this? -0- -Original Message- From: Jon Addison [mailto:[EMAIL PROTECTED] Sent: Monday, October 24, 2005 6:06 AM To: Smith, Mark E. Subject: Re: Hello. You've seen it on "60 Minutes" and read the BBC News report -- now find out just what everyone is talking about. Message-Id: <[EMAIL PROTECTED]> Subject: [WARNING-SPAM]:[333]: X-RBL-Warning: CATCHALLMAILS: X-RBL-Warning: FIVETEN-SPAM: 225.72.226.221.blackholes.five-ten-sg.com. X-RBL-Warning: NOABUSE: "Not supporting [EMAIL PROTECTED]" X-RBL-Warning: SORBS-DUL: "Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?221.226.72.225"; X-RBL-Warning: IPNOTINMX: X-RBL-Warning: NOLEGITCONTENT: No content unique to legitimate E-mail detected. X-RBL-Warning: REVDNS: This E-mail was sent from a MUA/MTA 221.226.72.225 with no reverse DNS entry. X-RBL-Warning: MS-SNAKEOIL: Message failed MS-SNAKEOIL: 52. X-RBL-Warning: SPAMCHK: Message failed SPAMCHK: 3. X-RBL-Warning: SPAMDOMAINS: Spamdomain '@yahoo.' found: Address of [EMAIL PROTECTED] sent from invalid [No Reverse DNS]. X-RBL-Warning: FALSE-YAHOO: Message failed FALSE-YAHOO test (line 2, weight 30) X-RBL-Warning: WEIGHT120349CP: Total weight between 120 and 349. X-Declude-Sender: [EMAIL PROTECTED] [221.226.72.225] X-Declude-Spoolname: Ddba001ae99e2.smd X-Note: X-Note: == X-Note: Spam Score: 333 [SUBJECT STRING ON 120-349 & DELETED ON 350+] X-Note: Scan Time: 09:03:36 on 24 Oct 2005 X-Note: Spool File: Ddba001ae99e2.smd X-Note: Server Name: netrends.com X-Note: SMTP Sender: [EMAIL PROTECTED] X-Note: Reverse DNS & IP: [No Reverse DNS] [221.226.72.225] X-Note: Organization: popmail.netrends.com X-Note: Recipient(s): [EMAIL PROTECTED] X-Note: Country Chain: CHINA->destination X-Note: Tests Failed: CATCHALLMAILS [0], FIVETEN-SPAM [30], NOABUSE [10], SORBS-DUL [50], IPNOTINMX [0], NOLEGITCONTENT [0], REVDNS [40], MS-SNAKEOIL [150], SPAMCHK [3], SPAMDOMAINS [20], FALSE-YAHOO [30], WEIGHT120349 [120], WEIGHT120349CP [120] X-Note: In or Out: outgoing X-Note: == X-Note: This E-mail was scanned & filtered X-Note: filter [3.0.5.10] for SPAM & virus. X-Note: == X-Note: # Suppress your appetite and feel full and satisfied all day long # Increase your energy levels # Lose excess weight # Increase your metabolism # Burn body fat # Burn calories # Attack obesity And more.. http://coolhoodia.com/ # Suitable for vegetarians and vegans # MAINTAIN your weight loss # Make losing weight a sure guarantee # Look your best during the summer months http://coolhoodia.com/ Regards, Dr. Jon Addison --- 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.
