urban@trwspp.UUCP (01/23/87)
About a week ago, I posted a query about sendmail and the possibility of using SMTP through a serial line. The results of that query weren't encouraging, so I'd like to describe our situation in more detail and solicit suggestions. Basically, we have been given the task of providing straightforward (preferably "transparent") file transfer and electronic mail between 4.*bsd and a VMS system. The best way to do this, of course, would be to procure TCP/IP support for VMS and connect the systems in a local network. Unfortunately, we cannot be certain that the machines can be connected in this way--they might even be miles apart, connected by modem. So we need transfer mechanisms that (a) are cheap to set up (we don't have the manpower to write this stuff completely from scratch) (b) can operate through a (possibly unreliable?) serial line, and (c) can be made to interact smoothly with existing mail tools on both ends. We are, for example, considering Kermit as the basic mechanism for file transfer, because it operates on many systems, and because it's basically a freebie. We anticipate setting up a quasi-batch kermit-copy command at the Unix end which would work similarly to UUCP. However, Kermit isn't particularly good as a mail delivery system. To transfer mail from Unix to VMS via Kermit, the mail deliverer would ask Kermit to transfer the message (with envelope) into a well-known mail spooling directory on the other side, from which a daemon would periodically retrieve messages and deliver them into the local mail system. This seems rather clumsy. SMTP seems like a nice simple protocol for serial lines, but it really was designed on the assumption of a reliable virtual circuit. Serial lines (especially via modem) aren't really reliable enough to use with SMTP without some kind of error-correcting protocol being layered into the line driver somehow. Further, Sendmail only runs an SMTP server via a serial line (via the -bs flag); since it doesn't implement TURN, it's not usable for bidirectional mail transfer via a serial line without extension. There appear to be serial-line IP drivers available for Unix; I don't know what the licensing arrangement is, nor do I know if something analogous exists for VMS. Evidentlyl, SMTP could be used in both directions through such an arrangement (albeit slowly). Is there a UUCP for VMS? How much does it cost? Does anyone have any further ideas?
jc@cdx39.UUCP (01/28/87)
> .... To transfer mail from Unix to > VMS via Kermit, the mail deliverer would ask Kermit to transfer > the message (with envelope) into a well-known mail spooling directory > on the other side, from which a daemon would periodically retrieve > messages and deliver them into the local mail system. This seems > rather clumsy. This is exactly what uucp mail does. I guess that means that uucp mail is clumsy. C'mon, would anyone make such a vile accusation? (:-) Somehow, I suspect that most mailers work this way, except for those on non-multiprogramming systems like MS/DOS or the Macintosh. On multiprogramming systems, it's the easy way to do the job. -- John M Chambers Phone: 617/364-2000x7304 Email: ...{adelie,bu-cs,harvax,inmet,mcsbos,mit-eddie,mot[bos]}!cdx39!{jc,news,root,usenet,uucp} Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193 Clever-Saying: If we can't fix it, it ain't broke.
jsdy@hadron.UUCP (02/06/87)
In article <620@cdx39.UUCP> jc@cdx39.UUCP (John Chambers) writes: (for Kermit) >> the message (with envelope) into a well-known mail spooling directory >> on the other side, from which a daemon would periodically retrieve >This is exactly what uucp mail does. >Somehow, I suspect that most mailers work this way, ... I'm kinda surprised, John. Outgoing UUCP mail may spool, if your sendmail.cf is set up that way. All my local mail is immediate-dial. Incoming UUCP mail is put into a spool directory, true; but then rmail is immediately called (by UUXQT) to deliver it. Similarly, SMTP mail comes into a spool directory and sendmail (the one playing SMTP daemon) forks itself off to deliver it instanter. Only non-interactive message collection systems, which have no control over messages coming in while they do house-keeping, might do what you suggested. (I have written one such.) -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised)