Jim Seymour’s suggestions/examples for Postfix anti-UCE configuration

Created : Mon Dec 31 17:39:29 EST 2001
Updated : Mon Mar 19 10:33:09 EDT 2007

Jim Seymour’s suggestions/examples for Postfix anti-UCE configuration.
(Aka : Postfix Anti-UCE Cheat Sheet)

USE AT YOUR OWN RISK !

Note that my configuration may not be suitable for
your purposes. That is one reason I put lots of
comments and so-forth in here. Read it, understand
it, and formulate a stance that best suits your
needs.

The "general flow" of the smtp_recipient_restrictions in main.cf is as
follows (and yes : the order is important) :

1. (1st 6 statements) : ensure the HELO/EHLO and smtp envelope stuff are "sane." Prohibit verification checks of recipient addresses.
2. Dis-allow command "pipelining." (Generally only spamware tries to pipeline—particularly during dictionary attacks.).
3. Permit anything that passes the above restrictions and is from my network. (Destination doesn’t matter.).
4. Out-right reject anything from outside that’s not destined for my network.
5. Check certain recipient addresses before any local blacklisting or DNSbl checks.
6. Check the local black-lists, white-lists and combined black-/whitelists (HELO/EHLO, sender [envelope from] and client [sending server] checks).
7. Check the DNSbls and RHSbls.

Check the Postfix docs for what it all means, in detail. If you’re in
doubt : join the postfix-users mailing list and ask.

For 1.x versions of Postfix :

For 2.x versions of Postfix :

/etc/postfix/main.cf :

/etc/postfix/recipient_checks.pcre :

/etc/postfix/helo_checks :

/etc/postfix/helo_checks.pcre :

/etc/postfix/sender_checks :

/etc/postfix/client_checks :

/etc/postfix/client_checks.pcre :

General Notes On "hostname," "helo," "client," "sender" and "recipient" Access Lists and Restrictions

What "hostname," "helo," "sender" and "client" mean

 HELO/EHLO is what the sending machine *tells* your machine it is. It is easily spoofed and frequently mis-configured. Thus it may have no basis in reality.

 HELO/EHLO is checked with the "helo" and "hostname" smtpd restrictions and checks.

 "Sender" is the envelope-sender address (SMTP "MAIL FROM"), not the client machine’s IP address or host name, or the "From :" field in the headers. (Though envelope-sender may well match "From :" in the headers.)

 "Sender" is checked with the smtpd sender restrictions and checks.

 "Client" is the sending machine’s IP address—and possibly host name (if one can be derived from a reverse lookup of the IP address).

 "Client" is checked with the smtpd client restrictions and checks.

 "Recipient" refers to the email address passed in the SMTP RCPT TO, not the "To :," "Cc :" or other fields in the header.

 "Recipient" is checked with the smtpd recipient restrictions and checks.

If you put access lists before the DNSbl checks, as shown in the "main.cf" examples, above, they can serve as combined whitelists and blacklists.

WARNING : You must be very careful with white-listing ! For example : If you "OK" something in smtpd_recipient_restrictions before reject_unauth_destination, you can turn your server into an open mail relay for whatever you "OK"d or whomever spoofs it (if it’s spoof-able).

See : "Understanding The Order In Which Restrictions Are Applied" for more detail.

