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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
05-31-2012, 01:19 PM
"Mike Burger"
question for those who run mail servers
> 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:
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
site-update-subscribe@bubbanfriends.org
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
05-31-2012, 01:59 PM
Ned Slider
question for those who run mail servers
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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
05-31-2012, 02:16 PM
Bob Hoffman
question for those who run mail servers
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....
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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
05-31-2012, 02:20 PM
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 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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
05-31-2012, 02:27 PM
question for those who run mail servers
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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
05-31-2012, 02:30 PM
Bob Hoffman
question for those who run mail servers
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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Thu May 31 18:30:02 2012
Return-path: <marketing-bounces@lists.fedoraproject.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Thu, 31 May 2012 17:31:25 +0300
Received: from bastion01.fedoraproject.org ([209.132.181.2]:35725 helo=bastion.fedoraproject.org)
by s2.java-tips.org with esmtp (Exim 4.77)
(envelope-from <marketing-bounces@lists.fedoraproject.org>)
id 1Sa6Ou-0006ri-8T
for tom@linux-archive.org; Thu, 31 May 2012 17:31:25 +0300
Received: from lists.fedoraproject.org (collab03.vpn.fedoraproject.org [192.168.1.70])
by bastion01.phx2.fedoraproject.org (Postfix) with ESMTP id 31C072116D;
Thu, 31 May 2012 14:24:59 +0000 (UTC)
Received: from collab03.fedoraproject.org (localhost [127.0.0.1])
by lists.fedoraproject.org (Postfix) with ESMTP id 8E4F040A52;
Thu, 31 May 2012 14:24:57 +0000 (UTC)
X-Original-To: marketing@lists.fedoraproject.org
Delivered-To: marketing@lists.fedoraproject.org
Received: from smtp-mm03.fedoraproject.org (vm4.fedora.ibiblio.org
[152.19.134.143])
by lists.fedoraproject.org (Postfix) with ESMTP id 1935A40A0A
for <marketing@lists.fedoraproject.org>;
Thu, 31 May 2012 14:24:56 +0000 (UTC)
Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45])
by smtp-mm03.fedoraproject.org (Postfix) with ESMTP id D0D7E4081B
for <marketing@lists.fedoraproject.org>;
Thu, 31 May 2012 14:24:56 +0000 (UTC)
Received: by eekd41 with SMTP id d41so450213eek.32
for <marketing@lists.fedoraproject.org>;
Thu, 31 May 2012 07:24:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=message-id:date:from:user-agent:mime-version:to:subject:references
:in-reply-to:content-type:content-transfer-encoding;
bh=zSjav2sGNhff3q740ePpaavZnW3CZoSjzksJxaRMfH4=;
b=vLWdoJslyX6ObzeStdby2whOPcU55V6UwKUdU8Unu45tNnrD 5pMFztuECx6e5Vaq9h
nRlTql0JqtvYmzjIrAlTTQL4NvGN5/rsD9tmzo7s8zK9AmMDF5/ZuSD8zdaN5JyT37TT
EJE1uy3tN8LRZTscogR4IPEowNQFjSn7nVepjKEZMoC6c2g3cK ycM7GAPCvNgGJRcnvP
CG5DW+kPpyVcdRbCRAIfcp/a/aBec6BlO6YRSjMYhxxFL8YkrsNiE1HNXZiMw0jxR6DE
O64TJr7FY97Hi+v4GQvdRo1QN0X/hyIKQoNLl+fppZXBDfTEjXl12KAxdfGjMw6aYUF3
iQgg==
Received: by 10.14.53.79 with SMTP id f55mr7565125eec.69.1338474296027;
Thu, 31 May 2012 07:24:56 -0700 (PDT)
Received: from localhost.localdomain (85-220-55-128.dsl.dynamic.simnet.is.
[85.220.55.128])
by mx.google.com with ESMTPS id s8sm11013208ees.16.2012.05.31.07.24.54
(version=SSLv3 cipher=OTHER); Thu, 31 May 2012 07:24:55 -0700 (PDT)
Message-ID: <4FC77E8D.4070304@gmail.com>
Date: Thu, 31 May 2012 14:22:05 +0000
From: =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
<johannbg@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: marketing@lists.fedoraproject.org
Subject: Re: The Inquirier on F17
References: <37dacfe2-518c-496c-a624-21f033b73af7@zmail16.collab.prod.int.phx2.redhat.c om>
<4FC512ED.8090002@gmail.com>
<CANFAPZGn5Y5OJkJ1f-DzKHWu61WY3KL9O9igjx_vUNHd1wAihg@mail.gmail.com>
<4FC614D7.1010302@nicubunu.ro>
<CAP0i4reRSKKoY5gUx7P4J3gFKqqkCAZSk9DewmH_epvJiJCt mA@mail.gmail.com>
<20120531123909.GS3132@jayne.redhat.com>
In-Reply-To: <20120531123909.GS3132@jayne.redhat.com>
X-BeenThere: marketing@lists.fedoraproject.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Fedora Marketing team <marketing@lists.fedoraproject.org>
List-Id: Fedora Marketing team <marketing.lists.fedoraproject.org>
List-Unsubscribe: <https://admin.fedoraproject.org/mailman/options/marketing>,
<mailto:marketing-request@lists.fedoraproject.org?subject=unsubscrib e>
List-Archive: <http://lists.fedoraproject.org/pipermail/marketing/>
List-Post: <mailto:marketing@lists.fedoraproject.org>
List-Help: <mailto:marketing-request@lists.fedoraproject.org?subject=help>
List-Subscribe: <https://admin.fedoraproject.org/mailman/listinfo/marketing>,
<mailto:marketing-request@lists.fedoraproject.org?subject=subscribe>
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Sender: marketing-bounces@lists.fedoraproject.org
Errors-To: marketing-bounces@lists.fedoraproject.org
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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
05-31-2012, 05:35 PM
Craig White
question for those who run mail servers
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
05-31-2012, 07:41 PM
Nataraj
question for those who run mail servers
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
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
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos