On Sat, 2017-11-25 at 14:37 -0600, David Jones wrote: > With that rule as it stands, an easily spoofed "Amazon > <ord...@myamazon.com>" would not hit FAKE_AMAZON_FROM. Even if the > rule specified "@amazon.com," then native DMARC support would be > needed to block spoofed From: headers for the next amazon.com > spoof. Since SA doesn't have native DMARC support, every SA instance > would have to locally manage hundreds of these high-profile targets > for phishing. > Yes, agreed, and I wouldn't normally use anything like that as a serious rule recognising bad senders: if, as I have, you've got a mail archive it's better to use that to see whether you've ever sent mail to the sender of the message being checked. Theres no BL posting delay either.
I was trying to pass on the principle of combining two or more simple rules (often one or more would contain an alternates list) that aren't much use by themselves, but by combining them can become a rather specific spamtrap and, possibly rather stupidly, thought I'd use this as an example of how to use metsa rules. I originally started using the technique when OI was a member of a software-specific mailing list that carried huge amounts od sales spam bevcause (a) its mailing list had no spam detectors and very poor moderation and (b) also shared messages with an equally poorly defended web forum. I rapidly found that if I used two alternates-based rules, one for sales terms/phrases commonly used in spam and the other for product names and generic terms, then the meta-combo was remarkably spam-specific and FP-free to thre point that it woulkd even reliably recognise spam using new combinations of sales phrase and product. Martin
