Flashcards in Sendmail Deck (18):


Mail User Agent, e.g. a mail client program



Mail Transfer Agent, e.g. sendmail


sendmail began as an ___

attempt to unify chaos in a world without standards nor compatible protocols


sendmail's design principles:

Accept that one programmer is finite
Don't redesign (existing) user agents
Don't redesign the local mail store
Make sendmail adapt to the World, not vice versa
Change as little as possible
Think about reliability early


Wave 1 of sendmail's history (aka delivermail) had one job:

forward mail from one program to another


All configuration in delivermail was compiled in and based only on ___

special characters (e.g. @ : !) in each address, which had precedence ordering


Two characteristics of Wave 2 of sendmail's history (v3, 4, & 5)

re-wrote addresses for cross-network compatibility

SMTP was drafted, implemented, and included in sendmail itself


Wave 3 of sendmail's history is characterized by ___

an abundance of open-source, incompatible versions of sendmail


Wave 4 of sendmail's history involved the author ___ and ___

returning to Berkeley to unify internal subdomain addressing

studying the features of popular sendmail clones to guide development


Wave 5 of sendmail's history brought ___

a newly created company and commercial product
SMTP authentication
site security


Design Decisions in sendmail

Config file syntax
Rewriting rules
Using rewriting for parsing
Embedding SMTP & Queuing in sendmail
Queue implementation
Accepting and fixing bogus input
Config & the use of M4


Design decision and impact: Config file syntax

- file became longer and less comprehensible over time
- did not anticipate large install base, thus did not change obscure syntax early
- while sendmail was quick to respond to SMTP changes, config file readability suffered


Design decision and impact: Rewriting rules

- regexes would be too difficult
- scanning phase produced tokens for pattern match/replace
- rules needed to allow forwarding between networks with different addressing standards


Design decision and impact: Using rewriting for parsing

- conventional grammar-based parsing techniques would not have worked because of the amount of look-ahead required
- relatively easy to the patterns recognize and fix broken input


Design decision and impact: Embedding SMTP & Queuing in sendmail

- not embedding SMTP would have required richer protocols for inbound and outbound mail
- author would be inclined to leave queuing in today but move both sides of SMTP out, primarily for security reasons


Design decision and impact: Queue implementation

- each job had a control file & data file
- processed by reading all control files, storing in memory, and sorting
- broke down around 10k message in the queue
- DBs were still not great tech; memory too low and processing too expensive back then for a separate daemon
- message headers stored in queue control files seemed reasonable to address rewriting then, but not important now
- now, rewriting is rare and a source of errors


Design decision and impact: Accepting and fixing bogus input

- fixing things (like no From: header) allowed most mail to be sent at the time, but allowed broken clients to survive longer


Design decision and impact: Configuration & the use of M4

- m4 macro processor included with Unix
- sendmail 6 had a complete config file rewrite to use more of the m4 processor power
- now config file became too difficult to understand; essentially assembly code
- raw format config file was really a programming language, while m4 format was declarative