This chapter describes the basic requirements which sendmail X.0 must fulfill as well as the basic functionality that it must implement. It will state several obvious items just for the sake of completeness. This chapter will serve as a basis from which the author will work to design sendmail X.0. The content must be agreed upon by all relevant, involved parties. It will also lay the groundwork for the future development of the sendmail X series of MTAs, of which sendmail X.0 will be the first implementation. sendmail X.0 is not meant to be feature complete but a proof of concept. It must be designed and written with extensibility in mind. Subsequent versions of sendmail X will add more features.
Note: some sections of this document are still under development.
Some requirements for an MTA are so basic that it should not be necessary to mention them. However, we will do it nevertheless. These requirements are:
These requirements are conditio sina qua non, they will be taken for granted throughout this and related documents and during the design and implementation of sendmail X. In addition to these, sendmail X must be efficient. However, neither of the two main requirements will be compromised to increase efficiency. The intended goal for the efficiency of sendmail X is to be about one order of magnitude faster than sendmail 8.
There is another obvious requirement which is given here for completeness, i.e., conformance to all relevant RFCs, esp. RFC 2821 [Kle01], and implementation of (nearly) all RFCs that sendmail 8 handles:
| RFC 974 | Mail Routing and the Domain System [Par86] |
| RFC 1123 | Internet Host Requirements [Bra89] |
| RFC 1652 | SMTP 8BITMIME Extension [KFR+94] |
| RFC 1869 | SMTP Service Extensions [KFR+95] |
| RFC 1870 | SMTP SIZE Extension [KFM95] |
| RFC 1891 | SMTP Delivery Status Notifications [Moo96b] |
| RFC 1892 | The Multipart/Report Content Type for the Reporting of |
| Mail System Administrative Messages [Vau96b] | |
| RFC 1893 | Enhanced Mail System Status Codes [Vau96a] |
| RFC 1894 | Delivery Status Notifications [Moo96a] |
| RFC 1985 | SMTP Service Extension for Remote Message Queue Starting [Win96] |
| RFC 2033 | Local Mail Transfer Protocol [Mye96] |
| RFC 2034 | SMTP Service Extension for Returning Enhanced Error Codes [Fre96] |
| RFC 2045 | Multipurpose Internet Mail Extensions (MIME) |
| Part One: Format of Internet Message Bodies [FB96] | |
| RFC 2476 | Message Submission [GK98] |
| RFC 2487 | SMTP Service Extension for Secure SMTP over TLS [Hof99] |
| RFC 2554 | SMTP Service Extension for Authentication [Mye99] |
| RFC 2822 | Internet Message Format [Res01] |
| RFC 2852 | Deliver By SMTP Service Extension [New00] |
| RFC 2920 | SMTP Service Extension for Command Pipelining [Fre00] |
sendmail X must be compliant with all the usual buzzwords (marketing or software development): robust, flexible, scalable, extendable, maintainable, portable to modern OS with support for POSIX (or similar) threads and certain other basic requirements. What this really means in particular will be explained in the next sections. sendmail X must run well on Unix and Windows (natively), support for Windows will not be added later on as an afterthought. It must provide hooks for monitoring, managing, etc. It also must be simple to replace certain modules (library functions) by specialized functions, e.g., as in sendmail 8.12 different lookup schemes for mailboxes.
sendmail X should be backward compatible with sendmail 8 at the user level as far as the basic requirements (esp. security) allow this. This includes support for aliases and .forward files, however the actual implementation may differ and result in slightly different behavior.
sendmail X should minimize the burden it puts on other systems, i.e., it must not overwhelm other MTAs, and it should make efficient use of network resources. It must properly deal with resource shortages on the local system and degrade gracefully in such events. However, the first implementation(s) of sendmail X may require some large amounts of certain resources, esp. memory.
sendmail X is meant to be useful to a majority of users, and thus must deal with some of the quirks of other MTAs and MUAs. However, it will most likely not go to the extreme of sendmail 8. Even though it should be ``liberal in what it accepts'', there are limits. Those limits are given by the time required to implement workarounds for broken systems, the possible problems for security (which will not be compromised), performance (which will only be compromised if really necessary), the amount of architectural changes, etc.
In this section we explain what the various buzzwords mean with respect to sendmail X.
sendmail X must be robust which means that even in event of failures it should behave reasonably. It must never lose e-mails except in the case of hardware failures or software failures beyond sendmail's control that occur after sendmail has accepted responsibility for an e-mail (there's nothing sendmail can do if someone/something destroys the files/disks containing the e-mails). In the event of resource shortages (memory, disk, etc) it must degrade gracefully. It should be implemented in such a way that it can also deal with simple OS errors, e.g., if a (sub)process fails due to an error (e.g., looping because a system calls fails in unexpected ways), it should deal with that in a useful way, i.e., log an error message and exit without causing havoc to the rest of the system. It is not expected to deal with all possible errors (e.g., who supervises the supervisor?) but the design should be done properly to deal with most (also unexpected) problems.
sendmail X also must be able to deal with Denial of Service attacks as much as technically possible.
It must be possible to tune or replace components of the sendmail X system for different purposes to achieve good performance in almost all cases or to add new features.
sendmail X should be able to take advantage of changes in the underlying OS and hardware that modify the relative performance of the available components. For example, if more processing power (faster or more CPUs) is available then the overall system should become faster. However, this can't be taken to an extreme since other parts might become bottlenecks despite careful design. For example, it is unreasonable to expect twice as many local mail deliveries if the number of CPUs is doubled since the limiting factor is most likely disk I/O in this scenario.
Clustering/High Availability support might be required too. The impact, as far as an application designer is concerned, is:
It must be possible to extend sendmail X in various places. These include: interfaces to other mailbox identification schemes, interfaces to other map types, adding other delivery agents. sendmail X will have clear APIs for various extensions, as for example the milter API is one for sendmail 8.
sendmail X must be designed and implemented to be easily maintainable. This not just means adherence to the Sendmail coding standard, but also a clear design without ``surprises'', e.g., far reaching side effects.
It is important that (almost) each functionality in sendmail X is subject to automatic testing. Having tests greatly simplifies maintainability because changes to the implementation can be automatically tested, i.e., if some of the tests break then the changes are most likely incorrect (unless the tests are broken themselves). Tests should cover (almost) all of the code (paths).
sendmail X must run on Unix OSs which support (POSIX) threads and on Windows. The exact list of requirements for the OS is not yet finalized. sendmail X will be written in C, most likely C89-compliant.
There are several things that sendmail X will not do or offer. First of all, it will not use the same (or even compatible) configuration files as sendmail 8 does. There should be a tool to migrate sendmail 8 mc files to sendmail X configuration files. However, it is unlikely that cf files can be easily migrated to sendmail X configuration files.
sendmail X.0 will not not have support for:
Those features may be added in future versions.
This section deals with two aspects: the configuration file for sendmail X and the configuration options for sendmail X.0.
sendmail 8 uses a configuration file that is supposedly easy to parse, but hard to read, understand, or modify by a system administrator. Even though this was simplified by using a macro preprocessor (m4) and a significantly simpler input file (mc), it is still considered complex. Moreover, there is no syntax check for the mc file which makes it fairly user unfriendly.
Hence it is necessary that sendmail X uses a simpler and more flexible configuration file. We need a syntax that allows us to keep options that belong together in a structured entity. This will be achieved with a C like syntax using (initial) keywords and braces. Moreover, the syntax will be free form, i.e., it will not depend on indentations, use of tabs, etc. It is also a bad idea to require special software, e.g., editors, to maintain the configuration files. For example, requiring a syntax oriented editor will add an additional migration hurdle which must be avoided otherwise users may switch to a different MTA that does not have such additional requirements.
Since sendmail X will consist of several modules, it is likely that there are several configuration files, at least for modules that are really separate. Moreover, it might be useful to delegate certain parts of a configuration to different administrators or even users. For example, it should be possible to delegate the configuration of virtual domains to different administrators. However, this will not be implemented in sendmail X.0, but the design will take this into consideration.
sendmail X.0 will initially offer a subset of the (huge set of) configuration options of sendmail 8. It is simply not possible to implement all of the accumulated features of sendmail 8 in the first version of sendmail X within a reasonable timeframe and the limited resources we have.
The documentation for sendmail X must fulfill different requirements with respect to its structure and its formats. The latter is explained in the next section.
The sendmail documentation must at least consist of the following sections:
It is important that the documentation provides different levels of details. The current documentation is not particularly well structured or organized. It more or less requires to read everything, which, however, is not really necessary nor does it help someone who has a lot of other things to do besides installing an MTA. Even though the installation of an MTA usually requires a bit more than
./configure && make && make test && make install && startit is not really necessary to read about (or even understand) all parts of the MTA.
The documentation that describes sendmail X must be written in a format that allows easy generation of different versions including at least: