Skip to content

Postfix

Kolab uses Postfix as Mail Transfer Agent (MTA), to send and receive email.

Postfix has the following entry points:

  • Port 25 (SMTP): Email from other email servers is delivered here.
  • Port 587 (Submission): Email clients submit email here for delivery to other email addresses (local or remote).
  • Port 10587 (Internal Submission): Use by e.g. webmail to submit email, and not publicly available.

Postfix is in essence a queue for all email that is being exchanged, both internally and externally. Once a mail is accepted, postfix will hold on to it until it is successfully delivered, to either a remote mail server, or a local mailbox. If a system is temporarily unavailable, postfix will retry periodically until it succeeds.

Internally postfix is configured to route all email through a set of filters:

  • For spam/virus checking and DKIM signing and signature verification all mail is routed through Amavis.
  • For invitation policies, rate-limiting, sender/receipeint access policies, and grey-listing email is filtered through the Kolab API

For inbound email this results in the following:

graph TD
    A[SMTP] -->|Receives Email| B{MTA}
    B --> amavisd
    amavisd -->|Scan Result| B
    subgraph Amavis
    amavisd --> E[SpamAssassin]
    amavisd --> Clamd
    amavisd --> DKIM
    end
    B --> Kolab
    Kolab -->|Filter Result| B
    B ---->|Delivery| IMAP

Postfix maintains multiple queues internally:

  • Active: Email that is going to be delivered.
  • Deferred: Email that failed to be delivered, but is being retried until delivery succeeds.
  • Hold: Email that was place on hold is not automatically retried.

New emails enter the "Active" queue, and will automatically be moved to the Deferred queue when initial delivery fails. Email in the "Hold" queue is not automatically removed and requires administrator interaction.

Invitation policies

Kolab can automatically import iTip invitation updates that are received via mail. This is handled in the form of a mail filter.

Greylisting

Greylisting is a spam-combating technique that initially rejects email from an unknown sender ip. All legitimate MTAs will resubmit email that was rejected initially, but spam senders may not. Please note that this can lead to small delays, which can be problematic with signup codes with a timeout, as employed by various services during signup or even login.

Greylisting rules

Greylisting is implemented according to the recommendations in https://datatracker.ietf.org/doc/html/rfc6647

  • Greylist entries are matched by recipient/sender/sender network.
  • Only information within a timeframe (30 days) is considered.
  • If there is no existing greylist entry a message is deferred.
  • If there is an existing greylist entry that is older than a minimum age (1min), the message is accepted.
  • There is a global whitelist (by sender/sender network), that is automatically managed.
  • A domain is automatically whitelisted if there are 5 or more messages from the same sender/sender network pair, that have passed greylisting.
  • Whitelist entries are purged after an expiry timeframe, if no new messages have matched the whitelist.

Explanation:

  • The 1 min, minimum age protects against spammers that retry immediately, while allowing for relatively quick retries from legitimate sources.
  • Whitelist entries allow the system to learn about legitimate sources, which is reused accross recipients.
  • Whitelist entries are expired to handle sender reuse (a trustworthy source can turn into an untrustworthy one over time).

Rate limiting

Kolab can rate-limit outgoing email on a per-user and per-recipient basis.

Sender/Recipient access policies

The sender and recipient access policies make sure that:

  • Only authenticated local users can submit email
  • Only email for local users is accepted

This is important to prevent the system from being abused to send out spam.

Amavis

Postfix routes all email through amavis for:

  • Spam-checking via Spamassassin
  • Virus-checking via ClamAV
  • DKIM Signing and Signature verification

Note

Spam with a reasonable spam-score is still delievered to the users inbox (prefixed with a Spam marker in the subject). It is then up to the user to configure e.g. SIEVE filters to file all Spam into a Spam folder.