smtpd_recipient_restrictions -- Best Practices

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

smtpd_recipient_restrictions -- Best Practices

blue_cowdawg
Hi folks,

Hope this isn't too dumb a question, but here goes:  

Is there are "best practice" concerning the ordering of the directives
to the right hand side of the "=" for smtpd_recipient_restrictions?  

The reason I'm asking is I added a set of lines for RBL reverse DNS and
they don't seem to be having any effect.


--
Peter L. Berghold <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: smtpd_recipient_restrictions -- Best Practices

Matt Hayes
On 12/8/2011 2:04 PM, Peter L. Berghold wrote:

> Hi folks,
>
> Hope this isn't too dumb a question, but here goes:
>
> Is there are "best practice" concerning the ordering of the directives
> to the right hand side of the "=" for smtpd_recipient_restrictions?
>
> The reason I'm asking is I added a set of lines for RBL reverse DNS and
> they don't seem to be having any effect.
>
>

Peter,

Can you send us the smtpd_recipient_restrictions line from your main.cf?
  Might help to see how you have them ordered and what else you may be
able to add to help benefit you.

-Matt
Reply | Threaded
Open this post in threaded view
|

Re: smtpd_recipient_restrictions -- Best Practices

/dev/rob0
In reply to this post by blue_cowdawg
On Thursday 08 December 2011 13:04:13 Peter L. Berghold wrote:
> Is there are "best practice" concerning the ordering of the
> directives to the right hand side of the "=" for
> smtpd_recipient_restrictions?

Consider the relative costs of the restrictions. For example, a hash:
table access(5) lookup will have very little cost, whereas a
reject_rbl_client restriction incurs the delay and bandwidth of a DNS
lookup.

Furthermore, be aware of the potential problem of 'permit' results
allowing open relay:

http://www.postfix.org/SMTPD_ACCESS_README.html#danger

> The reason I'm asking is I added a set of lines for RBL reverse DNS
> and they don't seem to be having any effect.

The "real" question lacks adequate information to answer. See:

http://www.postfix.org/DEBUG_README.html#mail
--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header
Reply | Threaded
Open this post in threaded view
|

Re: smtpd_recipient_restrictions -- Best Practices

blue_cowdawg
In reply to this post by Matt Hayes
smtpd_recipient_restrictions =
    permit_mynetworks,
        permit_auth_destination,
    reject_unauth_destination,
    check_sender_access hash:/etc/postfix/access,
    permit_sasl_authenticated,
    reject_unauth_pipelining,
    reject_non_fqdn_sender,
    reject_non_fqdn_recipient,
    reject_unknown_recipient_domain,
        reject_unkown_helo_hostname,
    reject_invalid_hostname,
        reject_unknown_hostname,
    reject_rbl_client blackholes.easynet.nl,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client cbl.abuseat.org,
   reject_rbl_client cbl.abuseat.org,
    reject_rbl_client dnsbl.njabl.org,
   reject_rbl_client dul.dnsbl.sorbs.net,
    reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2,
    reject_rbl_client list.dsbl.org,
   reject_rbl_client list.dsbl.org,
    reject_rbl_client multihop.dsbl.org,
    reject_rbl_client opm.blitzed.org,
    reject_rbl_client sbl.spamhaus.org,
   reject_rbl_client sbl-xbl.spamhaus.org,
    permit







--
Peter L. Berghold <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: smtpd_recipient_restrictions -- Best Practices

Duane Hill-4
On Thursday, December 08, 2011 at 19:17:44 UTC, [hidden email] confabulated:

> smtpd_recipient_restrictions =
>     permit_mynetworks,
>         permit_auth_destination,
>     reject_unauth_destination,
>     check_sender_access hash:/etc/postfix/access,
>     permit_sasl_authenticated,
>     reject_unauth_pipelining,
>     reject_non_fqdn_sender,
>     reject_non_fqdn_recipient,
>     reject_unknown_recipient_domain,
>         reject_unkown_helo_hostname,
>     reject_invalid_hostname,
>         reject_unknown_hostname,
>     reject_rbl_client blackholes.easynet.nl,
>     reject_rbl_client bl.spamcop.net,
>     reject_rbl_client cbl.abuseat.org,
>    reject_rbl_client cbl.abuseat.org,

