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