On Thu, 2019-11-21 at 14:22 -0700, Grant Taylor wrote: > I like the logic. > > Unfortunately, you need to be very careful as you start to run into > all the text permutations / homograph attacks. > Fair comment. What you saw was hacked together to show the principle, but not tested.
Here's a tested version. In testing this I've assumed that if either the name or the address isn't an exact match then the rule should fire. This tests as fairly bullet proof: describe SPOOFED_MAYOR Check for spoofed mail from the Mayor header __SM1 From:name =~ /^John M Mayor$/ header __SM2 From:addr =~ /^john\@cityhall\.com$/ meta SPOOFED_MAYOR (__SM1 && ! __SM2) || ! _SM1 score SPOOFED_MAYOR 5.0 > This type of rule may accidentally incur false positives too, so be man > careful. > Indeed. My original rule, fires if the name part contains '@' or the address part contains a space, can almost be checked by inspection. The rule shown above requires the /^required text$/ construct to prevent additions at either end of the required strings from slipping past un- noticed. The final " || ! __SM1" meta term is only needed if you want to ensure that the name part must also be an exact match, i.e. you assume that the user will notice that the sender name isn't quite right, but a careful rule writer would not rely on that, hence its inclusion. It is not, however, needed for my original use of this rule type, which uses two long lists, e.g. common selling phrases and products being offered, simply assumes that any email that contains at least one match from each list is spam. Given carefully chosen phrases that have been seen in actual spam, my experience over several years shows that this type of rule is pretty resistant to FPs while still spotting spam using list content pairs that haven't been previously encountered. Martin