Email Architecture - Learning Module

Loading content...

0/240

Email Addressing

The Language of Email Destinations

The email address is perhaps the most recognized identifier in digital communication—a compact string that uniquely identifies a mailbox among billions worldwide. From the simple user@example.com to complex organizational hierarchies and internationalized addresses containing non-Latin characters, email addressing encompasses a rich set of standards, patterns, and practices that have evolved over five decades.

Email addressing goes far beyond simple username-and-domain combinations. It encompasses address syntax standards, domain verification, alias systems, forwarding mechanisms, catch-all configurations, subaddressing (plus-addressing), virtual domain hosting, and the increasingly important internationalization of addresses for global accessibility.

Mastering email addressing is essential for mail server administrators, developers building email-integrated applications, security professionals analyzing email authenticity, and anyone responsible for organizational email infrastructure. Understanding how addresses work enables proper configuration, troubleshooting, anti-spoofing implementation, and user experience optimization.

What You Will Learn

By completing this page, you will master email address syntax including edge cases and international formats, understand how domains are verified and routed, implement aliases and forwarding correctly, configure virtual domains for multi-tenant hosting, and leverage advanced addressing features like subaddressing and recipient rewriting.

Email Address Syntax and Structure

The email address format was established in the earliest days of networked email and standardized through successive RFCs. Understanding the complete syntax specification is crucial for validation, parsing, and security.

Basic Format:

local-part@domain

The @ symbol separates two distinct components:

Local Part: Identifies a specific mailbox within the domain
Domain: Identifies the mail system responsible for the mailbox

Formal Specification (RFC 5321, RFC 5322):

The standards define precise rules for valid addresses:

Local Part Rules

•Allowed Characters — Letters (a-z, A-Z), digits (0-9), and special characters: ! # $ % & ' * + - / = ? ^ _ ` { | } ~
•Dot (.) — Allowed but not at start or end, and not consecutively ("..")
•Maximum Length — 64 characters (RFC 5321)
•Case Sensitivity — Technically case-sensitive per RFC, but most servers treat as case-insensitive
•Quoted Strings — Quoted local parts ("john doe"@example.com) allow spaces and special characters, but rarely used
•Comments — Deprecated feature allowing comments in parentheses, largely ignored today

Domain Part Rules

•Format — Standard DNS hostname format (labels separated by dots)
•Characters — Letters (a-z, case insensitive), digits (0-9), hyphens (-)
•Labels — Each label 1-63 characters, not starting or ending with hyphen
•Maximum Length — 253 characters total (254 including null terminator)
•Top-Level Domain — Must exist in DNS root zone (com, org, net, country codes)
•IDN (Internationalized Domain Names) — Non-ASCII domains encoded as Punycode (xn--prefix)

Email Address Validity Examples
Address	Valid?	Notes
user@example.com	✅ Yes	Standard format
user.name@example.com	✅ Yes	Dots allowed in local part
user+tag@example.com	✅ Yes	Plus addressing (subaddressing)
user@subdomain.example.com	✅ Yes	Subdomains allowed
.user@example.com	❌ No	Local part cannot start with dot
user..name@example.com	❌ No	Consecutive dots not allowed
user@.example.com	❌ No	Domain cannot start with dot
@example.com	❌ No	Local part required
user@	❌ No	Domain required
user@example	⚠️ Maybe	Valid syntax, but no MX typically
"john doe"@example.com	✅ Yes	Quoted local part (rare)
user@例え.jp	✅ Yes	IDN (becomes xn-- encoded)

Address Validation Best Practices:

Properly validating email addresses is notoriously difficult. Many regex patterns reject valid addresses or accept invalid ones.

Recommended Approach:

Basic Format Check: Ensure presence of exactly one @ separating non-empty parts
Domain Validation: Verify domain has valid DNS syntax
MX Verification (optional): Check domain has MX or A records
Deliverability Test (optional): Send verification email

What NOT to Do:

Reject addresses with + (breaks subaddressing)
Reject long local parts (up to 64 chars is valid)
Require specific TLDs (new gTLDs constantly added)
Use overly strict regex (RFC 5322 regex is extremely complex)

