Re: why use sendmail?
Lo, on Sunday, March 31, Simon Hepburn did write:
> dman wrote:
>
> > The reason is that KMail is not a proper SMTP client. The RFCs (821,
> > 2821) state that if a message can't be delivered to the next server in
> > charge, then it must keep the message and retry later. It can't just
> > say "oh, well" and give up. KMail (along with Lookout and every other
> > User Agent) doesn't do this.
Haven't read the RFCs in question: does that requirement apply to MUAs,
or just MTAs?
> In such a situation KMail keeps the undelivered message in the outbox. I
> don't think you could call that "giving up". The message is not simply lost
> in cyberspace. How does Kmail keeping the message and trying again later
> differ from what an mta does ?
First, not all MUAs have that kind of functionality. In fact, the
`traditional' Unix MUAs, written in the days before POP was the dominant
mechanism for retrieving email, pretty much require that there be an MTA
running locally which can handle queuing and delivery issues. (And, in
general, this MTA darn well better be called /lib/sendmail or
/usr/lib/sendmail!) The mailer that I use, VM, also makes this
assumption, although it's possible to get it to talk to a remote MTA.
It's been so long since I've used that configuration that I don't recall
exactly what happens if the remote MTA is inaccessible.
Second, if you've got exim running constantly (instead of from
/etc/inetd.conf), it'll retry in the background without users having to
take any action. I guess it's my software engineering/development
training, but I like the idea of placing the queueing functionality in
one place (the MTA), rather than replicating it out among lots of
different places (all the various MUAs that people use). Still, I guess
this is more important on a large multi-user system.
Richard
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: