Table of Contents for
Postfix: The Definitive Guide

Version ebook / Retour

Cover image for bash Cookbook, 2nd Edition Postfix: The Definitive Guide by Kyle D. Dent Published by O'Reilly Media, Inc., 2003
  1. Postfix: The Definitive Guide
  2. Cover
  3. Postfix: The Definitive Guide
  4. Foreword
  5. Preface
  6. Audience
  7. Organization
  8. Conventions Used in This Book
  9. Comments and Questions
  10. Acknowledgments
  11. 1. Introduction
  12. 1.1. Postfix Origins and Philosophy
  13. 1.2. Email and the Internet
  14. 1.3. The Role of Postfix
  15. 1.4. Postfix Security
  16. 1.5. Additional Information and How to Obtain Postfix
  17. 2. Prerequisites
  18. 2.1. Unix Topics
  19. 2.2. Email Topics
  20. 3. Postfix Architecture
  21. 3.1. Postfix Components
  22. 3.2. How Messages Enter the Postfix System
  23. 3.3. The Postfix Queue
  24. 3.4. Mail Delivery
  25. 3.5. Tracing a Message Through Postfix
  26. 4. General Configuration and Administration
  27. 4.1. Starting Postfix the First Time
  28. 4.2. Configuration Files
  29. 4.3. Important Configuration Considerations
  30. 4.4. Administration
  31. 4.5. master.cf
  32. 4.6. Receiving Limits
  33. 4.7. Rewriting Addresses
  34. 4.8. chroot
  35. 4.9. Documentation
  36. 5. Queue Management
  37. 5.1. How qmgr Works
  38. 5.2. Queue Tools
  39. 6. Email and DNS
  40. 6.1. DNS Overview
  41. 6.2. Email Routing
  42. 6.3. Postfix and DNS
  43. 6.4. Common Problems
  44. 7. Local Delivery and POP/IMAP
  45. 7.1. Postfix Delivery Transports
  46. 7.2. Message Store Formats
  47. 7.3. Local Delivery
  48. 7.4. POP and IMAP
  49. 7.5. Local Mail Transfer Protocol
  50. 8. Hosting Multiple Domains
  51. 8.1. Shared Domains with System Accounts
  52. 8.2. Separate Domains with System Accounts
  53. 8.3. Separate Domains with Virtual Accounts
  54. 8.4. Separate Message Store
  55. 8.5. Delivery to Commands
  56. 9. Mail Relaying
  57. 9.1. Backup MX
  58. 9.2. Transport Maps
  59. 9.3. Inbound Mail Gateway
  60. 9.4. Outbound Mail Relay
  61. 9.5. UUCP, Fax, and Other Deliveries
  62. 10. Mailing Lists
  63. 10.1. Simple Mailing Lists
  64. 10.2. Mailing-List Managers
  65. 11. Blocking Unsolicited Bulk Email
  66. 11.1. The Nature of Spam
  67. 11.2. The Problem of Spam
  68. 11.3. Open Relays
  69. 11.4. Spam Detection
  70. 11.5. Anti-Spam Actions
  71. 11.6. Postfix Configuration
  72. 11.7. Client-Detection Rules
  73. 11.8. Strict Syntax Parameters
  74. 11.9. Content-Checking
  75. 11.10. Customized Restriction Classes
  76. 11.11. Postfix Anti-Spam Example
  77. 12. SASL Authentication
  78. 12.1. SASL Overview
  79. 12.2. Postfix and SASL
  80. 12.3. Configuring Postfix for SASL
  81. 12.4. Testing Your Authentication Configuration
  82. 12.5. SMTP Client Authentication
  83. 13. Transport Layer Security
  84. 13.1. Postfix and TLS
  85. 13.2. TLS Certificates
  86. 14. Content Filtering
  87. 14.1. Command-Based Filtering
  88. 14.2. Daemon-Based Filtering
  89. 14.3. Other Considerations
  90. 15. External Databases
  91. 15.1. MySQL
  92. 15.2. LDAP
  93. A. Configuration Parameters
  94. A.1. Postfix Parameter Reference
  95. 2bounce_notice_recipient
  96. access_map_reject_code
  97. alias_maps
  98. allow_mail_to_files
  99. allow_percent_hack
  100. alternate_config_directories
  101. append_at_myorigin
  102. authorized_verp_clients
  103. berkeley_db_read_buffer_size
  104. biff
  105. body_checks_size_limit
  106. bounce_service_name
  107. canonical_maps
  108. command_directory
  109. command_time_limit
  110. content_filter
  111. daemon_timeout
  112. debug_peer_list
  113. default_destination_concurrency_limit
  114. default_extra_recipient_limit
  115. default_process_limit
  116. default_recipient_limit
  117. default_verp_delimiters
  118. defer_service_name
  119. delay_notice_recipient
  120. deliver_lock_attempts
  121. disable_dns_lookups
  122. disable_mime_output_conversion
  123. disable_vrfy_command
  124. double_bounce_sender
  125. empty_address_recipient
  126. error_service_name
  127. export_environment
  128. fallback_relay
  129. fast_flush_domains
  130. fast_flush_refresh_time
  131. fork_attempts
  132. forward_expansion_filter
  133. hash_queue_depth
  134. header_address_token_limit
  135. header_size_limit
  136. home_mailbox
  137. ignore_mx_lookup_error
  138. in_flow_delay
  139. initial_destination_concurrency
  140. ipc_idle
  141. line_length_limit
  142. lmtp_connect_timeout
  143. lmtp_data_init_timeout
  144. lmtp_lhlo_timeout
  145. lmtp_quit_timeout
  146. lmtp_rset_timeout
  147. lmtp_tcp_port
  148. local_destination_concurrency_limit
  149. local_recipient_maps
  150. luser_relay
  151. mail_owner
  152. mail_spool_directory
  153. mailbox_command
  154. mailbox_delivery_lock
  155. mailbox_transport
  156. manpage_directory
  157. masquerade_domains
  158. max_idle
  159. maximal_backoff_time
  160. message_size_limit
  161. mime_header_checks
  162. minimal_backoff_time
  163. mydomain
  164. mynetworks
  165. myorigin
  166. newaliases_path
  167. notify_classes
  168. parent_domain_matches_subdomains
  169. pickup_service_name
  170. process_id_directory
  171. proxy_interfaces
  172. qmgr_clog_warn_time
  173. qmgr_message_active_limit
  174. qmgr_message_recipient_minimum
  175. qmqpd_error_delay
  176. queue_directory
  177. queue_run_delay
  178. rbl_reply_maps
  179. recipient_canonical_maps
  180. reject_code
  181. relay_domains_reject_code
  182. relay_transport
  183. relocated_maps
  184. resolve_dequoted_address
  185. sample_directory
  186. sendmail_path
  187. setgid_group
  188. showq_service_name
  189. smtp_bind_address
  190. smtp_data_done_timeout
  191. smtp_data_xfer_timeout
  192. smtp_destination_recipient_limit
  193. smtp_helo_timeout
  194. smtp_mail_timeout
  195. smtp_pix_workaround_delay_time
  196. smtp_quit_timeout
  197. smtp_rcpt_timeout
  198. smtp_skip_5xx_greeting
  199. smtpd_banner
  200. smtpd_data_restrictions
  201. smtpd_error_sleep_time
  202. smtpd_expansion_filter
  203. smtpd_helo_required
  204. smtpd_history_flush_threshold
  205. smtpd_noop_commands
  206. smtpd_recipient_limit
  207. smtpd_restriction_classes
  208. smtpd_soft_error_limit
  209. soft_bounce
  210. strict_7bit_headers
  211. strict_8bitmime_body
  212. strict_rfc821_envelopes
  213. swap_bangpath
  214. syslog_name
  215. transport_retry_time
  216. undisclosed_recipients_header
  217. unknown_client_reject_code
  218. unknown_local_recipient_reject_code
  219. unknown_virtual_alias_reject_code
  220. verp_delimiter_filter
  221. virtual_alias_maps
  222. virtual_mailbox_base
  223. virtual_mailbox_limit
  224. virtual_mailbox_maps
  225. virtual_transport
  226. B. Postfix Commands
  227. C. Compiling and Installing Postfix
  228. C.1. Obtaining Postfix
  229. C.2. Postfix Compiling Primer
  230. C.3. Building Postfix
  231. C.4. Installation
  232. C.5. Compiling Add-on Packages
  233. C.6. Common Problems
  234. C.7. Wrapping Things Up
  235. D. Frequently Asked Questions
  236. Index
  237. About the Author
  238. Colophon
  239. Copyright

