sender_access:

These are domains that are known to be friendly but that may appear in various DnsBlackholeLists. Examples of good canditates for this file are domains of every company that you do business with; you don't want to blacklist your clients, do you?

Alternatively, you can use this as a private blacklist of domains that you never want to receive mail from.

olethros.dmiyu.org      OK

recipient_access:

Process the same logic as the sender_access file, but on the recipient of the email. I've used this when a spammer Computing.JoeJob^?bed one of my domain and I was receiving about 5,000 bounce messages per hour to email addresses that didn't exist on my system.

spoofeduser@honeypot.net    550 This account was spoofed by some jackass spammer. It doesn't exist and never has.

smtpd_etrn_restrictions = permit # Only all explicit hosts to ETRN # check_etrn_access hash:/usr/local/etc/postfix/etrn_access, # reject

Using PostFix To Reject Spam

I've switched several production servers from using SendMail to PostFix for mail transfer. Among its features are an extremely readable configuration file syntax that allows for some very powerful spam filtering.

Configuration Files

The following sections are the contents (or portions) of various PostFix configuration files.

helo_access:

This file mainly used as a deny list. When a remote server (that is, one not on our LAN) says HELO, reject the message if it claims to be one of our own servers. In other words, if it is demonstrably lying about its identity then we don't want to talk to it.

honeypot.net            REJECT You are not me.  Shoo.
208.162.254.122         REJECT You are not me.  Shoo.

secondary_mx_access:

This is a list of our secondary mailservers. We perform some "expensive" filtering at late stages in the pipeline, and if we can trust that our secondary servers have already performed these tests, then there's no need to run them again. Particularly note the GreyListing^? feature. We really don't want to greylist mail coming in from our secondaries since it could cause a nasty and needless logjam.

2001:470:1f00:ffff::c87 OK
66.119.7.200            OK
glaaki.masonitg.com     OK

master.cf:

main.cf uses these defined services for various filtering operations.

# Amavis-new
127.0.0.1:10025 inet n  -       n       -       -       smtpd
    -o content_filter=
    -o local_recipient_maps=
    -o relay_recipient_maps=
    -o smtpd_restriction_classes=
    -o smtpd_client_restrictions=
    -o smtpd_helo_restrictions=
    -o smtpd_sender_restrictions=
    -o smtpd_recipient_restrictions=permit_mynetworks,reject
    -o mynetworks=127.0.0.0/8
    -o strict_rfc821_envelopes=yes
    -o smtpd_error_sleep_time=0
    -o smtpd_soft_error_limit=1001
    -o smtpd_hard_error_limit=1000
# SPF server
spfpolicy  unix  -       n       n       -       -       spawn
  user=nobody argv=/usr/bin/perl /usr/local/libexec/postfix/smtpd-policy.pl
# Greylisting
greypolicy  unix  -       n       n       -       -       spawn
  user=nobody argv=/usr/bin/perl /usr/local/libexec/postfix/greylist.pl

main.cf:

This configuration makes a few assumptions:

• All of the outgoing mailservers for our domains are on our LAN.
• Our secondary mailservers are using equally restrictive rulesets.
• We are willing to discard email with broken or forged headers.
• We are comfortable with using DnsBlackholeList to reject likely spam.

While the filters are fairly strict, though, they really don't reject anything that isn't almost guaranteed to be from a spammer. Basically, they demand:

• HELO
  • The sending hostname has to be in a valid format. It doesn't even have to exist - it just has to be well-formed.
• Sender address
  • The sender's domain name has to be well-formed and has to exist. If either of those are false, then it would be impossible to send a bounce message or to reply to them anyway.
• Recipient address
  • The recipient's domain name has to be well-formed and existing. If it isn't, then we can't deliver mail to them anyway.
