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.
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.
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:
- I can't afford the potential FPs from idiots who don't know how to
configure their mail servers.
- 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....
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
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.*
<nsip>
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
Well, if my late sister had used email, that might be a nice thing to block. Dominos... your system is telling you that you need to go to a non-big-chain, better, pizza shop.
mark
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:
- I can't afford the potential FPs from idiots who don't know how to
configure their mail servers.
- 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.
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.
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 mail
servers 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 5/31/2012 10:20 AM, m.roth@5-cent.us wrote:
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?
yea, that is what I think. I feel this setting, once you permit authenticated users, should only be dealing with badly setup dns for an internet based mail server and not someone's home computer or iphone. at least, I think so. Most of the issues I find on the net appear from pre-2009 era. Gonna add it to end of smtpd restrictions and see if anything comes of it. crossing fingers.
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
On 05/31/2012 10:35 AM, Craig White wrote:
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 _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Yes, I second this. No legitimate mail users today expect to send email directly from a mobile device or even a home broadband connection. Any mail server that allows incoming email directly from end users is going to get bombarded with spam. In recent years, most mailserver administrators know that they have to setup proper DNS as well. Disallowing mailservers without proper DNS stops massive amounts of spam, and lately I hardly ever have to add exceptions for this anymore. I run a mail server for a good number of users and I run with this:
This one is very reliable and will reject a good many broadband/dialup connections Under smtpd_client_restrictions: reject_rbl_client pbl.spamhaus.org
reject_unknown_client_hostname unknown_client_reject_code = 550
I just don't get alot of complaints from users anymore, running with these. This will of coarse depend heavily on your user base and who they exchange email with.
You might also look at postscreen. I've heard really good things about it, though I haven't had time to set it up yet.
Nataraj
-
Bob Hoffman -
Craig White -
m.roth＠5-cent.us -
Mike Burger -
Nataraj -
Ned Slider