Postscreen DNSBL Sites

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
67 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Postscreen DNSBL Sites

Steve Jenkins-3
I recently removed TRBLSPAM from my postscreen_dnsbl_sites lists after they went offline earlier this month (this should be a reminder to do the same for anyone here who also used them). That got me wondering about what DNSBL sites others have been successfully using with Postscreen.

Here's my current setup:

postscreen_dnsbl_threshold = 3
postscreen_dnsbl_sites =
        zen.spamhaus.org*2,
        b.barracudacentral.org*2,
        dnsbl.mjabl.org,
        dnsbl.ahbl.org,
        bl.spamcop.net,
        swl.spamhaus.org*-4,
        list.dnswl.org=127.[0..255].[0..255].0*-2,
        list.dnswl.org=127.[0..255].[0..255].1*-4,
        list.dnswl.org=127.[0..255].[0..255].[2..255]*-6

This setup has been working pretty well for me, and reduces false positives by not allowing any single DNSBL to block an incoming connection without concurrence from at least one other DNSBL.

I'm wondering if others can recommend any other DNSBLs that I should consider, or if anyone has any other feedback on my setup.

Thanks,

SteveJ
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen DNSBL Sites

/dev/rob0
On Tue, Apr 23, 2013 at 10:42:36AM -0700, Steve Jenkins wrote:
> I recently removed TRBLSPAM from my postscreen_dnsbl_sites lists
> after they went offline earlier this month (this should be a
> reminder to do the same for anyone here who also used them). That
> got me wondering about what DNSBL sites others have been
> successfully using with Postscreen.
>
> Here's my current setup:

Looks very similar to mine, http://rob0.nodns4.us/postscreen.html

> postscreen_dnsbl_threshold = 3
> postscreen_dnsbl_sites =
>         zen.spamhaus.org*2,
>         b.barracudacentral.org*2,
>         dnsbl.mjabl.org,

What? $ whois mjabl.org                                                                          
NOT FOUND

If you meant NJABL, they've been gone longer than TRBL, 2013-03-01.

>         bl.spameatingmonkey.net,
>         dnsbl.ahbl.org,

These are highly accurate for me. AHBL doesn't list as much, but I've
never seen it return anything questionable.

>         bl.spamcop.net,
>         swl.spamhaus.org*-4,
>         list.dnswl.org=127.[0..255].[0..255].0*-2,
>         list.dnswl.org=127.[0..255].[0..255].1*-4,
>         list.dnswl.org=127.[0..255].[0..255].[2..255]*-6
>
> This setup has been working pretty well for me, and reduces false
> positives by not allowing any single DNSBL to block an incoming
> connection without concurrence from at least one other DNSBL.

I'm fine with blocking for Zen alone, thus I give it 3. Of course
it's possible to continue using it as a reject_rbl_client smtpd
restriction, also. (I do that too. For some recipient domains I
also reject using BRBL.)

> I'm wondering if others can recommend any other DNSBLs that I
> should consider, or if anyone has any other feedback on my setup.

Having watched logs awhile following upgrade to 2.11 snapshots, I
found that PSBL and Mailspike are doing a good job. SORBS should
definitely be there as a 1-point list; I've had that a long time,
finding that SORBS often pushes a 2-point result over the top.

I'm considering lowering BRBL to one point and taking it out of smtpd
restrictions. I've had recent problems with a sender from nerim.net
in France. I don't doubt that the global army of 'cudas has gotten
spam from there, but a 2-point list needs to be conservative IMO.

Again, Mailspike is looking good, and I might soon switch to use of
rep.mailspike.net as a combined black/white list, but that will get
ugly in the sites list. I wish they had a different set of return
codes, i.e., a 127.0.x.x for the bad listings and 127.1.x.x for the
good ones.

As I recently noted on this list, the whitelist sites are mostly
unused. There is almost no overlap between the blacklists and
whitelists. One nerim.net host (of numerous outbounds they use) seems
to be the only one (it's on BRBL and DNSWL.org as a .0, trust level
"none".)

You can double your threshold and scores and add in more one-point
lists for testing. I didn't do that with my recent additions, but I
know they have been around long enough to have some credibility. In
that case I think a 1-point result is safe enough.
--
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen DNSBL Sites

DTNX Postmaster
In reply to this post by Steve Jenkins-3
On Apr 23, 2013, at 19:42, Steve Jenkins <[hidden email]> wrote:

