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