NOTE: All sender domains and IP’s have been replaced with a unique name.
CHKUSER accepted sender: from <[email protected]::> remote <na01-by2-obe.outbound.protection.outlook.com:unknown:10.189.254.17> rcpt <> : sender accepted spamdyke[8804]: DENIED_OTHER from: [email protected] to: [email protected] origin_ip: 10.189.254.17 origin_rdns: (unknown) auth: (unknown) encryption: TLS reason: 550_See_http://spf.pobox.com/why.html?sender=Joe-Customer%40mydomain.com&ip=10.189.254.17&receiver=mail-01.mydomain.com_(#5.7.1) CHKUSER accepted sender: from <[email protected]::> remote <na01-bn1-obe.outbound.protection.outlook.com:unknown:10.189.254.17> rcpt <> : sender accepted spamdyke[16794]: DENIED_OTHER from: [email protected] to: [email protected] origin_ip: 10.189.254.17 origin_rdns: (unknown) auth: (unknown) encryption: TLS reason: 550_See_http://spf.pobox.com/why.html?sender=Joe-Customer%40mydomain.com&ip=10.189.254.17&receiver=mail-01.mydomain.com_(#5.7.1) CHKUSER accepted sender: from <[email protected]::> remote <na01-bn1-obe.outbound.protection.outlook.com:unknown:10.189.254.17> rcpt <> : sender accepted spamdyke[31470]: DENIED_OTHER from: [email protected] to: [email protected] origin_ip: 10.189.254.17 origin_rdns: (unknown) auth: (unknown) encryption: TLS reason: 550_See_http://spf.pobox.com/why.html?sender=Joe-Customer%40mydomain.com&ip=10.189.254.17&receiver=mail-01.mydomain.com_(#5.7.1) On Mar 11, 2014, at 11:57 AM, Eric Shubert <[email protected]> wrote: > I would expect the SPF patch to be checking the (assuming public) IP of the > sending server. Is this not the case? > > An example from your smtp log might be helpful. qmlog can find this easily > for you. > > -- > -Eric 'shubes' > > On 03/11/2014 08:49 AM, Scot Needy wrote: >> 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] >> >> > > > > > --------------------------------------------------------------------- > 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]