// Simple, practical email validation
function isValidEmail(email) {
    // Basic structure check - not RFC-complete but practical
    const basicPattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
    if (!basicPattern.test(email)) return false;
    
    const [localPart, domain] = email.split('@');
    if (localPart.length > 64) return false;
    if (domain.length > 253) return false;
    
    return true;
}

Domain Handling and Mail Routing

The domain portion of an email address determines where mail should be delivered. Understanding domain handling is essential for mail server configuration and troubleshooting.

Domain Classification:

From an MTA's perspective, domains fall into categories:

Domain Types in Mail Systems

•Local Domain — Domains for which the MTA accepts mail and performs local delivery. Mail to these domains is delivered to local mailboxes.
•Relay Domain — Domains for which the MTA accepts mail and forwards to another server. Common for backup MX or internal relaying.
•Virtual Domain — Domains hosted on a multi-tenant system where mailboxes don't correspond to system users. Common in hosting environments.
•Remote Domain — Any domain not in the above categories. Mail is routed via MX lookup and standard SMTP delivery.

Postfix Domain Configuration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# /etc/postfix/main.cf - Domain Configuration
 
# Primary hostname and domain
myhostname = mail.example.com
mydomain = example.com
 
# Local delivery destinations (traditional Unix mailboxes)
mydestination = $myhostname, localhost.$mydomain, localhost
 
# Virtual mailbox domains (database-backed, no system users)
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-domains.cf
 
# Relay domains (forward to another server)
relay_domains = internal.example.com
 
# Transport maps (custom routing per domain)
transport_maps = hash:/etc/postfix/transport
 
# /etc/postfix/transport - Custom Domain Routing
internal.example.com    smtp:[internal-mail.example.com]:25
legacy.example.com      relay:[legacy-server.example.com]
partner.com             smtp:partner-mx.example.com
 
# /etc/postfix/mysql-virtual-domains.cf
user = postfix
password = secret
hosts = 127.0.0.1
dbname = mailserver
query = SELECT 1 FROM virtual_domains WHERE name='%s' AND active=1

DNS Requirements for Email Domains:

Properly configuring DNS is fundamental to email delivery. Each domain handling email needs:

MX Records (Mail Exchanger):

example.com.     IN MX   10 mail1.example.com.
example.com.     IN MX   20 mail2.example.com.

A/AAAA Records for Mail Servers:

mail1.example.com.  IN A      198.51.100.10
mail2.example.com.  IN A      198.51.100.11
mail1.example.com.  IN AAAA   2001:db8::10

Reverse DNS (PTR Records):

10.100.51.198.in-addr.arpa.  IN PTR  mail1.example.com.

Authentication Records (TXT):

example.com.                   IN TXT  "v=spf1 mx -all"
default._domainkey.example.com IN TXT  "v=DKIM1; k=rsa; p=..."
_dmarc.example.com             IN TXT  "v=DMARC1; p=reject; rua=..."

Common DNS Issues:

Issue	Symptom	Solution
Missing MX	Delivery fails or goes to A record	Add MX records
MX points to CNAME	Some servers reject	MX must point to A/AAAA
Missing reverse DNS	Rejected by many servers	Add PTR record
SPF missing/wrong	Spam classification	Correct SPF record
DKIM misconfigured	Authentication fails	Verify key matches

Aliases and Distribution Lists

Email aliases provide alternative addresses that deliver to existing mailboxes or expand to multiple recipients. They're fundamental to managing email in organizations of any size.

Types of Aliases:

Alias Categories

•Simple Alias — One address maps to one mailbox. Example: webmaster@example.com → admin@example.com
•Multi-Target Alias — One address maps to multiple mailboxes. Example: sales@example.com → alice@, bob@, carol@
•External Alias — Maps to addresses in other domains. Example: forward@example.com → user@gmail.com
•Pipe Alias — Delivers to a program rather than mailbox. Example: tickets@example.com → |/usr/bin/ticket-parser
•File Alias — Appends to a file. Example: archive@example.com → /var/mail/archive
•Include Alias — References file containing list of addresses. Example: team@ → :include:/etc/mail/team-list