If you want smtpd access map entries to match hosts and sub-domains on just the domain part (e.g. : "example.com" matches "host.example.com" and "host.subdomain.example.com," you must specify :

in main.cf. Otherwise, you have to do things like :

The "parent_domain_matches_subdomains" parameter became available in Postfix versions as of 20011119. Prior to that, you must use the "multiple/leading-dot entry" solution.

Postfix experimental release 20030706 contains experimental support for CIDR-based lookup tables, so the regexp-type lookups for address ranges may soon no longer be necessary. To see if your version of Postfix supports CIDR-based maps, do a "man cidr_table" and look for "cidr" in the output of "postconf -m".

See the FAQ regarding "null senders." (Aka : Empty MAIL FROM or empty envelope sender.)

Understanding The Order In Which UCE Checks Are Applied

Anti-UCE/Anti-Virus processing is applied in the following order :

 1. SMTPD Restrictions
 2. Header/body Checks
 3. Content Filters

Understanding The Order In Which SMTPD Restrictions Are Applied

There are three parts to restrictions :

 restriction "stages"
 restrictions
 access lists (or maps)

Postfix’ restriction stages are as follows, and are processed in the following order :

 smtpd_client_restrictions
 smtpd_helo_restrictions
 smtpd_sender_restrictions
 smtpd_recipient_restrictions
 smtpd_data_restrictions

regardless of the order in which they’re listed in main.cf.

Processing within a restriction stage ends on the first match, with the exception of a "DUNNO" result.

What means "DUNNO ?" : "DUNNO" means "I don’t know, somebody else decide." DUNNO is covered in more detail, later.

Each restriction stage must evaluate to "OK" or "DUNNO" for processing to continue with the next stage.

The default value of the smtpd_recipient_restrictions stage is the result of "permit_mynetworks, reject_unauth_destination". The default for every other stage is empty—the default action for which is "DUNNO".

Individual restrictions (within a restriction stage) are evaluated in the order in which they’re listed.

Items in an access list are are matched depending on the type of access list. Regular expression tables, such as pcre and regexp, are checked in the order in which entries are listed. Indexed table map types such as hash, dbm, btree, etc., use the value being checked as an index key.

Here are some simple (and not fully-functional !) examples to demonstrate the principles described above :

Notes : We’ll assume /etc/postfix is Postfix’ configuration directory.
"mumble :" refers to an indexed map type, such as "hash :," "dbm :," etc.

Suppose you have client_checks and sender_checks access maps that look like this :

/etc/postfix/client_checks :

/etc/postfix/sender_checks :

If placed in separate restriction stages :

/etc/postfix/main.cf (partial) :

A client address of 192.168.6.7 will result in a REJECT, and that’s it. If Joe’s email was coming from that address, he’s out of luck. Processing will never reach smtpd_sender_restrictions.

A client address of 172.16.4.5 will stop further processing of additional client checks - so "" will not be processed. But since that restriction stage evaluated to "OK," smtpd_sender_restrictions will still be processed. A sender of bob@example.com will result in a REJECT.

If instead you were to put client_checks and sender_checks in the same restriction stage, something like this :

/etc/postfix/main.cf (partial) :

The "OK" of 172.16.4.5 would stop further processing of the sender restrictions stage, and good ol’ Bob would get through.

What do you mean, "DUNNO ?"

It was noted earlier that a match stops further processing of an access list, and of the restriction stage that "called" it. But what does a restriction return when there’s no match ? Well, it returns "DUNNO." ("I don’t know, somebody else decide.")

It can be handy to explicitly specify DUNNO in certain circumstances, such as to suppress further lookups in an access list, but where you don’t necessarily want to "OK" something. Postfix lets you do this.

In the examples above, a client address of 10.1.2.3 would halt further checks in the client_checks access map, just as if an OK or REJECT were specified, but processing would resume with the next restriction check in that stage.

How might this come in handy ?

Well, let’s say :
 You don’t want to accept connections from 10.* IPs
 Except for example.com, at 10.1.2.3, which you do want.
 But you don’t want to hear from Bob.

Using the *second* example of smtpd_sender_restrictions, above :

Everything in 10.*.*.* except 10.1.2.3 will result in a REJECT because of the first two client_checks entries.

Since 10.1.2.3 resulted in a DUNNO, rather than an OK, processing will resume with the sender checks.

Bob will get REJECTed by the entry in the sender checks file.

In summary :

 "REJECT" stops processing entirely.

 "OK" stops processing of an access list and the restriction stage
that contains it. Processing resumes with the next restriction
stage (if any).

 "DUNNO" stops processing of an access list. Processing resumes with the next item in the restriction stage (if any).

 Finally, remember that unless you have set smtpd_delay_reject = no (default is "yes"), no actual rejecting takes place until after RCPT TO in the SMTP exchange. In fact...

You can put all restrictions under one restriction class ?

Yes. As Liviu Daia notes :

Any of the smtpd restrictions may contain checks referring to a preceding SMTP stage (check_sender_access may appear [for example] in smtpd_recipient_restrictions), with the exception of smtpd_data_restrictions, which, as a rule of thumb, should not refer to restrictions specific to recipient checks.

Victor Duchovni added :

With "smtpd_delay_reject = yes" (that is by default), *all* the built-in restriction lists other than "smtpd_data_restrictions" are evaluated for every recipient. So if possible expensive checks on the client ip or name, HELO name, or sender address that are independent of the recipient address should be moved to the "data" restrictions. In this scenario smtpd_recipient_restrictions can be used for just relay control !

Note that results of RBL lookups are cached, so these are cheap to evaluate multiple times.

So, for performance reasons, one might be tempted to put all restrictions in smtpd_data_restrictions. But note also this comment by Victor Duchovni :

Multi-recipient messages do not have a "distinguished" recipient. So all restrictions that look at recipient addresses evaluate to "DUNNO" when used in the data restrictions. This is why they are not generally useful in that context.

There’s another possible danger with putting all restrictions under smtpd_recipient_restrictions. You must be very careful with white-listing ! For example : If you "OK" something in smtpd_recipient_restrictions *before* reject_unauth_destination, you can turn your server into an open mail relay for whatever you "OK"d or whomever spoofs it (if it’s spoof-able).

Lastly : For Postfix 2.x versions, reject_unauth_pipelining should always be placed in smtpd_data_restrictions, even if it’s the only one you put there. See FAQ Q16/A16.

Acknowledgments

This section was created from contributions by Noel Jones, Liviu Daia, Victor Duchovni and Wietse Venema in the postfix-users mailing list.

Understanding Header and Body Checks

Header and body checks files are not access maps. You *don’t* "postmap" them. Nor do you "postmap" any other regexp or pcre file. (You do have to do a "postfix reload" after changing them, however.)

Header checks regular expressions are applied in the order in which they are listed in your header checks file. First match wins. They are applied to each header in the email in the order in which the headers are seen. Body checks work similarly, except against the email body, line-by-line.

You cannot whitelist a sender or client in an access list to bypass header or body checks. Header and body checks take place whether you explicitly "OK" a client or sender, in access lists, or not.

Also, as Noel Jones noted in reply to a question in postfix-users :

The FILTER action isn’t performed until after the mail has been fully accepted stored in the queue. Therefore, you cannot bypass header/body checks using the FILTER action.

You cannot "OK" an entire set of headers based on one header.

For example : One might be tempted to try :

in an attempt to block everything from example.com, except if it’s
sent to "postmaster" or "abuse" at your end.

This will not work. Postfix header checks are header-by-header. Even
if you "OK" one header, the other headers will be checked
independently. Even were that not so : You have no way of knowing in
what order headers will be present. So, in the example above, if the
"From :" is seen before the "To :", you’d be out-of-luck anyway.

What *will* work is the following :

to reject everything from users in example.com except Joe.

Note : The above are not functional regular expressions.
They’re for demonstration purposes only. Proper regular
expression construction is beyond the scope of this
document.

Body checks are likewise : Evaluated line-by-line.

Postfix presents multi-line text headers, e.g. :

and (if it’s a newer, "MIME-aware" version of Postfix) :

to header_checks as a single text string, with embedded newlines.

Conditional Header Checks

People often ask if they can check one kind of header based on the
existence of something, or the lack thereof, in a different
header.

For example :

The goal above obviously being to check for headers with "Make
Money Fast !" in the Subject only if the recipient is *not* the
postmaster.

This won’t work ! Remember : Header (and body) checks process one
header (or line, with body checks) at a time. Since it’s
impossible for the "To :" header to be "on the same line" as the
"Subject :" header, the example above does nothing interesting.

By the way, there’s another problem with the example above : Do not
indent lines within "if" conditionals. Start all lines in header
and body checks at the left margin.

Understanding DNSbl’s and RHSbl’s

A DNSbl (DNS BlockList) works for IP addresses only. Thus one can
check client IP address’ against DNSbl’s, but not sender addresses.

An RHSbl (Right-Hand Side BlockList - so-called because they are
primarily meant to check the "right-hand side" of sender addresses)
works on host and domain names. Postfix 2.x supports the use of these
for client host and domain names, as well, but the check is meaningful
only *if* the client address has a hostname associated with it.

Examples :

Note : The following is for illustration purposes only, and
does NOT constitute endorsement of the lists used.

reject_rbl_client sbl.spamhaus.org valid - check client IP
address’ against the
SpamHaus DNSbl

reject_rhsbl_sender rhsbl.sorbs.net valid - check the RHS of
sender addresses against
the SORBS RHSbl

reject_rhsbl_client rhsbl.sorbs.net valid - check the client’s
domain against the SORBS
RHSbl. Doesn’t work if
client is "unknown"

reject_rbl_client rhsbl.sorbs.net INVALID - attempt to check
client IP address’ against
an RHSbl

reject_rhsbl_sender sbl.spamhaus.org INVALID - attempt to check
sender domain names against
a DNSbl

reject_rhsbl_client sbl.spamhaus.org INVALID - attempt to check
client domain names
against SpamHaus DNSbl

See Also : "A Note About DNS BlackLists (DNSbl’s and RHSbl’s)," later
in this document.

If you’re unclear on what’s meant by "client" and "sender," see the
section ``What "helo," "sender" and "client" mean,’’ under ``General
Notes On "recipient," "helo," "sender" and "client" Access Lists,’’
above.

Lastly : Postfix 1.x versions support DNSbls *only*, via the
"maps_rbl_domains" list and the "reject_maps_rbl" restriction.

Stopping Forged Freemail

In main.cf, create an smtpd restriction class and, to that restriction
class, add a client checks that lists all the "OK" hosts, followed by
a reject. Add a check_sender_access rule that checks against a list
of freemail hosts.

/etc/postfix/main.cf :

In the check_sender_access file, list all the freemail hosts you wish
to check, and have the check defer to the from_freemail_host
restriction class.

/etc/postfix/freemail_access :

In the restriction class’ check_client_access list (file), "OK"
freemail hosts only.

/etc/postfix/freemail_hosts :

What happens is : client host connects and attempts to deliver email.
If the senders domain is listed in the freemail_access file, the
restriction class causes the client host to be checked to see if it,
too, is one of the freemail hosts. If it is, it’s "OK". If it’s not
(e.g. : sender claims to be from yahoo.com and the client host is
really in spamhaven.net), the terminating reject rule kills it.

It should go without saying : Users that are in the habit of mailing
through their ISP’s SMTP server, but with a freemail sender address,
will be rejected by restriction classes such as this unless they’re
whitelisted before-hand.

As noted under the "main.cf" examples at the beginning : "dbm" or
"hash" depends on your system. The above is for my Sun SPARC
Solaris boxen. Linux usually uses "hash".

See also : FAQ Q1/A1 and Q15/A15.

When Anti-Spam Measures Collide : Sender Address Verifications Rejected

I recently found myself unable to email anybody with a Verizon
email address. After a bit of investigating, I figured-out it
was because Verizon uses a form of Sender Address Verification
(SAV), spam from Verizon space had caused much of it to be
blacklisted on my mailserver, so Verizon’s servers’ SAV probes
were being rejected, resulting in even legitimate email addresses
on my mail server looking to Verizon as if they weren’t.

Restriction classes to the rescue !

/etc/postfix/main.cf :

/etc/postfix/verizon_sav_client.pcre :

/etc/postfix/verizon_sav_sender.pcre :

Basically, this simply says : If the (envelope) sender is
"antispamNNN@mumble.verizon.net" *and* the client hostname is
"scNNNpub.verizon.net" or "svNNNpub.verizon.net," OK it. If it’s
"antispamNNN@mumble.verizon.net" and it’s *not* a valid host, reject
it.

Make sure to put the smtpd_recipient_restrictions entry before any of
the anti-UCE checks you want to skip, but *after* the
"permit_mynetworks" and "reject_unauth_destination" pair.

This actually neatly kills two birds with one stone : Not only can it
enable Verizon’s SAV-like mechanism to work (with your mail server)
again, but it’ll also reject attempts to spoof a Verizon "antispam..."
email address.

Note : It would *appear* Verizon caches the results of its SAV tests.
If Verizon has recently rejected an email from your server due to it
rejecting the SAV test message, there will be an unknown (to me,
anyway) delay before they’ll accept email from it again.

Back-Scatter To Non-Sending (Role) Addresses

If spammers are spoofing one of your non-sending role address’, such
as "info@" or "www@," you will undoubtedly get hit with back-scatter
from ill-designed/-configured "accept and bounce" electronic mail
systems. This can be at least partially mitigated against by refusing
to accept bounces to addresses that do not send.

Restriction classes to the rescue, again !

/etc/postfix/main.cf :

/etc/postfix/check_bounce_sender :

/etc/postfix/non-sending_recipients :

Basically, this simply says : If the (envelope) sender is the null
sender, check to see if the recipient is one that never sends email
and, if so, 5xx with an informative explanation.

You can add additional senders to check_bounce_sender. I’ve found the
following useful :

MAILER-DAEMON@
Gateway_SMTP@
devnull@
MDaemon@
imsspostmaster@
Administrator@
imss@
majordomo@
symantec_antivirus_for_smtp_gateways@
postmaster@
Symantec_Mail_Security_for_SMTP@
Mail_Security_for_SMTP@

Don’t forget to postmap the two access files and "postfix reload"
after changes to main.cf.

Note also that the "dbm :" type will have to be "hash :" on some
systems.

Compensating For Verisign’s Abuse Of The Domain Name System (DNS)

(And other uses for check_*_mx_access.)

On or about September 16th, 2003, Verisign put in wildcard records for
the .com and .net top-level domains, causing lookups on non-existent
domains, or even domains that simply have no DNS, to return a DNS
record pointing to one of their own servers. The result of this, from
a mail server administrator’s perspective, is that checks for valid
sender and recipient domains (reject_unknown_sender_domain and
reject_unknown_recipient_domain, respectively, in Postfix) wouldn’t
work for the .com and .net TLDs any more, because now *all* .com and
.net domains would appear to be "valid." Say "Thank you, Verisign."

Wietse quickly released a new Postfix snapshot to address this
problem. You use it like this :

/etc/postfix/main.cf :

/etc/postfix/mx_access :

Then "postmap" the mx_access file, "postfix reload" and you’re all
set.

Remember : "dbm" or "hash" depends on your system. The
above is for my Sun SPARC Solaris boxen. Linux usually
uses "hash".

If you wanted to *really* make sure, change the map types to "cidr :"
and make the mx_access file look like this, for example :

/etc/postfix/mx_access :

Support for this requires snapshot release postfix-2.0.16-20030917,
or later.

While you’re at it, you might wish to consider doing :

route add -net 64.94.110.0 -netmask 255.255.255.0 127.0.0.1 1

as well. Just to show Verisign you really care ;).

