https://issues.apache.org/SpamAssassin/show_bug.cgi?id=4255
Lorens Kockum <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #33 from Lorens Kockum <[email protected]> --- (In reply to Theo Van Dinter from comment #24) > Hopefully this will put this idea to bed, or allow people to figure out a > way to deal with the false > positives (by all means, if you come up with a useful way to check for this > sans FPs, let us know!) As an > example of FPs: > > <a > href="http://www65.americanexpress.com/clicktrk/Tracking?mid=MESSAGEID&msrc=ENG- > ALERTS&url=https://www.americanexpress.com/estatement/?12345";>https:// > www.americanexpress.com/estatement/?12345</a> > > <A > HREF="http://echo.epsilon.com/WebServices/EchoEngine/T.aspx?l=ID";>https:// > www.hilton.com/en/ww/email/tab_email_subscriptions.jhtml</A> Can't do anything about the second one, but I am shouldering an annoying amount of phishing that misrepresents the phishing HREF URL with a legitimate URL in the text label. After coming here to find out why this was not already a high-scoring SA rule, I wrote this which only checks that domains are the same to the second level. I think you'd need a second rule if you want to hit on falsified co.uk and such. full MISLEADING_URL_LABEL m{href="https?://([^"/]*\.)?([^\."/]+\.[^\."/]+)(/[^"]*)?"[^>]*>https?://(?!([^"/]*\.)?\2["/])([^/]*)} describe MISLEADING_URL_LABEL An A label seems to be a URL but its SLD.TLD differs from the actual URL in the HREF I would be very interested in learning what effect this has on a big corpus! -- You are receiving this mail because: You are the assignee for the bug.
