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


Reply via email to