Postfix SMTP Configuration

jinying8869

Original website:http://www.metaconsultancy.com/whitepapers/smtp.htm
No any modifications!
Postfix SMTP Configuration
© 2002 by metaconsultancy
　　A typical organization runs an email system to accept mail addressed to local users and to send local users' mail to each other and to the outside world.
　　I like to use the Postfix email system, because it is relatively easy to configure and has a good record for security. More information about Postfix is available from the  Postfix website.
　　This whitepaper discusses how to set up the Postfix email system to handle your organization's email needs. Special attention is focused running Postfix on Debian Linux, getting Postfix to co-operate with a Cyrus IMAP server, and configuring authentication-based relay authorization.

Table Of Contents

• SMTP Tutorial
  
• Installation
  
• Basic Configuration
  
• Delivery to Mailstore
  
• Alias Control
  
• Relay Control
  
• Spam Control
  
• Performance Tuning
  

SMTP Tutorial　　Mail transport agents (MTAs) like Postfix speak to each other using SMTP (Simple Mail Transport Protocol). To understand how MTAs work, and sometimes don't work, it will help to have a very basic understanding of this protocol. If you telnet to the smtp port (port 25) of a mail server, you can speak with an MTA directly in its native language. Here is an example of how to send bob@example.com an email from alice@somewhere.net.  

$ telnet smtp.example.com smtp
Trying 192.0.34.72...
Connected to smtp.example.com.
Escape character is '^]'.
220 smtp.example.com ESMTP Postfix (Debian/GNU)
HELO smtp.somewhere.net
250 smtp.example.com
MAIL From: alice@somewhere.net
250 Ok
RCPT To: bob@example.com
250 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Hello, Bob!
Love, Alice.
.
250 Ok: queued as F169C23068
QUIT
221 Bye
Connection closed by foreign host.

The client begins by identifying itself (HELO) and telling the server it has an email (MAIL) to deliver to one or more recipients (RCPT). It then conveys the contents of the email (DATA) and leaves (QUIT). The server responds to each directive with a numerical code and a message that indicates the success or failure of the requested operation.　　Each MTA that handles a mail adds headers containing information about the SMTP session. For example, when it is stored at its destination, the full header and body of the mail we sent above looks like this.  

Received: from smtp.somewhere.net (smtp.badguy.net [])
          by smtp.example.com (Postfix) with SMTP id F169C23068
          for <bob@example.com>; Tue,  6 Aug 2002 12:02:15 -0700 (PDT)
Message-Id <20020806190215.F169C23068@smtp.example.com>
Date: Tue,  6 Aug 2002 12:02:15 -0700 (PDT)
From: alice@somewhere.net
To: undisclosed-recipients:;
Hello, Bob!
Love, Alice.

Notice that the &quot;Received&quot; header reports not only the name the client reported in its HELO greeting (here smtp.somewhere.net), but also the name resolved via reverse DNS lookup of the client IP address (here smtp.badguy.net). Gasp! A forged love-letter!   
Installation　　The postfix source is available for download from the postfix website, but Debian provides well-maintained packages which will satisfy our needs.

# aptitude install postfix
# aptitude install postfix-ldap postfix-tls
While not necessary for postfix to function, the postfix-ldap and postfix-tls packages provide additional functionality that we will employ in this tutorial, so we suggest you install them, too.   
Basic Configuration　　Postfix configuration files live in the directory /etc/postfix/. The main configuration file for postfix is /etc/postfix/main.cf, which is organized into simple key = value directives, one per line. Since Postifx is very good at guessing reasonable defaults, it is actually possible to have a working mail server with a completely empty main.cf, but there are probably at least a couple of values you will want to set explicitly.

main.cf
myhostname = smtp.example.com
mydomain = example.com

　　The first line sets $myhostname to a FQDN (fully qualified domain name) for your mail server. This is the name that postfix will report to fellow SMTP daemons when exchanging mail. Other SMTP daemons may take umbrage if your SMTP daemon reports a false or fake FQDN, so make sure $myhostname really does resolve to your server's IP address.  By default, $myhostname is determined via the hostname() API, and $mydomain is set to the domain part of $myhostname.

Mail Hub　　If you want to receive incoming mail, you will need to tell Postfix the domain names (the part of an email address after the @) it should interpret as local users.

main.cf
mydestination = $mydomain $myhostname localhost.$mydomain

