Date: Sun, 14 Dec 97 16:54:41 EST From: Snuffles@kew.com Subject: UUPC-Info-Request Digest 1997 #22 To: uupc-info-digest@kew.com Message-ID: Reply-To: UUPC-Info-Request@kew.com UUPC-Info-Request Digest Sun, 14 Dec 97 Volume 1997: Issue 22 Today's Topics: [Q]Address does not contain at sign (@) [Q]bounce option and rmail log Apologies digiboards under UUPC/extended and NT Fw: pmail/mail4u support in UUPC/extended 1.12u ix.netcom.com BANNED from kew.com pmail/mail4u support in UUPC/extended 1.12u (2 msgs) rmail Queue Dir Support UUPC/extended import file errors 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: Fri, 05 Dec 1997 19:28:04 -0500 From: Drew Derbyshire Subject: [Q]Address does not contain at sign (@) To: Tsubasa Sakurai Tsubasa Sakurai wrote: > I have trouble UUPC/Extended Ver1.12t with uusmtpd. > > I test Mailing List Soft for smtp,then > > 4 <<< MAIL FROM: > getOperands Returning client 4 token > 4 >>> 501 : Address does not contain at sign (@) > > xxxxxxx is mailing list's name. > > And sent to localdomain address without @localdomainname, > I got same error. You will. We require the mail user agent (such as netscape) to provide the full address. Why isn't the client providing the domain name? > Could you tell me How to disable "Address check"? You can't without rebuilding the source. RFC-821 addresses require a domain name, as a mailbox is defined as: ::= "@" This is enforced in part to help fight SPAM -- it prevents remote sites presenting local-part only addresses which would then pass as local addresses through additional filters. -- Internet: ahd@kew.com Voice: 781-279-9812 May the source be with you --DECWars ------------------------------ Date: Sat, 06 Dec 1997 09:27:18 -0500 From: Drew Derbyshire Subject: [Q]bounce option and rmail log To: Tsubasa Sakurai It's a bug, we hope to have it corrected for 1.12u. Tsubasa Sakurai wrote: > > Help me plese,for UUPC/extended. > > I'd like to use options=bounce. > But,To: address is not correct. > For ex. > Subject: Failed mail for sakusaku > Date:Mon, 01 Dec 1997 10:54:38 +0900 > From:"Unix to Unix Copy" > To:t-sakurai@iijnet > CC:postmaster@ntb.co.jp > > iijnet is my provider's name and NOT t-sakurai's domain name. > > My UUPC.RC > NodeName=ntbgw > Domain=ntb.co.jp > Mailserv=iijnet > > I found out same in rmail.log (It's not only 1.12t) > 12/05-20:45 RMAIL: UUPC/extended 1.12t (Nov 25 1997 22:57:28) > 12/05-20:45 Spooling mail from tsakurai@ntbgw to help@kew.com via > iijnet > 12/06-09:50 rmail: UUPC/extended 1.12t (Nov 25 1997 22:57:28) > 12/06-09:50 Delivering mail from ahd@iijnet to tsakurai > I want tsakurai@ntb.co.jp (not tsakurai@ntbgw) and > ahd@kew.com (not ahd@iijnet). > > Whrer am I mistake ? > > Thank you for reading. > > #StigWare SMTP Server is error occured for Netscape Ver4 > #uusmtpd is work well both(netscape ver3 and 4) :-) > -- > Tsubasa Sakurai > tsakurai@ntb.co.jp -- Internet: ahd@kew.com Voice: 781-279-9812 "Throw the terminal server in the pond!" - ahd, out of context ------------------------------ Date: Sun, 07 Dec 1997 21:47:38 -0500 From: MarchHare@momeraths.org (Sysop) Subject: Apologies To: uupc-info@kew.com -----BEGIN PGP SIGNED MESSAGE----- I've switched ISP's for various reasons, and the old ISP did not handle the conversion very well. It appears that they hung on to some incoming mail :( However, I am still around, and I appear to be receiving email correctly now. John - -- //------------------------------------------------------------------------ // momerath@apk.net sevot yhtils eht dna ,gillirb sawT` // MarchHare@momeraths.org ebaw eht ni elbmig dna eryg diD // ,sevogorob eht erew ysmim llA // .ebargtuo shtar emom eht dnA // In case of stupidity, break glass. -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 iQCVAwUBNItf3bMHJ4yl8MPNAQEC3AP+JAG48EOp/rsHAJYK4SBiAqSKHu+9yn7k 6uZYgOw2+RaRW0QAB6hKHrGp2q8sbX+nidZrYPMMCln6fFlfw+3YKLB5Cx1lYfz2 1diRC3JumfOeq6fcr5rPnExMO3rvHsurMjS3FKzSCQqR8erZ8iFW1zQF+EAkXCNY MFKW+P1usDY= =JQkp -----END PGP SIGNATURE----- ------------------------------ Date: Tue, 9 Dec 1997 20:03:00 -0500 (EST) From: Drew Derbyshire Subject: digiboards under UUPC/extended and NT To: uupc-info@pandora.hh.kew.com has anyone used digiboards with UUPC/extended and NT? I have reports the open() call fails with a funky error ... -ahd- -- Drew Derbyshire Internet: ahd@kew.com Kendra Electronic Wonderworks Telephone: 781-279-9812 "If I have to ask, I don't want to know the answer." ------------------------------ Date: Thu, 04 Dec 1997 20:19:14 -0500 From: Drew Derbyshire Subject: Fw: pmail/mail4u support in UUPC/extended 1.12u To: Erwin Authried , Had I properly reread the original mail message before I did the code, I might have done exactly as the original user suggested via + in the aliases file, but the advantages of the current code are such that if it works, I'll leave it that way. If it DOESN'T work, tell me what needs to be changed. (Failing to trap "permission denied" open errors doesn't count, that's plain old sloppy programming.) Erwin Authried wrote: > Thanks for adding the queue dir support. However, wouldn't a design like the suggested pmail support in the alias file > name: +\ > be more flexible? [I'd like to but ...] Yes, but that's not the primary design goal for me. Remember, this is just an off-shoot of normal RMAIL delivery. I'm working in the existing RMAIL program, which already has numerous code paths which I don't want to add to, especially with SMTP delivery (of much more general use to people) for OS/2 and NT bloating the code. I'm up to my ass in TCP/IP alligators here, and this was just a side trip. :-) I was able to do a very small code change to add the function as documented, merely changing the file name written by the current local delivery routine in a similar manner as to how the "directory" option affects delivery. This allows: * Fewer lines of code, meaning it can go into the 1.12u release reasonably tested. * Compact code, meaning it can be included in the memory constrained DOS version of RMAIL. * Consistency, meaning it makes all mailboxes delivered the same way (except full path names in such as those in alias and forward files), and easier documented. * Global Access to the configuration -- if I need to add support for gathering these mailboxes in MAIL, the option information is known to UUPC/extended. Alias information is not available when reading mail. > Since you don't want to support my suggested write/rename scheme, > would a support of lockfiles be more to your taste? I was thinking > of lockfiles similar to the implementation in procmail: > rc-file option like lockfilename=, > When such an option exists, is created in the same > directory where the message is written, and removed after writing is > complete. This might be usable for mailbox files too, if somebody has > an environment where the windows locking mechanism can't be used. Regarding lock files, the entire UUPC/extended suite _strongly_ relies on opening files for output with DENY_ALL to ensure locking; the only lock files we use are generally for those cases where a lock is needed for a LOGICAL resource, such as a remote system or a UUXQT queue. As an aside, even our lock files also use DENY_ALL as the protocol, not merely the existence of the file. Procmail needs lock files because UNIX file locking is optional, so applications might not follow the protocol. We just don't support multi-tasking environments where locking is not supported, so it's moot point for us. I especially would not want lock files enabled for mailbox files, the second open could double the network overhead of delivering a message if the mail program itself is stored locally. [Sorry.] -ahd- -- Internet: ahd@kew.com Voice: 781-279-9812 "Nuke those VMBLOK's and them suckers is history" - J. J. McMahon, out of context ------------------------------ Date: Sat, 13 Dec 1997 12:39:30 -0500 (EST) From: Drew Derbyshire Subject: ix.netcom.com BANNED from kew.com To: abuse@netcom.com Due to NETCOM's total inability to monitor your users enough to prevent massive SPAMMING of our site, we have banned ix.netcom.com from sending kew.com ANY mail in the future. This is the first otherwise valid domain we have _ever_ had to ban -- CIS, AOL, and Earthlink have all managed to keep some kind of lid on SPAM, a talent NETCOM clearly lacks. Should you clean up your act and keep your SPAMMers away from us, we will be happy to lift the ban. All users of netcom.com on kew.com mailing lists will be dropped immediately. -ahd- ------------------------------ Date: Wed, 03 Dec 1997 08:31:05 -0500 From: "Drew Derbyshire - UUPC/Extended Support" Subject: pmail/mail4u support in UUPC/extended 1.12u To: "UUPC Mailing List" The 1.12u release of UUPC/extended will include support for writing one message per file as required by the PMAIL and MAIL4U programs. The pattern used will be: \uupc\mail\userid\UUMX####.ext Where: '\uupc\mail' is the user specified mail directory. 'userid' is the user id receiving the mail, truncated to eight characters. 'UUMX' is a literal. '####' is the unique alphanumeric sequence generated by UUPC/extended. This actually the same counter used by the internal UUPC/extended spool, and is unique across the system for 36*36*36*36 or 1.8 million messages. '.ext' is the extension the user specified in the UUPC.RC, if any. If omitted, no extension is added to each file. The UUPC/extended seperator line of binary ones is NOT written the mailboxes. The author of mail4u asked that the mailboxes be written under a different name and then renamed to prevent race conditions (UUPC/extended code tends to rely on locking instead in such conditions). However due the nature of the change which was in the middle of existing code, I was not able to provide this feature without further abusing the code, and so omitted it. (UUPC/extended does rely on locking in a stable fashion, and it's also faster.) Sorry for the omission. The option will be enabled by options=uniquemailbox in the UUPC.RC file. The UUPC/extended MAIL program WILL NOT be able to read this format. -ahd- ------------------------------ Date: Thu, 4 Dec 1997 18:26:28 +1300 From: stephen@digitech.co.nz Subject: pmail/mail4u support in UUPC/extended 1.12u To: "UUPC Mailing List" ** Reply to note from "Drew Derbyshire - UUPC/Extended Support" Wed, 03 Dec 1997 08:31:05 -0500 > > The 1.12u release of UUPC/extended will include support for writing one > message per file as required by the PMAIL and MAIL4U programs. The > pattern used will be: > > \uupc\mail\userid\UUMX####.ext > > Where: > > '\uupc\mail' is the user specified mail directory. > > 'userid' is the user id receiving the mail, truncated to eight > characters. > > 'UUMX' is a literal. > > '####' is the unique alphanumeric sequence generated by > UUPC/extended. This actually the same counter used by the internal > UUPC/extended spool, and is unique across the system for 36*36*36*36 > or 1.8 million messages. > > '.ext' is the extension the user specified in the UUPC.RC, if any. > If omitted, no extension is added to each file. Thanks for adding this - it will eliminate the need for running uu2pc after uuxqt to convert the formats. We currently do this for use with the Pegasus (Windows) and Post Road (OS/2) mailers. However, the current setup for my company using uu2pc puts the mail files in the directory \uupc\mail\userid\inbasket. To use the uniquemailbox option, I will need to go to all the PCs in my company and change the directory in which they look for mail - not impossible, but a job to be avoided! So, would it be possible to have some flexibility and control over the directory used for the uniquemailbox option? -- Stephen Worthington Telephone: +64-4-569 6764 (home) Digi-Tech Communications Ltd +64-4-389 8909 (work) stephen@digitech.co.nz (work) Fax: +64-4-389 9901 (work) stephen@inisant.actrix.gen.nz (home) http://www.digitech.co.nz ------------------------------ Date: Tue, 02 Dec 1997 19:44:21 -0500 From: Drew Derbyshire Subject: rmail Queue Dir Support To: Erwin Authried Erwin Authried wrote: > > Drew, > here are my test results with RMAIL 1.12t (32bit) and the pipe driver: > > My alias file for testing is: > > testusr: aa > ab > > aa: |deliv.exe c:\tmp\aa > > ab: |deliv.exe c:\tmp\ab > > deliv.exe is my delivery program that writes into the given queue directory. > > 1) localdomain=... fixes the errormessage of rmail This will be properly corrected in 1.12u, as previously noted. > 2) with Options=imfile: mail to testusr works (1.12r crashes with this configuration) > 3) with Options=noimfile: mail to testusr is correctly delivered to recipient aa, > for recipient "ab" a file with length zero is created. (same as in 1.12r) > Generally spoken, the first recipient is handled correctly, for all other > recipients a zero length file is created. No error is reported. Excellent description, I was able to fix the problem easily. In imfile.c, function executeIMFCommand, the work file is closed and reopened. The reopen is done with "w+" when it should be "a+". This will be corrected in 1.12u, of course. > 4) if postmaster=testusr, mail to testusr is not delivered to the two aliases "aa", "ab". > Instead, the message is written to two mailboxes aa.mxt and ab.mxt. > I don't know if this behaviour is a bug, there is a simple workaround: > I have to make sure that postmaster is an alias with exactly one recipient. Postmaster disables certain functions to avoid loops when bouncing mail. It is a feature, more or less. -- Internet: ahd@kew.com Voice: 781-279-9812 "Sorry, but support is not currently available via email." - MicroSoft.COM ------------------------------ Date: Sun, 14 Dec 1997 14:25:22 -0500 From: Drew Derbyshire Subject: UUPC/extended import file errors To: master@iaas.msu.su, UUPC-Info Mailing List UUPC/extended has a bug in the file name routines which convert non-compliant names to valid DOS Names. If a short name has invalid characters, it is likely to be copied in a way which results in uninitialize memory being accessed. This may be the cause of the crashes of the NEWS components under OS/2. It will be corrected as part of 1.12u. In addition ... Michail Vidiassov wrote: > > > ---------------------------------------------------------------------- > > > 2) There are 2 bugs in long filename support in WIN32 environment: > > > names with a dot truncated and names on FAT truncated. You have already > > > got a fix with TAPI version of 1.12r, but the bugs are still alive in 1.12s. As he correctly described ... a) Period was dropped from valid character set for long names. b) NT file systems (VFAT) which allow long file names were report as not allowing them. Both of these errors are corrected in 1.12u. In addition, NT file system queries are cached in the same manner as OS/2 queries, which should provide a good performance boost for long running servers and/or file system scanners (in particularm, some news programs). -- Internet: ahd@kew.com Voice: 781-279-9812 "You can't get there from here" -ahd-, giving directions to NJ from Rest Area on I-88 in the heart of NY Catskills ------------------------------ End of UUPC-Info-Request Digest ******************************