Sendmail

Question 1

MUA

Answer 1

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

Question 2

MTA

Answer 2

Mail Transfer Agent, e.g. sendmail

Question 3

sendmail began as an ___

Answer 3

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

Question 4

sendmail’s design principles:

Answer 4

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

Question 5

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

Answer 5

forward mail from one program to another

Question 6

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

Answer 6

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

Question 7

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

Answer 7

re-wrote addresses for cross-network compatibility

SMTP was drafted, implemented, and included in sendmail itself

Question 8

Wave 3 of sendmail’s history is characterized by ___

Answer 8

an abundance of open-source, incompatible versions of sendmail

Question 9

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

Answer 9

returning to Berkeley to unify internal subdomain addressing

studying the features of popular sendmail clones to guide development

Question 10

Wave 5 of sendmail’s history brought ___

Answer 10

a newly created company and commercial product
SMTP authentication
site security

Question 11

Design Decisions in sendmail

Answer 11

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

Question 12

Design decision and impact: Config file syntax

Answer 12

• 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

Question 13

Design decision and impact: Rewriting rules

Answer 13

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

Question 14

Design decision and impact: Using rewriting for parsing

Answer 14

• 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

Question 15

Design decision and impact: Embedding SMTP & Queuing in sendmail

Answer 15

• 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

Question 16

Design decision and impact: Queue implementation

Answer 16

• 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

Question 17

Design decision and impact: Accepting and fixing bogus input

Answer 17

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

Question 18

Design decision and impact: Configuration & the use of M4

Answer 18

• 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