Alias Configuration Examples
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# /etc/aliases - System-wide aliases (Postfix, Sendmail)
 
# Required system aliases (RFC 2142)
postmaster:     root
abuse:          root
webmaster:      admin
hostmaster:     admin
 
# Simple redirects
admin:          alice
info:           alice, bob
 
# External forwarding
forward-me:     external-user@gmail.com
 
# Distribution list via include file
engineering:    :include:/etc/mail/lists/engineering
 
# Pipe to program
support-tickets: "|/usr/local/bin/process-ticket"
 
# Multiple recipients with external addresses
sales:          alice@example.com, bob@example.com, sales-archive@backup.com
 
# Null delivery (discard)
blackhole:      /dev/null
 
# After editing, run: newaliases (or: postalias /etc/aliases)
 
 
# /etc/mail/lists/engineering - Include file format
alice@example.com
bob@example.com
carol@example.com
# Comments start with #
dave@example.com

Virtual Aliases (Domain-Agnostic):

For virtual domain hosting, Postfix uses virtual alias maps instead of system aliases:

# /etc/postfix/virtual

# Format: source-address    destination(s)

# Simple virtual aliases
info@domain1.com           john@domain1.com
info@domain2.com           jane@domain2.com

# Cross-domain forwarding
old-address@domain1.com    new-address@domain2.com

# Catch-all (all unmatched for domain)
@domain3.com               admin@domain3.com

# Distribution across domains
all-staff@company.com      alice@sales.company.com, bob@tech.company.com

Distribution Lists vs. Group Mailboxes:

Feature	Alias/Distribution List	Shared Mailbox
Replies go to	Original sender	Shared mailbox
Storage	Individual mailboxes	Single shared store
Sent mail appears	In each user's Sent	Optional shared Sent
Permissions	N/A	Granular (often)
Use case	Announcements, forwarding	Collaborative response

Alias Loops and Expansion Limits

Alias configurations can create forwarding loops (A→B→A) which MTAs detect and break. They also impose expansion limits—a single message to a list of 10,000 recipients creates significant load. Large lists should use mailing list managers (Mailman, Sympa) rather than simple aliases.

Email Forwarding: Mechanisms and Implications

Email forwarding redirects messages to different addresses, but this seemingly simple operation has profound implications for authentication, delivery, and troubleshooting.

Forwarding Mechanisms:

How Forwarding is Implemented

•Alias-Based Forwarding — Address in alias table points to external address. MTA delivers to external domain via normal SMTP.
•.forward File (Unix) — User-controlled file in home directory specifying forwarding destinations. Processed by MDA during delivery.
•Sieve Filter Forwarding — User-created Sieve rules with 'redirect' action. More sophisticated (conditional forwarding, keeping copy).
•Server-Side Rules — IMAP server or webmail rules forwarding mail (Exchange rules, Gmail filters).
•Client-Side Forwarding — MUA configured to auto-forward. Requires client running.

The SPF/DKIM/DMARC Forwarding Problem:

Forwarding breaks email authentication in subtle but significant ways:

SPF Breaks:

Original: alice@sender.com → bob@intermediate.com
Forwarded: intermediate.com forwards → carol@final.com