　　The $mydestination parameter lists the domains for which the SMTP server will treat mail as destined for a local user. In our example, we have told postfix that all mail to addresses of the form username@example.com and username@smtp.example.com is to be accepted for local delivery.
　　When postfix recieves a mail to an address not contained in the mydestination parameter, it assumes that it is being asked to relay the mail to the appropriate destination. If postfix's configuration allows it to relay the mail, it will attempt to contact the computer named in the mail's address.

Satelite Client　　Most of the computers within your organization should not accept mail for local delivery, but instead pass everything on to a mail hub. It is easy to configure Postfix to do this.  

main.cf
mydestination =
relayhost = smtp.example.com

Leaving $mydestination blank instructs Postfix that no mail is to be delivered locally, and setting $relayhost to the address of your mail hub tells Postfix where it should route any mail that falls into its hands.   
Delivery to Mailstore　　Next, you need to tell Postfix where to put the mail it accepts for local delivery. By default, it will put mail for username into the file /var/spool/mail/username. This is the traditional storage location for mail on Unix systems, and most console-based Unix email clients get their mail from there.
　　The trouble with this approach is, pretty much only console-based Unix email clients get their mail from there. Very few users today, even Unix users, use such clients to read their email. Most users like to access their mail across a network using GUI-based clients which speak the IMAP or POP protocols. To work with such clients, you need to configure Postfix to hand mail off to an IMAP or POP server.
　　We use Cyrus-IMAP for local mail storage. It is well-maintained and open-source, supports POP and well as IMAP access, and has several useful additional features such as native SSL support and support for sieve filtering.
　　Cyrus, as well as a number of other modern mail storage systems, use LMTP (local mail transport protocol) to accept incoming mail. Fortunately, Postfix speaks LTMP, too.
　　If Cyrus is on the same computer as Postfix, you can use a filesystem socket for local delivery. For example,  

main.cf
mailbox_transport = lmtp:unix:/var/run/cyrus/socket/lmtp

Be sure that postfix has the necessary permissions to access the socket. If you are using the Debian Cyrus packages, this can be accomplished by making postfix a member of the mail group.
# adduser postfix mail
　　If Cyrus is on a different computer, use an LMTP network socket.  

main.cf
mailbox_transport = lmtp:inet:imap.example.com

In either case, Cyrus must be configured to accept mail via the socket; consult our Cyrus whitepaper for instructions.   
Alias Control　　Aliases are alternative names for local users. If Postfix is sent a mail for an-alias@example.com, it will check its alias tables to see whether an-alias maps to one or more existing local users before it returns a bounce notice.
　　Certain aliases are required by tradition and RFC to exist for any organization. These are:


alias
role
sysadmin
the system administrator
postmaster
the email administrator
webmaster
the website administrator
abuse
address to report hackers, spammers　　We will show you two ways to implement alias tables: one which defines aliases in the local file /etc/aliases, and other which stores them in an LDAP database. To let Postfix know about these two alias tables, we use the following directive.

mail.cf
alias_maps = hash:/etc/aliases, ldap:ldapdata

Flat File　　Our /etc/aliases file contains the basic, required aliases.

aliases
root: user1, user2
sysadmin: root
postmaster: root
abuse: root
webmaster: root
www: root

We have aliased them all to root, and aliased root to a couple of our users (chaining aliases and multiple targets are both allowed). In a large organization, these aliases might map to different people.　　Postfix actually uses a hash of the aliases file, instead of consulting it directly, in order to speed lookup. To generate the hash, enter

# postalias /etc/aliases
whereupon the /etc/aliases.db hash file will be generated. This step must be repeated each time an aliases file is updated.   
LDAP Database
main.cf
ldapdata_server_host = ldap.example.org
ldapdata_search_base = dc=example,dc=org
ldapdata_query_filter = (mailLocalAddress=%s)
ldapdata_result_attribute = mailRoutingAddress


Relay Control　　When handed a mail, Postfix compares the domain name in the RCPT &quot;To:&quot; data (the part after the @) with $mydestination to determine whether the mail should be delivered to a local user or relayed to a remote host.  
　　In the early days of email, SMTP servers would happily relay any mail handed to them; it was the neighborly thing to do. An SMTP server willing to relay any mail handed to it is called an &quot;open relay&quot;.  These days, the internet is a less neighborly place, full of bandwidth thieves and spammers who are only too happy to use your open relay for their own nefarious purposes. Running an open relay is not only unneighborly; it is likely to get your organization blacklisted as a source of spam.  This section covers how to configure Postfix to ensure that only authorized mail is relayed through your server.
　　Relaying is controlled by the smtpd_recipient_restrictions directive, which accepts as its value a stack of restrictions which are evaluated, in order, until one returns either REJECT or PERMIT. (If you have experience with PAM stacks or with chains of firewall rules, this concept will be familiar.)  

IP-Based Relay Control　　The simplest form of relay control is accept mail for relay only from IP addresses owned by your organization, or otherwise known to be trustworthy.  

mynetworks = 127.0.0.0/8 192.0.34.0/8
relay_domains =
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, permit

The permit_mynetworks restriction returns PERMIT if the IP address of the connecting client matches an IP address in $mynetworks. The reject_unauth_destination returns REJECT if the destination is not the local machine or a member of $relay_domains.   
Auth-Based Relay Control　　IP-based relay control is usually effective (the exception being a rogue user of a trusted machine), but often unnecessarily restrictive. Users with home internet access will likely want to use your smtp server to send email from home, which requires you to add their home IP address (or even large IP address blocks, if their provider uses DHCP) to $mynetworks. Users who travel will likely want to send mail from wherever they go, which is completely impossible using an IP-based scheme.
　　An effective alternative to IP-based relay control is authentication-based relay control. Before relaying a mail, Postfix requests a username and password, then sends the mail only if the username and password are valid. Authenticated users are allowed to send mail from any computer anywhere. Most modern mail clients support SMTP authentication.
　　Setting up authentication-based relay control is significantly more complex than setting up IP-based relay control, not least because you will want to ensure that communications are encrypted before you allow a password to be transmitted. Still, until you set up authentication-based relay, you will be subject to ceaseless pressure from users to make your relay ever more open, until some day you bite the bullet and decide to read this section.
　　The first step is to insert permit_sasl_authenticated into the smtpd_recipient_restrictions list.  

smtpd_recipient_restrictions = permit_mynetworks,
                               permit_sasl_authenticated,
                               reject_unauth_destination, permit

This returns a PERMIT for authenticated users. Now we need to configure Postix to support authentication.　　Before configuring Postfix to support authentication, we need to configure it to support public key encryption To do so, create a certificate and key file for your mail server as described in our Digital Certificates whitepaper. Then tell Postfix where to find these files.  

/etc/postfix/main.cf
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/postfix/smtp.example.crt
smtpd_tls_key_file = /etc/postfix/smtp.example.key

　　Now we can enable authentication, with the requirement that the TLS encryption layer be active before authentication occurs.  

/etc/postfix/main.cf
smtpd_sasl_auth_enable = yes
smtpd_tls_auth_only = yes

This setup ensures that the passwords used for authentication cannot be read by a network sniffer.　　Postfix now knows that it is should support the SMTP AUTH command, but it does not yet know how to check the usernames and passwords clients give it for validity. To get authentication working, you need to specify a method for the SASL library to check usernames and passwords. The method most likely to be familiar to Linux users is PAM, which works just fine.  For SASL version one, it was possible to specify PAM to Postfix directly as the SASL authentication mechanism. The current version of SASL does not support this; instead, we must tell Postfix to use saslauthd, the SASL authentication daemon, to check passwords, and then tell saslauthd to use PAM in turn.
　　To obtain saslauthd, install the sasl2-bin package

# aptitude install sasl2-bin

The package's install script will automatically set up scripts in /etc/rc.d/init/ to start saslauthd when the machine is booted.　　Next, tell Postfix to use saslauthd for password checking.  

/etc/postfix/sasl/smtpd.conf
pwcheck_method: saslauthd
mech_list: plain login

Programs communicate with saslauthd via a filesystem socket in the /var/run/saslatuhd/ directory. In order for Postfix to access with filesystem socket, it must be a member of the sasl group.
# adduser postfix sasl

Don't forget
# /etc/init.d/saslauthd restart

to restart saslauthd after making these changes.　　Finally, tell saslauthd to use PAM for authentication.  

/etc/default/saslauthd
START=yes
MECHANISMS=&quot;pam&quot;

When contacted by postfix, saslauthd will consult the configuration file /etc/pam.d/smtp to determine which PAM modules to use. Fox example,
/etc/pam.d/smtp
auth        required      pam_ldap.so
account     required      pam_ldap.so
session     required      pam_ldap.so

