Archive-Date: Fri, 03 Jan 1992 14:37:01 EST Sender: Date: Fri, 03 Jan 1992 14:36:39 EST From: Matt Madison Reply-To: Matt Madison To: mx-list@vms.ecs.rpi.edu Message-ID: <00954162.4E0C09E0.7715@vms.ecs.rpi.edu> Subject: MX V3.0 revision level A now available After receiving a handful of reports of minor bugs and one about a somewhat more major bug in MX V3.0, I have produced a maintenance release, called revision A. Everyone who obtains the MX030 kit by anonymous FTP will be getting the updated version. If you have MX V3.0 currently installed and would like to upgrade painlessly to V3.0A, you should get the files 01README.REVA_UPGRADE and MX_REVA_UPGRADE030.A_Z, which is the upgrade kit for existing V3.0 users. The MX030 kit on FILESERV will remain the older version for the time being; request package MX_REVA_UPGRADE030 for the upgrade kit. The bugs fixed in V3.0A are the ones that have been reported in the last month: 1. The /DEFAULT_ROUTER qualifier to the MCP SET SMTP command was not being recognized, due to a command table error. 2. The MCP MODIFY PATH command could not be used to update a route specification for a path. 3. Some SMTP 5xx general-failure error codes were not causing a message to be returned to sender, but instead were getting re-tried. This affected both SMTP-over-TCP/IP and SMTP-over-DECnet outbound messages. 4. The DOMAIN NAMES support added in V3.0 assumed that the mailer specified in DOMAIN NAMES was identical to the mailer in the XMAILER NAMES file for the gateway node, causing some gateway problems. 5. The MX_JNET process was not correctly handling an accounting file reset. 6. The LINK commands in the installation kit were being affected by LNK$LIBRARY logical names defined on some systems, causing some of the MX executables (noticeably, MX_MAILSHRP) to be linked incorrectly. All LINK commands in the installation kit have had the /NOUSERLIBRARY qualifier added to eliminate this problem. 7. The MCP help file incorrectly stated that the /REPLY_TO qualifier on the MCP DEFINE LIST command was not yet supported. The documentation for DEFINE LIST in the Management Guide is also incorrect; this will be fixed in a future documentation release. Number 4 on the list is a fairly important fix if you are trying to use the DOMAIN NAMES support in MX. The rest of the stuff is pretty minor. -Matt -- Matthew Madison, Systems Programmer | Internet: madison@vms.ecs.rpi.edu Engineering Computing Services | BITNET: MADISON@RPIECSVX Rensselaer Polytechnic Institute | Troy, New York 12180-3590 USA | ================================================================================ Archive-Date: Sun, 05 Jan 1992 09:33:27 EST To: mx-list@vms.ecs.rpi.edu Date: 2 Jan 92 23:48:42 GMT From: robin@lsl.co.uk (Robin Fairbairns) Reply-To: robin@lsl.co.uk (Robin Fairbairns) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan2.234842.1119@lsl.co.uk> Subject: Mail-list->news gatewaying under 3.0 I installed 3.0 over the holiday (well, other people were having a holiday, anyway ;-), and have made up for it by idling my time away on the first day "back" investigating (inter alia) use of mail-news gatewaying using the stuff in the "contrib" directory. (I'd put this off until I had 3.0, so as to be able to use alternative routings.) It's all very well, but gatemail fails to `trigger' on either of the first two lines coming out of a mailing list, viz., Return-Path and Errors-To. I'm happy to hack at gatemail (I already had to, to deal with a not-quite RFC822 header in the UK Coloured Book Software); but is this something that comes under Matt's heading of `minor bugs that have turned up under v3.0'? If so, I'll hold off - there's no _real_ problem, since NEWS ignores lines before "#! rnews", anyway. -- Robin Fairbairns, Senior Consultant, postmaster and general dogsbody Laser-Scan Ltd., Science Park, Milton Rd., Cambridge CB4 4FY, UK Email: robin@lsl.co.uk --or-- rf@cl.cam.ac.uk ================================================================================ Archive-Date: Mon, 06 Jan 1992 17:24:49 EST Sender: Date: Mon, 06 Jan 1992 16:26:15 CST From: Larry Fahnoe Reply-To: Larry Fahnoe To: mx-list@vms.ecs.rpi.edu Message-ID: <009543CD.1CB0E740.3083@ind.pillsbury.com> Subject: Suppress message text in debug reports? Is there a way that I can suppress the message text from showing up in the debugging logs? I know that it can be valuable to see the entire SMTP session, but normally, I'm only interested in the header information. If not, it might be nice to have an MCP SET agent qualifier to do this sort of thing. --Larry --- Larry Fahnoe The Pillsbury Co., M.S. 3272 Network Operations Supervisor 200 South 6th Street 612/330-8957 Minneapolis, MN 55402-1464 Internet: lfahnoe@ind.pillsbury.com -or- lfahnoe@nic.mr.net ================================================================================ Archive-Date: Mon, 06 Jan 1992 18:41:11 EST To: mx-list@vms.ecs.rpi.edu Date: 6 Jan 92 23:34:11 GMT From: ake@dayton.saic.com (Earle Ake) Reply-To: ake@dayton.saic.com (Earle Ake) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan6.183412.1970@dayton.saic.com> References: <009543CD.1CB0E740.3083@ind.pillsbury.com> Subject: Re: Suppress message text in debug reports? In article <009543CD.1CB0E740.3083@ind.pillsbury.com>, lfahnoe@ind.pillsbury.com (Larry Fahnoe) writes: > Is there a way that I can suppress the message text from showing up in > the debugging logs? I know that it can be valuable to see the entire > SMTP session, but normally, I'm only interested in the header > information. If not, it might be nice to have an MCP SET agent > qualifier to do this sort of thing. I don't really see the need for changing it. You don't have to debug that often to worry about it. Besides, sometimes the problem is in the middle of sending the message or when the link closes. If you only displayed the headers and not the entire session, you might lose some important information. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Tue, 07 Jan 1992 16:31:43 EST To: mx-list@vms.ecs.rpi.edu Date: 7 Jan 92 13:01:39 GMT From: robin@lsl.co.uk (Robin Fairbairns) Reply-To: robin@lsl.co.uk (Robin Fairbairns) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan7.130139.1128@lsl.co.uk> Subject: What is MCP REVIEW supposed to do? MCP for v3.0 includes a nice-looking command REVIEW However, I find I'm unable to get _anything_ out of it, regardless of how I invoke it. I've tried reviewing a list that has existed since the upgrade to 3.0 reviewing a list I've just created both the above, specifying @lsl.co.uk The last gives me a message saying that there's no such list; the other two simply produce no output whatever. Am I doing something wrong? Do others have success with this command? -- Robin Fairbairns, Senior Consultant, postmaster and general dogsbody Laser-Scan Ltd., Science Park, Milton Rd., Cambridge CB4 4FY, UK Email: robin@lsl.co.uk --or-- rf@cl.cam.ac.uk ================================================================================ Archive-Date: Tue, 07 Jan 1992 18:49:06 EST Sender: Date: Tue, 07 Jan 1992 16:46:50 CST From: "George D. Greenwade" Reply-To: "George D. Greenwade" To: robin@lsl.co.uk CC: mx-list@vms.ecs.rpi.edu Message-ID: <00954499.271413C0.20419@SHSU.edu> Subject: RE: What is MCP REVIEW supposed to do? In <1992Jan7.130139.1128@lsl.co.uk>, (MX-List, 7 Jan 92 13:01:39 GMT), robin@lsl.co.uk (Robin Fairbairns) posted: >MCP for v3.0 includes a nice-looking command REVIEW > >However, I find I'm unable to get _anything_ out of it, regardless of >how I invoke it. I've tried > reviewing a list that has existed since the upgrade to 3.0 > reviewing a list I've just created > both the above, specifying @lsl.co.uk > >The last gives me a message saying that there's no such list; the other >two simply produce no output whatever. > >Am I doing something wrong? Do others have success with this command? The command should work for all lists under 3.0 format. Do not add the node specification, just use MCP REVIEW list-name. For list owners out there, I found a handy use of this. Try MCP REVIEW listname/OUT=listname.ASCII. This provides an ASCII file which you can use the DCL SEARCH command verb on to check things quickly. 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, 08 Jan 1992 15:21:56 EST To: mx-list@vms.ecs.rpi.edu Date: 8 Jan 92 09:36:12 GMT From: robin@lsl.co.uk (Robin Fairbairns) Reply-To: robin@lsl.co.uk (Robin Fairbairns) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan8.093612.1130@lsl.co.uk> References: <1992Jan7.130139.1128@lsl.co.uk> Subject: Re: What is MCP REVIEW supposed to do? In article <1992Jan7.130139.1128@lsl.co.uk>, robin@lsl.co.uk (that's me) writes: > MCP for v3.0 includes a nice-looking command REVIEW > > However, I find I'm unable to get _anything_ out of it, regardless of > how I invoke it. I've tried > reviewing a list that has existed since the upgrade to 3.0 should have included ^before >[...] > Am I doing something wrong? Do others have success with this command? Several people (including the indefatigable BED_GDG - who also posted, and Matt himself) have mailed me to say that they do indeed have success with the command; most have suggested that I check that I have privileges for the task. In fact, I always assert process/priv=all before running MCP, since in the normal course of events even the MCP config file is protected against me. However, lest there was some silly going on, I logged in as SYSTEM and tried from there. Not even SYSTEM can review my lists. So thanks, all, but unless someone can think of some other bright idea, I suppose it's yet another thing that I must put down to being due to polarity w.r.t. the Atlantic Ocean (;-). -- Robin Fairbairns, Senior Consultant, postmaster and general dogsbody Laser-Scan Ltd., Science Park, Milton Rd., Cambridge CB4 4FY, UK Email: robin@lsl.co.uk --or-- rf@cl.cam.ac.uk ================================================================================ Archive-Date: Wed, 08 Jan 1992 19:00:29 EST To: mx-list@vms.ecs.rpi.edu Date: 8 Jan 92 22:00:35 GMT From: ake@dayton.saic.com (Earle Ake) Reply-To: ake@dayton.saic.com (Earle Ake) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan8.170035.1974@dayton.saic.com> References: <1992Jan7.130139.1128@lsl.co.uk>, <1992Jan8.093612.1130@lsl.co.uk> Subject: Re: What is MCP REVIEW supposed to do? In article <1992Jan8.093612.1130@lsl.co.uk>, robin@lsl.co.uk (Robin Fairbairns) writes: > In article <1992Jan7.130139.1128@lsl.co.uk>, robin@lsl.co.uk (that's me) writes: >> MCP for v3.0 includes a nice-looking command REVIEW >> >> However, I find I'm unable to get _anything_ out of it, regardless of >> how I invoke it. I've tried >> reviewing a list that has existed since the upgrade to 3.0 > should have included ^before >>[...] >> Am I doing something wrong? Do others have success with this command? > > Several people (including the indefatigable BED_GDG - who also posted, > and Matt himself) have mailed me to say that they do indeed have success > with the command; most have suggested that I check that I have > privileges for the task. > > In fact, I always assert process/priv=all before running MCP, since in > the normal course of events even the MCP config file is protected > against me. However, lest there was some silly going on, I logged in as > SYSTEM and tried from there. Not even SYSTEM can review my lists. > > So thanks, all, but unless someone can think of some other bright idea, > I suppose it's yet another thing that I must put down to being due to > polarity w.r.t. the Atlantic Ocean (;-). Try this. Look in the directory mx_root:[mlf.mailing_lists] for a file called 'your-list-name'.mailing_list. If that does not exist then the list has not been converted to the new format under 3.0. Maybe that's why the review command doesn't work. If that's the case, add a dummy user and then remove him will convert the list to the 3.0 format. Maybe that's it? Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Thu, 09 Jan 1992 14:45:58 EST Message-ID: <9201091941.AA24927@whistler.sfu.ca> Sender: hayward@whistler.sfu.ca Date: Thu, 9 Jan 1992 11:45:07 -0800 To: mx-list@vms.ecs.rpi.edu From: Michael_Hayward@whistler.sfu.ca Reply-To: Michael_Hayward@whistler.sfu.ca Subject: Rewrite rules and From: fields We run both MX and JNET on one of our VAXes, using it as a gateway into BITNET. One "problem" with the present configuration is that, when a message is sent through the MX software into BITNET, when it reaches its recipient (on a BITNET node), the From: field looks like: From: somename%somehost.sfu.ca@BITNODE where for this example "BITNODE" is the Bitnet node name of our VAX (which, again for the sake of this example, has an Internet-style name of "bitnode.sfu.ca"). We would like to be able to have it arrive with a From: field something like: From: someone@somehost.sfu.ca so that replies to the message would go through the Internet, rather than through Bitnet and back through the gateway. I tried a set of rewrite rules along the lines of: def rew "<{user}%{host}@bitnode.sfu.ca>" "<{user}@{host}>" def rew "<{user}%{host}@BITNODE.BITNET>" "<{user}@{host}>" def rew "<{user}%{host}@BITNODE>" "<{user}@{host}>" with no apparent effect on the From: field at the recipient's end. I have left Automatic percent-hack handling on for the agents, since I would like to at least be *able* to handle incoming addresses which have explicitly used the percent-hack source routing. Is there anyone else out there who has tried to solve this same "problem", or who might have other ideas/approaches? ...Michael Hayward ================================================================================ Archive-Date: Fri, 10 Jan 1992 05:33:20 EST To: mx-list@vms.ecs.rpi.edu Date: 8 Jan 92 18:14:38 GMT From: berk@inter-tel.com (Tom Berk) Reply-To: berk@inter-tel.com (Tom Berk) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan8.181438.2576@inter-tel.com> Subject: SMTP over DECnet Example (I attempted to post this a few weeks ago. I don't think it worked. If it did, and this is a duplicate, my apologies). I have an application for SMTP over DECnet. It's unclear to me from the documentation exactly how to set it up. How should the address look? Can anybody supply me with an example? Thanks in advance. -- Tom Berk Inter-Tel, Inc. Chandler, AZ berk@inter-tel.com 602-961-9000 ================================================================================ Archive-Date: Fri, 10 Jan 1992 11:24:15 EST Sender: Date: Fri, 10 Jan 1992 11:21:03 EST From: hak@hakvax.kodak.com Reply-To: hak@Kodak.COM To: mx-list@vms.ecs.rpi.edu Message-ID: <009546C7.237CB7A0.13357@hakvax.kodak.com> Subject: DECNET_SMTP on other than MX? If I understand things correctly, the DECNET_SMTP support will only work between two VMS boxes running MX ... Is that correct? Has ANYONE configured DECNET_SMTP between a VMS/MX system and any OTHER system type? AL Killenbeck, Eastman Kodak Co, Rochester, NY hak@kodak.com ================================================================================ Archive-Date: Mon, 13 Jan 1992 03:37:12 EST To: mx-list@vms.ecs.rpi.edu Date: 12 Jan 92 23:42:56 GMT From: robin@lsl.co.uk (Robin Fairbairns) Reply-To: robin@lsl.co.uk (Robin Fairbairns) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan12.234256.1143@lsl.co.uk> References: <1992Jan7.130139.1128@lsl.co.uk>, <1992Jan8.093612.1130@lsl.co.uk>, <1992Jan8.170035.1974@dayton.saic.com> Subject: Re: What is MCP REVIEW supposed to do? - SOLUTION In article <1992Jan8.170035.1974@dayton.saic.com>, ake@dayton.saic.com (Earle Ake) writes: > In article <1992Jan8.093612.1130@lsl.co.uk>, robin@lsl.co.uk (Robin Fairbairns) writes: >> In article <1992Jan7.130139.1128@lsl.co.uk>, robin@lsl.co.uk (that's me) writes: >>> MCP for v3.0 includes a nice-looking command REVIEW >>> >>> However, I find I'm unable to get _anything_ out of it, regardless of >>> how I invoke it. I've tried > > Try this. Look in the directory mx_root:[mlf.mailing_lists] for a > file called 'your-list-name'.mailing_list. If that does not exist then the > list has not been converted to the new format under 3.0. Maybe that's why > the review command doesn't work. If that's the case, add a dummy user and > then remove him will convert the list to the 3.0 format. Maybe that's it? Good old Earle: he provoked me into spotting the solution. His mention of that directory reminded me of the logical MX_MLIST_DIR in the documentation. Sure enough, that wasn't getting set on my system. I hand-edited it into the logicals file in mx_dir:, set it by hand in the running system, and lo! and behold! - REVIEW now works for me. For me, this raises the question of why the logicals file (which I presume is generated by the installation procedure) didn't contain that logical. Fwiw (in pursuance of my assumption), I installed everything except Jnet, Decnet SMTP and the documentation. -- Robin Fairbairns, Senior Consultant, postmaster and general dogsbody Laser-Scan Ltd., Science Park, Milton Rd., Cambridge CB4 4FY, UK Email: robin@lsl.co.uk --or-- rf@cl.cam.ac.uk ================================================================================ Archive-Date: Mon, 13 Jan 1992 10:44:08 EST To: mx-list@vms.ecs.rpi.edu Date: 13 Jan 92 14:41:35 GMT From: ake@dayton.saic.com (Earle Ake) Reply-To: ake@dayton.saic.com (Earle Ake) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan13.094135.1976@dayton.saic.com> References: <1992Jan8.093612.1130@lsl.co.uk>, <1992Jan8.170035.1974@dayton.saic.com>, <1992Jan12.234256.1143@lsl.co.uk> Subject: Re: What is MCP REVIEW supposed to do? - SOLUTION In article <1992Jan12.234256.1143@lsl.co.uk>, robin@lsl.co.uk (Robin Fairbairns) writes: > Good old Earle: he provoked me into spotting the solution. His mention > of that directory reminded me of the logical MX_MLIST_DIR in the > documentation. Sure enough, that wasn't getting set on my system. I > hand-edited it into the logicals file in mx_dir:, set it by hand in the > running system, and lo! and behold! - REVIEW now works for me. > > For me, this raises the question of why the logicals file (which I > presume is generated by the installation procedure) didn't contain that > logical. Fwiw (in pursuance of my assumption), I installed everything > except Jnet, Decnet SMTP and the documentation. The logical name should be defined in the mx_exe:mx_start.com file. Check to see if indeed the MLF is starting up properly. To do this, see if you have an entry for MLF in the mx_dir:mx_startup_info.dat file. You also might check to see if there is an error during the initial startup of MX by submitting the mx_startup.com and have it save the output. Something tells me it isn't right just yet. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Mon, 13 Jan 1992 11:09:59 EST Sender: Date: Mon, 13 Jan 1992 11:06:47 EST From: David Matthews (301)405-4830 Reply-To: David Matthews (301)405-4830 To: MX-LIST@vms.ecs.rpi.edu CC: dmatthews@uap.umd.edu Message-ID: <00954920.A47B1A80.6628@uap.umd.edu> Subject: Reply automatic editing software NEWSRDR has a nice reply arrangement that automatically brings up the replied-to message with each line preceded by a >. I need a similar thing for MX and/or VMS MAIL. Everyone else seems to have one. Any suggestions as to an ftp site? Dr. David L. Matthews, IPST, Univ. of Maryland, College Park MD 20742-2431 dmatthews@uap.umd.edu UMDUAP::DMATTHEWS (301)405-4830 FAX (301)314-9363 ================================================================================ Archive-Date: Mon, 13 Jan 1992 12:08:37 EST Date: Mon, 13 Jan 1992 13:04:24 EST From: "Bill Wilder: 902 679-5577" Reply-To: "Bill Wilder: 902 679-5577" Subject: Multiple instances of LOCAL and DEC_SMTP Processes Sender: wilder@NSRSKE.AGR.CA To: MX-LIST@VMS.ECS.RPI.EDU CC: wilder@NSRSKE.AGR.CA Message-ID: <00954931.12D40E00.1770@NSRSKE.AGR.CA> The documentation for MX V3.0 suggests multiple instances of LOCAL and DNSMTP processes may be started on a node (p. 9-3). However, MX_ROOT:[EXE]MX_START.COM seems hard-coded to allow this only for the ROUTER and SMTP processes. Which is correct? I can easily change MX_START to allow the multiple instances - any harm in doing so? Bill Wilder, Computer Systems Manager Internet: WILDER@NSRSKE.AGR.CA Research Station, Agriculture Canada Kentville, Nova Scotia CANADA Phone: (902) 679-5577 B4N 1J5 Fax: (902) 679-2311 ================================================================================ Archive-Date: Mon, 13 Jan 1992 12:32:28 EST Sender: Date: Mon, 13 Jan 1992 12:29:55 EST From: murphy@hal.hahnemann.edu Reply-To: murphy@hal.hahnemann.edu To: dmatthews@uap.umd.edu CC: mx-list@vms.ecs.rpi.edu Message-ID: <0095492C.4164C700.913@hal.hahnemann.edu> Subject: RE: Reply automatic editing software > From: MX%"dmatthews@uap.umd.edu" 13-JAN-1992 11:56:12.69 > Subj: Reply automatic editing software > NEWSRDR has a nice reply arrangement that automatically brings up the > replied-to message with each line preceded by a >. I need a similar thing > for MX and/or VMS MAIL. Everyone else seems to have one. Any suggestions > as to an ftp site? > > Dr. David L. Matthews, IPST, Univ. of Maryland, College Park MD 20742-2431 > dmatthews@uap.umd.edu > UMDUAP::DMATTHEWS > (301)405-4830 FAX (301)314-9363 There is a DCL command procedure called MAIL_EDIT.COM that was submitted to the DECUS symposia tapes at the Spring 1991 Symposium in Atlanta. It appears on either the VAX SIG symposium tape or on CD-ROM #9 from the DECUS library. Although MAIL_EDIT.COM is the standard way of getting VMS Mail to use an external editor, this is a highly customized version the command procedure. This version was developed at Memphis State by: Harry Flowers Internet: FLOWERS@MSUVX1.MEMST.EDU 112 Admin Bldg Bitnet: FLOWERS@MEMSTVX1 Memphis, TN 38152 Phone: (901) 678-2663 This is the author's description of the file: MAIL_EDIT.COM - This command file allows: o Spell checking of outgoing mail before you send it; uses the Vassar spelling package (not included) or any other which is invoked with the SPELL command. o Quoting of messages you reply to or forward. You may choose the quote character(s). The default is "> ". Unlike most of these on the net, this one will work with EDT or TPU because it achieves this with DCL. It also filters out the internal mail header on messages received through the foreign mail interface (keys off the "%"). o Appending a signature file to the end of your mail message. Directions for set-up and customization are included in the command file. I don't know if it is available via FTP. You could always send mail to the author at the one of the above addresses. I am afraid our site does not have anonymous ftp yet. If you can't get it from the author or one of the DECUS sources, I could probably email it to you. Although I don't have VMS SHARE or any thing else to compact it. The file size is 9 VMS blocks. I have been using this command procedure for the last few weeks and have not run into any problems. In fact, I used it while replying to your message. Hope this helps! John ------------------------------------------------------------------------------- H H U U | John Murphy | Voice: (215) 448-1042 HHHH U U | Library System Manager | Fax: (215) 448-8180 H H UUUU | Hahnemann University | EMail: murphy@hal.hahnemann.edu ------------------------------------------------------------------------------- ================================================================================ Archive-Date: Mon, 13 Jan 1992 14:48:38 EST To: mx-list@vms.ecs.rpi.edu Date: 13 Jan 92 14:03:19 EST From: ake@dayton.saic.com (Earle Ake) Reply-To: ake@dayton.saic.com (Earle Ake) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan13.140320.1977@dayton.saic.com> References: <00954920.A47B1A80.6628@uap.umd.edu> Subject: Re: Reply automatic editing software In article <00954920.A47B1A80.6628@uap.umd.edu>, dmatthews@uap.umd.edu (David Matthews 405-4830, 301) writes: > NEWSRDR has a nice reply arrangement that automatically brings up the > replied-to message with each line preceded by a >. I need a similar thing > for MX and/or VMS MAIL. Everyone else seems to have one. Any suggestions > as to an ftp site? I have something set up to use the TPU editor. It can be easily modified for the standard EDT editor if you choose. I can e-mail or post as it isn't that long. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Tue, 14 Jan 1992 16:44:20 EST Date: Tue, 14 Jan 1992 14:36:51 MST From: "Russ Wilton, Systems Manager" Reply-To: "Russ Wilton, Systems Manager" To: mx-list@vms.ecs.rpi.edu CC: wilton@hg.uleth.ca Message-ID: <00954A07.2AAB8CC0.18684@hg.uleth.ca> Subject: Mail looping Hi: I recently had a situation where a mail message was looping in the MX system. Someone at CAMIS.STANFORD.EDU sent a message to someone at my site and put a trailing period on the end of the address. I haven't checked the RFC's on this but I don't think it is legal to do this. In any case, my system went into a loop forwarding it to itself via SMTP, since it didn't recognize it as being for local delivery, with the period on the end. By the time I noticed the problem, it had been looping for three days and the nn.HDR_INFO file had grown to over 200 blocks. I have run into this type of problem before and have been able to protect against it with appropriate rewrite rules. But it doesn't seem to be possible to anticipate the odd ways people will mangle addresses, so I wonder if some protection against looping should be built right into MX itself. Another mail system I have some experience with, STMail, just counts the number of `Received:' headers on the message, and if it exceeds twenty, it is assumed to be looping and is returned to the sender. This is kind of a brute force method, but it does work, and I have never known it to return a message which wasn't in fact looping. It will also catch larger loops, where a message is bouncing amoung two or more nodes. I am running MX 2.3-1 on VMS 5.4-1, by the way. What are the chances of adding some loop protection in an upcoming version? I really can't afford the extra CPU and Disk I/O load that looping mail causes. Thanks Russ. #===============================================================# # Russell D Wilton E Mail: WILTON@HG.ULeth.CA # # Systems and Comm Manager Voice: (403) 329-2525 # # Computing Services FAX: (403) 329-2022 # # University of Lethbridge # # 4401 University Drive Lethbridge, Alberta, CANADA T1K 3M4 # #===============================================================# ================================================================================ Archive-Date: Tue, 14 Jan 1992 17:30:19 EST Sender: Date: Tue, 14 Jan 1992 14:26:12 PST From: Carl J Lydick Reply-To: Carl J Lydick To: mx-list@vms.ecs.rpi.edu Message-ID: <00954A05.AAA01EC0.20516@SOL1.GPS.CALTECH.EDU> Subject: RE: Mail looping > I recently had a situation where a mail message was looping in the MX >system. Someone at CAMIS.STANFORD.EDU sent a message to someone at my >site and put a trailing period on the end of the address. I haven't checked >the RFC's on this but I don't think it is legal to do this. In any case, >my system went into a loop forwarding it to itself via SMTP, since it didn't >recognize it as being for local delivery, with the period on the end. >By the time I noticed the problem, it had been looping for three days and >the nn.HDR_INFO file had grown to over 200 blocks. I've had similar things happen to me; always my fault. > I have run into this type of problem before and have been able to protect >against it with appropriate rewrite rules. But it doesn't seem to be possible >to anticipate the odd ways people will mangle addresses, so I wonder if some >protection against looping should be built right into MX itself. It's not necessary, since, as I'll explain below, you're greatly overstating the potential for the sort of mail loop you're talking about. > Another mail system I have some experience with, STMail, just counts the >number of `Received:' headers on the message, and if it exceeds twenty, it >is assumed to be looping and is returned to the sender. This is kind of a >brute force method, but it does work, and I have never known it to return >a message which wasn't in fact looping. It will also catch larger loops, >where a message is bouncing amoung two or more nodes. It will also prevent your mail from getting to you if you've had the misfortune to be on a long trip, stopping at a number of places, and at each stop forwarding your mail to your next intended stop from the machine you're currently sitting at because you can't manage to log in on your home machine or any of the machines already in the forwarding path for one reason or another. I've nearly had that happen to me once. Each of the places I stopped had a good enough network connection that they managed to get e-mail going in and out of their site, but trying to arrange an interactive terminal session so I could forward my mail directly from my home machine to the next point on my itinerary just wasn't feasible. I'm not saying this is a likely occurrence (unless, of course, you're part of a community that uses BITnet a lot :-), but it CAN happen. > I am running MX 2.3-1 on VMS 5.4-1, by the way. What are the chances of >adding some loop protection in an upcoming version? I really can't afford >the extra CPU and Disk I/O load that looping mail causes. You don't have to anticipate every possible perversion of addressing that will get a message intended for you sent to your machine. You merely have to anticipate all versions of your machine's name that your machine will resolve to itself. E.g., while someone could use an arbitrary nickname for your machine in their host tables, and their machine would dutifully send mail addressed to your machine via that nickname to your machine, that normally will NOT cause the sort of forwarding loop you describe. Only addresses that your own machine's TCP/IP package can resolve as pointing to your machine will cause such problems. I don't think it's unreasonable to ask that postmasters be familiar enough with the software they're running to be able to figure out what names will and won't resolve to their own machines. ================================================================================ Archive-Date: Tue, 14 Jan 1992 18:41:27 EST Date: Tue, 14 Jan 1992 16:30:00 MST From: "Russ Wilton, Systems Manager" Reply-To: "Russ Wilton, Systems Manager" To: carl@SOL1.GPS.CALTECH.EDU CC: mx-list@vms.ecs.rpi.edu, wilton@hg.uleth.ca Message-ID: <00954A16.F85BF600.19024@hg.uleth.ca> Subject: RE: Mail looping Carl Lydick writes: > >I've had similar things happen to me; always my fault. > As you say, it happens even to experts :-) so why not have some protection against it? > >It will also prevent your mail from getting to you if you've had the misfortune >to be on a long trip, stopping at a number of places, and at each stop >forwarding your mail to your next intended stop from the machine you're >currently sitting at because you can't manage to log in on your home machine or >any of the machines already in the forwarding path for one reason or another. > If this is a problem, then make the make the limit a MCP settable parameter, and you can set it to 100 if need be. > >You don't have to anticipate every possible perversion of addressing that will >get a message intended for you sent to your machine. You merely have to >anticipate all versions of your machine's name that your machine will resolve >to itself. > This is true for a tight loop of the type I encountered, but if you are sending mail to a machine which for some unknown reason forwards it back to you, you can still get into a looping situation even if your own tables are set up properly. I'm not suggesting that this is a major problem, but I suspect a lot of us have run into it from time to time. In the interests of saving us the annoyance of dealing with looping mail, and enhancing the reputation of MX as a solid system, I think a sanity check is not unreasonable. I guess only Matt can tell us how easy this would be to implement, but as the `Received:' lines are stripped off incomming messages and put into the HDR_INFO file, it shouldn't be too hard to count them. Any comments Matt? Russ. #===============================================================# # Russell D Wilton E Mail: WILTON@HG.ULeth.CA # # Systems and Comm Manager Voice: (403) 329-2525 # # Computing Services FAX: (403) 329-2022 # # University of Lethbridge # # 4401 University Drive Lethbridge, Alberta, CANADA T1K 3M4 # #===============================================================# ================================================================================ Archive-Date: Tue, 14 Jan 1992 18:58:39 EST Date: Tue, 14 Jan 1992 15:54:35 PST From: "John F. Sandhoff" Reply-To: sandhoff@csus.edu To: wilton@hg.uleth.ca CC: mx-list@vms.ecs.rpi.edu, syssand@CCVAX.CCS.CSUS.EDU Message-ID: <00954A12.03ACA2C0.22996@CCVAX.CCS.CSUS.EDU> Subject: RE: Mail looping > Another mail system I have some experience with, STMail, just counts the > number of `Received:' headers on the message, and if it exceeds twenty, it > is assumed to be looping and is returned to the sender. A slightly cleaner protection mechanism is to analyze the received headers looking for your own machine name. If you ("you" being the mailer software) find that you've already received this message before, then something must be wrong. Of course, I believe that you would need to make sure you've seen it several times before (the number 16 comes to mind as a safely high value) to prevent false rejections from it being bounced and passed back to you. John F. Sandhoff, Network Support California State University, Sacramento sandhoff@csus.edu ================================================================================ Archive-Date: Tue, 14 Jan 1992 21:51:23 EST Date: Tue, 14 Jan 1992 21:45:24 EST From: hardis@VAX844.PHY.NIST.GOV (Jonathan E. Hardis) Reply-To: hardis@VAX844.PHY.NIST.GOV (Jonathan E. Hardis) To: mx-list@vms.ecs.rpi.edu CC: hardis@VAX844.PHY.NIST.GOV Message-ID: <00954a43.05e8e0e0.5398@VAX844.PHY.NIST.GOV> Subject: Re: Mail looping I hesitate to bring this up, since I never bothered to diagnose it in detail and I'm only running Version 1.2 of MX. However, I have seen the problem where a message gets into a loop on my machine, spins around 15 times, and is returned to sender. The sender is a NeXT machine. (P.S. -- I'll install MX 3.0 when I have a chance.) ================================================================================ Archive-Date: Wed, 15 Jan 1992 12:02:11 EST To: mx-list@vms.ecs.rpi.edu Date: 15 Jan 92 15:43:16 GMT From: ake@dayton.saic.com (Earle Ake) Reply-To: ake@dayton.saic.com (Earle Ake) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan15.104316.1978@dayton.saic.com> References: <00954A12.03ACA2C0.22996@CCVAX.CCS.CSUS.EDU> Subject: RE: Mail looping In article <00954A12.03ACA2C0.22996@CCVAX.CCS.CSUS.EDU>, syssand@CCVAX.CCS.CSUS.EDU (John F. Sandhoff) writes: > >> Another mail system I have some experience with, STMail, just counts the >> number of `Received:' headers on the message, and if it exceeds twenty, it >> is assumed to be looping and is returned to the sender. > > A slightly cleaner protection mechanism is to analyze the received > headers looking for your own machine name. If you ("you" being the > mailer software) find that you've already received this message before, > then something must be wrong. Of course, I believe that you would need > to make sure you've seen it several times before (the number 16 comes > to mind as a safely high value) to prevent false rejections from it being > bounced and passed back to you. I ran into the same thing awhile back when I switched from CMU to MultiNet as the TCP/IP transport. There was an MX record messed up such that the mail also got into a loop. I saw the message go through here MANY times before I shutdown MX and manually killed it. I think it would be easy to implement the 16 headers before it is returned idea. What about it Matt? Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Thu, 16 Jan 1992 00:22:40 EST To: mx-list@vms.ecs.rpi.edu Date: 15 Jan 92 12:33:54 -0400 From: koffley@nrlvx1.nrl.navy.mil Reply-To: koffley@nrlvx1.nrl.navy.mil Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan15.123354.649@nrlvx1.nrl.navy.mil> Subject: MCP QUEUE command broken ? Has anybody seen this one ? Below are two calls to MCP using the new QUEUE command to SHOW and SHOW/ALL. Somehow I suspect that my queue file may not be in the new format (I believe there is a new queue file format anyway). $ mcp queue show Entry Status Size Source Agent Entry Status Size ----- ------ ------ ------ ------- ----- ------ ------ 16428 INPROG 97935 LOCAL SMTP 16453 INPROG 97935 17870 INPROG 935 MAIL BURDETT "IDM BOB" 17931 INPROG 51612 LOCAL SMTP 17935 INPROG 51612 18535 INPROG 0 LOCAL 19486 INPROG 102756 LOCAL SMTP 19583 INPROG 102756 20599 INPROG 637 LOCAL <> 21602 INPROG 51598 LOCAL 21604 INPROG 51636 LOCAL 21608 INPROG 51650 LOCAL 21683 INPROG 50936 LOCAL 21809 INPROG ****** LOCAL SMTP 21811 INPROG ****** %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000003, PC=0003DE2D, PSL=03C00000 Improperly handled condition, image exit forced. Signal arguments Stack contents Number = 00000005 00001AA8 Name = 0000000C 00000000 00000000 0003DE11 00000003 00000000 0003DE2D 21FC0000 03C00000 7FED2D38 7FED2D10 00009D59 7FED360C 7FED360C Register dump R0 = 00000000 R1 = 00000003 R2 = 7FED360C R3 = 7FED360C R4 = 00001AA8 R5 = 000288F8 R6 = 000286E0 R7 = 00028478 R8 = 000064F0 R9 = 00001114 R10= 000288F8 R11= 00028670 AP = 7FED2C6C FP = 7FED2C2C SP = 7FED2CA8 PC = 0003DE2D PSL= 03C00000 $ mcp queue show/all Entry Status Size Source Agent Entry Status Size ----- ------ ------ ------ ------- ----- ------ ------ 16428 INPROG 97935 LOCAL SMTP 16453 INPROG 97935 17870 INPROG 935 MAIL BURDETT "IDM BOB" 17931 INPROG 51612 LOCAL SMTP 17935 INPROG 51612 18535 INPROG 0 LOCAL 19486 INPROG 102756 LOCAL SMTP 19583 INPROG 102756 20599 INPROG 637 LOCAL <> 21602 INPROG 51598 LOCAL 21604 INPROG 51636 LOCAL 21608 INPROG 51650 LOCAL 21683 INPROG 50936 LOCAL 21809 INPROG ****** LOCAL SMTP 21811 INPROG ****** %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=00000003, PC=0003DE2D, PSL=03C00000 Improperly handled condition, image exit forced. Signal arguments Stack contents Number = 00000005 00001AA8 Name = 0000000C 00000000 00000000 0003DE11 00000003 00000000 0003DE2D 21FC0000 03C00000 7FED2D38 7FED2D10 00009D59 7FED360C 7FED360C Register dump R0 = 00000000 R1 = 00000003 R2 = 7FED360C R3 = 7FED360C R4 = 00001AA8 R5 = 000288F8 R6 = 000286E0 R7 = 00028478 R8 = 000064F0 R9 = 00001114 R10= 000288F8 R11= 00028670 AP = 7FED2C6C FP = 7FED2C2C SP = 7FED2CA8 PC = 0003DE2D PSL= 03C00000 -- \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ < Joe Koffley KOFFLEY@NRLVAX.NRL.NAVY.MIL > < Naval Research Laboratory KOFFLEY@CCF.NRL.NAVY.MIL > < Space Systems Division AT&T : 202-767-0894 > \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ ================================================================================ Archive-Date: Thu, 16 Jan 1992 17:40:48 EST To: mx-list@vms.ecs.rpi.edu Date: 16 Jan 92 22:36:59 GMT From: madison@mdmvs.ecs.rpi.edu (Matt Madison) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: References: <00954A12.03ACA2C0.22996@CCVAX.CCS.CSUS.EDU>,<1992Jan15.104316.1978@dayton.saic.com> Reply-To: madison@vms.ecs.rpi.edu Subject: RE: Mail looping Sounds like some reasonably intelligent counting of Received lines would help prevent some problems. I'll put it on my to-do list. -Matt -- Matthew Madison, Systems Programmer | Internet: madison@vms.ecs.rpi.edu Engineering Computing Services | Bitnet: MADISON@RPIECSVX Rensselaer Polytechnic Institute | Troy, New York 12180-3590 USA | ================================================================================ Archive-Date: Thu, 16 Jan 1992 19:21:28 EST Date: Thu, 16 Jan 1992 19:13:16 EST From: "Russell O. Redman" Reply-To: "Russell O. Redman" To: mx-list@vms.ecs.rpi.edu CC: redman@hiaras.hia.nrc.ca Message-ID: <00954BC0.19EAA5A0.15575@hiaras.hia.nrc.ca> Subject: RE: Mail looping We recently suffered from a mail loop similar to those described in the last few days (not involving MX though). One of the accounts of a subsciber to a LISTSERV list was deleted so that all further messages to that account were rejected by the system mailer and returned. Unfortunately, the system mailer seemed to have a non-standard name so that the listserver treated this a valid new submission to the list and rebroadcast it to everyone on the list, including to the nonexistant account. It bounced 14 times before I caught it and stopped it, and the damage would have been much worse had the account been on a North American machine with a shorter round trip delay. This kind of looping is much more serious than an internal loop in a local mail system, but could be controlled in the same way, with an intelligent count of the Received: lines. The correct response, however, is not to send the message back to the owner (which would just continue the same loop) but to divert the message to the Postmaster for human intervention. I suspect that the critical count to reject a potentially-looping message should be smaller for a mailing list than for regular mail (Any comments out there?) but ANY automatic limit is better than wait-till-Monday-morning-and-complain-to-the-system-manager, which is how I found out that I had a problem. So here is another vote in favour of intelligent Received: counting to limit mail loops. Russell O. Redman redman@hiaras.hia.nrc.ca ================================================================================ Archive-Date: Thu, 16 Jan 1992 19:47:46 EST Date: Fri, 17 Jan 1992 01:46:48 +0100 From: Per Hogstedt Reply-To: Per Hogstedt Subject: No From in envelope. Sender: hogstedt@plab.se To: mx-list@vms.ecs.rpi.edu Message-ID: <00954BF7.13423880.3534@plab.se> We have had a few cases of MX sending messages where the "From" part is missing in the envelope. This seems to happen when someone is sending a mail to a local user that does not exist, like a typo in the username. If I understand it correctly, the Internet RFC821 allows the return address to be empty, but unfortunately some gateways do not accept it, and the mail is hanging in their queues. My question is: is there a way of convincing MX to make shure this field is not empty, e.g., by putting the local postmaster as return address if no other is available? Regards, Per Hogstedt hogstedt@plab.se ================================================================================ Archive-Date: Fri, 17 Jan 1992 10:58:32 EST To: mx-list@vms.ecs.rpi.edu Date: 17 Jan 92 09:50:56 EST From: ake@dayton.saic.com (Earle Ake) Reply-To: ake@dayton.saic.com (Earle Ake) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan17.095056.1987@dayton.saic.com> References: <1992Jan2.234842.1119@lsl.co.uk> Subject: Re: Mail-list->news gatewaying under 3.0 (FIXED) In article <1992Jan2.234842.1119@lsl.co.uk>, robin@lsl.co.uk (Robin Fairbairns) writes: > I installed 3.0 over the holiday (well, other people were having a > holiday, anyway ;-), and have made up for it by idling my time away on > the first day "back" investigating (inter alia) use of mail-news > gatewaying using the stuff in the "contrib" directory. (I'd put this > off until I had 3.0, so as to be able to use alternative routings.) > > It's all very well, but gatemail fails to `trigger' on either of the > first two lines coming out of a mailing list, viz., Return-Path and > Errors-To. I'm happy to hack at gatemail (I already had to, to deal > with a not-quite RFC822 header in the UK Coloured Book Software); but is > this something that comes under Matt's heading of `minor bugs that have > turned up under v3.0'? If so, I'll hold off - there's no _real_ > problem, since NEWS ignores lines before "#! rnews", anyway. I have already sent Robin fixes for his problem. I just finished up modifying the mail/news gateway code and command procedures. I have the new vms_share file to Matt to be put into the contrib directory. These are MX3.0 specific changes so don't try this with pre-MX 3.0. If anyone finds a problem with the code or documentation, please let me know. I can also send the file to anyone directly if you want. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Sat, 18 Jan 1992 15:30:18 EST To: mx-list@vms.ecs.rpi.edu Date: 14 Jan 92 18:16:23 GMT From: robin@lsl.co.uk (Robin Fairbairns) Reply-To: robin@lsl.co.uk (Robin Fairbairns) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan14.181624.1157@lsl.co.uk> References: <1992Jan8.093612.1130@lsl.co.uk>, <1992Jan8.170035.1974@dayton.saic.com>, <1992Jan12.234256.1143@lsl.co.uk> Subject: Re: What is MCP REVIEW supposed to do? - SOLUTION In article <1992Jan12.234256.1143@lsl.co.uk>, robin@lsl.co.uk (Robin Fairbairns) writes: > [history deleted] > > [...] the logical MX_MLIST_DIR in the > documentation. Sure enough, that wasn't getting set on my system. I > hand-edited it into the logicals file in mx_dir:, set it by hand in the > running system, and lo! and behold! - REVIEW now works for me. Dave Goppelt (of Digital, but speaking _only_ for himself) has come up with what seems to me the explanation of this effect. He noticed that MCP REVIEW _only_ works (on a virgin MX V3 cluster) on the node which runs MLF. Now, on my cluster, that's a server that no-one's supposed to log in to (and in particular, I don't...). Presumably MX_MLIST_DIR was only necessary, in MX V<3, on the node(s) that run MLF - but now it's needed on any node an MX system user may log in on. I guess this constitutes a bug report, Matt. Well, a buglet, anyway. -- Robin Fairbairns, Senior Consultant, postmaster and general dogsbody Laser-Scan Ltd., Science Park, Milton Rd., Cambridge CB4 4FY, UK Email: robin@lsl.co.uk --or-- rf@cl.cam.ac.uk ================================================================================ Archive-Date: Mon, 20 Jan 1992 13:49:06 EST Message-ID: <199201201844.AA12104@csn.org> Date: Sun, 19 Jan 92 11:53:19 PDT From: Joe Carvalho Reply-To: Joe Carvalho To: mx-list@vms.ecs.rpi.edu Subject: SUBSCRIBE ================================================================================ Archive-Date: Mon, 20 Jan 1992 16:08:25 EST Return-Path: cts@dragon.COM Date: Mon, 20 Jan 92 16:01:41 EST Message-ID: <00954EC9FFC3C1E0.202002A3@dragon.com> From: cts@dragon.COM Reply-To: cts@dragon.COM Subject: Problem with UUCP Interface on MX 3.0 To: mx-list@vms.ecs.rpi.edu There seems to be a problem with MX 3.0 rev A with the UUCP interface. The UUCP From header contains a leading "!" in the path. This has been giving several mailers my machine talks to fits, as well as generating bad return paths. Example: From !dragon.com!sun-am!cts Mon, 20 Jan 92 15:44:14 EST remote from dragon UUCP generated a header without the leading "!". Does anyone have a workaround for this problem? Is there something in the rewrite rules that would fix this? Charles Smith cts@dragon.com ================================================================================ Archive-Date: Mon, 20 Jan 1992 20:08:16 EST To: mx-list@vms.ecs.rpi.edu Date: 20 Jan 92 19:26:42 EST From: ake@dayton.saic.com (Earle Ake) Reply-To: ake@dayton.saic.com (Earle Ake) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan20.192643.1991@dayton.saic.com> References: <00954EC9FFC3C1E0.202002A3@dragon.com> Subject: Re: Problem with UUCP Interface on MX 3.0 In article <00954EC9FFC3C1E0.202002A3@dragon.com>, cts@dragon.COM writes: > There seems to be a problem with MX 3.0 rev A with the UUCP interface. > The UUCP From header contains a leading "!" in the path. This has > been giving several mailers my machine talks to fits, as well as > generating bad return paths. > > Example: > > From !dragon.com!sun-am!cts Mon, 20 Jan 92 15:44:14 EST remote from dragon > > UUCP generated a header without the leading "!". > > Does anyone have a workaround for this problem? Is there something > in the rewrite rules that would fix this? The problem actually is in DECUS UUCP and not MX. MX only brought about the problem. The fix is to upgrade your uucp_mailshr image. What version of uucp are you now running? I can send you uucp 1.3-2 which will fix the problem. The problem comes from the fact that UUCP expects a from line that looks like: > From dragon.com!sun-am!cts Mon, 20 Jan 92 15:44:14 EST remote from dragon MX does not put the "remote from xxx" which is a legal thing to do. When UUCP parses the line, it puts in the leading "!" but since the line looks like: > From dragon.com!sun-am!cts Mon, 20 Jan 92 15:44:14 EST it doesn't have any site name to put in front of it. The new mailshr image fixes this. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Tue, 21 Jan 1992 13:35:50 EST To: mx-list@vms.ecs.rpi.edu Date: 21 Jan 92 09:35:39 EST From: ake@dayton.saic.com (Earle Ake) Reply-To: ake@dayton.saic.com (Earle Ake) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan21.093539.1996@dayton.saic.com> References: <00954EC9FFC3C1E0.202002A3@dragon.com>, <1992Jan20.192643.1991@dayton.saic.com> Subject: Re: Problem with UUCP Interface on MX 3.0 In article <1992Jan20.192643.1991@dayton.saic.com>, ake@dayton.saic.com (Earle Ake) writes: > In article <00954EC9FFC3C1E0.202002A3@dragon.com>, cts@dragon.COM writes: >> There seems to be a problem with MX 3.0 rev A with the UUCP interface. >> The UUCP From header contains a leading "!" in the path. This has >> been giving several mailers my machine talks to fits, as well as >> generating bad return paths. >> >> Example: >> >> From !dragon.com!sun-am!cts Mon, 20 Jan 92 15:44:14 EST remote from dragon >> >> UUCP generated a header without the leading "!". >> >> Does anyone have a workaround for this problem? Is there something >> in the rewrite rules that would fix this? > > The problem actually is in DECUS UUCP and not MX. MX only brought > about the problem. The fix is to upgrade your uucp_mailshr image. What > version of uucp are you now running? I can send you uucp 1.3-2 which will > fix the problem. I have made the executable available via mail. To receive the DECUS UUCP 1.3-2 mailshr image, send a message to fileserv@dayton.saic.com. The text of the message should contain only the line: send uucp_mailshr13-2 You will receive the image in MFTU encoded vms_shared format in 5 pieces. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Tue, 21 Jan 1992 18:26:06 EST Date: Tue, 21 Jan 1992 15:21:51 PST From: "John F. Sandhoff" Reply-To: sandhoff@csus.edu To: mx-list@vms.ecs.rpi.edu CC: syssand@CCVAX.CCS.CSUS.EDU Message-ID: <00954F8D.9A222600.27043@CCVAX.CCS.CSUS.EDU> Subject: SMTP-over-DECnet stupid query I've got a dumb, stupid, ignorant question. MX 3.0 contains support for SMTP-over-DECnet. What does it do for me? I realize that there's a new DECnet object that presumably gets around some of the DECmail-11 limitations. I also assume that the addressing is cleaner running this. (Right now I can send mail from a DECnet-only host to my cluster running MX by specifying the proper path: CCVAX::MX%"sandhoff@csus.edu". Ugliness). I assume the DECnet object gets defined on the MX node - but what gets installed on the DECnet node that communicates with it? How do I specify 'deliver mail via DECnet to "node x"'? I haven't actually done an install yet so maybe it'll become clear to me when I do. But what would help is a very brief description of what this new functionality looks like. John F. Sandhoff, Network Support California State University, Sacramento sandhoff@csus.edu ================================================================================ Archive-Date: Wed, 22 Jan 1992 12:55:45 EST To: mx-list@vms.ecs.rpi.edu Date: 22 Jan 92 10:53:51 EST From: ake@dayton.saic.com (Earle Ake) Reply-To: ake@dayton.saic.com (Earle Ake) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan22.105351.1998@dayton.saic.com> References: <00954F8D.9A222600.27043@CCVAX.CCS.CSUS.EDU> Subject: Re: SMTP-over-DECnet stupid query In article <00954F8D.9A222600.27043@CCVAX.CCS.CSUS.EDU>, syssand@CCVAX.CCS.CSUS.EDU (John F. Sandhoff) writes: > > I've got a dumb, stupid, ignorant question. MX 3.0 contains support > for SMTP-over-DECnet. What does it do for me? > > I realize that there's a new DECnet object that presumably gets > around some of the DECmail-11 limitations. I also assume that the > addressing is cleaner running this. (Right now I can send mail from a > DECnet-only host to my cluster running MX by specifying the proper > path: CCVAX::MX%"sandhoff@csus.edu". Ugliness). I assume the DECnet object > gets defined on the MX node - but what gets installed on the DECnet > node that communicates with it? How do I specify 'deliver mail via > DECnet to "node x"'? > > I haven't actually done an install yet so maybe it'll become clear > to me when I do. But what would help is a very brief description of > what this new functionality looks like. If you have only one node that runs tcp/ip and many other nodes DECnet connected, you can use MX on all nodes. The nodes that have only DECnet can send messages bound for other sites via the SMTP-over-DECnet channel. The message will have a decent return address. The message will not fail if the node CCVAX is not currently available as in your example. On the DECnet-only node, you install the base kit and the SMTP-over- DECnet pieces. On the internet node, you also install the SMTP-over-DECnet piece. Let's say that GATE is the gateway machine and END is the DECnet only box. Both nodes are in the csus.edu domain. Mail is sent to end.csus.edu. The MX record for end.csus.edu points to node gate.csus.edu. Node GATE receives the message then sends it via SMTP-over-DECnet to node END. Here is what the definitions look like in MCP: On the node END: MCP> DEFINE PATH "*end.csus.edu" Local MCP> DEFINE PATH * Decnet/ROUTE="GATE" On the node GATE: MCP> DEFINE PATH "end.csus.edu" Decnet/ROUTE="END" After setting up the SMTP-over-DECnet specific things, this should work. I can send you more information if you get frustrated. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Wed, 22 Jan 1992 13:29:18 EST Return-Path: cts@dragon.COM Date: Wed, 22 Jan 92 11:33:37 EST Message-ID: <00955036E1D868C0.20200497@dragon.com> From: cts@dragon.COM Reply-To: cts@dragon.COM Subject: Problem with looping messages to a mailing list. To: mx-list@vms.ecs.rpi.edu I've been having problems with mail looping to a mailing list from a mailer daemon or uucp account. Is there a good and simple way to deflect these messages to another account? ================================================================================ Archive-Date: Wed, 22 Jan 1992 14:34:39 EST From: Pedro Manuel Matias Reply-To: Pedro Manuel Matias To: MX-List@vms.ecs.rpi.edu Date: Wed, 22 Jan 92 17:18:47 GMT Subject: MX documentation Message-ID: <0696100727@CTQB01.CTQB.PT> I got the MX package as part of CMU/TEK 6.5 which means that the only documentation I got were the release notes (thats how I found out about this mailing list). Can anyone tell me how to obtain a copy of the Users Guide ? Thanks. Pedro Matias. ------------------------------------- Phone : (351-1) 442-6246 Ext. 341 Fax : (351-1) 442-8766 email : matias@ctqb01.ctqb.pt !!!! New address !!!! Mailing address : Centro de Tecnologia Quimica e Biologica Rua da Quinta Grande 6 Apartado 127 2780 OEIRAS Portugal ================================================================================ Archive-Date: Wed, 22 Jan 1992 14:34:54 EST Sender: Date: Wed, 22 Jan 1992 13:29:22 CST From: "George D. Greenwade" Reply-To: "George D. Greenwade" To: cts@dragon.COM CC: mx-list@vms.ecs.rpi.edu Message-ID: <00955047.0F934EA0.17177@SHSU.edu> Subject: RE: Problem with looping messages to a mailing list. On Wed, 22 Jan 92 11:33:37 EST, posted: > I've been having problems with mail looping to a mailing list from a mailer > daemon or uucp account. Is there a good and simple way to deflect these > messages to another account? Others may give better advice, but to really answer this, I'd need to see some of the bounce headers. The reason is that I need to see how the daemon is getting the list name to post back to. I assume that you've got the public consumption version of 3.0, that your list is set up so that the reply-to field is the original poster and that you've defined some alias as a errors-to/return-path field. If so, let's look at the header for this message > Return-Path: Should be the equivalent of the field in errors_to, i.e.: $MCP DEFINE LIST "MX-List"/ERROR="list-mgr@vms.ecs.rpi.edu" Received: from vms.ecs.rpi.edu by Niord.SHSU.EDU (MX V3.0A) with SMTP; Wed, 22 Jan 1992 13:06:26 CST > Errors-To: list-mgr@vms.ecs.rpi.edu Just to be sure > X-ListName: Message Exchange discussion list X-ListName was used in lieu of the original 2.4-2/3.0 Sender because of looping problems encountered at our site (and maybe a few others). >Received: from emory.mathcs.emory.edu by vms.ecs.rpi.edu (MX V3.0A) with SMTP; > Wed, 22 Jan 1992 13:29:07 EST >Received: from dragon.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.3.2.19) > via UUCP id AA16791 ; Wed, 22 Jan 92 13:25:40 -0500 >Return-Path: cts@dragon.COM Once more, please. >Received: by dragon.com (DECUS UUCP ///1.3-2/2.5/); Wed, 22 Jan 92 11:33:37 EST >Date: Wed, 22 Jan 92 11:33:37 EST >Message-ID: <00955036E1D868C0.20200497@dragon.com> >From: cts@dragon.COM This will point to you since you were the poster. > Reply-To: cts@dragon.COM This will also point to you if the list is set up to (nolist,sender), i.e.: $MCP DEFINE LIST "MX-List"/REPLY=(NOLIST,SENDER) If: $MCP DEFINE LIST "MX-List"/REPLY=(LIST,NOSENDER) had been specified, the Reply-To: field would have been mx-list@vms.ecs.rpi.edu While I have not yet seen a problem along these lines, it is something I am constantly aware of on those lists where we use (LIST,NOSENDER) and is a possible cause. The Return-Path: and Errors-To: should have been consulted first, though (to be RFC 822 consistent, I believe). >Subject: Problem with looping messages to a mailing list. >To: mx-list@vms.ecs.rpi.edu In all likelihood, this is the only place where your list name is appearing -- a daemon is seriously sick if it is referring to this field for a bounce. >X-Vms-Mail-To: MX-LIST My first suggestion is to REMOVE/NONOTIFY the user with the suspect address, then ADD/NONOTIFY USERSPEC NOMAIL them so you have them for reference and contact the bouncing site. If you would like to pass along a bounce header so I (or others) can take a look at it, please do so (no guarantees, but maybe....). 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, 22 Jan 1992 14:53:09 EST From: Pedro Manuel Matias Reply-To: Pedro Manuel Matias To: MX-List@vms.ecs.rpi.edu Date: Wed, 22 Jan 92 17:17:31 GMT Message-ID: <0696100651@CTQB01.CTQB.PT> SUBSCRIBE ------------------------------------- Phone : (351-1) 442-6246 Ext. 341 Fax : (351-1) 442-8766 email : matias@ctqb01.ctqb.pt !!!! New address !!!! Mailing address : Centro de Tecnologia Quimica e Biologica Rua da Quinta Grande 6 Apartado 127 2780 OEIRAS Portugal ================================================================================ Archive-Date: Wed, 22 Jan 1992 20:04:58 EST Return-Path: cts@dragon.COM Date: Wed, 22 Jan 92 19:28:02 EST Message-ID: <0095507928088680.20200407@dragon.com> From: cts@dragon.COM Reply-To: cts@dragon.COM Subject: RE: Problem with looping messages to a mailing list To: mx-list@vms.ecs.rpi.edu >Others may give better advice, but to really answer this, I'd need to see >some of the bounce headers. The reason is that I need to see how the >daemon is getting the list name to post back to. I assume that you've got >the public consumption version of 3.0, that your list is set up so that the >reply-to field is the original poster and that you've defined some alias as >a errors-to/return-path field. If so, let's look at the header for this >message I'm using MX 3.0, rev A, have an errors to path, and have the reply set to (list,nosender). >Should be the equivalent of the field in errors_to, i.e.: >$MCP DEFINE LIST "MX-List"/ERROR="list-mgr@vms.ecs.rpi.edu" The error path is to the list admin. -- Charles Smith cts@dragon.com ================================================================================ Archive-Date: Thu, 23 Jan 1992 09:07:55 EST Sender: Date: Thu, 23 Jan 1992 07:58:47 CST From: "George D. Greenwade" Reply-To: "George D. Greenwade" To: cts@dragon.COM CC: mx-list@vms.ecs.rpi.edu Message-ID: <009550E2.095B5820.19801@SHSU.edu> Subject: RE: Problem with looping messages to a mailing list In <0095507928088680.20200407@dragon.com> (Wed, 22 Jan 92 19:28:02 EST), Charles Smith posted: > I'm using MX 3.0, rev A, have an errors to path, and have the reply set to > (list,nosender). > > >Should be the equivalent of the field in errors_to, i.e.: > >$MCP DEFINE LIST "MX-List"/ERROR="list-mgr@vms.ecs.rpi.edu" > > The error path is to the list admin. The bouncing mailer has a problem -- it is looking at the Reply-To: field to bounce and overlooking the prior fields which it ought to be looking at (such as From:, if nothing else). The problem field (as far as the offending host is concerned is the Reply-To: field since the listname is what ought to be appearing in that field under your configuration. Again, I suggest temporarily removing users at the offending site via REMOVE/NONOTIFY "username" and ADD/NONOTIFY "username" NOMAIL then sending a nicely worded message to the postmaster@badhost (with a cc to the affected users) explaining the problem to him/her (i.e., consumption of bandwidth with junk mail making their site look foolish) and kindly requesting that they look into it. Alternately (and this is a second best option), temporarily set the list to (NOLIST,SENDER) and see what the behavior of badhost is. Postmaster@badhost still needs to know about this, though! Regards and best wishes, 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: Thu, 23 Jan 1992 11:22:32 EST To: mx-list@vms.ecs.rpi.edu Date: 23 Jan 92 00:56:30 PST From: jeh@cmkrnl.com Reply-To: jeh@cmkrnl.com Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan23.005630.255@cmkrnl.com> References: <00954EC9FFC3C1E0.202002A3@dragon.com>, <1992Jan20.192643.1991@dayton.saic.com>, <1992Jan21.093539.1996@dayton.saic.com> Subject: UUCP Version 1.3-2 ?!? (Was: Problem with UUCP Interface on MX 3.0 In article <1992Jan21.093539.1996@dayton.saic.com>, ake@dayton.saic.com (Earle Ake) writes: > In article <1992Jan20.192643.1991@dayton.saic.com>, ake@dayton.saic.com (Earle Ake) writes: >> I can send you uucp 1.3-2 which will fix the problem. > > I have made the executable available via mail. To receive the DECUS > UUCP 1.3-2 mailshr image, send a message to fileserv@dayton.saic.com. [...] What the heck is version 1.3-2? We have released version 1.3A. The next version will be 1.3B (unless a lot of us get our acts together and do a LOT of work first). Or is "version 1.3-2" simply a version of uucp_mailshr ? --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG Internet: jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com Uucp: ...{crash,eisner,uunet}!cmkrnl!jeh ================================================================================ Archive-Date: Thu, 23 Jan 1992 12:26:44 EST Date: Thu, 23 Jan 1992 12:23:28 EST From: Jim Gaynor Reply-To: Jim Gaynor To: mx-list@vms.ecs.rpi.edu Message-ID: <00955107.02F32D80.14739@agvax2.ag.ohio-state.edu> Subject: Mailing from All-In-1 2.4 after K602 patch... Hullo, all. I just applied the All-In-1 2.4 Update 2.0, which includes the k602 patch. One of the things that the k602 patch "fixes" is that fact that you cannot have lower-case addresses when sending mail to the "special" address (using a "_" in front of the address.) This means that SPECIAL.COM is updated by this patch, as well as other things relating to it. The practical upshot of all this is that, after applying the patch, using my modified SPECIAL.COM to send mail via MX caused the message to vanish into the bit bucket, never to return. Never fear, for I went ahead and rewrote it. The following version of SPECIAL.COM will allow you to send email from All-In-1 via MX, by prefacing the address with "_". Thus, if you desire to send email to "fred@bigvax.stateu.edu", you'd enter "_fred@bigvax.stateu.edu" in All-In-1's TO: field. This rewrite incorporates the "/NOCC" fix that was noted here on the MX-list, and I've added some decent commenting as well. Thanks to all appropriate people, as my brain is too soggy to recall specific names. One final note - after you add this in using the Customization Management section, and your System Manager (if it isn't you) moves it to the "live" area, make sure that the file itself is world readable and executable. Otherwise, non-privved users won't be able to use it. -- Jim Gaynor * * * Cut Here * * * $! OALIB:SPECIAL.COM V2.4 - K602 Last edited: (see rev notes) $! Electronic Mail Subsystem $! Deliver mail to the "SPECIAL" destination $! $! Rev Notes: $! $! This version of SPECIAL.COM has been modified to send all mail $! "special routed" mail out via an SMTP transport. In this case, $! it is Message Exchange, aka MX. One portion has been added, and $! certain minor portions have been commented out. Nothing of the $! original file has been deleted. $! $! 22/jan/1992 Jim Gaynor $! $ ASSIGN/USER NLA0: SYS$OUTPUT $ ASSIGN/USER NLA0: SYS$ERROR $ ON WARNING THEN GOTO NOT_SENT $ ORIG_DIR := 'F$LOGICAL("SYS$DISK")''F$DIRECTORY()' $ MY_NODE := 'F$LOGICAL("SYS$NODE") $ $ UNDERLINE_LOOP: $ IF "''F$EXTRACT(0,1,MY_NODE)'" .NES. "_" THEN GOTO SETUP_PARAM $ MY_NODE := 'F$EXTRACT(1,99,MY_NODE) $ GOTO UNDERLINE_LOOP $ $ SETUP_PARAM: $ WRITE OAMAILBOX "OA GET PROFIL.DIRECT[OA$USER]" $ @DCLMAILBOX: $ HOME_DIR = RESULT $ WRITE OAMAILBOX "OA GET #MAILSUBJ" $ @DCLMAILBOX: $ SUBJ = RESULT $ WRITE OAMAILBOX "OA GET #MAILFILE" $ @DCLMAILBOX: $ FILE = RESULT $ WRITE OAMAILBOX "OA GET #MAILNODE" $ @DCLMAILBOX: $ NODE = RESULT $ IF NODE .EQS. "" THEN GOTO SEND_IT $ IF 'F$LOCATE("::",NODE) .EQ. 'F$LENGTH(NODE) THEN NODE := 'NODE':: $ IF "''MY_NODE'" .EQS. "''NODE'" THEN NODE := "" $ WRITE OAMAILBOX "OA GET OA$STATUS=""1""" $ @DCLMAILBOX: $ $ SEND_IT: $ WRITE OAMAILBOX "OA GET #MAILADDR" $ @DCLMAILBOX: $ TO = NODE + RESULT $ LOOP1: $ IF F$EXTRACT(0,1,TO) .NES. "_" THEN GOTO REALLY_SEND $ TO = F$EXTRACT(1,99,TO) $ GOTO LOOP1 $ REALLY_SEND: $ ASSIGN/USER NLA0: SYS$OUTPUT $ ASSIGN/USER NLA0: SYS$ERROR $ SET DEFAULT 'HOME_DIR $! $! Here start the fancy things added for Internet mailing $! $! First, we knock the contents of "TO" down to all lower case, $! since that's what the net likes. We also add the transport name $! to the front. In this case it's "MX%" for Message Exchange. But $! it could also be "IN%", "WIN%", "SMTP%", or whatever is used on $! your own particular system. $! $ TO = "MX%" + """""" + F$EDIT(TO,"LOWERCASE") + """""" $! $! Since we can't pass the quotes that MX requires via standard DCL, $! we'll write the MAIL command to a .COM file and submit it that way. $! $ OPEN/WRITE OUTFILE SPECIAL_TEMP.COM $ WRITE OUTFILE "$MAIL" $ WRITE OUTFILE "SEND/NOEDIT/NOSELF/NOCC ''FILE'" $ WRITE OUTFILE "''TO'" $ WRITE OUTFILE "''SUBJ'" $ WRITE OUTFILE "EXIT" $ WRITE OUTFILE "$EXIT" $ CLOSE OUTFILE $! $! Run the .COM file we just made, and then delete it to leave no $! trace that we were here. $! $ @SPECIAL_TEMP $ DELETE /NOCONFIRM SPECIAL_TEMP.COM;* $! $! End of add-ins. Following stuff is commented out, since it $! doesn't work (or is irrelevant) after the stuff we just added in. $! $! MAIL/SUBJ=&SUBJ &FILE &TO $! IF $STATUS THEN GOTO DONE $! $! NOT_SENT: $! Status := '$STATUS $! WRITE OAMAILBOX "OA GET OA$STATUS=""''STATUS'""" $! @DCLMAILBOX: $! $! We now return you to your regularly scheduled SPECIAL.COM... $! $ DONE: $ SET DEFAULT 'ORIG_DIR $ EXIT * * * End of Add-In * * * --- Jim Gaynor - System Analyst Internet: gaynor@agvax2.ag.ohio-state.edu Ohio State University - ACS/FMS Phone: Voice 614/292-4338 - FAX 614/292-7443 ObDiscl: Everything stated here and above is _my_ opinion. Mine mine mine! ObQuote: "Aiiiigggghhhh! Small children!" - John Cusack, "Hot Pursuit" ================================================================================ Archive-Date: Thu, 23 Jan 1992 14:12:13 EST To: mx-list@vms.ecs.rpi.edu Date: 23 Jan 92 17:21:37 GMT From: ake@dayton.saic.com (Earle Ake) Reply-To: ake@dayton.saic.com (Earle Ake) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan23.122137.2000@dayton.saic.com> References: <1992Jan20.192643.1991@dayton.saic.com>, <1992Jan21.093539.1996@dayton.saic.com>, <1992Jan23.005630.255@cmkrnl.com> Subject: Re: UUCP Version 1.3-2 ?!? (Was: Problem with UUCP Interface on MX 3.0 In article <1992Jan23.005630.255@cmkrnl.com>, jeh@cmkrnl.com writes: > In article <1992Jan21.093539.1996@dayton.saic.com>, ake@dayton.saic.com (Earle Ake) writes: >> In article <1992Jan20.192643.1991@dayton.saic.com>, ake@dayton.saic.com (Earle Ake) writes: >>> I can send you uucp 1.3-2 which will fix the problem. >> >> I have made the executable available via mail. To receive the DECUS >> UUCP 1.3-2 mailshr image, send a message to fileserv@dayton.saic.com. [...] > > What the heck is version 1.3-2? > > We have released version 1.3A. The next version will be 1.3B (unless a lot of > us get our acts together and do a LOT of work first). > > Or is "version 1.3-2" simply a version of uucp_mailshr ? The 1.3-2 is a version of the mailshr image from Tom Allebrandi. This was a fix for the problem of a leading bag in the first from line of the uucp message. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Thu, 23 Jan 1992 14:51:16 EST To: mx-list@vms.ecs.rpi.edu Date: 23 Jan 92 18:26:09 GMT From: berk@inter-tel.com (Tom Berk) Reply-To: berk@inter-tel.com (Tom Berk) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan23.182609.1904@inter-tel.com> Subject: error activating transport MX I've run into a problem when trying to install MX (3.0) on a MicroVAX 2000 running VMS 5.1. Everything seems to go OK in the installation, but when I try to send a mail message through MX, I get an error. I've installed the same version on systems running VMS 5.4, 5.4-2, and 5.0-2 with no problems. Here's a copy of the output: $ MAIL MAIL> s/noedit To: MX%"SYSTEM@TUCSON.INTER-TEL.COM" %MAIL-E-ERRACTRNS, error activating transport MX %LIB-E-ACTIMAGE, error activating image DUA1:[MX.][EXE]MX_MAILSHRP.EXE -SYSTEM-F-NOSHRIMG, privileged shareable image cannot have outbound calls I thought we must have had something INSTALLed that shouldn't be, but a reboot and re-installation did not clear up the problem. Any clues? What other information can I get? -- Tom Berk Inter-Tel, Inc. Chandler, AZ berk@inter-tel.com 602-961-9000 ================================================================================ Archive-Date: Thu, 23 Jan 1992 17:58:45 EST To: mx-list@vms.ecs.rpi.edu Date: 23 Jan 92 20:31:21 GMT From: ake@dayton.saic.com (Earle Ake) Reply-To: ake@dayton.saic.com (Earle Ake) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan23.153121.2001@dayton.saic.com> References: <1992Jan23.182609.1904@inter-tel.com> Subject: Re: error activating transport MX In article <1992Jan23.182609.1904@inter-tel.com>, berk@inter-tel.com (Tom Berk) writes: > > I've run into a problem when trying to install MX (3.0) on a MicroVAX 2000 > running VMS 5.1. Everything seems to go OK in the installation, but when > I try to send a mail message through MX, I get an error. I've installed the > same version on systems running VMS 5.4, 5.4-2, and 5.0-2 with no problems. > > Here's a copy of > the output: > > $ MAIL > > MAIL> s/noedit > To: MX%"SYSTEM@TUCSON.INTER-TEL.COM" > %MAIL-E-ERRACTRNS, error activating transport MX > %LIB-E-ACTIMAGE, error activating image DUA1:[MX.][EXE]MX_MAILSHRP.EXE > -SYSTEM-F-NOSHRIMG, privileged shareable image cannot have outbound calls > > I thought we must have had something INSTALLed that shouldn't be, but a reboot > and re-installation did not clear up the problem. > > Any clues? What other information can I get? Get version MX 3.0A as it takes care of your problem. There is a lnk$library defined on your system which gets linked in but should not. From Matt's announcement: 6. The LINK commands in the installation kit were being affected by LNK$LIBRARY logical names defined on some systems, causing some of the MX executables (noticeably, MX_MAILSHRP) to be linked incorrectly. All LINK commands in the installation kit have had the /NOUSERLIBRARY qualifier added to eliminate this problem. You can also get around this problem by deassigning lnk$library before installing MX. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Fri, 24 Jan 1992 12:07:15 EST Sender: Date: Fri, 24 Jan 1992 10:02:59 MST From: "Russ Wilton, Systems Manager" Reply-To: "Russ Wilton, Systems Manager" To: mx-list@vms.ecs.rpi.edu CC: wilton@hg.uleth.ca Message-ID: <009551BC.8E3F43A0.11825@hg.uleth.ca> Subject: Mail looping AGAIN Hi: I hate to keep complaining about this, but I just finished cleaning up another mail looping mess. This one was a little more serious than just having my local machine continuously forwarding mail to itself. In this case the mail message originated locally. It was addressed to a user at another site, with a copy to the sender. It appears that the copy to the sender got into a loop with the local machine forwarding it to itself, although I couldn't see anything wrong with the address. The big problem though, is that every time through the loop, it sent a copy to the remote address. Over the course of a day and a half, it sent out 1791 copies of the message with each copy being 102 bytes longer than the last one. I think it totalled about 165 Megabytes. I'm just waiting for the postmaster at the remote site to start sending me nasty messages. :-( I'm running VMS 5.4-1 and MX 3.0A. Has anybody else seen this type of behaviour? I don't know if my analysis of the problem is correct or not, as I have been unable to replicate it. But I do know I dumped a heck of a lot of data in some poor unsuspecting person's mail box. Could we give loop checking a HIGH priority for getting fixed soon? Thanks. Russ. #===============================================================# # Russell D Wilton E Mail: WILTON@HG.ULeth.CA # # Systems and Comm Manager Voice: (403) 329-2525 # # Computing Services FAX: (403) 329-2022 # # University of Lethbridge # # 4401 University Drive Lethbridge, Alberta, CANADA T1K 3M4 # #===============================================================# ================================================================================ Archive-Date: Fri, 24 Jan 1992 12:30:46 EST Sender: Date: Fri, 24 Jan 1992 10:26:36 MST From: "Russ Wilton, Systems Manager" Reply-To: "Russ Wilton, Systems Manager" To: mx-list@vms.ecs.rpi.edu CC: wilton@hg.uleth.ca Message-ID: <009551BF.DA85E860.11981@hg.uleth.ca> Subject: MX 3.0A logical names Hi: I recently upgraded to MX 3.0A and I notice that Matt has changed the startup procedure such that a given cluster node will only have the logical names defined relating to a particular transport if it is running that transport software. Eg., node not running the SMTP software will not have MX_SMTP_DIR defined. I applaud Matt's efforts to reduce the clutter of logical names, but I think he may have gone a bit too far. When I'm sitting at my clustered workstation, which isn't running any of the transports, I need the logicals defined so I can poke around in the log and accounting files to see how the other nodes are running. And as our UK friend recently noted, you can't manage the mailing lists from a node which isn't running the MLF process, because the logical name isn't defined. I think a solution to the problem is to have the `directory' logicals all defined in MX_LOGICALS.DAT, so that all nodes will have the logicals for all transports running anywhere in the cluster. Comments? Russ. #===============================================================# # Russell D Wilton E Mail: WILTON@HG.ULeth.CA # # Systems and Comm Manager Voice: (403) 329-2525 # # Computing Services FAX: (403) 329-2022 # # University of Lethbridge # # 4401 University Drive Lethbridge, Alberta, CANADA T1K 3M4 # #===============================================================# ================================================================================ Archive-Date: Fri, 24 Jan 1992 13:30:50 EST Sender: Date: Fri, 24 Jan 1992 13:28:57 EST From: Matt Madison Reply-To: madison@vms.ecs.rpi.edu To: mx-list@vms.ecs.rpi.edu Message-ID: <009551D9.53393960.12083@mdmvs.ecs.rpi.edu> Subject: Quick update on things First, apologies to anyone who has tried to get a hold of me over the last couple of weeks. I picked up some additional responsibilities at work here this month and my schedule has been rather hectic and with rather odd hours lately. I'm pretty much caught up on my back e-mail now, so if you've been expecting a reply from me on something and you haven't heard anything yet, you might try me again. Second, I've updated the [ANONYMOUS.MX.CONTRIB] area on vms.ecs.rpi.edu (and vms2, too) with Earle Ake's new MAIL_NEWS stuff and Jim Gaynor's new ALL-IN-1 stuff. The new files are MAIL_NEWS_MX30.VMS_SHARE and ALL-IN-1_TO_MX_3.TXT, respectively. I've updated the MX_CONTRIB package on FileServ@vms.ecs.rpi.edu, too -- the new files in the package are MX_CONTRIB.ALL-IN-1_TO_MX and MX_CONTRIB.MAIL_NEWS_MX30. Third, to address some of the bugs pointed out recently, I'm starting work on MX V3.0B. Bugs to be fixed include: - a bug in the MX_MAILSHR/MX_MAILSHRP stuff that limits you to 31 messages being sent via MX in a single MAIL session (or program using callable MAIL) - the over-zealous-removal-of-logicals problem - a possible bug in the SMTP outbound stuff - some folks are seeing MX_SMTP die with ACCVIO's from time to time and I'm not quite sure why yet. If you're seeing this problem, please let me know (and include any info about the problem if you can). That's it. Anyone interested in testing the V3.0B update before the general release should drop me a line. -Matt -- Matthew Madison, Systems Programmer | Internet: madison@vms.ecs.rpi.edu Engineering Computing Services | Bitnet: MADISON@RPIECSVX Rensselaer Polytechnic Institute | Troy, New York 12180-3590 USA | ================================================================================ Archive-Date: Fri, 24 Jan 1992 14:03:24 EST Date: Fri, 24 Jan 1992 13:57:59 EST From: Mighty Firebreather Reply-To: Mighty Firebreather To: wilton@hg.uleth.ca CC: mx-list@vms.ecs.rpi.edu Message-ID: <009551DD.61C4D6C0.20891@nscvax.princeton.edu> Subject: RE: MX 3.0A logical names Russ Wilton writes: > I recently upgraded to MX 3.0A and I notice that Matt has changed the >startup procedure such that a given cluster node will only have the logical >names defined relating to a particular transport if it is running that >transport software. Eg., node not running the SMTP software will not have >MX_SMTP_DIR defined. I applaud Matt's efforts to reduce the clutter of >logical names, but I think he may have gone a bit too far. When I'm >sitting at my clustered workstation, which isn't running any of the transports, >I need the logicals defined so I can poke around in the log and accounting >files to see how the other nodes are running. And as our UK friend recently >noted, you can't manage the mailing lists from a node which isn't running >the MLF process, because the logical name isn't defined. > I think a solution to the problem is to have the `directory' logicals >all defined in MX_LOGICALS.DAT, so that all nodes will have the logicals >for all transports running anywhere in the cluster. Comments? > If you mean that there should be a command file that defines all the logical names and that will be optionally executed by the system manager or SYSTARTUP_V5.COM, I agree. MX_LOGICALS.DAT does not sound like such a command file. I'm all in favor of anything that eliminates logicals, directories, log files, etc. that apply to components that I am not running. MX is already a large package and anything that increases modularity should be encouraged. ************************************************************************* * * * Here, there be dragons! * * dragon@nscvax.princeton.edu * * * * Richard B. Gilbert * ************************************************************************* ================================================================================ Archive-Date: Fri, 24 Jan 1992 15:13:20 EST Date: Fri, 24 Jan 1992 12:09:54 PST From: "W. Todd Wipke" Reply-To: "W. Todd Wipke" To: mx-list@vms.ecs.rpi.edu Message-ID: <009551CE.49228680.26479@SECS.UCSC.EDU> Subject: LAVC - BULLETIN - MULTINET problem I am running a LAVC under VMS 5.3-1 with MX and BULLETIN. The LAVC is homogeneous and all outgoing mail appears to come from SECS.UCSC.EDU. MX handles that just fine and SECS runs all the 6 MX processes and the BULLCP process of BULLETIN. The problem arises when another node in the LAVC posts a message with BULLETIN which puts that nodename in the "from" field. Anyone answering the msg sends mail to that satellite node which REFUSES the mail. Since all satellites run MULTINET, I would think an incoming msg would fire up the smtp server and queue the msg for local delivery and MX would then look at the satellite address and decide it is local to SECS and it would get delivered on the root node by the local delivery agent. Is there something I must change in multinet, or must I run one of the smtp server processes on each satellite node?? [I don't want to alter BULLETIN, since if someone directly mails to a satellite we still have the same problem.] wipke@secs.ucsc.edu ================================================================================ Archive-Date: Fri, 24 Jan 1992 15:26:03 EST Date: Fri, 24 Jan 1992 12:20:14 EST From: wells@pvii.ethel.cray.com Reply-To: wells%pvii@ethel.cray.com To: MX-List@vms.ecs.rpi.edu CC: wells%pvii@ethel.cray.com, t1555@icm.cray.com Message-ID: <009551cf.b9bc6720.50%pvii@ethel.cray.com> Subject: REVIEW REVIEW ================================================================================ Archive-Date: Fri, 24 Jan 1992 17:06:28 EST Sender: Date: Fri, 24 Jan 1992 15:02:03 MST From: "Russ Wilton, Systems Manager" Reply-To: "Russ Wilton, Systems Manager" To: mx-list@vms.ecs.rpi.edu CC: wilton@hg.uleth.ca Message-ID: <009551E6.55A51D60.12764@hg.uleth.ca> Subject: Mailing lists Hi: I recently upgraded to MX V3.0A and I am wondering how to convert my existing mailing lists to the new format. That is, how do I convert my MX_ROOT:[LOCAL.MLIST]xxx.MLIST files into MX_ROOT:[MLF.MAILING_LISTS]xxx.MAILING_LIST files. The system seems to work with the files in the old format, but I assume I should convert them at some point. I can't seem to find anything pertinent in the documentation. Any help greatly appreciated. Thanks Russ. #===============================================================# # Russell D Wilton E Mail: WILTON@HG.ULeth.CA # # Systems and Comm Manager Voice: (403) 329-2525 # # Computing Services FAX: (403) 329-2022 # # University of Lethbridge # # 4401 University Drive Lethbridge, Alberta, CANADA T1K 3M4 # #===============================================================# ================================================================================ Archive-Date: Fri, 24 Jan 1992 18:19:25 EST Sender: Date: Fri, 24 Jan 1992 17:09:18 CST From: "George D. Greenwade" Reply-To: "George D. Greenwade" To: wilton@hg.uleth.ca CC: mx-list@vms.ecs.rpi.edu Message-ID: <009551F8.1CA4F640.24622@SHSU.edu> Subject: RE: Mailing lists In <009551E6.55A51D60.12764@hg.uleth.ca> (Fri, 24 Jan 1992 15:02:03 MST), "Russ Wilton, Systems Manager" posted: > I recently upgraded to MX V3.0A and I am wondering how to convert my > existing mailing lists to the new format. That is, how do I convert my > MX_ROOT:[LOCAL.MLIST]xxx.MLIST files into > MX_ROOT:[MLF.MAILING_LISTS]xxx.MAILING_LIST files. The system seems to > work with the files in the old format, but I assume I should convert them > at some point. I can't seem to find anything pertinent in the > documentation. Any help greatly appreciated. Thanks The file will automatically convert on its first subscriber transaction. If you *really* want to go to the new format, include the commands: ADD/NONOTIFY JOE@BUGUS REMOVE/NONOTIFY JOE@BOGUS in the body of a mail message to the -Request address and MX will take care of the rest. If there is no subscriber transaction, the old file will continue to work fine. 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: Sun, 26 Jan 1992 07:29:33 EST To: mx-list@vms.ecs.rpi.edu Date: 26 Jan 92 10:05:29 GMT From: robin@lsl.co.uk (Robin Fairbairns) Reply-To: robin@lsl.co.uk (Robin Fairbairns) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan26.100529.1185@lsl.co.uk> References: <00954EC9FFC3C1E0.202002A3@dragon.com>, <1992Jan20.192643.1991@dayton.saic.com> Subject: Re: Problem with UUCP Interface on MX 3.0 In article <1992Jan20.192643.1991@dayton.saic.com>, ake@dayton.saic.com (Earle Ake) writes: > In article <00954EC9FFC3C1E0.202002A3@dragon.com>, cts@dragon.COM writes: >> There seems to be a problem with MX 3.0 rev A with the UUCP interface. >> The UUCP From header contains a leading "!" in the path. This has >> been giving several mailers my machine talks to fits, as well as >> generating bad return paths. >> >> [...] > > The problem actually is in DECUS UUCP and not MX. MX only brought > about the problem. The fix is to upgrade your uucp_mailshr image. What > version of uucp are you now running? I can send you uucp 1.3-2 which will > fix the problem. I recognise that the world at large (and I in particular) should be grateful to Earl for his continuing support of us all with this kind of offer. However, wouldn't a better course be for Matt to include a copy of the patched UUCP_MAILSHR in future distributions, and for now to stick a copy in the [.contrib] directory? What d'you think, Matt? -- Robin Fairbairns, Senior Consultant, postmaster and general dogsbody Laser-Scan Ltd., Science Park, Milton Rd., Cambridge CB4 4FY, UK Email: robin@lsl.co.uk --or-- rf@cl.cam.ac.uk ================================================================================ Archive-Date: Sun, 26 Jan 1992 18:03:51 EST From: Pedro Manuel Matias Reply-To: Pedro Manuel Matias To: mx-list@vms.ecs.rpi.edu Date: Sun, 26 Jan 92 14:16:16 GMT Subject: Not exactly MX business ... Message-ID: <0696435376@CTQB01.CTQB.PT> Hello, folks ! I'm a new addition to the MX-net and while I'm waiting for the fileserver to send me the latest version, I'd like to put forward a question that is not related to MX - Does anybody know of a package (excluding CMU TEK) that will enable a UNIX machine to print on a VMS print queue ? We have UCX v1.3 on our VAX. Pedro Matias. ------------------------------------- Phone : (351-1) 442-6246 Ext. 341 Fax : (351-1) 442-8766 email : matias@ctqb01.ctqb.pt !!!! New address !!!! Mailing address : Centro de Tecnologia Quimica e Biologica Rua da Quinta Grande 6 Apartado 127 2780 OEIRAS Portugal ================================================================================ Archive-Date: Mon, 27 Jan 1992 19:11:12 EST Date: Mon, 27 Jan 1992 16:04:23 PST From: wells@pvii.ethel.cray.com Reply-To: wells%pvii@ethel.cray.com To: MX-List@vms.ecs.rpi.edu CC: wells%pvii@ethel.cray.com Message-ID: <0095544a.899145c0.333%pvii@ethel.cray.com> Subject: SUBSCRIBE SUBSCRIBE ================================================================================ Archive-Date: Mon, 27 Jan 1992 19:51:32 EST Sender: Date: Tue, 28 Jan 1992 01:51:01 MET From: Eckart Meyer Reply-To: Eckart Meyer To: MX-LIST@VMS.ECS.RPI.EDU CC: meyer@ifn.ing.tu-bs.de Message-ID: <0095549C.7DE552A0.1184@ifn.ing.tu-bs.de> Subject: NAME_CONVERSION, 2 Question, 1 Suggestion I just tried out my own version of NAME_CONVERSION written in C. Two questions: 1. The example file stated, that the routines must be reentrant and therefor all data which are not local to a subroutine (those are on the stack in C and that is o.k.) must be pointed to by the context variable as shown in the example. Now: Why can't I use static variables? Those are in local, no-sharable program sections, so each process using the sharable image has it's own copy. Do the MX processes really call the sharable image from AST level, which seems to me the only need for reentrant code? I have used static variables and had no problems so far. I even used the RTL-routines malloc/free. 2. When MX_MAILSHR or the router ask for name translation to form the From: or Sender: or Return-Path: line, and the convert routine returns a string, the local node name is always appended! I would like to specify a complete RFC address here, because I try to use this feature to support domains connected by several mechanisms and they have their own domain names. Because they have MX-records in the nameservers, they would like to have the correct From: lines. Is there a possiblity to extend the interface (maybe use new codes 3,4,5... BTW: I got the MAIL_REWRITE.C from UUCP and modified it to be used with name_conversion. This module was originally from ANU-NEWS and it reads a file containing rewrite-rules - for the From: lines in this case. Eckart ----------------------------------------------------------------------------- Eckart Meyer Address: Schleinitzstr. 23 Inst. f. Nachrichtentechnik 3300 Braunschweig Technical University of Braunschweig Germany Phone: +49 531 391 2454 E-Mail: meyer@ifn.ing.tu-bs.de FAX: +49 531 391 5192 I7100501@DBSTU1.BITNET (not preferred) VMSmail: PSI%26245050351130::MEYER (DATEX-P) ----------------------------------------------------------------------------- ================================================================================ Archive-Date: Mon, 27 Jan 1992 19:57:09 EST Sender: Date: Tue, 28 Jan 1992 01:57:21 MET From: Eckart Meyer Reply-To: Eckart Meyer To: MX-LIST@VMS.ECS.RPI.EDU CC: meyer@ifn.ing.tu-bs.de Message-ID: <0095549D.606AD320.1186@ifn.ing.tu-bs.de> Subject: "PSISMTP" ? Another suggestion: We now have DNSMTP. Would it be too difficult to have a PSISMTP? Just replace the DECnet code by PSI code...? (No, I don't have a Bliss-Compiler). Just an idea (but a good one :-)) Eckart ----------------------------------------------------------------------------- Eckart Meyer Address: Schleinitzstr. 23 Inst. f. Nachrichtentechnik 3300 Braunschweig Technical University of Braunschweig Germany Phone: +49 531 391 2454 E-Mail: meyer@ifn.ing.tu-bs.de FAX: +49 531 391 5192 I7100501@DBSTU1.BITNET (not preferred) VMSmail: PSI%26245050351130::MEYER (DATEX-P) ----------------------------------------------------------------------------- ================================================================================ Archive-Date: Mon, 27 Jan 1992 20:08:50 EST Sender: Date: Tue, 28 Jan 1992 02:09:02 MET From: Eckart Meyer Reply-To: Eckart Meyer To: MX-LIST@VMS.ECS.RPI.EDU CC: meyer@ifn.ing.tu-bs.de Message-ID: <0095549F.01D41FE0.1188@ifn.ing.tu-bs.de> Subject: Rewriting and foreign Mail-interfaces Another suggestion: We now have DNSMTP. Would it be too difficult to have a PSISMTP? Just replace the DECnet code by PSI code...? (No, I don't have a Bliss-Compiler). Just an idea (but a good one :-)) Eckart ----------------------------------------------------------------------------- Eckart Meyer Address: Schleinitzstr. 23 Inst. f. Nachrichtentechnik 3300 Braunschweig Technical University of Braunschweig Germany Phone: +49 531 391 2454 E-Mail: meyer@ifn.ing.tu-bs.de FAX: +49 531 391 5192 I7100501@DBSTU1.BITNET (not preferred) VMSmail: PSI%26245050351130::MEYER (DATEX-P) ----------------------------------------------------------------------------- ================================================================================ Archive-Date: Tue, 28 Jan 1992 11:45:31 EST To: mx-list@vms.ecs.rpi.edu Date: 28 Jan 92 16:38:43 GMT From: madison@mdmvs.ecs.rpi.edu (Matt Madison) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: References: <0095549C.7DE552A0.1184@ifn.ing.tu-bs.de> Reply-To: madison@vms.ecs.rpi.edu Subject: Re: NAME_CONVERSION, 2 Question, 1 Suggestion In article <0095549C.7DE552A0.1184@ifn.ing.tu-bs.de>, meyer@ifn.ing.tu-bs.de (Eckart Meyer) writes: > I just tried out my own version of NAME_CONVERSION written in C. > Two questions: > > 1. The example file stated, that the routines must be reentrant > and therefor all data which are not local to a subroutine > (those are on the stack in C and that is o.k.) must be pointed > to by the context variable as shown in the example. Now: Why > can't I use static variables? Those are in local, no-sharable > program sections, so each process using the sharable image has > it's own copy. Do the MX processes really call the sharable > image from AST level, which seems to me the only need for > reentrant code? > > I have used static variables and had no problems so far. I > even used the RTL-routines malloc/free. The reason the code must be re-entrant is that there might be multiple invocations of it occurring simultaneously within a single process... for example, when using callable MAIL. > 2. When MX_MAILSHR or the router ask for name translation to form > the From: or Sender: or Return-Path: line, and the convert > routine returns a string, the local node name is always > appended! I would like to specify a complete RFC address here, > because I try to use this feature to support domains connected > by several mechanisms and they have their own domain names. > Because they have MX-records in the nameservers, they would > like to have the correct From: lines. > > Is there a possiblity to extend the interface (maybe use > new codes 3,4,5... It's already on my to-do list. -Matt -- Matthew Madison, Systems Programmer | Internet: madison@vms.ecs.rpi.edu Engineering Computing Services | Bitnet: MADISON@RPIECSVX Rensselaer Polytechnic Institute | Troy, New York 12180-3590 USA | ================================================================================ Archive-Date: Tue, 28 Jan 1992 12:26:14 EST Sender: Date: Tue, 28 Jan 1992 18:26:07 MET From: Eckart Meyer Reply-To: Eckart Meyer To: MX-LIST@VMS.ECS.RPI.EDU CC: meyer@ifn.ing.tu-bs.de Message-ID: <00955527.819E2BC0.1216@ifn.ing.tu-bs.de> Subject: Rewriting and foreign Mail-Interfaces Oops, I mixed up the two files... Here is the text for the subject: I would like to have the following rewrite-rules: <{user}@{node}.{dte}.mydom> -> <@mydom:"PSI%{dte}::{node}::{user}"> and percent-hacking must be ON. The router should preserve the string when enclosed in quotation marks. For now I setup a path to SITE for those addresses, define a logical MX_DTE_{dte} = PSI%{dte}::, rewrite the address to MX_DTE_{dte}::{node}::{user} and feed it back to MX via MX_SITE_IN. Not elegant but works Eckart ----------------------------------------------------------------------------- Eckart Meyer Address: Schleinitzstr. 23 Inst. f. Nachrichtentechnik 3300 Braunschweig Technical University of Braunschweig Germany Phone: +49 531 391 2454 E-Mail: meyer@ifn.ing.tu-bs.de FAX: +49 531 391 5192 I7100501@DBSTU1.BITNET (not preferred) VMSmail: PSI%26245050351130::MEYER (DATEX-P) ----------------------------------------------------------------------------- ================================================================================ Archive-Date: Tue, 28 Jan 1992 12:52:38 EST Sender: Date: Tue, 28 Jan 1992 18:48:48 EST From: "Serge ALGAROTTI Groupe E.I.I" Reply-To: Serge.Algarotti@cemef.cma.fr To: MX-list@vms.ecs.rpi.edu CC: algarotti@TARZAN.CMA.FR Message-ID: <0095552A.ABE840C0.458@TARZAN.CMA.FR> Subject: MX with several boots nodes ? I installed MX (transport smtp with ucx) on a lavc on the first boot node and the satellites and it's work very well. But I dont understand exactly what i must do to access MX on the other boot node (second,third...) - must i do install the mx base software ? - must i do install the netlib software? ? - must i do install the tcp/ip package ? - must i do start one or more process ? - mx_startup.com doesnt work if MX is not installed - mx___startup.com ask for netlib_startup I must resolve this problem, because i want using MX from the all nodes of the cluster. Can you tell me what i must do exactly ? thank you very much for your help ------------------------------------------------------------------------------ Serge ALGAROTTI Ecole Des Mines/CEMEF fax : (33) 93 65 43 04 SOPHIA ANTIPOLIS phone : (33) 93 95 75 75 06560 VALBONNE FRANCE E-mail : Serge.Algarotti@cemef.cma.fr ------------------------------------------------------------------------------- ================================================================================ Archive-Date: Wed, 29 Jan 1992 19:51:54 EST Sender: Date: Wed, 29 Jan 1992 19:46:33 EST From: Mike Snavely Reply-To: Mike Snavely To: mx-list@vms.ecs.rpi.edu Message-ID: <009555FB.E7A091E0.394@netltm.ucls.ohiou.edu> Subject: MX delivery... does FIN in the FLQU display really mean FIN? Hello everyone, I have an interesting question concerning loacl delivery of incoming MX mail. This question arises from a current problem on another local system that has MX installed. The version of MX in use, I believe, is version 1.3. Sorry, but it's not my system. Here's the question. The system that I refer to is running All-In-1. All-In-1 users have their VMSmail forwarded to All-In-1 via Message Router's MRGATE. (i.e. user "JOE" has a VMSmail forwarding address of MRGATE::A1::JOE) Let's further assume, that Message Router's MGRATE dies and stops transferring mail from VMSmail to All-In-1. Obviously the mail then does not deliver from VMSmail to All-In-1. My question is what does MX do? If I look at FLQU, I see the mail message change to a status of "FIN". I guess that means that MX is finished with the delivery. Yet I look at the MX_LOCAL_LOG.LOG and see something like this: Processing queue entry number 2956 Checking local name: mrgate::a1::wemer LOCAL_USER: mrgate::a1::wemer looks like a DECnet address. This is a regular delivery. DELIVER: Using Info-Mac%sumex-aim.stanford.edu@OUACCVMB.ucls.ohiou.edu as VMS MAIL From address. DELIVER: Using "Info-Mac Digest V10 #23" as subject. DELIVER: Delivering to mrgate::a1::wemer (DECnet destination) DELIVER_FILE: Command: MAIL/PROTOCOL=MX_MAILSHR MX_ROOT:[LOCAL]LCL_B7A21B80_00955565_20200D80.TMP;1 mrgate::a1::wemer DELIVER_FILE: Subprocess says: MAIL/PROTOCOL=MX_MAILSHR MX_ROOT:[LOCAL]LCL_B7A21B80_00955565_20200D80.TMP;1 mrgate::a1::wemer DELIVER_FILE: Subprocess says: %MRGATE-E-MRFROMVMS, Error transferring message to Message Router DELIVER_FILE: Subprocess says: -SYSTEM-F-LINKEXIT, network partner exited DELIVER_FILE: Subprocess says: WRITE SYS$OUTPUT F$FAO("EXIT:!XL",F$INTEGER($STATUS)) DELIVER_FILE: Subprocess says: EXIT:00000001 DELIVER: Status=00000001 from DELIVER_FILE All done with this entry. which indicates a failure as opposed to a log file like this which indicates success: Processing queue entry number 3923 Checking local name: MACKLIN LOCAL_USER: Found fwdg address MRGATE::A1::MACKLIN (VMS) = "mrgate::a1::macklin"@OUVAXA.UCLS.OHIOU.EDU (MX) Forwarding to: "mrgate::a1::macklin"@OUVAXA.UCLS.OHIOU.EDU FORWARD_MESSAGE: Normal forward - including Resent hdrs. FORWARD_MESSAGE: Resent-From=MACKLIN (VMS), (MX) FORWARD_MESSAGE: Forwarding queue entry number=3925 FORWARD_MESSAGE: Forwarding to: "mrgate::a1::macklin"@OUVAXA.UCLS.OHIOU.EDU All done with this entry. The big questions is: What happens to the first file? Does it end up in never-never land. It looks to me like MX detects an error, but still concludes that the delivery was good enough to trash the file from its queue. Am I wrong? Thanks in advance. /Mike --------------------------------------------------------------- Mike Snavely, Wide Area Network Coordinator, Communication Network Services, Ohio University 021-I Scott Quad, Athens OH 45701 (614)593-1042 Internet: SNAVELY@OUVAXA.UCLS.OHIOU.EDU (preferred address) Bitnet: SNAVELY@OUACCVMB.BITNET --------------------------------------------------------------- ================================================================================ Archive-Date: Wed, 29 Jan 1992 21:08:57 EST Date: Wed, 29 Jan 92 17:54:16 -0800 Message-ID: <9201300154.AA15800@eagle.is.lmsc.lockheed.com> From: marshall@force.decnet.lockheed.com (Bob Marshall O/67-92 B/561 x65737) Reply-To: marshall@force.decnet.lockheed.com (Bob Marshall O/67-92 B/561 x65737) To: "MX-List@vms.ecs.rpi.edu"@eagle.decnet.lockheed.com Subject: Beginner's question I've just installed MX 2.3 (haven't gotten 3.0 yet) and it all works fine within my company's local campus. But I had trouble sending mail out through the CISCO router which gets me out onto the Internet (at least I can get out via ftp and telnet). I've since discovered that SMTP is apparently blocked at the router, based on the following decree in my company's security manual : "All Internet e-mail must be routed through the host eagle.is.lmsc.lockheed.com...etc, etc". In VMSMail, I can send Internet mail by specify and address such as EAGLE::"user@host". That works fine. What I *WANT* to be able to do is send to addresses like MX%"user@host". So, for SMTP (i.e., non-local) mail I have to force it through node EAGLE. But I'm having trouble figuring out where I am supposed to specify that in either the MX_STARTUP file or in the MX_CONFIG file. DEFAULT_SMTP_ROUTER doesn't sound like the right thing to use. Sorry for such a basic question; mailers are not my forte. Separate question : I'm trying to get MX 3.0A from vms.ecs.rpi.edu. I can ftp there, and I can log in via anonymous ftp, but as soon as I try to access the disk I get "closing data connection" and "device timeout" messages from the ftp server. I can successfully use ftp everywhere else around the world except at this one site. Any clues as to what may be going on here? Also, does anyone know the IP address for vms2.ecs.rpi.edu? My name resolver doesn't seem to able to resolve it. Bob Marshall marshall@force.ssd.lmsc.lockheed.com ================================================================================ Archive-Date: Wed, 29 Jan 1992 22:23:37 EST Date: Wed, 29 Jan 1992 19:19:59 EST From: Bob Marshall O/67-92 B/561 x65737 Reply-To: Bob Marshall O/67-92 B/561 x65737 To: MX-List@vms.ecs.rpi.edu Message-ID: <009555F8.314518B0.445@force.ssd.lmsc.lockheed.com> Subject: List REVIEW ================================================================================ Archive-Date: Thu, 30 Jan 1992 09:37:32 EST To: mx-list@vms.ecs.rpi.edu Date: 30 Jan 92 09:16:37 EST From: ake@dayton.saic.com (Earle Ake) Reply-To: ake@dayton.saic.com (Earle Ake) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan30.091638.2005@dayton.saic.com> References: <9201300154.AA15800@eagle.is.lmsc.lockheed.com> Subject: Re: Beginner's question In article <9201300154.AA15800@eagle.is.lmsc.lockheed.com>, marshall@force.decnet.lockheed.com (Bob Marshall O/67-92 B/561x65737) writes: > I've just installed MX 2.3 (haven't gotten 3.0 yet) and it all works > fine within my company's local campus. But I had trouble sending mail out > through the CISCO router which gets me out onto the Internet (at least > I can get out via ftp and telnet). I've since discovered that SMTP is > apparently blocked at the router, based on the following decree in > my company's security manual : "All Internet e-mail must be routed > through the host eagle.is.lmsc.lockheed.com...etc, etc". > > In VMSMail, I can send Internet mail by specify and address such > as EAGLE::"user@host". That works fine. What I *WANT* to be able to > do is send to addresses like MX%"user@host". So, for SMTP (i.e., > non-local) mail I have to force it through node EAGLE. But I'm having > trouble figuring out where I am supposed to specify that in either > the MX_STARTUP file or in the MX_CONFIG file. DEFAULT_SMTP_ROUTER > doesn't sound like the right thing to use. The default router is the thing to use in this case. Set it via MCP. The command would look like: MCP> set smtp/default="eagle.is.lmsc.lockheed.com" Make sure to save the configuration then issue a: $ MCP reset/all command to tell the processes to re-read the configuration. _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Thu, 30 Jan 1992 10:00:40 EST To: mx-list@vms.ecs.rpi.edu Date: 30 Jan 92 09:39:02 EST From: ake@dayton.saic.com (Earle Ake) Reply-To: ake@dayton.saic.com (Earle Ake) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan30.093902.2006@dayton.saic.com> References: <9201300154.AA15800@eagle.is.lmsc.lockheed.com>, <1992Jan30.091638.2005@dayton.saic.com> Subject: Re: Beginner's question In article <1992Jan30.091638.2005@dayton.saic.com>, ake@dayton.saic.com (Earle Ake) writes: > The default router is the thing to use in this case. Set it via MCP. > The command would look like: > > MCP> set smtp/default="eagle.is.lmsc.lockheed.com" > > Make sure to save the configuration then issue a: > > $ MCP reset/all > > command to tell the processes to re-read the configuration. A little correction on my part. This is for MX 3.0 and later. In earlier versions you define the logical name MX_SMTP_DEFAULT_ROUTER logical name. Define this either in the mx_startup.com or in systartup_v5.com just before starting MX. _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Thu, 30 Jan 1992 10:00:55 EST To: mx-list@vms.ecs.rpi.edu Date: 30 Jan 92 09:42:17 EST From: ake@dayton.saic.com (Earle Ake) Reply-To: ake@dayton.saic.com (Earle Ake) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Jan30.094217.2007@dayton.saic.com> References: <009555FB.E7A091E0.394@netltm.ucls.ohiou.edu> Subject: Re: MX delivery... does FIN in the FLQU display really mean FIN? In article <009555FB.E7A091E0.394@netltm.ucls.ohiou.edu>, snavely@netltm.ucls.ohiou.edu (Mike Snavely) writes: > Hello everyone, > > I have an interesting question concerning loacl delivery of incoming MX > mail. This question arises from a current problem on another local system > that has MX installed. The version of MX in use, I believe, is version > 1.3. Sorry, but it's not my system. > Processing queue entry number 2956 > Checking local name: mrgate::a1::wemer > LOCAL_USER: mrgate::a1::wemer looks like a DECnet address. > This is a regular delivery. > DELIVER: Using Info-Mac%sumex-aim.stanford.edu@OUACCVMB.ucls.ohiou.edu as VMS MAIL From address. > DELIVER: Using "Info-Mac Digest V10 #23" as subject. > DELIVER: Delivering to mrgate::a1::wemer (DECnet destination) > DELIVER_FILE: Command: MAIL/PROTOCOL=MX_MAILSHR MX_ROOT:[LOCAL]LCL_B7A21B80_00955565_20200D80.TMP;1 mrgate::a1::wemer > DELIVER_FILE: Subprocess says: MAIL/PROTOCOL=MX_MAILSHR MX_ROOT:[LOCAL]LCL_B7A21B80_00955565_20200D80.TMP;1 mrgate::a1::wemer > DELIVER_FILE: Subprocess says: %MRGATE-E-MRFROMVMS, Error transferring message to Message Router > DELIVER_FILE: Subprocess says: -SYSTEM-F-LINKEXIT, network partner exited > DELIVER_FILE: Subprocess says: WRITE SYS$OUTPUT F$FAO("EXIT:!XL",F$INTEGER($STATUS)) > DELIVER_FILE: Subprocess says: EXIT:00000001 > DELIVER: Status=00000001 from DELIVER_FILE > All done with this entry. > > > which indicates a failure as opposed to a log file like this which > indicates success: Yes, MX thinks this is a success since the exit code was 1. In a version of MX around 2.0 or later, this was reported and taken care of. Have the site having the problem ungrade to 3.0A and this will take care of it. > The big questions is: What happens to the first file? Does it end up in > never-never land. It looks to me like MX detects an error, but still > concludes that the delivery was good enough to trash the file from its > queue. Am I wrong? MX thinks the delivery was a success so it is done with it. Again, get the current version and this will take care of it. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Thu, 30 Jan 1992 17:55:06 EST Sender: Date: Thu, 30 Jan 1992 14:48:49 PST From: Carl J Lydick Reply-To: Carl J Lydick To: ake@dayton.saic.com CC: mx-list@vms.ecs.rpi.edu Message-ID: <0095569B.7A05AE40.21497@SOL1.GPS.CALTECH.EDU> Subject: Re: MX delivery... does FIN in the FLQU display really mean FIN? > MX thinks the delivery was a success so it is done with it. Again, >get the current version and this will take care of it. And don't forget to complain to whoever provided MRGATE about the bogus success status. ================================================================================ Archive-Date: Fri, 31 Jan 1992 10:21:22 EST Sender: Date: Fri, 31 Jan 1992 10:17:26 EST From: John Hasstedt Reply-To: John Hasstedt To: mx-list@vms.ecs.rpi.edu Message-ID: <0095573E.BAE8DE20.1617@sbnuc1.phy.sunysb.edu> Subject: Questions about mx I am running VMS V5.4, MX V3.0, JNET V3.5, and MULTINET V3.0. I have two questions about MX: 1. The following was sent to the NODMGT list: > Notes of the Pre-DECUS BITNET Technical Meeting > Held December 7, 1991, in Anaheim, CA US (much deleted) >Use of MAILER, rather than >SMTPUSER or other names, for the ID of the mail delivery agent (PMDF or >MX), was recommended. When I installed MX, I used MXMAILER for the username of the mail delivery agent. Since the recommendation is to use MAILER, I was wondering if it is possible to easily change this. Can I make MX recognize both MXMAILER and MAILER as the mailer account? If so, I could update my node entry to use the new mailer name, but still process mail from machines using the old information. 2. When I installed JNET many years ago, the installation procedure created the POSTMASTER account. I set it to forward to my account and have never used it. I was wondering if there is any need to keep it. Is there any advantage to having the account instead of setting up a postmaster alias in MX? ========================================================================== John Hasstedt BITNET: MANAGER@SUNYSBNP Physics Department Internet: John.Hasstedt@sunysb.edu State University of New York HEPNET: SBNUC::MANAGER or 44145::MANAGER Stony Brook, NY 11794-3800 Phone: 516-632-8154 FAX: 516-632-8573 ================================================================================ Archive-Date: Fri, 31 Jan 1992 14:37:35 EST To: mx-list@vms.ecs.rpi.edu Date: 31 Jan 92 19:33:50 GMT From: madison@mdmvs.ecs.rpi.edu (Matt Madison) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <55!s0dk@rpi.edu> References: <0095573E.BAE8DE20.1617@sbnuc1.phy.sunysb.edu> Reply-To: madison@vms.ecs.rpi.edu Subject: Re: Questions about mx In article <0095573E.BAE8DE20.1617@sbnuc1.phy.sunysb.edu>, manager@sbnuc1.phy.sunysb.edu (John Hasstedt) writes: >(much deleted) >>Use of MAILER, rather than >>SMTPUSER or other names, for the ID of the mail delivery agent (PMDF or >>MX), was recommended. > >When I installed MX, I used MXMAILER for the username of the mail delivery >agent. Since the recommendation is to use MAILER, I was wondering if it is >possible to easily change this. Can I make MX recognize both MXMAILER and >MAILER as the mailer account? If so, I could update my node entry to use the >new mailer name, but still process mail from machines using the old >information. No, there is no easy way to do this. With some minor modifications to the code, though, I could make it easier. I'll see what I can do. >2. When I installed JNET many years ago, the installation procedure created the >POSTMASTER account. I set it to forward to my account and have never used it. >I was wondering if there is any need to keep it. Is there any advantage to >having the account instead of setting up a postmaster alias in MX? There is if someone does a SEND/FILE to you instead of sending you mail (or sends you what s/he thinks is mail but MX doesn't... i.e., not class M, not a filetype of NOTE or MAIL, etc.). Plus Jnet, I believe, takes files that come in with an invalid destination username and puts them in JAN_RECEIVE area for user POSTMASTER. I'm not sure what it would do if an actual userid POSTMASTER didn't exist. -Matt -- Matthew Madison, Systems Programmer | Internet: madison@vms.ecs.rpi.edu Engineering Computing Services | Bitnet: MADISON@RPIECSVX Rensselaer Polytechnic Institute | Troy, New York 12180-3590 USA |