smtpd_recipient_restrictions

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

smtpd_recipient_restrictions

Simon Brereton-2
Hi

I know this gets beaten to death on a regular basis, but sometimes I get in a muddle and I'd appreciate a sanity check.  Currently my main.cf looks like:

## SPAM STUFF and REJECT CODES ##
smtpd_recipient_restrictions = reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        permit_sasl_authenticated,
        reject_sender_login_mismatch,
        check_helo_access hash:/etc/postfix/helo_checks,
        check_sender_access hash:/etc/postfix/ip_whitelist,
        check_recipient_access hash:/etc/postfix/laxdomains,
        check_sender_access hash:/etc/postfix/backscatter
        reject_invalid_hostname,
        reject_non_fqdn_hostname,
        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname,
        check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
    permit_mynetworks,
        check_policy_service inet:127.0.0.1:10031,
        reject_unlisted_recipient,
        reject_unauth_destination,
        check_policy_service unix:private/policy-spf,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client cbl.abuseat.org,
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client blackholes.mail-abuse.org,
        reject_rbl_client tw.countries.nerd.dk,
        reject_rbl_client kr.countries.nerd.dk,
        reject_rbl_client cn.countries.nerd.dk,
        reject_rbl_client relays.mail-abuse.org,
        reject_rhsbl_sender dsn.rfc-ignorant.org,
        warn_if_reject,
                reject_unknown_client,
        warn_if_reject,
                reject_rhsbl_client dsn.rfc-ignorant.org,
        warn_if_reject,
                reject_rbl_client dnsbl.sorbs.net,
        warn_if_reject,
                reject_rbl_client dnsbl.njabl.org,
        warn_if_reject,
                reject_rbl_client dul.dnsbl.sorbs.net,
        permit


This stuff builds up over time and I find I can't always remember the rational for putting things in the order I put them.  One point of concern that I have is that when I added in the policy-spf the warnings were clear that it needs to go after reject_unauth_destination otherwise it turns the box into an open relay.  The same logic should apply to the policyd service, yes?  But yet there it is above reject_unauth_destination and the online but http://www.checkor.com/ and http://verify.abuse.net/cgi-bin/relaytest says I'm not an open relay, so I'm confused.

Looking over the list though, I propose:

## SPAM STUFF and REJECT CODES ##
smtpd_recipient_restrictions = reject_non_fqdn_sender,
        reject_non_fqdn_recipient,
        reject_sender_login_mismatch,
# shouldn't this be before permit_sasl?
        permit_sasl_authenticated,
        check_helo_access hash:/etc/postfix/helo_checks,
        check_sender_access hash:/etc/postfix/ip_whitelist,
        check_recipient_access hash:/etc/postfix/laxdomains,
#domains that don't want grey-listing and rigourous helo checking - would be better to put this after unknown_recipient_domain, yes?
        reject_invalid_hostname,
        reject_non_fqdn_hostname,
        reject_unknown_sender_domain,
        reject_unknown_recipient_domain,
        reject_invalid_helo_hostname,
        reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname,
        check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre,
        check_sender_access hash:/etc/postfix/backscatter
# the other items will catch more and should therefore come first, yes?
    permit_mynetworks,
        reject_unlisted_recipient,
        reject_unauth_destination,
# does the order of reject_unlisted and reject_unauth matter?  Both are mysql lookups but domain should come before recipient, no?
     check_policy_service unix:private/policy-spf,
        check_policy_service inet:127.0.0.1:10031,
# makes sense to put the grey-listing after SPF verified hosts, yes?
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client cbl.abuseat.org,
        reject_rbl_client zen.spamhaus.org,
        reject_rbl_client blackholes.mail-abuse.org,
        reject_rbl_client tw.countries.nerd.dk,
        reject_rbl_client kr.countries.nerd.dk,
        reject_rbl_client cn.countries.nerd.dk,
        reject_rbl_client relays.mail-abuse.org,
        reject_rhsbl_sender dsn.rfc-ignorant.org,
        warn_if_reject,
                reject_unknown_client,
        warn_if_reject,
                reject_rhsbl_client dsn.rfc-ignorant.org,
        warn_if_reject,
                reject_rbl_client dnsbl.sorbs.net,
        warn_if_reject,
                reject_rbl_client dnsbl.njabl.org,
        warn_if_reject,
                reject_rbl_client dul.dnsbl.sorbs.net,
# can I group all the warn_if_rejects?
        Permit

I'd be grateful for comments/suggestions.  Are there newer/better RBLs I should be using?

Simon



Reply | Threaded
Open this post in threaded view
|

Re: smtpd_recipient_restrictions

/dev/rob0
On Thursday 27 October 2011 10:32:54 Simon Brereton wrote:
> I know this gets beaten to death on a regular basis, but sometimes

Indeed it does, such as ... today! Read the "Config check" thread.

