Email/Postfix

From WhyAskWhy.org Wiki
< Email
Revision as of 16:11, 24 February 2014 by Deoren (talk | contribs) (Formatting tweaks and more restrictions notes)
Jump to: navigation, search


TODO

  • Explain differences between envelope and header TO/FROM addresses

Research

Rejecting Unlisted Sender

http://postfix.1071664.n5.nabble.com/smtpd-reject-unlisted-sender-tp31275p31278.html


Rejecting Unlisted Recipient

smtpd_reject_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. [1].

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. [2]

Creating a variable in main.cf and referring to it from master.cf

http://www.seaglass.com/postfix/faq.html#mstrspc


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


Unsorted

  • 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?

http://www.seaglass.com/postfix/faq.html#lgsbj


Envelope vs Header addresses

The envelope of a message consists of the information given in the MAIL FROM and RCPT TO commands [2] , 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.

Error conditions

In SMTP, error conditions can be either temporary or permanent. [2] 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?

http://www.seaglass.com/postfix/faq.html#vrtglal

You can use a regular expression map to pull this off.

regexp:/etc/postfix/virtual_alias

/postmaster@.*/            admin@seaglass.com

Marking activated header/body check rules in log messages

Is there any way to know which entry for header_checks and body_checks caused a message to be rejected?

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 [182]


will log "Message content rejected [182]" 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?

http://www.seaglass.com/postfix/faq.html#vrtcmd

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. [3]

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.


Delivery agents

  • 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 virtual Postfix daemon.


master.cf

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 postmap.

Content filtering

  • 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.

Restrictions

SMTP restrictions

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 mtpd_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. [4] 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 smtpd_relay_restrictions. That


Access Restriction Description
permit_mynetworks permits the current recipient if the connecting client is within the networks specified by $mynetworks. It is this restriction that gives your own clients relay access. If the connecting client is not within $mynetworks, the next item in the restriction list will be evaluated.
reject_unauth_destination 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_unlisted_sender 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 smtpd_reject_unlisted_sender

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. [5]

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; [5]

References


Official Documentation

Authentication

Unsorted

Research and possibly implement