MANAGER@SKIDMORE.BITNET (Leo Geoffrion) (12/21/87)
Does anyone have recommendations for an inexpensive store & forward extension for VMS Mail? Since we have a homogeneous VAX/micros environment, we are not really interested in the elaborate packages that do conversion to EMAIL PROFS, or other foreign protocols. As the number of small VAXen proliferate, the probability that a user may have his/her unit offline increases. I'd like a simple program that can simply buffer mail while that node is off line and send it through when it returns to service. The SET FORWARD command of VMS MAIL fails because that user is then unable to receive mail if it arrives while the forwarding address is offline. Any suggestions -- or perhaps even a PD program or two?? =================================================================== Leo D. Geoffrion BITNET: MANAGER@SKIDMORE.BITNET Associate Director for NYNEX: (518) 584-5000 Ext. 2628 Academic Computing Skidmore College Saratoga Springs, NY 12866
WARNER..NAGY@FNALB.BITNET (Frank.J.Nagy@jade.Berkeley.EDU, (12/23/87)
Leo Geoffrion <MANAGER%SKIDMORE.BITNET@CUNYVM.CUNY.EDU> writes: > Does anyone have recommendations for an inexpensive store & forward extension > for VMS Mail? Since we have a homogeneous VAX/micros environment, we are > not really interested in the elaborate packages that do conversion to EMAIL > PROFS, or other foreign protocols. Digital has a product called the Message Router which is available in several flavors. One package is explicitly designed to provide a store&forward interface for VMS MAIL; other packages provide programmer interfaces, etc. By hearsay, I understand that the VMS Mail Message Router package is easy to install and setup. I don't know anything about its performance, reliability, etc. as we do not have this package at Fermilab (although people complain about lack of s&f in VMS Mail). I just happen to be aware of the product since I've been trying to get the complainers to look into the package (to no avail). = Frank J. Nagy "VAX Guru & Wizard" = Fermilab Research Division EED/Controls = HEPNET: WARNER::NAGY (43198::NAGY) or FNAL::NAGY (43009::NAGY) = BitNet: NAGY@FNAL = USnail: Fermilab POB 500 MS/220 Batavia, IL 60510
XRBEO@VPFVM.BITNET (Bruce O'Neel) (12/24/87)
Re: Store and forward for VMS mail. My only attempt at store and forward was to always use the editor to create my note and then I wrote a .com file to do the mail. It went something like this $ @sendmail <node::user> <file> <subject, in "> This just copied the file to a unique name in a directory I'd set up for this purpose and put a few line header on it holding the name and subject. I also had a batch job sitting in the batch queue which every hour started up, went through this directory and tried to send the mail to the different people out there, sent me mail back if the message wasn't going to make it (say I got the wrong user id), deleted the scratch files if the mail made it, and then resubmitted itself to run in another hour. This wasn't elegant, and didn't always work (say the system crashed and I didn't resubmit the batch job) but it did make vax mail on a large decnet network less painfull. And no, I don't have the .com file but it wasn't large or difficult to write (I didn't try to be fancy). bruce <xrbeo@vpfvm> on bitnet.
mem@zinn.UUCP (Mark E. Mallett) (01/01/88)
In article <8712250028.AA23885@jade.berkeley.edu>, WARNER..NAGY@FNALB.BITNET (Frank.J.Nagy@jade.Berkeley.EDU, writes: > Leo Geoffrion <MANAGER%SKIDMORE.BITNET@CUNYVM.CUNY.EDU> writes: > > > Does anyone have recommendations for an inexpensive store & forward extension > > for VMS Mail? Since we have a homogeneous VAX/micros environment, we are > > not really interested in the elaborate packages that do conversion to EMAIL > > PROFS, or other foreign protocols. > I didn't see the original of this-- One possibility, if you already have a lot of VAXes and happen to have one or more that runs Ultrix, is to send all the mail through the ultrix systems which DO have store-and-forward mail. Some years ago I wrote a program that ran as a VMS DECnet mail object and handled SMTP mail traffic between VMS and TOPS20 machines. The program queued up incoming mail; a background job was run to dequeue it and deliver it by talking to the appropriate mail object (SMTP if the destination was a DEC20, VMSMail if the destination was a VAX; common destination sites were of course optimized, failures were requeued and returned to sender after some parameterized length of time). Mail was sent the other way by using the old (new then) trick of sending to a dedicated account and putting the real destination in a comment, viz: to: MAILBOX!user@DEC20 (I also provided other ways of specifying information in a pseudo-header within the VMS mail body). A background process was responsible for taking mail out of the MAILBOX mailbox and putting it in the above-mentioned mail queue. A fallout of this is that the process magically provided VMS-to-VMS store-and-forward capability. Unfortunately the MAILBOX!user addressing scheme made the REPLY command not work, but this was acceptable. This was a fairly quick hack but it worked very well. For simply doing VMS store and forward, I would consider writing a new VMS mail object that would handle the VMS mail negotiations through a store-and-forward queue, and either attempt local delivery itself or talk to the "real" VMS mail program assigned to another DECnet object number and let IT deliver the mail. -- Mark E. Mallett Home phone: 603-424-8129 uucp: mem@zinn.UUCP (...decvax!elrond!zinn!mem or ...sii!zinn!mem) BIX: mmallett