Local Mail Transfer Protocol

Some POP/IMAP servers use nonstandard message stores. Since it would be unreasonable to expect MTAs such as Postfix to understand many different proprietary formats, the Local Mail Transfer Protocol (LMTP) provides a way to pass email messages from one local mail service to another without depending on a common message store. LMTP is based on, and is a simplified version of, SMTP. With LMTP, the server can either accept an email message immediately or it cannot accept it at all. There is no attempt by the LMTP server to queue or redeliver a message that cannot be delivered immediately.

When an MTA makes a delivery to an SMTP server, where the message is destined for multiple recipients, and one or more recipients cannot accept the message for some reason, the SMTP server takes the responsibility of queuing the message to deliver it later, and reports an overall successful delivery to the MTA. LMTP servers do not queue messages, so they must return an individual status reply for every recipient of a particular email message. For those recipients that could not be delivered, the MTA, and not the LMTP server, takes the responsibility of queuing the message and attempting redelivery.

LMTP conversations can occur between mail subsystems on the same machine or on different machines on a local area network. It is not recommended for wide area networks, since the protocol depends on a quick response to indicate whether the message was delivered. With SMTP there is a recognized synchronization problem between sending and receiving mail systems that sometimes causes duplicate messages to be delivered. It is believed that LMTP over wide area networks would make the problem worse.