At final.com:
- Envelope-From: often unchanged (alice@sender.com)
- Connecting IP: intermediate.com's server
- SPF check: Does intermediate.com's IP pass sender.com's SPF?
- Result: FAIL (intermediate.com isn't authorized for sender.com)

DKIM Usually Survives: If the forwarding server preserves headers and body unchanged, DKIM signatures remain valid. Modifications (footers, subject prefixes) break DKIM.

DMARC Impact: With SPF failing and DKIM potentially broken, DMARC checks fail, even for legitimate forwarded mail.

Solutions to Forwarding Authentication Issues:

SRS (Sender Rewriting Scheme): Rewrites envelope-From when forwarding:

Original: alice@sender.com
Rewritten: SRS0=hash=tt=sender.com=alice@intermediate.com

Now SPF checks intermediate.com's authorization for intermediate.com, which passes. Bounces route back correctly via SRS decoding.

ARC (Authenticated Received Chain): RFC 8617 extension where forwarding servers add cryptographic seals attesting to authentication status when received. Receiving servers can trust ARC-validated chains from known forwarders.

ARC-Seal: i=1; cv=none; d=intermediate.com; s=arc; ...
ARC-Message-Signature: i=1; d=intermediate.com; ...
ARC-Authentication-Results: i=1; intermediate.com;
    dkim=pass header.d=sender.com;
    spf=pass smtp.mailfrom=sender.com

Best Practice: Avoid Blind Forwarding

When possible, use 'keep a copy' forwarding (Sieve: redirect :copy) rather than pure forwarding. This preserves the original delivery while also forwarding. If forwarding breaks, at least messages remain in the original mailbox.

Subaddressing: Plus Addressing and Tag Extensions

Subaddressing (commonly called plus addressing or tag addressing) allows users to create dynamic address variations that all deliver to the same mailbox. The most common format uses a plus sign (+) separator:

user+tag@example.com → user@example.com (same mailbox)

How Subaddressing Works:

Sender sends to john+newsletter@example.com
MTA receives message for john+newsletter@example.com
MTA strips +tag portion (configurable delimiter)
Delivers to john@example.com mailbox
Original recipient (with +tag) preserved in headers
User can filter based on tag

Subaddressing Use Cases

•Automatic Filtering — Give each service a unique tag: amazon+orders@example.com, github+notifications@example.com. Filter into folders based on envelope recipient.
•Spam Tracking — When signups start receiving spam, the tag reveals which service leaked or sold your address.
•Service Identification — Quickly identify email context from the address in subject/headers.
•Account Organization — Separate personal, work, and project correspondence via tagged addresses.
•Testing and Development — Create many test accounts from a single mailbox: test+user1@, test+user2@, etc.

Configuring Subaddressing in Postfix
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
# /etc/postfix/main.cf
 
# Enable plus addressing for local delivery
# recipient_delimiter specifies the separator character
recipient_delimiter = +
 
# For virtual mailbox hosting:
# Postfix strips the +tag before virtual mailbox lookup
# virtual_mailbox_maps lookup for "user@domain" matches "user+tag@domain"
 
 
# Sieve filter using subaddress for sorting (Dovecot)
# ~/.dovecot.sieve
 
require ["envelope", "subaddress", "fileinto"];
 
# Use detail (the +tag part) for folder filing
if envelope :detail "to" "shopping" {
    fileinto "Shopping";
    stop;
}
 
if envelope :detail "to" "newsletters" {
    fileinto "Newsletters";
    stop;
}
 
if envelope :detail "to" "banking" {
    fileinto "Finance";
    stop;
}
 
# Alternative: Use wildcard matching on full address
if envelope :matches "to" "*+*@example.com" {
    # Extract tag and file to folder named after tag
    # (More complex Sieve with variables extension)
}

Alternative Delimiters:

While + is most common, some systems use different delimiters:

Delimiter	Example	Common Provider
	user+tag@domain	Gmail, Outlook, most modern systems
	user-tag@domain	Some legacy systems
.	user.tag@domain	Some configurations (conflicts with normal dots)
=	user=tag@domain	Rare

Limitations:

Some websites incorrectly reject addresses with + as invalid
Spammers may strip +tags when selling addresses
Users forget which tags they used for which services
Not universally supported (though major providers all support)

Gmail's Dot Tolerance

Gmail ignores dots in the local part: john.doe@gmail.com, johndoe@gmail.com, and j.o.h.n.d.o.e@gmail.com all deliver to the same mailbox. This is Gmail-specific behavior, not a standard. Do not assume other providers work this way.

Virtual Domains and Multi-Tenant Hosting

Virtual domain hosting enables a single mail server to handle email for multiple independent domains, each with its own users, without requiring system accounts for each mailbox. This architecture powers email hosting providers, managed services, and organizations with multiple domains.

Virtual vs. Local (System) Domains:

Aspect	Local Domain	Virtual Domain
User Storage	System accounts (/etc/passwd)	Database/LDAP records
Home Directory	Per-user home directories	Configurable (often vhost-style)
Shell Access	Potentially available	Not required
Quota Management	System quotas	Application-level
Scalability	Limited by OS user limits	Virtually unlimited
Administration	Unix commands	Application/database
Multi-domain	Complex	Native

Virtual Domain Configuration (Postfix + Dovecot)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
# /etc/postfix/main.cf - Virtual Mailbox Configuration
 
# Virtual mailbox domain list (from database)
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-domains.cf
 
# Virtual mailbox locations (from database)  
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailboxes.cf
 
# Virtual aliases (from database)
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-aliases.cf
 
# Base directory for virtual mailboxes
virtual_mailbox_base = /var/vmail
 
# Virtual user/group for mailbox ownership
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_minimum_uid = 100
 
# Delivery via Dovecot LMTP
virtual_transport = lmtp:unix:private/dovecot-lmtp
 
 
# /etc/postfix/mysql-virtual-domains.cf
user = postfix_user
password = database_password
hosts = 127.0.0.1
dbname = mailserver
query = SELECT name FROM virtual_domains WHERE name='%s' AND active=1
 
# /etc/postfix/mysql-virtual-mailboxes.cf
query = SELECT CONCAT(domain, '/', local_part, '/') FROM virtual_users 
        WHERE email='%s' AND active=1
 
# /etc/postfix/mysql-virtual-aliases.cf
query = SELECT destination FROM virtual_aliases WHERE source='%s' AND active=1
 
 
# Database schema example
CREATE TABLE virtual_domains (
    id INT AUTO_INCREMENT PRIMARY KEY,
    name VARCHAR(255) NOT NULL UNIQUE,
    active BOOLEAN DEFAULT TRUE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
 
CREATE TABLE virtual_users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    domain_id INT REFERENCES virtual_domains(id),
    email VARCHAR(255) NOT NULL UNIQUE,
    local_part VARCHAR(64) NOT NULL,
    domain VARCHAR(255) NOT NULL,
    password VARCHAR(255) NOT NULL,  -- Encrypted
    quota_bytes BIGINT DEFAULT 1073741824,  -- 1GB
    active BOOLEAN DEFAULT TRUE,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
 
CREATE TABLE virtual_aliases (
    id INT AUTO_INCREMENT PRIMARY KEY,
    domain_id INT REFERENCES virtual_domains(id),
    source VARCHAR(255) NOT NULL,
    destination VARCHAR(255) NOT NULL,
    active BOOLEAN DEFAULT TRUE
);

Virtual Mailbox Directory Structure:

/var/vmail/
├── domain1.com/
│   ├── alice/
│   │   ├── Maildir/
│   │   │   ├── cur/
│   │   │   ├── new/
│   │   │   └── tmp/
│   │   └── sieve/
│   └── bob/
│       └── Maildir/
├── domain2.com/
│   ├── user1/
│   │   └── Maildir/
│   └── user2/
│       └── Maildir/
└── domain3.net/
    └── ...

Multi-Tenant Isolation:

Virtual hosting must ensure domain isolation:

Users can only access their own domain's address book
Quotas apply per-user and potentially per-domain
Administrative access is domain-scoped
DKIM keys are per-domain
Logs can be filtered by domain for privacy

Catch-All Addresses and Default Handling

A catch-all (or default) address receives all mail sent to undefined addresses within a domain. While sometimes useful, catch-all configurations carry significant implications.

Catch-All Configuration:

# Virtual alias catch-all
@example.com    admin@example.com

# This means: any address at example.com not otherwise defined
# delivers to admin@example.com

Legitimate Use Cases:

Valid Catch-All Applications

•Migration Periods — Ensure no mail is lost during migration when addresses may not be fully configured yet.
•Small Organizations — Tiny organizations where one person handles all inquiries regardless of address used.
•Domain Monitoring — Track what addresses people attempt to use (before deciding whether to create them).
•Historical Address Preservation — Accept mail to addresses that once existed but were retired.

Catch-All Problems

•Massive Spam Reception — Spammers generate random addresses; catch-all receives all of them. Volume can be overwhelming.
•Directory Harvest Attacks — Attackers enumerate valid vs. invalid addresses; catch-all makes all addresses appear valid.
•Backscatter Prevention Conflict — Cannot reject unknown recipients at SMTP time since all recipients are accepted.
•NDR Spam — Bounce messages for spam sent to random addresses flood the catch-all recipient.
•Resource Consumption — Processing spam to nonexistent addresses wastes server resources.

Alternatives to Catch-All:

Explicit Address Creation: Create specific addresses/aliases for each use case. More work upfront but cleaner long-term.

Subaddressing: Use plus addressing (admin+anything@example.com). Provides flexibility without catch-all risks.

Reject Unknown at SMTP Time:

smtpd_reject_unlisted_recipient = yes

Reject invalid addresses during SMTP conversation. Prevents spam to nonexistent addresses from entering the system.

Redirect to Rejection Address: Catch-all to an address that auto-replies with "address not found" rather than accepting silently.

Catch-All with Aggressive Filtering: If catch-all is required, apply extra scrutiny (spam scoring, rate limiting) to messages to catch-all recipients.

Security Advisory

Catch-all configurations are generally discouraged unless absolutely necessary. The spam amplification effect usually outweighs any convenience benefit. Default to rejecting unknown recipients at SMTP time for better security and resource management.

Internationalized Email Addresses (EAI)

Email Address Internationalization (EAI), defined in RFC 6530 and related standards, extends email to support non-ASCII characters in both the local part and domain part of addresses. This enables billions of people to use email addresses in their native scripts.

Examples of Internationalized Addresses:

пользователь@почта.рф            (Russian Cyrillic)
用户@邮箱.中国                     (Chinese)
उपयोगकर्ता@डाक.भारत              (Hindi Devanagari)
utilisateur@courriel.québec       (French with accent)
δοκιμή@παράδειγμα.δοκιμή          (Greek)

EAI Technical Components

•SMTPUTF8 Extension (RFC 6531) — SMTP extension signaling server supports UTF-8 in addresses. Required path from submission through delivery must all support it.
•UTF-8 Headers (RFC 6532) — Allows UTF-8 in message headers (From, To, Subject, etc.). Replaces RFC 2047 encoding for many cases.
•Internationalized Domain Names (RFC 5891 - IDNA) — Domains with non-ASCII characters encoded as Punycode (xn--prefix) in DNS while displayed in native script to users.
•EAI Message Format (RFC 6533) — Delivery status notifications for EAI addresses. Internationalized bounce handling.

How IDN Domain Encoding Works:

User sees:     用户@邮箱.中国
DNS query:     用户@xn--5nxu16j.xn--fiqs8s

Conversion (Punycode/IDNA):
邮箱 → xn--5nxu16j
中国 → xn--fiqs8s

EAI Adoption Challenges:

Challenge	Description
Limited Server Support	Many MTAs don't support SMTPUTF8 yet
Path Requirement	Entire delivery path must support EAI
Fallback Complexity	Downgrade to ASCII addresses for incompatible systems
Application Support	Many applications incorrectly validate/reject EAI addresses
User Experience	Entering addresses in different scripts varies by keyboard/OS
Homograph Attacks	Visual spoofing using similar-looking characters from different scripts

Current Status (2026):

Major providers (Gmail, Outlook.com) support receiving EAI mail. Sending EAI addresses (using them as the From address) has more limited support. Adoption is growing, especially in regions with non-Latin scripts.

Configuring EAI Support (Postfix):

# /etc/postfix/main.cf
smtputf8_enable = yes
smtputf8_autodetect_classes = sendmail, verify

Testing EAI Support

Before deploying EAI addresses in production, test thoroughly. Send to and from EAI addresses, verify display in various clients, and confirm bounces work correctly. Many integration points may have issues with non-ASCII characters.

Address Rewriting and Masquerading

Address rewriting modifies email addresses as messages pass through the mail system. This can normalize addresses, hide internal structure, or implement special routing.

Types of Rewriting:

Common Rewriting Scenarios

•Masquerading — Hide internal domains: user@internal.corp.com → user@corp.com. Presents a unified external identity.
•Canonical Mapping — Normalize addresses: john.doe@corp.com → jdoe@corp.com. Maintains consistency.
•Sender Rewriting (SRS) — For forwarding: user@original.com → SRS0=..=original.com=user@forwarder.com. Fixes SPF for forwarded mail.
•Recipient Rewriting — Route to internal systems: public@corp.com → internal-queue@app.corp.com. Abstract internal from external.
•Domain Renaming — Handle mergers/rebrandings: user@oldcompany.com → user@newcompany.com.

Postfix Address Rewriting Configuration
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
# /etc/postfix/main.cf - Address Rewriting
 
# ===== SENDER REWRITING =====
 
# Masquerade (hide subdomain in From)
masquerade_domains = corp.example.com
masquerade_classes = envelope_sender, header_sender
masquerade_exceptions = root, postmaster
 
# This rewrites:
# alice@dept.corp.example.com → alice@corp.example.com
 
 
# Canonical sender rewriting (general transformation)
sender_canonical_maps = hash:/etc/postfix/sender_canonical
 
# /etc/postfix/sender_canonical
alice           alice.johnson@example.com
@old.example.com        @example.com
 
 
# SMTP-time sender rewriting (for outbound only)
smtp_generic_maps = hash:/etc/postfix/generic
 
# /etc/postfix/generic
alice@localhost         alice.johnson@example.com
root@localhost          sysadmin@example.com
 
 
# ===== RECIPIENT REWRITING =====
 
# Canonical recipient rewriting
recipient_canonical_maps = hash:/etc/postfix/recipient_canonical
 
# /etc/postfix/recipient_canonical
old-list@example.com    new-list@example.com
former-employee         current-employee@example.com
 
 
# ===== SRS (Sender Rewriting Scheme) =====
# Implemented via policy service or milter
 
# Using PostSRSd:
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient,header_recipient

Rewriting Considerations:

Preserve Original for Replies: Rewriting the header From/Reply-To affects where replies go. Rewriting only the envelope affects routing/authentication but preserves reply path.

Impact on DKIM: Rewriting the From header invalidates DKIM signatures that include the From header. Consider re-signing after rewriting.

Logging/Tracking: Document rewrite rules thoroughly. When troubleshooting delivery, ensure you can trace both original and rewritten addresses.

Transitive Mappings: Be cautious of rewrite chains: A→B, B→C. Most systems don't apply rewrites recursively, but some do, potentially creating loops.

Summary: Mastering Email Addressing

We have thoroughly explored email addressing—from basic syntax through advanced configurations powering complex multi-domain environments. Let's consolidate this knowledge:

Key Takeaways

•Email addresses follow RFC 5321/5322 syntax — Local part (64 chars max) @ domain (253 chars max) with specific allowed characters.
•Domain handling determines mail routing — Local, virtual, relay, and remote domains receive different treatment by MTAs.
•DNS is foundational to email addressing — MX, A/AAAA, PTR, and TXT records enable routing and authentication.
•Aliases provide address flexibility — Simple redirects, distribution lists, and programmatic delivery via alias configuration.
•Forwarding impacts authentication — SPF breaks on forwarding; SRS and ARC provide solutions.
•Subaddressing enables user-controlled organization — Plus addressing creates unlimited variations for filtering and tracking.
•Virtual domains power multi-tenant hosting — Database-backed configuration scales to unlimited domains and users.
•Catch-all is generally discouraged — Spam amplification usually outweighs convenience; reject unknown recipients instead.
•EAI expands email globally — Internationalized addresses support native scripts; adoption is growing.
•Address rewriting normalizes and hides structure — Masquerading, canonical mapping, and SRS modify addresses in transit.

Module Complete:

With this page, you have completed Module 1: Email Architecture. You now possess comprehensive knowledge of:

Email system components and their interactions
Mail server types, software, configuration, and operations
User agent categories, protocols, and security
Complete mail flow from sender to recipient
Email addressing in all its complexity

The next modules will dive deep into specific email protocols (SMTP, POP3, IMAP) and advanced topics like email security.

Module Complete

Congratulations! You have mastered Email Architecture—the foundational knowledge underpinning all email system design, configuration, and troubleshooting. You're now prepared to explore email protocols in depth and implement production-grade email infrastructure.