- 1 TODO
- 2 Research
- 3 Unsorted
- 4 Envelope vs Header addresses
- 5 Error conditions
- 6 Important options to set
- 7 Delivery agents
- 8 Whitelisting
- 9 master.cf
- 10 Indexed lookup tables
- 11 Content filtering
- 12 Restrictions
- 13 References
- Explain differences between envelope and header TO/FROM addresses
Rejecting Unlisted Sender
Rejecting Unlisted Recipient
Request that the Postfix SMTP server rejects mail for unknown recipient addresses, even when no explicit reject_unlisted_recipient access restriction is specified. This prevents the Postfix queue from filling up with undeliverable MAILER-DAEMON messages. .
An address is always considered "known" when it matches a virtual(5) alias or a canonical(5) mapping.
Problem reports - postmaster
The type of problems that Postfix will report to the postmaster is configurable with the notify_classes parameter. By default, only resource issues such as out-of-disk-space problems and software problems will be reported, but you may configure Postfix to report more types of problems. For example, you might also want to know about SMTP protocol violations: notify_classes = resource, software, protocol When Postfix reports a problem, a transcript of the SMTP session is included. This can be a valuable debugging aid. Opt for more extensive error reporting rather than terse reporting. If you receive too many error reports, see if you can use the filtering features of your delivery agent or your mail client to remove the error reports that you are not interested in. 
- The always_bcc parameter can be used to archive email.
echo "Hello World"
Envelope vs Header addresses
The envelope of a message consists of the information given in the MAIL FROM and RCPT TO commands  , that is, the sender and recipient information that are used to deliver the message. An SMTP server pays no attention what so ever to the From, To, and Cc message headers.
- Bounces are always sent to the envelope sender address
- The sender address of bounce messages is the empty sender address, often called the null sender.
- The null sender address must not be blocked.
In SMTP, error conditions can be either temporary or permanent.  Both 4 and 5 are used to signal errors. A client that receives a temporary error designated by 4 should disconnect, keep the message in the queue, and retry at a later time. Typical temporary error conditions include a full mail queue disk, a server configuration error that must be resolved before messages can be accepted, or a temporary DNS lookup error. Permanent errors are indicated by the first digit being 5 and mean that the request will never be accepted, so a client will have to remove the message from the queue and send a bounce to the sender telling him or her that the message could not be delivered.
Important options to set
smtpd_delay_reject (default: yes)
Wait until the RCPT TO command before evaluating $smtpd_client_restrictions, $smtpd_helo_restrictions and $smtpd_sender_restrictions, or wait until the ETRN command before evaluating $smtpd_client_restrictions and $smtpd_helo_restrictions.
This feature is turned on by default because some clients apparently mis-behave when the Postfix SMTP server rejects commands before RCPT TO.
The default setting has one major benefit: it allows Postfix to log recipient address information when rejecting a client name/address or sender address, so that it is possible to find out whose mail is being rejected. 
Early Postfix versions evaluated SMTP access restrictions lists as early as possible. The client restriction list was evaluated before Postfix sent the "220 $myhostname..." greeting banner to the SMTP client, the helo restriction list was evaluated before Postfix replied to the HELO (EHLO) command, the sender restriction list was evaluated before Postfix replied to the MAIL FROM command, and so on. This approach turned out to be difficult to use.
Current Postfix versions postpone the evaluation of client, helo and sender restriction lists until the RCPT TO or ETRN command. This behavior is controlled by the smtpd_delay_reject parameter.
Restriction lists are still evaluated in the proper order of (client, helo, etrn) or (client, helo, sender, relay, recipient, data, or end-of-data) restrictions.
When a restriction list (example: client) evaluates to REJECT or DEFER the restriction lists that follow (example: helo, sender, etc.) are skipped.
Around the time that smtpd_delay_reject was introduced, Postfix was also changed to support mixed restriction lists that combine information about the client, helo, sender and recipient or etrn command.
- The Postfix delivery agents are the last daemons to touch messages before they leave the email server.
- Virtual mailbox users (users without real accounts on the system) have their messages delivered via the
Each restriction list is evaluated from left to right until some restriction produces a result of PERMIT, REJECT or DEFER (try again later). The end of the list is equivalent to a PERMIT result. By placing a PERMIT restriction before a REJECT restriction you can make exceptions for specific clients or users. This is called whitelisting; 
Indexed lookup tables
An indexed lookup table is a text file containing key/value pairs. The first part of each line, up to the first space or tab, will be taken as a lookup key and the rest of the line will be taken as the corresponding value. One drawback with indexed lookup tables is that you do have to remember to run
postmap when you updated the file. This is not necessary with ldap or sql database lookups.
- You do not have to reload or restart Postfix after updating an indexed file with
- After-queue content filtering takes email, does massaging and passes back to Postfix.
- Before-queue filter is intensive and ties up local and remote resources in order to filter email before it is allowed into the queue.
SMTP restrictions work on envelop content, not mail content (including headers?)
A common misconception is that only restrictions on the recipient address can be placed in smtpd_recipient_restrictions, only restrictions on the sender address can be placed in smtpd_sender_restrictions, and so on but because of the default value of smtpd_delay_reject, that is not true. 
- access - Postfix SMTP server access table
- Postfix Per-Client/User/etc. Access Control
- postmap - Postfix lookup table management
- Postfix Address Classes
- Linode.com - Email Server Guides
- Enhanced Mail System Status Codes
- ISPmail tutorial for Debian Lenny - Postfix to Database Mappings
- Postfix Complete Virtual Mail System
- http://ubuntudanmark.dk/blog/artikler/2012/09/09/email-server-med-virtuelle-brugere-pa-debian/ (not sure about this one)
- Postfix Transport Maps – Diverting Mail Traffic