Tip

Apart from delivery to nonstandard message stores, a real benefit of the LMTP protocol is that it allows for a highly scalable and reliable mail system. One or more Postfix servers can receive mail from the public Internet and make deliveries to multiple LMTP backend systems. As the load increases, it is a simple matter to add more boxes to the front- or backend systems.

The most common implementation of LMTP delivery is the Cyrus IMAP server from Carnegie Mellon University. It is available from the Project Cyrus web page at http://asg.web.cmu.edu/cyrus/. Cyrus IMAP uses its own message store, as shown in Figure 7-2. This section looks at how Postfix can use the LMTP protocol to hand off messages to Cyrus IMAP. For more information about configuring Cyrus IMAP, see Managing IMAP by Dianna Mullet and Kevin Mullet (O’Reilly).

Postfix and Cyrus IMAP

Cyrus IMAP is intended to run on servers that provide POP/IMAP access only, where users do not need a shell account. If you are creating a mail server for existing users on a system, you will probably want to use another simpler POP/IMAP solution, such as Qualcomm’s Qpopper (POP access only) or the University of Washington’s IMAP Toolkit, which doesn’t require any special configuration to work with Postfix. This section deals with configuration issues for getting Postfix to work together with Cyrus IMAP.

Postfix and Cyrus IMAP
Figure 7-2. Postfix and Cyrus IMAP

Cyrus IMAP can listen for LMTP deliveries using either Unix-domain sockets or TCP sockets. You must know which method you are using so that you can configure Postfix appropriately. If you want to use Unix-domain sockets, both Postfix and the Cyrus IMAP server must be on the same machine. If you use TCP sockets, the Cyrus IMAP server could be on the same system or any other system on your network. LMTP delivery is configured in your main.cf file or in a transport map.

For Postfix to accept messages to be delivered locally to Cyrus IMAP, the destination domain name of the email address must be listed in the mydestination parameter. (You may also want to configure Cyrus deliveries via the virtual transport. See Chapter 8.) Then you must configure Postfix to pass messages to Cyrus IMAP. Use the mailbox_transport, local_transport, or fallback_transport parameter to tell Postfix how much local processing to do before handing off messages to Cyrus. If you are using local_transport or fallback_transport, make sure that Postfix knows about all of the Cyrus users, by including the usernames in a lookup table listed with the local_recipient_maps parameter.

mailbox_transport

The mail message is given to the local delivery agent first. The local delivery agent checks for and expands any aliases or entries in .forward files. After expansion of the original address, the message is delegated to the Postfix LMTP client, which delivers it to the LMTP server.

local_transport

When you specify that the local transport should be LMTP, Postfix transfers the message directly to the Postfix LMTP client. The normal local delivery agent does not process the message at all, so there is no expansion of aliases or .forward files.

fallback_transport

