Sendmail is an MTS for UNIX and UNIX-like systems that was originally written by Eric Allman.
Sendmail has an official web page, sponsored by the Sendmail company. It has its own Usenet newsgroup.
Sendmail is a software that, like other softwares, rose to dominance of its particular area by dint of being the one that was supplied pre-packaged with the main thing that one was buying. Many Unix vendors (and indeed many vendors of other operating systems, such as IBM for OS/2 Warp) took Sendmail, compiled it, packaged it, created configuration files for it, and shipped it along with their operating systems.
Many opine that Sendmail did not rise to dominance because of its quality. The MMDF 2 FAQ quotes one particularly scathing comment:
Sendmail was once compared by one old Internet hand to "those killer bees that escaped from the laboratory--and now they're everywhere and you can't get rid of 'em".
However, the evidence is that gradually the world is getting rid of Sendmail, if only very slowly. The reason that it is happening slowly is that many users do, indeed, take what comes in the box. Dan Bernstein, seeing the results of a survey of SMTP servers that he took in 2000, concluded the following:
As in previous surveys, most of the Sendmail servers announce version numbers known to have security holes, in some cases remotely exploitable. Very few servers are running the most recent free version of Sendmail, or any commercial version of Sendmail. Apparently most Sendmail users simply take what comes with the operating system.
What comes in the box is not always Sendmail, of course. SCO Unix traditionally came bundled with MMDF.
A back door in Sendmail when it provided SMTP service that allowed remote execution of programs as the superuser was, of course, one of the infection vectors for the famous Internet Worm of 1987. Sendmail has had a long history since then of security problems due to design and implementation bugs. Security holes are still being found and fixed 14 years later.
The fact that many operating system vendors provide Sendmail pre-built and bundled with the operating system only exacerbates the problem. All too often the operating system vendor's version of Sendmail is both tailored to the operating system and out of date, resulting in it being hard to replace it with an updated version.
Interestingly, Sendmail is the only MTS whose proponents insist that local delivery is not a part of its job. (And this despite the fact that Sendmail does have a local delivery agent of its own, named mail.local.) All of the other MTSes have local delivery agents as part of their packages that far exceed the capabilities of Sendmail's local delivery agent. mail.local does not support
It is ironic that, given the claim about local delivery not being a part of its job, it is Sendmail itself that handles /etc/aliases and ~/.forward. In other MTSes, these (and their equivalents) are handled by the local delivery agents, not by the MTA itself.
Sendmail has a large monolithic configuration file, sendmail.cf with a complex structure, written in a language that is specific to Sendmail and illegible by human beings. It has been said that the contents of the rules sections of sendmail.cf most closely resemble the effect of line noise on a non-error-correcting modem. It has also been said that capturing such line noise into a text file has about as much chance of resulting in a working sendmail.cf as does any attempt to actually edit that file.
The modern recommendation is to generate sendmail.cf from another file, sendmail.mc, using the m4 macro processor, rather than edit it directly. The contents of sendmail.mc are legible by human beings. However, not all operating system vendors ship m4 and sendmail.mc.
With or without m4, modifying the configuration of Sendmail certainly cannot be easily automated under script control with echo and cat.
Sendmail rewrites the envelopes and headers of messages as it processes them. This is because it was initially designed to cope with a diverse set of message formats and mail transports, and so required the ability to translate envelopes and headers from one format to another as mail was routed from one mail system to another. Nowadays, this mechanism is unnecessary. Indeed, an MTA that rewrites headers is frowned upon as a bad thing, because more often than not it obscures actual operation and hampers problem diagnosis. It also causes problems of its own (such as the conversion of names to "canonical" form and back altering the headers of messages that are in transit through an MTS relay that is using Sendmail). Unfortunately, Sendmail's rewriting cannot be turned off, because the "canonicalisation" and the processing of "rulesets" are an integral part of the design.
Like exim and smail, Sendmail comprises one, single, huge set-UID root binary. This binary can be invoked by a variety of names, each of which alters the default behaviour (in the absence of subsequent command line options): sendmail, mailq, and newaliases.
Unlike qmail and Postfix (and, to a lesser extent, MMDF and Zmailer), there is no clear security partitioning in Sendmail at all. Indeed, many operations that are run under other unprivileged user IDs in MMDF, qmail, and Postfix are run as root in Sendmail.
Sendmail is available by anonymous FTP.