> I recently removed TRBLSPAM from my postscreen_dnsbl_sites lists after they went offline earlier this month (this should be a reminder to do the same for anyone here who also used them). That got me wondering about what DNSBL sites others have been successfully using with Postscreen.
>
> Here's my current setup:
>
> postscreen_dnsbl_threshold = 3
> postscreen_dnsbl_sites =
>         zen.spamhaus.org*2,
>         b.barracudacentral.org*2,
>         dnsbl.mjabl.org,
>         bl.spameatingmonkey.net,
>         dnsbl.ahbl.org,
>         bl.spamcop.net,
>         swl.spamhaus.org*-4,
>         list.dnswl.org=127.[0..255].[0..255].0*-2,
>         list.dnswl.org=127.[0..255].[0..255].1*-4,
>         list.dnswl.org=127.[0..255].[0..255].[2..255]*-6
>
> This setup has been working pretty well for me, and reduces false positives by not allowing any single DNSBL to block an incoming connection without concurrence from at least one other DNSBL.
>
> I'm wondering if others can recommend any other DNSBLs that I should consider, or if anyone has any other feedback on my setup.

We use ZEN, the BRBL and our own local blacklist. All equal weight,
treshold set at 1, no whitelists yet. Pretty boring, I guess, but it
works well for us so far.

How many false positives do you get if you use ZEN and BRBL as single
'decision makers'?

Cya,
Jona

Reply | Threaded
Open this post in threaded view
|

Re: Postscreen DNSBL Sites

DTNX Postmaster
In reply to this post by /dev/rob0
On Apr 23, 2013, at 20:23, /dev/rob0 <[hidden email]> wrote:

>> postscreen_dnsbl_threshold = 3
>> postscreen_dnsbl_sites =
>>        zen.spamhaus.org*2,
>>        b.barracudacentral.org*2,
>>        dnsbl.mjabl.org,
>
> What? $ whois mjabl.org                                                                          
> NOT FOUND
>
> If you meant NJABL, they've been gone longer than TRBL, 2013-03-01.

IIRC, they were part of the XBL, and therefore included in ZEN?

Cya,
Jona
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen DNSBL Sites

Steve Jenkins-3
In reply to this post by /dev/rob0
On Tue, Apr 23, 2013 at 11:23 AM, /dev/rob0 <[hidden email]> wrote:
Looks very similar to mine, http://rob0.nodns4.us/postscreen.html

> postscreen_dnsbl_threshold = 3
> postscreen_dnsbl_sites =
>         zen.spamhaus.org*2,
>         b.barracudacentral.org*2,
>         dnsbl.mjabl.org,

What? $ whois mjabl.org
NOT FOUND
If you meant NJABL, they've been gone longer than TRBL, 2013-03-01

First, thanks for the detailed and insightful reply. Exactly the type of feedback I was hoping for.

And yep - njabl IS what I meant, and I've yanked them. :)
 
>         bl.spameatingmonkey.net,
>         dnsbl.ahbl.org,

These are highly accurate for me. AHBL doesn't list as much, but I've
never seen it return anything questionable.

>         bl.spamcop.net,
>         swl.spamhaus.org*-4,
>         list.dnswl.org=127.[0..255].[0..255].0*-2,
>         list.dnswl.org=127.[0..255].[0..255].1*-4,
>         list.dnswl.org=127.[0..255].[0..255].[2..255]*-6

I'm fine with blocking for Zen alone, thus I give it 3. Of course
it's possible to continue using it as a reject_rbl_client smtpd
restriction, also. (I do that too. For some recipient domains I
also reject using BRBL.)

I also do that. Any thoughts on these settings which I currently use?

reject_rbl_client b.barracudacentral.org,
 reject_rbl_client zen.spamhaus.org,
 reject_rbl_client bl.spamcop.net,
 reject_rbl_client psbl.surriel.com,
 reject_rhsbl_client dbl.spamhaus.org,
 reject_rhsbl_sender dbl.spamhaus.org,
 reject_rhsbl_helo dbl.spamhaus.org,

> I'm wondering if others can recommend any other DNSBLs that I
> should consider, or if anyone has any other feedback on my setup.

Having watched logs awhile following upgrade to 2.11 snapshots, I
found that PSBL and Mailspike are doing a good job. SORBS should
definitely be there as a 1-point list; I've had that a long time,
finding that SORBS often pushes a 2-point result over the top.

I'm considering lowering BRBL to one point and taking it out of smtpd
restrictions. I've had recent problems with a sender from nerim.net
in France. I don't doubt that the global army of 'cudas has gotten
spam from there, but a 2-point list needs to be conservative IMO.

Again, Mailspike is looking good, and I might soon switch to use of
rep.mailspike.net as a combined black/white list, but that will get
ugly in the sites list. I wish they had a different set of return
codes, i.e., a 127.0.x.x for the bad listings and 127.1.x.x for the
good ones.

As I recently noted on this list, the whitelist sites are mostly
unused. There is almost no overlap between the blacklists and
whitelists. One nerim.net host (of numerous outbounds they use) seems
to be the only one (it's on BRBL and DNSWL.org as a .0, trust level
"none".)

