COMPUTER AND NETWORK
SYSTEM ADMINISTRATION
Summer 1996 - Lesson 19
Sendmail I
A. Introduction
1. RFC 821
- written in 1982 by Jonathan Postel
- describes the commands and functioning of SMTP (Simple Mail
Transfer Protocol)
- the kinds of commands that we are talking about are the commands
that an SMTP delivery agent must use (such as "sendmail")
telnet mu 25 (or "telnet mu smtp")
S: MAIL FROM:
R: 250 OK
S: RCPT TO:
R: 250 OK
S: RCPT TO:
R: ... Addressee unknown
S: VRFY bill
R: ... User unknown
S: DATA
R: 354 Enter mail, end with "." on a line by itself
S: Hi there, how are things going?
S: See ya later, dude.
S: .
R: 250 OK
S: QUIT
2. RFC 822
- written in 1982 by David Crocker
- Standard for the format of ARPA Internet text messages
- defines the syntax and contents of the mail header formats
- what must be in a RETURN-PATH, FROM, SUBJECT, etc.
2. RFC 1123
- written in 1989 by the Internet Engineering Task Force
- a standard that defines the requirements for Internet
host software
- among these are telnet, ftp, and electronic mail
- written for software developers and vendors
- this RFC updates the commands that MUST, and/or SHOULD
exist for an SMTP program to be compliant with the standard
- this part of RFC 1123 is an update of RFC 821
- some of the strategy recommendations for the SMTP:
> there must be timeouts on all activities
> never send error messages in response to error messages
> mail that cannot be immediately sent must be queued and
periodically retried
> the sender must delay retrying a delivery after one attempt
has failed. The retry interval should be at least 30 minutes.
> retries continue until the sender gives up (generally 4-5
days)
- there is a table in the RFC that summarizes the MUSTs, SHOULDs,
and MAYs when writing an SMTP agent
B. Mail systems
1. consist of several components
2. user agents
- these are the user frontend to mail
- a user agent, at a minimum, composes mail and passes it
to a delivery agent
- you could easily write your own user agent using RFC 822
as a guide
- /bin/mail, /usr/ucb/mail, elm, pine, Eudora, etc.
- some user agents have system-wide startup files:
/usr/ucb/mail global is /usr/lib/Mail.rc
- the SunOS 4.x default start-up file has only
set append dot
> append instead of pre-pend messages to mbox
> allow dot on line by itself to end messages
- there are many options
3. transport agents
- the user agents passes the message to a transport agent
- ISO official agent is built on X.400 (a directory service)
book mentions used pretty much only in Europe and by US Govt.)
- UNIX agents built on RFC 821
- "sendmail" is the most popular
- checkered past (read page 456); two main branches:
IDA (Institutionen for Datavetenskap) Sendmail
ftp://uiarchive/cso.uiuc.edu/pub/packages/mail/sendmail
Sendmail V8
ftp://ftp.cs.berkeley.edu/pub/sendmail
- The "out of the box" vendor's version of sendmail
is usually very old, buggy, and a security hole!
(table 21.2, page 458)
- SysAdmin: you will want to install the latest sendmail
you can find! (either IDA or V8)
- runs suid root, is the biggest security hole on the system
- CERT advisory about every six months w/ sendmail
4. delivery agent
- when sendmail on the receiving end gets message, it
turns it over to a local delivery agent to perform
actual delivery
- on UNIX systems this is /bin/mail (the same binary that
is the AT&T user agent)
- thus /bin/mail must run suid root, also
- it has to append the message to the mailbox owned by the user
- to do this /bin/mail assumes the identity of the user
so the owner can read the mail and it can write across
NFS boundaries
- it also creates a lock file so two instances of /bin/mail
won't be writing to the file at the same time
- it retries every 5 seconds for up to 5 minutes
(configurable) before giving up
5. addressing
- route based (relative)
> involves knowing every hop from here to recipient
> Used in older-style UUCP "bang" (=!) addresses:
fsuvax!usfvax!kremlinvax!joe@blob
- location-independent (absolute)
> list only the final destination
- RFC 1123 strongly supports only absolute addressing
> kuncick@cs.fsu.edu
6. mail headers
From <@sed.cs.fsu.edu:kuncick@grep.cs.fsu.edu>
Mon Mar 13 09:54:56 1995
> added by /bin/mail on sed
> the "From " is the key divider between messages
> edit your mailbox and add a couple of line with
"From " and see what happens
> also need a date (or something written beyond the username)
> we're working backwards in time here
> /bin/mail on sed received this from the sendmail on sed
at 9:54:56
Return-Path: <<@sed.cs.fsu.edu:kuncick@grep.cs.fsu.edu>>
> used to send error message back to sender, if necessary
Received: from sed.cs.fsu.edu by nu.cs.fsu.edu with ESMTP (8.6.8.1/31nu)
id JAA17793; Mon, 13 Mar 1995 09:54:55 -0500
> nu is using sendmail version 8.6.8.1
> sed's sendmail received this from nu's sendmail at 9:54:55
> note the -5 hour offset from GMT, this allows you
to compare time stamps from different time zones
> note the queue ID number - JAA17793, this is unique only to
a particular machine (usually kept in /usr/spool/mqueue)
Received: from gatech.edu by sed.cs.fsu.edu with SMTP (8.6.9/56)
id JAA14637; Mon, 13 Mar 1995 09:54:51 -0500
> sed received the message from gatech at 9:54:51
> sed then routed the message to nu because there is no alias
and .forward file set to kuncick@cs.fsu.edu
> cs.fsu.edu is a DNS alias (CNAME record) that points to nu
Received: from grep.cs.fsu.edu by gatech.edu with SMTP id AA22192
(5.65c/Gatech-10.0-IDA for );
Mon, 13 Mar 1995 09:55:47 -0500
> here gatech receives the message from grep.cs (which is where
Dave sent it from)
> back to time 9:55:47
Received: by grep.cs.fsu.edu (8.6.9/56)
id JAA11144; Mon, 13 Mar 1995 09:54:48 -0500
> here grep's sendmail receives the message from /usr/ucb/mail
> looks like gatech and grep's clocks aren't in sync!
Date: Mon, 13 Mar 1995 09:54:48 -0500
From: "D.C. Kuncicky"
Message-Id: <199503131454.JAA11144@grep.cs.fsu.edu>
> note the message ID number, this is a world-wide unique
identifier for the message (timestamp.queue name)
To: kuncick@sed.cs.fsu.edu
Subject: test
Status: R
> this is added by my user agent as I read the message
> O means I have modified my mailbox since reading the
mail
7. spool directories
- may be specified in sendmail and /bin/mail binaries
- default is /var/spool/mail
- mode 1777
- each person owns his or her own mailbox and may edit it
directly
- CompSci exports /var/spool/mail
- NFS locking problems may cause problems if one user reads
mail from two places at once
- if a user receives mail on two different machines in
close proximity, inconsistencies may result
- trade-off for convenience
(continued in "Sendmail II")