postfix -`smtpd_recipient_restrictions` defaults are not allowed

[shoulders]

SYSTEM INFORMATION
OS type and version	Ubuntu Linux 22.04.4
Webmin version	2.111
Usermin version	2.010
Virtualmin version	7.10.0
Theme version	21.10
Package updates	9 package updates are available

the issue

When you do a fresh virtualmin install, go to this setting. The default items filled are not listed as options in the office documentation for this setting.

https://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions

Webmin --> Postfix Mail Server --> SMTP Server Options --> Restrictions on recipient addresses

• permit_mynetworks
• permit_sasl_authenticated
• reject_unauth_destination

[iliajie]

Hello,

We impose permit_mynetworks permit_sasl_authenticated reject_unauth_destination values for smtpd_recipient_restrictions option upon Virtualmin installation time.

Default value for smtpd_recipient_restrictions is set to an empty string.

All looks good to me here.

[shoulders]

They are not listed as valid options for smtpd_recipient_restrictions, is the documentation out of date or sometimes wrong?

should these not be in smtpd_client_restrictions instead?

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

Dangerous use of smtpd_recipient_restrictions

• By now the reader may wonder why we need smtpd client, helo or sender restrictions, when their evaluation is postponed until the RCPT TO or ETRN command. Some people recommend placing ALL the access restrictions in the smtpd_recipient_restrictions list. Unfortunately, this can result in too permissive access. How is this possible?
• The purpose of the smtpd_recipient_restrictions feature is to control how Postfix replies to the RCPT TO command. If the restriction list evaluates to REJECT or DEFER, the recipient address is rejected; no surprises here. If the result is PERMIT, then the recipient address is accepted. And this is where surprises can happen.

[iliajie]

They are not listed as valid options for smtpd_recipient_restrictions, is the documentation out of date or sometimes wrong?

I'm not sure what you mean, I see it in the same documentation page:

https://www.postfix.org/SMTPD_ACCESS_README.html#lists

[shoulders]

I see it here in the link you just sent.

but why is it not in the main https://www.postfix.org/postconf.5.html document very confusing. The relevant parameters are referenced for other options but not smtpd_recipient_restrictions

https://www.postfix.org/postconf.5.html#smtpd_recipient_restrictions does not list these as valid parameters.

I think that the new paradigm is to split the relevant actions to to the different functions so as to better select/filter emails

Is this page out of date? it mentions post fix 2.1

Lastly, are these not options that are applied against the client and not the RCPT TO address if we look at it without referencing the documentation.

p.s. I am going to bug out for the day :) Back in the office tommorow 😄

[shoulders]

This might help explain why I moved the settings. things have moved about but compatibility allows stuff to still work.

http://www.postfix.org/postconf.5.html#smtpd_relay_restrictions

• With Postfix versions before 2.10, the rules for relay permission and spam blocking were combined under smtpd_recipient_restrictions, resulting in error-prone configuration. As of Postfix 2.10, relay permission rules are preferably implemented with smtpd_relay_restrictions, so that a permissive spam blocking policy under smtpd_recipient_restrictions will no longer result in a permissive mail relay policy.

http://www.postfix.org/COMPATIBILITY_README.html

• Background: smtpd_relay_restrictions is primarily designed to enforce a mail relaying policy, while smtpd_recipient_restrictions is primarily designed to enforce spam blocking policy. Both are evaluated while replying to the RCPT TO command, and both support the same features.
• To maintain compatibility with earlier versions, Postfix will keep evaluating smtpd_recipient_restrictions before smtpd_relay_restrictions, as long as the compatibility_level is less than 3.6, and the smtpd_relay_before_recipient_restrictions parameter is left at its implicit default setting.

[shoulders]

@iliajie Now I understand this better

We impose permit_mynetworks permit_sasl_authenticated reject_unauth_destination values for smtpd_recipient_restrictions option upon Virtualmin installation time.

All 3 of these values will work in smtpd_recipient_restrictions

• permit_mynetworks = valid and fine
• permit_sasl_authenticated = valid and fine
• reject_unauth_destination = does work but should be in smtpd_relay_restrictions

move reject_unauth_destination to smtpd_relay_restrictions, why?

• smtpd_recipient_restrictions should be used for a Spam control policy
• smtpd_relay_restrictions should be used for a Relay control policy
• http://www.postfix.org/SMTPD_ACCESS_README.html
  • the example on this pages shows reject_unauth_destination in smtpd_relay_restrictions
• Dangerous use of smtpd_recipient_restrictions
  • By now the reader may wonder why we need smtpd client, helo or sender restrictions, when their evaluation is postponed until the RCPT TO or ETRN command. Some people recommend placing ALL the access restrictions in the smtpd_recipient_restrictions list. Unfortunately, this can result in too permissive access. How is this possible?
  • The above mistake will not happen with Postfix 2.10 and later, when the relay policy is specified under smtpd_relay_restrictions, and the spam blocking policy under smtpd_recipient_restrictions. Then, a permissive spam blocking policy will not result in a permissive mail relay policy.