Quote:
Originally Posted by blargman
If the ISP has the policy of putting their ip's in the PBL. There's pretty much nothing that can be done except for forging the Received From: headers yourself. Otherwise they need to use the ISP's outbound servers. That's my idea of the matter anyway. Though I thought this was just for unauthenticated mail, I'm seeing an issue of it myself currently with authenticated mail. :\ It's showing ESMTPA in the header yet SpamHaus is still blocking it.
|
Something to watch out for regarding this, it'll depend upon how the remote MTA is evaluating the RBL
If they're checking the connecting IP, even mangling/rewriting the Received header won't do the trick - the connecting IP will still be exposed, queried, and buggered. The headers won't be visible until the DATA command is sent, acknowledged, etc.
The other thing to point out, is the "Received" header that the remote MTA creates is one you'll have no control over - and is the one most likely to contain your IP. So to that end, you'd be somewhat stuck.
Generally RBL providers (among others) will recommend that with lists such as the PBL, you query *only* the connecting IP against the blacklist - reason being, it is perfectly legitimate for a host on a dynamic IP to connect to their ISP's SMTP server and send away; in fact, this is what Spamhaus recommends if you're listed on the PBL (assuming the listing isn't in error). If you do deep header parsing, and query every IP found against an RBL (such as Spamhaus PBL) which is intended solely to restrict what IP's are allowed to connect directly, you end up with a considerable amount of what are by most accounts false positives.
Similar logic applies for those using the ZEN aggregate zone - if you utilize ZEN, and do deep header parsing (a practice which is generally not recommended) for RBL checks, the return code should be evaluated beyond the topmost (or most recent, rather) header and only trigger policy if found in SBL-XBL, but not PBL. A listing on SBL-XBL 2 or 3 layers deep is cause for suspicion. A listing on PBL 2 or 3 layers deep is not.
At any rate, rather than continuing on this tangent....headers are very, very easily forged, and no *single* header is a reliable indicator of spam. Tis usually best to consider the makeup of the header, or extract specific tokens that are common to mail sent from botnets.
Hope this helps someone, and doesn't bore everyone to sleep