require_rdns bug (?)
in [Sendmail]
|
From: Andrzej Adam Filip on 22 Feb 2010 06:18 DJ GRP <deejay.grp(a)gmail.com> wrote: > we are using compiled sendmail (latest version) under CentOS 5.4. For > the last 48 hours there have been some issues with it. In particular, > it started rejecting a large number of messages because it claimed > they came from unresolved IPs. > > We are indeed using require_rdns feature. The thing is, it behaved > similarly for properly resolved IPs, too. There was no DNS service > interruption during the specific interval. I even tried to perform a > dig and an nslookup at the same time sendmail was rejecting IP > 1.2.3.4, and I got back a proper hostname. > > As a workaround, I restarted sendmail and the issue was gone. > > I would appreciate some comments and/or help on this, since I am not > willing to stop using require_rdns. 0) Could you post a few of the relevant log entries? Especially it would provide useful hist to see 0a) smtp reply codes generated (4?? or 5??) 0b) a few specific IP addresses 1) I personally recommend using FEATURE(`anfi/require_rdns') with FEATURE(`anfi/rsdnsbl') => It would allow you to exclude a few "near by countries" from revDNS checks and use more strict revDNS checks for a few "bad far away countries" using IP->country mapping provided by some DNS services/zones. "Politically correct" justification of the above is "fine tuning" revDNS and DNSBL/DNSWL checks to *locally* seen ham/spam ratio :-) -- [pl>en Andrew] Andrzej Adam Filip : anfi(a)onet.eu : Andrzej.Filip(a)gmail.com Open-Sendmail: http://open-sendmail.sourceforge.net/ They are relatively good but absolutely terrible. -- Alan Kay, commenting on Apollos
From: DJ GRP on 22 Feb 2010 06:41 > 0) Could you post a few of the relevant log entries? > Especially it would provide useful hist to see > 0a) smtp reply codes generated (4?? or 5??) > 0b) a few specific IP addresses Here you can see that a specific IP does not resolve, and immediately after sendmail restart (a few seconds later) it starts resolving properly. > Feb 22 12:19:19 srv sendmail[13574]: ruleset=check_relay, arg1=[192.104.147.44], arg2=192.104.147.44, relay=[192.104.147.44], reject=550 5.7.1 Fix reverse DNS for 192.104.147.44 > Feb 22 12:20:00 srv sendmail[13839]: ruleset=check_relay, arg1=[192.104.147.44], arg2=192.104.147.44, relay=[192.104.147.44], reject=550 5.7.1 Fix reverse DNS for 192.104.147.44 > Feb 22 12:20:20 srv sendmail[13959]: ruleset=check_relay, arg1=[192.104.147.44], arg2=192.104.147.44, relay=[192.104.147.44], reject=550 5.7.1 Fix reverse DNS for 192.104.147.44 > Feb 22 12:21:01 srv sendmail[14218]: ruleset=check_relay, arg1=[192.104.147.44], arg2=192.104.147.44, relay=[192.104.147.44], reject=550 5.7.1 Fix reverse DNS for 192.104.147.44 > Feb 22 12:21:05 srv sendmail[14243]: ruleset=check_relay, arg1=[192.104.147.44], arg2=192.104.147.44, relay=[192.104.147.44], reject=550 5.7.1 Fix reverse DNS for 192.104.147.44 > Feb 22 12:21:21 srv sendmail[14345]: ruleset=check_relay, arg1=[192.104.147.44], arg2=192.104.147.44, relay=[192.104.147.44], reject=550 5.7.1 Fix reverse DNS for 192.104.147.44 > Feb 22 12:22:09 srv sendmail[14609]: ruleset=check_relay, arg1=[192.104.147.44], arg2=192.104.147.44, relay=[192.104.147.44], reject=550 5.7.1 Fix reverse DNS for 192.104.147.44 > Feb 22 12:22:22 srv sendmail[14742]: ruleset=check_relay, arg1=[192.104.147.44], arg2=192.104.147.44, relay=[192.104.147.44], reject=550 5.7.1 Fix reverse DNS for 192.104.147.44 > Feb 22 12:22:22 srv sendmail[14744]: ruleset=check_relay, arg1=[192.104.147.44], arg2=192.104.147.44, relay=[192.104.147.44], reject=550 5.7.1 Fix reverse DNS for 192.104.147.44 > Feb 22 12:23:19 srv sendmail[15051]: o1MANDmS015051: from=<user(a)mydomain.com>, size=0, class=0, nrcpts=1, proto=SMTP, daemon=MTA, relay=ahep-b13.ahepahosp.gr [192.104.147.44] > Feb 22 12:23:19 srv sendmail[15051]: o1MANDmU015051: from=<user(a)mydomain.com>, size=0, class=0, nrcpts=1, proto=SMTP, daemon=MTA, relay=ahep-b13.ahepahosp.gr [192.104.147.44] > Feb 22 12:23:19 srv sendmail[15051]: o1MANDmW015051: from=<user(a)mydomain.com>, size=0, class=0, nrcpts=1, proto=SMTP, daemon=MTA, relay=ahep-b13.ahepahosp.gr [192.104.147.44] > 1) I personally recommend using FEATURE(`anfi/require_rdns') with > FEATURE(`anfi/rsdnsbl') => It would allow you to exclude a few > "near by countries" from revDNS checks and use more strict revDNS > checks for a few "bad far away countries" using IP->country mapping > provided by some DNS services/zones. I don't see any problem with that, although I am not sure we actually need it since we enforce the same policy for everyone. Then again, you definitely know what you are saying, so I dare to ask: would you recommend this for our case (where no particular policy is enforced)?
From: ska on 23 Feb 2010 04:23 DJ GRP wrote: > Here you can see that a specific IP does not resolve, and immediately > after sendmail restart (a few seconds later) it starts resolving > properly. > > > Feb 22 12:22:22 srv sendmail[14744]: ruleset=check_relay, arg1=[192.104.147.44], arg2=192.104.147.44, relay=[192.104.147.44], reject=550 5.7.1 Fix reverse DNS for 192.104.147.44 > > Feb 22 12:23:19 srv sendmail[15051]: o1MANDmS015051: from=<user(a)mydomain.com>, size=0, class=0, nrcpts=1, proto=SMTP, daemon=MTA, relay=ahep-b13.ahepahosp.gr [192.104.147.44] I don't know how sendmail caches DNS results, but it does. There had been a time, when 192.104.147.44 resulted to "not found: 3(NXDOMAIN)", IMHO, because "Fix reverse DNS for" does not mean SRVFAIL and does not mean "Forgery". Can you find something in the logs between the last entry of a correct relaying and the first "5.7.1". -ska
|
Pages: 1 Prev: require_rdns bug Next: timeout writing message to a.mx.mail.yahoo.com.: Broken pipe |