You can double your threshold and scores and add in more one-point
lists for testing. I didn't do that with my recent additions, but I
know they have been around long enough to have some credibility. In
that case I think a 1-point result is safe enough.

Again, excellent advice and feedback. Thank you - I'm off to test out some of the ones you suggested!

SteveJ 
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen DNSBL Sites

/dev/rob0
On Tue, Apr 23, 2013 at 11:41:42AM -0700, Steve Jenkins wrote:
> On Tue, Apr 23, 2013 at 11:23 AM, /dev/rob0 <[hidden email]> wrote:
>
> > Looks very similar to mine, http://rob0.nodns4.us/postscreen.html
> >
> > > postscreen_dnsbl_threshold = 3
[snip]

> > I'm fine with blocking for Zen alone, thus I give it 3. Of course
> > it's possible to continue using it as a reject_rbl_client smtpd
> > restriction, also. (I do that too. For some recipient domains I
> > also reject using BRBL.)
>
> I also do that. Any thoughts on these settings which I currently use?
>
> reject_rbl_client b.barracudacentral.org,
>  reject_rbl_client zen.spamhaus.org,
>  reject_rbl_client bl.spamcop.net,
>  reject_rbl_client psbl.surriel.com,

With those restrictions, you could just as well raise the
corresponding postscreen_dnsbl_sites scores to 3 for each. ISTM that
you're missing the point of scoring.

Yes, as I mentioned, Zen and (for most domains) BRBL listings are
good enough for outright rejection, but I would not do that for
Spamcop nor PSBL. Both of those are driven by automated processes
which could result in "false positives".

>  reject_rhsbl_client dbl.spamhaus.org,
>  reject_rhsbl_sender dbl.spamhaus.org,
>  reject_rhsbl_helo dbl.spamhaus.org,

Yes, absolutely.

I should explain here that my smtpd restrictions are variable
depending on the recipient address. A check_recipient_access lookup
early in the process decides how aggressive the restrictions will be.
More conservative domains (or even user addresses; I have the
database schema in place to support per-user restrictions, but have
not gotten around to providing users an interface to set their
preference) will only use Zen as reject_rbl_client, and only then
after checking all DNSWLs for all trust levels as
permit_dnswl_client.

More aggressive domains will also reject for more aggressive DNSBLs,
such as BRBL, SEM, and even spamcop, and they skip the lower trust
levels on DNSWL.org.[1]

My restrictions are, to put it bluntly, a terrifying mess. :) Yes,
they bewilder me, and I made them! It's easy enough to explain the
basic principles, but it's awful to try to figure out the details.
This isn't something I'd recommend to most sites. I spent way too
many unpaid hours on developing those restrictions, and as you
pointed out in your OP, things like this do require care and feeding
from time to time.



[1] I have even considered using DNSWL.org's 127.0.15.0 code, which
    is "Email marketers of trust level 'none'", as a blacklist, for
    the most aggressive filtering. That's a misuse of DNSWL.org's
    service, but for addresses which are not signing up for any
    marketing mail, I'm sure it would be very effective. The vast
    majority of the relatively little overlap I have seen in DNSWL
    and DNSBL listings have been these 127.0.15.0 clients.
--
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen DNSBL Sites

David Benfell
In reply to this post by Steve Jenkins-3
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/23/2013 10:42 AM, Steve Jenkins wrote:
>
> This setup has been working pretty well for me, and reduces false
> positives by not allowing any single DNSBL to block an incoming
> connection without concurrence from at least one other DNSBL.
>
First, thanks for introducing me to postscreen. Since I moved my
domains to a dedicated server in Germany, I've been getting hammered
with spam, so second, I've been testing this out, minus the mjabl
entry, and it seems to have stopped the spammers in their tracks. I'm
not going to claim it's optimum, because I don't know, but it works
*very* well.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRd1itAAoJELJhbl/uPb4SYOQQAJIF7mYgy0ipZC0SekcsrjKM
QOp9IHDGAuKnvN4U5uPhyJc7M17JGOijf4SUc8PX148EsIL85ytKlr1xMyxuvNlX
RLoetJGXmditRYfH2pRjHibMs5RuZN+k5auDyG9OEXZebo+YC3KwdRJiAy5pKi+V
H+EFtD5QGQ1EKslQNFYdm1Yp5JDs2qOiWKe9/imBPw3KxN86wJwMP2MnLG5cEg+s
W9dDQsOBccJU25W3XZO362lBP5MMRlBDwMWx2ijW2dDGaJBuQu2ZtDbUa/apY0r9
nl74QUUZdU741YHk6l31wF8Hj3tsJKLYrEOBm1A+VoUbj1kWWugMUEoH1hT14U5V
L8SjT7IPOhy310pMLoThZWb+mS7VBBb3C82m6TJjqd93ekx2dsl9uH6TzTwcIlPS
aVPZ0bpUJzzZSIXhaPTbFCx+3Na7oMQOCWUT5Esrqpgs9LgHxF7NrmkvVbUDOtbT
o4siP6TGTB39egv1DCDSIC/hiolCkXidY54eHMi2fgDfvH3f8AsHudGyaXGa71YF
DZPauec43avRp6rN2uedg+aiRg4eSTT6vMRvvI1dp0nU22ugZRwEkXWcWodmppR3
/vv0I0os+G5G689IvbuXb9kEerNXTU8RBonFyZehaG55EkoRDP1cfBgj0lKPL5Sj
vtPVE/fSDqggYOm0Qi7d
=wFOx
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen DNSBL Sites

