If you are responsible for maintaining an internet-connected mail-server, then you have, no doubt, come to hate spam and the waste of resources which comes with it. When I first decided to lock down my own mail-server, I found many resources that helped in dealing with these unwanted messages. Each of them contained a trick or two, however very few of them were presented in the context of running a real server, and none of them demonstrated an entire filtering framework. In the end I created my own set of rules from the bits and pieces I found, and months of experimentation and fine-tuning resulted in the system detailed in this article.
This article will show you how to configure a Postfix mail-server in order to reject the wide majority of unwanted incoming “junk email”, whether they contain unsolicited commercial email (UCE), viruses, or worms. Although my examples are specific to Postfix, the concepts are generic and can be applied to any system that can be configured at this level of detail.
For a real world example, I’ll use my server’s configuration details:
Hostname | Kanga.honeypot.net |
Public address | 208.162.254.122 |
Postfix configuration path | /usr/local/etc/postfix |
Goals
This configuration was written with two primary rules in mind:
- Safety is important above all else. That is, I would much rather incorrectly allow an unwanted message through my system than reject a legitimate message.
- The system had to scale well. A perfect system that uses all of my server’s processing power at moderate workloads is not useful.
It’s easy to experiment with Postfix, and it can be customized to your level of comfort
To these ends, several checks—that may have reduced the number of “false negatives” (messages that should have been rejected but were not) at the cost of increasing the number of “false positives” (legitimate messages that were incorrectly rejected)—were avoided. The more resource-intensive tests were moved toward the end of the configuration. This way, the quick checks at the beginning eliminated the majority of UCE so that the longer tests had a relatively small amount of traffic to examine.
HELO restrictions
When a client system connects to a mail-server, it’s required to identity itself using the SMTP HELO
command. Many viruses and spammers skip this step altogether, either by sending impossibly invalid information, or lying and saying that they are one of your own trusted systems—in the hopes that they will be granted undeserved access. The first step in the filtering pipeline, then, is to reject connections from clients that are severely mis-configured or that are deliberately attempting to circumvent your security. Given their simplicity, these tests are far more effective than might be imagined, and they were implemented in my main.cf
file with this settings block:
1 smtpd_delay_reject = yes 2 smtpd_helo_required = yes 3 smtpd_helo_restrictions = 4 permit_mynetworks, 5 check_helo_access hash:/usr/local/etc/postfix/helo_access, 6 reject_non_fqdn_hostname, 7 reject_invalid_hostname, 8 permit
Given their simplicity, these tests are far more effective than might be imagined
Line 1 is a fix for certain broken (but popular) clients, and is required in able to use HELO
filtering at all. The second line rejects mail from any system that fails to identify itself. Line 4 tells Postfix to accept connections from any machines on my local network. The next line references an external hash table that contains a set of black- and whitelisted entries; mine looks like this:
woozle.honeypot.net OK honeypot.net REJECT You are not me. Shoo! 208.162.254.122 REJECT You are not me. Shoo!
The first line in the table explicitly allows connections from my laptop so that I can send mail when connected through an external network. At this point Postfix has already been told to accept connections from all of my local machines and my short list of remote machines, so any other computer in the world that identifies itself as one of my systems is lying. Since I’m not particularly interested in mail from deceptive systems, those connections were flatly rejected.
Lines 6 through 8 complete this stage by rejecting connections from hosts that identify themselves in blatantly incorrect ways, such as “MAILSERVER” and “HOST@192.168!aol.com”.
Some administrators also use the reject_unknown_hostname
option to ignore servers whose hostnames can’t be resolved, but in my experience this causes too many false positives from legitimate systems with transient DNS problems or other harmless issues.
You can test the effect of these rules, without activating them on a live system, by using the warn_if_reject
option to cause Postfix to send debugging information to your maillog without actually processing them. For example, line 6 could be replaced with:
warn_if_reject, reject_non_fqdn_hostname,
This way the results can be observed without the risk of inadvertently getting false positives.
reject_unauth_pipelining
15 smtpd_recipient_restrictions =
16 reject_unauth_pipelining,
From: http://www.postfix.org/postconf.5.html
Note: reject_unauth_pipelining is not useful outside smtpd_data_restrictions when 1) the client uses ESMTP (EHLO instead of HELO) and 2) with "smtpd_delay_reject = yes" (the default). The use of reject_unauth_pipelining in the other restriction contexts is therefore not recommended.
reject_non_fqdn_hostname
In combination with Outlook the "reject_non_fqdn_hostname" in the helo restrictions will prevent your mail from the local network to be sent, even with "permit_mynetworks" enabled.
I have not found a workaround for this problem, but to disable the fqdn requirement.
Re: reject_non_fqdn_hostname
I had the same problem with Outlook -- I believe it uses a substring of the machine name for the HELO command. Since we don't have too many Outlook clients, it was pretty easy to add the individual machines to my helo_access file. I grabbed the HELO identification from the Outlook error message that popped up when a user tried to send a message (this is also available in the log file). Then I put an entry in helo_access as follows:
machine_name OK
Solved
I got the solution to my problem. Somebody pointed out that my main.cf was not correctly configured. permit_mynetworks was not working because I set mynetworks = 10.0.0.0/32 instead of 10.0.0.0/8.
Have a look here this thread.
helo_access for Outlook clients
Hi have tried the helo_access file as well. But, I simply have not been able to get Outlook to work.
Is there a specific place one puts the helo_access lookup within main.cf?
Thanks in advance.
Rama
Outlook the "reject_non_fqdn_hostname"
FYI, it works if you use "SMTP authentication" which is probably a good idea anyway.
workaround for outlook
a better workaround: dont use outlook (=
relays.ordb.org
Should remove line 25:
reject_rbl_client relays.ordb.org,
ordb.org no longer provides any services.
You end up with a bunch of messages similar to this in your mail logs:
warning: x.x.x.x.relays.ordb.org: RBL lookup error: Host or domain name not found. Name service error for name=x.x.x.x.relays.ordb.org type=A: Host not found, try again
relays.ordb.org
It was announced a little while ago that ordb.org was no longer going
to be maintained and it is now no longer available. That is why you
are seeing the errors.
It you are using ordb.org as an RBL, remove it.
RBLs in general
Are the other two (RBLs) any decent at all?
from my experience (most recently with www.tqmcube.com) is that RBLs blacklist a whole lot of legitmate e-mail servers and thus cause WAY too many false positives.
so far the HELO,valid sender domain and greylisting is working wonders. I have dropped spam making it through the e-mail server by 80-90%. my bayesian filter (I use spamprobe) takes care of the rest, and since I put those additions into my e-mail server *knocks on wood* I haven't gotten any spam into my inbox. yeah!
and my end users of mailing list run are ecstatic as well.
but RBLs, the mission statements sound good, but in practice, I don't see them actually living up to them.
Greylisting
The greylist configuration in smtpd_recipient_restrictions is missing
No, it's not. The following
No, it's not. The following line runs postgray.
check_policy_service inet:127.0.0.1:10023
I have a great alternative
Some of this stuff is really interesting, but a bit beyond me at some points. I do have a great service that takes care of alot of this stuff. It's a company out of LA and they did wonders for my Mailing.
Cheers,
Justin
Really?
So, what is it?
Rubi
Postfix Client Problem
Dear
I'm a system engineer at WirelessIP. My current mailserver is using Postfix. Recently i face with my client complaint about sending slow with large attachment from client side to my server. So Do u have any idea to solve this ? or to make it faster than usual.
Thanks and Good luck
Best Regards,
Chantha
Email:chantha@wirelessip.com.kh
Post new comment