- 1 TODO
- 2 Research
- 3 Creating a variable in main.cf and referring to it from master.cf
- 4 Unsorted
- 5 Is there some kind of debug or verbose logging option so that I can see exactly what happens with my mail?
- 6 Envelope vs Header addresses
- 7 Error conditions
- 8 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?
- 9 Marking activated header/body check rules in log messages
- 10 Is there any way I can have a virtual alias deliver a message to a program?
- 11 Important options to set
- 12 Delivery agents
- 13 Whitelisting
- 14 master.cf
- 15 Indexed lookup tables
- 16 Content filtering
- 17 Restrictions
- 18 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
- The always_bcc parameter can be used to archive email.
echo "Hello World"
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_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.  The name of the restriction list only indicates at what state 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 know 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.
- Postfix Configuration Parameters - smtpd_reject_unlisted_recipient
- Linux Email by Packt Publishing
- Postfix Configuration Parameters - smtpd_delay_reject
- Postfix SMTP relay and access control
- Postfix Configuration Parameters - smtpd_recipient_restrictions
- Cite error: Invalid
<ref>tag; no text was provided for refs named
- 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
- 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)