Postfix, Unsolicited Commercial Email, and Access Controls

Postfix offers an extremely flexible set of access controls, primarily targeted at preventing unsolicited commercial email from being delivered through the server. In order to construct a suitable set of controls it is necessary to understand the order in which rules are checked and how they interact. By default Postfix will accept mail for delivery from or to any client on your local network and any domains that are hosted by Postfix. So, by default, Postfix is not an open relay. This is a good beginning and may be all that is needed in many environments. However, because UCE is such a nuisance for users and network administrators, it may be worthwhile to implement more advanced filtering. This section will address the basics of the Postfix UCE control features.

Access Control List Order

Every message that enters the smtpd delivery daemon will be processed by a number of access control lists and checked against a number of rules to ensure that the message is one that the administrator actually wants delivered. The goal for most administrators is to prevent unsolicited commercial email from passing through these rules, yet allow every legitimate email to be delivered. This is a lofty goal and a delicate balance. No perfect solution exists, as long as people are willing to steal the resources of others for their own commercial gain and go to great lengths to overcome the protections in place to prevent such abuse. However, in most environments it is possible to develop a reasonable set of rules that prevents most spam and allows most or all legitimate mail through unharmed.

It is important to understand the order of processing if complex sets or rules are to be used, as attempting to use a particular rule too early in the chain can lead to subtle errors or strange mail client behavior. Because not all clients react exactly correctly to some types of refusals, and not all clients create correctly formed SMTP requests, it is not unlikely that a misplaced rule will lock out some or all of your clients from sending legitimate mail. It could also just as easily lead to opening a hole in your spam protections early in the rule set, which would allow illicit mail to pass.

The Postfix UCE controls begin with a couple of simple yes or no checks, called smtpd_helo_required and strict_rfc821_envelopes, both configured in the SMTP Server Options page. The first, if enabled, requires a connecting mail client to introduce itself fully by sending a HELO command. This can stop some poorly designed bulk email programs. The second option requires for the envelope to fit the SMTP specification precisely, thus enforcing complete headers. Though the envelope and HELO can be forged by a bulk mailer, it may stop the more hastily implemented variants (well, how many good programmers do you know that write tools to help spammers?).

The next stage is the four SMTP restrictions also found on the SMTP Server Options page. These further limit from where and to where mail will be delivered. The order of traversal for these four lists of rules is:

  1. Restrictions on client hostnames/addresses or smtpd_client_restrictions

  2. Restrictions on sends in HELO commands or smtpd_helo_restrictions

  3. Restrictions on sender addresses or smtpd_sender_restrictions

  4. Restrictions on recipient addresses or smtpd_recipient_restrictions

Each of these checks can return REJECT, OK, or DUNNO. If REJECT, the message will be refused, and no further rules will be checked. If OK, no further rules in the given restriction will be checked, and the next restriction list will be checked. If DUNNO, the list will continue to process the current restriction until it gets another result ( OK or REJECT) or until the list end is reached, which is an implicit OK. If all lists return OK, the message will be passed to the regular expressions checks, otherwise it will be rejected.

Next come the regular expression-based header_checks and body_checks. These options, if enabled, provide a means to test the actual contents of the headers and the body of the email, respectively. Both operate in the same way, though they should be used somewhat differently. Header checks can be used to prevent well-known spamming domains from sending you email or for stopping some well-known bulk-mailer software. By entering some signature of the offender, like the domain name, or the X-mailer field identifying the software, the mail can be rejected before the body is even sent. Body checks, though they use the same regular expressions and file format as header checks, should be used more sparingly, as the mail must be accepted before it can be checked. Thus bandwidth is wasted on receipt of the mail, and worse, the server will be occupied for a potentially long while with processing the entire contents of every email. In short, use header checks whenever is convenient, and use body checks only when an effective header check cannot be devised. Only REJECT or OK is permitted for the returned values.

Note 

Webmin, as of this writing (version 1.020), does not provide access to the regular expressions-based checks, header_checks and body_checks. It is likely that a near-future version will support these features, however.



The Book of Webmin... or How I Learned to Stop Worrying and Love UNIX
The Book of Webmin: Or How I Learned to Stop Worrying and Love UNIX
ISBN: 1886411921
EAN: 2147483647
Year: 2006
Pages: 142
Authors: Joe Cooper

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net