From b5896ba9f6047e7031e2bdee0622d543e11a6734 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Mon, 6 May 2024 03:46:30 +0200 Subject: Adding upstream version 3.4.23. Signed-off-by: Daniel Baumann --- README_FILES/RESTRICTION_CLASS_README | 166 ++++++++++++++++++++++++++++++++++ 1 file changed, 166 insertions(+) create mode 100644 README_FILES/RESTRICTION_CLASS_README (limited to 'README_FILES/RESTRICTION_CLASS_README') diff --git a/README_FILES/RESTRICTION_CLASS_README b/README_FILES/RESTRICTION_CLASS_README new file mode 100644 index 0000000..9c78684 --- /dev/null +++ b/README_FILES/RESTRICTION_CLASS_README @@ -0,0 +1,166 @@ +PPoossttffiixx PPeerr--CClliieenntt//UUsseerr//eettcc.. AAcccceessss CCoonnttrrooll + +------------------------------------------------------------------------------- + +PPoossttffiixx rreessttrriiccttiioonn ccllaasssseess + +The Postfix SMTP server supports access restrictions such as reject_rbl_client +or reject_unknown_client_hostname on the right-hand side of SMTP server access +(5) tables. This allows you to implement different junk mail restrictions for +different clients or users. + +Having to specify lists of access restrictions for every recipient becomes +tedious quickly. Postfix restriction classes allow you to give easy-to-remember +names to groups of UCE restrictions (such as "permissive", "restrictive", and +so on). + +The real reason for the existence of Postfix restriction classes is more +mundane: you can't specify a lookup table on the right-hand side of a Postfix +access table. This is because Postfix needs to open lookup tables ahead of +time, but the reader probably does not care about these low-level details. + +Example: + + /etc/postfix/main.cf: + smtpd_restriction_classes = restrictive, permissive + # With Postfix < 2.3 specify reject_unknown_client. + restrictive = reject_unknown_sender_domain + reject_unknown_client_hostname ... + permissive = permit + + smtpd_recipient_restrictions = + permit_mynetworks + # reject_unauth_destination is not needed here if the mail + # relay policy is specified with smtpd_relay_restrictions + # (available with Postfix 2.10 and later). + reject_unauth_destination + check_recipient_access hash:/etc/postfix/recipient_access + ... + + /etc/postfix/recipient_access: + joe@my.domain permissive + jane@my.domain restrictive + +With this in place, you can use "restrictive" or "permissive" on the right-hand +side of your per-client, helo, sender, or recipient SMTPD access tables. + +The remainder of this document gives examples of how Postfix access restriction +classes can be used to: + + * Shield an internal mailing list from outside posters, + * Prevent external access by internal senders. + +These questions come up frequently, and the examples hopefully make clear that +Postfix restriction classes aren't really the right solution. They should be +used for what they were designed to do, different junk mail restrictions for +different clients or users. + +PPrrootteeccttiinngg iinntteerrnnaall eemmaaiill ddiissttrriibbuuttiioonn lliissttss + + We want to implement an internal email distribution list. Something like + all@our.domain.com, which aliases to all employees. My first thought was to + use the aliases map, but that would lead to "all" being accessible from the + "outside", and this is not desired... :-) + +Postfix can implement per-address access controls. What follows is based on the +SMTP client IP address, and therefore is subject to IP spoofing. + + /etc/postfix/main.cf: + smtpd_recipient_restrictions = + ... + check_recipient_access hash:/etc/postfix/access + ...the usual stuff... + + /etc/postfix/access: + all@my.domain permit_mynetworks,reject + all@my.hostname permit_mynetworks,reject + +Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files. +To find out what map types Postfix supports, use the command ppoossttccoonnff --mm. + +Now, that would be sufficient when your machine receives all Internet mail +directly from the Internet. That's unlikely if your network is a bit larger +than an office. For example, your backup MX hosts would "launder" the client IP +address of mail from the outside so it would appear to come from a trusted +machine. + +In the general case you need two lookup tables: one table that lists +destinations that need to be protected, and one table that lists domains that +are allowed to send to the protected destinations. + +What follows is based on the sender SMTP envelope address, and therefore is +subject to SMTP sender spoofing. + + /etc/postfix/main.cf: + smtpd_recipient_restrictions = + ... + check_recipient_access hash:/etc/postfix/protected_destinations + ...the usual stuff... + + smtpd_restriction_classes = insiders_only + insiders_only = check_sender_access hash:/etc/postfix/insiders, reject + + /etc/postfix/protected_destinations: + all@my.domain insiders_only + all@my.hostname insiders_only + + /etc/postfix/insiders: + my.domain OK matches my.domain and subdomains + another.domain OK matches another.domain and subdomains + +Getting past this scheme is relatively easy, because all one has to do is to +spoof the SMTP sender address. + +If the internal list is a low-volume one, perhaps it makes more sense to make +it moderated. + +RReessttrriiccttiinngg wwhhaatt uusseerrss ccaann sseenndd mmaaiill ttoo ooffff--ssiittee ddeessttiinnaattiioonnss + + How can I configure Postfix in a way that some users can send mail to the + internet and other users not. The users with no access should receive a + generic bounce message. Please don't discuss whether such access + restrictions are necessary, it was not my decision. + +Postfix has support for per-user restrictions. The restrictions are implemented +by the SMTP server. Thus, users that violate the policy have their mail +rejected by the SMTP server. Like this: + + 554 : Access denied + +The implementation uses two lookup tables. One table defines what users are +restricted in where they can send mail, and the other table defines what +destinations are local. It is left as an exercise for the reader to change this +into a scheme where only some users have permission to send mail to off-site +destinations, and where most users are restricted. + +The example assumes DB/DBM files, but this could also be done with LDAP or SQL. + + /etc/postfix/main.cf: + smtpd_recipient_restrictions = + ... + check_sender_access hash:/etc/postfix/restricted_senders + ...other stuff... + + smtpd_restriction_classes = local_only + local_only = + check_recipient_access hash:/etc/postfix/local_domains, reject + + /etc/postfix/restricted_senders: + foo@domain local_only + bar@domain local_only + + /etc/postfix/local_domains: + this.domain OK matches this.domain and subdomains + that.domain OK matches that.domain and subdomains + +Specify ddbbmm instead of hhaasshh if your system uses ddbbmm files instead of ddbb files. +To find out what map types Postfix supports, use the command ppoossttccoonnff --mm. + +Note: this scheme does not authenticate the user, and therefore it can be +bypassed in several ways: + + * By sending mail via a less restrictive mail relay host. + + * By sending mail as someone else who does have permission to send mail to + off-site destinations. + -- cgit v1.2.3