Appears to be a valid deny based on the senders domain SPF rules. The postmaster for the domain rejected confirms the connection and the SPF deny list.
I can get them to update the list but we would both prefer a public IP that would be difficult to spoof. On Mar 11, 2014, at 11:37 AM, Eric Shubert <[email protected]> wrote: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
