Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!midway!clout!chinet!les From: les@chinet.chi.il.us (Leslie Mikesell) Newsgroups: comp.mail.uucp Subject: Re: Is UUNET going to upgrade? Message-ID: <1991Jun25.203114.27430@chinet.chi.il.us> Date: 25 Jun 91 20:31:14 GMT References: <1084@camco.Celestial.COM> <28609F47.1E0D@tct.com> Organization: Chinet - Chicago Public Access UNIX Lines: 39 In article emv@msen.com (Ed Vielmetti) writes: > Quite! Batch SMTP already exists and is supported by Smail 3.1 (among > other transports). What say you, UUNET? BSMTP could cut down > significantly on E-Mail processing overhead, and lots of us out here > in modemland are already using it. > >Chip, could you give a tutorial on compressed batched SMTP ? That >would seem to be the ideal thing for long-haul links with high modem >costs. How to set it up within smail, what the gotchas are, how much >of a savings in on-line time there is and at what cost in extra >compression vs. benefit in fewer uuxes done. In addition to the compression (which could be done apart from the batching if you have large mail messages) the real savings is in having fewer files for uucico to handle, especially if you are using PEP modems with spoofing. The spoofing mode only works within a file with the upper-level handshaking for each file suffering from the modem's slow turn around time. Since normaly uucp mail takes two files per message (data in one, command in the other) reducing this to two files per batch can be a big win. In addition you get the ability to use SMPT addressing with unlimited recipients per message which is nice if you run list expanders. The down side is that (a) the receiving site must be set up to match, (b) you need to impose an arbitrary delay in delivery to accumulate a batch and you may not be able to syncronize the batching with inbound calls, and (c) Smail3's (B)SMTP transport isn't quite binary transparent in that the convertion of LF's to CR/LF and extra leading '.'s on lines that start with '.' doesn't always invert (for example if the message body contains CR's with no LF). >Numbers would be nice to know, if they're convincing we'll start to >offer the service on our dialups. Look at real time (from your phone bill) vs. uucp's xferstats numbers to get an idea of how much time you spend in the between-file handshakes. Les Mikesell les@chinet.chi.il.us