Here are some other things you can do with check_*_mx_access (this is
a "cidr :" map type) :

The point here being : Why accept email from senders, or attempt to
deliver it to recipients, whose MX resolve to machines you can’t
possibly contact ?

Two Cautions are in order :

If you’re running "split horizon" (aka : "split namespace") DNS,
where hosts on your LAN, including your mail server, have a
different view of IP addresses than hosts outside your LAN, and
your LAN addressing is RFC 1918, you can end up rejecting all
email to your own mail server. (Yes, I’m sad to say, this author
did this to himself !) To work around this you need to either put
"check_recipient_mx_access," and perhaps "check_sender_mx_access,"
*after* permit_mynetworks, or whitelist the IP addresses in
question.

If you’re using "check_recipient_mx_access" on a mail gateway or
Internet-connected mailserver, and the destination for outgoing
email has a large number of MX’ whose A records don’t resolve,
with "warning : Unable to look up MX host...", the SMTP client may
time-out awaiting a response from the Internet-connected MTA, as
the latter spends a long time running each unresolvable
MX through check_recipient_mx_access, resulting in the email never
being moved to the Internet-connected MTA, even though it may
actually be deliverable.

It has come to my attention that some "anti-spammers" have taken to
listing 127.0.0.1 and the like as one of their domain MX’ in the
belief that it stops or reduces spam. (For those whom are interested
in my opinion : No, I don’t think doing this is a particularly good
idea—for a variety of reasons. See FAQ Q18/A18.) The configuration
detailed above will cause email from such domains to be rejected.