> I get in a muddle and I'd appreciate a sanity check.  Currently my
> main.cf looks like:
>
> ## SPAM STUFF and REJECT CODES ##
> smtpd_recipient_restrictions = reject_non_fqdn_sender,
>         reject_non_fqdn_recipient,
>         permit_sasl_authenticated,
>         reject_sender_login_mismatch,
>         check_helo_access hash:/etc/postfix/helo_checks,
>         check_sender_access hash:/etc/postfix/ip_whitelist,
>         check_recipient_access hash:/etc/postfix/laxdomains,
>         check_sender_access hash:/etc/postfix/backscatter

In that thread I mentioned why this is a bad idea.

>         reject_invalid_hostname,
>         reject_non_fqdn_hostname,

... and that this syntax is deprecated ...

>         reject_unknown_sender_domain,
>         reject_unknown_recipient_domain,
>         reject_invalid_helo_hostname,
>         reject_non_fqdn_helo_hostname,

... but here you are with the same restrictions' new syntax!

>         reject_unknown_helo_hostname,

I mentioned this one too.

>         check_reverse_client_hostname_access
> pcre:/etc/postfix/fqrdns.pcre, permit_mynetworks,
>         check_policy_service inet:127.0.0.1:10031,
>         reject_unlisted_recipient,
>         reject_unauth_destination,
>         check_policy_service unix:private/policy-spf,
>         reject_rbl_client bl.spamcop.net,

I wouldn't trust Spamcop for outright rejection, but it is useful in
postscreen(8) scoring.

>         reject_rbl_client cbl.abuseat.org,
>         reject_rbl_client zen.spamhaus.org,

CBL is part of Zen.

>         reject_rbl_client blackholes.mail-abuse.org,
>         reject_rbl_client tw.countries.nerd.dk,
>         reject_rbl_client kr.countries.nerd.dk,
>         reject_rbl_client cn.countries.nerd.dk,

I don't know those.

>         reject_rbl_client relays.mail-abuse.org,
>         reject_rhsbl_sender dsn.rfc-ignorant.org,

I'd only use the RFCI lists in scoring, too.

>         warn_if_reject,
>                 reject_unknown_client,
>         warn_if_reject,
>                 reject_rhsbl_client dsn.rfc-ignorant.org,
>         warn_if_reject,
>                 reject_rbl_client dnsbl.sorbs.net,
>         warn_if_reject,
>                 reject_rbl_client dnsbl.njabl.org,
>         warn_if_reject,
>                 reject_rbl_client dul.dnsbl.sorbs.net,
>         permit
>
>
> This stuff builds up over time and I find I can't always remember
> the rational for putting things in the order I put them.  One
> point of concern that I have is that when I added in the
> policy-spf the warnings were clear that it needs to go after
> reject_unauth_destination otherwise it turns the box into an open
> relay.  The same logic should apply to the policyd service, yes?

As well as to anything which might return permit or OK. See the other
thread, and the link posted therein.

> But yet there it is above reject_unauth_destination and the online
> but http://www.checkor.com/ and
> http://verify.abuse.net/cgi-bin/relaytest says I'm not an open
> relay, so I'm confused.

You probably are open for certain relay attempts. An online checker
cannot test for all possible combinations of sender, EHLO, et c.

> Looking over the list though, I propose:
>
> ## SPAM STUFF and REJECT CODES ##
> smtpd_recipient_restrictions = reject_non_fqdn_sender,
>         reject_non_fqdn_recipient,
>         reject_sender_login_mismatch,
> # shouldn't this be before permit_sasl?

Yes, if you're using that. Also a good idea to put user submission on
a separate smtpd(8) service.

>         permit_sasl_authenticated,
>         check_helo_access hash:/etc/postfix/helo_checks,
>         check_sender_access hash:/etc/postfix/ip_whitelist,
>         check_recipient_access hash:/etc/postfix/laxdomains,
> #domains that don't want grey-listing and rigourous helo checking -
> would be better to put this after unknown_recipient_domain, yes?
> reject_invalid_hostname,
>         reject_non_fqdn_hostname,
>         reject_unknown_sender_domain,
>         reject_unknown_recipient_domain,
>         reject_invalid_helo_hostname,
>         reject_non_fqdn_helo_hostname,
>         reject_unknown_helo_hostname,
>         check_reverse_client_hostname_access
> pcre:/etc/postfix/fqrdns.pcre, check_sender_access
> hash:/etc/postfix/backscatter
> # the other items will catch more and should therefore come first,
> yes? permit_mynetworks,
>         reject_unlisted_recipient,
>         reject_unauth_destination,
> # does the order of reject_unlisted and reject_unauth matter?  Both
> are mysql lookups but domain should come before recipient, no?
> check_policy_service unix:private/policy-spf,
>         check_policy_service inet:127.0.0.1:10031,
> # makes sense to put the grey-listing after SPF verified hosts,
> yes? reject_rbl_client bl.spamcop.net,
>         reject_rbl_client cbl.abuseat.org,
>         reject_rbl_client zen.spamhaus.org,
>         reject_rbl_client blackholes.mail-abuse.org,
>         reject_rbl_client tw.countries.nerd.dk,
>         reject_rbl_client kr.countries.nerd.dk,
>         reject_rbl_client cn.countries.nerd.dk,
>         reject_rbl_client relays.mail-abuse.org,
>         reject_rhsbl_sender dsn.rfc-ignorant.org,
>         warn_if_reject,
>                 reject_unknown_client,
>         warn_if_reject,
>                 reject_rhsbl_client dsn.rfc-ignorant.org,
>         warn_if_reject,
>                 reject_rbl_client dnsbl.sorbs.net,
>         warn_if_reject,
>                 reject_rbl_client dnsbl.njabl.org,
>         warn_if_reject,
>                 reject_rbl_client dul.dnsbl.sorbs.net,
> # can I group all the warn_if_rejects?
>         Permit
>
> I'd be grateful for comments/suggestions.  Are there newer/better
> RBLs I should be using?