When the fallback transport is LMTP, Postfix gives the message to its local delivery agent first. The normal aliases and .forward files are expanded, and if the recipient has a normal account on the system, delivery is made to the appropriate mail store on the system. If no such account exists, delivery is delegated to the Postfix LMTP client for delivery to the LMTP server. If you have actual accounts on the system that should receive email messages in the conventional message store, and the rest of your email users do not have system accounts but do receive mail through the Cyrus IMAP server, you should configure the fallback_transport to use LMTP delivery.

Specify your chosen transport type using the following format:

               xxx_transport = service:socket_type[:/path/to/socket]

For LMTP delivery, service must be lmtp, which refers to the lmtp service in the /etc/postfix/master.cf file. The socket_type is either unix or inet for Unix domain, or TCP sockets, respectively. The default is inet, which means that if your LMTP server uses an inet socket, you can simply specify the service as:

local_transport = lmtp

A typical LMTP transport configuration in /etc/postfix/main.cf using local_transport and a Unix domain socket looks like the following:

local_transport = lmtp:unix:/var/imap/socket/lmtp

A Postfix and Cyrus IMAP Example

To build Cyrus IMAP, you need the Cyrus SASL library, which is used to authenticate users for the IMAP server.[1] You must first build and install the Cyrus SASL library, and then you can build the Cyrus IMAP server. The Cyrus software requires at least Version 3 of Berkeley DB. If you were using a version of Berkeley DB prior to Version 3, you may need to update your entire system. Having different versions of Berkeley DB intermixed on your system will likely lead to problems that can be difficult to track down. If you have to upgrade your libraries, consider rebuilding other packages that use Berkeley DB (such as Perl and Postfix), so that everything on your system uses the same version of the library.

Follow the instructions in the Cyrus SASL and IMAP distributions to compile and install them correctly on your system. There might be binary distributions available for your platform. Check your normal software sources to see if you can save yourself the trouble of building the Cyrus software.

For this example, assume that you have a Postfix server receiving mail for the domain example.com. All of the email accounts are set up within the Cyrus IMAP server running on the same system, so there are very few actual login accounts on the system. However, you want mail destined for the root account or postmaster alias to be sent to the correct person, which means that you need to expand local aliases before handing off messages to the Cyrus IMAP server. To achieve this, set the mailbox_transport parameter to point to the lmtp delivery agent, which will be configured to deliver mail to the Cyrus IMAP server:

  1. Complete the installation and configuration of Cyrus IMAP on your system. Check the Cyrus configuration file (normally /etc/cyrus.conf) to make sure that it is configured to use Unix-domain sockets, and note the location of the socket file. You should see an entry that resembles the following:

    SERVICES {
      # add or remove based on preferences
      imap          cmd="imapd" listen="imap" prefork=0
      pop3          cmd="pop3d" listen="pop3" prefork=0
      # LMTP is required for delivery
      lmtpunix      cmd="lmtpd" listen="/var/imap/socket/lmtp" prefork=0
    }

    The lmtpunix entry shows the correct path to the socket file.

  2. Follow the documentation that came with your package to add users to your Cyrus IMAP server.

  3. Check the /etc/postfix/master.cf to make sure that the lmtp service is set up correctly. The line should look like the following:

    lmtp      unix  -       -       n       -       -       lmtp

    If you have a default Postfix installation, the lmtp line will already be in the file, as shown in the example. The fifth column indicates whether the LMTP delivery agent should run within a chrooted environment. In this example, the Postfix LMTP delivery agent must read the socket file created by the Cyrus IMAP server, so leave this column with the value n.[2]

  4. Check the main.cf file to make sure that the domain you are receiving mail for is listed in the mydestination parameter. It might be listed explicitly:

    mydestination = $myhostname, localhost.$mydomain, $mydomain,
       example.com

    or it might come from the $mydomain variable:

    mydomain = example.com
    mydestination = $myhostname, localhost.$mydomain, $mydomain
  5. Specify that the mailbox_transport parameter should use the lmtp service from the master.cf file, and point to the Cyrus IMAP socket file whose path you determined from the Cyrus configuration file (see item 1):

    mailbox_transport = lmtp:unix:/var/imap/socket/lmtp
  6. Reload Postfix:

    # postfix reload


[1] It is the same library that is used to add authentication support for Postfix. See Chapter 12 for more information on adding SMTP authentication support to Postfix.

[2] It is possible to set up your system in such a way that allows the LMTP delivery agent to read the socket file even from within the Postfix chroot environment, but it is probably not necessary.