Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Learning and Trying to Understand

I've spent the last week learning about what Postfix can do to help reduce spam. If I understand correctly the different *_restrictions configuration parameters control when the checks are done and then the list of restrictions such as permit_mynetworks and check_client_access control what is checked. Is that correct?

If I understand correctly, the checks are performed in the following order:

  • smtpd_client_restrictions
  • smtpd_helo_restrictions
  • smtpd_sender_restrictions
  • smtpd_relay_restrictions
  • smtpd_recipient_restrictions

Is that correct? And if I understand correctly, smtpd_delay_reject does not affect the order of the checks but only affects when the reject is sent. Right?

My Sever Set Up

The smtpd_relay_restrictions configuration parameter doesn't seem to be set on my Plesk 11 server. My Postfix version is 2.8.4.

I've also noticed that some of the checks are listed multiple times under different configuration parameters. Do they need to be listed multiple times?

Here's my current configuration:

smtpd_sender_restrictions =
    check_sender_access hash:/var/spool/postfix/plesk/blacklists
    permit_sasl_authenticated
    check_client_access pcre:/var/spool/postfix/plesk/non_auth.re

smtpd_client_restrictions =
    permit_mynetworks

smtpd_recipient_restrictions =
    permit_mynetworks
    check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
    permit_sasl_authenticated
    reject_unauth_destination

If I understand correctly, that would be the same as this:

smtpd_sender_restrictions =

smtpd_client_restrictions =

smtpd_recipient_restrictions =
    permit_mynetworks
    check_sender_access hash:/var/spool/postfix/plesk/blacklists
    permit_sasl_authenticated
    check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
    permit_mynetworks
    check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
    permit_sasl_authenticated
    reject_unauth_destination

The blacklists file is empty. The the no_auth files has this:

/^/ PREPEND X-No-Auth: unauthenticated sender

and no_relay file has this:

/^/ PREPEND X-No-Relay: not in my network

If I understand correctly, the last two add the headers to all emails that are not already permitted.

Concerns

  • Repeated Checks
    Does Postfix perform the check again when it's listed multiple times? Or does Postfix know it already did that check? If the checks are performed multiple times, that seems like a waste. If they are not performed multiple times, do the no_auh/no_relay headers actually get added properly in all cases?

  • Missing smtpd_relay_restrictions
    Excerpt from Postfix SMTP relay and access control

    NOTE: Postfix versions before 2.10 did not have smtpd_relay_restrictions. They combined the mail relay and spam blocking policies, under smtpd_recipient_restrictions. This could lead to unexpected results. For example, a permissive spam blocking policy could unexpectedly result in a permissive mail relay policy.

    Another excerpt:

    Some people recommend placing ALL the access restrictions in the smtpd_recipient_restrictions list. Unfortunately, this can result in too permissive access.

    So I don't want to list all restrictions under smtpd_recipient_restrictions, but having multiple restrictions and the same checks under different restrictions gets confusing. Is it safe to use just smtpd_recipient_restrictions and smtpd_relay_restrictions and ignore the client, helo, sender?

  • Blacklist
    Isn't that blacklist rather early in the list? If the sender is part of my network and can authenticate, should I really block based on sender email? Right now the table is empty, but I am not sure what Plesk component might add email addresses to that table. It would also go against the RFC that requires 100% delivery to postmaster@ and abuse@ addresses.

Here's What I Want to Accomplish

  • keep it fairly simple
  • ensure I don't create an open relay or other security hole
  • ensure I don't block valid email
  • whitelist postmaster@ and abuse@ addresses that exist in the virtual alias table
  • blacklist IP address blocks of spammers from China/Korea
  • reject, with regular expression, all but certain recipient addresses on a domain that uses a catch-all. I'm using a catch-all on one domain so I can use VERP-y bounce addresses even though Plesk doesn't support VERP.

Here's What I Was Thinking

In /etc/postfix/main.cf

#smtpd_client_restrictions =
#smtpd_helo_restrictions =
#smtpd_sender_restrictions =

smtpd_relay_restrictions =
    permit_mynetworks
    check_client_access pcre:/var/spool/postfix/plesk/no_relay.re
    permit_sasl_authenticated
    check_client_access pcre:/var/spool/postfix/plesk/non_auth.re
    reject_unauth_destination

smtpd_recipient_restrictions =
    check_recipient_access pcre:/etc/postfix/custom/recipient_checks.pcre
    check_client_access cidr:/etc/postfix/custom/sinokorea.cidr
    check_sender_access hash:/var/spool/postfix/plesk/blacklists

In /etc/postfix/custom/recipient_checks.pcre

# Always accept mail to postmaster@ and abuse@
/^postmaster@/ OK
/^abuse@/ OK

# Reject all mail sent to mailapp.ourdomain.com
# except for certain specific recipients
# and bounce messages which may use VERP
if /@mailapp\.ourdomain\.com$/
!/^(?:validuser|anothervalid|bounces(?:\+.+)?)@/ REJECT
endif

I've come across examples that have the @ escaped in the regular expressions. It's not a special character, is it?

Would my proposed configuration accomplish want I want?

(Note to self and any other Plesk users reading this - A cron job may be required to regularly restore the changes to main.cf file since some Plesk actions seem to overwrite this file.)

share|improve this question
add comment

1 Answer 1

Whatever you do, don't leave home without:

smtpd_client_restrictions = reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net

These have been catching the majority for me all by themselves.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.