Blocking of valid incoming emails with iRedAPD policy server
MTAs have a timeout limit for external server processes (e.g., policy servers or milters). For example, using a policy server like iRedAPD, the postfix MTA will wait for the completion of a process until it reaches its timeout limit, which is set by default to 100 seconds (policy_service_timeout). Since iRedAPD processes SMTP connections in a sequential manner, attackers can exploit this timeout mechanism: they do this by designing the SPF record of the sending domain to return with deliberate delays, thereby disrupting valid incoming email delivery within a specific timeframe.
Here's the scenario: attackers require a domain and a custom authoritative server for that domain, both of which can be relatively easily obtained and controlled. Consider an attacker owns a domain named a.com. Given iRedAPD's SPF lookup limit of 20, the attacker can configure a.com's SPF record requiring 20 lookups. By controlling the domain with a custom authoritative server, the attacker can introduce a delay of up to 3 seconds for each lookup (since iRedAPD allows up to 3 seconds for each DNS query). This setup extends the SPF validation time to 60 seconds in total (20 lookups * 3 seconds each).
One might argue that the DNS resolver's timeout could be shorter than 3 seconds, but this limitation can be bypassed: with CNAME record expansion. Attackers can use CNAMEs to create chains for domains included in the SPF record, and this expansion is handled by the resolver, not the SPF validator. This strategy increases the number of queries to the authoritative server without affecting iRedAPD's maximum lookup threshold.
With this scenario, if two emails are sent at t0, SPF validation for these couple emails will complete at time t120. This means, any benign emails being sent within t0 and t20 is going to be rejected since policy_service_timeout will be invoked. This is illustrated in the attached figure. Here t_lim is individual DNS query resolution time and T_lim is total SPF resolution time.
Dear @spf-measurement
would you like to send a PR to help fix it? :)