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