Univention Bugzilla – Bug 40377
extend smtpd_recipient_restrictions with useful restrictions for blocking spam and not mailable mails
Last modified: 2020-04-03 15:51:08 CEST
It would be nice to set the following smtpd_recipient_restrictions as default to prevent the mailserver from mails, which are not RFC conform and/or not mailable. I recommend the following settings as default: mail/postfix/smtpd/restrictions/recipient/01: reject_non_fqdn_recipient mail/postfix/smtpd/restrictions/recipient/02: reject_non_fqdn_sender mail/postfix/smtpd/restrictions/recipient/03: reject_unknown_sender_domain mail/postfix/smtpd/restrictions/recipient/05: check_policy_service unix:private/listfilter (set if mail/postfix/policy/listfilter=true) mail/postfix/smtpd/restrictions/recipient/10: permit_mynetworks mail/postfix/smtpd/restrictions/recipient/20: permit_sasl_authenticated mail/postfix/smtpd/restrictions/recipient/30: reject_unauth_destination mail/postfix/smtpd/restrictions/recipient/35: reject_unlisted_recipient mail/postfix/smtpd/restrictions/recipient/40 check_policy_service inet:127.0.0.1:10023 (set if mail/postfix/greylisting=true) The first two restrictions reject the request when the MAIL FROM or RCPT TO address is not in fully-qualified domain form, as required by the RFC. The third restriction reject the request when Postfix is not final destination for the sender address, and the MAIL FROM domain has 1) no DNS MX and no DNS A record, or 2) a malformed MX record such as a record with a zero-length MX hostname. These restrictions are set for all incoming mails (even if you are (SASL) logged in or in mynetworks).
A hint should be added, that for old Outlook clients reject_non_fqdn_sender must be after permit_sasl_authenticated (they use only their hostname in HELO).
There is a Customer ID set so I set the flag "Enterprise Customer affected".
Production config of one of our customers: smtpd_recipient_restrictions = check_policy_service unix:private/listfilter, reject_unlisted_recipient, reject_non_fqdn_sender, reject_non_fqdn_recipient, permit_mynetworks, reject_unauth_destination, reject_unknown_sender_domain, reject_invalid_helo_hostname, reject_unknown_sender_domain, check_sender_access hash:/etc/postfix/check_sender_domain_access, check_sender_access hash:/etc/postfix/check_custom_sender_access, check_recipient_access hash:/etc/postfix/check_custom_recipient_access, check_client_access hash:/etc/postfix/check_custom_client_access, #check_policy_service inet:127.0.0.1:10040, permit # special recipient_restrictions which may be used by smtps/submission services # (can be configured via UCR: mail/postfix/submission/restrictions/recipient/...) submission_recipient_restrictions = reject_sender_login_mismatch, check_sender_access hash:/etc/postfix/check_submission_sender_access, reject_unknown_recipient_domain, check_policy_service unix:private/listfilter, check_policy_service inet:127.0.0.1:12345, permit_sasl_authenticated, reject
We should install the new default on fresh installations. During the update from UCS 4.3-0 to 4.3-1 the new default should be only applied if the current configuration is equal to the old default config.
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.
The absence of useful restrictions is still a point which could cause security related problems in case no hardening of the mail stack is done.
A Ticket-Number is required to qualify a Bug as "School Customer Affected" or "Enterprise Customer Affected".
(In reply to Arvid Requate from comment #7) > A Ticket-Number is required to qualify a Bug as "School Customer Affected" > or "Enterprise Customer Affected". The absence of a ticket number doesnt necessarily mean that one of those customer groups is not affected. The ticket system is a tool primarily used by the support team. During system setups we do in professional services we usually dont create tickets because we mostly solve issues by ourself and probably document it somewhere. I added a customer ID which is indeed a School customer. From my point of view it doesnt matter if one of the flags are set or not because the defaults have to be adjusted in any case and will therefor affect all customers.