Archive-Date: Tue, 01 Dec 1992 00:08:38 CST Sender: goathunter@WKUVX1.BITNET Date: Tue, 01 Dec 1992 00:05:25 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00964694.C474EE20.10082@WKUVX1.BITNET> Subject: MX-LIST Administrivia: Monthly Post Last modified: 2-JUL-1992 00:40 01:26 (Created) Welcome to MX-List@WKUVX1.BITNET, an electronic mailing list established for the discussion of the Message Exchange mail software. This is a routine posting you will see from time to time on MX-List. The MX-List archives are maintained at ARCHIVES@WKUVX1.BITNET. To get a copy of any month's postings, send an e-mail message with the body SEND MX-List.yyyy-mm to ARCHIVES@WKUVX1.BITNET, where "yyyy" is the year and "mm" is the numeric representation of the month. For example, the message SENDME MX-List.1992-04 will send the archives for April 1992. To remove yourself from the mailing list, send the following command to LISTSERV@WKUVX1.BITNET: SIGNOFF MX-List LISTSERV supports a few other commands for your convenience. The following commands can be handled automatically by the list processor: SIGNOFF MX-List - to remove yourself from the list REVIEW MX-List - to get a list of subscribers QUERY MX-List - to get the status of your entry on the list SET MX-List NOMAIL - to remain on the list but not receive mail SET MX-List MAIL - to resume receiving mail from the list SET MX-List CONCEAL - to not report your address in a REVIEW SET MX-List NOCONCEAL - to report your address in a REVIEW SET MX-List REPRO - to receive posts you make to MX-List SET MX-List NOREPRO - to not receive posts you make to MX-List LIST - to get a list of mailing lists served by WKUVX1 HELP - to receive a help file By default, subscriptions are set to MAIL, REPRO, NOCONCEAL. If you have any questions, comments, or suggestions about MX-List, please contact the list owner at the address below. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Hunter Goatley, VAX Systems Programmer goathunter@WKUVX1.BITNET Western Kentucky University Academic Computing, STH 226 (502) 745-5251 Bowling Green, KY 42101 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ================================================================================ Archive-Date: Tue, 01 Dec 1992 12:57:29 CST Sender: mckeetr@cvse.cortex.prospect.com Date: Tue, 01 Dec 1992 13:42:59 EST From: "Tim McKee, 803-366-2620" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: mckeetr@cvse Message-ID: <00964706.FA1BCC20.1739@cvse.cortex.prospect.com> Subject: Microsoft mail linkage??? Is there any UUCP package that will interface with MICROSOFT MAIL on the MACINTOSH? We have a division that uses the product and we need to integrate them with our VAX systems running MX and VMS-UUCP. (They are not actually remote, but I can treat them as such...) Any suggestions? ============================================== Timothy R. McKee Senior Consultant - VAX/VMS Internals Cortex Corporation - SouthEast Field Office Phone: (803) 366-2620 FAX: (803) 366-5417 ================================================================================ Archive-Date: Tue, 01 Dec 1992 21:36:13 CST Sender: fisk@mayo.edu Date: Tue, 01 Dec 1992 21:16:10 EST From: Tom Fisk | 2D-337 STM | 5-4341 Reply-To: MX-List@WKUVX1.BITNET To: MX-list@WKUVX1.BITNET CC: fisk@bru Message-ID: <00964746.48E2BBE1.9843@cvdv99.mayo.edu> Subject: Reply-to address is getting messed up I don't know if this is an MX configuration related problem or not, but given the readership of this list, I am hoping somebody has experienced this and can send me off in the right direction. We are running MX-3.1a on a VAXstation 4000-60 with UCX 2.0. When I send a mail message to an internet address, my "reply-to" address gets changed from "fisk@mayo.edu" to "fisk@bru". (Maybe you can see it in the header for this message!). I know that "bru" is a Un*x node within our network that, I believe, is the gateway out to the rest of the internet. I have asked our networking people to check if my definitions on bru are correct and they have assured me that they are...but the problem is still there and we are in a quandry since nobody knows what to do next (me most of all!). I have bounced some messages to some locations to see what I get back. Here is an example that I bounced to mit.edu: ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From: MX%"Postmaster@mayo.EDU" 13-NOV-1992 07:17:15.19 To: FISK CC: Subj: SMTP delivery error Date: Fri, 13 Nov 1992 07:17:07 EST To: Note: this message was generated automatically. A problem occurred during SMTP delivery of your message. Error occurred sending to the following user(s): (via mit.edu): %MX_SMTP-F-MBX_UNAVAILABLE, action not taken: mailbox unavailable Transcript: Rcvd: 220 MIT.EDU Sendmail 5.61/1.1 No collect or third-number calls at Fri, 13 Nov 92 08:13:46 EST Sent: HELO cvdv99 Rcvd: 250 MIT.EDU Hello cvdv99 (cvdv99.mayo.edu), pleased to meet you Sent: MAIL FROM: Rcvd: 250 ... Sender ok Sent: RCPT TO: Rcvd: 550 ... User unknown: No such file or directory Sent: QUIT Rcvd: 221 MIT.EDU closing connection ======================================================================== Message follows. Received: by cvdv99.mayo.edu (MX V3.1C) id 8744; Fri, 13 Nov 1992 07:17:03 EST Sender: fisk@mayo.edu Date: Fri, 13 Nov 1992 07:17:02 EST From: Tom Fisk | 2D-337 STM | 5-4341 Reply-To: fisk@bru To: bounce@mit.edu Message-ID: <009638AC.13A1CE61.8744@cvdv99.mayo.edu> Subject: Postmaster, please return with path information intact Hi...I am trying to find out who is hosing my return address, please return this message with the path information intact. Thanks much! Tom ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ So...do you have any hints or suggestions? Thanks much! Tom. ------------------------------------------------------------------------------- Thomas B. Fisk +----------------------------+ Internet: fisk@mayo.edu Mayo Clinic | If you don't know where | Voice: (507) 255-4341 200 First Street SW | you're going you'll never | FAX: (507) 255-5484 Mail Stop 2D-337 STM | get there. | Rochester, MN 55905 +----------------------------+ ------------------------------------------------------------------------------- ================================================================================ Archive-Date: Wed, 02 Dec 1992 12:21:22 CST From: Reply-To: MX-List@WKUVX1.BITNET Subject: MX Cluster Configuration Question. Message-ID: <1992Dec1.003511.23@dmc.com> Date: 1 Dec 92 00:35:11 EST To: MX-List@WKUVX1.BITNET I've looked at TFM for a while and haven't found an explicit answer to this one: Which components of MX MUST be run on every node in a cluster? The documentation says that they all can be run on every node, but that doesn't seem right to me. -- Dick Munroe Internet: munroe@dmc.com Doyle Munroe Consultants, Inc. UUCP: ...uunet!thehulk!munroe 267 Cox St. Office: (508) 568-1618 Hudson, Ma. FAX: (508) 562-1133 GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection. ================================================================================ Archive-Date: Wed, 02 Dec 1992 12:21:38 CST From: Subject: MX delivering mail as IN%"..." - possible ? Message-ID: <1992Dec2.155111.1848@aragorn.unibe.ch> Sender: news@aragorn.unibe.ch Reply-To: MX-List@WKUVX1.BITNET Date: Wed, 2 Dec 1992 15:51:11 GMT To: MX-List@WKUVX1.BITNET Hi, we have installed MX 3.1C and are quite happy with it. Due to previous installations of PMDF all out users send their mail in the form of IN%"...", which work perfectly. But: all the mail coming in, are in the form of MX%"...". This causes now some problems with the new installed mail interface GMAIL, which can detect adresses either in form of IN%"..." or MX%"...", but not both. I can't force 1000 users to use the MX"..." form after several years of use ... so is there a change to force MX to deliver incoming mail with the address IN"...". I don't want to hack around in the source unless I know where to look. Thanks for any help - Martin ******************************************************************************* Martin Egger, Ph.D., Computing Services - System and User Support Group University of Bern, P.O. Box, Laenggassstrasse 51, CH-3012 Bern, Switzerland Phone: ++41 (0)31 65 38 45, Fax: ++41 (0)31 65 38 65, Telex: 753 112 unib ch RFC: egger@id.unibe.ch, X.400: S=egger;OU=id;O=unibe;P=switch;A=arcom;C=ch; HEPNET/SPAN: 20579::49203::egger, DECnet (Switzerland): 49203::egger ******************************************************************************* ================================================================================ Archive-Date: Wed, 02 Dec 1992 12:50:38 CST Sender: goathunter@WKUVX1.BITNET Date: Wed, 02 Dec 1992 12:49:56 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <009647C8.BAE80EC0.5570@WKUVX1.BITNET> Subject: RE: MX Cluster Configuration Question. writes: > >I've looked at TFM for a while and haven't found an explicit answer to this >one: > > Which components of MX MUST be run on every node in a cluster? > >The documentation says that they all can be run on every node, but that doesn't >seem right to me. I think they all can. No part of MX *must* run on every node in a cluster. The only reason for running multiple components is to spread the work around. At least I *think* that's true.... Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Wed, 02 Dec 1992 13:59:21 CST Date: Wed, 2 Dec 92 14:12:10 -0500 Message-ID: <9212021912.AA06229@genrad.com> From: Reply-To: MX-List@WKUVX1.BITNET X-MX-Warning: Warning -- Invalid "To" header. To: "mx-list%wkuvx1.bitnet@ukcc.uky.edu" CC: Subject: Re: MX Cluster Configuration Question. > I've looked at TFM for a while and haven't found an explicit answer to this > one: > > Which components of MX MUST be run on every node in a cluster? > > The documentation says that they all can be run on every node, but that doesn't > seem right to me. > -- > Dick Munroe Internet: munroe@dmc.com In my experience, the answer is none of them. On my clusters, I execute the MX startup on all nodes, but MX_STARTUP_INFO.DAT is (for example): 001NETLIB:* 002ROUTER:CD4000 003LOCAL:CD4000 004DNSMTP:CD4000 004SITE:CD4000 004SMTP:CD4000 004SMTP_SERVER:CD4000,CDMV21,DUMPY,CDVS07,CDVS14,CDVS24 004XSMTP:CD4000 005MLF:CD4000 In explanation: CD4000 is the boot node, CDMV21, etc, startup UCX and have defined IP addresses (so may receive SMTP mail); other nodes in the cluster (i.e. about 15 Vaxstations) just need to be able to use MX% from mail, hence only need to do the basic startup. Obviously, CD4000 handles all the outgoing mail, list processing etc. -------------------------------------------------------------------------------- Name : Derek Dongray, Systems Manager, GenRad Ltd. Phone : 061 486 1511 ext 166 InterNet : Dongray@GenRad.com UKnet : Derek.Dongray@GenRad.co.uk PSS : 234261600119::Dongray CompuServe : 70374,2745 Address : Monmouth House, Monmouth Road, Cheadle Hulme, Cheshire, SK8 7AY, UK. ================================================================================ Archive-Date: Wed, 02 Dec 1992 14:13:34 CST From: Subject: Re: MX Cluster Configuration Question. Message-ID: <1992Dec2.183714.26286@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <1992Dec1.003511.23@dmc.com> Date: Wed, 2 Dec 1992 18:37:14 GMT To: MX-List@WKUVX1.BITNET In article <1992Dec1.003511.23@dmc.com>, you write: >I've looked at TFM for a while and haven't found an explicit answer to this >one: > > Which components of MX MUST be run on every node in a cluster? None. If you want to be able to send mail using MX, you must at least execute $ @SYS$STARTUP:MX_STARTUP LOGICALS so that the logical names get defined and MX_MAILSHR & MX_MAILSHRP get INSTALLed. Other than that, there need only be one of each of the processing agents running in a cluster in order for mail to get through. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Wed, 02 Dec 1992 14:30:20 CST From: Reply-To: MX-List@WKUVX1.BITNET Subject: MX without using MX% ? Date: 2 Dec 1992 19:32:49 GMT Message-ID: <1fj311INN5tl@chnews.intel.com> To: MX-List@WKUVX1.BITNET There is a patch for MAILSHR.EXE which allows you to use MX without the MX% qualifer when sending mail. Unfortunaly this broke under VMS 5.5-2. Any suggestions or ideas on how to fix this? -- Cecil Lee, Intel Corp., CLee@SC9.INTEL.COM UUCP : {pur-ee,qantel,amdcad,oliveb,decwrl,hplabs}!intelca!mipos3!sc9!clee Not An Evil Tempter Being ================================================================================ Archive-Date: Wed, 02 Dec 1992 15:09:19 CST Date: Wed, 02 Dec 1992 12:46:38 PST From: "W. Todd Wipke" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@RPIECSVX.BITNET Message-ID: <009647C8.45686820.13538@SECS.UCSC.EDU> Subject: why have processes on various nodes Another reason to have duplicate server MX processes running is to assure that if one node fails, mail will still get processed and delivered. Like dual ported disks! wipke@secs.ucsc.edu ================================================================================ Archive-Date: Wed, 02 Dec 1992 16:00:28 CST Sender: fisk@mayo.edu Date: Wed, 02 Dec 1992 15:41:39 EST From: Tom Fisk | 2D-337 STM | 5-4341 Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <009647E0.B82CF981.10269@cvdv99.mayo.edu> Subject: Mail reply-address messed up - fixed Thanks to all those who replied to my message on the addressing problem. It was a configuration problem with UCX where we did not have the fully-qualified domain name for our local node or the institutional mail gateway node. I also had to rerun the MXCONFIG procedure after I changed this. If you received a bounced mail message it was because things were really messed up during this process! (Sorry :-( ) Thanks again for your help! Tom. ------------------------------------------------------------------------------- Thomas B. Fisk +----------------------------+ Internet: fisk@mayo.edu Mayo Clinic | If you don't know where | Voice: (507) 255-4341 200 First Street SW | you're going you'll never | FAX: (507) 255-5484 Mail Stop 2D-337 STM | get there. | Rochester, MN 55905 +----------------------------+ ------------------------------------------------------------------------------- ================================================================================ Archive-Date: Wed, 02 Dec 1992 19:10:07 CST Date: Wed, 02 Dec 1992 15:17:09 CST From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: egger@ubevx1.unibe.ch Message-ID: <009647DD.4CC7B7A0.12511@SHSU.edu> Subject: RE: MX delivering mail as IN%"..." - possible ? On Wed, 2 Dec 1992 15:51:11 GMT, Martin Egger posted: > we have installed MX 3.1C and are quite happy with it. Due to previous > installations of PMDF all out users send their mail in the form of > IN%"...", which work perfectly. But: all the mail coming in, are in the > form of MX%"...". This causes now some problems with the new installed mail > interface GMAIL, which can detect adresses either in form of IN%"..." or > MX%"...", but not both. I can't force 1000 users to use the MX"..." form > after several years of use ... so is there a change to force MX to deliver > incoming mail with the address IN"...". I don't want to hack around in the > source unless I know where to look. This is a wild guess, but will probably work. Check how the logical MAIL$PROTOCOL_IN is defined in your system logical tables. If it exists and looks anything other than "MAIL$PROTOCOL_IN" [exec] = "MX_MAILSHR" (LNM$SYSTEM_TABLE) 1 "MX_MAILSHR" [exec] = "MX_EXE:MX_MAILSHR" (LNM$SYSTEM_TABLE) define it by: DEFINE/SYS/EXEC MAIL$PROTOCOL_IN MX_MAILSHR That should clear up the problem and make it transparent to your users. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ================================================================================ Archive-Date: Wed, 02 Dec 1992 20:12:40 CST From: osymh%msu.oscs.montana.edu@MTSUNIX1.BITNET Sender: osymh%msu.oscs.montana.edu@MTSUNIX1.BITNET Date: Wed, 02 Dec 1992 14:14:02 MST From: "Michael L. Hitch" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <009647D4.7AFC6AC0.2882@trex.oscs.montana.edu> Subject: RE: Reply-to address is getting messed up Tom Fisk | 2D-337 STM | 5-4341 writes: => We are running MX-3.1a on a VAXstation 4000-60 with UCX 2.0. When I send => a mail message to an internet address, my "reply-to" address gets changed => from "fisk@mayo.edu" to "fisk@bru". (Maybe you can see it in the header => for this message!). Your message as received here has "fisk@cvdv99" as the From: header, but had "fisk@mayo.edu" as the Sender: header. I tried replying directly to "fisk@mayo.edu", but got an error back about being received too many times. The loop was on cvdv99.mayo.edu, so I suspect that most likely you do not have the hostname defined correctly on cvdv99 - see the release notes in section 1.4 [VMS/ULTRIX Connection Notes]. You may also have not defined "cvdv99" as a local node in your MX configuration. MX does not appear to recognize "cvdv99.mayo.edu" as a local node and tries to forward it to that node and receives it again. It could be because UCX says it's host name is "cvdv99" (instead of "cvdv99.mayo.edu") and the MX configuration doesn't have "cvdv99" as a local node , or the MX configuration doesn't have "cvdv99.mayo.edu as a local node. => I know that "bru" is a Un*x node within our network that, I believe, is the => gateway out to the rest of the internet. I have asked our networking people => to check if my definitions on bru are correct and they have assured me that => they are...but the problem is still there and we are in a quandry since nobod => knows what to do next (me most of all!). I'm not sure why "bru" is showing up as the Reply-To: address, but you might check the definition of the logical "MX_VMSMAIL_LOCALHOST". I think that logical is used for the Reply-To: address and should probably be defined as "@mayo.edu" on your system - I would guess it's probably defined as "@bru" for some reason. Hope this helps you out. --- Michael L. Hitch osymh@msu.oscs.montana.edu Computer Consultant OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA ================================================================================ Archive-Date: Thu, 03 Dec 1992 08:53:43 CST Return-Path: Sender: gege@cal.enst.fr Date: Thu, 03 Dec 1992 14:33:36 EST From: Why not ? Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <009648A0.60FE09E9.17928@cal.enst.fr> Subject: who is in charge of MX? I made a modification in MX_MAILSHR, and i would know who to contact to integrate this modification in MX. I believe hunter goatley quit maintening it, but i don't know who is in charge now. thank you. ================================================================================ ! Guillaume Gerard ! Email gerard@enst.fr ! ! Systems responsible ! X400 C=FR AD=ATLAS PD=TELECPARIS ! ! French Telecom University ! PSI *2080750412855::gerard ! ================================================================================ %SYSTEM-W-TMNYFNGRS, too many fingers on keyboard ================================================================================ Archive-Date: Thu, 03 Dec 1992 09:42:45 CST Date: Thu, 03 Dec 1992 09:43:04 EST From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: WKUVX1.BITNET!MX-list@esseye.si.com Message-ID: <00964877.CA90E540.821@swdev.si.com> Subject: RE: MX delivering mail as IN%"..." - possible ? George D. Greenwade, Ph.D. writes: >This is a wild guess, but will probably work. Check how the logical > MAIL$PROTOCOL_IN >is defined in your system logical tables. If it exists and looks anything >other than > "MAIL$PROTOCOL_IN" [exec] = "MX_MAILSHR" (LNM$SYSTEM_TABLE) >1 "MX_MAILSHR" [exec] = "MX_EXE:MX_MAILSHR" (LNM$SYSTEM_TABLE) >define it by: > DEFINE/SYS/EXEC MAIL$PROTOCOL_IN MX_MAILSHR MAIL$PROTOCOL_xxxx logicals do not need to be EXEC mode. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 03 Dec 1992 10:01:11 CST Sender: goathunter@WKUVX1.BITNET Date: Thu, 03 Dec 1992 10:00:54 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: gege@CAL.enst.fr Message-ID: <0096487A.4855F040.5826@WKUVX1.BITNET> Subject: RE: who is in charge of MX? Why not ? writes: > > I made a modification in MX_MAILSHR, and i would know who to contact >to integrate this modification in MX. > I believe hunter goatley quit maintening it, but i don't know who >is in charge now. > thank you. I'm maintaining it. Actually, I'm working on finding the time to start maintaining it! 8-) My time should be headed in that direction now; indeed, I'm doing some work on it now.... Just send the new files to me, or a DIFF output, or maybe the best place to start would be with what changes you made. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Thu, 03 Dec 1992 10:15:33 CST Sender: goathunter@WKUVX1.BITNET Date: Thu, 03 Dec 1992 10:15:19 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096487C.4BE5E2E0.5834@WKUVX1.BITNET> Subject: RE: MX delivering mail as IN%"..." - possible ? "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: > >>This is a wild guess, but will probably work. Check how the logical >> MAIL$PROTOCOL_IN >>is defined in your system logical tables. If it exists and looks anything >>other than >> "MAIL$PROTOCOL_IN" [exec] = "MX_MAILSHR" (LNM$SYSTEM_TABLE) >>1 "MX_MAILSHR" [exec] = "MX_EXE:MX_MAILSHR" (LNM$SYSTEM_TABLE) >>define it by: >> DEFINE/SYS/EXEC MAIL$PROTOCOL_IN MX_MAILSHR > >MAIL$PROTOCOL_xxxx logicals do not need to be EXEC mode. > This still doesn't completely solve Martin's problem, though. Incoming mail will still have a "From:" address that says MX%"....". The solutions above will let IN% work when sending mail. If I understand correctly what he's saying about GMAIL, it can't be set up to recognize both MX% and IN%---which means his users cannot REPLY to their mail because it'll have MX% (if GMAIL is set to recognize IN%). I think the best thing to do would be modify GMAIL to accept both, if the sources are available, as this is bound to affect others. In any case, you can change the MX% string by defining the logical MX_PROTOCOL_PREFIX: $ define/sys/exec mx_protocol_prefix in% Incoming mail will now look like: IN%"goathunter@WKUVX1.BITNET". Note that this means MAIL$PROTOCOL_IN must also be defined. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Thu, 03 Dec 1992 10:30:07 CST Date: 03 Dec 1992 10:58:47 -0400 (EDT) From: "G. Del Merritt" Reply-To: MX-List@WKUVX1.BITNET Subject: How do I get to a Lotus Notes network? To: MX-List@WKUVX1.BITNET Message-ID: <009648825E39E800.22200FEB@giant.IntraNet.com> Is there a cookbook way to get MAIL from the InterNet to a person on a Lotus Notes "network"? The address given to me had lot's of "@"s and embedded spaces; is there a well known Lotus Notes gateway? Thanks. Del Merritt del@IntraNet.com ccavax!giant!del IntraNet, Inc., 255 Washington Street, Newton, MA 02158 Voice: 617-527-7020; FAX: 617-527-6779 ================================================================================ Archive-Date: Thu, 03 Dec 1992 11:52:05 CST Date: Thu, 03 Dec 1992 12:28:56 EST From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: WKUVX1.BITNET!mx-list@esseye.si.com Message-ID: <0096488E.F69AE2A0.998@swdev.si.com> Subject: RE: MX delivering mail as IN%"..." - possible ? Hunter says: >I think the best thing to do would be modify GMAIL to accept both, if >the sources are available, as this is bound to affect others. In any >case, you can change the MX% string by defining the logical >MX_PROTOCOL_PREFIX: > > $ define/sys/exec mx_protocol_prefix in% > >Incoming mail will now look like: IN%"goathunter@WKUVX1.BITNET". >Note that this means MAIL$PROTOCOL_IN must also be defined. How about just setting GMAIL to recognize MX% only and use the MAIL$PROTOCOL logical? That's what I had in mind. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 03 Dec 1992 12:10:20 CST Sender: goathunter@WKUVX1.BITNET Date: Thu, 03 Dec 1992 12:09:37 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: tillman@swdev.si.com Message-ID: <0096488C.43AF9480.5862@WKUVX1.BITNET> Subject: RE: MX delivering mail as IN%"..." - possible ? "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: > >Hunter says: > >>I think the best thing to do would be modify GMAIL to accept both, if >>the sources are available, as this is bound to affect others. In any >>case, you can change the MX% string by defining the logical >>MX_PROTOCOL_PREFIX: >> >> $ define/sys/exec mx_protocol_prefix in% >> >>Incoming mail will now look like: IN%"goathunter@WKUVX1.BITNET". >>Note that this means MAIL$PROTOCOL_IN must also be defined. > >How about just setting GMAIL to recognize MX% only and use the MAIL$PROTOCOL >logical? That's what I had in mind. > Unless I'm misunderstanding how GMAIL works, I answered that in the part you cut out. GMAIL will only recognize one: either MX% or IN%. If you want it to recognize IN%, then users *cannot* REPLY to incoming mail because it will say "From: MX%....". If GMAIL doesn't recognize MX%, then it probably won't allow you to REPLY. If it *does* recognize MX%, then it won't recognize the user's IN% on new outgoing mail. Make sense? So the solution I mentioned above, in conjunction with define MAIL$PROTOCOL_IN, changes it all from MX% to IN%. Just using MAIL$PROTOCOL_IN only affects outgoing mail---it has no effect on the "From:" line of *incoming* mail. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Thu, 03 Dec 1992 13:19:05 CST Date: Thu, 03 Dec 1992 14:01:50 EST From: jon@QCVAXA.BITNET Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096489B.F0BAC0A0.9843@qcvaxa.acc.qc.edu> Subject: help help ================================================================================ Archive-Date: Thu, 03 Dec 1992 18:43:34 CST From: Subject: MX w/CMU-TEK not using MX records Date: 4 Dec 1992 00:13:58 GMT Message-ID: <1fm7s6INNlj1@crcnis1.unl.edu> Reply-To: MX-List@WKUVX1.BITNET Keywords: MX CMU-TEK records To: MX-List@WKUVX1.BITNET We are running MX V2.3, CMU-TEK V6.6-5, and VMS 5 on a VAX 3900. It seems that we can't send mail to hosts that only have MX records. When I run IPNCP, I can RRFETCH MX records, so I know CMU-TEK can retrieve them. How do I get MX to ask for/use MX records? Thanks. -- Russell mosemann@unl.edu ================================================================================ Archive-Date: Fri, 04 Dec 1992 10:22:00 CST Date: Fri, 04 Dec 1992 11:18:56 EST From: Shakil Khan Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: khan@QCVAXA.BITNET Message-ID: <0096494E.59A28BE0.11084@qcvaxa.acc.qc.edu> signoff mx-list ================================================================================ Archive-Date: Fri, 04 Dec 1992 12:37:45 CST From: Subject: RE: MX delivering mail as IN%"..." - possible ? Date: 4 Dec 1992 17:18:17 GMT Message-ID: <1fo3spINNpn@gap.caltech.edu> References: <0096488E.F69AE2A0.998@swdev.si.com> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <0096488E.F69AE2A0.998@swdev.si.com>, "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: =Hunter says: = =>I think the best thing to do would be modify GMAIL to accept both, if =>the sources are available, as this is bound to affect others. In any =>case, you can change the MX% string by defining the logical =>MX_PROTOCOL_PREFIX: => => $ define/sys/exec mx_protocol_prefix in% => =>Incoming mail will now look like: IN%"goathunter@WKUVX1.BITNET". =>Note that this means MAIL$PROTOCOL_IN must also be defined. = =How about just setting GMAIL to recognize MX% only and use the MAIL$PROTOCOL =logical? That's what I had in mind. How about just getting rid of GMAIL, since MX will handle mail destined for BITnet faster and better than GMAIL does, and that's what GMAIL is for? -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Fri, 04 Dec 1992 12:37:57 CST From: Subject: RE: MX delivering mail as IN%"..." - possible ? Date: 4 Dec 1992 17:16:15 GMT Message-ID: <1fo3p0INNpn@gap.caltech.edu> References: <0096487C.4BE5E2E0.5834@WKUVX1.BITNET> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <0096487C.4BE5E2E0.5834@WKUVX1.BITNET>, Hunter Goatley writes: >This still doesn't completely solve Martin's problem, though. Incoming >mail will still have a "From:" address that says MX%"....". The >solutions above will let IN% work when sending mail. If I understand >correctly what he's saying about GMAIL, it can't be set up to >recognize both MX% and IN%---which means his users cannot REPLY to >their mail because it'll have MX% (if GMAIL is set to recognize IN%). However, if GMAIL is still the abomination it was 5 years ago (i.e., a huge DCL script that does practically nothing but takes up lots of CPU time and I/O), it really shouldn't be impossible to make it accept two prefixes. This still leaves us with the question: If you've got MX, WHY THE HELL ARE YOU ALSO USING GMAIL? MX does everything GMAIL does (or did last time I had to look at it), it does it faster, it does it BETTER. What possible reason can someone have for using GMAIL these days? For those not familiar with GMAIL: It is (or was) a huge DCL script that took a mail address, tried to figure out whether it was supposed to go out to BITnet, and it it did, converted the mail command to the appropriate JNET commands. It was, if I recall correctly, from Europe, which serves to explain a lot, if you've seen other communications software from there. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Fri, 04 Dec 1992 13:15:50 CST Date: Fri, 4 Dec 92 19:08 GMT From: "UK TeX Archive Manager " Reply-To: MX-List@WKUVX1.BITNET To: MX-LIST%BITNET.WKUVX1@NSFNET-RELAY.AC.UK Subject: RE: MX delivering mail as IN%"..." - possible ? In message <1fo3p0INNpn@gap.caltech.edu> dated 4 Dec 1992 17:16:15 GMT carl said: > It was, if I recall correctly, from Europe, which serves to explain > a lot, if you've seen other communications software from there. Hey! Despite what some little-Englanders would have us believe, the UK is in Europe. One of the major "invisible earnings" of the UK, for the past 10--15 years at least, has been the writing of communications software by UK-based software houses for US clients who are unable to find the requisite calibre of consultants over there. SO don't knock European software authors, or there'll be a bigger flame war than U**x vs. VMS! Brian {Hamilton Kelly} System Manager for the UK TeX Archive at Aston University PS I must own up to having written a huge DCL script whose purpose (apart from consuming tons of CPU time) is to parse the Grey-Book mail headers on traffic which has proved undeliverable because DEC's Colour Book Software is just too too finnicky about trivial syntax errors. But this script is only applied to mail that would otherwise have been delivered to Postmaster only: now it gets delivered there, to the intended recipient (if that can be ascertained) and a copy, with explanatory guide (e.g., telling the sender NOT to put any periods in the text outside the when that format is used for the from or other relevant fields --- yes, period is illegal under RFC-822) sent back to the original correspondent, if THAT can be ascertained. It can also redeliver mail accidentally sent to the wrong address, and make it appear that it's only just (correctly) arrived, so could have recovered this week's little collection that some of you may have seen that were incorrectly sent to info-multinet-relay@tgv.com. So although this is a huge DCL script, and I *ought* to get around to rewriting it as a proper program instead of a deeply recursive command procedure, it doesn't get to run all the time, as I guess GMAIL must, judging from the description. ================================================================================ Archive-Date: Fri, 04 Dec 1992 13:36:49 CST Sender: goathunter@WKUVX1.BITNET Date: Fri, 04 Dec 1992 13:36:02 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: macro32@WKUVX1.BITNET CC: mx-list@WKUVX1.BITNET Message-ID: <00964961.80873B80.6195@WKUVX1.BITNET> Subject: OK, chill.... Well, it's that time of the year again.... This goes out to MACRO32 and MX-List. How about if we cut the flames and the intentional provocational comments that are being made? To coin a phrase, "Why can't we all just get along?" Carl appears to be doing his best to alienate everybody one way or another. Ehud's been leaving these groups alone lately. 8-) There are others, of course. I can't do anything about comp.os.vms, but since I own MX-List and MACRO32, I can make the following request: Please keep the topic relevant. If you don't have anything nice to say, then don't say anything. If somebody has really pissed you off, reply to them directly via e-mail---no reason several hundred other people have to see you bickering. And don't make comments that you now are going to be upsetting to some large portion of the readership (like Carl's jab at European communications software authors in MX-List or the religious jabs going on in MACRO32 over AXP). Thanks for your help.... Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Fri, 04 Dec 1992 14:27:34 CST Subject: RE: MX delivering mail as IN%"..." - possible ? Message-ID: <1992Dec4.160032.6735@aragorn.unibe.ch> From: Date: Fri, 4 Dec 1992 16:00:32 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: news@aragorn.unibe.ch References: <0096488C.43AF9480.5862@WKUVX1.BITNET> To: MX-List@WKUVX1.BITNET In article <0096488C.43AF9480.5862@WKUVX1.BITNET>, >Hunter Goatley writes: >"Brian Tillman, Smiths Industries, VAX Support, x8425" writes: >> >>Hunter says: >> >>>I think the best thing to do would be modify GMAIL to accept both, if >>>the sources are available, as this is bound to affect others. In any >>>case, you can change the MX% string by defining the logical >>>MX_PROTOCOL_PREFIX: >>> >>> $ define/sys/exec mx_protocol_prefix in% >>> >>>Incoming mail will now look like: IN%"goathunter@WKUVX1.BITNET". >>>Note that this means MAIL$PROTOCOL_IN must also be defined. >> >>How about just setting GMAIL to recognize MX% only and use the MAIL$PROTOCOL >>logical? That's what I had in mind. >> >Unless I'm misunderstanding how GMAIL works, I answered that in the >part you cut out. > >GMAIL will only recognize one: either MX% or IN%. If you want it to >recognize IN%, then users *cannot* REPLY to incoming mail because it >will say "From: MX%....". If GMAIL doesn't recognize MX%, then it >probably won't allow you to REPLY. If it *does* recognize MX%, then >it won't recognize the user's IN% on new outgoing mail. Make sense? >So the solution I mentioned above, in conjunction with define >MAIL$PROTOCOL_IN, changes it all from MX% to IN%. > >Just using MAIL$PROTOCOL_IN only affects outgoing mail---it has no >effect on the "From:" line of *incoming* mail. > >Hunter >------ >Hunter Goatley, VMS Systems Programmer, Western Kentucky University >goathunter@WKUVX1.BITNET, 502-745-5251 Hunter is absolutely right. His (and Matt Madisons) proposed solution of defining $ define/sys/exec mx_protocol_prefix in% did exactly what I wanted and GMAIL is working fine now. My thanks to Hunter and Matt. ******************************************************************************* Martin Egger, Ph.D., Computing Services - System and User Support Group University of Bern, P.O. Box, Laenggassstrasse 51, CH-3012 Bern, Switzerland Phone: ++41 (0)31 65 38 45, Fax: ++41 (0)31 65 38 65, Telex: 753 112 unib ch RFC: egger@id.unibe.ch, X.400: S=egger;OU=id;O=unibe;P=switch;A=arcom;C=ch; HEPNET/SPAN: 20579::49203::egger, DECnet (Switzerland): 49203::egger ******************************************************************************* ================================================================================ Archive-Date: Fri, 04 Dec 1992 14:46:19 CST Date: Fri, 04 Dec 1992 15:37:59 EST From: "Steve Thompson, Cheme System Mangler" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00964972.89E9D1E0.7048@cheme.tn.cornell.edu> Subject: on MLFAKE MX 3.1C, VMS 5.5-1. Is it possible to use MLFAKE to add users to a mailing list without having the subscription message mailed to them? If the mailing list is defined as /NOADD_MESSAGE, it merely sends the default subscription message instead. If this is not possible, is the mailing list file structure defined somewhere, such that I can do this by hand? Thanks. Steve /SIG ================================================================================ Archive-Date: Sat, 05 Dec 1992 08:53:18 CST Subject: Re: on MLFAKE Message-ID: <1992Dec4.222917.24472@news.arc.nasa.gov> From: Date: Fri, 4 Dec 1992 22:29:17 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: usenet@news.arc.nasa.gov References: <00964972.89E9D1E0.7048@cheme.tn.cornell.edu> To: MX-List@WKUVX1.BITNET In article <00964972.89E9D1E0.7048@cheme.tn.cornell.edu>, "Steve Thompson, Cheme System Mangler" writes: >Is it possible to use MLFAKE to add users to a mailing list without having >the subscription message mailed to them? If the mailing list is defined >as /NOADD_MESSAGE, it merely sends the default subscription message >instead. If this is not possible, is the mailing list file structure >defined somewhere, such that I can do this by hand? Thanks. You can't do it with MLFAKE, but... If you're the list manager or have privileges to add users to the list yourself, and it's an MX mailing list, all you have to do is use the ADD/NONOTIFY command to add the users in question. The MLF guide should describe the list management commands and their qualifiers. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Sat, 05 Dec 1992 08:53:22 CST From: Subject: RE: MX delivering mail as IN%"..." - possible ? Message-ID: <1992Dec5.112312.11686@aragorn.unibe.ch> Sender: news@aragorn.unibe.ch Reply-To: MX-List@WKUVX1.BITNET References: <0096487C.4BE5E2E0.5834@WKUVX1.BITNET>,<1fo3p0INNpn@gap.caltech.edu> Date: Sat, 5 Dec 1992 11:23:12 GMT To: MX-List@WKUVX1.BITNET In article <1fo3p0INNpn@gap.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes: >In article <0096487C.4BE5E2E0.5834@WKUVX1.BITNET>, Hunter Goatley writes: >>This still doesn't completely solve Martin's problem, though. Incoming >>mail will still have a "From:" address that says MX%"....". The >>solutions above will let IN% work when sending mail. If I understand >>correctly what he's saying about GMAIL, it can't be set up to >>recognize both MX% and IN%---which means his users cannot REPLY to >>their mail because it'll have MX% (if GMAIL is set to recognize IN%). > >However, if GMAIL is still the abomination it was 5 years ago (i.e., a huge DCL >script that does practically nothing but takes up lots of CPU time and I/O), it >really shouldn't be impossible to make it accept two prefixes. > >This still leaves us with the question: If you've got MX, WHY THE HELL ARE YOU >ALSO USING GMAIL? MX does everything GMAIL does (or did last time I had to >look at it), it does it faster, it does it BETTER. What possible reason can >someone have for using GMAIL these days? No, it doesn't. >For those not familiar with GMAIL: It is (or was) a huge DCL script that took >a mail address, tried to figure out whether it was supposed to go out to >BITnet, and it it did, converted the mail command to the appropriate JNET >commands. It was, if I recall correctly, from Europe, which serves to explain >a lot, if you've seen other communications software from there. That's not the GMAIL we have. Our GMAIL is a fullscreen oriented interface to VMS Mail and not a foreign mail protocol as MX. >------------------------------------------------------------------------------- - >Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL > >Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My >understanding of astronomy is purely at the amateur level (or below). So >unless what I'm saying is directly related to VAX/VMS, don't hold me or my >organization responsible for it. If it IS related to VAX/VMS, you can try to >hold me responsible for it, but my organization had nothing to do with it. ******************************************************************************* Martin Egger, Ph.D., Computing Services - System and User Support Group University of Bern, P.O. Box, Laenggassstrasse 51, CH-3012 Bern, Switzerland Phone: ++41 (0)31 65 38 45, Fax: ++41 (0)31 65 38 65, Telex: 753 112 unib ch RFC: egger@id.unibe.ch, X.400: S=egger;OU=id;O=unibe;P=switch;A=arcom;C=ch; HEPNET/SPAN: 20579::49203::egger, DECnet (Switzerland): 49203::egger ******************************************************************************* ================================================================================ Archive-Date: Mon, 07 Dec 1992 16:27:15 CST Subject: MW & TCPware V3.0 ??? Message-ID: <1992Dec7.165236.28@dnz.rws.nl> From: Reply-To: MX-List@WKUVX1.BITNET Date: 7 Dec 92 16:52:36 UTC To: MX-List@WKUVX1.BITNET Hi, can you tell me if I can use MX together with TCPware V3.0 ???? Thanks.. Mar ================================================================================ Archive-Date: Mon, 07 Dec 1992 16:27:32 CST From: Reply-To: MX-List@WKUVX1.BITNET Subject: MX with TCPware V3.0 ?? Message-ID: <1992Dec7.133124.27@dnz.rws.nl> Date: 7 Dec 92 13:31:24 UTC To: MX-List@WKUVX1.BITNET Hi, thanks for reading this. Can I use MX together with the SMTP server from TCPware Version 3 ?? Regards , Mar ================================================================================ Archive-Date: Mon, 07 Dec 1992 19:12:06 CST From: daveh@vax.oxford.ac.uk Reply-To: MX-List@WKUVX1.BITNET Subject: Local agent crashes Message-ID: <1992Dec7.101833.10630@vax.oxford.ac.uk> Date: 7 Dec 92 10:18:32 GMT To: MX-List@WKUVX1.BITNET Hi, Last week the maximum file count on our MX disk was reached. This seems to have caused incoming mail to create entries in the MX queue file, but because the file limit had been reached the actual files were not created. When the local agent tried to deliver one of these messages, it fell over with the following error: 3-DEC-1992 14:26:06.33: MX Local (pid 0005E936) starting 3-DEC-1992 14:27:56.88: MX Local (pid 0005E936) exiting %RMS-F-FNF, file not found %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel PC abs PC PROCESS PROCESS 199 000000E1 00001AD6 MX_LOCAL MX_LOCAL 30 00000311 00001511 I would have expected the delivery agent to handle this sort of thing without crashing. Any comments anyone? Dave -- David Hastings | "Imposition of order=escalation of chaos" VAX Systems Programmer | Oxford University Computing Services| "Just when you think you've won the daveh@vax.oxford.ac.uk | rat race, along come faster rats" ================================================================================ Archive-Date: Tue, 08 Dec 1992 06:05:22 CST Sender: goathunter@WKUVX1.BITNET Date: Tue, 08 Dec 1992 06:04:52 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00964C47.2387F4E0.6921@WKUVX1.BITNET> Subject: RE: Local agent crashes daveh@vax.oxford.ac.uk writes: > >Last week the maximum file count on our MX disk was reached. This seems to have >caused incoming mail to create entries in the MX queue file, but because the >file limit had been reached the actual files were not created. When the local >agent tried to deliver one of these messages, it fell over with the following >error: > [...] >%RMS-F-FNF, file not found [...] > >I would have expected the delivery agent to handle this sort of thing without >crashing. Any comments anyone? > I would have too, but I suspect it died because the FNF error is fatal. Most of MX just RETURNs any error that occurs, without checking specifically to see what the error was. In many cases, such as this one, that might be the best thing, though it would be nice if MX told you it was dying. I'll try to address this in the next version of MX. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Tue, 08 Dec 1992 09:28:23 CST Date: Tue, 08 Dec 1992 10:24:22 EST From: Ian Vaz Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00964C6B.63CA1C80.27156@mars.senecac.on.ca> Subject: MX v2.3 and MX records. Hello all, The objective of this message is to encourage users of MX v2.3 to upgrade to MX v3.1C. We had been running MX v2.3 until last week. The problem that made us change over was the fact that v2.3 had no idea on how to send mail to nodes that only had MX records and not A records, i.e., gatewayed nodes. I upgraded to v3.1C this week-problem resolved. I believe there was a similar cry for help from a user with an identical problem last week. If you are reading this, get the v3.1C upgrade. It works and is actually much nicer with a more sophisticated queue management interface that gives more pertinent details. Yes, I know, slap my wrists for using such an old version. Here goes,..., slap slap slap. Thanks to Hunter Goately and Matt Madison for the help they extended us in resolving this issue. ******************************************************************* * Ian Vaz * * Seneca College * * Don Mills, Ontario * * (416) 491-5050 x 7252 * * Internet e-mail addresses: i) ian@mars.senecac.on.ca * * ii) ian@phobos.senecac.on.ca * ******************************************************************* ================================================================================ Archive-Date: Tue, 08 Dec 1992 14:50:42 CST Date: Tue, 8 Dec 92 15:53 GMT From: "UK TeX Archive Manager " Reply-To: MX-List@WKUVX1.BITNET To: MX-LIST%BITNET.WKUVX1@NSFNET-RELAY.AC.UK Subject: RE: MX v2.3 and MX records. In message <00964C6B.63CA1C80.27156@mars.senecac.on.ca> dated Tue, 08 Dec 1992 10:24:22 EST Ian Vaz wrote: > The objective of this message is to encourage users of MX v2.3 to upgrade > to MX v3.1C. We had been running MX v2.3 until last week. The problem > that made us change over was the fact that v2.3 had no idea on how to > send mail to nodes that only had MX records and not A records, i.e., > gatewayed nodes. I upgraded to v3.1C this week-problem resolved. I believe > there was a similar cry for help from a user with an identical problem > last week. If you are reading this, get the v3.1C upgrade. It works and > is actually much nicer with a more sophisticated queue management interface > that gives more pertinent details. Aha! I was recently corresponding with Robin Fairbairns, and had asked him if MX knew about MX records, to which he thought the answer was NO. In the UK, we're *very* interested in knowing about the existence of MX records, because the preference level is required to control the mailing method for traffic *within* the uk.ac community: some sites are to be mailed used Grey-book mail over Janet, and others may use SMTP over Internet. So when and if there's ever a Grey-book mail interface to MX, it will be necessary for MX to use the MX records; therefore I'm very pleased to hear that it now does something with them. If there's anyone else out there, apart from Robin, who is striving to get GBM to work through MX (or perhaps I mean to get MX to support Colour Book Software), I'd be glad to hear from him/her, and to swap ideas and commiserations! Brian {Hamilton Kelly} System Manager for the UK TeX Archive at Aston University ================================================================================ Archive-Date: Tue, 08 Dec 1992 21:36:46 CST Subject: Re: MX with TCPware V3.0 ?? Message-ID: <1992Dec9.012118.1818@aragorn.unibe.ch> From: Date: Wed, 9 Dec 1992 01:21:18 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: news@aragorn.unibe.ch References: <1992Dec7.133124.27@dnz.rws.nl> To: MX-List@WKUVX1.BITNET In article <1992Dec7.133124.27@dnz.rws.nl>, mvdhoeven@dnz.rws.nl (Mar v.d. Hoeven) writes: >Can I use MX together with the SMTP server from TCPware Version 3 ?? >Regards , Mar It runs without any problems at our site... Greetings, Martin ---------------------------------------------------------------------------- Radio Suisse Ltd, Internet: winter@vision.rs.ch Laupenstrasse 18a postmaster@vision.rs.ch 3008 Bern PSI-Mail: +22846431062::WINTER (public X.25) Switzerland X.400: C=CH; A=ARCOM; P=RS; O=DM; S=WINTER, G=MARTIN ---------------------------------------------------------------------------- ================================================================================ Archive-Date: Wed, 09 Dec 1992 12:52:54 CST Date: Wed, 09 Dec 1992 12:52:02 EST From: "Stanley J. McCaslin" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00964D49.2F0C8760.1046@PSCCS1.PERU.EDU> Subject: need MAILSHR patch for VMS 5.5 We just upgraded to VMS 5.5-2, and lost the patch to MAILSHR.EXE which allows users to enter internet-style addresses directly, without the MX%"... I tried re-pathcing the new MAILSHR.EXE with the old patch, but it doesn't seem to work. Is there a patch available which works with VMS 5.5? If so, where can I find it? Stanley J. McCaslin Inet: mccaslin@psccs1.peru.edu Assistant Professor, Computer Science Phone:402/872-2208 Peru State College, Peru, Nebraska Home: 402/872-7595 ================================================================================ Archive-Date: Wed, 09 Dec 1992 17:56:05 CST Subject: Does RPI's UCX Finger support unix-style info? Message-ID: <1992Dec9.160148.81@dymaxion.ns.ca> From: bg@dymaxion.ns.ca Reply-To: MX-List@WKUVX1.BITNET Date: 9 Dec 92 16:01:48 AST To: MX-List@WKUVX1.BITNET I have questions about RPI's UCX FINGER (uses MDMLIB and was bundled with our distribution of MX 3.0). - does the finger server support Unix-type finger info? - plan file, last login, etc. - the docs are sketchy at best; are there better docs? - where is the latest version and when was it last updated? - I have MX 3.1 but haven't installed it yet. Is the latest finger in this package? (I know, I could check. Call me lazy, but I don't want to waste the effort unpacking and hunting through it if it isn't there. Besides, even if I found it, I wouldn't know if it is the latest.) Ben. -- Ben Armstrong, Software Development bus: (902)422-1973 Dymaxion Research Ltd., fax: (902)421-1267 Halifax, Nova Scotia, Canada B3J 1R2 Internet: bg@dymaxion.ns.ca ================================================================================ Archive-Date: Wed, 09 Dec 1992 18:44:04 CST Subject: Re: Does RPI's UCX Finger support unix-style info? Message-ID: <1992Dec9.234016.258@news.arc.nasa.gov> From: Date: Wed, 9 Dec 1992 23:40:16 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: usenet@news.arc.nasa.gov References: <1992Dec9.160148.81@dymaxion.ns.ca> To: MX-List@WKUVX1.BITNET In article <1992Dec9.160148.81@dymaxion.ns.ca>, bg@dymaxion.ns.ca writes: >I have questions about RPI's UCX FINGER (uses MDMLIB and was bundled with >our distribution of MX 3.0). >- does the finger server support Unix-type finger info? > - plan file, last login, etc. Nope. It's pretty simple and just gives basic info. I never cared for all those bells and whistles anyway. If you're looking for something fancier, you should probably check out the DECUS Finger package. Terry Kennedy (terry@spcvxa.spc.edu) has been working on UCX support for it, which may be done by now. >- the docs are sketchy at best; are there better docs? >- where is the latest version and when was it last updated? I don't know if I ever got round to improving the documentation. You should find the latest version on ftp.spc.edu, directory [.MADISON.UCX_FINGER]. >- I have MX 3.1 but haven't installed it yet. Is the latest finger > in this package? (I know, I could check. Call me lazy, but I don't > want to waste the effort unpacking and hunting through it if it isn't > there. Besides, even if I found it, I wouldn't know if it is the > latest.) The finger stuff is not (and never was) included with MX. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Wed, 09 Dec 1992 21:31:46 CST Subject: RE: Local agent crashes Message-ID: <1992Dec9.132505.10689@vax.oxford.ac.uk> From: daveh@vax.oxford.ac.uk Reply-To: MX-List@WKUVX1.BITNET Date: 9 Dec 92 13:25:05 GMT References: <00964C47.2387F4E0.6921@WKUVX1.BITNET> To: MX-List@WKUVX1.BITNET In article <00964C47.2387F4E0.6921@WKUVX1.BITNET>, goathunter@WKUVX1.BITNET (Hunter Goatley) writes: > daveh@vax.oxford.ac.uk writes: >> >>Last week the maximum file count on our MX disk was reached. This seems to have >>caused incoming mail to create entries in the MX queue file, but because the >>file limit had been reached the actual files were not created. When the local >>agent tried to deliver one of these messages, it fell over with the following >>error: >> > [...] >>%RMS-F-FNF, file not found > [...] >> >>I would have expected the delivery agent to handle this sort of thing without >>crashing. Any comments anyone? >> > I would have too, but I suspect it died because the FNF error is > fatal. Most of MX just RETURNs any error that occurs, without > checking specifically to see what the error was. In many cases, such > as this one, that might be the best thing, though it would be nice if > MX told you it was dying. > > I'll try to address this in the next version of MX. > > Hunter -- The additional problem is that the local agent just crashes if it can't find the files - unless you've got tracing switched on you don't know which entry is actually causing the problem. Until you find this and get rid of it the local agent will fall over when it is restarted. Dave -- David Hastings | "Imposition of order=escalation of chaos" VAX Systems Programmer | Oxford University Computing Services| "Just when you think you've won the daveh@vax.oxford.ac.uk | rat race, along come faster rats" ================================================================================ Archive-Date: Fri, 11 Dec 1992 15:45:52 CST Date: Thu, 10 Dec 1992 17:00:12 CST From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00964E35.0528EDC0.8324@SHSU.edu> Subject: Support for VRFY on SMTP_Server? This is yet another topic to bother Hunter with (which is not extraordinarily high on my wish list, but...). Are there any plans to support any form of user interface of commands for the SMTP_Server in MX? One of the feature supported by quite a few sites is the VRFY command (as well as HELP), which can be reached via TELNETting to port 25 and handling things interactively. This is nice for verifying things for list owners (among other things). Presently, MX doesn't appear to support anything along these lines. Has anyone overcome this, have I missed something somewhere, is this to be supported in future a release? Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ================================================================================ Archive-Date: Fri, 11 Dec 1992 15:46:20 CST From: Subject: Re: test Message-ID: <1992Dec10.234017.22505@news.Hawaii.Edu> Sender: (Henry Stilmack - JAC Hawaii SysMgr) Reply-To: MX-List@WKUVX1.BITNET References: <00964234.81CC9780.12449@SECS.UCSC.EDU> Date: Thu, 10 Dec 1992 23:40:17 GMT To: MX-List@WKUVX1.BITNET OK, folks - I posted this update of the MAILPATCH.COM (patch to MAILSHR.EXE which allows MX to work without the "MX%") right after I ran into the same problem. Please note the section of the file which customizes for VMS version - I added the bit for v5.5-2. (Note to Hunter - Do you want to put this into the new (whenever that is) distribution? If so, go ahead). =============CUT HERE=========================CUT HERE======================== MAILSHR.EXE ! ! Modifed Nov, 1990, RPW to replace IN%" with MX%" and to make the form ! user@system translate into mx%"user@system" instead of system::user ! ! This patch will be of interest to any VAX/VMS system (more especially if it ! is running PMDF) since it lets TO: or CC: addresses such as ! user%machine@site.co.org to be accepted without the IN% prefix and without ! surrounding double quotes. Yes, let's admit it, it lets VMS mail accept Un*x ! type addresses. In addition to its original goal, the format of this ! modification is also original by the fact of the straight macro code that ! can easily be modified/expanded or altered (ie IN% could become M_INTERNET:: ! in the case of most Schlumberger VMS nodes) ! If the address is "similar" (see algorithm below) to user%machine@site.co.org ! it is simply rewritten as IN%"user%machine@site.co.org" and passed along. ! At the same time, user@machine will be accepted and rewritten as machine::user ! If the IN% prefix is not the one in use on your VAX/VMS system, but XYZ% is, ! then all you have to do is $ DEFINE/SYSTEM/EXECUTIVE - ! MAIL$PROTOCOL_IN - ! XYZ_ROOT:[EXE]XYZ_MAILSHR ! or wherever the XYZ overlay for MAIL ! ! might be located and installed from ! ! See additional impact remarks below. ! ! This patch applies to SYS$LIBRARY:MAILSHR.EXE (usually SYS$COMMON:[SYSLIB]) ! from VMS 5.0 to Field Test version of 5.4 as of June 1990 ! ! We recommend: ! ! $ SET DEFAULT SYS$COMMON:[SYSLIB] ! $ INSTALL:= $INSTALL/COMMAND ! $ PATCH @ this_file.COM ! $ INSTALL REPLACE SYS$COMMON:[SYSLIB]MAILSHR.EXE ! ! Claude Barbe - Schlumberger-Doll Research - Ridgefield, CT - USA ! (Internet) barbe@sdr.slb.com (a happy hacker of MAIL and PMDF for over 3yr) ! ! 3-Jul-1990 ! ! No warranty implied. This can be freely copied and altered. Use it at ! your own risks. It is probably pure chance if it ever worked on a ! particular system. ! ! Additional remarks on the impact of this patch ! ! 1) With this patch in place we hope to make addressing unique in the VMS world ! whether a message is sent via DECnet or via a foreign protocol (such as ! the successful/affordable PMDF) without forcing any one to use prefixes ! and/or quotes. Quotes are to be avoided by all means since MAIL and DEC's ! MRGATE interface have no mechanisms to imbed quoted addresses between ! quotes (ie MRGATE and PMDF cannot carry the same message!) ! 2) There are risks of confusion for new users who will learn that the Un*x ! addressing format works on a patched VMS system and who will never bother ! to know the DEC way to send mail with double colons between node and ! username until they use a non patched VMS system ! 3) The patch will certainly break when DECnet node names will contain dots ! but this is in DECnet phase V and we still have to see a field test ! for this product. By that time a better patch will be developped or ! whatever foreign protocol is used (PMDF by default) will just handle ! these deliveries that could have gone also more simply across DECnet ! 4) The patch is far from being fully RFC822 compliant and there are risks ! that some users will be confused by the lack of completeness. This ! in some case will be due to the approach taken in this patch where, ! instead of redoing the address parsing that DEC is doing in MAIL, we ! simply hacked a string filter on a "DEC approved string" which has already ! been pruned of commas and exclamation points. Users familiar with "bang" ! addresses will still have to say IN%"node!node!user@relay.somewhere" ! 5) After a few extra weeks of testing on a larger scale, this patch will be ! submitted to DEC as an SPR for improvement. Hopefully, then DEC will ! support the de facto standard (or at least the most commonly used part ! of it). In the mean time let's try to let our users access Internet ! addresses in the most natural way. At last! ! ! Validity of this patch ! ! It has only been tested on VMS 5.3-1 but is expected to work on VMS 5.0 to 5.4 ! (well, 5.4 is not out yet, so at least up to T5.4-4). This part of the code ! is the same for all these versions of VMS 5, only the addresses changed after ! 5.0. For VMS 4.6/4.7, unfortunately the code was different and it was not ! found worth the effort to retrofit this patch for a version of VMS that was ! replaced 23 months ago. ! ! For VMS 5.0 only, uncomment the following 6 lines and comment another 6 lines ! below. ! ! If you patch, VMS 5.0, it is different from the following VMS versions ! MAIL$$ADD_ADDR is located at 000049C2 and ! ADD_ADDR is located at 000048EF ! then uncomment the following 6 lines and comment out 6 similar lines below !DEF !MAIL$$ADD_ADDR !000049C2 !ADD_ADDR !000048EF !EXI ! ! If you patch any versions from VMS 5.1 to T5.4-4 including 5.1 and 5.2, all ! appear to have identical MAIL$$ADD_ADDR always located at 000049D2 and ! calling ADD_ADDR always located at 000048FF ! For VMS 5.0 comment out the following 6 lines and uncomment 6 lines above ! !DEF !MAIL$$ADD_ADDR !000049D2 !ADD_ADDR !000048FF !EXI ! ! For V5.5-2, it looks like MAIL$$ADD_ADDR is at 000049DA, so modify the patch: ! DEF MAIL$$ADD_ADDR 000049DA ADD_ADDR 00004907 EXI ! ! Now make sure that we have a patch area ! ALI/B PATAREA ! And now enter instruction mode ! SE M I EXI ! Start implementing the ALTER_TO subroutine ! It was first developped and tested as a MACRO-32 program ! and changed into the body of this patch.com file by ! a MACRO_TO_PATCH.COM procedure developped for that purpose DEP /PAT PATAREA !; ALTER_TO is called with the same 2 arguments used by !; MAIL$$SEND_ADD_ADDR in calling MAIL$$ADD_ADDR and will call !; ADD_ADDR itself with or without a rewrite. There is no rewrite !; if SYS$FAO fails. The original address is never modified and !; will still appear unmodified in the "published" TO: field. !; !; At this point when MAIL$$ADD_ADDR calls ALTER_TO, 4(AP) points !; to a string descriptor which MAIL has already parsed to be one !; of a single recipient (we don't have to look for commas or for !; an @ sign preceding a distribution list). Because of the !; location of this patch, floating/unquoted "!"s seem unlikely. !; !; The principle of this patch is to allow plain RFC addresses !; to be acceptable by mail. We never anticipated to fully deal !; with the full RFC822 format but simply to lrt forms such as !; user@site.org or user%machine@site.company.org with all atoms !; being alphanumerics and the whole address void of double quotes !; !; At the same time STRAIGHTFORWARD phase IV DECnet mail addresses !; are also allowed in an RFC822 like format: USERNAME@NODENAME !; is being transformed into NODENAME::USERNAME. Note well that !; the code will NOT transform any address with an "@" into !; a more complex DECnet mail address such as AAA::BBB::USER. !; !; The parsing is an adhoc scanning of the string looking for !; no more than one "@", checking the absence of " and for the !; A and B parts of A@B distinguish between A-Z,0-9,a-z,$,%,.,- !; and other characters (in case MAIL's parser would any slip thru) !; !; More exactly the algorithm is: !; !; input string might look like A@B with A and B containing no " !; if " or not A@B, pass the string to ADD_ADDR unchanged ! Case 1 !; else if A or B has any character not in A-Z,0-9,a-z,$,%,.,- !; pass IN%"A@B" ! Case 2 !; else !; if B has no dots (pure DECnet) pass B::A ! Case 3 !; else pass IN%"A@B" ! Case 2 !; 'alter_to: .word 7C ' ! ; entry mask save R2-R6 ' movq @B^4(ap),r0' ' movzwl r0,r0' ' clrl r2' 'cdblp1: cmpb #^x22,(r1)' ' beql cdbcs1' ' cmpb #^x40,(r1)+' ' beql cdbl1x' ' incl r2 ' ! ; length of A in A@B ' sobgtr r0,cdblp1' 'cdbcs1: movab @B^4(ap),r2' ' jmp cdbcom ' ! ; no changes - case 1 'cdbl1x: decl r0 ' ! ; count "@" ' bleq cdbcs1 ' ! ; branch if at end ' tstl r2' ' beql cdbcs1 ' ! ; branch if @B with no A ' clrl r3 ' ! ; now parse after "@" 'cdblp2: cmpb #^x22,(r1)' ' beql cdbcs1' ' cmpb #^x40,(r1)+' ' beql cdbcs1' ' incl r3 ' ! ; length of B in A@B ' sobgtr r0,cdblp2' !; passed test 1 - we have A@B - Now check A ' movq @B^4(ap),r0' !; allocate room on stack for 2 descriptors (for A and B) ' pushl r1' ' pushl r2' ' movl sp,r5 ' ! ; r5 points to desc(A) ' movl r2,r0' ' beql cdbcs1' ' jsb cdbck1' ' tstl r0' ' bneq cdbcs2' ' incl r1' ' pushl r1' ' pushl r3' ' movl sp,r6 ' ! ; r6 points to desc(B) ' movl r3,r0' ' beql cdbcs1' ' jsb cdbck1' ' tstl r0' ' beql cdbps2' ! ; build IN%"A@B" for case 2 !; use the stack this way for all $FAO !; outlen initial sp <- r3 <-r2 !; ptr to outbuf initial sp-264 <- r2 minus 8 !; ...... <- r2 to beg of ptr !; outbuf initial sp-4 <- r3 minus 4 !; ...... initial sp-256 <- sp 'cdbcs2: pushl #22534121 ' ! ; ctrstr #^A/!AS"/ ' pushl #2225584D ' ! ; ctrstr #^A/MX%"/ ' pushl sp ' ! ; make desc to ctrstr ' pushl #8 ' ! ; make desc to ctrstr ' movl sp,r4 ' ! ; address of desc to ctrstr ' subl #4,sp ' ! ; adjusted stack ' movl sp,r3 ' ! ; save stack for outlen ' movl sp,r2 ' ! ; end of desc to outbuf ' subl #108,sp ' ! ; end of outbuf ' movl sp,-(r2) ' ! ; make outbuf ' movzwl #100,-(r2) ' ! ; make outbuf ' pushl B^4(AP) ' ! ; #4 P1 pass what we got ' pushl r2 ' ! ; #3 outbuf ' pushl r3 ' ! ; #2 outlen ' pushl r4 ' ! ; #1 ctrstr ' calls #4,@#7FFEDF50 ' ! ; calls #04,g^sys$fao ' blbs r0,N102$' ' jmp cdberr' 'N102$: movw (r3),(r2) ' ! ; complete ptr to final text ' jmp cdbcom' 'cdbps2: movq @B^4(ap),r0' ' addl r2,r1' ' incl r1' ' movl r3,r0' ' jsb cdbck2' ' tstl r0' ' bneq cdbcs2 ' ! ; ! ! ; build B::A for case 3 'cdbcs3: pushl #5341213A ' ! ; ctrstr #^A/:!AS/ ' pushl #3A534121 ' ! ; ctrstr #^A/!AS:/ ' pushl sp ' ! ; make desc to ctrstr ' pushl #8 ' ! ; make desc to ctrstr ' movl sp,r4 ' ! ; address of desc to ctrstr ' subl #4,sp ' ! ; adjusted stack ' movl sp,r3 ' ! ; save stack for outlen ' movl sp,r2 ' ! ; end of desc to outbuf ' subl #108,sp ' ! ; end of outbuf ' movl sp,-(r2) ' ! ; make outbuf ' movzwl #100,-(r2) ' ! ; make outbuf ' pushl r5 ' ! ; #5 Second sub string A ' pushl r6 ' ! ; #4 first sub string B ' pushl r2 ' ! ; #3 outbuf ' pushl r3 ' ! ; #2 outlen ' pushl r4 ' ! ; #1 ctrstr ' calls #5,@#7FFEDF50 ' ! ; calls #05,g^sys$fao ' blbs r0,N103$' ' jmp cdberr' 'N103$: movw (r3),(r2) ' ! ; complete ptr to final text ' jmp cdbcom' !; check if all alpha numerical + .-_$% returns non zero 'cdbck1: cmpb #^x41,(r1)' ' bgtr cdbck11' ' cmpb #^x5A,(r1)' ' bgeq cdbck19' 'cdbck11: cmpb #^x61,(r1)' ' bgtr cdbck12' ' cmpb #^x7A,(r1)' ' bgeq cdbck19' 'cdbck12: cmpb #^x30,(r1)' ' bgtr cdbck13' ' cmpb #^x39,(r1)' ' bgeq cdbck19' 'cdbck13: cmpb #^x24,(r1)' ' beql cdbck19' ' cmpb #^x25,(r1)' ' beql cdbck19' ' cmpb #^x2D,(r1)' ' beql cdbck19' ' cmpb #^x2E,(r1)' ' beql cdbck19' ' cmpb #^x5F,(r1)' ' rsb' 'cdbck19: incl r1' ' sobgtr r0,cdbck1' ' rsb' !; check if we have at least one dot (then r0 > 0) 'cdbck2: cmpb #^x2E,(r1)' ' bneq cdbck29' ' rsb' 'cdbck29: incl r1' ' sobgtr r0,cdbck2' ' rsb' !; 'cdberr: movab @B^4(ap),r2 ' !; If SYS$FAO fails, use original addr 'cdbcom: MOVQ #^X00000001,-(SP)' ' movl B^8(ap),-(sp)' ' pushl r2' ' CALLS #04,L^ADD_ADDR' ' ret ' !; this is the only RET for ALTER_TO EXI ! Above was the new code ! Below is the patch in the existing code that ! will make use of the ALTER_TO new code RE MAIL$$ADD_ADDR 'MOVQ #^X00000001,-(SP)' 'MOVQ B^04(AP),-(SP)' 'CALLS #04,W^ADD_ADDR' 'RET' EXIT 'MOVQ B^04(AP),-(SP)' 'CALLS #02,ALTER_TO' 'RET' EXIT ! And now update if we reached this point without a single error U !---------------------- end of patch ---------------------- ______________________________________________________________________________ Henry Stilmack ) Computing Systems Manager ) Perform random kindnesses UK/Netherlands/Canada Joint Astronomy Centre ) and senseless acts of beauty 660 N. A'ohoku Place, Hilo, HI 96720 ) hps@jach.Hawaii.Edu 808-969-6530 ) ------------------------------------------------------------------------------ ================================================================================ Archive-Date: Sat, 12 Dec 1992 07:26:35 CST Date: Sat, 12 Dec 1992 08:22:38 EST From: "Steve Thompson, Cheme System Mangler" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: olin@cheme.cornell.edu Message-ID: <00964F7F.0C09AD00.13032@cheme.cornell.edu> Subject: Re: test >I posted this update of the MAILPATCH.COM (patch to MAILSHR.EXE which allows >MX to work without the "MX%") right after I ran into the same problem. Please >note the section of the file which customizes for VMS version - I added the bit >for v5.5-2. >(Note to Hunter - Do you want to put this into the new (whenever that is) >distribution? If so, go ahead). For VMS 5.5-1, the appropriate locations are: MAIL$$ADD_ADDR 000049D2 ADD_ADDR 000048FF However, I note that after installing the patch, I observe the following. I am using MX 3.1C and VMS 5.5-1. In the following, "host" is the short- form name of a local machine, "host.full" is the fully-qualified name. To: MX%"me@host" works To: MX%"me@host.full" works To: me@host.full works To: me@host appears to work but never delivers the message. Doesn't appear to be in the MX queue. Anyone else seen this? -Steve /SIGNATURE ================================================================================ Archive-Date: Mon, 14 Dec 1992 12:46:19 CST From: Subject: Turnaround time problem with MX 3.1/JNET Message-ID: <1992Dec14.185233.1@sejnet.sunet.se> Sender: news@sunic.sunet.se Reply-To: MX-List@WKUVX1.BITNET Date: Mon, 14 Dec 1992 18:52:33 GMT To: MX-List@WKUVX1.BITNET In order to provide an 8-bit clean path for nordic users wishing to create LISTSERV mailing lists where the official languages are scandinavian, I am starting to make intensive use of MX and am having a turnaround time problem. Users post to 'listname@LISTSERV.SUNET.SE', which is forwarded via a MX router rule to 'listname@SEARN.BITNET'. LISTSERV processes the message and sends mail with a %-hack back to the VAX, via JNET, which then takes care of the SMTP delivery. This bypasses the SMTP translation tables on the VM system which, unfortunately, I am not at liberty to change for 8-bitness as they are imposed by the INTERBIT specifications. It has already been agreed that INTERBIT must be updated to use 8-bit tables but we have not yet agreed on the table to use. Anyway the problem is that it takes a while for the VAX to forward mail - in either direction. The machine being mostly idle, it looks like there is a built-in delay for polling the JNET queues, but of course I may have misconfigured something. I am running MX V3.1. Is there anything I can do to make MX more responsive? It gives the users the impression the machine is heavily loaded at 3am on a sunday :-) Eric ================================================================================ Archive-Date: Tue, 15 Dec 1992 08:10:53 CST Date: Tue, 15 Dec 1992 15:06:37 +0100 From: "Lars Blomberg, KTH Stockholm" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: blomberg@plasma.kth.se Message-ID: <00965212.FAA366A0.9183@plasma.kth.se> Subject: File server case sensitivity We are currently running MX V3.1C with several mailing lists and file servers. Some of the file servers are associated with mailing lists to restrict access. It seems that for a user to be authorized to access such a file server the from-address must agree exactly (i.e., case-sensitively) with the address on the mailing list even if this has been specified with the /nocase option. Is this a bug in MX MLF or is our MX/mailing lists/file servers set up incorrectly? Lars Blomberg Royal Institute of Technology, Stockholm ================================================================================ Archive-Date: Tue, 15 Dec 1992 11:47:46 CST From: Subject: Re: File server case sensitivity Message-ID: <1992Dec15.170446.6239@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <00965212.FAA366A0.9183@plasma.kth.se> Date: Tue, 15 Dec 1992 17:04:46 GMT To: MX-List@WKUVX1.BITNET In article <00965212.FAA366A0.9183@plasma.kth.se>, "Lars Blomberg, KTH Stockholm" writes: >We are currently running MX V3.1C with several mailing lists and file servers. >Some of the file servers are associated with mailing lists to restrict access. >It seems that for a user to be authorized to access such a file server the >from-address must agree exactly (i.e., case-sensitively) with the address on >the mailing list even if this has been specified with the /nocase option. >Is this a bug in MX MLF or is our MX/mailing lists/file servers set up >incorrectly? Definitely a bug in MLF. I forgot to update the FILESERV_CHECK_ACCESS routine (in module FILESERV.B32) to handle NOCASE-set mailing list users. Thanks for finding it. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Tue, 15 Dec 1992 16:45:31 CST Sender: ault@jtk.queens.edu Date: Tue, 15 Dec 1992 17:32:37 EST From: "Richard H. Ault" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: ault@jtk.queens.edu Message-ID: <00965227.60447620.32361@jtk.queens.edu> Subject: MX delivery to black hole We are running MX 3.1C, UCX 1.3, and VMS 5.5-2 on new MV3100's. Accounts were moved from a functioning system on an MVII which didn't have the problems I'm now encountering (I think, that system was only on 5.5-2 for two weeks prior to the shift and the problem is only occuring on some low use accounts). The symptoms: Local VMS mail (node::user) works for all users and hosts. Inbound mail works for all users. Outbound mail addressed mx%"..." goes down a hole. For a mail addressed to a another user on another local node with debug on all I see is one entry in the router log that looks like: 15-DEC-1992 15:37:26.32 %PROCESS, Processing entry number 32360 15-DEC-1992 15:37:26.43 %PROCESS, Status from READ_INFO was 00000001 15-DEC-1992 15:37:26.43 %PROCESS, Message originated in VMS Mail. 15-DEC-1992 15:37:26.44 %PROCESS, will run domain expander on envelope addresses. 15-DEC-1992 15:37:26.44 %PROCESS, will run domain expander on message headers. 15-DEC-1992 15:37:26.73 %PROCESS, Finished VMSmail-origin preprocessing. 15-DEC-1992 15:37:26.73 %PROCESS, Marking this entry as finished. I can't find any entries in any other logs including Local that refer to this message, the user who sent it or the user it was addressed to. A user with sysprv shows this problem as well. MCP show all shows: Configuration file: MX_DEVICE:[MX]MX_CONFIG.MXCFG;7 MX version id is: MX V3.1C Domain-to-path mappings: Domain="queens.edu", Path=Local Domain="jtk.queens.edu", Path=Local Domain="jtk", Path=Local Domain="[152.36.64.252]", Path=Local Domain="*.BITNET", Path=SMTP, Route="cunyvm.cuny.edu" Domain="*.UUCP", Path=SMTP, Route="uunet.uu.net" Domain="*", Path=SMTP Aliases: LocalName="Postmaster", Address="ault@jlp.queens.edu" LocalName="POSTMAST", Address="ault@jlp.queens.edu" SMTP agent settings: Retry interval: 0 00:30:00.00 Maximum number of retries: 96 Number of DNS failure retries: 12 Accounting: disabled Default router: (none) LOCAL agent settings: DECnet delivery retry interval: 0 00:30:00.00 Maximum number of retries: 96 Accounting disabled. Top headers: FROM,SENDER,TO,RESENT_TO,CC,RESENT_CC,BCC,RESENT_BCC,MESSAGE_ID, RESENT_MESSAGE_ID,IN_REPLY_TO,REFERENCES,KEYWORDS,SUBJECT, ENCRYPTED,DATE,REPLY_TO,RECEIVED,RESENT_REPLY_TO,RESENT_FROM, RESENT_SENDER,RESENT_DATE,RETURN_PATH,OTHER Bottom headers: (none) ROUTER agent settings: Automatic percent-hack handling: enabled JNET agent settings: Automatic percent-hack handling: enabled BSMTP replies: disabled Accounting: disabled Lenient about gatewaying mail: no No mailer username set. DECnet_SMTP agent settings: Retry interval: 0 00:30:00.00 Maximum number of retries: 96 Accounting disabled. SITE agent settings: Retry interval: 0 00:30:00.00 Maximum number of retries: 96 X25_SMTP agent settings: Retry interval: 0 00:30:00.00 Maximum number of retries: 96 Accounting disabled. (queens.edu is defined in the DNS as a mail alias for jtk.queens.edu) and ucx$ucp show host gives: LOCAL database Host address Host name 127.0.0.1 LOCALHOST, localhost 152.36.64.251 jlp.queens.edu, jlp, JLP, admin, ADMIN 152.36.64.2 jr.queens.edu, jr, JR 152.36.64.252 jtk.queens.edu, jtk, JTK, james, JAMES, JTK.QUEENS.EDU 152.36.64.1 max.queens.edu, max, MAX 128.109.193.1 ncnoc.concert.net BIND database Server: 128.109.193.1 ncnoc.concert.net Host address Host name 192.101.21.1 ncnoc.concert.net 128.109.193.1 ncnoc.concert.net 128.109.131.3 reggae.concert.net 152.36.64.4 pc004.queens.edu 152.36.64.5 pc005.queens.edu 152.36.64.6 pc006.queens.edu 152.36.64.7 pc007.queens.edu 152.36.64.251 jlp.queens.edu 152.36.64.1 max.queens.edu 152.36.64.252 jtk.queens.edu 152.36.64.3 pc003.queens.edu 152.36.64.2 jr.queens.edu finally sh log mx* gives: (LNM$SYSTEM_TABLE) "MX_DEVICE" = "JTK$DKA300:" "MX_DIR" = "MX_DEVICE:[MX]" "MX_EXAMPLES_DIR" = "MX_ROOT:[EXAMPLES]" "MX_EXE" = "MX_ROOT:[EXE]" "MX_FLQ_DEBUG" = "ON" "MX_LOCAL_DEBUG" = "ON" "MX_LOCAL_DIR" = "MX_ROOT:[LOCAL]" "MX_MAILSHR" = "MX_EXE:MX_MAILSHR" "MX_MAILSHRP" = "MX_EXE:MX_MAILSHRP" "MX_MLF_DIR" = "MX_ROOT:[MLF]" "MX_MLIST_DIR" = "MX_ROOT:[MLF.MAILING_LISTS]" "MX_MSG" = "MX_EXE:MX_MSG" "MX_NODE_NAME" = "jtk.queens.edu" "MX_ROOT" = "MX_DEVICE:[MX.]" "MX_ROUTER_DEBUG" = "ON" "MX_ROUTER_DIR" = "MX_ROOT:[ROUTER]" "MX_SHR" = "MX_EXE:MX_SHR" "MX_SITE_DEBUG" = "ON" "MX_SITE_DOM_EXPANSION" = "MX_EXE:DOMAIN_EXPANSION" "MX_SMTP_DEBUG" = "ON" "MX_SMTP_DIR" = "MX_ROOT:[SMTP]" "MX_SMTP_SERVER_DEBUG" = "ON" "MX_VMSMAIL_FROM_FORMAT" = "" "MX_VMSMAIL_LOCALHOST" = "@jtk.queens.edu" Any suggestions, comments, any other information I should gather? HELP!! ================================================================================ Archive-Date: Tue, 15 Dec 1992 17:39:33 CST Date: Wed, 16 Dec 1992 00:17:27 +0100 From: Per Hogstedt Reply-To: MX-List@WKUVX1.BITNET Subject: The case problem Sender: hogstedt@plab.se To: MX-List@WKUVX1.BITNET Message-ID: <0096525F.EE37BF40.24543@plab.se> Matt spoke: >Definitely a bug in MLF. I forgot to update the FILESERV_CHECK_ACCESS routine >(in module FILESERV.B32) to handle NOCASE-set mailing list users. Thanks >for finding it. Since the case sensitivity problem has been a bit disturbing, I'd like to know if there is any chance that this could be corrected before the next release of MX (3.1d?). I don't know how extensive the update would be, but if there is anyone out there planning to hack away, I am interested to know and if possible help. Cheers, Per ------- Per Hogstedt Internet: hogstedt@plab.se Lindholmen Utveckling or: hogstedt@ae.chalmers.se P.O. Box 8714 Phone...: +46 31 50 70 50 S-402 75 Gothenburg Fax.....: +46 31 51 53 13 Sweden MiniCall: +46 74 35 68 49 ================================================================================ Archive-Date: Fri, 18 Dec 1992 07:29:01 CST Sender: goathunter@WKUVX1.BITNET Date: Fri, 18 Dec 1992 07:24:54 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096542D.F9FA7280.9679@WKUVX1.BITNET> Subject: RE: The case problem Per Hogstedt writes: > >Matt spoke: >>Definitely a bug in MLF. I forgot to update the FILESERV_CHECK_ACCESS routine >>(in module FILESERV.B32) to handle NOCASE-set mailing list users. Thanks >>for finding it. > >Since the case sensitivity problem has been a bit disturbing, I'd like to know >if there is any chance that this could be corrected before the next release >of MX (3.1d?). I don't know how extensive the update would be, but if there >is anyone out there planning to hack away, I am interested to know and if >possible help. > I've fixed this for the next release of MX. I'm shooting for a mid-to-late-January release of MX v3.1D. It'll feature mostly little fixes to annoying problems like this one. I'm also alpha-testing new FLQ routines that Matt wrote in BLISS (the old routines were written in PL/1). The new FLQ stuff still uses the ISAM queue file, but it now uses subdirectories of FLQ_DIR to store messages to try to alleviate problems with the QUEUE.DIR file getting larger than 128 blocks. The BLISS rewrite was necessary to get MX working on Alpha, which has been partially done. Here's my planned schedule. My wife has got my Christmas break all planned out for me 8-), so I won't be able to work on MX much, if at all, over the next three weeks. Around 1/14/93 (can you believe another year has gone by?), I hope to finish adding bug fixes, maybe a new feature or two, then build an installation kit for beta-testing. Once at least one other person successfully runs V3.1D 8-), I'll release it. Once v3.1D is released, I plan to spend time finishing the port of MX to Alpha. Matt has successfully sent a mail message from MX on an Alpha, but it has *not* been thoroughly tested yet. I hope to have MX v3.1D running (and tested) on Alpha by the end of February. After *that*, it is my intention to replace the ISAM SYSTEM_QUEUE.FLQ_CTL file with a more efficient method. Naturally, the comments above state my *plans*. I'm going to do my best to meet the deadlines I've set, but I make no warranties, guarantees, promises, oaths, etc., that it'll actually happen then. 8-) Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Fri, 18 Dec 1992 09:22:56 CST From: Subject: Re: MX delivery to black hole Date: 18 Dec 1992 14:33:36 GMT Message-ID: <1gsng0INN1oqi@rs1.rrz.Uni-Koeln.DE> References: <00965227.60447620.32361@jtk.queens.edu> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <00965227.60447620.32361@jtk.queens.edu>, "Richard H. Ault" writes: >We are running MX 3.1C, UCX 1.3, and VMS 5.5-2 on new MV3100's. Accounts were just a guess: don't you need a special version of UCX 1.3 (1.3A-number) in combination with VMS 5.5-x ? (or UCX 2.0) -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ KOSMA = Koelner Observatorium fuer SubMillimeter-Astronomie Andreas Moravec TEL +49 (221) 470 3558 I. Physikalisches Institut FAX +49 (221) 470 5162 Universitaet zu Koeln TELEX 888 2291 UNIK D Zuelpicher Str. 77 INTERNET Moravec@Ph1.Uni-Koeln.De 5000 Koeln 41, Germany X.400 S=Moravec;OU=Ph1;P=Uni-Koeln;A=DBP;C=DE ================================================================================ Archive-Date: Fri, 18 Dec 1992 09:23:09 CST From: bg@dymaxion.ns.ca Reply-To: MX-List@WKUVX1.BITNET Subject: MX->ANU-News gateway missing message-id's Message-ID: <1992Dec18.084836.83@dymaxion.ns.ca> Date: 18 Dec 92 08:48:36 AST To: MX-List@WKUVX1.BITNET I've been having problems with the MX -> News gateway. The site deliver log looks fine, but most of the NEWSGATE work files never make it into the local news database. I never seem to see any error messages from the Anu-News Add file/delete NEWSGATE*.BATCH command when I run my skim procedure in batch, but if I try to save copies of the same NEWSGATE batch files and then add them interactively, Anu-News complains that these messages are missing message-id's. Is this just me, or am I using a bad version of the gateway? The really strange thing is, occasionaly, a message actually does make it into the database. -- Ben Armstrong, Software Development bus: (902)422-1973 Dymaxion Research Ltd., fax: (902)421-1267 Halifax, Nova Scotia, Canada B3J 1R2 Internet: bg@dymaxion.ns.ca ================================================================================ Archive-Date: Fri, 18 Dec 1992 11:31:52 CST Date: Fri, 18 Dec 1992 17:29:20 +0100 From: Per Hogstedt Reply-To: MX-List@WKUVX1.BITNET Subject: RE: The case problem Sender: hogstedt@plab.se To: MX-List@WKUVX1.BITNET Message-ID: <00965482.6A46B9A0.25085@plab.se> While we're at it; would it be violating some RFC if /NOCASE could be enabled on a per-list basis vs on a per-user basis? That is, adding a /NOCASE qualifier to the CREATE command? /Per (one minute later) ================================================================================ Archive-Date: Fri, 18 Dec 1992 11:32:03 CST Date: Fri, 18 Dec 1992 17:22:55 +0100 From: Per Hogstedt Reply-To: MX-List@WKUVX1.BITNET Subject: RE: The case problem Sender: hogstedt@plab.se To: MX-List@WKUVX1.BITNET Message-ID: <00965481.8450CA80.25083@plab.se> Hunter said: >I've fixed this for the next release of MX. I'm shooting for a >mid-to-late-January release of MX v3.1D. It'll feature mostly little >fixes to annoying problems like this one. I'm also alpha-testing new >[...] > >Here's my planned schedule. My wife has got my Christmas break all >planned out for me 8-), so I won't be able to work on MX much, if at >all, over the next three weeks. Around 1/14/93 (can you believe >another year has gone by?), I hope to finish adding bug fixes, maybe a Thanks for the info Hunter. Late-January is all right at least for me, since my wife _also_ has planned the Christmas break (do we see a pattern evolving here? :-)) /Per ------- Per Hogstedt Internet: hogstedt@plab.se Lindholmen Utveckling or: hogstedt@ae.chalmers.se P.O. Box 8714 Phone...: +46 31 50 70 50 S-402 75 Gothenburg Fax.....: +46 31 51 53 13 Sweden MiniCall: +46 74 35 68 49 ------- ================================================================================ Archive-Date: Tue, 22 Dec 1992 10:06:46 CST Date: Tue, 22 Dec 1992 15:58:07 EST From: david@V4.PH.ED.AC.UK Reply-To: MX-List@WKUVX1.BITNET To: MX-List@RPIECSVX.BITNET CC: david@v2.ph.ed.ac.uk Message-ID: <0096579a.5597f300.2746@v2.ph.ed.ac.uk> Subject: MX Edinburgh, 22-DEC-1992 I see we are running MX V1.2 of April 1990. Has there been an update? David Candlin ================================================================================ Archive-Date: Tue, 22 Dec 1992 14:34:00 CST Date: Tue, 22 Dec 1992 13:23:02 EST From: Mighty Firebreather Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: david@v4.ph.ed.ac.uk Message-ID: <00965784.AB7883E0.30377@nscvax.princeton.edu> Subject: RE: MX David Candlin writes: > I see we are running MX V1.2 of April 1990. Has there been an update? Five or six updates. MX is now at V3.1C. You have missed, at the very least, 2.0, 2.1, 2.2, 3.0, and 3.1 plus a few "patch" releases. ************************************************************************* * * * Here, there be dragons! * * dragon@nscvax.princeton.edu * * * * Richard B. Gilbert * ************************************************************************* ================================================================================ Archive-Date: Tue, 22 Dec 1992 17:30:24 CST From: Reply-To: MX-List@WKUVX1.BITNET Subject: MX Address Rewrite Problem Message-ID: <1992Dec22.134501.56@ta.vkr.tnv.com> Date: 22 Dec 92 13:45:01 EST To: MX-List@WKUVX1.BITNET I am having a problem with the address rewrite rules. I am using MX 3.1C. The following rule is defined: define rewrite "<{user}@{host}.dnet.{stuf}.tnv.com>" - "<""{host}::{user}""@vtrm01>" According to the log file, MX_ROUTER_LOG.LOG, the following recipient address does not match this rule: Recipient #0: No rewrite rules matched Nothing on PATHLIST. Checking BITNET gateways... No path patterns matched vtrv01.dnet.js.vkr.tnv.com Rewrote ... as Any constructive advice would be appreciated. Thanks. -- Fred LaForest UUCP: vtrm01!flaforest VMS/UNIX/(Whatever else we have in the building) System Programmer Vickers, Inc. GEnie: FALAFOREST Troy, MI 48007-0302 ================================================================================ Archive-Date: Wed, 23 Dec 1992 07:12:46 CST Message-ID: <00965819.01E1CB80.15833@uwwvax.uww.edu> Date: Wed, 23 Dec 1992 07:04:53 CST From: hunterl@uwwvax.uww.edu Reply-To: MX-List@WKUVX1.BITNET Subject: error message To: mx-list@WKUVX1.BITNET Does any one the reason the following error message occurs: %NONAME-E-NOMSG, Message number 08638182 It is reproducible at our site on mail to almaden.ibm.com Lyle Hunter Computer Center University Wisconsin-Whitewater hunterl@uwwvax.uww.edu ================================================================================ Archive-Date: Wed, 23 Dec 1992 09:46:49 CST Date: 23 Dec 1992 10:40:08 -0500 (EST) From: "Jonathan E. Hardis" Reply-To: MX-List@WKUVX1.BITNET Subject: RE: MX Address Rewrite Problem To: MX-List@WKUVX1.BITNET CC: hardis@garnet.nist.gov Message-ID: <00965837.14371C40.8250@garnet.nist.gov> > Any constructive advice would be appreciated. Thanks. Just the obvious -- be careful of the order of the rewrite rules, and make sure that you restart all the MX agents after you change them. ================================================================================ Archive-Date: Wed, 23 Dec 1992 13:18:28 CST From: Subject: Re: error message Message-ID: <1992Dec23.172508.8393@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <00965819.01E1CB80.15833@uwwvax.uww.edu> Date: Wed, 23 Dec 1992 17:25:08 GMT To: MX-List@WKUVX1.BITNET In article <00965819.01E1CB80.15833@uwwvax.uww.edu>, hunterl@uwwvax.uww.edu writes: >Does any one the reason the following error message occurs: >%NONAME-E-NOMSG, Message number 08638182 >It is reproducible at our site on mail to almaden.ibm.com It looks like a CMU-Tek error code. From the CMU V6.5 NETERROR.MSG file, it would appear to be NET$_DSFMTERR. It's different for V6.4; I don't know if it's different for V6.6. You can check it yourself by digging out the NETERROR.MSG file for the version you're running, using $ MESSAGE/LIST/NOOBJ NETERROR.MSG to generate the listing, then SEARCHing the listing file for 08638182. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Wed, 23 Dec 1992 13:45:40 CST Sender: jpsmith@PINE.atmel.com Date: Tue, 22 Dec 1992 10:31:51 MST From: I Hate When That Happens Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: jpsmith@BALSA.atmel.com Message-ID: <0096576C.C104CC40.3751@BALSA> Subject: SIGNOFF for now SIGNOFF ================================================================================ Archive-Date: Thu, 24 Dec 1992 08:58:23 CST Subject: Something is stripping blanks.... Message-ID: <1992Dec24.082048.1098@dmc.com> From: Reply-To: MX-List@WKUVX1.BITNET Date: 24 Dec 92 08:20:48 EST To: MX-List@WKUVX1.BITNET I've performed a series of experiments and something is stripping blanks from mail messages: 1. Sent a message containing: aaaaaaaaaaa bbbbbbbbbbb to myself via UUCP%"munroe@dmc.com" The "blank" line had been filled with spaces. 2. Checked the spool file, it had spaces in it. 3. Checked the copy self copy delivered by mail. IT had spaces in it. 4. When UUCP/MX delivered the mail, the spaces were gone. So a few questions: (1) is my experiment bogus? (2) Does DECUS UUCP (or MX, since that's REALLY the entity that had the message last) strip blanks? (3) Is this behavior legal? (4) Should it be stopped? The following is the message I received. I don't know if it's MX or UUCP that's loosing the blanks. From: MX%"munroe@dmc.com" 24-DEC-1992 08:07:34.55 To: _MUNROE CC: Subj: Return-Path: Received: from thehulk by DMC.COM (MX V3.1) with UUCP; Thu, 24 Dec 1992 08:07:08 EST Received: by dmc.com (DECUS UUCP /2.0/2.0/2.0/); Thu, 24 Dec 92 08:05:33 EST Date: Thu, 24 Dec 92 08:05:33 EST Message-ID: <009658EAA5E5F0E0.20200534@dmc.com> From: munroe@dmc.com Subject: To: munroe@dmc.com X-VMS-Mail-To: UUCP%"munroe@dmc.com" X-VMS-Mail-CC: MUNROE aaaaaaaaaa cccccccccc ================================================================================ Archive-Date: Sat, 26 Dec 1992 14:48:57 CST From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: Something is stripping blanks.... Date: 26 Dec 1992 15:36:49 -0500 Message-ID: <1hifp1INN1sk@dayub.dayton.saic.com> References: <1992Dec24.082048.1098@dmc.com> To: MX-List@WKUVX1.BITNET Dick Munroe (munroe@dmc.com) wrote: : I've performed a series of experiments and something is : stripping blanks from mail messages: : 1. Sent a message containing: : aaaaaaaaaaa : : bbbbbbbbbbb : to myself via UUCP%"munroe@dmc.com" : The "blank" line had been filled with spaces. : 2. Checked the spool file, it had spaces in it. : 3. Checked the copy self copy delivered by mail. IT had spaces : in it. : 4. When UUCP/MX delivered the mail, the spaces were gone. : So a few questions: : (1) is my experiment bogus? No it is not. : (2) Does DECUS UUCP (or MX, since that's REALLY the entity that : had the message last) strip blanks? It is MX that is doing the stripping. : (3) Is this behavior legal? I don't think so. : (4) Should it be stopped? I had mentioned it to Hunter after I found it. You can see it also if you are running MX and not UUCP. I noticed it with a mail message send via SMTP and delivered with the traling blanks removed from each line. -- Earle Ake Internet: NSI-DECnet (SPAN): 28276::ake ================================================================================ Archive-Date: Wed, 30 Dec 1992 14:06:45 CST Subject: Re: Something is stripping blanks.... Message-ID: <1992Dec29.135018.1107@dmc.com> From: Reply-To: MX-List@WKUVX1.BITNET Date: 29 Dec 92 13:50:18 EST References: <1992Dec24.082048.1098@dmc.com> To: MX-List@WKUVX1.BITNET In article <1992Dec24.082048.1098@dmc.com>, munroe@dmc.com (Dick Munroe) writes: > I've performed a series of experiments and something is > stripping blanks from mail messages: Well, it was indeed MX, as Earle pointed out. Specifically it appears to be MX_RMAIL. The fix was pretty easy and for those of you with sources the DIFF to MX_RMAIL.B32 is enclosed. I've mailed this to Hunter for inclusion in the next release of MX. Merry Holidays all. Dick Munroe -------------------------------------------------------------------------------- *** mx_rmail.b32.1 --- mx_rmail.b32 ************** *** 1,5 %TITLE 'MX_RMAIL' ! MODULE MX_RMAIL (IDENT='V1.4-1', MAIN=MX_RMAIL) = BEGIN !++ ! FACILITY: MX UUCP interface --- 1,5 ----- %TITLE 'MX_RMAIL' ! MODULE MX_RMAIL (IDENT='V1.5', MAIN=MX_RMAIL) = BEGIN !++ ! FACILITY: MX UUCP interface ************** *** 34,39 ! 20-MAY-1991 V1.3-1 Madison Check for 822-type address in From_ header. ! 04-NOV-1991 V1.4 Madison Use new RCPTDEF structure. ! 15-NOV-1991 V1.4-1 Madison MEM RCPT rtns. !-- LIBRARY 'SYS$LIBRARY:STARLET'; --- 34,41 ----- ! 20-MAY-1991 V1.3-1 Madison Check for 822-type address in From_ header. ! 04-NOV-1991 V1.4 Madison Use new RCPTDEF structure. ! 15-NOV-1991 V1.4-1 Madison MEM RCPT rtns. + ! 27-Dec-1992 V1.5 Munroe Do NOT trim blanks from the message when it + ! is put into the message queue!!! !-- LIBRARY 'SYS$LIBRARY:STARLET'; ************** *** 373,378 ELSE STR$COPY_DX (SENDER, %ASCID'<>'); FLQ_ADD (.QAB, NEWENT); WRITE_INFO (.QAB, NEWENT, %ASCID'SRC_INFO', SENDER, INFOQ, --- 375,384 ----- ELSE STR$COPY_DX (SENDER, %ASCID'<>'); + !++ + ! Add the UUCP message to the router queue. + !-- + FLQ_ADD (.QAB, NEWENT); WRITE_INFO (.QAB, NEWENT, %ASCID'SRC_INFO', SENDER, INFOQ, ************** *** 390,398 END; WHILE MDM_READF (.UNIT, STR2) DO BEGIN ! STR$TRIM (STR, STR2); ! MDM_WRITEF (.UNIT2, STR); ! NEWENT [QENT_L_SIZE] = .NEWENT [QENT_L_SIZE] + .STR [DSC$W_LENGTH]; END; MDM_CLOSEF (.UNIT); MDM_CLOSEF (.UNIT2); --- 396,403 ----- END; WHILE MDM_READF (.UNIT, STR2) DO BEGIN ! MDM_WRITEF (.UNIT2, STR2); ! NEWENT [QENT_L_SIZE] = .NEWENT [QENT_L_SIZE] + .STR2 [DSC$W_LENGTH]; END; MDM_CLOSEF (.UNIT); MDM_CLOSEF (.UNIT2); -------------------------------------------------------------------------------- Dick Munroe Internet: munroe@dmc.com Doyle Munroe Consultants, Inc. UUCP: ...uunet!thehulk!munroe 267 Cox St. Office: (508) 568-1618 Hudson, Ma. FAX: (508) 562-1133 GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection. ================================================================================ Archive-Date: Wed, 30 Dec 1992 15:23:42 CST Subject: Re: Something is stripping blanks.... Message-ID: <1992Dec29.183421.22777@news.arc.nasa.gov> From: Date: Tue, 29 Dec 1992 18:34:21 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: usenet@news.arc.nasa.gov References: <1992Dec24.082048.1098@dmc.com> To: MX-List@WKUVX1.BITNET Yes, MX trims trailing blanks. It does this for two reasons. 1. You have to trim blanks on messages coming in from BITNET. The typical message format there is fixed-length 80-byte records. 2. It saves space on disk. The BITNET problem should probably be handled by doing the blank-trimming in the MX-Jnet interface ONLY. And saving disk space is probably not as important as retaining message integrity. It typically isn't harmful, though. You should not expect trailing blanks to be retained on any message you send, however, in case it has to pass through a network and/or system that does blank-trimming. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Wed, 30 Dec 1992 16:17:45 CST Date: 29 Dec 1992 15:32:03 -0700 (MST) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: SMTP-over-DECnet security To: mx-list@WKUVX1.BITNET Message-ID: <01GSW5HVNETE006MJF@VAXF.COLORADO.EDU> In the MX version 3.1 manual, section 3.8.1, "Creating a DECnet Object for DECnet-SMTP", it recommends creating a proxy to allow other systems to use the username for the SMTP DECnet object on your local node. Wouldn't this allow a user on the remote system (SYSTEM, or MAILER, or whatever is the user on the remote system) to get your system to run FAL and have access to your system, or am I missing something? It seems more secure to require the remote system use the normal DECnet login method (the NCP database supplies the username, password, and the file to execute) -- it seems like this then locks the remote user into executing the pre-defined .EXE (or .COM, however you set it up) which can then do nothing more than deliver mail all over the place. -Dan Wing, dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet (DGW11) Systems Administrator, University Hospital, Denver ================================================================================ Archive-Date: Wed, 30 Dec 1992 17:29:31 CST Date: Wed, 30 Dec 1992 11:34:59 MEZ From: Peter Kobe Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00965DBE.E6738C20.31093@PIB1.physik.uni-bonn.de> Subject: RE: error message Lyle Hunter hunterl@uwwvax.uww.edu aks: >Does any one the reason the following error message occurs: >%NONAME-E-NOMSG, Message number 08638182 >It is reproducible at our site on mail to almaden.ibm.com This Code is given by CMU??? DSFMTERR Domain service: domain server returned format error Peter ===================================================================== Peter Kobe Internet: system@pib1.physik.uni-bonn.de Physikalisches Institut HEPNET: 13562::SYSTEM Universitaet Bonn Tel: (49) 228 73 3222 D 53 Bonn FAX: (49) 228 73 7869 Nussallee 12 ================================================================================ Archive-Date: Wed, 30 Dec 1992 21:39:32 CST Date: Tue, 29 Dec 1992 12:22:24 EST From: pat@che.phys.Virginia.EDU Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: pat@gomez.phys.Virginia.EDU Message-ID: <00965cfc.5c2d8740.2806@gomez.phys.virginia.edu> Subject: "error in device name" message on MX 3.1 I've long been running MX 2.0 on a Vaxcluster, all seven of whose nodes are currently running VMS 5.5 and CMU-TEK version 6.6-5. I haven't upgraded MX for two reasons: 1) "If it ain't broke, don't fix it" and 2) A couple of previous attempts to upgrade to 3.1 have been unsuccessful. However, a recent lack of success on my users' part in sending messages to the CERN particle accelerator site in Europe (addresses ending in .CH, e.g., joe@foo.bar.ch; the messages simply vanish and no bounced mail messages are received) is forcing me to confront this upgrade (to 3.1; unless somebody advises me otherwise, I'll get 3.1 working first and then worry about 3.1C or whatever is the current revision) and conquer it by any means necessary, in hopes that the newer version will have less trouble sending to CERN. Here's my problem: I've customized the 3.1 installation for our site (the ROUTER, LOCAL, and MLF processes all run on 3 of the 7 nodes; SMTP runs on these 3 plus one other node; and SMTP_SERVER runs on all 7 nodes). As best I can tell, I've modified it so it should be configured just as it has been to successfully run MX 2.0. I start up MX and all the appropriate processes start up, and will run until I stop them myself. However, as soon as I try to send an outgoing message, I receive the following error: MAIL> send To: mx%"user@site.edu" ! dummy user and site, of course %RMS-F-DEV, error in device name or inappropriate device type for operation I've checked all of the appropriate logicals I'm aware of (SHOW LOGICAL *MX* and SHOW LOGICAL *NETLIB*), and as best I can tell they're all defined properly; i.e., all logicals defined to point to directories or files do so successfully and MX_INET_HOST, MX_NODE_NAME, MX_SMTP_DEFAULT_ROUTER and MX_VMSMAIL_LOCALHOST all point to the correct machines. Does anybody have any idea what could be wrong here? Apologies if this is a beginner's question; I've recently taken over MX duties from the guru who set up 2.0 on this site and am still on the learning curve. Also, please let me know if I can supply additional useful information. Many thanks in advance. - Patrick Walsh University of Virginia Department of Physics pw@virginia.bitnet, pw@virginia.edu, pat@gomez.phys.virginia.edu ================================================================================ Archive-Date: Wed, 30 Dec 1992 21:54:56 CST Sender: goathunter@WKUVX1.BITNET Date: Wed, 30 Dec 1992 21:54:14 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: pat@gomez.phys.virginia.edu Message-ID: <00965E15.6849F580.11527@WKUVX1.BITNET> Subject: RE: "error in device name" message on MX 3.1 pat@che.phys.Virginia.EDU writes: > >I start up MX and all the appropriate processes >start up, and will run until I stop them myself. However, as soon as I try >to send an outgoing message, I receive the following error: > >MAIL> send >To: mx%"user@site.edu" ! dummy user and site, of course >%RMS-F-DEV, error in device name or inappropriate device type for operation > Your definition of the logical FLQ_DIR is either missing or wrong, most likely. FLQ_DIR should point to the MX QUEUE directory ([MX.QUEUE], unless you specified some other directory at installation time). Also, you should make sure MX_MAILSHR and MX_MAILSHRP are defined as MX_EXE:MX_MAILSHR and MX_EXE:MX_MAILSHRP respectively. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Wed, 30 Dec 1992 23:24:41 CST Sender: yale!nuconvex.com!simonpg@harvard.harvard.edu Date: Wed, 30 Dec 1992 18:22:21 EST From: Paul Simons Reply-To: MX-List@WKUVX1.BITNET To: MX-List@RPIECSVX.BITNET Message-ID: <00965DF7.CEF190A3.12@nuconvex.com> Subject: Picky logical name translation I finally made some time to get MX 3.1c up and running. I'm going to write a gateway between MX and DEC's Message Router. Any input would be appreciated. I have successfully transferred messages from MX to ALL-IN-1 using addresses like . I defined the logical mx_event_oper_class to be "network", and all the MX processes died: %SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=244D4E4C, PC =00050F07, PSL=03C00001 %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel PC abs PC 00050F07 00050F07 00050E66 00050E66 MX_ROUTER READ_CONFIG 288 000000C4 000020A5 MX_ROUTER MX_ROUTER 102 00000045 00001C45 When I took away the quotes, all was well! Paul Simons simonpg@nuconvex.com yale!nuconvex!simonpg uunet!hsi!nuconvex!simonpg CONnecticut Valley Electric eXchange