Quality of DNSBL is more important than quality. I have posted my
postscreen rules which are doing a very good job. I'd recommend that
you look that up and consider upgrading if you are pre-2.8.

Also, the Barracuda BRBL is a very nice service, almost on par with
Zen in terms of effectiveness, and has seemed very safe here.
--
    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

Simon Brereton-2
On 27 October 2011 12:07, /dev/rob0 <[hidden email]> wrote:
> On Thursday 27 October 2011 10:32:54 Simon Brereton wrote:
>> I know this gets beaten to death on a regular basis, but sometimes
>
> Indeed it does, such as ... today! Read the "Config check" thread.

It's tricky enough understanding my config, let alone someone else's
but it did raise some of the questions I had and I didn't want to
piggy back..

> I wouldn't trust Spamcop for outright rejection, but it is useful in
> postscreen(8) scoring.

I've never had a false-positive.  If anything it's not useful enough
(considering it's supposed to add IPs on a real-time basis).

>> This stuff builds up over time and I find I can't always remember
>> the rational for putting things in the order I put them.  One
>> point of concern that I have is that when I added in the
>> policy-spf the warnings were clear that it needs to go after
>> reject_unauth_destination otherwise it turns the box into an open
>> relay.  The same logic should apply to the policyd service, yes?
>
> As well as to anything which might return permit or OK. See the other
> thread, and the link posted therein.
>
>> But yet there it is above reject_unauth_destination and the online
>> but http://www.checkor.com/ and
>> http://verify.abuse.net/cgi-bin/relaytest says I'm not an open
>> relay, so I'm confused.
>
> You probably are open for certain relay attempts. An online checker
> cannot test for all possible combinations of sender, EHLO, et c.

Cheers.  I'll fix that.

>> Looking over the list though, I propose:
>>
>> ## SPAM STUFF and REJECT CODES ##
>> smtpd_recipient_restrictions = reject_non_fqdn_sender,
>>         reject_non_fqdn_recipient,
>>         reject_sender_login_mismatch,
>> # shouldn't this be before permit_sasl?
>
> Yes, if you're using that. Also a good idea to put user submission on
> a separate smtpd(8) service.

Submission port is open but not all clients can use it, so we remain
open on 25 for SASL authentication.  That may change in the future.

Whilst rereading postconf.5 I found:

reject_authenticated_sender_login_mismatch
    Enforces the reject_sender_login_mismatch restriction for
authenticated clients only. This feature is available in Postfix
version 2.1 and later.
reject_unauthenticated_sender_login_mismatch
    Enforces the reject_sender_login_mismatch restriction for
authenticated clients only. This feature is available in Postfix
version 2.1 and later.

Should I add those in here (or only on the submission port)?  I don't
really understand their usage.  Surely if sender login is mismatched,
that's not authenticated?   So my understanding (clearly wrong) is
that reject_unauthenticated_sender_login_mismatch =
reject_sender_login_mismatch and
reject_authenticated_sender_login_mismatch can't happen because a
mismatch wouldn't authenticate the sender!  What have I missed?


>> I'd be grateful for comments/suggestions.  Are there newer/better
>> RBLs I should be using?
>
> Quality of DNSBL is more important than quality. I have posted my
> postscreen rules which are doing a very good job. I'd recommend that
> you look that up and consider upgrading if you are pre-2.8.
>
> Also, the Barracuda BRBL is a very nice service, almost on par with
> Zen in terms of effectiveness, and has seemed very safe here.

2.8 is waiting for a debian port :)  My understanding is that once 2.8
is installed I don't need the policyd (at least not for grey-listing,
but it might be useful for other things.  At that stage I'll probably
upgrade it to 2.0 anyway and see what new features it has.  Haven't
seen Cami on here in a while though..

I appreciate the advice and patience.


Simon