On 08/18/2014 02:15 PM, Angus McIntyre wrote:
I’m seeing an uptick in a particular type of spam that I would very much like to filter. Fortunately, the spam has a quite distinctive fingerprint: the envelope sender of each message matches the regex:^[A-Za-z0-9_-]+-realuser=realdomain\.realtld\@[a-z0-9-]+\.[a-z]{2,4}$ (where ‘realuser’, ‘realdomain’ and ‘realtld’ jointly match an email address hosted on my server. For example, if I had a user ‘[email protected]’, the envelope sender on the spams might look like: [email protected] The ‘fred=example.com@’ is pretty distinctive for this spammer. There are a few legitimate domains that use an approximately similar convention, but the regex above will not match them. spammydomain.com, obviously, changes from run to run. They seem to be snowshoe’ing their way all over Cloudflare, with a few instances on HiVelocity. My impression is that Spamdyke’s sender blacklists only allow simplified wildcards, i.e. specifying @example.com to block all email from the ‘example.com’, so that’s probably not an option. Spamdyke’s header blacklist feature is slightly more complex/capable, but doesn’t match on the envelope sender (or allow me the full expressiveness I need). I could add a SpamAssassin rule to take care of these cases, but the way my system is configured, SpamAssassin will only flag spam, not delete it. Some of the addresses targeted by this particular spammer are set to forward to external systems, so — in order to preserve the reputation of my mail server — I’d like to kill this spam dead. I could use procmail, but this is something of a hassle. So before I go down that route, I wanted to ask whether there’s anything in the qmailtoaster toolbox that would allow me to block email based on applying the regex above to the envelope sender. I could also just use iptables to block CloudFlare entirely, but that seems a little extreme. Any suggestions would be gratefully received. Angus --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Sorry to delay my reply to this. I wanted to see if anyone would chime in on this. I guess not (yet). (C'mon folks!)
I too have seen an uptick in spam recently. There are 3 or so that are persistent daily, and sa-learn doesn't seem to be learning them well enough (or maybe fast enough) to tag them.
I haven't had a chance to dig into them yet before now. I've had a look at a few of them, they appear to fit your observation.
The good news is that the badmailto file can handle regexes. The problem would be having to define a separate entry for each address, which wouldn't be practical.
The bad news is that this form of address is perfectly legit for mailing lists. If you implemented this filter, I expect you'd no longer get messages from this list. (Oops!)
Of course, we'd all love to nail these suckers. They seem to be pretty diligent though, to the point of even having valid SPF and DKIM configurations.
The only tool we have at this point that I can see is SA. I think with a little tuning we should be able to get SA to recognize these, even if we have to write a new rule or two.
On second thought, one in particular that I'm seeing appears to be a phishing attempt. I haven't installed sane security (clamav additional signatures) on my new server yet. I'll do that, and see if these new spams keep coming or not.
If they persist, then I suggest delve deeper into SA. All the spams appear to have one or more links in the content which matches the domain of the sender. I wonder if that couldn't be used somehow. Isn't there a BL of sorts in SA that examines the domains of the urls in the message? I wonder if that's not working, or the spammers are just changing domains so fast that it's not effective. Or perhaps the SA scoring just needs a little tweaking for those rules.
TIA for everyone's input on this. -- -Eric 'shubes' --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
