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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
