Reasons behind defaulting atd and sendmail

[Patrick O'Callaghan]

On Tue, 2008-09-09 at 14:07 +0200, Timothy Murphy wrote:
> Patrick O'Callaghan wrote:
> 
> >> Are you just saying you could use another program in place of
> >> sendmail?
> ...
> > >> Perhaps if you gave an explicit example of "speaking SMTP directly" 
> >> I would understand better.
> > 
> > Fire up your favourite local email client (i.e. not a webmail service)
> > and look for Preferences.
> 
> OK, I see that I can indeed do this with kmail, indeed I am doing it.
> But I would have described that as using kmail as my MTA
> in place of sendmail for sending mail.

Kmail, Evolution etc. are MUAs (Mail User Agents). They also happen to
work as simple MTAs because they can talk SMTP, but their primary focus
is on the user, not the mail transport. Thus they don't use SMTP to
receive mail, just to send it (see below), and aren't considered daemons
in the usual sense.

Sendmail, Postfix etc. have no user interface to speak of and are
focussed on queue management, security, efficient transport of large
quantities of mail for many users etc.

> What about receiving email - don't I have to run rmail or equivalent?

The MUAs receive mail by a variety of methods, the most popular being
IMAP and POP. In this sense they aren't acting as MTAs but as windows
into a mail store maintained elsewhere, i.e. where an SMTP service is
being run by some MTA daemon.

The original model of MTS/MUA (MTS is Mail Transfer Service, meaning
roughly the collection of interconnected MTAs on the Internet) assumed
that the user would have a local MTA depositing mail in a local store to
be picked up by his MUA. POP and IMAP were invented in recognition of
the fact that many users aren't going to run a full MTA and that the
"store" is not local but exists on a remote server.

poc