- 1 TODO
- 2 Research
- 3 Creating a variable in main.cf and referring to it from master.cf
- 4 Configuration files
- 5 Parameters
- 6 Lookup tables
- 7 Unsorted
- 8 Is there some kind of debug or verbose logging option so that I can see exactly what happens with my mail?
- 9 Envelope vs Header addresses
- 10 Error conditions
- 11 Is it possible to have global virtual aliases for addresses like postmaster, so that mail for postmaster at all of my domains can go to the same address?
- 12 Marking activated header/body check rules in log messages
- 13 Is there any way I can have a virtual alias deliver a message to a program?
- 14 Important options to set
- 15 Delivery agents
- 16 master.cf
- 17 Indexed lookup tables
- 18 Content filtering
- 19 Restrictions
- 20 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. 
Creating a variable in main.cf and referring to it from master.cf
I need to add some smtpd restrictions to my master.cf file, something like: -o smtpd_recipient_restrictions=check_recipient_access hash:/etc/postfix/recipient_access Any idea how I can do that with the space required between the check_recipient_access and the lookup table? You can use a comma instead of a space: Another option is to define a variable in main.cf with all the restrictions you need, then use the variable in master.cf: # # main.cf # ... other_restrictions = check_recipient_access hash:/etc/postfix/recipient_access reject_unknown_recipient_domain ... # # master.cf # ... -o smtpd_recipient_restrictions=$other_restrictions
- By default, Postfix configuration files are stored in /etc/postfix. The two most important files are
master.cf; these files must be owned by root. Giving someone else write permission to either file (or to their parent directories) means giving root privileges to that person.
- Parameters resemble shell variables, but they do not support quotes.
- Postfix uses lazy evaluation, allowing you to use a parameter as a value to another parameter before you've defined in the configuration file (similar to many compiled languages).
- Postfix uses database files (aka, "lookup tables") for access control, address rewriting and other purposes.
- Many parameters can have multiple values. They can be separated by commas, spaces, tabs or newlines. When separating values with newlines, you must remember to including spaces or tabs in front of the values to indicate a continuation of the previous line. This "continued" line is also referred to as a logical line.
- All Postfix lookup tables store information as (key, value) pairs.
- Regular Expression lookup tables should not be run through
- For all lookup table types except regexp and pcre, Postfix makes multiple lookups for each of these restrictions, slightly dependent on what type of data is being looked up (email address or hostname for example). This makes it possible to make inexact wildcard matches, for example matching all e-mail addresses in a domain. 
- There are multiple lookup table types, ranging from a
statictype that always returns the same string as a result, to database and tcp-based daemon lookup tables. 
always_bccparameter can be used to archive email.
- Local domains are listed in
- Introducing virtual alias domains does not cause the original local domain to stop accepting messages.
- Header and body checks can use the
IGNOREaction to remove a matched line from the message (as if it never existed at all).
- Virtual aliases not only apply to virtual alias domains, but to all messages that pass through Postfix.
- You can rewrite a virtual alias to a local alias. You can then rewrite a local alias to scripts/commands. I believe that Mailman is one such example.
- The envelope of a message consists of the information given in the
- A SMTP server pays no attention to the
- Bounces are always sent to the envelope sender address.
Is there some kind of debug or verbose logging option so that I can see exactly what happens with my mail?
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.
Is it possible to have global virtual aliases for addresses like postmaster, so that mail for postmaster at all of my domains can go to the same address?
You can use a regular expression map to pull this off.
Marking activated header/body check rules in log messages
Not really. Most people include a unique marker on the RHS to identify their rules. You can do something as simple as numbering your rules. For example,
/freehotsex/ REJECT Message content rejected 
will log "Message content rejected " when this rule is used to reject a message.
Is there any way I can have a virtual alias deliver a message to a program?
Not directly. You have to use a virtual alias to rewrite the address to something that is delivered to a pipe transport or a local address on the system.
Important options to set
smtpd_delay_reject (default: yes)
Wait until the RCPT TO command before evaluating
$smtpd_sender_restrictions, or wait until the ETRN command before evaluating
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. 
$myhostname should be listed within
$mydestination so mail addressed to
localhost is delivered properly.
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
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_rejectwas 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
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.
The name of the restriction controls what information is used as the lookup key. For example, the
check_client_access restriction looks up the client IP address and hostname in a lookup table, allowing you to, say, ban certain clients that are known to send spam. 
Restrictions that I like to use:
- Reject mail for aliases that I've retired.
- Whitelist other email servers that are improperly configured, but yet are still in charge of delivering mail that I want to receive.
- Whitelist other mail servers for our domains. This is more of a failsafe for other restrictions causing problems.
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.  The name of the restriction list only indicates at what stage in the SMTP session the listed restrictions will be applied.
postconf -d smtpd_recipient_restrictions
smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination
That default set of restrictions stops invalid relay attempts. Until Postfix 2.10.x that is how you kept spammers from using your mail system as a spam relay host and getting yourself added to block lists. With Postfix 2.10.x and later you now have a separate restriction list called
||permits the current recipient if the connecting client is within the networks specified by |
||will reject recipients whose domain is not one of the domains that postfix will accept mail for. In other words, this option rejects invalid relay attempts.|
||reject if the domain part of the sender address is a domain hosted by Postfix and the complete address would not be acceptable as a recipient address. The idea behind this feature is that there is no reason to accept messages with sender addresses known to be incorrect. See also |
If no rejection takes place by the end of a restriction list Postfix will accept the message. Some guides advocate placing
permit as the last item in restriction lists to emphasize this point. However, a permit result in one restriction list will not cause the message as a whole to be accepted. Only the remaining restrictions in the same list will be bypassed. This is not true for restrictions that return reject -- that result is always terminal and stops of the evaluation of all restriction lists. 
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; 
- Postfix Configuration Parameters - smtpd_reject_unlisted_recipient
- Linux Email by Packt Publishing
- Postfix Lookup Table Overview - Postfix lookup table types
- Postfix Configuration Parameters - smtpd_delay_reject
- Postfix Configuration Parameters - smtpd_recipient_restrictions
- Postfix SMTP relay and access control
- access - Postfix SMTP server access table
- Postfix Per-Client/User/etc. Access Control
- postmap - Postfix lookup table management
- Postfix Address Classes
- Postfix Lookup Table Overview
- 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
- Uses whitelists, lots of RBL entries and includes all restriction lists, albeit in questionable order?
- - Postfix and Email Resources (companion site to Postfix: The Definitive Guide)