No  need  to  check  cbl.abuseat.org  twice?  You  can remove it as it
is included in zen.spamhaus.org which you have below.

>     reject_rbl_client dnsbl.njabl.org,
>    reject_rbl_client dul.dnsbl.sorbs.net,
>     reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2,
>     reject_rbl_client list.dsbl.org,
>    reject_rbl_client list.dsbl.org,
>     reject_rbl_client multihop.dsbl.org,

dsbl.org has been dead since June of 2008.

>     reject_rbl_client opm.blitzed.org,

opm.blized.org ended in May of 2006.

>     reject_rbl_client sbl.spamhaus.org,
>    reject_rbl_client sbl-xbl.spamhaus.org,

These both are included in zen.spamhaus.org.

>     permit

--
There  are  10  kinds  of  people in the world... Those who understand
binary, and those who don't.

Reply | Threaded
Open this post in threaded view
|

Re: smtpd_recipient_restrictions -- Best Practices

Brian Evans - Postfix List
In reply to this post by blue_cowdawg
On 12/8/2011 2:17 PM, Peter L. Berghold wrote:
> smtpd_recipient_restrictions =
>     permit_mynetworks,
>         permit_auth_destination,
This restriction at this location will IGNORE all RBL lookups when mail
is destined for your system.
I suggest removing it as it is implied if reject_unauth_destination
fails to reject.

>     reject_unauth_destination,
>     check_sender_access hash:/etc/postfix/access,
>     permit_sasl_authenticated,

This placement of permit_sasl_authenticated will only skip checks below
it.  Is this what you intend?

>     reject_unauth_pipelining,
>     reject_non_fqdn_sender,
>     reject_non_fqdn_recipient,
>     reject_unknown_recipient_domain,
>         reject_unkown_helo_hostname,
>     reject_invalid_hostname,
>         reject_unknown_hostname,
>     reject_rbl_client blackholes.easynet.nl,
>     reject_rbl_client bl.spamcop.net,
>     reject_rbl_client cbl.abuseat.org,
>    reject_rbl_client cbl.abuseat.org,

Listing an RBL twice won't increase the chance of it being caught.
>     reject_rbl_client dnsbl.njabl.org,
>    reject_rbl_client dul.dnsbl.sorbs.net,
>     reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2,
>     reject_rbl_client list.dsbl.org,
>    reject_rbl_client list.dsbl.org,

Ditto on last comment, plus dsbl.org has been dead a while

>     reject_rbl_client multihop.dsbl.org,
>     reject_rbl_client opm.blitzed.org,
>     reject_rbl_client sbl.spamhaus.org,
>    reject_rbl_client sbl-xbl.spamhaus.org,
>     permit

Permit at then end is harmless as it is also implied if all others pass.

Suggest reviewing all RBLs. Some are dead, and some can be combined.
zen.spamhaus.org will include (sbl|xbl|pbl).spamhaus.org
xbl.spamhaus.org includes cbl.abuseat.org

Brian
Reply | Threaded
Open this post in threaded view
|

Re: smtpd_recipient_restrictions -- Best Practices

/dev/rob0
In reply to this post by blue_cowdawg
Where did you find this list? There are major issues here.

On Thursday 08 December 2011 13:17:44 Peter L. Berghold wrote:

> smtpd_recipient_restrictions =
>     permit_mynetworks,

fine ...

>         permit_auth_destination,

"If the destination is served by this host, accept the mail."

>     reject_unauth_destination,

"If the destination is NOT hosted here, reject the mail."

Nothing goes past this point, ever.

>     check_sender_access hash:/etc/postfix/access,

Bad practice to use a file name "access"; name it for the function it
serves and/or the type of lookup: "sender_access" makes sense.
Furthermore, sender address lookups are very ineffective against spam,
if that was the goal in having it here; and unsafe in whitelisting, if
that was the goal.

>     permit_sasl_authenticated,

Needs to come before reject_unauth_destination, if it is to have any
use.

>     reject_unauth_pipelining,

Okay, except per above that this is never evaluated,

