Gentoo Wiki


Please format this article according to the guidelines and Wikification suggestions, then remove this notice {{Wikify}} from the article

Complete Virtual Mail Server

Getting Started

Basic Mail Setup

Enhanced Mail Services

Anti-Spam Configuration

Anti-Virus Configuration

Log Analyzer

Wrapping it Up


Refining the Postfix Setup

In the sections above, we set the groundwork to do some further refining of our installation. In the next few sections, we will go through the necessary steps to start utilizing these items and further tighten the security of our installation.

Mail Quotas

When we first installed postfix and the database, we made sure we put in provisions for mailbox quotas. Now is the time that we are going to use these. The setup is very straight forward. First we adjust the postfix configuration to start enforcing quotas.

Code: /etc/postfix/
# nano –w /etc/postfix/

#Support for Postfix VDA quotas
virtual_create_maildirsize = yes
virtual_mailbox_extended = yes
virtual_mailbox_limit_maps = pgsql:/etc/postfix/pgsql/
virtual_mailbox_limit_override = yes
virtual_maildir_limit_message = Sorry, the recipients mailbox is currently full. Please try again later.
virtual_overquota_bounce = yes

Now we just need the access file so that the quotas can be read out of our database. Note that VDA requires the quota size in bytes, so I have specified the select_field as 1024*1024*quota. This will allow us to specific the quota size in the database as Megabytes.

Code: /etc/postfix/pgsql/
# nano -w /etc/postfix/pgsql/

# Postfix virtual_mailbox_limit_maps
# Lookup table that defines the mailbox quota limits for specific
# addresses.

user            = postfix
password        = $password
dbname          = postfix
hosts           = dbServerhostname
table           = mailbox
select_field    = 1024*1024*quota
where_field     = email
additional_conditions = and active = 'true'

Like all other steps along the way, make sure you test the quotas before you move on. I set the quota quite low (1 MB) and then sent a series of small messages (approx 200K each) and verified that once the mailbox was full, any further messages were rejected. You do whatever testing you need to do to feel comfortable that it works.

Setting the quota to 0, 'disables' it (and not -1 as someone might think).

