1<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN" 2 "http://www.w3.org/TR/html4/loose.dtd"> 3 4<html> 5 6<head> 7 8<title>Postfix Per-Client/User/etc. Access Control</title> 9 10<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> 11<link rel='stylesheet' type='text/css' href='postfix-doc.css'> 12 13</head> 14 15<body> 16 17<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">Postfix 18Per-Client/User/etc. Access Control</h1> 19 20<hr> 21 22<h2>Postfix restriction classes</h2> 23 24<p> The Postfix SMTP server supports access restrictions such as 25reject_rbl_client or reject_unknown_client_hostname on the right-hand side 26of SMTP server access(5) tables. This allows you to implement 27different junk mail restrictions for different clients or users. 28</p> 29 30<p> Having to specify lists of access restrictions for every 31recipient becomes tedious quickly. Postfix restriction classes 32allow you to give easy-to-remember names to groups of UCE restrictions 33(such as "permissive", "restrictive", and so on). </p> 34 35<p> The real reason for the existence of Postfix restriction classes 36is more mundane: you can't specify a lookup table on the right-hand 37side of a Postfix access table. This is because Postfix needs to 38open lookup tables ahead of time, but the reader probably does not 39care about these low-level details. </p> 40 41<p> Example: </p> 42 43<blockquote> 44<pre> 45/etc/postfix/main.cf: 46 smtpd_restriction_classes = restrictive, permissive 47 # With Postfix < 2.3 specify reject_unknown_client. 48 restrictive = reject_unknown_sender_domain reject_unknown_client_hostname ... 49 permissive = permit 50 51 smtpd_recipient_restrictions = 52 permit_mynetworks 53 # reject_unauth_destination is not needed here if the mail 54 # relay policy is specified with smtpd_relay_restrictions 55 # (available with Postfix 2.10 and later). 56 reject_unauth_destination 57 check_recipient_access hash:/etc/postfix/recipient_access 58 ... 59 60/etc/postfix/recipient_access: 61 joe@my.domain permissive 62 jane@my.domain restrictive 63</pre> 64</blockquote> 65 66<p> With this in place, you can use "restrictive" or "permissive" 67on the right-hand side of your per-client, helo, sender, or recipient 68SMTPD access tables. </p> 69 70<p> The remainder of this document gives examples of how Postfix 71access restriction classes can be used to: </p> 72 73<ul> 74 75<li> <a href="#internal"> Shield an internal mailing list from 76outside posters</a>, 77 78<li> <a href="#external"> Prevent external access by internal 79senders</a>. 80 81</ul> 82 83<p> These questions come up frequently, and the examples hopefully 84make clear that Postfix restriction classes aren't really the right 85solution. They should be used for what they were designed to do, 86different junk mail restrictions for different clients or users. 87</p> 88 89<h2><a name="internal">Protecting internal email distribution 90lists</a></h2> 91 92<blockquote> 93 94<p> We want to implement an internal email distribution list. 95Something like all@our.domain.com, which aliases to all employees. 96My first thought was to use the aliases map, but that would lead 97to "all" being accessible from the "outside", and this is not 98desired... :-) </p> 99 100</blockquote> 101 102<p> Postfix can implement per-address access controls. What follows 103is based on the SMTP client IP address, and therefore is subject 104to IP spoofing. </p> 105 106<blockquote> 107<pre> 108/etc/postfix/main.cf: 109 smtpd_recipient_restrictions = 110 ... 111 check_recipient_access hash:/etc/postfix/access 112 <i>...the usual stuff...</i> 113 114/etc/postfix/access: 115 all@my.domain permit_mynetworks,reject 116 all@my.hostname permit_mynetworks,reject 117</pre> 118</blockquote> 119 120<p> Specify <b>dbm</b> instead of <b>hash</b> if your system uses 121<b>dbm</b> files instead of <b>db</b> files. To find out what map 122types Postfix supports, use the command <b>postconf -m</b>. </p> 123 124<p> Now, that would be sufficient when your machine receives all 125Internet mail directly from the Internet. That's unlikely if your 126network is a bit larger than an office. For example, your backup 127MX hosts would "launder" the client IP address of mail from the 128outside so it would appear to come from a trusted machine. </p> 129 130<p> In the general case you need two lookup tables: one table that 131lists destinations that need to be protected, and one table that 132lists domains that are allowed to send to the protected destinations. 133</p> 134 135<p> What follows is based on the sender SMTP envelope address, and 136therefore is subject to SMTP sender spoofing. </p> 137 138<blockquote> 139<pre> 140/etc/postfix/main.cf: 141 smtpd_recipient_restrictions = 142 ... 143 check_recipient_access hash:/etc/postfix/protected_destinations 144 <i>...the usual stuff...</i> 145 146 smtpd_restriction_classes = insiders_only 147 insiders_only = check_sender_access hash:/etc/postfix/insiders, reject 148 149/etc/postfix/protected_destinations: 150 all@my.domain insiders_only 151 all@my.hostname insiders_only 152 153/etc/postfix/insiders: 154 my.domain OK <i>matches my.domain and subdomains</i> 155 another.domain OK <i>matches another.domain and subdomains</i> 156</pre> 157</blockquote> 158 159<p> Getting past this scheme is relatively easy, because all one 160has to do is to spoof the SMTP sender address. </p> 161 162<p> If the internal list is a low-volume one, perhaps it makes more 163sense to make it moderated. </p> 164 165<h2><a name="external">Restricting what users can send mail to 166off-site destinations</a></h2> 167 168<blockquote> 169 170<p> How can I configure Postfix in a way that some users can send 171mail to the internet and other users not. The users with no access 172should receive a generic bounce message. Please don't discuss 173whether such access restrictions are necessary, it was not my 174decision. </p> 175 176</blockquote> 177 178<p> Postfix has support for per-user restrictions. The restrictions 179are implemented by the SMTP server. Thus, users that violate the 180policy have their mail rejected by the SMTP server. Like this: 181</p> 182 183<blockquote> 184<pre> 185554 <user@remote>: Access denied 186</pre> 187</blockquote> 188 189<p> The implementation uses two lookup tables. One table defines 190what users are restricted in where they can send mail, and the 191other table defines what destinations are local. It is left as an 192exercise for the reader to change this into a scheme where only 193some users have permission to send mail to off-site destinations, 194and where most users are restricted. </p> 195 196<p> The example assumes DB/DBM files, but this could also be done 197with LDAP or SQL. </p> 198 199<blockquote> 200<pre> 201/etc/postfix/main.cf: 202 smtpd_recipient_restrictions = 203 ... 204 check_sender_access hash:/etc/postfix/restricted_senders 205 <i>...other stuff...</i> 206 207 smtpd_restriction_classes = local_only 208 local_only = 209 check_recipient_access hash:/etc/postfix/local_domains, reject 210 211/etc/postfix/restricted_senders: 212 foo@domain local_only 213 bar@domain local_only 214 215/etc/postfix/local_domains: 216 this.domain OK <i>matches this.domain and subdomains</i> 217 that.domain OK <i>matches that.domain and subdomains</i> 218</pre> 219</blockquote> 220 221<p> Specify <b>dbm</b> instead of <b>hash</b> if your system uses 222<b>dbm</b> files instead of <b>db</b> files. To find out what map 223types Postfix supports, use the command <b>postconf -m</b>. </p> 224 225<p> Note: this scheme does not authenticate the user, and therefore it can be 226bypassed in several ways: </p> 227 228<ul> 229 230<li> <p> By sending mail via a less restrictive mail 231relay host. </p> 232 233<li> <p> By sending mail as someone else who does have permission 234to send mail to off-site destinations. </p> 235 236</ul> 237 238</body> 239 240</html> 241
