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
|
# Rationale
## The case for libESMTP
In the good old days of Un\*x when men were real men, women were real women and
timesharing systems were real timesharing systems and networks were not
commonplace, the *"pipe it into sendmail"* approach was a good one. Sendmail
can handle many diverse means of mail transport and can parse and translate
addresses and message headers to suit the underlying transport's
characteristics. It is convenient for programmers, just shell out to
sendmail and pipe the message into sendmail's standard input. Not much
code is required to do this which is good, less code means fewer bugs.
However, things have changed over the years. Nowadays, personal workstations
are normal and electronic mail transported using the SMTP protocol is
ubiquitous. The mail server (known as a Mail Transport Agent or MTA) that is
supposed to handle mail submission is almost invariably remote from the
workstation. There are many other MTAs to choose from than sendmail, and the
alternatives are typically easier to install and maintain.
Unfortunately, the MUAs have not changed much in the way they work. They still
shell out to sendmail. This means that MTA authors must provide a sendmail
command to wrap the way their program really works. Users on workstations need
a sendmail-like MTA on the local host which can be an administrative
nightmare. There are many command line options which must be accepted but do
nothing; useful SMTP extensions that are not supported via the command line
options (or just not supporetd). Where is sendmail really installed on this
system? Does the emulation implement every obscure feature an MTA might need?
The solution is simple, an MUA uses SMTP to submit its mail to the MTA. SMTP
is defined in open standards that are easy to obtain, all MTAs implement it and
it breaks the dependency on an external program's idiosyncrasies and calling
conventions. Furthermore, it works across a network. Sendmail talks SMTP so
its ability to transport mail using other mechanisms is not lost. Nowadays,
most, if not all, users are on workstations and the MTA is on a remote system.
Using SMTP directly surely must be the solution.
Unfortunately, while interacting by the use of standardised protocols is the
solution for the modern networked environment, writing the client side of even
a simple protocol like SMTP is not that trivial. Quite a lot of code is needed
just to implement the communications between client and server, never mind the
protocol itself. There are many SMTP extensions which are desirable but not so
easy to implement. There are restrictions on the format of many of the
protocol elements, for example, the domain of an email address should not
reference a CNAME in the DNS. MUA authors are caught between the Devil and the
deep blue sea. Either they opt for the simple solution which requires
installation of a complex piece of MTA software or they choose the protocol
solution which is difficult to implement.
By having a library that implements an electronic mail submission API, it
becomes as easy for programmers to use SMTP for mail submission as it is to use
sendmail. The library is isolated from the application since it interfaces
only via the API. On modern systems implementing dynamic linking, the library
can be upgraded without disturbing the application.
Given a simple and intuitive API and a robust implementation, programmers will
adopt it. Direct use of SMTP eliminates the necessity for sendmail or any
other MTA to be present on workstations.
**libESMTP** is my attempt at implementing just such a library.
----
Brian Stafford, November 2000.
|