>     reject_non_fqdn_sender,
>     reject_non_fqdn_recipient,
>     reject_unknown_recipient_domain,

Even if these were evaluated, you'd never see such messages at this
point.

>         reject_unkown_helo_hostname,

Misspelled, and risky even if spelled right.

>     reject_invalid_hostname,

Old syntax, but okay. reject_non_fqdn_helo_hostname might help more.

>         reject_unknown_hostname,

This is the old syntax for the one you misspelled.

>     reject_rbl_client blackholes.easynet.nl,

I'm not familiar with the policies of this list. Are you?

>     reject_rbl_client bl.spamcop.net,

Spamcop recommends against being used for outright rejection, it WILL
block some non-spam sometime, because of their automated procedures.

Always ALWAYS know the policies of any third-party service you are
trusting to block mail for you.

>     reject_rbl_client cbl.abuseat.org,
>    reject_rbl_client cbl.abuseat.org,

"It's déjà vu all over again"

>     reject_rbl_client dnsbl.njabl.org,
>    reject_rbl_client dul.dnsbl.sorbs.net,

These two are probably okay, but did you know that?

>     reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2,

What does this do?

>     reject_rbl_client list.dsbl.org,
>    reject_rbl_client list.dsbl.org,
>     reject_rbl_client multihop.dsbl.org,

"It's déjà vu all over again", and what's worse, DSBL shut down in
2008, over three years ago! Were you following some old howto? That
does not work in email land. Spammers change frequently, as do the
antispam tools at our disposal.

>     reject_rbl_client opm.blitzed.org,

I can't remember when this one closed. Before DSBL, I think.

>     reject_rbl_client sbl.spamhaus.org,
>    reject_rbl_client sbl-xbl.spamhaus.org,

SBL is included in SBL-XBL, and CBL (above) is included in the latter.
In addition, all of these are included in the newer (and recommended)
Zen list.

>     permit

The answer to your original question is that permit_auth_destination
prevents any other restrictions from being used.
--
    Offlist mail to this address is discarded unless
    "/dev/rob0" or "not-spam" is in Subject: header
Reply | Threaded
Open this post in threaded view
|

Re: smtpd_recipient_restrictions -- Best Practices

Noel Jones-2
In reply to this post by blue_cowdawg
On 12/8/2011 1:17 PM, Peter L. Berghold wrote:
> smtpd_recipient_restrictions =
>     permit_mynetworks,

OK.

>         permit_auth_destination,


Permits all mail handled by your server.

>     reject_unauth_destination,

Rejects all mail not handled by your server.

Nothing left after that...  None of the following rules are
currently being used.


Probably should remove the permit_auth_destination.


>     check_sender_access hash:/etc/postfix/access,
>     permit_sasl_authenticated,

This is too late for sasl auth.  Move this to just after
permit_mynetworks.

>     reject_unauth_pipelining,
>     reject_non_fqdn_sender,
>     reject_non_fqdn_recipient,
>     reject_unknown_recipient_domain,

Since you've already rejected mail for domains not handled by your
server, the only possible unknown recipient domain is your own when
your DNS hiccups.


>         reject_unkown_helo_hostname,
>     reject_invalid_hostname,
>         reject_unknown_hostname,

reject_unknown_hostname is likely to reject legit mail.  Use with
caution.

>     reject_rbl_client blackholes.easynet.nl,

dead rbl.  It's important to review your RBLs every once in a while
to make sure they are still active and that their policies still
seem reasonable to you.


>     reject_rbl_client bl.spamcop.net,
>     reject_rbl_client cbl.abuseat.org,
>    reject_rbl_client cbl.abuseat.org,

repeated.

>     reject_rbl_client dnsbl.njabl.org,
>    reject_rbl_client dul.dnsbl.sorbs.net,
>     reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2,
>     reject_rbl_client list.dsbl.org,
>    reject_rbl_client list.dsbl.org,

dead.

>     reject_rbl_client multihop.dsbl.org,
>     reject_rbl_client opm.blitzed.org,
>     reject_rbl_client sbl.spamhaus.org,
>    reject_rbl_client sbl-xbl.spamhaus.org,

repeated.  Use zen.spamhaus.org instead.

>     permit
>




  -- Noel Jones