I use LDAP. (For information on using the pam_ldap module, consult our whitepaper on LDAP Authentication for Linux.)   
Spam Control　　Unsolicited bulk email, colloquially called spam, is an increasingly problematic nuisance for both everyday email users and system administrators. Postfix offers a number of configuration directives you can use to try to catch and reject incoming spam.
　　The heart of Postfix's spam control system is a gauntlet of four restriction lists. The restriction lists reject or permit mail based on configurable criteria. The lists are named smtpd_*_restrictions, where the * is one of:  


client
restricts which clients may connect to smtpd
helo
restrictions based on HELO (or EHLO) greeting
sender
restrictions based on MAIL From: data
recipient
restrictions based on RCPT To: data

We already encountered the smtpd_recipient_restrictions list in the section above on relay control. There we showed how to restrict relayed mail to authorized machines and users. The other restriction lists operate in the same way, and we will now show how to use them to reject incoming spam.　　Some restrictions may appear on any list.  


permit
PERMIT all mail
reject
REJECT all mail

Typically you will use these only at the end of a restriction list to define its default policy. If you do not set one, the default policy for all restriction lists (except smtpd_recipient_restrictions) is PERMIT.
Client Restrictions　　The smtpd_client_restrictions list makes decisions based on the IP address of the connecting client. Possible list entries include:  


permit_mynetworks
PERMIT if IP is in $mynetworks
reject_unknown_client
REJECT if IP has no PTR in DNS
reject_rbl_client
REJECT if IP is blacklisted　　Most organizations want to be able to at least accept a connection for any source. This corresponds to  

main.cf
smtpd_client_restrictions = permit

which is the default.　　If you run separate inbound and outbound Postfix servers for your organization, you could limit connections to the outbound Postfix server by setting  

main.cf
smtpd_client_restrictions = permit_mynetworks, reject

in its configuration file. Using a firewall is probably a better solution, since it allows you to refuse all external connections to the server, not just those to the smtp port.　　The reject_rbl_client criterion requires additional explanation. Several organizations maintain lists of IP addresses from which spam has been observed to originate. Rejecting connections from IPs in such &quot;real-time black hole&quot; lists (RBLs) can be a extremely effective way to block spam.
　　Of course, a blacklist is only as good its criteria for including and excluding addresses. The people who maintain such lists are, as you might expect, rather zealous anti-spammers, and have been known to be rather aggressive, blacklisting entire class A (or larger!) network blocks that include a single spam-producing IP, occasionally even blacklisting the IPs of those who have merely been critical of their work. To avoid subjective judgments, some blacklists have turned to automated criteria, but unless the criteria are exquisitely well-chosen, that can lead to more problems than it solves. Here I list, without endorsement, several freely available blackhole lists.  


RBL Address
Web Address
Description
relays.ordb.org
www.ordb.org
lists open relays; inclusion by testing, removal by request and re-testing
bl.spamcop.net
www.spamcop.net
lists spammers; inclusion by user reports, removal by expiration
sbl.spamhaus.org
spamhaus
tracks IP used by a small number of known &quot;spam-gangs&quot;
spews.relays.osirusoft.com
spews
lists spammers; inclusion and removal by maintainers' judgment

To reject mail from addresses listed in one or more of these blacklists, use the reject_rbl_client restriction followed by the RBL address. For example:
main.cf
smtpd_client_restrictions = reject_rbl_client sbl.spamhaus.org,
                            permit

Note that, if an RBL you use goes down, your incoming mail throughput will drop precipitously, as Postfix waits for its RBL request to time out for every incoming mail.　　For a long time, I did not personally use blackhole lists, because I had several times been burned by the RBL server going down. Recently, spam has become such a huge headache that I have begun using RBLs again.

HELO restrictions　　The smtpd_helo_restrictions list makes decisions based on the HELO (or EHLO) greeting provided by the client. Many spammers use fake hostnames or even garbage in their HELO greeting; by rejecting mail from such clients, you may be able to cut down on incoming spam.  


reject_invalid_hostname
REJECT if HELO greeting is neither a DN nor an IP
reject_non_fqdn_hostname
REJECT if HELO greeting is neither a FQDN nor 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

For example,
main.cf
smtpd_helo_restrictions = reject_invalid_hostname, permit

will reject mail from clients that use garbage HELO greetings.　　For an overview of which HELO greetings are rejected by which reject_*_hostname restrictions, consult the following table.  


blarg!
example
example.com
192.0.34.72
invalid
X
non_fqdn
X
X
unknown
X
X
?
X

