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 controlNOTE: 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 justsmtpd_recipient_restrictionsandsmtpd_relay_restrictionsand 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.)
