Access Management in E-Mail Systems

Access management in email systems is the practice of controlling who may connect to a mail server, who may send through it, and who may read which mailbox. It covers three separate questions that are often treated as one:

1. Who may deliver mail to us? Inbound access, controlled at the SMTP connection by ACLs and blocklists.
2. Who may send mail through us? Outbound access, controlled by SMTP authentication on the submission service.
3. Who may read this mailbox? Mailbox access, controlled by IMAP/POP authentication and per-folder permissions.

Getting the second one wrong is what turns a mail server into a source of abuse. Getting the third one wrong exposes mail; getting the first wrong mostly means more spam in the inbox.

Who may send mail through the server?

The dividing line is the port. Port 25 is for server-to-server transfer and accepts mail for local recipients from anyone; ports 587 and 465 are the submission service, and there authentication is mandatory.

Conflating them is the classic open relay: a server that accepts mail for arbitrary destinations on port 25 without authentication. The relevant controls are:

• SMTP AUTH over TLS only. Credentials must never cross the network in plaintext, which means smtpd_tls_auth_only = yes in Postfix or the equivalent elsewhere.
• A closed relay policy. reject_unauth_destination, or its equivalent, as the terminating rule of the recipient restrictions.
• Sender ownership enforcement. An authenticated user should only be able to use envelope senders they are entitled to, otherwise one compromised account can forge every address in your domain.
• Rate limits per account. A mailbox that suddenly sends 10,000 messages an hour is compromised, and a limit converts that from an outage into a ticket.

How is inbound access controlled?

Inbound access management is decided during the SMTP conversation, before the message body is accepted:

• Connection stage — the client IP address is checked against local allow and deny maps and against DNS blocklists. See IP blacklisting for how those lists work.
• HELO/EHLO stage — the hostname the client presents is checked for syntactic validity and consistency with its reverse DNS.
• Envelope stage — sender and recipient are validated. Rejecting unknown recipients here rather than accepting and bouncing later is what prevents backscatter.
• Content stage — only after all of the above does it make sense to spend CPU on scanning the message.

Allow lists and deny lists: when to use which

A deny list is the default posture for a public mail server: accept from everyone, reject known-bad. It scales to the open internet, and it is what DNSBLs are built for.

An allow list inverts the default and only makes sense where the set of legitimate senders is closed and known:

• Traffic from an application server or monitoring host to an internal relay.
• A partner or supplier feed that must never be blocked, protected by an explicit entry above the blocklist checks.
• Administrative access to a management interface.

The failure modes differ. A stale deny list lets spam through, which is annoying. A stale allow list silently bypasses every check beneath it, which is how an entry added years ago for a since-decommissioned partner becomes a hole. Allow list entries should therefore be as narrow as possible, dated, and reviewed.

What about mailbox access?

Mailbox access is a different system with different failure modes. It is governed by IMAP or POP authentication and, for shared and delegated mailboxes, by per-folder ACLs.

Two practices matter more than the rest. First, shared mailboxes such as info@, sales@ or abuse@ should have their access grants reviewed when people change roles, since delegation is added far more often than it is removed. Second, legacy IMAP and SMTP clients that cannot do modern authentication force the use of app passwords — those are full-strength credentials with no second factor, and they are what credential-stuffing attacks target.

What should be monitored?

Access management is not a configuration you finish. The things worth alerting on are:

• Authentication failures per account and per source IP, to catch credential stuffing before it succeeds.
• Successful authentication from unexpected geographies or at unusual hours.
• Outbound volume per authenticated account against its normal baseline.
• Rejected relay attempts, which indicate someone is probing the server.
• Changes to allow lists and to mailbox delegations, which should be rare enough that each one is worth reading.