Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!ucsd!ncr-sd!matt From: matt@ncr-sd.SanDiego.NCR.COM (Matt Costello) Newsgroups: comp.mail.uucp Subject: Re: BSMTP - Its time has come Message-ID: <2300@ncr-sd.SanDiego.NCR.COM> Date: 17 Jun 88 22:26:54 GMT References: <14605@uunet.UU.NET> <10127@mcdchg.UUCP> <10266@ncc.Nexus.CA> <1787@van-bc.UUCP> <10267@ncc.Nexus.CA> <9593@g.ms.uky.edu> Organization: NCR Corporation, Rancho Bernardo Lines: 63 In article <9593@g.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: >Well now, there's finally some interest in doing this :-), a year >after I posted that code you've got sitting there. Anyway, let me >toss out a few thoughts which'll have to be overcome. I wrote two programs (bsmtp-send and bsmtp-rcv) to do Batched SMTP over UUCP communication links last year. Unfortunately I did them on company time so they are owned by NCR. I might be able to get permission to distribute them if necessary, or it should be easy to reverse-engineer them from the manual pages. I'll mail the manual pages upon request. I'm going to talk about how I implemented bsmtp-send, as bsmtp-rcv is trivial (with our mail router). It is not always pretty, but it works. This implementation is specific to HDB UUCP, although it could be modified for other flavors of UUCP. >Queueing. To take advantage of the batching in bsmtp you want to >have as many mail messages in the batch as you can manage. But >neither smail or sendmail will handle more than one message at >a time, will they? True. The solution is to let UUCP do it. This also presents the minimum delay since no mail is off hiding elsewhere. My solution is to keep a link to the transmitted data file and then append new mail messages to the queued data file whenever possible. This is very easy except for finding the queued data file in the first place; this is the part specific to Honey DanBer UUCP. Appending to the BSMTP batch involves opening a link to the queued batch and then appending from the trailing "QUIT" in the file which requires that the last 5-7 bytes of the file be overwritten. The links to the spooled data files are kept in the directory /usr/spool/uucp/.bsmtp with the system name as the file name. As long as the link count of the file is still two it means that the BSMTP batch has not been transmitted, although the UUCP lock file is checked to make sure that it does try to modify the data file while uucico is reading it. If it is not able to append to the existing batch it creates and queues a new one. When bsmtp-send creates a new batch it spools it using uux and then scans the UUCP spool directory for that system looking for it. The file must pass 3 criteria: the file name must start with a 'D', it must have the right date, and it must end with QUIT. The size of the file is not checked because it is passed to uux in a pipe and the length is not known. When the file is found it is linked into /usr/spool/uucp/.bsmtp for use by the next invocation of bsmtp-send. >Routing. Yes, you can say that uunet does BSMTP (assuming that >you get Rick to implement it). Now, what do you do after that? >You'll have other sites with BSMTP capabilities also. Other >places might want to send BSMTP to remote sites. How do you >tell the world that you can do BSMTP and what domains you're >willing to handle gatewaying? I'm not saying this very well >so I hope I'm getting through anyway. Only our neighbors need to know that we handle BSMTP. I prefer to think of BSMTP as a protocol layer on top of UUCP. Any neighbors of ncr-sd are welcome to send us BSMTP batches. See! I've just announced it. -- Matt Costello +1 619 485 2926 {ucsd,cbosgd,pyramid,nosc.ARPA}!ncr-sd!matt