07.06.2014 Views

2 - Raspberry PI Community Projects

2 - Raspberry PI Community Projects

2 - Raspberry PI Community Projects

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

11.1.3.1. IP-Based Access Restrictions<br />

The smtpd_client_restrictions directive controls which machines are allowed to communicate<br />

with the email server.<br />

smtpd_client_restrictions = permit_mynetworks,<br />

warn_if_reject reject_unknown_client,<br />

check_client_access hash:/etc/postfix/access_clientip,<br />

reject_rbl_client sbl-xbl.spamhaus.org,<br />

reject_rbl_client list.dsbl.org<br />

Example 11.6<br />

Restrictions Based on Client Address<br />

When a variable contains a list of rules, as in the example above, these rules are evaluated in<br />

order, from the first to the last. Each rule can accept the message, reject it, or leave the decision<br />

to a following rule. As a consequence, order matters, and simply switching two rules can lead<br />

to a widely different behavior.<br />

The permit_mynetworks directive, used as the first rule, accepts all emails coming from a machine<br />

in the local network (as defined by the mynetworks configuration variable).<br />

The second directive would normally reject emails coming from machines without a completely<br />

valid DNS configuration. Such a valid configuration means that the IP address can be resolved to<br />

a name, and that this name, in turn, resolves to the IP address. This restriction is often too strict,<br />

since many email servers do not have a reverse DNS for their IP address. This explains why the<br />

Falcot administrators prepended the warn_if_reject modifier to the reject_unknown_client<br />

directive: this modifier turns the rejection into a simple warning recorded in the logs. The<br />

administrators can then keep an eye on the number of messages that would be rejected if the<br />

rule were actually enforced, and make an informed decision later if they wish to enable such<br />

enforcement.<br />

TIP<br />

access tables<br />

The restriction criteria include administrator-modifiable tables listing combinations<br />

of senders, IP addresses, and allowed or forbidden hostnames. These<br />

tables can be created from an uncompressed copy of the /usr/share/doc/<br />

postfix-doc/examples/access.gz file. This model is self-documented in its<br />

comments, which means each table describes its own syntax.<br />

The /etc/postfix/access_clientip table lists IP addresses and networks;<br />

/etc/postfix/access_helo lists domain names; /etc/postfix/access_<br />

sender contains sender email addresses. All these files need to be turned into<br />

hash-tables (a format optimized for fast access) aer each change, with the<br />

postmap /etc/postfix/file command.<br />

The third directive allows the administrator to set up a black list and a white list of email servers,<br />

stored in the /etc/postfix/access_clientip file. Servers in the white list are considered as<br />

trusted, and the emails coming from there therefore do not go through the following filtering<br />

rules.<br />

258 The Debian Administrator's Handbook

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!