Xref: utzoo comp.mail.misc:5285 gnu.emacs.help:1831 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!linac!att!ucbvax!ulysses!danj1 From: Dan_Jacobson@ATT.COM Newsgroups: comp.mail.misc,gnu.emacs.help Subject: Re: wanted: mail user agent that verifies local addresses before sending Message-ID: Date: 24 Apr 91 04:09:06 GMT References: <1991Apr18.210755.18654@chinet.chi.il.us> <1991Apr22.161201.5966@chinet.chi.il.us> Sender: netnews@ulysses.att.com Reply-To: Dan_Jacobson@ihlpz.ATT.COM Organization: AT&T-BL, Naperville IL, USA Lines: 57 In-reply-to: les@chinet.chi.il.us's message of 22 Apr 91 16:12:01 GMT [sorry i'm not trimming the quoted stuff] >>>>> On 22 Apr 91 16:12:01 GMT, les@chinet.chi.il.us (Leslie Mikesell) said: les> In article Dan_Jacobson@ihlpz.ATT.COM writes: >[I'm saying that [william.j.carpenter@att.com's] feedmail.el passes >mail to /bin/[r]mail, which is supposed to be on all unix machines, >as opposed to /usr/lib/sendmail. I'm saying that feedmail.el can be >popped in place, without having to be adjusted for whatever mail >system you're running... I wasn't saying that it had magic powers to >pre-forecast remote errors.] >Leslie> What if the thing that happens to be named /bin/rmail just >Leslie> queues messages and delivers in another process? >Depending on the value of the Emacs variable mail-interactive >("Documentation: Non-nil means when sending a message wait for and >display errors. nil means let mailer mail back a message to report >errors."), Bill's feedmail.el will choose /bin/rmail if you want >mailed back errors, and /bin/mail, if you want instant errors. >[Of course it's customizable.] les> That sounds fairly reasonable, but you might look for /usr/lib/sendmail les> first and let it verify the addresses before sending if it is there. [actually, that's the GNU Emacs default way. feedmail.el also can do that] les> I suppose someone has a machine where sendmail (or smail3 in it's les> sendmail disguise) exists but isn't the real mail transport. les> The obvious problem here is that there really is no standard for a yes... its much more convienient for us to have one version of emacs that calls /bin/[r]mail than to guess what mail stuff is running on the many machines we're copying this version too. les> mail user agent and mail transport agent to communicate beyond actually les> handing the message over. In the fairly common situation of a hub les> machine handling alias processing for a group, it may not even be les> possible. A semi-solution would be to make the user agent able to les> parse the common error bounces and help fix them, or at least delete actually, the mailer discussed in newsgroup gnu.emacs.vm.bug has a command, "vm-resend-bounced-message: Extract the original text from a bounced message and resend it. You will be placed in a Mail mode buffer with the extracted message and you can change the recipient address before resending the message." les> the added header cruft so you have your original back. I don't know les> of any that offer to do this, though. This approach would have the les> advantage of using a single recovery method for both local and les> remote errors. In the case of a hub machine expanding aliases, the les> user may not know the difference. les> Les Mikesell les> les@chinet.chi.il.us