SPF check "Multiple redirections/includes to the same domain detected" - ORF Forums

SPF check "Multiple redirections/includes to the same domain detected" RSS Back to forum

1

Lately, we're seeing an increasing number of spam messages coming through, mostly from randomly generated (but valid) [3 characters].[6 characters].com addresses. They share the same trivial recursion in their SPF records, and the domains are served by the same NS servers.

We are wondering if it is (or would be) possible to block mails based on the NS server(s) of the TLD, in this case *.dnspod.net. Blocking based on the trivial recursion in the SPF record is probably easily circumvented by the spammers.



As mentioned, we have found the following to be common for these messages:

1) Trivial recursion in the SPF record.
ORF reports this as " Multiple redirections/includes to the same domain detected. Processing aborts.", and, as far as we can tell, stops after the (configurable) recursion limit of 20.

http://www.kitterman.com/getspf2.py reports this as:
"Results - PermError SPF Permanent Error: include has trivial recursion: include:ngyu02.gxjfsm.com"

2) Common NS records

All the domains are served by the following NS servers:

f1g1ns1.dnspod.net. ['119.167.195.3', '122.225.217.192', '182.140.167.166', '183.60.52.217'] [TTL=172800]
f1g1ns2.dnspod.net. ['112.90.143.29', '122.225.217.191', '180.153.162.150', '182.140.167.188'] [TTL=172800]

Blacklisting the domains used is unfeasible, since they are randomly generated, and there is a staggering amount of them. The IP addresses that get through are not listed in the Spamhaus CSS snowshoeing list.
The name server tools at gWebTools.com currently report approximately 1.5 million different domains:

http://www.gwebtools.com/ns-spy/f1g1ns1.dnspod.net
http://www.gwebtools.com/ns-spy/f1g1ns2.dnspod.net




Example 1:

SPF record for ngyu02.gxjfsm.com:
"v=spf1 include:ngyu02.gxjfsm.com ~all"

DNS details:
http://www.intodns.com/check/?domain=gxjfsm.com

Excerpt from log:

-- EVENT SUMMARY --
Time: 09.10.2014 15:09:04 GMT+0200 W. Europe Daylight Time
Sender Email:
Recipient Email: [removed]
Related IP: 218.241.11.85
Action: (not available)
Email Subject: Bluetooth Speaker&Mini Speakers

-- EVENT MESSAGE --
Error checking the SPF policy of domain "ngyu02.gxjfsm.com": Multiple redirections/includes to the same domain detected. Processing aborts.

-- EVENT DETAILS --
Filtering Point: On Arrival
Event Class: System Message
Severity: Warning
Server: [removed]
Event Source: MSEXCHANGE
HELO Domain: (not available)
Message ID: (not available)
Log Mode: Verbose
ORF Version: 5.3 REGISTERED



Example 2:

SPF record for zga.dgkjuc.com:
"v=spf1 include:zga.dgkjuc.com ~all"

DNS details:
www.intodns.com/check/?domain=dgkjuc.com

-- EVENT SUMMARY --
Time: 10.10.2014 02:38:55 GMT+0200 W. Europe Daylight Time
Sender Email:
Recipient Email: [removed]
Related IP: 218.241.8.174
Action: (not available)
Email Subject: Pet Products

-- EVENT MESSAGE --
Error checking the SPF policy of domain "zga.dgkjuc.com": Multiple redirections/includes to the same domain detected. Processing aborts.

-- EVENT DETAILS --
Filtering Point: On Arrival
Event Class: System Message
Severity: Warning
Server: [removed]
Event Source: MSEXCHANGE
HELO Domain: (not available)
Message ID: (not available)
Log Mode: Verbose
ORF Version: 5.3 REGISTERED

by dg 9 years ago
2

@dg: Unfortunately, ORF does not have any built-in mechanism for blacklisting emails based on NS records or SPF recursion issues. (On a related note, SPF recursion issues are actually detected during evaluation as they occur, definitely before the recursion limit would be reached -- that's another safety mechanism to prevent malicious policies from exhausting resources).

Anyway, as dnspod.net is an otherwise legitimate provider, I would not recommend using NS heuristics to blacklist all emails coming from domains served by their name servers. However, the way how the SPF policy is set up for these domains is clearly malicious and can't be easily attributed to operator error. With this in mind, I've written a simple PowerShell script that can be attached to ORF as an External Agent to check if the sender has an SPF policy that exhibits the pattern you described.

You can download the agent from http://vamsoft.com/downloads/agents/spfselfagent.zip.

To set up the agent, add a new External Agent in ORF and

1) Set the Agent Executable to your PowerShell binary (PS 2.0 is required), e.g. C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

2) For the Command-Line Parameters field, set -NoLogo -ExecutionPolicy Bypass -File C:\orf\spfself.ps1 {SENDER} (be sure to replace C:\orf\spfself.ps1 with your path).

3) Set up blacklist action for Exit Code 1.

You will also need to customize spfself.ps1 with your own paths and DNS settings (see TODO entries in the file).

With some effort, the script can be customized for NS record checking, but I believe that may cause false positives with legitimate dnspod.net domains.

by Péter Karsai (Vamsoft) 9 years ago
(in reply to this post)

3

@Péter Karsai (Vamsoft): Perfect, thanks a lot! It is successfully blocking the offending senders.

External Agent support is an extremely handy and powerful feature.

by dg 9 years ago
(in reply to this post)

4

@dg: I'm glad to hear it helped. External Agents can indeed come handy and given how PowerShell is becoming the de facto management tool for Microsoft products and how powerful it is, I think it's a great choice for agents. I'll see if I can find time to write an article about this topic in the coming weeks.

by Péter Karsai (Vamsoft) 9 years ago
(in reply to this post)

New comment

Fill in the form below to add a new comment. All fields are required. If you are a registered user on our site, please sign in first.

It will not be published.
hnp1 | hnp2