/dev/rob0
On Tue, Apr 23, 2013 at 08:59:41PM -0700, David Benfell wrote:

> On 04/23/2013 10:42 AM, Steve Jenkins wrote:
> >
> > This setup has been working pretty well for me, and reduces false
> > positives by not allowing any single DNSBL to block an incoming
> > connection without concurrence from at least one other DNSBL.
> >
> First, thanks for introducing me to postscreen. Since I moved my
> domains to a dedicated server in Germany, I've been getting
> hammered with spam, so second, I've been testing this out, minus
> the mjabl entry, and it seems to have stopped the spammers in their
> tracks. I'm not going to claim it's optimum, because I don't know,
> but it works *very* well.

Since you mention "mjabl" I think you might not be familiar with
these DNSBL (and DNSWL) services. It bears repeating: you really
should become familiar with them.

Did you sign up for Barracuda Reputation Block List? It's free of
charge, but they do require registration.

Links are on my page that you will see (or have seen) upthread. Take
the time to know the policies of each of these services.

Good luck, and enjoy watching the spam rejections. :)
--
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen DNSBL Sites

Vincent Lefevre-10
In reply to this post by /dev/rob0
On 2013-04-23 13:23:17 -0500, /dev/rob0 wrote:
> Looks very similar to mine, http://rob0.nodns4.us/postscreen.html

Thanks for this example.

BTW, are the deep protocol tests (in addition to the dnsbl tests)
useful in practice? Do you have statistics? Is this mainly for
new zombies that have not had the time to be blacklisted yet?

In particular, the non-SMTP command test is already implemented
at the smtpd level. So I suppose that the main reasons would be
the command pipelining test and the bare newline test.

--
Vincent Lefèvre <[hidden email]> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen DNSBL Sites

Steve Jenkins-3
In reply to this post by /dev/rob0
On Tue, Apr 23, 2013 at 12:41 PM, /dev/rob0 <[hidden email]> wrote:
With those restrictions, you could just as well raise the
corresponding postscreen_dnsbl_sites scores to 3 for each. ISTM that
you're missing the point of scoring.

Yes, as I mentioned, Zen and (for most domains) BRBL listings are
good enough for outright rejection, but I would not do that for
Spamcop nor PSBL. Both of those are driven by automated processes
which could result in "false positives".

Thanks - I see that now. My smtpd_recipient_restrictions now include these as the final config options before "permit":

        reject_rbl_client b.barracudacentral.org,
        reject_rbl_client zen.spamhaus.org,
        reject_rhsbl_client dbl.spamhaus.org,
        reject_rhsbl_sender dbl.spamhaus.org,
        reject_rhsbl_helo dbl.spamhaus.org,

 And based on your excellent article on your site, I've updated my Postscreen settings to:

# POSTSCREEN OPTIONS v20130423
postscreen_access_list = permit_mynetworks,
        cidr:/etc/postfix/postscreen_access.cidr,
        hash:/etc/postfix/postscreen_whitelist

postscreen_blacklist_action = drop
postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce
postscreen_dnsbl_threshold = 3

postscreen_dnsbl_sites =
        zen.spamhaus.org*3,
        b.barracudacentral.org*2,
        dnsbl.ahbl.org*2,
        bl.spamcop.net,
        dnsbl.sorbs.net,
        psbl.surriel.com,
        bl.mailspike.net,
        swl.spamhaus.org*-4,
        list.dnswl.org=127.[0..255].[0..255].0*-2
        list.dnswl.org=127.[0..255].[0..255].1*-3
        list.dnswl.org=127.[0..255].[0..255].[2..255]*-4

I've got a few "older" (1994 - 1996) domains running on this server, which some email addresses that I'm sure are in some of those "1MM email addresses!" CD-ROMs from the 90s. So even though this is a "personal" server, there's plenty of spammer action trying to get through. Doing a tail -f on the maillog and watching Postscreen + the smtpd restrictions do their work is always a satisfying feeling!

Thanks again, rob0, for your excellent examples and willingness to educate. After monitoring these tweaks on my personal server for a bit, I'm going to deploy these to our production mail servers.

