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_restrictions
andsmtpd_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.)
Best Answer
OK, this is long question. I'll try to answering some part of above question. And maybe draw a summary based on them.
Disclaimer: I haven't used plesk, but I have used postfix. This question age was more than one year, so maybe the plesk has update their config for postfix. But I think this question would be useful for someone who design and implement postfix restriction
Q1: Are these two configs equivalent?
AND
If an email comes from mynetworks, then it won't be checked by
/var/spool/postfix/plesk/no_relay.re
and/var/spool/postfix/plesk/no_relay.re
. It means that email will be accepted and not changed. In terms of postfix action (REJECT, ACCEPT), it won't different, but for plesk maybe these two headers is important.Q2: 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?
Yeah, it's maybe looks like wasteful when two checks repeated. But this repeated checks will be placed in different places/restrictions. And in every checks, there are some logic or algorithm how postfix treated an email. You may concern of repeated check if the check was heavy one such as check_policy_service or DNSBL. For lightweight check like permit_mynetwork, you may ignore it.
Q3: Is it safe to use just smtpd_recipient_restrictions and smtpd_relay_restrictions and ignore the client, helo, sender?
Well, with two smtpd_recipient_restrictions and smtpd_relay_restrictions should be enough for some advanced restriction. But it's for postfix >= 2.10. For user with postfix < 2.10, you can places checks in multiple directive so postfix won't become too permissive.
Q4: Would my proposed configuration accomplish want I want?
Yep, good job for simplifying your current postfix restriction. But beware that postfix was part of plesk. The engineer of plesk may arrange those restriction for some reasons such as modularity or simple maintenance.
Summary: