On 03/11/2014 08:16 AM, Scot Needy wrote:
SPAM dyke is working great but I am also getting false positives from my clients SPF records.
Just to be clear, SPF checking doesn't happen in spamdyke. Yet. This might be a feature of spamdyke in the future.
In the meantime, I've seen problems in the past with the qmail SPF patch. I've backed off the spfbehavior setting on my QMT hosts to '1' so SPF isn't enforced. I don't recall the specific circumstances of the problem.
I expect that Sam will get it right in spamdyke though. Plus, I think spamdyke is the logical place for this checking to happen. So the long term plan is to have spamdyke implement SPF, and to remove the qmail SPF patch from QMT (as opposed to trying to fix the patch). Just FYI.
Have you determined if your FPs are errors on the client's part (erroneous SPF records) or if it appears to be a bug in the SPF patch?
Back to the NAT issue. spandyke is testing SPF records against it’s local internal IP and failing to send the traffic.
This would be the qmail SPF patch, not spamdyke. Also, I'm not sure what you mean by this. Can you give an example please?
Mail administrators are not keen to adding non routable IP addresses to their SPF allow lists because anyone can forge this IP through a personal NAT. So back to the NAT question. Would there be a way to tell spamdyke that it’s local ip is really the outside routable IP of the NAT ?
I think there's some confusion here. I'm not aware of the SPF patch checking NAT'd addresses. It should be (and does as far as I'm aware) check the public address of the sending server.
-- -Eric 'shubes' --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