SteveJ
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen DNSBL Sites

Jeroen Geilman
On 04/24/2013 11:23 PM, Steve Jenkins wrote:
On Tue, Apr 23, 2013 at 12:41 PM, /dev/rob0 <[hidden email]> wrote:
With those restrictions, you could just as well raise the
corresponding postscreen_dnsbl_sites scores to 3 for each. ISTM that
you're missing the point of scoring.

Yes, as I mentioned, Zen and (for most domains) BRBL listings are
good enough for outright rejection, but I would not do that for
Spamcop nor PSBL. Both of those are driven by automated processes
which could result in "false positives".

Thanks - I see that now. My smtpd_recipient_restrictions now include these as the final config options before "permit":

        reject_rbl_client b.barracudacentral.org,
        reject_rbl_client zen.spamhaus.org,

These make any deviation in scoring for zen and barracuda in POSTSCREEN irrelevant.
The reject_rbl_client results are not weighted; they're fail/pass.
I'd just remove them here.

(You still don't have the hang of scoring.)

-- 
J.
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen DNSBL Sites

Steve Jenkins-3
On Wed, Apr 24, 2013 at 2:27 PM, Jeroen Geilman <[hidden email]> wrote:
These make any deviation in scoring for zen and barracuda in POSTSCREEN irrelevant. 
The reject_rbl_client results are not weighted; they're fail/pass.
I'd just remove them here.

(You still don't have the hang of scoring.)

Ok - I think it's finally penetrating my thick skull. :) The Zen entry was probably a wash, since I am scoring Zen at 3 and making the dnsbl threshold = 3. So the smtpd restriction wasn't blocking anything that wouldn't have been blocked anyway.

But I now see that scoring BRBL at 2 was pointless because the BRBL smtpd restriction would have rejected the message even in the (probably unlikely) event that BRBL flagged it and none of the other sources did. In that case, the message should have got through.

Both smtpd client restrictions have been removed. Thx, Jeroen.

SteveJ
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen DNSBL Sites

/dev/rob0
In reply to this post by Jeroen Geilman
On Wed, Apr 24, 2013 at 11:27:41PM +0200, Jeroen Geilman wrote:

> On 04/24/2013 11:23 PM, Steve Jenkins wrote:
> >On Tue, Apr 23, 2013 at 12:41 PM, /dev/rob0 <[hidden email]>:
> >
> >    With those restrictions, you could just as well raise the
> >    corresponding postscreen_dnsbl_sites scores to 3 for each.
> >    ISTM that you're missing the point of scoring.
> >
> >    Yes, as I mentioned, Zen and (for most domains) BRBL listings
> >    are good enough for outright rejection, but I would not do
> >    that for Spamcop nor PSBL. Both of those are driven by
> >    automated processes which could result in "false positives".
> >
> >
> >Thanks - I see that now. My smtpd_recipient_restrictions now
> >include these as the final config options before "permit":
> >
> >        reject_rbl_client b.barracudacentral.org,
> >        reject_rbl_client zen.spamhaus.org
>
> These make any deviation in scoring for zen and barracuda in
> POSTSCREEN irrelevant.
> The reject_rbl_client results are not weighted; they're fail/pass.

True, but for all we know they could be preceded by a
check_policy_service or permit_dnswl_client restriction.

> I'd just remove them here.

I disagree. I like having a fallback in case something went awry with
the postscreen_dnsbl_sites lookups. Maybe the replies arrived too
late? Now, for smtpd, our named has these queries cached, so it will
be instant.

> (You still don't have the hang of scoring.)

Again, can't say. I'd have the Zen higher, before most whitelisting,
but yes, BRBL belongs down there at the end.

And then too is the "Steve's server, Steve's rules" issue. If it's
meeting his needs, that's what matters. :)
--
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: Postscreen DNSBL Sites

Steve Jenkins-3
On Wed, Apr 24, 2013 at 3:15 PM, /dev/rob0 <[hidden email]> wrote:
True, but for all we know they could be preceded by a
check_policy_service or permit_dnswl_client restriction.

Well, in this case they're not (yet?) preceded by any of those... but I'm learning more and more with every piece of this discussion, and now want to play around with putting "permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3]" somewhere in there.

Again, can't say. I'd have the Zen higher, before most whitelisting,
but yes, BRBL belongs down there at the end.

Assuming I do want put them back in, and try out permit_dnswl_client entry (only for low, medium, and high), how high up my smtpd_recipient_restrictions food chain should the Zen and permit_dnswl_client entries be (realizing the Zen reject should be above the dnswl permit)?

Here are my current entries:

smtpd_recipient_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_invalid_hostname,
        reject_unauth_destination,
        warn_if_reject reject_non_fqdn_hostname,
        warn_if_reject reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        reject_unknown_sender_domain,
        warn_if_reject reject_unknown_reverse_client_hostname,
        warn_if_reject reject_non_fqdn_helo_hostname,
        warn_if_reject reject_invalid_helo_hostname,
        warn_if_reject reject_unknown_helo_hostname,
        reject_unauth_pipelining,
        check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
        check_helo_access hash:/etc/postfix/helo_access,
        check_sender_access hash:/etc/postfix/check_backscatterer,
        check_sender_access hash:/etc/postfix/access,
        reject_rhsbl_client dbl.spamhaus.org,
        reject_rhsbl_sender dbl.spamhaus.org,
        reject_rhsbl_helo dbl.spamhaus.org,
        permit

My guess would be to either put them just after the reject_unknown_sender_domain or just before the check_reverse_client_hostname... but that's a total guess. The BRBL entry I'd stick back just in front of the reject_rhsbl_client entry.

SteveJ
Reply | Threaded
Open this post in threaded view
|

Restrictions after postscreen (was: Re: Postscreen DNSBL Sites)

/dev/rob0
On Wed, Apr 24, 2013 at 03:44:19PM -0700, Steve Jenkins wrote:

> On Wed, Apr 24, 2013 at 3:15 PM, /dev/rob0 <[hidden email]> wrote:
>
> > True, but for all we know they could be preceded by a
> > check_policy_service or permit_dnswl_client restriction.
>
> Well, in this case they're not (yet?) preceded by any of those...
> but I'm learning more and more with every piece of this discussion,
> and now want to play around with putting "permit_dnswl_client
> list.dnswl.org=127.0.[0..255].[1..3]" somewhere in there.
>
> > Again, can't say. I'd have the Zen higher, before most
> > whitelisting, but yes, BRBL belongs down there at the end.
>
> Assuming I do want put them back in, and try out
> permit_dnswl_client entry (only for low, medium, and high), how
> high up my smtpd_recipient_restrictions food chain should the Zen
> and permit_dnswl_client entries be (realizing the Zen reject should
> be above the dnswl permit)?
>
> Here are my current entries:
>
> smtpd_recipient_restrictions =
>         permit_mynetworks,
>         permit_sasl_authenticated,

I don't put these permit_* in global restrictions; I only apply them
to submission via -o smtpd_relay_restrictions=... in master.cf. And
that brings up another point: if you're using 2.10 you now have
smtpd_relay_restrictions for relay control.

>         reject_invalid_hostname,

Deprecated syntax for reject_invalid_helo_hostname.

>         reject_unauth_destination,

See above re: smtpd_relay_restrictions.

>         warn_if_reject reject_non_fqdn_hostname,

I consider this one quite safe. In fact, it's one of the CBL's
listing criteria; when they see a host using a non-FQDN as HELO, it
will be listed. Deprecated syntax again.

>         warn_if_reject reject_non_fqdn_sender,
>         reject_non_fqdn_recipient,
>         reject_unknown_sender_domain,

These are safe, but mostly pointless here. You might want them on
submission, in case a user has a misconfigured MUA.

>         warn_if_reject reject_unknown_reverse_client_hostname,

Safe, because many large receivers do this as well.

>         warn_if_reject reject_non_fqdn_helo_hostname,

This is the new syntax for reject_non_fqdn_hostname, you do the
warning twice for the same thing.

>         warn_if_reject reject_invalid_helo_hostname,

Deja vu all over again!

>         warn_if_reject reject_unknown_helo_hostname,

This one is NOT safe. A lot of sites use HELOs which don't resolve.
So I'd not take off the warn_if_reject.

>         reject_unauth_pipelining,

This could go higher. It's a "cheap" restriction.

>         check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
>         check_helo_access hash:/etc/postfix/helo_access,
>         check_sender_access hash:/etc/postfix/check_backscatterer,
>         check_sender_access hash:/etc/postfix/access,

"access" is not a descriptive name. I would name it either
"sender_access" or whatever the general purpose of the lookup is. It
could also be merged with the check_backscatterer lookup.

>         reject_rhsbl_client dbl.spamhaus.org,
>         reject_rhsbl_sender dbl.spamhaus.org,
>         reject_rhsbl_helo dbl.spamhaus.org,
>         permit
>
> My guess would be to either put them just after the
> reject_unknown_sender_domain or just before the
> check_reverse_client_hostname... but that's a total guess.
> The BRBL entry I'd stick back just in front of the
> reject_rhsbl_client entry.

I wouldn't whitelist the check_*_access lookups, but you might choose
to do that for your own reasons.

I would put Zen just before the three DBL lookups. This way the DBL
lookups might be avoided. I'd keep DBL before DNSWL. I doubt the
DNSWL folks want to list any client sending for DBL-listed domains,
so check DBL first.

The "low, medium, and high" idea is good, although recently I have
seen a case where BRBL listed a DNSWL "none" host (with legitimate
mail, sigh.)
--
  http://rob0.nodns4.us/ -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Reply | Threaded
Open this post in threaded view
|

Re: Restrictions after postscreen (was: Re: Postscreen DNSBL Sites)

Vincent Lefevre-10
On 2013-05-01 07:14:37 -0500, /dev/rob0 wrote:
> On Wed, Apr 24, 2013 at 03:44:19PM -0700, Steve Jenkins wrote:
> >         warn_if_reject reject_unknown_reverse_client_hostname,
>
> Safe, because many large receivers do this as well.

That's interesting. Several months ago, I intended to add it, but
I noticed that legitimate mail I received sometimes contained
"unknown" (at least for some user), e.g.

Received: from <snip> (unknown [174.33.138.226])
        by ioooi.vinc17.net (Postfix) with ESMTP id 017ED31D51
        for <[hidden email]>; Tue, 19 Jul 2011 05:03:52 +0200 (CEST)

and at that time, I thought that the machine didn't have a correct
reverse hostname, so that I thought that adding this option would be
bad. But if I grep all the messages from this IP, I now notice that
for most of them, I get "host1743300226138.direcway.com" instead of
"unknown", which occurs only from time to time. This makes me think
that the "unknown" could just be due to a temporary failure, but
with the above option, the mail wouldn't be rejected (it would just
be delayed from time to time due to the 450 reply, as documented).
Is this correct?

Regards,

--
Vincent Lefèvre <[hidden email]> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply | Threaded
Open this post in threaded view
|

Re: Restrictions after postscreen

Noel Jones-2
On 5/2/2013 6:27 AM, Vincent Lefevre wrote:

> On 2013-05-01 07:14:37 -0500, /dev/rob0 wrote:
>> On Wed, Apr 24, 2013 at 03:44:19PM -0700, Steve Jenkins wrote:
>>>         warn_if_reject reject_unknown_reverse_client_hostname,
>>
>> Safe, because many large receivers do this as well.
>
> That's interesting. Several months ago, I intended to add it, but
> I noticed that legitimate mail I received sometimes contained
> "unknown" (at least for some user), e.g.
>
> Received: from <snip> (unknown [174.33.138.226])
>         by ioooi.vinc17.net (Postfix) with ESMTP id 017ED31D51
>         for <[hidden email]>; Tue, 19 Jul 2011 05:03:52 +0200 (CEST)
>
> and at that time, I thought that the machine didn't have a correct
> reverse hostname, so that I thought that adding this option would be
> bad. But if I grep all the messages from this IP, I now notice that
> for most of them, I get "host1743300226138.direcway.com" instead of
> "unknown", which occurs only from time to time. This makes me think
> that the "unknown" could just be due to a temporary failure, but
> with the above option, the mail wouldn't be rejected (it would just
> be delayed from time to time due to the 450 reply, as documented).
> Is this correct?
>
> Regards,
>

If the DNS lookup fails with a temporary error, the mail will be
deferred.

It's important to note that not all clients labeled as "unknown"
will be rejected by reject_unknown_reverse_client_hostname.

For enlightenment, compare the docs on
reject_unknown_client_hostname (a strict test not widely used), with
the docs on reject_unknown_reverse_client_hostname (a generally safe
check).

Very strict:
http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname

Generally safe:
http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostname



  -- Noel Jones
Reply | Threaded
Open this post in threaded view
|

reject_unknown_reverse_client_hostname safe? (was: Restrictions after postscreen)

Vincent Lefevre-10
On 2013-05-02 11:08:13 -0500, Noel Jones wrote:

> If the DNS lookup fails with a temporary error, the mail will be
> deferred.
>
> It's important to note that not all clients labeled as "unknown"
> will be rejected by reject_unknown_reverse_client_hostname.
>
> For enlightenment, compare the docs on
> reject_unknown_client_hostname (a strict test not widely used), with
> the docs on reject_unknown_reverse_client_hostname (a generally safe
> check).
[...]

In order to be sure, I decided to check against my mail archive.
I've written a small Perl script for that (attached). Some clients
don't seem to have a reverse hostname. Both IPv4 and IPv6 are
concerned. For instance:

Received: from carotte.tilapin.org (unknown [95.138.72.61])
        by ioooi.vinc17.net (Postfix) with ESMTPS id EFA4959
        for <[hidden email]>; Tue,  2 Oct 2012 03:15:23 +0200 (CEST)

$ host 95.138.72.61
Host 61.72.138.95.in-addr.arpa. not found: 3(NXDOMAIN)

and this is from a Debian developer.

There's something that is quite strange with one of the mail I've
sent from my machine at work (ypig):

Received: from ypig.lip.ens-lyon.fr (unknown [IPv6:2002:8c4d:d7f:1:21f:29ff:fe04:3efb])
        by ioooi.vinc17.net (Postfix) with ESMTPS id A053EA4
        for <[hidden email]>; Tue, 12 Feb 2013 14:12:33 +0100 (CET)

An IPv6 address is listed while it was an IPv4 connection (IPv6
doesn't work at ens-lyon.fr as shown by "ping6" and "ssh -6" from
ypig to ioooi, which give a "Network is unreachable" error). It
seems to be the only exception for this machine (the IPv4 address
with the associated reverse hostname is normally given). Is there
any explanation?

Note: for this date, I no longer have any logs.

--
Vincent Lefèvre <[hidden email]> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

smtp-unknown-reverse (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_reverse_client_hostname safe?

Noel Jones-2
On 5/5/2013 8:10 PM, Vincent Lefevre wrote:

> On 2013-05-02 11:08:13 -0500, Noel Jones wrote:
>> If the DNS lookup fails with a temporary error, the mail will be
>> deferred.
>>
>> It's important to note that not all clients labeled as "unknown"
>> will be rejected by reject_unknown_reverse_client_hostname.
>>
>> For enlightenment, compare the docs on
>> reject_unknown_client_hostname (a strict test not widely used), with
>> the docs on reject_unknown_reverse_client_hostname (a generally safe
>> check).
> [...]
>
> In order to be sure, I decided to check against my mail archive.
> I've written a small Perl script for that (attached). Some clients
> don't seem to have a reverse hostname. Both IPv4 and IPv6 are
> concerned. For instance:
>
> Received: from carotte.tilapin.org (unknown [95.138.72.61])
>         by ioooi.vinc17.net (Postfix) with ESMTPS id EFA4959
>         for <[hidden email]>; Tue,  2 Oct 2012 03:15:23 +0200 (CEST)
>
> $ host 95.138.72.61
> Host 61.72.138.95.in-addr.arpa. not found: 3(NXDOMAIN)

Most large mail providers outright reject mail from such clients.
The few that don't reject it send it straight to the spam folder.
That doesn't mean there are no clients without valid rDNS. You'll
just be one more of the many they have trouble with.


>
> and this is from a Debian developer.
>
> There's something that is quite strange with one of the mail I've
> sent from my machine at work (ypig):
>
> Received: from ypig.lip.ens-lyon.fr (unknown [IPv6:2002:8c4d:d7f:1:21f:29ff:fe04:3efb])
>         by ioooi.vinc17.net (Postfix) with ESMTPS id A053EA4
>         for <[hidden email]>; Tue, 12 Feb 2013 14:12:33 +0100 (CET)
>
> An IPv6 address is listed while it was an IPv4 connection (IPv6
> doesn't work at ens-lyon.fr as shown by "ping6" and "ssh -6" from
> ypig to ioooi, which give a "Network is unreachable" error). It
> seems to be the only exception for this machine (the IPv4 address
> with the associated reverse hostname is normally given). Is there
> any explanation?
>
> Note: for this date, I no longer have any logs.
>


Postfix logs what the system reports to it.
Apparently IPv6 worked at some point with this particular client.



  -- Noel Jones



Reply | Threaded
Open this post in threaded view
|

Re: reject_unknown_reverse_client_hostname safe?

Stan Hoeppner
In reply to this post by Vincent Lefevre-10
On 5/5/2013 8:10 PM, Vincent Lefevre wrote:

> Received: from carotte.tilapin.org (unknown [95.138.72.61])
>         by ioooi.vinc17.net (Postfix) with ESMTPS id EFA4959
>         for <[hidden email]>; Tue,  2 Oct 2012 03:15:23 +0200 (CEST)
>
> $ host 95.138.72.61
> Host 61.72.138.95.in-addr.arpa. not found: 3(NXDOMAIN)

~$ host 95.138.72.61
Host 61.72.138.95.in-addr.arpa. not found: 3(NXDOMAIN)

~$ host carotte.tilapin.org
carotte.tilapin.org has address 5.187.106.61

Not only is rDNS non-existent but the HELO name points to an IP
different than the client IP.  It's difficult to FUBAR this more than it is.

> and this is from a Debian developer.

Your logic would suggest that fighter pilots are intrinsically excellent
kite fliers.  This is simply not the case.  Most have never flown kites.
 I would make an educated guess than most Linux app devs know nothing
about SMTP RFCs or BCPs or setting up a server properly.  Most likely
know only enough to plug an IP or hostname of an SMTP relay server into
their MUA, just like most non dev users.  How many Apache devs know how
to code for Gnome?  How many Gnome devs know how to patch bugs in mysql?

Being a Debian developer carries zero weight here.

--
Stan

1234