On 31/05/12 15:16, Bob Hoffman wrote: > On 5/31/2012 9:59 AM, Ned Slider wrote: >> On 31/05/12 14:09, Bob Hoffman wrote: >>> Not technically a centos question, but a lot of you guys seem to manage >>> some large systems >>> and I could use some clarification on a postfix setting.* >>> >>> *reject_unknown_client_hostname >>> (in postfix< 2.3 reject_unknown_client) >>> >>> When I first used this there were issues with users trying to send mail >>> through the server >>> from hotels, wireless spots, etc. This was solved by pushing up permit >>> sasl_authenticated. >>> >>> I took it out after those issues. I read many online posts from 2008 >>> saying too many >>> false positives. (though none were clear if those were incoming mail or >>> from mail users) >>> >>> Do you use reject_unknown_client_hostname? >>> >> I don't use it because as you already say the false positive rate is too >> high. This is caused largely by incorrectly configured entries in dns. >> >> For example, suppose a client connects from a given IP address. >> >> Postfix will do a rDNS lookup on that IP address to get the client >> hostname. If that lookup fails then the mail will get temp rejected. >> >> Then Postfix will do a DNS lookup on the client hostname it just >> retrieved. If that lookup fails then the mail will get temp rejected. >> >> The above two conditions result in temp rejections in case of temporary >> dns lookup failures which provides a bit of a safety net allowing 5 days >> (by default) for folks to notice (and fix) issues in their logs. From my >> experience I'd say most people do not bother reading their logs on a >> daily basis, at best only when they are made aware of a problem. >> >> Finally, Postfix will check that the DNS lookup on the client hostname >> matches the client IP that is connecting to the server. If it doesn't >> match then the message will be permanently rejected. This is where FPs >> will result as far too many people do not understand how to correctly >> configure their server in DNS. >> >> To summarise, you are looking for IP -> hostname -> IP to match. >> >> >> Mail admins typically take two lines of approach on this: >> >> 1. I can't afford the potential FPs from idiots who don't know how to >> configure their mail servers. >> >> 2. I have no sympathy for idiots who don't know how to configure their >> mail servers and to hell with the FPs, - I'm going to teach them a >> lesson and reject their mail. >> >> It's your mail server and you are free to configure it as you see fit. >> Decide which of the two camps above best describes your view and act >> accordingly. >> > I am not too concerned about a mail server on some website not being set > up right, > the notice they get would be fine with me. > I am just concerned someone sending from an iphone using someone's > poorly setup > wireless would be affected.... > [Rhetorical] And how do you expect Postfix to differentiate between the two examples you have given? > I am gonna test it out and see what happens. Should be thrilling experience. > And man, once you figure out how to use DNS correctly, it seems so simple > to make it work right. > > on a side note, I tested apews.org as a rbl and rhsbl and it worked fine... > until..... > it blocked amazon.com receipts, dominos online orders, and my sisters > mail from earthlink.. > lol and there's the thing. You can test settings and they appear to be working fine, then some time down the line you get hit with FPs or other issues. This is why we seek the views and experiences of others who have already beaten that path; reject_unknown_client_hostname WILL cause FPs. How you decide to act upon that is up to you as it's your mail server. What I would suggest is that if you do want to test reject_unknown_client_hostname then you use warn_if_reject instead of rejecting outright and monitor your logs for rejection rates/FPs. warn_if_reject reject_unknown_client_hostname If you place this at the end of your restrictions then you'll also get an idea as to how effective it is as an anti-spam restriction. If it blocks little to no spam then the conversation becomes moot.