Hello Simon, Thursday, November 13, 2003, 5:54:48 AM, you wrote:
S> -----BEGIN PGP SIGNED MESSAGE----- S> Hash: SHA1 S> Hello Mark, S> On Thu, 13 Nov 2003 04:49:36 -0700 your time, you said: PA>>> Have you tried placing the filter topmost, so that it is executed PA>>> prior to all other (inbox-)filters (just to make sure it's not PA>>> other filters that keep your new filter from working)? MT>> I have tried this. It has been in several locations. I just tested MT>> it at the top. Same story. S> I tried it with the .msg files you sent me. So far I can only get one S> file to filter: the Sasha Mcneill <[EMAIL PROTECTED]> spam message S> using " Digital Cable " as the filter string, directly copied and S> pasted from the _source_ I.e *View Source* and copy the S> [sp]Digital[sp]Cable[sp] including the whitespaces and paste that into S> the strings field. However, spam no2 is different. Simon, I'm back awake again after 2hrs. Please clarify the above statement. When I view source on Sasha Mcneill, I see plain text without quotes "Digital Cable". Spaces before Digital and between Digital and Cable. Is this what you see, or is there actually a [sp] displayed? If there is no [sp], I wonder why my filter is not working?????? If there IS [sp] what exactly did you do to view this? S> The key to spam message no 2 is I think a combination of the MIME S> "Content-Type: multipart/alternative;" header, a breaking of the RFC S> standards, and exploiting the way in which unknown tags are handled in S> HTML renderers. It seems to me that the it goes like this: S> 1. Create a "Content-Type: multipart/alternative;" message. This is S> done to send a multipart message containing a plaintext message and a S> html message so if your mail client doesn't allow html viewing you get S> to see a plain text message instead. S> 2. Break the rules: deliberately fail to add a text/plain; declaration S> after the MIME header as is required in the RFC and instead add the S> html declaration first: "Content-Type: text/html;" as the second part S> of the message. This means that the message will now *appear* to S> display as text even though it's really html. S> 3. Randomly pack out the HTML message part with useless tags: as we S> know, all unknown tags in HTML are ignored so they don't show up and S> nothing is rendered. S> So you have no true plaintext to filter against because there isn't S> any text part to the message, and the text in the html part of the S> message is masked by phoney html tags so you can't get a full string S> to filter against. S> I'd definitely use SpamPal for this. I don't know whether there's a S> way around it, but it would save a lot of headwork to use something S> that would catch it without any problems. I appreciate this comment. So we are assuming that the developers of SpamPal have scratched their heads until "Raw", and have figured these type of things out and build it into their software, and must continually update the definitions by subscription service that we download to stay up to date with the latest Spam techniques. Have I got this right? -- Best regards, Mark mailto:[EMAIL PROTECTED] ________________________________________________ Current version is 2.01.3 | "Using TBUDL" information: http://www.silverstones.com/thebat/TBUDLInfo.html