Some Common Anti-UCE-Related Postfix Logfile Messages

Here’s a sub-set of logfile entries you might see, resulting from some
of the anti-UCE measures discussed here. This is *not* a comprehensive
list ! Such a list would be impractical.

Client host rejected : cannot find your hostname

reject_unknown_client

(See FAQ Q7/A7)

Client host rejected :

check_client_access maptype:mapname

If a custom reject message is specified in the access list, that
will be , else the generic "Access denied" will be
logged.

Client host [ip address] blocked using ...

reject_rbl_client (Postfix 2.x) or
reject_maps_rbl + maps_rbl_domains (Postfix 1.x).

Helo command rejected : Host not found

reject_unknown_hostname

(See FAQ Q7/A7)

Helo command rejected : Invalid name

reject_invalid_hostname

Helo command rejected : need fully-qualified hostname

reject_non_fqdn_hostname

Helo command rejected :

check_helo_access maptype:mapname

If a custom reject message is specified in the access list, that
will be , else the generic reason will be logged.

Recipient address rejected : Domain not found

reject_unknown_recipient_domain

Recipient address rejected : Improper use of SMTP command pipelining

reject_unauth_pipelining

Recipient address rejected : need fully-qualified address

reject_non_fqdn_recipient

Relay access denied

reject_unauth_destination

