Re: Creating exceptions to greylisting
- On 2/2/2013 1:55 PM, Gerben Wierda wrote:
> Just so there is no misunderstanding: I am unhappy running an older version that is not updated with security fixes anymore and I had planned to upgrade before now (but not immediately when 10.8 came out as 10.8.0 Server was not what you say trustworthy. I skipped 10.7 server altogether because it is a disaster area.That's awfully difficult to read. Try putting each on its own line as
> I plan to upgrade asap to 10.8 server.
> For now, I came up with:
> smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/whitelist_mtaclientdomains reject_rbl_client zen.spamhaus.org permit
> smtpd_recipient_restrictions = permit_sasl_authenticated permit_mynetworks reject_unauth_destination check_client_access hash:/etc/postfix/whitelist_mtaclientdomains check_policy_service unix:private/policy permit
in the examples we've given you. Also, put everything under
and eliminate smtpd_client_restrictions altogether. Now you no longer
have to duplicate restrictions between them. More importantly, you have
fine grained control over evaluation order. Thus, this would be much
> Which makes sure some clients are permitted before they end up in either RBL or Policy. Just for you more experienced people: is this OK?When using separate client and recipient restrictions, as you have
above, your rbl check against Zen can trigger before your whitelist
checks, causing a rejection. Using the method I've detailed above
avoids this situation. Because Postfix performs delayed rejection by
default, you can put all of your restrictions under
smtpd_recipient_restrictions and carefully control the order of
restriction evaluations. I'd guess that every experienced OP on this
list does it this way. It just doesn't make any sense to do otherwise.
> Does macports overwrite what Apple has provided or does it have its own separate tree (like fink used to have, which means you get another job that is: keeping the second tree up to date)?I have zero experience with MacOS. Sorry.
- On Sat, Feb 02, 2013 at 03:34:30PM -0600, Stan Hoeppner wrote:
> check_client_access pcre:/etc/postfix/client_accessThis is not robust for two reasons, the first is a simple oversight,
> /.*facebook\.com$/ permit
since "notfacebook.com" is not "facebook.com" and any SMTP client
in the real facebook.com domain would be a proper sub-domain.
The second issue is not easy to fix, transient DNS lookup errors
(timeouts, ...) may result in a client hostname of "unknown" rather
than <mumble>.facebook.com. In such cases the whitelist entry will
not apply. Generally this is a problem as messages may be erroneously
rejected due to a transient error. In this case, provided the whitelist
entry is solely to avoid greylisting, this is OK, since greylisting
is responds with temporary (4XX) error codes.
- On 2/2/2013 3:50 PM, Viktor Dukhovni wrote:
> On Sat, Feb 02, 2013 at 03:34:30PM -0600, Stan Hoeppner wrote:It wasn't intended to be robust Viktor, but quite the opposite.
>> check_client_access pcre:/etc/postfix/client_access
>> /.*facebook\.com$/ permit
> This is not robust for two reasons, the first is a simple oversight,
> /.*facebook\.com$/ permitI guess you missed what came directly after that...
> /\.facebook\.com$/ permit
> since "notfacebook.com" is not "facebook.com" and any SMTP client
> in the real facebook.com domain would be a proper sub-domain.
On 2/2/2013 3:08 PM, Stan Hoeppner wrote:
> You may want to be more specific. I made my example very generic as
> your expression above seems to miss some of their outbound host rdns,
> such as: outappmail004.snc4.facebook.com
Sometimes, when a kid asks for an apple, it's better to give him a
rotten one, so as to teach him to pick his own fresh apples from the
tree. I.e. I gave him a rotten example of a regex hoping/assuming he'd
do some legwork and create his own set of fully qualified expressions to
meet his needs.
- --> Gerben Wierda <gerben.wierda@...> [2013-02-02 20:55:42 +0100]:
> Just so there is no misunderstanding: I am unhappy running anSure, I can understand that.
> older version that is not updated with security fixes anymore and
> I had planned to upgrade before now (but not immediately when 10.8
> came out as 10.8.0 Server was not what you say trustworthy. I skipped
> 10.7 server altogether because it is a disaster area. I plan
> to upgrade asap to 10.8 server.
> Does macports overwrite what Apple has provided or does it haveNo, Macports does not overwrite what Apple has installed and yes,
> ts own separate tree (like fink used to have, which means you get
> another job that is: keeping the second tree up to date)?
it does use its own separate filesystem as Fink does; it's under
/opt/local. However, they do specify that have programs installed
in /usr/local (i.e. manually installed or otherwise) causes issues
when using Macports. Totally OT, sorry about that.
It does provide you a way of keeping installed programs up-to-date
which is why I suggested it. You simply use launctl/Launchd to
select which MTA you use; i.e. the Macports installed version or
the Apple preinstalled version.