• Pre-delivery
  • We use several of the most conservative DnsBlackholeLists to reject email from open relays, computers infected with mail-transmitting worms, and proven spammers.
  • We use SPF to reject forged ("Joe jobbed") sender domains.
  • All remaining delivery candidates are greylisted, which has proven to be tremendously powerful at blocking spam.
  • Once past the greylist, all messages go through a virus scanner (ClamAV^?) and SpamAssassin via amavisd. Note that is this point in the process, the vast majority of unwanted email has been rejected and very few further emails are caught by these filters. They are strictly a last line of defense.

smtpd_delay_reject = yes

# If you can't be polite, then we don't want to talk to you.
smtpd_helo_required = yes

smtpd_helo_restrictions =
        # Allow anyone on our network, by IP address.
        permit_mynetworks,
        # Now, block anyone *not* on our network who claims to be.
        check_helo_access hash:/usr/local/etc/postfix/helo_access,
        # Syntax checks
        reject_non_fqdn_hostname,
        reject_invalid_hostname,
        # DNS check:
        # reject_unknown_hostname,
        # Allow anyone making it so far.
        permit

smtpd_client_restrictions =
        # Test restricting unknown clients
        warn_if_reject,
        reject_unknown_client,
        permit

smtpd_etrn_restrictions =
        permit
        # Only all explicit hosts to ETRN
        # check_etrn_access hash:/usr/local/etc/postfix/etrn_access,
        # reject

smtpd_sender_restrictions =
        # Authenticated users are good people.  Let them talk to us even if
        # we can't verify their hostname in later steps.
        permit_sasl_authenticated,
        permit_mynetworks,
        # Drop people with screwed up addresses.  How are we supposed to
        # communicate with them anyway?
        reject_non_fqdn_sender,
        reject_unknown_sender_domain,
        permit

smtpd_recipient_restrictions =
        reject_unauth_pipelining,
        # Noone gets to send to invalid recipients.
        reject_non_fqdn_recipient,
        reject_unknown_recipient_domain,
        # Local senders can pick recipients that aren't on our own network.
        permit_mynetworks,
        # So can authenticated SMTP senders.
        permit_sasl_authenticated,
        # At this point, reject relaying for every other domain that we don't
        # serv.
        reject_unauth_destination,
        # OK, we've determined that the recipient is either local or that the
        # sender is authorized to send email to remote domains.  In the case
        # of local recipients, make sure that the person actually exists
        # before wasting expensive DNS checks on them.
        # reject_unlisted_recipients,
        #
        # Now, we've verified that the recipient is legitimate.  The final
        # suite of tests enforces various anti-UCE policies:
        #
        ## DNS CHECKS
        # Blackhole lists
        reject_rbl_client relays.ordb.org,
        reject_rbl_client list.dsbl.org,
        reject_rbl_client sbl-xbl.spamhaus.org,

        # Trust our secondary MXes are equally aggressive at rejecting malformed
        # messages.  Pass mail coming in from any of them.
        check_helo_access hash:/usr/local/etc/postfix/secondary_mx_access,

        # SPF
        check_policy_service unix:private/spfpolicy
        # # Don't greylist mail that we're a secondary MX for
        # check_recipient_access hash:/usr/local/etc/postfix/relay_domains,
        # Grey everything else
        check_policy_service unix:private/greypolicy

        # Ran the gauntlet?  Go ahead and send it!
        permit

Results

I personally receive an average of about 600 emails per day (I'm on a lot of mailing lists). Before implementing this ruleset, I received 20-30 spams in my inbox per day, and SpamAssassin filtered 40 or 50 more into a special IMAP directory for later examination.

On the three-day weekend after going live with these rules on my personal server, I received 1 (one) spam in my inbox and SpamAssassin caught 2 more. The traffic I receive from the mailing lists hasn't decreased at all, so I believe that I'm rejecting few false positives. In short, this has been the single most beneficial change I've ever made to my mail delivery system. The experience has been completely positive with no downside whatsoever.

-- KirkStrauser - 13 Jul 2004