Sender address rejected : Domain not found

reject_unknown_sender_domain

Sender address rejected : need fully-qualified address

reject_non_fqdn_sender

Sender address rejected :

check_sender_access maptype:mapname

If a custom reject message is specified in the access list, that
will be , else the generic "Access denied" will be
logged.

Sender address [user@some.domain] blocked using...

reject_rbl_client (Postfix 2.x only)

Unable to look up MX host ... for Recipient address ... : Host not found,
try again

check_recipient_mx_access

One-or-more of the recipient domain’s MX hosts are unresolvable.
This *may* result in otherwise deliverable email being stalled.

A Note About DNS BlackLists (DNSbl’s and RHSbl’s)

This bit’s non-technical. I put it in here, not so much for the
experienced mail admin., but for those new to the game. And because,
as with the info above, I’ve been asked repeatedly for my opinion.

Think about your use of DNSbl’s carefully. If you use a DNSbl to
block/reject email, you are effectively giving some outside party
control over your mail server. This is not *necessarily* a Bad
Thing—it’s just something to keep in mind. Choose wisely.

Another thing that’s *absolutely* critical, if you’re going to use
a DNSbl or RHSbl, is that you keep up-to-date on its status.
Sometimes, when a blocklist goes out-of-service, you can end-up
rejecting *all* email.

That being said...

DNSbl’s I Currently Use (in alphabetical order)

Currently Under Evaluation

I currently am not evaluating any new DNSbls or RHSbls.

DNSbl’s and RHSbl’s I Specifically Recommend Against (And Why)

• relays.osirusoft.com - Out-of-service since Aug. 26, 2003. Announced to multiple forums and mailing lists at the time.

• SPEWS - I used to use SPEWS, but became concerned about its policies after a couple of what I felt to be "questionable" listings, so I stopped using it. I don’t have a big problem with SPEWS, per se (in fact : I generally support its listing policies and methodology), I just don’t use it nor recommend others do so. My thanks to SPEWS for the use of its list in the past.

As of March, 2007, it would appear SPEWS data hasn’t been
updated since August, 2006. Who knows what the nature of the
problem might be, but I’d argue a list that combines SPEWS’
level of aggressiveness with this degree of undependability
shouldn’t be used.

• proxies.relays.monkeys.com - Out-of-service since Monday, Sep. 22nd, 2003. Announced to news.admin.net-abuse.email, at least. Thanks to its maintainer for his contributions.

Update : Announced to news.admin.net-abuse.email (and
elsewhere ?), on Tuesday, Feb. 10, 2004, that
*.relays.monkeys.com nameservers would be decommissioned,
thus resulting in future lookups going unanswered.

Update : As of 15 March, 2004, relays.monkeys.com appears to be
returning positive responses for all addresses.

• nomorefunn.moensted.dk - This sorry excuse for a DNSbl has my IP netblock listed because it’s a DSL netblock ? A business class DSL netblock with static, routable IP address assignments ? Heh. If you bounce me because you’re using this abomination, I will locally, permanently blacklist your domain at LinxNet.com.

• xbl.selwerd.cx - Out-of-service since Monday, Nov. 10th, 2003. Announced to news.admin.net-abuse.email and news.admin.net-abuse.blocklisting, at least.

• DRBL - Allegedly "Distributed Realtime Blocking List". Appears to be operated by Russian ISPs and administrators ? Hard to say, being as every web site I went to that referred to this "organization" was down or displayed a default Apache installation page. Anyway, they have all of the DSL space in which I’m located blackholed. That’s their prerogative. It’s also my prerogative to permanently locally blacklist anybody that bounces my email because they’re using it.

