Jim Seymour’s suggestions/examples for Postfix anti-UCE configuration
- General Notes On "hostname,"
- Understanding The Order (...)
- Understanding Header and (...)
- Understanding DNSbl’s and (...)
- Stopping Forged Freemail
- When Anti-Spam Measures (...)
- Back-Scatter To Non-Sending
- Compensating For Verisign’s
- Some Common Anti-UCE-Related
- A Note About DNS BlackLists
- When There’s No Point To (...)
- Frequently Asked Questions
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) :
- (1st 6 statements) : ensure the HELO/EHLO and smtp envelope stuff are "sane." Prohibit verification checks of recipient addresses.
- Dis-allow command "pipelining." (Generally only spamware tries to pipeline—particularly during dictionary attacks.).
- Permit anything that passes the above restrictions and is from my network. (Destination doesn’t matter.).
- Out-right reject anything from outside that’s not destined for my network.
- Check certain recipient addresses before any local blacklisting or DNSbl checks.
- Check the local black-lists, white-lists and combined black-/whitelists (HELO/EHLO, sender [envelope from] and client [sending server] checks).
- 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 :
# IMPORTANT NOTES
#
# "dbm" or "hash" depends on your system. The above is for my Sun
# SPARC Solaris boxen. Linux usually uses "hash".
#
# You need to have PCRE support built into Postfix at compile time to
# use the "pcre:" types.
#
# If it's necessary that the mail server accept SMTP connections
# from internal machines that don't HELO properly, you'll have to
# move at least reject_non_fqdn_hostname, and possibly also
# reject_invalid_hostname, to *after* permit_mynetworks. There's no
# harm in doing this, should you find it necessary. See FAQ items
# 2-4 for more on this topic.
#
# The trailing "permits" aren't necessary, strictly speaking, because
# there's an earlier "permit_mynetworks." I just put them there
# because it makes clear that whatever passes the earlier "check" and
# "reject" tests will be permitted. I like "self-documenting ``code''".
#
# You'll observe that all of my anti-UCE checks are under
# smtpd_recipient_restrictions, instead of having a separate
# smtpd_client_restrictions, etc. This is because, unless you have set
# smtpd_delay_reject = no (default is "yes"), no rejecting takes place
# until after RCPT TO anyway. It's easier, cleaner and more
# predictable when all of the anti-UCE stuff is under recipient
# restrictions. (Except for reject_unauth_pipelining under Postfix
# 2.x. See FAQ Q16/A16. There are also possible performance issues
# doing things this way. See "Understanding The Order In Which
# Restrictions Are Applied" for more info.)
#
# Note that SpamHaus' xbl zone is a super-set of the CBL, and, in turn,
# SpamHaus' zen zone is all three SpamHaus zones. So, for efficiency's
# sake, one could replace the CBL and two SpamHaus zones with a
# single check of zen.spamhaus.org./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 :
parent_domain_matches_subdomains = smtpd_access_mapsin main.cf. Otherwise, you have to do things like :
example.com REJECT
.example.com REJECTThe "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 "
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. :
Received: from host.example.com (host.example.com [192.168.1.2])
by mail.example.com (Postfix) with ESMTP id 157B64304
for <phred@example.com>; Sun, 31 Aug 2003 09:20:55 -0400 (EDT)and (if it’s a newer, "MIME-aware" version of Postfix) :
Content-Disposition: attachment;
filename=textfile.txt
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
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
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
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)
cbl.abuseat.org
list.dsbl.org
sbl.spamhaus.org
pbl.spamhaus.orgCurrently 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) :
lan/wan
Internet === primary MX =============+
gateway | lan
+===== internal mail
| server
Internet ==== secondary MX ========+
gateway lan/wan
Or perhaps:
Internet ==== primary MX and mail server ---- lan
^
|
|
Internet ==== secondary MX ==========+
wanFrequently 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/head... http://jimsun.linxnet.com/misc/body...
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/printa...
Security Sage Support Guides POSTFIX UNSOLICITED COMMERCIAL EMAIL / ANTI-SPAM GUIDE - MAIN.CF http://www.securitysage.com/guides/...
Ralf Hildebrandt : Mailhub Configuration Mailhub http://www.stahl.bau.tu-bs.de/ hild...
River of Stars : Spam Block List Implementation http://www.river.com/ops/nospam/mai...
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/postfi...
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.
Annonces générales :
Site réalisé avec SPIP 2.1.1 + AHUNTSIC
