What is deep header inspection?
Some anti-spam tools will actually look at the reputation of IP addresses in each of the received headers of an email. Reputation mechanisms usually involve multiple sources, e.g., DNSBLs and Honeypot-driven reputation services.
Here’s a sample header:
Delivered-To: address@gmail.com
Received: by 1.1.1.1 with SMTP id e5cs33412ibd;
Fri, 16 Apr 2010 08:38:08 -0700 (PDT)
Received: by 1.2.2.2 with SMTP id e9mr1978437rvi.51.1271432287560;
Fri, 16 Apr 2010 08:38:07 -0700 (PDT)
Return-Path: me@mydomain.com
Received: from SERVER.somedomain.com (mail.somedomain.com [3.3.3.3])
by mx.google.com with ESMTP id 11si4715430qyk.0.2010.04.16.08.38.06;
Fri, 16 Apr 2010 08:38:07 -0700 (PDT)
Received: from myserver.mydomain.com (unverified [4.4.4.4]) by SERVER.somedomain.com
(XYZ MTA) with ESMTP id <B0001262286@SERVER.somedomain.com> for <address@gmail.com>;
Fri, 16 Apr 2010 11:38:08 -0400
Bolded: IP addresses that will be verified.
Problem
Since some of the IP reputation systems used are DNSBLs, some administrators might unwittingly use IP lists that cover dynamic IP ranges used by ISPs. These IPs are not supposed to be used for sending email directly (such as those used by a DSL or cable modem), but which should be able to send email indirectly (such as through their ISP). Examples: pbl.spamhaus.org and dul.dnsbl.sorbs.net.
What happens?
Messages sent out by ISP end-users will be bounced or quarantined because the administrator is (incorrectly) using DNSBLs that cover dynamic IP ranges.
In fact, the folks who maintain the Spamhaus1 PBL list explicitly warn against the use of such measures:
Caution: Because the PBL lists normal customer IP space, do not use PBL on smarthosts or SMTP AUTH outbound servers for your own customers (or you risk blocking your own customers if their dynamic IPs are in the PBL). Do not use PBL in filters that do any ‘deep parsing’ of Received headers, or for other than checking IP addresses that hand off to your mailservers.
What to do
Make sure you carefully research any DNSBLs you plan to use with deep header inspection prior to putting them into operation. Otherwise, you might wind up shooting yourself in the foot!
Reference:
pbl.spamhaus.org
My solution to some of this would be! have a standard for the DNS reply codes..
127.0.0.2 reply = blocked for reason A
127.0.0.3 reply = blocked for reason is dynamic
127.0.0.4 reply = blocked for reason is open relay
and so on.. so then the mail sysop can, through software or rule, how do deal with each reply type.
Some DNSBLs (SORBS.NET I believe) already segment their response codes.