• rfc-ignorant.org - Technically a Right-Hand Side blocklist (RHSbl), rather than a DNSbl. RFCI’s listing criteria takes RFC requirements far too literally, in my opinion, and, some argue, interprets them incorrectly.

• dorkslayers.com - Dead since May, 2003. Announced to news.admin.net-abuse.email, at least. Wasn’t set to purposefully return "hits" on everything when it was de-commissioned, but when Verisign pulled its recent .com and .net hijack stunt, that’s what happened.

• easynet.nl - On Friday, November 21, 2003, the admin of the easynet.nl DNSbl and RHSbl zones announced their retirement. They have been discontinued as of December 1, 2003. Ben : Thanks for your contributions.

• wirehub.net - Wirehub was purchased by easynet.nl and all wirehub DNSbl zones were renamed to easynet zones. This change was announced back on May 25, 2003. Subsequent to this, the easynet.nl DNSbl’s and RHSbl’s were discontinued. (See above.)

• opm.blitzed.org - Blitzed.org’s OPM (Open Proxy Monitor) zones were discontinued as of May, 2006. See http://wiki.blitzed.org/OPM_status

• ORDB.org - Open Relay DataBase announced its shut-down on December 18, 2006.

See Also : "Understanding DNSbl’s and RHSbl’s," earlier in this
document.

When There’s No Point To A Secondary MX

This doesn’t relate directly to anti-UCE measures, per se, but the
question often comes up "How do I reject spam relayed via my secondary
MX ?" - when the secondary MX isn’t one under the user’s control.

Admins often configure things to specify their ISP’s mail server, or
some other mail server not under their control, as their domain’s
secondary MX. One imagines the thinking is that this secondary MX
will collect email destined for their domain if the primary MX is down
or unreachable, and forward it on when the primary again becomes
available.

There’s really no advantage to be gained by specifying such a
host as a secondary MX, and, in fact, there are two distinct
disadvantages to doing so.

A backup MX that isn’t under your control, where you can enforce
the same anti-UCE restrictions as you do on your primary MX, only
provides a way for spammers to get around your anti-UCE
restrictions. And spammers *will* exploit it. Anti-UCE HELO and
client checks can’t be enforced at all on email relayed from such
a secondary MX.

The second disadvantage is that recipient, sender, header and body
checks, and any other content checks (e.g. : anti-virus filters) at
your mail server, on email relayed from the secondary MX, *will*
result in rejects, but, since the email has already been accepted on
your domain’s behalf by the secondary MX, it will be bounced by your
secondary MX—probably to a spoofed, innocent 3rd party. At this
point you become part of the Internet’s problem.

Most any modern MTA will queue email for delivery for 3-5 days
anyway, so a backup MX that only ends-up delivering to your
primary MX doesn’t do anything actually useful for you.

The only time a secondary MX makes sense is if it’s a mail server
under your control, where you can enforce rules consistent
between it and your primary MX, it’s on an independent network
connection, and that can relay incoming email via an independent,
usually private, connection. E.g. (simplified) :

Frequently Asked Questions (FAQs)

Q1. Is there any reason why the "freemail senders" checks can’t be
extended to check other hosts that are commonly spoofed for UCE
purposes ? AOL, for example, is commonly spoofed.

A1. Not at all. But understand what’s really happening with the
"freemail senders" check. All it’s doing is checking that if it’s
any of the listed freemail senders, the host is any of the listed
freemail senders. It does *not* check to make sure that the sender
domain and host are consistent with one another. To accomplish
the latter, precisely, you’d have to have separate restriction
classes for each domain you wanted to check.

See also : FAQ Q15/A15.

Q2. Regarding your checks "reject_invalid_hostname,"
"reject_non_fqdn_hostname" and "check_helo_access" : Isn’t rejecting
on HELO/EHLO not being a valid and FQDN’d hostname a violation of
the RFC’s ?

A2. Why yes, yes it is. Doing so is a judgement call. In *my*
experience : it stops more spam than it does result in "false
positives." And in the few cases where it has resulted in false
positives, I’ve found that a friendly dialog with the offending
mail server’s owner got it straightened out. Your mileage may
vary.

Machines outside "mynetworks" should *never* HELO/EHLO as being in
your domain. So even if you want to forego
"reject_invalid_hostname" and "reject_non_fqdn_hostname," it seems
to me perfectly reasonable to still do the "check_helo_access"
restriction.

Q3. But MUAs under Microsoft Windows send HELO with only the
hostname part, no domain name ! Apple Mail sets it to only
the domain part from the client email address !

A3. For internal machines (i.e. : on your LAN) this is a non-issue
*if* "permit_mynetworks" precedes "reject_invalid_hostname" and
"reject_non_fqdn_hostname." (The examples I give above are
primarily designed for Internet email gateways.) Likewise
"permit_sasl_authenticated," if you’re using it.

Q4. But a lot of people use Microsoft mail clients !

A4. With regards to that point, I am guided by this philosophy :

"If fifty million people say a stupid thing,
it is still a stupid thing."
- Anatole France

Simply substitute "do" for "say" ;)

