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? Other than someone trying to access the server to send mail through it as a user I do not see how this could be a bad setting and am thinking of using it. A person sending out a mail to the server, even if in that badly set up hotel wireless should be using their gmail, yahoo, own server, isp mail servers and should not be directly sending from their iphone....is that correct? or do you ignore the use of this setting still? -thanks for any updates on the use of this setting.
> 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? > > Other than someone trying to access the server to send mail through it > as a user I do > not see how this could be a bad setting and am thinking of using it. > A person sending out a mail to the server, even if in that badly set up > hotel wireless > should be using their gmail, yahoo, own server, isp mail servers and > should not > be directly sending from their iphone....is that correct? > > or do you ignore the use of this setting still? > > -thanks for any updates on the use of this setting.Hi, Bob. I do not use this setting, though I do have this in my main.cf: unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 I can understand your wanting to use it, but you definitely want/need to keep the "permit_sasl_authenticated" at the top. The idea, as you're no doubt aware, is that if they have a username and password, presumably you're allowing them to relay email, as long as they've authenticated. The iPhone provides that functionality with little effort required to configure. -- Mike Burger http://www.bubbanfriends.org Visit the Dog Pound II BBS telnet://dogpound2.citadel.org http://dogpound2.citadel.org https://dogpound2.citadel.org To be notified of updates to the web site, visit: https://www.bubbanfriends.org/mailman/listinfo/site-update or send a blank email to: site-update-subscribe at bubbanfriends.org
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.
m.roth at 5-cent.us
2012-May-31 14:20 UTC
[CentOS] question for those who run mail servers
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 postfixsetting.*> > *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 bypushing up permit> sasl_authenticated.This caught my eye: they don't have an account on those hotspots, they *have* to be connecting, via mailtool or webmail, to their *real* mailserver, I would think.><snip>> not see how this could be a bad setting and am thinking of using it. > A person sending out a mail to the server, even if in that badly set up > hotel wireless should be using their gmail, yahoo, own server, isp mailservers and> should not be directly sending from their iphone....is that correct?I guarantee that those folks with too-"smart"-for-their-own-good phones will send directly from them. Having never looked at a header from an email sent via iPhone, I don't know - don't they have a legit mailserver as their gateway? <snip> mark
On May 31, 2012, at 6:09 AM, 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? > > Other than someone trying to access the server to send mail through it > as a user I do > not see how this could be a bad setting and am thinking of using it. > A person sending out a mail to the server, even if in that badly set up > hotel wireless > should be using their gmail, yahoo, own server, isp mail servers and > should not > be directly sending from their iphone....is that correct? > > or do you ignore the use of this setting still? > > -thanks for any updates on the use of this setting.---- if the goal is to minimize spam then this is a really good option as it duplicates methodologies employed by a lot of the large e-mail providers (ie, AOL) which require both the forward and reverse addresses to resolve. Requiring someone to authenticate to a known SMTP host is reasonable and prudent - and I would agree that the senders should be using a registered SPF (sender permitted from) SMTP host for forwarding their outgoing e-mails. Craig