reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Bill Cole
I recently updated a Postfix system from 2.4 to 2.9 and I have found what I believe is a change in behavior for reject_unknown_sender_domain which is confusing. In the past, an effective means of dealing with some classes of persistent spammers was to tell the local DNS resolver (BIND 9) to

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Noel Jones
On 10/3/2012 1:15 PM, Bill Cole wrote: I recently updated a Postfix system from 2.4 to 2.9 and I have found what I believe is a change in behavior for reject_unknown_sender_domain which is confusing. In the past, an effective means of dealing with some classes of persistent spammers was to

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Wietse Venema
Bill Cole: I recently updated a Postfix system from 2.4 to 2.9 and I have found what I believe is a change in behavior for reject_unknown_sender_domain which is confusing. In the past, an effective means of dealing with some Sort answer: Postfix does not pass SERVFAIL, it just rejects them

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Bill Cole
On 3 Oct 2012, at 14:48, Wietse Venema wrote: Bill Cole: I recently updated a Postfix system from 2.4 to 2.9 and I have found what I believe is a change in behavior for reject_unknown_sender_domain which is confusing. In the past, an effective means of dealing with some Sort answer:

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Ralf Hildebrandt
DNS is definitely failing for dfleur.com, as the hit on the SA rule NO_DNS_FOR_FROM indicates and as confirmed by a manual query: ~$ dig dfleur.com mx ; DiG 9.8.1-P1 dfleur.com mx ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 47102 ;; flags: qr rd ra;

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Wietse Venema
Bill Cole: ; DiG 9.9.1-P3 dfleur.com mx ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 41183 How will I reproduce this quickly? Wietse

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Viktor Dukhovni
On Wed, Oct 03, 2012 at 04:00:05PM -0400, Bill Cole wrote: reject_unknown_sender_domain This is what I would expect, based on the documentation. However, it is accepting and delivering mail whose sender domain yields a SERVFAIL and I can't figure out why. Note that as I stated in my first

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Bill Cole
On 3 Oct 2012, at 16:21, Ralf Hildebrandt wrote: DNS is definitely failing for dfleur.com, as the hit on the SA rule NO_DNS_FOR_FROM indicates and as confirmed by a manual query: ~$ dig dfleur.com mx ; DiG 9.8.1-P1 dfleur.com mx ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode:

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Stefan Palme
On Wed, 2012-10-03 at 16:00 -0400, Bill Cole wrote: lazarus:~# dig dfleur.com mx ; DiG 9.9.1-P3 dfleur.com mx ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 41183 ... ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Oct 3 15:07:35 2012 Your locally installed DNS

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread /dev/rob0
On Wed, Oct 03, 2012 at 04:26:33PM -0400, Wietse Venema wrote: Bill Cole: ; DiG 9.9.1-P3 dfleur.com mx ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 41183 How will I reproduce this quickly? Comcast owns dnssec-failed.org, a zone set up with

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Bill Cole
On 3 Oct 2012, at 16:26, Wietse Venema wrote: Bill Cole: ; DiG 9.9.1-P3 dfleur.com mx ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 41183 How will I reproduce this quickly? I am not sure. If your resolver is BIND you can make dfleur.com (and as

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Bill Cole
On 3 Oct 2012, at 16:38, Stefan Palme wrote: On Wed, 2012-10-03 at 16:00 -0400, Bill Cole wrote: lazarus:~# dig dfleur.com mx ; DiG 9.9.1-P3 dfleur.com mx ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 41183 ... ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Oct 3

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread /dev/rob0
On Wed, Oct 03, 2012 at 04:35:59PM -0500, I wrote: On Wed, Oct 03, 2012 at 04:26:33PM -0400, Wietse Venema wrote: Bill Cole: ; DiG 9.9.1-P3 dfleur.com mx ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 41183 How will I reproduce this

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Bill Cole
On 3 Oct 2012, at 14:46, Noel Jones wrote: On 10/3/2012 1:15 PM, Bill Cole wrote: I recently updated a Postfix system from 2.4 to 2.9 and I have found what I believe is a change in behavior for reject_unknown_sender_domain which is confusing. In the past, an effective means of dealing with

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Wietse Venema
Wietse Venema: Bill Cole: ; DiG 9.9.1-P3 dfleur.com mx ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 41183 Net::DNS::Nameserver to the rescue, with a trivial reply handler of: sub reply_handler { my ($qname, $qclass, $qtype,

Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Wietse Venema
Bill Cole: On 3 Oct 2012, at 16:26, Wietse Venema wrote: Bill Cole: ; DiG 9.9.1-P3 dfleur.com mx ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 41183 How will I reproduce this quickly? I am not sure. If your resolver is BIND you can

SOLVED! was Re: reject_unknown_sender_domain and DNS SERVFAIL result

2012-10-03 Thread Bill Cole
Predictably, the cause of this odd behavior was in fact external to Postfix. The server has 3 DNS servers in resolv.conf: itself, another one sitting across the room, and a third far away which was added in the same disaster recovery event that precipitated the upgrade from 2.4.5 to 2.9.3 a