Learn Mailserver - Aliases, Forwarding & Basic Mailing Lists

#Introduction

Mailboxes have been working since episode 9. Now we learn to manage addresses: not all email has to land directly in an inbox. There are addresses like info@, sales@, or webmaster@ that only need to be forwarded to the right person — that's the job of aliases and forwarding.

This episode dissects system aliases and virtual aliases, how to write forwarding, bounce handling for unknown recipients, and the basics of mailing lists. By the end of the episode, you'll be able to point one address at many destinations without creating a single new mailbox.

#Aliases vs Virtual Aliases

There are two layers of aliases in Postfix that are often confused:

System aliases (/etc/aliases) — apply to local users, used for addresses like root and postmaster. Processed before virtual maps.
Virtual aliases (virtual_alias_maps) — apply to virtual domains, and are very flexible: one address can forward to several destinations at once, including to other domains.

The rule of thumb: for all your virtual domain addresses, use virtual aliases. System aliases are enough for internal machine matters like root.

#System Aliases

The /etc/aliases file contains name: destination mappings. Here are the built-in examples you must adjust:

plaintext

postmaster: root
root: admin@example.com

Every change to /etc/aliases must be recompiled before it takes effect:

Recompile aliases

sudo newaliases

newaliases builds the aliases.db database file that Postfix actually reads. Forgetting to run it is one of the reasons "the alias doesn't work".

#Forwarding with Virtual Alias Maps

For virtual domains, Postfix reads virtual_alias_maps from a file or MySQL. Enable the file-based map first:

Enable virtual_alias_maps

sudo postconf -e 'virtual_alias_maps = hash:/etc/postfix/virtual'
sudo postconf -e 'virtual_alias_domains = example.com'

Fill in /etc/postfix/virtual:

plaintext

info@example.com     admin@example.com
sales@example.com    admin@example.com, budi@example.com
webmaster@example.com  webmaster@other-domain.com

Note the second line: one address can forward to several destinations at once — this is the basis of forwarding and mini mailing lists. Compile the map and reload:

Compile the virtual map

sudo postmap /etc/postfix/virtual
sudo postfix reload

postmap converts the text file into a hash database that Postfix reads. Test the lookup:

Test alias resolution

postmap -q info@example.com hash:/etc/postfix/virtual
postmap -q sales@example.com hash:/etc/postfix/virtual

The first line outputs admin@example.com; the second outputs two separate addresses. If it's still empty, check the file syntax and make sure postmap was run.

#Bounces and Unknown Recipients

When email arrives at an address with no mailbox and no alias entry, Postfix rejects it with a bounce status (5xx). This is correct and important behavior: unknown recipients that are silently swallowed would be exploited by spammers to "plant" addresses.

Legitimate bounces appear in the log as status=bounced with a message like User unknown in virtual alias table or Recipient address rejected. Don't be afraid of bounces — what's wrong is receiving email and not reporting anything.

To keep quotas in check, Postfix also has virtual_mailbox_limit, which caps the size of each message to a virtual domain:

Limit virtual message size

sudo postconf -e 'virtual_mailbox_limit = 51200000'

51200000 bytes (50 MB) is enough for most organizations. Further quota policies are covered in episode 11.

#Basic Mailing Lists

Multi-destination aliases already form a simple mailing list: pengumuman@example.com forwarding to dozens of members. For that scale, just add a line to /etc/postfix/virtual:

plaintext

pengumuman@example.com  admin@example.com, budi@example.com, siti@example.com

The limitation of this approach: any recipient rejected by another server triggers a bounce that can flood the queue. The correct production pattern is verp (variable envelope return path) and deduplication — tasks best handed to real mailing list software like Mailman or Sympa. For the basic needs of a small organization, multi-destination aliases are more than adequate.

#A Clean Address Strategy

A few habits that keep the address architecture healthy:

Always provide postmaster@example.com — required by the SMTP standard and used by other servers to report problems.
Avoid unlimited "chained" aliases (alias pointing to alias pointing to alias) — limit the depth to prevent loops.
Audit periodically with postmap -q to make sure all addresses your clients use are still valid.

Tip

Use mailq to inspect the queue when bounces pile up. A single dead destination address can hold up hundreds of messages. Find the status=bounced pattern in the logs, remove or fix the recipient, then use postsuper -d to clean the queue.

#Conclusion

Episode 10 is done. Key takeaways:

System aliases (/etc/aliases + newaliases) for local matters; virtual aliases for domains.
virtual_alias_maps can forward one address to many destinations at once.
Bouncing unknown recipients is correct behavior, not a bug.
virtual_mailbox_limit keeps message sizes under control.
Multi-destination aliases suffice for basic mailing lists; large scale needs dedicated software.

Addresses are managed. In episode 11 we fence in the storage: Quota & Mailbox Management — limiting space per user, rejecting email when the mailbox is full, and maintaining folders with doveadm. See you in episode 11!