Dan_Jacobson@ATT.COM (04/18/91)
>>>>> On 15 Apr 91 05:10:34 GMT, mp@andante.att.com (Mark Plotnick) said:
Mark> I've been asked to look into modifying /usr/ucb/Mail, or providing a
Mark> replacement for it, so that when a user is sending a message it
Mark> verifies that each destination address is valid before passing the
Mark> message on to the mailer. If any destination addresses are invalid it
Mark> prompts the user to re-enter them. Sort of like the 'msg' mailer that
Mark> some sites run (ran?).
Mark> We'd prefer a mail program that could interface to /usr/lib/sendmail.
How 'bout one that interfaces with /bin/mail or /bin/rmail, that way
it will work on all machines.
Mark> The request comes from a user here who's tired of the effort it takes
Mark> to detect and resend messages that are bounced back to him because he
Mark> mistyped a user name. I've told him that it would be difficult to
Mark> verify remote addresses in real-time, so it's OK with him if only local
Mark> users, system-wide aliases, and aliases in a user's .mailrc file are
Mark> verified. Suggestions welcome.
I'm using GNU Emacs' mail-mode with William_J_Carpenter@ATT.COM's
recently posted (to gnu.emacs.sources, Apr 5 1991) feedmail.el
emacs-lisp add-on. [GNU Emacs can emulate vi of course, by the way].
Among other features, for [local addresses of course] that fail, a
"*Outgoing Email Errors*" window pops up, with e.g., "dfgasgdfafdsg...
User unknown" style messages in it... you just go back to the "*mail*"
buffer and fix the addresses... and resend. You can preview your
alias expansions too if you wish, etc.
Mark> Mark Plotnick
Mark> allegra!mp, mp@allegra.att.com
--
Dan_Jacobson@ATT.COM Naperville IL USA +1 708 979 6364les@chinet.chi.il.us (Leslie Mikesell) (04/19/91)
In article <DANJ1.91Apr17160336@cbnewse.ATT.COM> Dan_Jacobson@ihlpz.ATT.COM writes: >Mark> We'd prefer a mail program that could interface to /usr/lib/sendmail. >How 'bout one that interfaces with /bin/mail or /bin/rmail, that way >it will work on all machines. How do you ask /bin/mail or /bin/rmail to verify an address on all (any) machines? What if the thing that happens to be named /bin/rmail just queues messages and delivers in another process? >Mark> The request comes from a user here who's tired of the effort it takes >Mark> to detect and resend messages that are bounced back to him because he >Mark> mistyped a user name. I've told him that it would be difficult to >Mark> verify remote addresses in real-time, so it's OK with him if only local >Mark> users, system-wide aliases, and aliases in a user's .mailrc file are >Mark> verified. Suggestions welcome. Where is he getting the addresses from in the first place? If he has a list on the machine, why not read it in directly from there? Why not make it easy to fix and remail a bounced message so it will be just as easy when the bad remote addresses come back? Some machines send all unknown mail to a central host to make it easier to maintain the aliases and lists - in this case, there won't be any local errors. Les Mikesell les@chinet.chi.il.us
Dan_Jacobson@ATT.COM (04/20/91)
>>>>> On 18 Apr 91 21:07:55 GMT, les@chinet.chi.il.us (Leslie Mikesell) said: Leslie> In article <DANJ1.91Apr17160336@cbnewse.ATT.COM> Dan_Jacobson@ihlpz.ATT.COM writes: >Mark> We'd prefer a mail program that could interface to /usr/lib/sendmail. >How 'bout one that interfaces with /bin/mail or /bin/rmail, that way >it will work on all machines. Leslie> How do you ask /bin/mail or /bin/rmail to verify an address on Leslie> all (any) machines? [I'm saying that 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@chinet.chi.il.us (Leslie Mikesell) (04/22/91)
In article <DANJ1.91Apr19223024@cbnewse.ATT.COM> Dan_Jacobson@ihlpz.ATT.COM writes: >[I'm saying that 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.] That sounds fairly reasonable, but you might look for /usr/lib/sendmail first and let it verify the addresses before sending if it is there. I suppose someone has a machine where sendmail (or smail3 in it's sendmail disguise) exists but isn't the real mail transport. The obvious problem here is that there really is no standard for a mail user agent and mail transport agent to communicate beyond actually handing the message over. In the fairly common situation of a hub machine handling alias processing for a group, it may not even be possible. A semi-solution would be to make the user agent able to parse the common error bounces and help fix them, or at least delete the added header cruft so you have your original back. I don't know of any that offer to do this, though. This approach would have the advantage of using a single recovery method for both local and remote errors. In the case of a hub machine expanding aliases, the user may not know the difference. Les Mikesell les@chinet.chi.il.us
Dan_Jacobson@ATT.COM (04/24/91)
[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 <DANJ1.91Apr19223024@cbnewse.ATT.COM> 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