FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 05-31-2012, 01:09 PM
Bob Hoffman
 
Default 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.
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-31-2012, 01:19 PM
"Mike Burger"
 
Default 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:

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@bubbanfriends.org
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-31-2012, 01:59 PM
Ned Slider
 
Default 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
 
Old 05-31-2012, 02:16 PM
Bob Hoffman
 
Default 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
 
Old 05-31-2012, 02:20 PM
 
Default 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
 
Old 05-31-2012, 02:27 PM
 
Default 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
 
Old 05-31-2012, 02:30 PM
Bob Hoffman
 
Default 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

T24gMDUvMzEvMjAxMiAxMjozOSBQTSwgUGF1bCBXLiBGcmllbG RzIHdyb3RlOgo+IE9uIFRodSwg
TWF5IDMxLCAyMDEyIGF0IDA4OjI5OjMwQU0gKzAyMDAsIEdpYW 5sdWNhIFNmb3JuYSB3cm90ZToK
Pj4gT24gV2VkLCBNYXkgMzAsIDIwMTIgYXQgMjozOCBQTSwgTm ljdSBCdWN1bGVpPG5pY3VfZmVk
b3JhQG5pY3VidW51LnJvPiAgd3JvdGU6Cj4+PiBCdXQgSSB0aG luayB3ZSBhbGwgYWdyZWUgdGhl
IGxpbmtlZCBhcnRpY2xlIGlzIHJlYWxseSBiYWQgd3JpdHRlbi BhbmQgaXQKPj4+IHdvdWxkIGhl
IHVzZWZ1bCB0byAiaGVscCIgdGhvc2UgbmV3cyBzb3VyY2VzIH RvIGltcHJvdmUgdGhlaXIgcmVw
b3J0aW5nLgo+PiBJbiBhZGRpdGlvbiwgSSdkIGxvdmUgdG8gaG VhciBzb21lIHNvcnQgb2Ygb2Zm
aWNpYWwgd29yZCBhYm91dCB0aGUKPj4gIkZlZG9yYSBwcm9qZW N0IHNlcnZlcyBhcyB0aGUgcHJv
dmluZyBncm91bmQgZm9yIG5ldyBmZWF0dXJlcyB0aGF0Cj4+IG V2ZW50dWFsbHkgZW5kIHVwIGlu
IHRoZSBmaXJtJ3MgUmVkIEhhdCBFbnRlcnByaXNlIExpbnV4IC hSSEVMKQo+PiBvcGVyYXRpbmcg
c3lzdGVtIiBwYXJ0LiBJIG1lYW4sIGlzIHRoaXMgYSBjb25jZX B0IFJlZCBIYXQgaXMgYWN0aXZl
bHkKPj4gbWFya2V0aW5nPwo+Pgo+PiBJZiBzbywgYXMgYW4gYW 1iYXNzYWRvciBJJ2QgbG92ZSB0
byBrbm93IGl0IGJlY2F1c2UgSSBhbSBjb25zdGFudGx5Cj4+IG ZpZ2h0aW5nIGFnYWluc3QgdGhp
cyAiRmVkb3JhIGlzIGEgYmV0YSAob3Igd29yc2UpIGxldmVsIH BhY2thZ2UgYW5kCj4+IGl0cyB1
c2VycyBhcmUganVzdCBSZWQgSGF0J3MgZ3VpbmVhIHBpZ3MiIG F0dGl0dWRlIGluIHByZXNzLCBi
bG9ncyBhbmQKPj4gdXNlcnMgb2Ygb3RoZXIgZGlzdHJvcy4KPj 4KPj4gSWYgdGhhdCdzIG5vdCB0
cnVlLCBpdCB3b3VsZCBiZSByZWFsbHkgdXNlZnVsIHRvIGhhdm Ugc29tZSB3b3JkcyBmcm9tCj4+
IGEgQHJlZGhhdCBzcG9rZXNwZXJzb24gdG8gYmFjayBhIGRpZm ZlcmVudCBwb2ludCBvZiB2aWV3
IG9uIHRoZSBSZWQKPj4gSGF0L0ZlZG9yYSByZWxhdGlvbnNoaX AKPiBUaGVyZSdzIGEgYmlnIGRp
ZmZlcmVuY2UgYmV0d2VlbiAiRmVkb3JhIGlzIGEgYmV0YSBhbm QgdXNlcnMgYXJlCj4gZ3VpbmVh
IHBpZ3MsIiBhbmQgIkZlZG9yYSBpcyBhIHBsYWNlIHdoZXJlIC phbnkgY29udHJpYnV0b3IqIGNh
biB3b3JrCj4gb24gbmV3IHRlY2huaWNhbCBmZWF0dXJlcyBhbm QgcHV0IHRoZW0gaW4gZnJvbnQg
b2YgbWlsbGlvbnMgb2YgdXNlcnMKPiBhcyBwYXJ0IG9mIGEgZn JlZSBhbmQgb3BlbiBzb3VyY2Ug
c29mdHdhcmUgZGV2ZWxvcG1lbnQgcHJvY2Vzcy4iICBSZWQKPi BIYXQgaXMgb25seSBwYXJ0IG9m
IG91ciBjb21tdW5pdHkgYW5kIHdlJ3ZlIGhhZCBwbGVudHkgb2 Ygb3RoZXIKPiBjb250cmlidXRv
cnMgb3ZlciB0aGUgeWVhcnMgcHV0IG5ldyBzb2Z0d2FyZSBpbn RvIHRoZSBkaXN0cmlidXRpb24g
Zm9yCj4gcGVvcGxlIHRvIHVzZS4KPgo+IEJlaW5nIHRoZSBwcm 92aW5nIGdyb3VuZCBmb3IgbmV3
IHRlY2hub2xvZ3kgdGhhdCBtaWdodCBiZSBpbiBhIGZ1dHVyZQ o+IFJIRUwgcmVsZWFzZSBpcyBv
bmx5IG9uZSBmdW5jdGlvbiBvZiB0aGUgRmVkb3JhIFByb2plY3 QuICBPZiBjb3Vyc2UKPiB0aGF0
IGZ1bmN0aW9uIGlzIHF1aXRlIGltcG9ydGFudCB0byBSZWQgSG F0LCBhbmQgYSByZWFzb24gd2h5
IFJlZCBIYXQKPiBjb250aW51ZXMgdG8gcHV0IHN1YnN0YW50YW lsIHJlc291cmNlcyBpbnRvIEZl
ZG9yYS4gIEJ1dCBpdCdzIG5vdCB0aGUKPiBvbmx5IHRoaW5nIH RoZSBGZWRvcmEgUHJvamVjdCBk
b2VzLCBhbmQgYXMgeW91IGtub3cgbG90cyBvZgo+IGNvbnRyaW J1dG9ycyBoYXZlIHRoZWlyIG93
biByZWFzb25zIHRvIHBhcnRpY2lwYXRlIGFzIHdlbGwuCgpIZX JlIHdlIGNvbWUgdG8gb25lIG9m
IHRoZSBjb3JlIGlzc3VlcyBvZiBSZWQgSGF0IHZzIFRoZSBGZW RvcmEgCmNvbW11bml0eSBhcyBp
biB3ZSAoIHRoZSBjb21tdW5pdHkgKSBkbyBub3QgdmlldyBSSE VMIHJlbGVhc2UgYmVpbmcgb25l
IApmdW5jdGlvbiBvZiB0aGUgRmVkb3JhIFByb2plY3QuCgpSZW QgSGF0IGNlcnRhaW5seSBiZWxp
ZXZlcyBpdCB0byBiZSBvbmUgb2YgdGhlIGZ1bmN0aW9uIHRoZS Bwcm9qZWN0IApob3dldmVyIHdl
ICggdGhlIGNvbW11bml0eSApIGNlcnRhaW5seSBkb24ndCBub3 Igc2hvdWxkIHdlIGFzIGFuIHBy
b2plY3QgCmFsbG93IGFueSBzcG9uc29yIFJlZCBIYXQgb3Igb3 RoZXJ3aXNlIGhhdmUgYW55IGlu
Zmx1ZW5jZSBlaXRoZXIgCmRpcmVjdGx5IG9yIGluZGlyZWN0bH kgb2YgdGhlIHByb2plY3QgYW5k
IGl0J3MgZGlyZWN0aW9uLgoKPiBBbm90aGVyIHdheSB0byB0aG luayBhYm91dCBpdCBpcyBsaWtl
IHRoaXMuLi4gQW55IGRlZGljYXRlZAo+IGNvbnRyaWJ1dG9yIG hhcyB0aGUgcG90ZW50aWFsIHRv
IGNvbnRyaWJ1dGUgZmVhdHVyZXMgYW5kIHRlY2hub2xvZ3kgdG 8KPiBpbnRlZ3JhdGUgaW50byBG
ZWRvcmEgdGhlIGRpc3RyaWJ1dGlvbiwganVzdCBsaWtlIFJlZC BIYXQgZG9lcy4gIEl0Cj4ganVz
dCBzbyBoYXBwZW5zIHRoYXQgUmVkIEhhdCBkZWRpY2F0ZXMgcG VvcGxlLCB0aW1lLCBhbmQgbW9u
ZXkgdG8KPiB0aGF0IGNyZWF0aW9uIGFuZCBpbnRlZ3JhdGlvbi BlZmZvcnQsIGFuZCBhcyBhIHJl
c3VsdCBlYWNoIHJlbGVhc2UgaGFzCj4gbG90cyBvZiBpbm5vdm F0aXZlIG5ldyBmZWF0dXJlcy4K
ClNvIGluIGVzc2VuY2UgaGVyZSB5b3Ugc2F5IHRoYXQgYWxsIG lubm92YXRpb24gdGhhdCBoYXBw
ZW4gaW4gdGhlIApwcm9qZWN0IGlzIGFsbCB0aGFua3MgdG8gUm VkIEhhdCBhbmQgdGhlIGNvbW11
bml0eSBtZW1iZXJzIHRpbWUgaXMgCndvcnRobGVzcyBjb21wYX JlZCB0byB0aGUgdGltZSBhbmQg
bW9uZXkgUmVkIEhhdCBzcG9uc29yIHRoZSBwcm9qZWN0IHdpdG guCgpJIHdvdWxkIHNheSB0aGF0
IHRoZSBhYm92ZSBpcyBhIHJhdGhlciBpbnRlcmVzdGluZyByZX Nwb25zZSBmcm9tIGEgCmZvcm1l
ciBwcm9qZWN0IGxlYWRlciB0aGVuIGFnYWluIGlmIG1lbW9yeS BzZXJ2ZXMgbWUgY29ycmVjdCB5
b3UgCmFjdHVhbGx5IGRpZCBjYWxsIEZlZG9yYSAiQmV0YSIgaW 4gb25lIG9mIHRoZSBSZWQgSGF0
IHN1bW1pdCBkdXJpbmcgeW91IAp0aW1lIGFzIG91ciBwcm9qZW N0IGxlYWRlciBzbyBJIGNhbnQg
c2F5IHRoYXQgSSdtIHN1cnByaXNlZCBieSB0aGlzLgoKPiAgIC BBcyB0aGUgRmVkb3JhIGNvbW11
bml0eSAoYW5kIGluZGVlZAo+IHRoZSB3aWRlciBGT1NTIGNvbW 11bml0eSkgZXNzZW50aWFsbHkg
ImVsZWN0cyIgdGhlIGJlc3Qgc3R1ZmYgb3Zlcgo+IHRpbWUsIF JlZCBIYXQgY2FuIHVzZSB0aGF0
IGNyb3dkIHdpc2RvbSB0byBoZWxwIGRlY2lkZSB3aGF0IHBpZW Nlcwo+IG1ha2UgdGhlIG1vc3Qg
c2Vuc2UgZm9yIGl0cyBlbnRlcnByaXNlIHByb2R1Y3QuICBBbn kgb3RoZXIgY29udHJpYnV0b3IK
PiBjYW4gZG8gdGhlIHNhbWUgdGhpbmcsIGF0IHdoYXRldmVyIH NjYWxlIG1ha2VzIHNlbnNlIGZv
ciB0aGVtLgo+CgpUcnVlIGJ1dCBhdCB0aGUgc2FtZSB0aW1lIG 5vIG90aGVyICpzcG9uc29yKiBp
cyBhbGxvd2VkIHRvIGVzc2VudGlhbGx5IAoqc3BvbnNvciogdG hlIHByb2plY3QgYXMgeW91IGFz
IHRoZSBmb3JtZXIgcHJvamVjdHMgbGVhZGVyIGFyZSB3ZWxsIA phd2FyZSBvZi4KCkluIHRoZSBl
bmQgZnJvbSB0aGUgY29tbXVuaXRpZXMgcG9pbnQgb2Ygdmlldy BSZWQgSGF0IGlzIGEgc3BvbnNv
ciBubyAKbW9yZSBubyBsZXNzLCB3ZSBGZWRvcmEgaGF2ZSBvdX Igb3duIGxlYWRlcnNoaXAsIG91
ciBvd24gZGV2ZWxvcGVyIGJhc2UgCmFuZCBvd24gcHJpb3JpdG llcyBGZWRvcmEgZ29lcyBpdCdz
IG93biB3YXkgcmVnYXJkbGVzcyBvZiBSZWQgSGF0IG9yIApSSE VMIG9yIGFueSBvdGhlciBjb250
cmlidXRvcixzcG9uc29yIG9yIGRpc3RyaWJ1dGlvbiBkb3duc3 RyZWFtIHRvIHVzIAp0aGlua3Mu
CgpSZWQgSGF0IGNhbiBjb250aW51ZSB0byBhZHZlcnRpc2UgdG 8gaXQncyBwYXJ0bmVycyB0aGF0
IHdlIGFyZSBzb21lIGtpbmQgCm9mIHRlc3RpbmcvcHJvdmluZy Bncm91bmQgZm9yIFJIRUwgYW5k
IGRpcmVjdGx5IG9yIGluZGlyZWN0bHkgdHJ5IHRvIAppbmZsdW VuY2UgdGhlIGRpcmVjdGlvbiBv
ZiB0aGUgcHJvamVjdCBhbmQgd2UgdGhlIGNvbW11bml0eSB3aW xsIApjb250aW51ZSB0byBkbyBv
dXIgYmVzdCB0byBzaGFrZSB0aGF0IHN0YW1wIG9mZiB0aGUgcH JvamVjdCBhbmQgc3RheSAKZmly
bSBhdCB0aGUgc3RlZXJpbmcgd2hlZWwgYW5kIHRyeSB0byBwcm V2ZW50IFJlZCBIYXQgZnJvbSBk
b2luZyBzbyBhbmQgCndlIHdpbGwgY29udGludWUgdG8gZG8gc2 8gdW50aWwgZWl0aGVyIG9uZSBv
ZiB0aGUgdHdvIHBvc3NpYmxlIG91dGNvbWUgCm9uIGhvdyB0aG F0IHdpbGwgZW5kIHdpbGwgY29t
ZSB0byBwYXNzLgoKSkJHCi0tIAptYXJrZXRpbmcgbWFpbGluZy BsaXN0Cm1hcmtldGluZ0BsaXN0
cy5mZWRvcmFwcm9qZWN0Lm9yZwpodHRwczovL2FkbWluLmZlZG 9yYXByb2plY3Qub3JnL21haWxt
YW4vbGlzdGluZm8vbWFya2V0aW5n
 
Old 05-31-2012, 03:47 PM
Ned Slider
 
Default question for those who run mail servers

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
 
Old 05-31-2012, 05:35 PM
Craig White
 
Default 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
 
Old 05-31-2012, 07:41 PM
Nataraj
 
Default 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

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




_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 07:10 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org