Q5. Couldn’t one do the same thing with check_sender_access
(envelope-sender) as with the check_helo_access with regards to
checking for somebody spoofing ones own domain ?

A5. Dangerous. There are a number of scenarios where a sender from
outside mynetworks might legitimately have an envelope-sender
address in (one of) your domain(s). E.g. :

fred@yourdom.ain sends mail to jim@example.com

But jim@example.com has, unknown to fred, a .forward pointing
to jim@yourdom.ain

That results in example.com’s mailserver legitimately sending
that email with yourdom.ain in the envelope-sender

(Thanks a tip o’ the hat to Andrew of SuperNews for pointing
this gotcha out.)

Q6. Why are all of your restrictions under recipient restrictions ?

A6. You didn’t read the comments below those examples, did you ?
Please go back and do so. See also : "Understanding The Order In
Which Restrictions Are Applied"

Q7. Why don’t you use reject_unknown_hostname or
reject_unknown_client ?

A7. Too many "false positives" (that is : rejects too much non-spam
email), in my experience.

(By the way, Derrick ’dman’ Hudson brought up a very
good point in the postfix-users mailing list : If you’re
going to use reject_unknown_hostname anyway, you
probably want to put it *after* reject_non_fqdn_hostname
to prevent an unqualified hostname from matching one in
your own domain.)

Q8. Do you use header and body checks ?

A8. Yes

Q9. Why don’t you put header and body checks suggestions on a web
page ?

A9. Two reasons : 1) I don’t feel the need to show spammers how to get
around them and 2) They change too frequently for anything
published to stay up-to-date. Sorry. I do, however, have some
of my anti-virus/worm/trojan header and body checks expressions
shown here :

http://jimsun.linxnet.com/misc/header_checks.txt
http://jimsun.linxnet.com/misc/body_checks.txt

Q10. I notice you have both sbl.spamhaus.org *and*
blackholes.easynet.nl in your list of DNSbls. Since the latter
includes the former : What’s the point ?

A10 : You’ll observe in my main.cf examples that I check the SBL before
blackholes.easynet.nl. I do this so I can track SBL "hits"
separately. There’s no particular reason for this. I just like
to do it.

Update : As of August 6, 2003, Steve Linford of the Spamhaus
Project announced that the SBL will no longer be available via
other DNSbls. If you want to use the SBL, you’ll have to use
sbl.spamhaus.org.

Update : As of Friday, November 21, 2003, the administrator of
the easynet.nl DNSbl and RHSbl zones announced they would be
discontinued as of December 1, 2003.

Q11. Why do you use the DNSbl’s/RHSbl’s you use ?

A11. The main criteria is my personal determination, based in part on
the opinions of people I know and trust, as to whether I feel I
can trust the honesty, integrity, competence, consistency and,
well... "sanity" of the list maintainer(s). Then, of course,
what the list’s published listing policy is. (The latter is
meaningless w/o the former.)

In many cases : I’ve had one-on-one interaction with the
maintainer(s) of the DNSbl’s I use.

Please note that a particular DNSbl’s absence on my "uses" list
is NOT a condemnation. It more likely means that the DNSbls I’m
using seem sufficient. It might also mean that I’ve tried a
particular DNSbl and found that it doesn’t catch anything that
the others I’m already using don’t catch—so there’s no point.

Q12. Shouldn’t "reject_unknown_sender_domain" reject email with an
empty envelope sender (empty MAIL FROM or "null sender") ?

A12. No ! The null sender (<>) is used to send bounces. According to
RFCs, "An empty reverse path MUST be supported." (Ref : RFC1123,
section 5.2.9)

Q13. Is there a way to get Postfix to do DNSbl or RHSbl checks on
"Received :" headers ?

A13. Not "natively." That is : Not without an add-on of some type,
such as SpamAssassin.

If you’re trying to do this because you have a secondary MX
that’s not under your control : I recommend you consider doing
away with the secondary MX. See "When There’s No Point To A
Secondary MX," above, for a detailed discussion.

Q14. When I issue "postmap header_checks" command I get things like
``postmap : warning : header_checks, line 2 : record is in "key :
value" format ; is this an alias file ?" What is wrong ?

A14 : You don’t "postmap" header or body checks files, nor any other
"regexp :" or "pcre :" type file. However you must "postfix
reload", after changing these, if you want your changes to take
effect immediately.

Q15. As regards your "Stopping Forged Freemail" section, and FAQ
Q1/A1 : Other than complexity of the configuration, what prevents
you from setting a from_freemail_host_yahoo,
from_freemail_host_excite, from_freemail_host_netscape, et al and
then having your /etc/postfix/freemail_access reference the
appropriate matching list for each one.

A15 : Nothing at all. Feel free :)

See also : FAQ Q1/A1

Q16. Why, for the Postfix 2.x version of your smtpd_*_restrictions,
have you moved reject_unauth_pipelining to the new
smtpd_data_restrictions stage ?

A16. Because it’s more effective there. For more information, search
the postfix—users mailing list archives for the thread subject
"Where Goes reject_unauth_pipelining ?," during the month of
November, 2003.

