Date: Fri, 25 Apr 97 23:52:27 EDT From: Snuffles@kew.com Subject: UUPC-Info-Request Digest 1997 #9 To: uupc-info-digest@kew.com Message-ID: Reply-To: UUPC-Info-Request@kew.com UUPC-Info-Request Digest Fri, 25 Apr 97 Volume 1997: Issue 9 Today's Topics: BANG! batching to junk Bug (?) in imfile.c Gateway delivery bug introduced in RMAIL 1.12r personal mailer problem with e-mail (2 msgs) Reent- lines ... (2 msgs) TAPI Works Fine uucico aborting at line 590 UUxqt and Rmail problems 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. Note: Questions on UUPC/extended itself which are not of general interest should be sent to help@kew.com, not to the mailing list. Nor questions should be posted on Usenet, we don't read it. (Much.) ---------------------------------------------------------------------- Date: Tue, 22 Apr 1997 23:42:33 -0500 From: "Drew Derbyshire - UUPC/extended Support" Subject: BANG! To: infoweb.abs.net!krs@infoweb.abs.net On 22 Nov 1996 15:02:50 +0100, infoweb.abs.net!krs@infoweb.abs.net wrote: > I'm setting up UUPC v1.12r on Windows95, but am having problem getting > the RFC-822 headers I require > > What I want is: > From Sysop Tue, Oct 29, 1996 18:47:26 GMT remote from infoweb.abs.net > > Or perhaps: > From Sysop@infoweb.abs.net Tue, Oct 29, 1996 18:47:26 GMT > > What I get is: > From Sysop!infoweb.abs.net Tue, Oct 29, 1996 18:47:26 GMT remote from > infoweb > > I had thought the 'nobang' option might be useful, but it doesn't seem > to have any effect. I may add this option in 1.12s. -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 Hanlon's Razor: Never attribute to malice that which can be adequately explained by stupidity. ------------------------------ Date: Fri, 25 Apr 1997 22:51:54 -0500 From: "Drew Derbyshire - UUPC/Extended Support" Subject: batching to junk To: "Henning Moeller" On Wed, 7 Aug 96 10:10:57 +0000, "Henning Moeller" wrote: > I'm using UUPC/extended version 1.12r on OS/2 Warp (FP 17). I don't do any > feeding but just polling my mail+news and reading them with elm+trn. > > I've got a problem which seems to be associated with my upgrading from > version 1.12j. I've written a script which scans the junk group and does > create new directories according the newsgroups: header in these postings. > This used to work fine with 1.12j but doesn't do with 1.12r, because the > articles, for which no newsgroup-directory yet exists aren't moved to junk > anymore but are discarded. Following is a small part of my newsrun.log: > > 08/07-02:52 newsrun: UUPC/extended 1.12r (Jan 20 1996 10:45:15) > 08/07-02:52 deliver_article: Article <4u2l19$mcu@quake.garlic.com> undeliverable to groups comp.os.os2.moderated, distribution world > 08/07-02:52 deliver_article: Article <4u2l1d$gda@quake.garlic.com> undeliverable to groups comp.os.os2.moderated, distribution world > 08/07-02:52 deliver_article: Article <4u2l1g$mdo@quake.garlic.com> undeliverable to groups comp.os.os2.moderated, distribution world > 08/07-02:52 deliver_article: Article <4u2l1l$gds@quake.garlic.com> undeliverable to groups comp.os.os2.moderated, distribution world > 08/07-02:52 deliver_article: Article <4u2l1o$ge0@quake.garlic.com> undeliverable to groups comp.os.os2.moderated, distribution world > 08/07-02:52 deliver_article: Article <4u2l1t$me6@quake.garlic.com> undeliverable to groups comp.os.os2.moderated, distribution world > 08/07-02:52 deliver_article: Article <4u2l23$oei@quake.garlic.com> undeliverable to groups comp.os.os2.moderated, distribution world > 08/07-02:52 deliver_article: Article <4u2ljc$snk@quake.garlic.com> undeliverable to groups comp.os.os2.moderated, distribution world > 08/07-02:52 deliver_article: Article <4u2lj9$sni@quake.garlic.com> undeliverable to groups comp.os.os2.moderated, distribution world > 08/07-02:52 newsrun: Received 44 articles, of which 0 were bad and 9 were undeliverable. > 08/07-02:52 newsrun: Retained 35 articles, of which 0 were duplicates and 0 were junked. > > I can't make out my mistake. Your (excellent) documentation says about > newsrun (Okay, you'll know but I want to claim that I've read it...): > > 7. If no valid local groups are defined and the local group junk exists in > the ACTIVE file, the article is saved to junk. Otherwise, the article > is discarded. > > I also have skimmed through the "Changes" section but didn't find any hint > to my problem. > > Now, why is my junk group empty all the time? Any idea? A bug in 1.12r. If you have source and a compiler, there is an statement: if ( snum ); That's the error, it will be fixed in 1.12s, which I hope to turn around in the month. -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 "That which thy fathers have bequeathed to thee, earn it anew if thou wouldst possess it." - Goethe "Faust" ------------------------------ Date: Fri, 25 Apr 1997 08:55:12 -0500 From: "Drew Derbyshire - UUPC/Extended Support" Subject: Bug (?) in imfile.c To: "Gerald Me" On Mon, 21 Apr 1997 20:04:25 +8, "Gerald Me" wrote: > Previously I send in a mail regarding error of > > imunload: malloc: not enought memory. > > I have trace throught the log with your program and found that may be > there is something wrong in the executeIMFcommand routines within the > Imfile.C program. You're correct, the free was missing. > In line 991 of imfile.c under the executeIMFcommand routine, after > the mktempname( tempName, "TMP" ); statement, should the FOPEN be > open for tempName instead of imf->filename? > > I am reading your soruce from UPC12prs?.ZIP. Yes, you're also correct -- in addition, the file should always be opened in text mode. This will be corrected in 1.12s of UUPC/extended. BTW, notify your ISP that that the from address is being mangled on your mail -- we do not accept mail from 'invalid sites' to avoid getting SPAM mail from bogus (fake) domains, and as sent your message had a from address of 'mailer': Apr 25 08:01:19 athena sendmail[6012]: Ruleset check_mail () rejection: 418 ... invalid host name -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 "OSI: Same day service in a nano-second world." - Van Jacobson ------------------------------ Date: Fri, 25 Apr 1997 23:17:42 -0500 From: "Drew Derbyshire - UUPC/Extended Support" Subject: Gateway delivery bug introduced in RMAIL 1.12r To: "Stephen Marquard" On Tue, 20 Aug 1996 10:34:39 +0200, "Stephen Marquard" wrote: > Hi Drew > > It looks like a bug relating to the IMFILE / Gateway delivery stuff > has been introduced between 1.12p and 1.12r. > > Two log file entries follow, operating on exactly the same queue > directory (different debug levels). > > 08/20-10:25 rmail: UUPC/extended 1.12p (Nov 8 1995 07:29:54) > (2) imopen: Using disk for 0 byte file (max i-m is 65000) > (1) Gatewaying mail (713 bytes) from scm@picasso to one@thorin via thorin using "uulan.exe" > (1) Gatewaying mail (713 bytes) from scm@picasso to two@thorin via thorin using "uulan.exe" > (1) Gatewaying mail (713 bytes) from scm@picasso to three@thorin via thorin using "uulan.exe" > > Under 1.12r, deliveries to the 2nd and subsequent addresses on the > same rmail command line don't get any input passed to the gateway > process. At least one bug, which I posted a comment on yesteday, was found in the underlying gateway code, and will be fixed in 1.12s. I'll look for more. This was under DOS? Does it fail with both imfile or noimfile set? -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 "That which thy fathers have bequeathed to thee, earn it anew if thou wouldst possess it." - Goethe "Faust" ------------------------------ Date: Fri, 25 Apr 1997 23:08:34 -0500 From: "Drew Derbyshire - UUPC/Extended Support" Subject: personal mailer To: "=?iso-8859-1?q?K.-P.__Kirchd=F6rfer?=" On Sat, 26 Apr 97 03:41:42 +0100, "=?iso-8859-1?q?K.-P._Kirchd=F6rfer?=" wrote: > >> Any news about the next release of UUPC/extended? > > > >By the end of May 1997. > > Good news. A word about new features, like smtp, or major bug fixes? smtp is doubtful for may 1997. Numerous small bug fixes in news, imfile support, and perhaps UUCP From lines. -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 "That which thy fathers have bequeathed to thee, earn it anew if thou wouldst possess it." - Goethe "Faust" ------------------------------ Date: Wed, 23 Apr 1997 21:49:17 +0200 From: "Enrico Kliesch" Subject: problem with e-mail To: Hello this Enrico. I am looking for a programm which can split a wildcard e-mail in ca. 20 virtual e-mail. The problem is we are not woking in a net, we don't have linux. We only have Windows95 as a single user system. *********************************************************** Mind Building - another kind of music my Website: http://www.geocities.com/hollywood/hills/4846 my E-Mail: enrico.kliesch@student.uni-halle.de ********************************************************** ------------------------------ Date: Wed, 23 Apr 1997 19:48:57 -0400 From: "Drew Derbyshire - UUPC/Extended Support" Subject: problem with e-mail To: "Enrico Kliesch" On Wed, 23 Apr 1997 21:49:17 +0200, "Enrico Kliesch" wrote: > Hello this Enrico. I am looking for a programm which can split a wildcard > e-mail in ca. 20 virtual e-mail. The problem is we are not woking in a net, > we don't have linux. We only have Windows95 as a single user system. Define wildcard. You could define a alias list in UUPC/extended to send it to 20 addresses, that is no problem ... -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 GOD is REAL unless declared INTEGER. ------------------------------ Date: Wed, 23 Apr 1997 08:20:05 -0500 From: "Drew Derbyshire - UUPC/extended Support" Subject: Reent- lines ... To: "Jan Edholm" Check your mailer, it ignored the reply-to line. (Effective later this week, all in-bound mail to xhelp will bounce, so fix your problem). On Wed, 23 Apr 1997 09:13:11 +0200, "Jan Edholm" wrote: > On 22 Apr 97 at 18:03, Drew Derbyshire - UUPC/extend wrote: > > On Wed, 25 Sep 1996 09:27:34 +1200, AWood@pdl-elec.co.nz wrote: > > > The RFC822 standard says that multiple Resent lines are not a good > > > idea and therefore the mail message may not make it through the > > > system but I thought since the change is so small that you may like > > > to do it. > > > > Not sure if a good idea or not. Comments from the list? > > This is undefined according to rfc822, right? > Is it possible to add a leading 'X-[Comment]' to the extra > Resent-lines? -Then it would be clearly defined... The mail program does this -- rmail will not attempt to add-resent lines, so I'm in a mood to mangle the ones already there. -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 "Your arm felt good wrapped around my shoulder And I -- I felt I like I belonged And I -- I felt I could be someone . . ." - Tracey Chapman ------------------------------ Date: Wed, 23 Apr 1997 08:23:08 -0500 From: "Drew Derbyshire - UUPC/extended Support" Subject: Reent- lines ... To: "Boris Popov" Check your mail program, it ignored the reply-to field -- mail to this address will BOUNCE after the end of the week. On Wed, 23 Apr 1997 18:43:43 +0600, "Boris Popov" wrote: > > > ----------------------------------------------------- > > > The RFC822 standard says that multiple Resent lines are not a good > > > idea and therefore the mail message may not make it through the > > > system but I thought since the change is so small that you may like > > > to do it. > > > > Not sure if a good idea or not. Comments from the list? > > -- > > Yes, it's a good idea, because not only Pegasus Mail put an additional > 'Resent' lines in header. No, the correct action is get Pegasus mail fixed. Have you contacted the authors? > And it's not always possible to parse headers in > the script. Of course, order of new Resent lines are undefined, some programs > put it at the begining of original header and some at the end. So, there must > be an option like 'useresentlast' which means that we must use last resent > line, and by default the first one. That is exactly WHY we refuse to process them. Such behavior depends on the particular message in question, and will almost always be wrong. -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 "Your arm felt good wrapped around my shoulder And I -- I felt I like I belonged And I -- I felt I could be someone . . ." - Tracey Chapman ------------------------------ Date: Fri, 25 Apr 1997 10:20:24 -0400 From: "M. Scott Wills" Subject: TAPI Works Fine To: Drew Derbyshire - UUPC/Extended Support I never got round to posting the result of my TAPI uucico quest. The version I received from the author of the TAPI mods works just fine. My problems in using it related to the fact that I had copied a real *.mdm modem decription file and just modified the fields suggested in the TAPI uucico docs. As it turns out, one of the common entries (I think it was the modem init string) needs to be blank. Otherwise, the code tries to send the init string after opening the TAPI connection. Of course this fails to produce the expected response (probably "OK"), so the dialer code thinks the connection failed. The moral is, if you start with the minimum number of fields required by the TAPI uucico, it works fine. The error checking could be improved to avoid this situation, but it may be better to go ahead and provide TAPI capability with some caveats and then improve the logic later. Just thought I should pass along what I'd learned. Acutally, I've switched to POP for my local transport. Scott ---------------------------------------------------------------------------- M. Scott Wills, mwills@ge-harris.com, Voice: 407-242-5494, Fax: 407-242-4223 ------------------------------ Date: Fri, 25 Apr 1997 22:58:44 -0500 From: "Drew Derbyshire - UUPC/Extended Support" Subject: uucico aborting at line 590 To: "Mark Jonckheere" On Tue, 13 Aug 1996 00:04:21 +0000, "Mark Jonckheere" wrote: > I have a problem using uupc 1.12p on windows 3.11 over a tcp/ip > connection. When I give two uucp commands on my UNIX machine to send a > file to my pc, it will start two uucico processes at the same time. The > first one transmits the two files, the second one fails and does a number > of retries. At the same time on the pc uupoll restarts uucico after > running uuxqt. This second uucico aborts at line 590 because > "tpassiveopen: bind(pollingSock)failed", "bind: (10048) Address already > in use". > > I suppose that due to a race condition the second uucico(UNIX) connection > is already sent to the first uucico(PC) just before it exits and as long > as the second uucico(UNIX) tries to send a login command, the address > remains in use. > > There is no way to control my UNIX host when to decide to send something > to my PC, so this problem occurs +/- once every day. Two workarounds: Switch to Taylor UUCP on the UNIX which is better in general. It has a parameter to prevent multiple starts within a specified time period; I set a local system to 1 minute to prevent such overdriving, although being OS/2 it's not the issue you seem to have, just wanting not wanting to run too many processes. Also, you can tell uucp not to start UUCICO when it runs, normally via the -r flag. > I tried to modify the listen call with a queue of 1 instead of 2, I > don't know if this is a good solution because I can not recompile the > program with visual C++ 1.5. I'll try to get the next version (not 1.12s, but after it) to compile with 1.52. No promises, since Windows 95 is stable with the 32 bit version and we never claimed the Windows 3.1 version any good. > Maybe a sleep of 1 minute followed by a retry after an unsuccessfull bind > would be a solution for my problem? Dunno. uupoll should sleep for an increasing period after each failure, if the socket is not timing out you/I have got a deeper problem. Run netstat and see if the socket is still active after ~ 10 minutes. -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 "That which thy fathers have bequeathed to thee, earn it anew if thou wouldst possess it." - Goethe "Faust" ------------------------------ Date: Wed, 23 Apr 1997 00:32:01 -0500 From: "Drew Derbyshire - UUPC/extended Support" Subject: UUxqt and Rmail problems To: ash@gn.apc.org On Fri, 20 Dec 1996 20:24:10 +0000, "Ashley Drees" wrote: > Hi. > > My ISP often sends confirm messages with a from address of > From: %@foo.bar.. > > the "r" release does not like this.. nor does the "p", is there a fix > or is there a way round this.. at the moment I use a small perl > script to search the headers.. this is slow, but does work.. The header is impossible to parse ... why is the ISP sending such trash? We kill 'em, as you have found out. ANy other users having a problem with this? -- Drew Derbyshire UUPC/extended e-mail: software@kew.com Telephone: 617-279-9712 General Custer plotted strategy on Windows NT. ------------------------------ End of UUPC-Info-Request Digest ******************************