You might also want to let the user know that his mailbox is getting to full. This can be accomplished by <some one else please fill this in.> (I think SqWebMail from courier might do it. Then again, I have no clue what I'm talking about, wether it is a client thing, or a server thing)

HELO Restrictions

Hi. Let’s look at a few options that will help us restrict the flow of likely SPAM through our system. This is not meant to take the place of proper spam filtering software, it is only an initial block that will weed out the basic stuff.

The smtpd_helo_restrictions parameter makes decisions based on the HELO (or EHLO) greeting sent from the mail client. Spammers will often use fake hostnames or put garbage in the HELO greeting. Rejecting mail from such clients will cut down some of the incoming spam.

Options include:

	reject_invalid_hostname	  REJECT if HELO greeting is not a DN or an IP
	reject_non_fqdn_hostname  REJECT if HELO greeting is not a FQDN or an IP
	reject_unknown_hostname	  REJECT if HELO host has no A or MX in DNS
	permit_naked_ip_address	  PERMIT if HELO greeting is an IP

To get a better understanding, the following table will show you which of the above reject_*_hostname restrictions will cause various HELO greetings to fail. In the table an X means the message is rejected and a ? means rejection will depend on whether or not a DNS record exists for that domain.

				bogus          example
reject_invalid_hostname	          X	
reject_non_fqdn_hostname	  X               X
reject_unknown_hostname	          X               X                   ?                     X

Notice that reject_unknown_hostname not only rejects fake FQDNs, but it also rejects IP addresses. If you want to allow your system to accept mail from IP’s, then you can list permit_naked_ip_address before reject_invalid_hostname and IP’s will pass. I decided to keep my configuration tight and will not allow just IP addresses.

Code: /etc/postfix/
# nano –w /etc/postfix/

smtpd_helo_restrictions =  reject_invalid_hostname,

If you are uncertain about whether or not the above settings will work, postfix gives a way to test what would be rejected, without actually rejecting. If any reject_* restriction is proceeded by a warn_if_reject, then an incoming message that triggers that condition will not be rejected, but a log entry will be created. The above reject_invalid_hostname could be tested by changing the above to:

Code: /etc/postfix/
# nano –w /etc/postfix/

smtpd_helo_restrictions =  reject_invalid_hostname,

Then you will want to watch the log for reject_warning messages.

Warning: Hopefully this was big enough for you to notice. The above settings can have some unexpected consequences. The average home user who may try to connect to your server from their home mail client will not likely have their hostname setup in a way that will pass the above tests. As an example, my windows system (no flames please) is setup as frasier and when it connect to port 25 to send mail, it uses EHLO frasier to identify itself. Of course this does not pass the above tests and so the mail is rejected. For my use, I have turned these off as I have a number of home users connecting. This doesn't influence the working of webmail however (atleast squirrelmail).

// how about adding permit_mynetworks to the list? worked for me - paul 31-oct-06

You also may consider moving these restrictions to smtpd_recipient_restrictions and delaying them until after sasl_authentication in the same restriction block. Although I only use reject_invalid_hostname, because many ISPs and clients continue to misconfigure themselves :-( docunext - my page on postfix spam defense - 2006-12-14.

Another couple of simple changes you can make ensure that the client issues a HELO greeting before being allowed to send any mail through and is immediately rejected if there are any problems with the HELO greeting as defined above in the restrictions. This will eliminate the spam-ware that doesn’t bother to issue the HELO greeting to increase its throughput and ensure that invalid attempts to connect are bounced as quickly as possible.

Code: /etc/postfix/
# nano –w /etc/postfix/

smtpd_helo_required = yes
smtpd_delay_reject = no

Next, you should disable the VRFY command. This is a command used to test whether a local address exists or not. This command is used almost exclusively by the people who maintain bulk mailing lists to search for valid email addresses.

Code: /etc/postfix/
# nano –w /etc/postfix/

disable_vrfy_command = yes

When connecting to the smtpd port, Postfix displays your hostname and identifies itself as a Postfix server. We will change the banner displayed when you first connect to include our hostname and the phrase “NO UCE”. There is a proposed US federal law that unsolicited commercial email cannot be sent through a server that includes the string NO UCE in the 220 greeting line. Not that I believe people will actually follow this, I just wanted to get rid of Postfix in the header as it is nobody else’s business.

Code: /etc/postfix/
# nano –w /etc/postfix/

smtpd_banner = $myhostname NO UCE ESMTP

Final Testing

You now have a fully functioning, ready to use mail server that is pretty secure as far as servers go. It still doesn’t take care of things like spam, etc. but that will be later in this guide. A good number of you who are using this to setup a small server that will have a limited number of users, etc. will be satisfied with this. For those of you who want more, don’t worry, this guide goes on for quite a few pages (like you haven’t had enough of me yet).

Independent of whether or not you plan to carry on, this would be a good time to do a full round of testing. Make sure you do all the basics, setup a mail account on a client, send/receive with another account (don’t forget you require secure connections and authentication). You will also want to go back and re-visit the websites we mentioned above for testing your server, and

Postfix Performance

Postfix shouldn’t need any special tweaking to handle the email of most small to mid-sized servers (approximately 1000 users) on run of the mill desktop hardware. If you think you are going to need to go beyond this, then the following will be of interest.

Process Availability

Postfix consists of a number of applications that work together to process the mail. Each application does it’s job as appropriate and then hands the mail off to the next one. By default, Postfix limits the number of concurrent processes of any one application to 50.

The smtp or smtpd daemons are likely to be the first processes to bump up against this limit as mail traffic increases. If the number of live smtp or smtpd daemons shown by the “ps aux” command reaches a significant fraction of the default limit (e.g. 45 of 50), you will want to increase that limit via the default_process_limit direction in /etc/postfix/

Code: /etc/postfix/
# nano –w /etc/postfix/

Default_process_limit = 100

Now before you just run off willy-nilly increasing processes, be sure your machine has sufficient memory to take on the added load. Examine the output of the “ps aux” command to determine the percentage of memory used by each process. Based on this, be sure you have enough memory to accommodate the number you have specified.

CPU Speed

Assuming that you have enough processes running, but you are still not getting great throughput, you next need to consider the CPU. Use “top” to determine the average CPU utilization. If it is too high (over 70%) you will want to consider a new, faster processor.

DNS Lookup

Before hitting process or CPU limits, you are likely to find you are losing a lot of time to DNS lookups. Mail delivery requires a minimum of one IP address lookup and so throughput is impacted by the communication latency with your DNS server. You may want to consider setting up your own caching DNS server local to your mail server. These are very straight forward to setup and can have a significant impact on your lookup time and overall throughput.

Disk Storage

Postfix maintains a number of queue directories in /var/spool/postfix. The Postfix applications communicate by passing mail around through these queues. Throughput can be significantly increased by speeding access to these queues. Placing /var/spool/postfix on its own hard drive can have a significant impact on overall throughput. Be sure that the drive is mounted with the noatime option to remove the overhead of storing the time of every file. Postfix does not use access timestamps.

Multiple Mail Servers

A final option may to be scale up your system by running multiple mail servers in parallel. Since you do not need to maintain state information beyond a single smtp session, you can effectively use DNS round-robining. Simply assign multiple A entries to the FQDN of you mail hub in the DNS servers. When an SMTP client wants to send a mail, it will query the DNS to obtain the IP for the mail server. Each time, the DNS server will return a different IP thus approximating a balance load across your servers.

However, maybe better solution to use MX-record priority records in your DNS server, example for ISC/BIND:

@       IN     MX    10      mail1.domain.tld
@       IN     MX    20      mail2.domain.tld

In this case mail2.domain.tld has LOW priority, and mail1.domain.tld - HIGH.

Retrieved from ""

Last modified: Sun, 18 May 2008 06:53:00 +0000 Hits: 12,472