1

I've noticed a flood of spam that is related to the same range of IPs.

All the spam email has different HTML text (which is english but meaningless) and a few embedded pictures (which I block) but actaully is clearly machine generated and the internal formatting is very similar. BTW all link and external pictures are blocked by my mailer.

What I have noticed is that the MX for the 'from' address domain all reside in a small range of IPs, all of them are on the same VPS service 'Node Outlet India LLP'. So somebody is using this service to host a farm of spambots.

I would like to generate a spamassassin rule that says something like:

  • Extract the 'from' domain
  • Look up MX of that domain
  • Look up IP of that MX
  • Does it look like 36.255.24.x/21
  • Give it a high score, e.g. +2

I use spampd proxy and spamassassin running on Linux.

To clarify, here is an example: The spam email is from buymystuff@stufftobuy.com

The source email passes SPF, DMARC and is DKIM signed - all legit - but it's spam. By just those checks alone it scores well as ham.

The only thing spammy about it is the content. Mostly HTML and out of domain link embedded pictures and little text, only those features makes it have a spam score at all, but not a large one. These emails are clearly designed to avoid anti-spam measures.

I do an MX RR DNS lookup on stufftobuy.com and you get mail.stufftobuy.com, do a A RR DNS lookup on mail.stufftobuy.com and it returns an IPV4 from one a handful of address rages that all the from domain MX records point to.

I need to do more analysis but it seems to be from just two server farms, one in India the other in Turkey.

Of 1000 emails, a single IPV4 may only appear twice.

I can't just score or block stufftobuy.com as that actual domain name may only be used once. The next message may be from makecatvids.com or whatever.

Equally I can't just blindly block thousands of IPV4 in postfix as that would make the assumption that the ISP is bad rather than one of their customers.

UPDATE: I can see the askdns plugin exists, but I can't see how one rule can feed into another. A single DNS lookup is not enough.

Jay M
  • 378
  • 4
  • 11
  • Are you using some MTA (like postfix)? Usually, we do this kind of block directly on the MTA. – JucaPirama Nov 14 '19 at 16:22
  • MX records dictate where *you* should send *outgoing* mail to that domain. Is the spam also *originating* from that same IP range? If so, then the MX records are irrelevant, and you could simply blacklist the IP range that is sourcing the spam. – Jim L. Nov 14 '19 at 23:05
  • The IP source keeps changing. What I have noticed is that the address range of the MX pointed to by the from domain always has the same (large) address range. – Jay M Nov 15 '19 at 14:59

1 Answers1

1

Vastly more important: Make sure you're using sender IP reputation e.g. via Spamhaus Zen and the SpamCop Blocking List. These are already included in SpamAssassin by default (see RCVD_IN_PBL and RCVD_IN_BL_SPAMCOP_NET), just make sure you have Mail::SpamAssassin::Plugin::DNSEval properly loaded and that you're running with network tests enabled (which is also required for AskDNS).

Mail::SpamAssassin::Plugin::AskDNS cannot do this. You'd need to write your own plugin to do exactly what you're looking for.

However, perhaps this use of AskDNS can get you close:

ifplugin Mail::SpamAssassin::Plugin::AskDNS

askdns   JM_SPF_HAS_36_255 _AUTHORDOMAIN_ TXT /\sip4:36\.255\.(?:2[0-4]|3[01])\./
describe JM_SPF_HAS_36_255 From header's SPF record blesses an IP in 36.255.24.0/21
score    JM_SPF_HAS_36_255 2.0

endif

This checks the Sender Policy Framework (SPF) record for the header From domain. Caveats:

  • SPF is a list of hosts permitted to send mail on behalf of a domain (see below)
  • SPF checks domains in the SMTP connection's HELO & mail from commands, not headers
  • SPF records can contain domains, can include other records, etc, yet this rule only looks at IPs
    For example: v=spf1 ip4:198.51.100.21 mx a include:example.com ~all has issues:
    • Only one IP is explicitly listed here, and it doesn't match
    • The MX record might match, but it's listed as just mx and we can't resolve that to an IP
    • Ditto for the A record
    • Ditto for the inclusion; perhaps it has an a or another include:… that may list this IP

Regarding that first bullet: the MX record refers to receiving mail, so I consider SPF's list of permitted sending hosts to be more relevant in the general case, though I can't speak to your exact intention.

Update: You mentioned that these spams are DKIM-signed. Assuming they all share the same signing domain, just block based on that (no network lookup needed!):

header   JM_DKIM_EVIL_EXAMPLE_COM  DKIM-Signature =~ /\sd=evil\.example\.com;/
describe JM_DKIM_EVIL_EXAMPLE_COM  Message has DKIM signed by evil.example.com
score    JM_DKIM_EVIL_EXAMPLE_COM  2.0

You'll need one of these rules per signing domain (d=…) you find, which I expect is a small number.
Alternatively, you could use a regex alternation. For example:
/\sd=(?:(?:evil|spammer)\.example\.com|bad\.example\.info);/ will block d=evil.example.com;, d=spammer.example.com;, and d=bad.example.info;.

Adam Katz
  • 951
  • 8
  • 17
  • Thanks I did not think of looking at that. I'll go through the spam archive and see what comming signing domainds are used. Though given virtuall every email seems to come from a different domain I expect that've just automated the creation process, bulk buying domain names or running their own NS. – Jay M Nov 22 '19 at 09:41
  • P.S. I'm getting somewhere with normal rules. I've noticed certain patterns in the small quantity of text that I can create simple rules for. I thought the answer might be a custom plugin. Sadly of the many languages I have learned in my time PERL is not on the list, but maybe that will have to change. – Jay M Nov 22 '19 at 09:48