Date: Sun, 23 Apr 95 21:06:55 EDT From: Snuffles@kew.com Subject: UUPC-Info-Request Digest 1995 #13 To: uupc-info-digest@kew.com Message-ID: Reply-To: UUPC-Info-Request@kew.com UUPC-Info-Request Digest Sun, 23 Apr 95 Volume 1995: Issue 13 Today's Topics: (B)SMTP over UUPC or alternatives? Information on uucp for NT Need info on UUPC v1.2n/NNS setup for NT NT & wfwg clients Optimizing the speed Translation table in UUPC/extended. (3 msgs) Waffle and UUPC (2 msgs) Wrong path line To subscribe to UUPC-Info-Digest, send the command in the body of a message to listserv@kew.com: subscribe uupc-info-Digest To signoff from UUPC-Info-Digest, use "signoff" instead of "subscribe". You can also send an "index" to the listserv to get an index of back issues and other files available for retrieval. ---------------------------------------------------------------------- Date: Fri, 21 Apr 1995 12:41:42 +0100 (BST) From: ursr@omico.om.org Subject: (B)SMTP over UUPC or alternatives? To: UUPC/Extended mailing list We are running Pmail 3.22 together with UUPC 1.12j quite happily. But the mail volumes are going up and people start to buy V34 modems and suddenly we find that our throughput tops of around the 550 CPS mark. Most of it seems to have to do with the combination of the uucp protocol overhead and the many small files involved in uucp transfers. (we have now switched to Taylor 1.05 on Unix - which helps a bit) BUT it still is not enough for us. QUESTION: So, does anybody know of a way to "batch" those small files and then transmit them possibly even over uucp (uux?). What are others using for transport under Pmail (Charon, Mercury, SMTP/BSMTP ... etc.), that will work under at least Pmail Stand- alone DOS or Novell networked. (Preferably FREEWARE!) Reasons: We would like to stick to uupc (or uucp) because we have working packages for Unix, Mac's, DOS standalones & Novell Netware clients all working (almost)seemlessly and all of our clients finding it fairly easy to find a uucp-dial-up-access provider world-wide. ------------------------------ Date: Tue, 18 Apr 1995 07:19:54 From: tlupfer@clarisys.com Subject: Information on uucp for NT To: UUPC/Extended mailing list Do you have a version of uucp for Windows NT Server 3.5? Please email/mail whatever information you may have. Thank you. Tom ________________________________________________________________________ Tom Lupfer Internet: tlupfer@clarisys.com Clarity Systems Phone: (619) 458-0592 6540 Lusk Blvd, Suite C-237 Fax: (619) 458-0622 San Diego, CA 92121 ------------------------------ Date: Sat, 22 Apr 95 00:43:00 +0800 From: nsazman@dnv.po.my Subject: Need info on UUPC v1.2n/NNS setup for NT To: UUPC/Extended mailing list Hi Everyone, Greetings from Malaysia! I'm a newbie on this list and hope that other UUPC gurus could help me. As the title denotes I'm attempting to install uupc 1.2n and nns on windows nt 3.5. I have got 1.2k working (as far as mail is concerned) and have upgraded to v1.2n due to an nns requirement. I assumed to setup to be similar so I just copied the 1.2k setup files to 1.2n and tried a few options briefly mentioned in the nns documents hoping it would work. I must have done something WRONG coz after I ran REGSETUP -C my workstations NT registry got thrashed! Since there are no supporting documents for 1.2n, I would very much appreciate any kind of info that would aid my installation. Heres a bit of info on my hardware: Server Workstation ------ ----------- MS-Windows NT Server 3.5 MS-Windows NT WorkStation 3.5 Pentium/60 Pentium/90 32MB RAM 32MB RAM 2 x 1GB Hard disk 1GB Hard disk UUPC and NNS is installed on the server with the workstation acting as a gateway polling for mail/news from our provider. Thanks in advance. -Azman nsazman@dnv.po.my ------------------------------ Date: Sun, 16 Apr 1995 11:39:41 GMT From: tei!paul@senior.nectec.or.th Subject: NT & wfwg clients To: UUPC/Extended mailing list I'm starting to slowly switch our fsuucp over to uupc NT, what mail/rmail version should our clients use (ezmail front end)? Dos or windows? Thanks ------------------------------------------------------------------------------- Paul Hastings tei!paul@senior.nectec.or.th pjh@nwg.nectec.or.th Director Environmental Information Center Thailand Environment Institute ftp.nectec.or.th /pub/info/thailand-gis+maps----------------------------------- ------------------------------ Date: 16 Apr 1995 21:40:00 +0100 From: hajo@quijote.in-berlin.de Subject: Optimizing the speed To: UUPC/Extended mailing list Marco, Du schriebst am 14.04.95: > I am currently using UUPC 1.12 with a US Robotics 2880 Sporster modem, the > computer-modem speed is setted to 57600, the connection is 14400 bauds. > I think the transfer of data is very slow because I see the RD & SD leds > flashing but most of the time they are both off. > Is there any way to optimise/debug the connection to achive the maximum > transfer speed ?? I think you use the uucp-g protocol. uucp-g works by transferring data blocks, acknowledged by the remote system for having the right checksum. This way you get an error-free connection from computer to computer. The error control of the modem still allows lost characters at your COM port. These errors happen with all multitasking systems. The error correction of the modem works much faster than uucp error correction (especially if being able to talk "selective reject") and should always be enabled. The error correction of the modem also removes some lowlevel block information, and speeds things up. This way, you already get 1650 cps on a 14400 bps link, _without_ compression. Modem compression is not advisable on UUCP links. Batch packaging with gzip offline is always more effective than on-the-fly compression by modems. If your system is heavily loaded and cannot do compression, the modem compression should be enabled. Expect a speedup of 1:1,7 - 1:2 for uncompressed Usenet news and V42b compression (1:3 for source newsgroups). You may call the figures published by modem manufacturers pure nonsense or outright lies, whichever you prefer. How uucp-g works - theoretically -------------------------------- With uucp-g, your computer transfers data block A of size x to remote. After that, it sends block B of size x, block C, and so forth. x is called the blocksize. The uucp-g protocol knows blocksizes from 32 to 4096. While your uucico transfers the data, it waits for an ack for block A. The answer must come after y blocks, otherwise it will stop and wait for the ack (or resend if the data was bad). y is called the windowsize. uucp-g uses a windowsize of up to 7. At the end of a file, there is usually less data than the blocksize. The block can be padded up to x to send it. This is called fixed blocksize. The uucico can use smaller blocksizes instead. This is faster and called variable blocksize. uucp-g can use variable blocksize. uucp-g problems --------------- Everything fine? Not. uucp-g was first implemented in the days of 300 bps connections. Many old implementations of uucp-g were heavily restricted. Some very old could talk 64/3 only, some others 128/7, fixed blocksize. If you use a V32b or faster modem with 128/7, it will spend most of the time waiting for acks, and will be slooooooow. The solution is to do a full implementation of uucp-g. This was done some years ago by Ian Lance Taylor for Unix systems, therefore full implementations of uucp-g are often nicknamed "Taylor-uucico". If somebody tells you he or she has "a Taylor", you can be sure that this system can talk any blocksize up to 4096, windowsize 7, and variable blocksize with g. Today, more than 95% of private Unix systems can do this, and all professional networking computers do. You can still have problems in a company or university environment. Network administrators might recycle the oldest VMS or whatever system to let employees call in, and these old computers might still have the old restrictions. How UUPC does it ---------------- UUPC 1.12k includes a nearly full implementation of uucp-g. UUPC can talk 1024/7 with variable blocksize. The restriction to 1024 is there, because Snuffles the Polar Bear, in his remote arctic environment, does not know about warm places where it needs a letter to the phone company, 3 or 5 months waiting time, and 200$ for both the phone company and the computer hardware, to get two (bundable) 64000 bps channels for UUCP, allowing 7500cps transfer rates both. (Don't get jealous, the drawback is higher connection time rates for everybody, and 35-40$/month even before you connect.) When UUPC got a faster uucico, most uucicos were still old and slow. To avoid problems for the UUPC users, Drew decided to rename the more complete variant of uucp-g into uucp-v. Ian Taylor did it the other way. He assumed that giving the Unix freaks better software for free would be enough to redefine the meaning of uucp-g to the full implementation within short time. While at first, this added up to the situation that better UUPC uucicos and better Unix uucicos could not talk any faster, things are fine now. You can configure UUPC to talk faster g, and the current Taylor 1.05 will talk uucp-v. (1.04 and the Betas do not.) Nonetheless, there is a weird problem: During my test runs of UUPC in the last days, I tried both g and v with a Taylor 1.05 at the other end. In both cases, the same protocol runs with different naming. If "g" is negotiated, and g configured for 1024/7/variable on my side, the Taylor sends me 1024, but UUPC sends only 64. If "v" is negotiated, both sides send 1024. What to do? ----------- 1024 blocksize should be fine for compressed transfers on your 14400 bps link. For uncompressed transfer, 1024 might slow you down, but the difference is very small. If you know that there is a Taylor 1.05 at the other end, you best set "v" in your systems file, "1024" for v in the uucp.rc file, and variable blocksize in your whatever.mdm file. Just set debug level to 2, try and see. It will just throw you out if it does not talk v. If it is a Taylor 1.04, or a modern DOS client like Crosspoint, you set "g" in systems, 1024 for "g" in uucp.rc, and variable blocksize in *.mdm. If it is an old VAX, only TNT will speed things up. Your system might not able to talk with remote, if set to 1024/7/variable, while remote does not support this. This is better with modern implementations. Restriction to 1024 when talking to a Taylor or Crosspoint or whatever with support for bigger blocks is automated. Fast mail transfer ------------------ All this won't give you fast transfers for huge amounts of mail. Do not expect more than 400 cps average on a 1650 cps capable link with lots of mail. While news are transferred in compressed batches normally, mails are singles, with lots of overhead. Most Unix systems know a workaround for this: They use SMTP batches for UUCP mail, and can run compress or gzip over these. Some DOS clients talk the same trick. (One of the reasons Unix sysadmins love to do this: It saves them from some grief at Internet-UUCP relays, regarding bangpath adressing.) UUPC cannot do this trick. If you need to transfer huge amounts of small mails (there is no speed difference for huge mails), and remote supports SMTP batches, you better pack a big parcel with Italian chocolate. hajo ------------------------------ Date: Mon, 17 Apr 1995 08:30:35 -0400 From: Help@kew.com Subject: Translation table in UUPC/extended. To: UUPC/Extended mailing list On Sun, 16 Apr 1995 23:25:23 -0200, "Igor A. Karpov" wrote: > few days ago I ftp'd your UUPC/extended 1.12. In our country (Ukraine now, > a former USSR) there is a well-known packet with the same name but in > restricted form and with version number 6.13 or so. > If I'd have to choose, I'd rather prefer your edition. It is more flexible, > got a lot of additional capabilities and so on. But... > The point is that in USSR (and now in Ukraine, naturally) there were _two_ > different coding tables (even more, but the rest are forgotten now). It is > so called "KOI-8" and "codepage 866", supported with Microsoft etc. as the > only russian coding table for DOS. Almost all of the UUCP sites known to me > are using KOI-8, all of DOS running PC -- codepage 866 correspondently. > The russian version of UUPC, mentioned above, gives the possibility to include > translation table into configuration. > Are you planning to do something in this direction in nearest future ? I guess, > the Russian is not the only language which have different codepages... > > Sorry for bad English. The English is not bad. Trust me on that one. :-) UUPC/extended from here doesn't use _any_ code pages, it has no need internally (it doesn't care what it ship around the net). I don't know what the other program does, and so I can't reproduce what it does if I had time. (Unfortunately, I am also busy getting news support stablized as well). If the goal is to simply perform translation for RMAIL and no other programs (but allow for the possibility in the future), the source to RMAIL's deliver.c and kanji.c should be browsed for the example of how the suite translates in and out of eight bit character sets, and then add similar support for the other code page translation. If such support was neatly added and the changes shipped to me, I would try to get into the program. -ahd- -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-641-3452 "Give me Calculus, or Give me death!" - Patrick Henry Derbyshire ------------------------------ Date: Mon, 17 Apr 1995 17:53:57 +0200 (MET DST) From: storner@osiris.ping.dk Subject: Translation table in UUPC/extended. To: UUPC/Extended mailing list Pardon my barging in on this discussion, but SoftWare@kew.com writes about adding characterset translation to RMAIL: > UUPC/extended from here doesn't use _any_ code pages, it has no need > internally (it doesn't care what it ship around the net). [snip] > If the goal is to simply perform translation for RMAIL and no other > programs (but allow for the possibility in the future), the source to > RMAIL's deliver.c and kanji.c should be browsed for the example of how > the suite translates in and out of eight bit character sets, and then > add similar support for the other code page translation. If such > support was neatly added and the changes shipped to me, I would try to > get into the program. Characterset translations do not belong in the MTA (rmail); this is best performed in the user agent - the program used to read mail. The MTA has no way of knowing which characterset is active when the mail will eventually be displayed; for instance, on a DOS system with Windows installed there are _two_ native charactersets: The codepage 437/850/whatever when running in DOS, and ISO 8859/1 (Latin-1) when running Windows. If there are mail readers for both, then which one should an RMAIL-based conversion cater for? The MIME RFC's define a set of headers and encoding techniques for communicating non-ASCII charactersets through e-mail. Adding support for this to a mail-reader isn't difficult (I did it for rusnews/rnr). IMHO, if transparent handling of non-ASCII characters is the goal, then using a MIME-compliant mail-reader is the right way to achieve this. Adding presentation-specific stuff like characterset conversion to rmail is not. -- Henrik Storner | "Those are my principles. If you don't storner@osiris.ping.dk | like them, I have others." | Groucho Marx ------------------------------ Date: Wed, 19 Apr 1995 17:51:06 +0200 (MESZ) From: eurjof@eur.sas.com Subject: Translation table in UUPC/extended. To: UUPC/Extended mailing list Hi Henrik, On Mon, 17 Apr 1995 storner@osiris.ping.dk wrote: > Characterset translations do not belong in the MTA (rmail); this is > best performed in the user agent - the program used to read mail. I can only second this! Any mail should stay in its original format as long as possible to avoid any loss of information. It's the job of the MUA to display the mail correctly. If rmail would already do character translation, UUPC could no longer be used to gate mails or to transfer mails with different character sets (see RFC 1521) or different code page settings on the PC. Also some graphic MUAs can display more than 256 different character i.e. to support 32 bit character sets like proposed in RFC 1642. > The MTA has no way of knowing which characterset is active when the > mail will eventually be displayed; for instance, on a DOS system > with Windows installed there are _two_ native charactersets: The > codepage 437/850/whatever when running in DOS, and ISO 8859/1 (Latin-1) > when running Windows. If there are mail readers for both, then which > one should an RMAIL-based conversion cater for? And what if you use the PC (maybe running OS/2 or Windows NT) only for storing the mails and reading them from a different PC i.e. using a network drive or a TCP/IP protocol like IMAP4? > IMHO, if transparent handling of non-ASCII characters is the goal, > then using a MIME-compliant mail-reader is the right way to achieve > this. Adding presentation-specific stuff like characterset conversion > to rmail is not. Unfortunately, there are still too many MTAs out in the Internet that only transport 7 bit characters. I don't want UUPC/Extended to become yet another one of this category. Cheers, Jochen ------------------------------ Date: Wed, 19 Apr 1995 01:20:00 EST From: sizemorj@witness.com Subject: Waffle and UUPC To: UUPC/Extended mailing list Is anyone out there using Waffle as a frontend to UUPC? Is it possible to use Waffle multi-user capability with UUPC as the mail and news transport? If so how? Thanks! [Jim Sizemore, 31-Mar-94] ________________________________________________________________________ James E. Sizemore Jr. Email: sizemorj@witness.com http://jamcha.witness.com More Email BBS: (216)932-6110 ------------------------------------------------------------------------ ------------------------------ Date: Wed, 19 Apr 95 12:14:32 CDT From: gilbert@whatif.dseg.ti.com Subject: Waffle and UUPC To: UUPC/Extended mailing list If anyone has info on this topic, please email me as well. I had used UUPC in the past, and liked it. But I've been using WAFFLE recently because of its BBS frontend, and has to use its own uucp mechanism as well. I wish I could use UUPC's mechanism, which is more open, and allows me to connect to more frontend programs, while keeping the ability to do BBS. Hence the interest. Any ideas are welcome. Regards and thanks, Gilbert ----- Begin Included Message ----- From kendra!kew.com!vms-daemon@pioneer.ci.net Wed Apr 19 05:43:43 1995 Date: Wed, 19 Apr 1995 01:20:00 EST From: sizemorj@witness.com Subject: Waffle and UUPC To: UUPC/Extended mailing list Organization: More Email BBS 216-932-6110 Sender: uupc-info-request@kew.com X-Mailer: Rnf 0.78 Content-Length: 493 Is anyone out there using Waffle as a frontend to UUPC? Is it possible to use Waffle multi-user capability with UUPC as the mail and news transport? If so how? Thanks! [Jim Sizemore, 31-Mar-94] ________________________________________________________________________ James E. Sizemore Jr. Email: sizemorj@witness.com http://jamcha.witness.com More Email BBS: (216)932-6110 ------------------------------------------------------------------------ ----- End Included Message ----- ------------------------------ Date: 17 Apr 1995 00:25:00 +0100 From: hajo@quijote.in-berlin.de Subject: Wrong path line To: UUPC/Extended mailing list Hi Drew, Du schriebst am 15.04.95: > Systems tend to see that the local system not on the from line and stuff > it on themselves. UUPC/extended's preference it identify itself with > it's full domain seems to be viewed as a bug by many other packages. If "many other" means both smail and sendmail, you're in trouble.... ;-) I just tried with my DOS system at the site where I log in with UUPC. I used the same settings, normal RMail transfer. The FQDN was put in the path, the double name did not appear. Therefore, the FQDN in the path can't be the reason. Look into the header of this message. I will deliver it via the same system, fog.in-berlin.de, a Linux system where I call in to try UUPC. Again I reconfigured quijote to use the same transport as my UUPC system hanta.in-berlin.de. A local Unix guru said that the double entry is normally caused by wrong handling of header versus "envelope", whatever that means. > It called again at 2359? Hmm. A bug. In any case, just drop the > parameter, -e says to exit at that time, which is not what you want. I'm just trying, no problem. Since I cannot use the current Mail and News software for UUPC (most of my mail is written in German, and if using "mail", 1/4 of my incoming mail would be complaints about unreadable characters), I use the time to set up connections to work as expected. In the moment, I try to set up a regular UUCP call in the same fashion as with my DOS site. I have configured "quijote" to do one call between time A and time B (no problem), with unlimited BUSY retries (no problem), three connect tries maximum (???), and two login tries maximum (???) to cancel the event. One of the reasons for this setup: Since Unix-Sysadmins know that Unix is so phantastic that their system is never down, many of them let the modem take up the phone with S0=1 standard config, instead of taking up the phone with the computer by ATA after RING. If their Unix is not as phantastic as promised, I'm a poor man if not at home. I guess that UUPC can handle NO XXXXX and failed login dialogues different from BUSY somehow, but even by reading the docs back and forth, I can't figure out how. hajo -- ----[Hans-Joachim Zierke ]---------------------------------------------- [Rathenower Strasse 23 ] [D-10559 Berlin-Moabit] hajo@quijote.in-berlin.de [ +49-30 / 394 84 45] ----[Fax:(0)30 / 394 84 47]---------------------------------------------- ------------------------------ End of UUPC-Info-Request Digest ******************************