Q17. Something got through body_checks that shouldn’t have. But when
I forwarded it, *then* it got rejected. What’s up ?

A17. Most likely the original was in base-64 or some other encoding
scheme that your email client application decoded for you.
Postfix’ body_checks code doesn’t decode these.

Q18. What have you got against listing 127.0.0.1, or some equally
non-deliverable-to IP address, as ones lowest-priority MX ? It
reduces spam !

A18. Many things : 1) It breaks DNS MX. 2) It’s a short-term "cure,"
at best. 3) It’s of questionable efficacy. In any event : If
you’re going to purposefully break your DNS configuration, don’t
complain when people don’t accept your email *because* you have a
broken DNS configuration.

Q19. How can I show my appreciation for your contributions ?

A19. A simple "thanks" would be sufficient :). Really. But if you
wish to do something more concrete, and can afford to do so,
please consider making a tax-deductible donation to the SpamCon
Foundation Legal Fund at :

http://www.spamcon.org/legalfund/

Thanks !

Other Resources

Some other stuff I’ve tripped across that’s related to what’s on this
page. In no particular order. Mention here does not necessarily
constitute endorsement.

Advosys White Papers : Filtering malware and spam with Postfix
http://www.advosys.ca/papers/printable/postfix-filtering.html

Security Sage Support Guides
POSTFIX UNSOLICITED COMMERCIAL EMAIL / ANTI-SPAM GUIDE - MAIN.CF
http://www.securitysage.com/guides/postfix_uce_main.html

Ralf Hildebrandt : Mailhub Configuration Mailhub
http://www.stahl.bau.tu-bs.de/~hildeb/postfix/postfix_mailhub.shtml

River of Stars : Spam Block List Implementation
http://www.river.com/ops/nospam/mailconf.html

Fairly-Secure Anti-SPAM Gateway Using OpenBSD, Postfix, Amavisd-new,
SpamAssassin, Razor and DCC
http://lawmonkey.org/anti-spam.html

My Understanding Of How UCE Actually Works
http://www.mengwong.com/misc/postfix-uce-guide.txt

Postfix : Anti-Spam Utilities
http://www.hispalinux.es/~data/postfix/

And, of course...

Postfix Documentation, Howtos and FAQs
http://www.postfix.org/docs.html

Change History (in reverse-chronological [latest first] order)

Mon Mar 19 10:33:09 EDT 2007

Added back-scatter solution. Thanks and a tip o’ the hat to Mikhail.

Wed Mar 7 10:42:45 EST 2007

Added note about SPEWS data being stale.

Thu Mar 1 09:49:40 EST 2007

Added note about dangers of using check_recipient_mx_access when
destination may have multiple unresolvable MX’.

Wed Jan 31 13:31:04 EST 2007

Added note about zen.spamhaus.org

Sun Jan 28 18:00:52 EST 2007

Removed SORBS from my list of used/recommended DNSbls.

Sat Jan 6 23:23:46 EST 2007

Removed ordb.org from examples. Doh !

Mon Dec 18 11:37:53 EST 2006

Updated for end of ORDB.org

Tue Aug 8 09:06:07 EDT 2006

Updated for end of opm.blitzed.org

Sun Jun 12 08:25:16 EDT 2005

Updated "When Anti-Spam Measures Collide : Sender Address
Verifications Rejected" to include Verizon’s "svNNNpub..."
hosts. Added note about VZ apparently caching SAV test
results.

Wed Mar 16 06:53:58 EST 2005

Added note to "Stopping Forged Freemail" about users that send via
their ISPs’ mailservers using a freemail sender address. Expanded
slightly on FAQ item Q1/A1.

Tue Dec 14 13:03:31 EST 2004

Added "When Anti-Spam Measures Collide : Sender Address
Verifications Rejected" section.

Wed Jul 14 07:38:41 EDT 2004

Added note about "permit_sasl_authenticated" and Apple Mail to
FAQ Q3/A3. (Thanks to Steve Sisak)

Mon Mar 15 14:57:25 EST 2004

Added note about how relays.monkeys.com was now returning positive
responses for all queries.

Tue Feb 10 15:41:29 EST 2004

Note about relays.monkeys.com nameservers being decommissioned.

Sat Jan 3 10:42:18 EST 2004

Added dul.dnsbl.sorbs.net to my "recommended" list of DNSbls.

Sun Dec 28 12:15:09 EST 2003

Minor updates to "A Note About DNS BlackLists (DNSbl’s and
RHSbl’s)" section.

Sat Dec 20 00:25:54 EST 2003

Expanded on the "127.0.0.1 MX" discussion. Added FAQ Q18/A18.

Fri Dec 19 12:08:47 EST 2003

Added a note check_blurfl_mx_access discussion about how some
"anti-spammers" have listed 127.0.0.1 as one of their domain MX’.

Wed Dec 3 18:31:05 EST 2003

Started this section. Added short "Understanding The Order In
Which UCE Checks Are Applied" section. Renamed "Understanding The
Order In Which SMTPD Restrictions Are Applied."

Fri Dec 5 17:03:27 EST 2003

Added FAQ about why things that apparently shouldn’t sometimes get
through body_checks.