And on a totally unrelated note, is there any way enforce a rule to only be true if it applies for an individual MIME body part?
For instance, I might test for a mimeheader of Content-Transfer-Encoding being “7bit”, but also having seen BODY_8BITS… but I need them to both be true in an individual mime part. It doesn’t do me any good if there’s one text/plain section that is 7bit, followed by another text/html section that’s “base64” which fires the BODY_8BITS rule too. On Jun 25, 2014, at 2:21 PM, Philip Prindeville <philipp_s...@redfish-solutions.com> wrote: > I was surprised that my SPAM filters didn’t find this. > > Not sure what code page it’s using… whatever 0x04xx is in… what? Is this > UTF-8? > > There’s no explicit charset given. > > Also, I noticed that a lot of these types of SPAMs have ‘b’ replaced by > cyrillic soft sound, i.e. the word “about” is written as > аЬоut instead. > > Here’s the entire message. > > http://pastebin.com/qLyKx40b > > Here’s what I’m showing it matched: > > Jun 25 11:16:07 mail mimedefang.pl[18682]: s5PHFqsC019802: s5PHFqsC019802: > 4.889 (****) > BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VERIFIED,HTML_MESSAGE,L_BLOCK_ISP,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD > > Odd that it didn’t match MIME_CHARSET_FARAWAY or CHARSET_FARAWAY_HEADER or > any rules about excessive redundant encoding. > > Would it be a lot of work to the number of ETH (D w/ STROKE, whatever) > followed by 3/4 character pairs? > > Here’s the other thing I don’t get. > > The message claims to be 7-bit and text/plain, yet it uses encoded characters > which exceed 7-bit widths yet this doesn’t seem to be firing any rules either. > > Ь would seem to be at least an 11-bit wide character. > > Are we being “too liberal in what we accept”? > >