Here an X indicates that a REJECT is returned, and a ? indicates that whether a rejection is returned depends on the existance of a DNS record.　　Note that reject_unknown_hostname rejects IP addresses as well as fake FQDNs. To allow IP addresses, but still reject fake FQDNs, you can precede reject_unknown_hostnames with permit_naked_ip_address.  

main.cf
smtpd_helo_restrictions = permit_naked_ip_address, reject_invalid_hostname, permit

Sender Restrictions　　The smtpd_sender_restrictions list makes decisions based on the MAIL From: address given by the client. To avoid accountability, many spammers use fake From: addresses.  


reject_non_fqdn_sender
REJECT if MAIL host is neither a FQDN nor an IP
reject_unknown_sender_domain
REJECT if MAIL host has no A or MX in DNS
reject_sender_login_mismatch
REJECT if MAIL username does not match login username

The reject_non_fqdn_sender and reject_unknown_sender_domain restrictions operate on the MAIL data in a manner analogous to how reject_non_fqdn_hostname and reject_unknown_hostname operate on the HELO data.　　The reject_unknown_sender_domain restriction is particularly useful, since it rejects mail from an address which cannot be replied to; such mail is almost never from a valid, human correspondent.  

main.cf
smtpd_sender_restrictions = reject_unknown_sender_domain, permit

Recipient Restrictions　　The smtpd_recipient_restrictions list makes decisions based on the RCPT To: addresses given by the client.  


reject_unknown_recipient_domain
REJECT if RCPT host has no A or MX in DNS
reject_non_fqdn_recipient
REJECT if RCPT host is neither a FQDN nor an IP
reject_unauth_destination
REJECT unless recipient address is local or in $relay_domains
permit_auth_destination
PERMIT if recipient address is local or in $relay_domains
permit_sasl_authenticated
PERMIT if client has authenticated using SASL

Since the recipient address determines whether Postfix relays a mail or accepts it for delivery to a local user, smtpd_recipient_restrictions are used primarily to control relay authorization. Specific techniques are discussed in the &quot;Relay Control&quot; section above.   
Restriction List Tips　　A restriction can be used for its native restriction list or on any restriction list after that. It is often useful to use a restriction on a list later than its native one.  For example, the permit_mynetworks restriction is native to the smtpd_client_restrictions list, but we used it on the smtpd_recipient_restrictions list for relay control.  A second example would be to use reject_rbl_client (which is also native to the smtpd_client_restrictions list) after permit_sasl_authenticated on the smtpd_recipient_restrictions, so that authorized users are allowed to relay mail even from blacklisted servers.
　　Any given restriction could block legitimate mail as well as spam. It could also have too small an effect on spam to justify the additional resources (e.g. connecting to a remote DNS server) it requires. Without knowing the rates of true and false positives that a given restriction will generate, it is difficult to justify its adoption. Unfortunately, it is very difficult to make generalizations about the effects of different restrictions; the mail environments in which different organizations operate just differ too greatly.
　　Fortunately, Postfix allows you to passively test restrictions. If any reject_* restriction is proceeded by warn_if_reject, a REJECT from that restriction results in a log entry instead of a rejection of the mail.  For example, if you are considering using reject_unknown_sender_domain, you might want to specify  

main.cf
smtpd_sender_restrictions = warn_if_reject, reject_unknown_sender_domain, permit

and then watch for log entries like
Aug  6 10:33:12 smtp postfix/smtpd[23050]: reject_warning:
RCPT from unknown[211.186.53.127]: 450 <nobody@nowhere.org>:
Sender address rejected: Domain not found;
from=<nobody@nowhere.org> to=<bob@example.com>

Header and Body Checks　　So far, we have considered criteria that depend exclusively on how a client wishing to send mail presents itself. But it is the content of the mail that, for most users, makes it spam or not. Postfix allows you to reject mail based on regular expression tests of the content of both a mail's headers and a mail's body.

Other Directives　　There are a few other directives besides the smtpd_*_restrictions lists that can be usefully employed to fight incoming spam.
　　To increase mail throughput, some spam-ware doesn't bother to issue a HELO greeting. You can reject mail from clients who don't bother to say HELO.  

main.cf
smtpd_helo_required = yes

　　Finally, you will probably want to disable the VRFY command, an SMTP language element used to test whether a local addressee exists. The VRFY command is used almost exclusively by the maintainers address lists for bulk mailings to search for valid email addresses.  

