Gecko [ 122.154.134.11 ]

Name	Size	Permission
AAAREADME	2.7 KB	-rw-r--r--
ADDRESS_CLASS_README	9.33 KB	-rw-r--r--
ADDRESS_REWRITING_README	42.68 KB	-rw-r--r--
ADDRESS_VERIFICATION_README	19.46 KB	-rw-r--r--
BACKSCATTER_README	12.3 KB	-rw-r--r--
BASIC_CONFIGURATION_README	20.73 KB	-rw-r--r--
BUILTIN_FILTER_README	13.94 KB	-rw-r--r--
CDB_README	2.69 KB	-rw-r--r--
CONNECTION_CACHE_README	8.96 KB	-rw-r--r--
CONTENT_INSPECTION_README	3.29 KB	-rw-r--r--
DATABASE_README	13.25 KB	-rw-r--r--
DB_README	6.9 KB	-rw-r--r--
DEBUG_README	17.71 KB	-rw-r--r--
DSN_README	4.33 KB	-rw-r--r--
ETRN_README	11.4 KB	-rw-r--r--
FILTER_README	27.04 KB	-rw-r--r--
INSTALL	32.72 KB	-rw-r--r--
IPV6_README	11.73 KB	-rw-r--r--
LDAP_README	19.83 KB	-rw-r--r--
LINUX_README	1.64 KB	-rw-r--r--
LOCAL_RECIPIENT_README	5.65 KB	-rw-r--r--
MAILDROP_README	5.16 KB	-rw-r--r--
MILTER_README	36.6 KB	-rw-r--r--
MULTI_INSTANCE_README	42.4 KB	-rw-r--r--
MYSQL_README	4.31 KB	-rw-r--r--
NFS_README	4.73 KB	-rw-r--r--
OVERVIEW	18.57 KB	-rw-r--r--
PACKAGE_README	5.45 KB	-rw-r--r--
PCRE_README	2.87 KB	-rw-r--r--
PGSQL_README	4.4 KB	-rw-r--r--
QSHAPE_README	36.13 KB	-rw-r--r--
RELEASE_NOTES	12.37 KB	-rw-r--r--
RESTRICTION_CLASS_README	6.71 KB	-rw-r--r--
SASL_README	23.29 KB	-rw-r--r--
SCHEDULER_README	65.06 KB	-rw-r--r--
SMTPD_ACCESS_README	15.41 KB	-rw-r--r--
SMTPD_POLICY_README	19.37 KB	-rw-r--r--
SMTPD_PROXY_README	10.47 KB	-rw-r--r--
STANDARD_CONFIGURATION_README	25.24 KB	-rw-r--r--
STRESS_README	19.62 KB	-rw-r--r--
TLS_LEGACY_README	51.46 KB	-rw-r--r--
TLS_README	96.1 KB	-rw-r--r--
TUNING_README	23.76 KB	-rw-r--r--
ULTRIX_README	1.96 KB	-rw-r--r--
UUCP_README	5.14 KB	-rw-r--r--
VERP_README	7 KB	-rw-r--r--
VIRTUAL_README	23.29 KB	-rw-r--r--
XCLIENT_README	9.39 KB	-rw-r--r--
XFORWARD_README	8.28 KB	-rw-r--r--

Code Editor : RESTRICTION_CLASS_README

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
    	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 <user@remote>: 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.

${this.title}

Code Editor : RESTRICTION_CLASS_README