Xref: utzoo comp.emacs:5517 comp.mail.misc:1676 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!oliveb!intelca!mipos3!pinkas From: pinkas@hobbit.intel.com (Israel Pinkas ~) Newsgroups: comp.emacs,comp.mail.misc Subject: Re: making GNU Emacs talk SMTP Message-ID: Date: 6 Mar 89 20:42:51 GMT References: Sender: news@mipos3.intel.com Organization: Corporate CAD, INTeL Corporation, Santa Clara, CA Lines: 42 In-reply-to: rsm@amethyst.ma.arizona.edu's message of 5 Mar 89 23:23:59 GMT In article rsm@amethyst.ma.arizona.edu (Robert Maier) writes: > It would be nice if GNU Emacs, when used as a mail user agent, would > send mail by talking SMTP to a mail server instead of just invoking a > local `sendmail'. > > Has anyone succeeded in making Emacs talk SMTP? Coding in Elisp beats > writing a sendmail.cf any day... I have to disagree. There are a number of problems with this. 1) GNU Emacs runs on many machines that don't have SMTP, or that don't use SMTP for mail delivery. There are sites that use POP, uucp, and other mailer configurations. 2) You would still have to write the sendmail.cf. Look at MH (the Rand Mailer). The default configuration is to connect to the SMTP server. (Normally this is localhost, but you might want all mail to be delivered to one machine.) Since the SMTP server is usually sendmail, you wind up writing the sendmail.cf. 3) Most mailers deliver mail by invoking sendmail with flags. There may be a reason for a site to replace sendmail with a program that does something site-specific. For example, sites that use NFS without lockd might want to force all mail to the server machine. It would not be difficult to write an SMTP package in Elisp (see the NNTP package in GNUS). I just think that it is unnecessary. Besides, you could always use the MH-E package that is supplied. This does almost exactly what you want. -Israel -- -------------------------------------- Disclaimer: The above are my personal opinions, and in no way represent the opinions of Intel Corporation. In no way should the above be taken to be a statement of Intel. UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!cadev4!pinkas ARPA: pinkas%cadev4.intel.com@relay.cs.net CSNET: pinkas@cadev4.intel.com