disable_vrfy_command = yes


Performance Tuning　　Out of the box, Postfix is already sufficiently performant on comodity desktop hardware to handle the email load of a typical medium-sized organization (say 1000 people). You probably need to read this section only if you are configuring an email system for a large organization, or if the activities of your organization require a large volume of automated email (in which case, I hope you are not a spammer).
　　As any physical chemist knows, the speed of a complex process consisting of a chain of sub-processes is limited by the speed of the slowest sub-process. The same holds true for mail delivery, and if you want to speed up Postfix, you must identify the bottleneck which is limiting mail throughput. Here is a simple checklist of possbile limiting factors:

• process availability
  
• CPU speed
  
• DNS lookup time
  
• disk I/O speed
  
• network throughput
  

We will consider each of these factors in turn below.
Process Availability　　Postfix consists of about a dozen co-operating applications. The smtpd application accepts incoming mail from the smtp network port. The smtp (without a &quot;d&quot;) application contacts other MTAs on the internet to deliver outbound mail. Each of the other applications performs a simple operation on a mail before handing it off to the next one.
　　By default, Postfix limits the number of concurrent processes of any one application to 50. Since network connections are slow (relative to local interprocess communications), the smtp or smtpd daemons are likely to run up against this limitation first as mail traffic increases. If the number of live smtp or smtpd daemons shown by &quot;ps aux&quot; reaches a significant fraction of this default limit, you should consider increasing the limit. This is done via the default_process_limit directive.  

main.cf
default_process_limit = 100

Before you do this, make sure than your machine has sufficient memory to handle the additional daemon processes. Just examine the output of &quot;ps aux&quot; to determine the fraction of memory occupied by each Postfix process, and make sure you have enough memory to hold $default_process_limit of them. If not, consider purchasing additional memory.   
CPU Speed　　If you are not running up against the default_process_limit, but still not achieving the mail throughput you want, consider the possibility that you are CPU limited. Use &quot;top&quot; to determine the average CPU utilization of your mail server under peak load. If it is high (say 50% or more), consider purchasing a faster processor.

DNS Lookup　　Before your system is process-limited or CPU-limited, you are likely to be limited by DNS lookup times. Deliverying a mail requires looking up at very least one IP address, and the speed is therefore limited by the latency and bandwith of Postfix's communications with your DNS server. Consider setting up your own caching DNS server right next to your mail server (or, even better, on the mail server machine). Such a simple DNS server is surprisingly simple to set up and maintain, and can have a dramatic impact on DNS lookup times.

Disk Storage　　If you are not process-limited, CPU-limited, memory-limited, or network-limited, you can still be disk-limited. Postfix maintains a number of queue directories under /var/spool/postfix/. Postfix applications co-operate by picking up mail from one queue directory and, after performing their assiged operation, dropping it into another one.  You can go a long way toward increasing Postfix's throughput by speeding access to theses directories.  Place /var/spool/postfix on its own hard drive. If you can afford it, use a fast SCSI drive, as SCSI can schedule interleaved requests from multiple processes much better than IDE. If you can't afford a SCSI drive, buy a fast IDE drive and tune it using hdparm to achieve maximum throughput. Whatever drive you use, be sure to mount it with the noatime option to avoid the overhead involved in storing the time of each and every file; Postfix does not use access time stamps.

Multiple Mail Servers　　Imagine you have followed all the steps above, turning your Postfix server into a lean, mean, mailin' machine, and still you cannot reach the level of mail throughput necessary to achieve your goals. (Unless you are a spammer, you are probably going to have to imagine this scenario, because you are unlikely to face it in reality.) If you have a fat enough network pipe to handle several such boxes, you can scale your system up by running several mail servers in parallel.
　　Since there is no need to maintain state information beyond a single smtp session, you can use a technique called DNS round-robin to great effect. To implement DNS round-robin, assign multiple A entries to the FQDN of your mail hub in DNS.  

$ dig smtp.example.com +short
192.0.34.16
192.0.34.17
192.0.34.18

When an SMTP client wishes to send mail, it will query DNS to obtain the IP address of your ogranization's mail server. Each time, your DNS server will return a different IP first, thus approximately balancing the load across all your mail servers.　　For outbound mail, the scalability of the round-robin technique is limited only by your organization's total network bandwidth. For inbound mail, you may run up agaist the limitations of your IMAP or POP mailstores first.