whitelisting to correct rbl false positives

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

whitelisting to correct rbl false positives

lists-3
just noticed some email sent from gmail/google bouncing from my server as
sorbs RBL had that server/host listed;

Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
Client host [209.85.217.170] blocked using dnsbl.sorbs.net; Currently
Sending Spam See: http://www.sorbs.net/lookup.shtml?209.85.217.170;
from=<[hidden email]> to=<[hidden email]> proto=ESMTP
helo=<mail-ua0-f170.google.com>


what is correct way to whiltelist gmail/google

I have like this in main.cf[1]

so I should enter gmail into /etc/postfix/client_checks , yes?

do I need all google smtp published IPs, OR, can I just have like:

gmail.com OK
google.com OK ?

what other 'well known services' like google should I whitelist, yahoo,
hotmail ?

thanks for any pointers

[1]
...
smtpd_recipient_restrictions =.
 reject_unknown_sender_domain,
 reject_unknown_recipient_domain,.
 reject_non_fqdn_sender,.
 reject_non_fqdn_recipient,.
 reject_unlisted_recipient,.
 check_policy_service inet:127.0.0.1:7777,.
 permit_mynetworks,
 check_sasl_access hash:/etc/postfix/sasl_access
 permit_sasl_authenticated,
 reject_unauth_destination,
 check_recipient_access hash:/etc/postfix/recipient_no_checks,
 check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
 check_helo_access hash:/etc/postfix/helo_checks,
 check_sender_access hash:/etc/postfix/sender_checks,
 check_client_access hash:/etc/postfix/client_checks,
 check_client_access pcre:/etc/postfix/client_checks.pcre,
 reject_rbl_client zen.spamhaus.org,
 reject_rhsbl_client dbl.spamhaus.org,
 reject_rhsbl_sender dbl.spamhaus.org,
...

Reply | Threaded
Open this post in threaded view
|

Re: whitelisting to correct rbl false positives

Tanstaafl
On 11/17/2016 2:22 AM, Voytek <[hidden email]> wrote:

> just noticed some email sent from gmail/google bouncing from my server as
> sorbs RBL had that server/host listed;
>
> Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
> mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
> Client host [209.85.217.170] blocked using dnsbl.sorbs.net; Currently
> Sending Spam See: http://www.sorbs.net/lookup.shtml?209.85.217.170;
> from=<[hidden email]> to=<[hidden email]> proto=ESMTP
> helo=<mail-ua0-f170.google.com>
>
> what is correct way to whiltelist gmail/google

Wrong question...

Question should be - is outright blocking based on SORBS something I
should be doing?

Answer of course is a resounding NO. Use it for socring, maybe, but I
don't even use them because of their propensity for false positives.
Reply | Threaded
Open this post in threaded view
|

Re: whitelisting to correct rbl false positives

Noel Jones-2
In reply to this post by lists-3
On 11/17/2016 1:22 AM, Voytek wrote:

> just noticed some email sent from gmail/google bouncing from my server as
> sorbs RBL had that server/host listed;
>
> Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
> mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
> Client host [209.85.217.170] blocked using dnsbl.sorbs.net; Currently
> Sending Spam See: http://www.sorbs.net/lookup.shtml?209.85.217.170;
> from=<[hidden email]> to=<[hidden email]> proto=ESMTP
> helo=<mail-ua0-f170.google.com>
>
>
> what is correct way to whiltelist gmail/google
>
> I have like this in main.cf[1]
>
> so I should enter gmail into /etc/postfix/client_checks , yes?
>
> do I need all google smtp published IPs, OR, can I just have like:
>
> gmail.com OK
> google.com OK ?

Yes, whitelisting "gmail.com" and "google.com" clients should take
care of this problem. Make sure this whitelist is AFTER
reject_unauth_destination

>
> what other 'well known services' like google should I whitelist, yahoo,
> hotmail ?

If you insist on using an RBL with high collateral damage, you'll
probably need to whitelist all the major providers...

>
> thanks for any pointers

Pick your RBLs carefully. "More" isn't always "better".



  -- Noel Jones

>
> [1]
> ...
> smtpd_recipient_restrictions =.
>  reject_unknown_sender_domain,
>  reject_unknown_recipient_domain,.
>  reject_non_fqdn_sender,.
>  reject_non_fqdn_recipient,.
>  reject_unlisted_recipient,.
>  check_policy_service inet:127.0.0.1:7777,.
>  permit_mynetworks,
>  check_sasl_access hash:/etc/postfix/sasl_access
>  permit_sasl_authenticated,
>  reject_unauth_destination,
>  check_recipient_access hash:/etc/postfix/recipient_no_checks,
>  check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
>  check_helo_access hash:/etc/postfix/helo_checks,
>  check_sender_access hash:/etc/postfix/sender_checks,
>  check_client_access hash:/etc/postfix/client_checks,
>  check_client_access pcre:/etc/postfix/client_checks.pcre,
>  reject_rbl_client zen.spamhaus.org,
>  reject_rhsbl_client dbl.spamhaus.org,
>  reject_rhsbl_sender dbl.spamhaus.org,
> ...
>

Reply | Threaded
Open this post in threaded view
|

Re: whitelisting to correct rbl false positives

@lbutlr
In reply to this post by lists-3
On Nov 17, 2016, at 12:22 AM, Voytek <[hidden email]> wrote:
> Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
> mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
> Client host [209.85.217.170] blocked using dnsbl.sorbs.net; Currently
> Sending Spam See: http://www.sorbs.net/lookup.shtml?209.85.217.170;
> from=<[hidden email]> to=<[hidden email]> proto=ESMTP
> helo=<mail-ua0-f170.google.com>

You should be using scoring with your RBLs instead of willy-nilly rejecting mail based on any listing in any RBL.

For example, I cribbed this from someone on this list and am using a slightly modified version of it:

postscreen_dnsbl_sites = dnsbl.sorbs.net=127.0.0.10*6
 dnsbl.sorbs.net=127.0.0.14*6
 zen.spamhaus.org=127.0.0.[10;11]*6
 dnsbl.sorbs.net=127.0.0.5*6
 zen.spamhaus.org=127.0.0.[4..7]*6
 b.barracudacentral.org=127.0.0.2*6
 zen.spamhaus.org=127.0.0.3*6
 dnsbl.inps.de=127.0.0.2*6
 dnsbl.sorbs.net=127.0.0.7*4
 hostkarma.junkemailfilter.com=127.0.0.2*4
 bl.spamcop.net=127.0.0.2*4
 dnsrbl.swinog.ch=127.0.0.3*4
 ix.dnsbl.manitu.net=127.0.0.2*4
 psbl.surriel.com=127.0.0.2*4
 zen.spamhaus.org=127.0.0.2*3
 score.senderscore.com=127.0.4.[0..20]*3
 dnsbl.sorbs.net=127.0.0.6*3
 dnsbl.sorbs.net=127.0.0.8*2
 hostkarma.junkemailfilter.com=127.0.0.4*2
 dnsbl.sorbs.net=127.0.0.9*2
 dnsbl-1.uceprotect.net=127.0.0.2*2
 all.spamrats.com=127.0.0.38*2
 bl.nszones.com=127.0.0.[2;3]*1
 dnsbl-2.uceprotect.net=127.0.0.2*1
 dnsbl.sorbs.net=127.0.0.2*1
 dnsbl.sorbs.net=127.0.0.4*1
 score.senderscore.com=127.0.4.[0..69]*1
 dnsbl.sorbs.net=127.0.0.3*1
 hostkarma.junkemailfilter.com=127.0.1.2*1
 dnsbl.sorbs.net=127.0.0.15*1
 ips.backscatterer.org=127.0.0.2*1
 bl.nszones.com=127.0.0.5*-1
 score.senderscore.com=127.0.4.[90..100]*-1
 hostkarma.junkemailfilter.com=127.0.0.1*-2
 ips.whitelisted.org=127.0.0.2*-2
 list.dnswl.org=127.0.[0..255].0*-3
 dnswl.inps.de=127.0.[0;1].[2..10]*-2
 list.dnswl.org=127.0.[0..255].1*-4
 list.dnswl.org=127.0.[0..255].2*-5
 list.dnswl.org=127.0.[0..255].3*-6


Reply | Threaded
Open this post in threaded view
|

Re: whitelisting to correct rbl false positives

Phil Stracchino
On 11/18/16 14:43, @lbutlr wrote:
> On Nov 17, 2016, at 12:22 AM, Voytek <[hidden email]> wrote:
>> Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
>> mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
>> Client host [209.85.217.170] blocked using dnsbl.sorbs.net; Currently
>> Sending Spam See: http://www.sorbs.net/lookup.shtml?209.85.217.170;
>> from=<[hidden email]> to=<[hidden email]> proto=ESMTP
>> helo=<mail-ua0-f170.google.com>
>
> You should be using scoring with your RBLs instead of willy-nilly rejecting mail based on any listing in any RBL.

Well, certainly if you're using thirty or forty different RBLs including
list as hair-triggered as SORBS, anyway.  If you're only using a handful
of RBLs whose accuracy you trust, a one-strike policy may be appropriate.


--
  Phil Stracchino
  Babylon Communications
  [hidden email]
  [hidden email]
  Landline: 603.293.8485
Reply | Threaded
Open this post in threaded view
|

Re: whitelisting to correct rbl false positives

@lbutlr

> On Nov 18, 2016, at 1:01 PM, Phil Stracchino <[hidden email]> wrote:
>
> On 11/18/16 14:43, @lbutlr wrote:
>> On Nov 17, 2016, at 12:22 AM, Voytek <[hidden email]> wrote:
>>> Nov 17 12:56:47 emu postfix/smtpd[16381]: NOQUEUE: reject: RCPT from
>>> mail-ua0-f170.google.com[209.85.217.170]: 554 5.7.1 Service unavailable;
>>> Client host [209.85.217.170] blocked using dnsbl.sorbs.net; Currently
>>> Sending Spam See: http://www.sorbs.net/lookup.shtml?209.85.217.170;
>>> from=<[hidden email]> to=<[hidden email]> proto=ESMTP
>>> helo=<mail-ua0-f170.google.com>
>>
>> You should be using scoring with your RBLs instead of willy-nilly rejecting mail based on any listing in any RBL.
>
> Well, certainly if you're using thirty or forty different RBLs including
> list as hair-triggered as SORBS, anyway.  If you're only using a handful
> of RBLs whose accuracy you trust, a one-strike policy may be appropriate.

Scoring allows you to use whitelist RBLs like dnswl.org and whitelisted.org.