Archive-Date: Mon, 03 Feb 1992 15:56:09 EST Sender: Date: Mon, 03 Feb 1992 15:51:30 EST From: "Reuben D. Molloy" Reply-To: "Reuben D. Molloy" To: mx-list@vms.ecs.rpi.edu Message-ID: <009559C8.E593FCE0.5378@auvax1.adelphi.edu> Subject: translating .BITNET to @cunymv.cuny.edu Hi, I am running MX 3.0A under VMS 5.4-3. There seems to be a problem with the ".BITNET" at the end of Bitnet addresses not being translated into the name of the Bitnet/Internet gateway before leaving my system. I noticed in MX 2.3 that there where alot of rewrite rules that were no longer present with MX 3.0. I just thought they were handled differently with the new revision. I thought the following line in config.mcp would be sufficient in defining ".BITNET" to mean use cunymv.cuny.edu as the gateway. DEFINE PATH *.BITNET SMTP/ROUTE="cunyvm.cuny.edu" All mail messages sent with .BITNET on the end of the email address get bounded back to the sender with "unknown address". If I change the recipients address from "user@address.BITNET" to "user%address@cunyvm.cuny.edu" the mail is delivered with no problems. Could someone provide me with some insight as to what is going on here? If I need to provide more information I can. Thanks in advance. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Reuben D. Molloy | Internet Address: reuben@auvax1.adelphi.edu VAX/VMS System Manager | Telephone: (516)877-3341 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ================================================================================ Archive-Date: Tue, 04 Feb 1992 00:16:47 EST Return-Path: cts@dragon.COM Date: Tue, 4 Feb 92 00:01:53 EST Message-ID: <00955A0D67108BA0.202008B0@dragon.com> From: cts@dragon.COM Reply-To: cts@dragon.COM Subject: Inbound mail from UUCP To: mx-list@vms.ecs.rpi.edu I'm using Decus UUCP 1.3 as my primary mail transport to the rest of the world. Most messages arrive here with the from address in domain format; this generally works well. We get some kind of strange address re-writes on stuff that arrives in bang path format. For example, a file that is delivered with the from address of node!user ends up, after passing through MX, as user%node.UUCP@dragon.com (We're dragon.com) Which usually works... of course, what we'd really like to re-write the address as user@node or user@node.xxx.yyy The problem gets worse when a longer bang-path comes in. Note the following example I created. Note the first file is as delivered by UUCP, the second after being passed through MX. 1 -------------------------------------- From dragon.com!cts Mon Feb 3 22:22:55 1992 remote from emory Received: from dragon.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.3.2.19) via UUCP id AA07420 ; Mon, 3 Feb 92 22:22:54 -0500 Received: by dragon.com (DECUS UUCP ///1.3-2/2.5/); Mon, 3 Feb 92 22:19:05 EST Date: Mon, 3 Feb 92 22:19:05 EST Message-Id: <009559FF0A4F7600.20200827@dragon.com> From: emory!dragon.com!cts Subject: This is a test To: emory!dragon!cts X-Vms-Mail-To: UUCP%"emory!dragon!cts" 2 -------------------------------------- From: MX%"cts@dragon.com" 3-FEB-1992 23:46:53.45 To: CTS CC: Subj: This is a test Return-Path: Received: from emory by dragon.com (MX V3.0A) with UUCP; Mon, 03 Feb 1992 23:46:44 EST Received: from dragon.UUCP by emory.mathcs.emory.edu (5.65/Emory_mathcs.3.2.19) via UUCP id AA07420 ; Mon, 3 Feb 92 22:22:54 -0500 Received: by dragon.com (DECUS UUCP ///1.3-2/2.5/); Mon, 3 Feb 92 22:19:05 EST Date: Mon, 3 Feb 92 22:19:05 EST Message-ID: <009559FF0A4F7600.20200827@dragon.com> From: cts@dragon.com Subject: This is a test To: cts%dragon.UUCP%emory.UUCP@dragon.com X-Vms-Mail-To: UUCP%"emory!dragon!cts" ------------------ Any way to fix this? If I'm understanding re-write rules correctly, they only apply to outbound addresses, not stuff in the headers. Charles Smith cts@dragon.com ================================================================================ Archive-Date: Wed, 05 Feb 1992 09:11:13 EST Sender: Date: Wed, 05 Feb 1992 07:58:37 CST From: "George D. Greenwade" Reply-To: "George D. Greenwade" To: shiner@PYL.unibe.ch CC: mx-list@vms.ecs.rpi.edu Message-ID: <00955B19.2AB988C0.23737@SHSU.edu> Subject: RE: MX and X.400 This isn't precisely like my usual post to MX-List. On Wed, 5 Feb 1992 12:19:09 +0100, JOHN SHINER posted privately to me, as well as a few others: > Subject: MX and X.400 > > Dear colleague: > > We are running VAXen under VMS 5.4 and EAN X.400 software. We would like > to interface X.400 with VAX Mail using MX. Have you managed to do this? > If so, could you please send me information and corresponding files? > > Thank you in advance! > > JS Shiner, Physiologisches Institut, Buehlplatz 5, CH-3012 Bern, Switzerland > Phone: +41 / 31 / 65 87 22 (or 16 or 11) | FAX: +41 / 31 / 65 46 11 > E-mail: X-400: SHINER@PYL.UNIBE.CH | DECnet: PYLVC1::SHINER (48.500) My reasons for posting to MX-List in this reply are: (a) I have no experience in this; however, possibly someone on the list does; and (b) if someone does, I am sure Matt would be interested in placing it in the [MX.CONTRIB] directory on vms.ecs.rpi.edu (and possibly in future contrib releases of MX). If anyone can assist, please reply to John (and John, anything which gets misdirected to me I will make every effort to pass along). Regards and thanks, 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, 06 Feb 1992 05:29:27 EST Date: 6 Feb 92 0:10 +0100 From: Rok Vidmar Reply-To: Rok Vidmar To: Message-ID: <2035:rok.vidmar@uni-lj.ac.mail.yu> Subject: RE: MX and X.400 > (a) I have no experience in this; however, possibly someone on the list > does; and > (b) if someone does, I am sure Matt would be interested in placing it in > the [MX.CONTRIB] directory on vms.ecs.rpi.edu (and possibly in future > contrib releases of MX). I have done it, but I am not entirely happy with it. From EAN I am routing messages, whitch should go into VMSMail, to an ordinary EAN mailbox. Then I extract those messages to ASCII file and use DCL procedure to separate messages, convert addresses from RFC987 to RFC822 and feed the result to MX using SITE mechanism. The problem with this procedure is I loose envelope information! Large majority of messages have this information duplicated in headers, but not all of them. So the proper way to do it is to teach MX to speak T... (sorry, I forgot the name of the protocol and my papers are at work) and the only person to do it in my opinion is Matt. Matt? (I like the SMTP over PSI very much too, do you have PSI?) Regards, Rok Vidmar x.400: S=vidmar;G=rok;O=uni-lj;P=ac;A=mail;C=yu UCC, University of Ljubljana inet: rok.vidmar@uni-lj.ac.mail.yu Kardeljeva pl. 17 phone: +38 61 183579 61000 Ljubljana Slovenia ================================================================================ Archive-Date: Thu, 06 Feb 1992 21:54:39 EST To: mx-list@vms.ecs.rpi.edu Date: 6 Feb 92 11:02:50 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: <1992Feb6.110250.1225@lsl.co.uk> Subject: Multiple ROUTEs on site delivery We are running MX v3.0 (no patches) here under VMS V5.4-3. I have written a SITE delivery agent that (to some extent) forwards mail out using the UK academic community's Coloured Book (CBS) protocols. With the advent of V3.0, my site agent also processes a mail->news gateway. I use the /ROUTE= parameters in the configuration setup to distinguish the two uses of the site delivery agent. It works fine, singly (i.e., if a message is _just_ going to news, or _just_ going off-site via CBS. Observe, however, the following. `info' is our local general- information newsgroup; gaga50 a supported worker of ours at Glasgow University. For historical reasons, he qualifies to receive `info', but since he's off-site, he has to get it via mail. >Entry: 10704, Origin: [Local] > Status: IN-PROGRESS, size: 892 bytes > Created: 6-FEB-1992 00:02:10.68, expires 7-MAR-1992 00:02:10.68 > Last modified 6-FEB-1992 00:02:26.13 > SITE entry #10705, status: IN-PROGRESS, size: 892 bytes > Created: 6-FEB-1992 00:02:13.79, expires 7-MAR-1992 00:02:10.68 > Last modified 6-FEB-1992 00:02:25.09 > Recipient #1: , Route=NEWS > Recipient #2: , Route=CBS When there's one of these things in the queue, SITE doesn't process _anything_. The only way out that I've spotted is to shut down the SITE process and restart it. Am I doing something wrong, or is there a bug? Would either of the published patches help? HELP! - PLEASE!!!! -- 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, 10 Feb 1992 09:02:40 EST Sender: Date: Mon, 10 Feb 1992 09:01:21 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: <00955F0F.C2415F20.8100@uap.umd.edu> Subject: NEWSRDR dir listing Does anyone have a hack which would change the listing from the DIRECTORY command to show only the subject line, and more of it, rather than the sender's name plus a truncated subject line? Or, where in the source should I go to try to hack it myself? David Matthews ================================================================================ Archive-Date: Tue, 11 Feb 1992 15:38:43 EST To: mx-list@vms.ecs.rpi.edu Date: 11 Feb 92 16:40:48 GMT From: dmatthews@uap.umd.edu Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <11187@umd5.umd.edu> Reply-To: dmatthews@uap.umd.edu Subject: Looping I am posting the following for a friend. Please reply to him by email: Larry Bleau sysmgr@umaip.umd.edu Hi, folks. I also have a problem with MX mail looping. I'm running MX V2.1 with UCX V1.3. A normal-looking To: address is used, and for some reason UCX cannot return an IP number for the host. It gets rejected, and the next thing MX should do is bounce the message back to the sender. Instead, it proceeds to look up the _sending_ host's name and send the entire message back to it. Only the prefixes the host name (without any user name) to the source address: 29-JAN-1992 12:35 XMIT: PROTO=SMTP, SOURCE="", HOST="UMAIP.UMD.EDU", BYTES_SENT=358 29-JAN-1992 12:36 XMIT: PROTO=SMTP, SOURCE="<@umaip:dowling@UMAIP.UMD.EDU>", HOST="UMAIP.UMD.EDU", BYTES_SENT=435 29-JAN-1992 12:36 XMIT: PROTO=SMTP, SOURCE="<@umaip,@umaip:dowling@ UMAIP.UMD.EDU>", HOST="UMAIP.UMD.EDU", BYTES_SENT=512 When this queued entry gets run again, MX tries to send out to the original host, fails, etc. This thing is using 80% of my CPU, and I've no idea how to stop or prevent it, other than sitting there in FLQU and using alternate SHOW and CANCEL commands (it keeps getting requeued) or telling the user not to send his message. Other addresses seem to get mail okay. Can anyone be of assistance? I've enclosed extracts of the MX_SMTP_LOG.LOG file and the MX_SMTP_ACC.DAT file. Thanks in advance. Larry Bleau University of Maryland Physics Dept 301-405-6048 sysmgr@umaip.umd.edu P.S. I found out why MX couldn't find the IP number: the host name was mispelled and didn't exist! That's still no reason to go into an infinite loop, though. --------------------------------- Extract of file MX_SMTP_LOG.LOG : Processing queue entry number 5393 Recipient: Identified next hop as qa.nad.northrope.com SMTP_SEND: looking up host name qa.nad.northrope.com %MXLOOKUP, MX entry: VTVM1.CC.VT.EDU. expires 29-JAN-1992 16:30:01.88 %MXLOOKUP, MX entry: APL.WASHINGTON.EDU. expires 30-JAN-1992 12:01:43.07 %MXLOOKUP, MX entry: UMAIP.UMD.EDU. expires 29-JAN-1992 15:14:58.60 %MXLOOKUP, MX entry: UMAIL.UMD.EDU. expires 30-JAN-1992 05:04:23.05 MXLOOKUP: Asking nameserver ni.umd.edu about name QA.NAD.NORTHROPE.COM. MXLOOKUP: Trying 128.8.2.240... MXLOOKUP: Got 0 answers and 7 auths with authoritative = 0 MXLOOKUP: NS -> NS.NIC.DDN.MIL. MXLOOKUP: NS -> AOS.BRL.MIL. MXLOOKUP: NS -> KAVA.NISC.SRI.COM. MXLOOKUP: NS -> C.NYSER.NET. MXLOOKUP: NS -> TERP.UMD.EDU. MXLOOKUP: NS -> NS.NASA.GOV. MXLOOKUP: NS -> NIC.NORDU.NET. MXLOOKUP: Asking nameserver NS.NIC.DDN.MIL about name QA.NAD.NORTHROPE.COM. MXLOOKUP: Trying 192.112.36.4... MXLOOKUP: Name error with authoritative = 1 SMTP_SEND: Attempting to start session with qa.nad.northrope.com SMTP_SEND: Failed, sts=0C278032 SMTP_SEND: looking up host name UMAIP.UMD.EDU %MXLOOKUP, MX entry: VTVM1.CC.VT.EDU. expires 29-JAN-1992 16:30:01.88 %MXLOOKUP, MX entry: APL.WASHINGTON.EDU. expires 30-JAN-1992 12:01:43.07 %MXLOOKUP, MX entry: UMAIP.UMD.EDU. expires 29-JAN-1992 15:14:58.60 %MXLOOKUP, We have a match... %MXLOOKUP, umaip.UMD.EDU., pref=10 SMTP_SEND: Attempting to start session with umaip.UMD.EDU. SMTP_SEND: Connected SMTP_SEND: Rcvd: 220 umaip MX SMTP server ready at Wed, 29 Jan 1992 15:12:14 EST SMTP_SEND: Sent: HELO umaip SMTP_SEND: Rcvd: 250 Hello, umaip SMTP_SEND: Sent: MAIL FROM:<@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip, @umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip, @umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip, @umaip,@umaip,@umaip,@umaip,@umaip,@u SMTP_SEND: Rcvd: 250 MAIL command accepted. SMTP_SEND: Sent: RCPT TO: SMTP_SEND: Rcvd: 250 Recipient okay (at least in form) SMTP_SEND: Sent: DATA SMTP_SEND: Rcvd: 354 Start mail input; end with . ... SMTP_SEND: Sent: QUIT SMTP_SEND: Rcvd: 221 umaip Service closing transmission channel Recipient status=00000001 for Entry now completely processed, no retries needed. *** End of processing pass *** -------------------------------- Extract of MX_SMTP_ACC.DAT file: 29-JAN-1992 15:06 XMIT: PROTO=SMTP, SOURCE="<@umaip,@umaip,@umaip,@umaip, @umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip, @umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip, @umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@ 29-JAN-1992 15:11 XMIT: PROTO=SMTP, SOURCE="", HOST="umail.umd.edu", BYTES_SENT=662 29-JAN-1992 15:12 XMIT: PROTO=SMTP, SOURCE="<@umaip,@umaip,@umaip,@umaip, @umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip, @umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@umaip, @umaip,@umaip,@umaip,@umaip,@umaip,@umaip,@ -------------------------------- Dr. David L. Matthews, IPST, Univ. of Maryland, College Park MD 20742-2431 Internet: dmatthews@uap.umd.edu (301)405-4830 NSI/SPAN: UMDUAP::DMATTHEWS FAX (301)314-9363 ================================================================================ Archive-Date: Tue, 11 Feb 1992 16:37:16 EST To: mx-list@vms.ecs.rpi.edu Date: 11 Feb 92 20:42:32 GMT From: dmatthews@uap.umd.edu Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <11195@umd5.umd.edu> References: <11187@umd5.umd.edu> Reply-To: dmatthews@uap.umd.edu Subject: Re: Looping In article <11187@umd5.umd.edu>, dmatthews@uap.umd.edu writes: >I am posting the following for a friend. Please reply to him by email: > >Larry Bleau >sysmgr@umaip.umd.edu > >Hi, folks. I also have a problem with MX mail looping... So of course his MX mail isn't working, and any replies sent to him have probably bounced. Instead use bleau@delphi.umd.edu or if you're on NSI/DECNET 6604::SYSMGR OR POST AND I'LL FORWARD THE POSTINGS. Dr. David L. Matthews, IPST, Univ. of Maryland, College Park MD 20742-2431 Internet: dmatthews@uap.umd.edu (301)405-4830 NSI/SPAN: UMDUAP::DMATTHEWS FAX (301)314-9363 ================================================================================ Archive-Date: Wed, 12 Feb 1992 09:35:27 EST Sender: Date: Wed, 12 Feb 1992 09:35:16 EST From: Matt Madison Reply-To: madison@vms.ecs.rpi.edu To: mx-list@vms.ecs.rpi.edu Message-ID: <009560A6.D424B1E0.13256@mdmvs.ecs.rpi.edu> Subject: Message Router/MX problem Is there someone else running MR 3.2 with MX that might be able to lend some assistance? -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 | -begin forwarded message- From: b8tefeu@umsulx.minc.umd.edu (Fred Feurer) Message-ID: <9202111526.AA01486@umsulx.minc.umd.edu> To: madison@mdmvs.ecs.rpi.edu Subject: message router w/ MX Matt, Below is some information to a problem that I'm having with sending mail from Allin1 thru the Message Router VMSmail Gateway and MX. We just upgraded to Message Router 3.2 and I think it is causing ta problem with Return addresses. Replys use to work, but don't anymore. Would your suggestion be to use the SPECIAL.COM only? Stuff Follows: Matt, I have a question about MX. We're currently running V2.3 and will be installing V3.0-? in the near future. Background: We've installed a new version of Message Router (MR 3.2) to be exact and one of the users is still sending mail thru allin1 using the following: To: mx%"user@fully-qualified-host-name"@mrgate People can either send mail that way or by using the SPEICAL.COM file that is called with the following address: To: _user@fully-qualified-host-name My question is this: With the new version of MR, if a user sends mail thru the internet, it will get to the destination. But if someome replies, it get to the originating host and FLQU shows that the message is CANCELLED. The message will then return to the person that replied to the message will a Reomote Protocol Error. Could you look at the following? Thanks, Fred ---------------------------- Remote Protocol Problem ------------------- Original MEssage From ALLIN1 to Internet host: (Notice the cent sign in the top line) From "ums05::mrgate::"A1::B8TEFEU""@ums05.minc.umd.edu Tue Feb 11 08:55:24 1992 Received: by ums05.minc.umd.edu (MX V2.3-1) id 739; Tue, 11 Feb 1992 09:41:12 EST Date: Tue, 11 Feb 1992 09:41:12 EST From: "ums05::mrgate::\"A1::B8TEFEU\""@ums05.minc.umd.edu To: b8tefeu@umsulx.minc.umd.edu Message-Id: <00955FDE.7E1D0FE0.739@ums05.minc.umd.edu> Subject: test Status: RO From: NAME: Fred Feurer FUNC: Technical Services TEL: (301) 464-6165 To: mx%"b8tefeu@umsulx.minc.umd.edu"@mrgate test test After REply: From MAILER-DAEMON Tue Feb 11 09:48:16 1992 Date: Tue, 11 Feb 92 09:47:59 -0500 From: MAILER-DAEMON (Mail Delivery Subsystem) Subject: Returned mail: Remote protocol error To: b8tefeu Status: RO ----- Transcript of session follows ----- >>> RCPT To:<"ums05::mrgate::"A1::B8TEFEU""@ums05.minc.umd.edu> <<< 501 Syntax error in address 554 "ums05::mrgate::\"A1::B8TEFEU\""@ums05.minc.umd.edu... Remote protocol error ----- Unsent message follows ----- Received: by umsulx.minc.umd.edu (5.57/Ultrix3.0-C) id AA01387; Tue, 11 Feb 92 09:47:59 -0500 Date: Tue, 11 Feb 92 09:47:59 -0500 From: b8tefeu (Fred Feurer) To: "ums05::mrgate::\"A1::B8TEFEU\""@ums05.minc.umd.edu Subject: Re: test testing .. going back to you ================================================================================ Archive-Date: Wed, 12 Feb 1992 12:12:28 EST Sender: Date: Wed, 12 Feb 1992 12:12:33 EST From: Matt Madison Reply-To: madison@vms.ecs.rpi.edu To: mx-list@vms.ecs.rpi.edu Message-ID: <009560BC.CCDF6B80.13270@mdmvs.ecs.rpi.edu> Subject: New release of MX coming (soon?) I started working on the MX V3.0B minimal maintenance release when I discovered that one of the bug fixes I was making was going to involve changes to a bit more code than I originally thought. So, instead I'm working on V3.1, which will be a maintenance release with some additional functionality thrown in for good measure (though not too much). The bugs that will be fixed in V3.1 include: - occasional, mysterious, untraceable stopping of an MX process - over-zealous reduction of logical name definitions - MX_START's limitation on multiple instances of processes to Router and SMTP only - SITE interface hangs with multiple destination users (once I find that one) - MCP command definition mixup that prevents SHOW PATHS from working (but SHOW PATH does work) A new version of NETLIB will also be included which will have the following bug fixes: - Occasional ACCVIO's when using CMU-Tek TCP/IP - CMU-Tek's NET$_CREF (connection refused) not being translated to SS$_REJECT The new NETLIB (V1.5) is availble now in [ANONYMOUS.NETLIB] on vms.ecs.rpi.edu for those of you who would like to try it. It also includes, courtesy of Bernie Volz of Process Software Corp., support for their TCPware for VMS product as a TCP/IP transport. There is one more bug (extra work in the MXLOOK routine when NETLIB_DOMAIN is defined as "."), which I have yet to work on, so there will probably be an update to the V1.5 kit before too long. I think that covers all of the bugs reported since V3.0A was released. I will be reviewing my bugs file again, just to be sure, and if you know of a bug that I haven't mentioned here, please let me know. New features that will be included in V3.1: - startup and shutdown messages sent to OPCOM and logged in log files for each MX process - reasonably intelligent counting of Received: lines to detect mail looping problems - support for settable mailer userid for Jnet interface use (so you don't have to create a special MAILER account for MX) and ability to recognize more than one mailer userid I will be reviewing my wish-list file to see what else I can fit in, without going overboard. As with bugs, if there's some wish-list item you feel is particularly important, please let me know. Anyone who would like to play guinea pig for the new release should also drop me a line. I hope to have something ready for testing by next week some time. -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: Wed, 12 Feb 1992 14:56:24 EST To: mx-list@vms.ecs.rpi.edu Date: Wed, 12 Feb 1992 19:53:21 GMT From: gaynor@magnus.acs.ohio-state.edu (Jim Gaynor) Reply-To: gaynor@magnus.acs.ohio-state.edu (Jim Gaynor) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Feb12.195321.8362@magnus.acs.ohio-state.edu> References: <009560A6.D424B1E0.13256@mdmvs.ecs.rpi.edu> Subject: Re: Message Router/MX problem In article <009560A6.D424B1E0.13256@mdmvs.ecs.rpi.edu> madison@vms.ecs.rpi.edu writes: >Is there someone else running MR 3.2 with MX that might be able to >lend some assistance? > >[Problems using combo of MX, All-In-1, and Message Router deleted.] I think I might be able to shed some light on this. Over here we're running MX 3.0a, All-In-1 2.4 (with current patches), and Message Router 3.1b. We experience similar problems with users sending to Internet hosts from within All-In-1, and I don't really know of any solution that we can make (Matt might be able to do one). But I -can- explain what is happening. The problem is a combination of Message Router's behavior, and MX's behavior, and will occur whenever a user uses Message Router to send a message to another Internet host while in All-In-1. Here's some explanation. Joe the All-In-1 user sends email to Fred the VMSMail user on the same node (BIGVAX). The address Joe sends to (from within All-In-1) is FRED@MRGATE@BIGVAX. When Fred receives the message, the return address will be BIGVAX::MRGATE::"A1::JOE". Note the quotations. The reply that Fred sends will go to Message Router (MRGATE) on the node BIGVAX. There, the quotes will be stripped off, and Message Router will give the message to the All-In-1 Gateway (A1), which will give it to Joe in All-In-1. Now, what happens when Joe sends mail to an Internet user, say Sam? Joes sends his message to MX%"sam@stateu.edu"@MRGATE@BIGVAX. Do you see where this is going yet? Because Joe's return address on his own node is funky (BIGVAX::MRGATE::"A1::JOE"), the whole thing gets enclosed in quotes, and Joe's Internet hostname is appended on the end with a @ to create his Internet-style return address. So, we take BIGVAX::MRGATE::"A1::JOE", enclose it in quotes, and append @bigvax.edu to the end. Our result? "BIGVAX::MRGATE::"A1::JOE""@bigvax.edu Look at it. -We- know that it is supposed to mean (substititing parens for left/right quotes): (BIGVAX::MRGATE::(A1::JOE))@bigvax.edu But the nice machine doesn't know that - there's no left/right paren parsing. So the mailer thinks it's being given: (BIGVAX::MRGATE::)A1::JOE()@bigvax.edu And that's Bad Stuff. The mailer chokes on the funky A1::JOE, and address is unreplyable. It's the combination of Message Router's addition of quotes and MX's addition of quotes that kills it. IF YOU USE THE MODIFIED SPECIAL.COM: The modified special.com totally bypasses Message Router, and uses callable VMSMail. However, if Joe has his mail forwarded to his All-In-1 account, then the above-described problem will occur when Joe replies to a reply of a reply. Like so: 1) Joe sends from All-In-1 with special.com: _sam@stateu.edu 2) Sam's message gets a reply address of joe@bigvax.edu 3) Sam replies, message goes to Joe's VMSMail, goes through MRGATE to A1. 4) The reply address of this message is MX%"sam@stateu.edu"@MRGATE@BIGVAX Replying to that address is just like sending a new message using Message Router, and an unreplyable return address will be generated. WHAT CAN WE DO? Well, DEC sure isn't going to change Message Router. Go to them, and they'll advise purchasing a few products that will work with Message Router - some of which aren't out yet. Wollongong's package supposedly can get around the problem as well, although I don't know how (I've asked them to send me some lit) The only thing that I can think of is for Matt to make some kind of crufty hack that can have MX recognize those quotes and turn them into some other character - and undo the same thing when a message comes back. Whether than can be done and still have everything in accordance with relevant RFCs, I don't really know. Something that would work kind of like this: # Outgoing message look at local_sender_return_address if local_sender_return_address contains " then turn first " into ( turn second " into ) endif wrap local_sender_return_address in quotes append Internet_host_name to local_sender_return_address Send the message out on the Internet Processed, that would turn BIGVAX::MRGATE::"A1::JOE" into "BIGVAX::MRGATE::(A1::JOE)"@bigvax.edu # Incoming message extract recipient_local_address from recipient_internet_address remove external quotes from recipient_local_address look at recipient_local_address if recipient_local_address contains ( then convert to " if recipient_local_address contains ) then convert to " give the message to Local delivery And this would put it back together, turning "BIGVAX::MRGATE::(A1::JOE)"@bigvax.edu into BIGVAX::MRGATE::"A1::JOE" Of course, this is off the top of my head. But it just may work. Matt? Anyone? -- 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: Wed, 12 Feb 1992 18:33:02 EST To: mx-list@vms.ecs.rpi.edu Date: 12 Feb 92 18:14:42 GMT From: gjc@mitech.com (George J. Carrette) Reply-To: gjc@mitech.com (George J. Carrette) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <351@mitech.com> Subject: MX version availability/compatibility questions --- Cut to the chase: My problem is that I have a vaxstation-2000 running VMS 4.7 and an old version of CMU-TEK TCP-IP. Real old. V6.0 (1986). It is my nice old and reliable uucp access machine. Not much motivation to upgrade it to VMS 5.4 and Decwindows Motif. Why slow the thing down to a crawl? Q1: Does the current version of MX have any hope of running in that environment? Q2: Are there any old distributions of MX around which would? Note: I am willing to make modifications to C sources and recompile. ================================================================================ Archive-Date: Thu, 13 Feb 1992 16:09:34 EST Sender: Date: Thu, 13 Feb 1992 16:09:43 EST From: Matt Madison Reply-To: madison@vms.ecs.rpi.edu To: mx-list@vms.ecs.rpi.edu Message-ID: <009561A7.18F48B00.13363@mdmvs.ecs.rpi.edu> Subject: Updated NETLIB V1.5 kit now available I have placed an updated NETLIB V1.5 installation and source kit in directory [ANONYMOUS.NETLIB] on vms.ecs.rpi.edu and vms2.ecs.rpi.edu, which fixes a rather severe performance problem associated with the use of the NETLIB_DOMAIN logical name from previous versions. Anyone using MX V3.0 or V3.0A who is also using the NETLIB_DOMAIN logical to control name completion should probably get this update and install it. This change does not affect users of CMU-Tek TCP/IP V6.5 and later; however, there are a couple of CMU-Tek-related bug fixes in the V1.5 kit as well that would probably be worth pursuing. -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, 14 Feb 1992 07:29:37 EST To: mx-list@vms.ecs.rpi.edu Date: 13 Feb 92 16:02:46 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: <1992Feb13.160246.3457@inter-tel.com> Subject: Incorrect To: address We have a VAXcluster with one node running Multinet, and a Sun workstation mail server. We use MX to take care of routing all mail to the workstation through the Multinet node. All this works great. However, in some cases, we've see the "To:" field come out wrong. It's reproducible, but I haven't been able to narrow it down to a simple case. The problem occurs when a VAX users sends mail to a large distribution list specified in a file. (In our case, the file contains references to other subordinate distribution lists, but I'm not sure that's relevant). The VAX users that have their mail forwarded to their workstations receive the message OK, but the "To:" field contains the last line from the distribution list. When I tried to reduce this to a simpler case, it seemed to work OK. Is it possible that MX takes the last line in the case where the "To:" field would be too long, or could this be a bug? -- Tom Berk Inter-Tel, Inc. Chandler, AZ berk@inter-tel.com 602-961-9000 ================================================================================ Archive-Date: Fri, 14 Feb 1992 11:48:42 EST Sender: Date: Fri, 14 Feb 1992 11:43:18 EST From: "Steve Thompson, Cheme System Mangler" Reply-To: "Steve Thompson, Cheme System Mangler" To: mx-list@vms.ecs.rpi.edu Message-ID: <0095624B.0B93E9C0.20737@cheme.tn.cornell.edu> Subject: MX error codes? This morning I discovered a whole bunch of messages (over a hundred) apparently 'stuck' in the outgoing MX message queue. Some were notated as 'waiting until' a specific time, when in fact that time has passed many hours ago. Also, I have a collection of messages of the form: $RUN MX_EXE:MAILQUEUE Entry: 15054, Origin: [SMTP] Status: IN-PROGRESS SMTP entry #19221, status: READY Waiting for retry until: 14-FEB-1992 11:42:05.80 Recipient #1: , Route=DDD.cheme.CORNELL.EDU Error count=3 Last error: %NONAME-F-NOMSG, Message number 0C2680AC Can anyone tell me what the final message status means? I have searched through every message file that I can find, to no avail. Thanks. Steve ================================================================================ Archive-Date: Fri, 14 Feb 1992 16:11:11 EST To: mx-list@vms.ecs.rpi.edu Date: 14 Feb 92 20:48:41 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: <1992Feb14.154841.2034@dayton.saic.com> References: <0095624B.0B93E9C0.20737@cheme.tn.cornell.edu> Subject: Re: MX error codes? In article <0095624B.0B93E9C0.20737@cheme.tn.cornell.edu>, olin@cheme.tn.cornell.edu (Steve Thompson, Cheme System Mangler) writes: > This morning I discovered a whole bunch of messages (over a hundred) > apparently 'stuck' in the outgoing MX message queue. Some were notated > as 'waiting until' a specific time, when in fact that time has passed > many hours ago. Also, I have a collection of messages of the form: I have noticed that if the system crashes during delivery of a message, it gets stuck in the queue. The system comes back up and the message is INP in both the router and delivery agent portions. Maybe Matt can fix this or put it into his 'todo' list? If an entry is 'INP' and has been for more than an hour, change the state to 'RDY'. Would this fix it Matt? You might want to verify that one of the delivery agents does not currently have this. If you put the current process ID into the queue file and then check to see if it exists, this would tell if the process died or the system rebooted. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake ================================================================================ Archive-Date: Fri, 14 Feb 1992 16:39:55 EST Sender: Date: Fri, 14 Feb 1992 16:34:17 EST From: "Steve Thompson, Cheme System Mangler" Reply-To: "Steve Thompson, Cheme System Mangler" To: mx-list@vms.ecs.rpi.edu Message-ID: <00956273.B1FD0D00.20935@cheme.tn.cornell.edu> Subject: Re: Re: MX error codes? From Earle Ake (ake@dayton.saic.com): >In article <0095624B.0B93E9C0.20737@cheme.tn.cornell.edu>, olin@cheme.tn.cornell.edu (Steve Thompson, Cheme System Mangler) writes: >> This morning I discovered a whole bunch of messages (over a hundred) >> apparently 'stuck' in the outgoing MX message queue. Some were notated >> as 'waiting until' a specific time, when in fact that time has passed >> many hours ago. Also, I have a collection of messages of the form: > > I have noticed that if the system crashes during delivery of a message, >it gets stuck in the queue. The system comes back up and the message is INP >in both the router and delivery agent portions. Maybe Matt can fix this or >put it into his 'todo' list? If an entry is 'INP' and has been for more than >an hour, change the state to 'RDY'. Would this fix it Matt? You might want >to verify that one of the delivery agents does not currently have this. If >you put the current process ID into the queue file and then check to see if it >exists, this would tell if the process died or the system rebooted. This is interesting. I have noticed that messages get stuck in this state even if the system hasn't crashed recently. Usually, a 'QUEUE READY n' in MCP gets it going again. It doesn't happen very often (say once or twice a week out of a mail volume of about 250-300 messages a day), and I can't put my finger on anything unusual going on at the time (apart from the normal activities of my users :-)). I have speculated before that there may be subtle race condition at work here, as I have several nodes all attemtping delivery from a common database, and if I restrict delivery agents to a single node I don't see the problem (but then it's hard to get it to happen anyway). I'd like to thank Matt for his *very* fast reply to my earlier message, and to give him my thanks and congratulations for a great piece of software. I have more than one piece of his software, and it is in general a great deal more robust than most of the other software that I have that I *paid* for! Steve ================================================================================ Archive-Date: Sat, 15 Feb 1992 08:59:39 EST Sender: Date: Fri, 14 Feb 1992 16:34:17 EST From: "Steve Thompson, Cheme System Mangler" Reply-To: "Steve Thompson, Cheme System Mangler" To: mx-list@vms.ecs.rpi.edu Message-ID: <00956273.B1FD0D00.20935@cheme.tn.cornell.edu> Subject: Re: Re: MX error codes? From Earle Ake (ake@dayton.saic.com): >In article <0095624B.0B93E9C0.20737@cheme.tn.cornell.edu>, olin@cheme.tn.cornell.edu (Steve Thompson, Cheme System Mangler) writes: >> This morning I discovered a whole bunch of messages (over a hundred) >> apparently 'stuck' in the outgoing MX message queue. Some were notated >> as 'waiting until' a specific time, when in fact that time has passed >> many hours ago. Also, I have a collection of messages of the form: > > I have noticed that if the system crashes during delivery of a message, >it gets stuck in the queue. The system comes back up and the message is INP >in both the router and delivery agent portions. Maybe Matt can fix this or >put it into his 'todo' list? If an entry is 'INP' and has been for more than >an hour, change the state to 'RDY'. Would this fix it Matt? You might want >to verify that one of the delivery agents does not currently have this. If >you put the current process ID into the queue file and then check to see if it >exists, this would tell if the process died or the system rebooted. This is interesting. I have noticed that messages get stuck in this state even if the system hasn't crashed recently. Usually, a 'QUEUE READY n' in MCP gets it going again. It doesn't happen very often (say once or twice a week out of a mail volume of about 250-300 messages a day), and I can't put my finger on anything unusual going on at the time (apart from the normal activities of my users :-)). I have speculated before that there may be subtle race condition at work here, as I have several nodes all attemtping delivery from a common database, and if I restrict delivery agents to a single node I don't see the problem (but then it's hard to get it to happen anyway). I'd like to thank Matt for his *very* fast reply to my earlier message, and to give him my thanks and congratulations for a great piece of software. I have more than one piece of his software, and it is in general a great deal more robust than most of the other software that I have that I *paid* for! Steve ================================================================================ Archive-Date: Tue, 18 Feb 1992 13:11:54 EST Date: Tue, 18 Feb 1992 19:08:32 EST From: gege@cal.enst.fr (Why not ?) Reply-To: gege@cal.enst.fr (Why not ?) To: MX-List@vms.ecs.rpi.edu Message-ID: <009565ad.e87643a0.5007@cal.enst.fr> Subject: mx_mailshr Hello. I modified a version of MX_MAILSHR for MX 2.0, to allow the sending of smtp files by the callable VMSMAIL interface. The modified version merges 'user' headers and mx generated headers to build the outgoing message. This action is triggered by foreign type 1 messages, if LOG_IO is enabled, the latter to prevent malignous users to send forged smtp messages. I use it with an interface with anu-news. are you interested with that ? ================================================================================ ! Guillaume Gerard ! Bitnet GEGE@FRINT51 ! ! Systems responsible ! Email gerard@enst.fr ! ! French Telecom University ! X400 C=FR AD=ATLAS PD=TELECPARIS ! ! FAX: no access rights ! PSI *2080750412855::gerard ! ================================================================================ %SYSTEM-W-TMNYFNGRS, too many fingers on keyboard ================================================================================ Archive-Date: Tue, 18 Feb 1992 13:37:05 EST Sender: Date: Tue, 18 Feb 1992 12:35:32 CST From: hunterl@uwwvax.uww.edu Reply-To: hunterl@uwwvax.uww.edu To: mx-list@vms.ecs.rpi.edu Message-ID: <00956577.0155C6C0.25607@uwwvax.uww.edu> Subject: Error messages I am seeing repeated no-name or protocol error. The jobs remain in the queue and retry. Apparently they are being send since the far complains of multiple copies. Is this a known problem? Lyle Hunter Computer Center University Wisconsin-Whitewater hunterl@uwwvax.uww.edu ================================================================================ Archive-Date: Tue, 18 Feb 1992 13:55:05 EST To: mx-list@vms.ecs.rpi.edu Date: 18 Feb 92 10:53:13 CST From: brodie@fps.mcw.edu Reply-To: brodie@fps.mcw.edu Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Feb18.105313.528@fps.mcw.edu> References: <009561A7.18F48B00.13363@mdmvs.ecs.rpi.edu> Subject: Re: Updated NETLIB V1.5 kit now available In article <009561A7.18F48B00.13363@mdmvs.ecs.rpi.edu>, madison@mdmvs.ecs.rpi.edu (Matt Madison) writes: > I have placed an updated NETLIB V1.5 installation and source kit in directory > [ANONYMOUS.NETLIB] on vms.ecs.rpi.edu and vms2.ecs.rpi.edu, which fixes a > rather severe performance problem associated with the use of the NETLIB_DOMAIN > logical name from previous versions. Anyone using MX V3.0 or V3.0A who is > also using the NETLIB_DOMAIN logical to control name completion should probably > get this update and install it. Well, I upgraded to MX 3.0, and domain name lookups are failing miserably. (outbound mail is almost useless.). I am quiote unclear as to the use of the NETLIB stuff. Do I need to startup NETLIB separately?? How/when is the NETLIB_DOMAIN stuff used? (wouldn't it just use the domain name servers specified in my UCX config??) -- Kent C. Brodie - Sr. Systems Manager InterNet: brodie@fps.mcw.edu Faculty Physicians & Surgeons uucpNet: fps.mcw.edu!brodie Medical College of Wisconsin MaBellNet: +1 414 266 5080 "Researchers have shown that people who drink four or more cups of coffee a day are 40% more prone to heart attacks.... I guess we all now know what happened to *MISTER* Olson...." -Jay Leno ================================================================================ Archive-Date: Tue, 18 Feb 1992 14:21:25 EST Return-Path: From: brenner@nova.tat.physik.uni-tuebingen.de (Martin Brenner) Reply-To: brenner@nova.tat.physik.uni-tuebingen.de (Martin Brenner) Message-ID: <9202181919.AA28492@nova.tat.physik.uni-tuebingen.de> Subject: Problem: Invalid From: Address To: MX-List@vms.ecs.rpi.edu Date: Tue, 18 Feb 92 20:19:46 MEZ I have problems with mails that bounce because the From: ADdress looks looks invalid for the SMTP-server. Is there a chance to change this, so that mails with invalid From-Header no longer generate the 501 error message? Of course, the From: address IS invalid, but the mail should be delivered anyway. Thanks, -Martin ----- Transcript of session follows ----- While talking to castor.tat.physik.uni-tuebingen.de: >>> MAIL From:<@ean-relay.ac.uk,@omega.qmw.ac.uk:mm@qmw.ac.uk@UK.AC> <<< 501 Invalid address: <@ean-relay.ac.uk,@omega.qmw.ac.uk:mm@qmw.ac.uk@UK.AC> 554 soffel@castor... Remote protocol error -- Martin Brenner, Institut f. Theoretische Astrophysik, Universitaet Tuebingen brenner@tat.physik.uni-tuebingen.de ================================================================================ Archive-Date: Tue, 18 Feb 1992 17:27:28 EST From: bleau@delphi.umd.edu (LAWRENCE R BLEAU) Reply-To: bleau@delphi.umd.edu (LAWRENCE R BLEAU) Message-ID: <9202182226.AA26750@delphi.umd.edu> Subject: MX hangs while sending To: mx-list@vms.ecs.rpi.edu Date: Tue, 18 Feb 92 17:26:50 EST Hi folks, I'm back. My last problem was looping in MX mail, which was solved (apparently) by upgrading to v3.0A. I thought all was right with the world, until just today. Now, when I try sending mail from VMS MAIL using MX%"user@host" syntax, VMS MAIL just sits there, not responding, never giving me the Subject: prompt. Does anyone have any idea what the ____ is going on? I'm running MX V3.0A, UCX V1.3, on VMS V5.3-1. Telnet and ftp work fine accessing other hosts, which means name resolution is okay. BTW, the command MCP QUEUE SHOW also hangs, so I can't get any info on what's happenning there. Included below is the output from an MCP SHOW ALL. The nodes in my cluster are umaip, local, image, khaos, and img. The log files in the various directories (MX_ROOT:[*]*.LOG) all look normal, with no entries for the past several days. -- Larry Bleau University of Maryland bleau@delphi.umd.edu 301-405-6048 Enclosure: UMAIP$ MCP MCP> SHOW ALL Configuration file: MX_ROOT:[000000]MX_CONFIG.MXCFG;5 MX version id is: MX V3.0A Domain-to-path mappings: Domain="umaip.umd.edu", Path=Local Domain="local.umd.edu", Path=Local Domain="image.umd.edu", Path=Local Domain="khaos.umd.edu", Path=Local Domain="img.umd.edu", Path=Local Domain="umaip.umd", Path=Local Domain="umaip", Path=Local Domain="local.umd", Path=Local Domain="local", Path=Local Domain="image.umd", Path=Local Domain="image", Path=Local Domain="khaos.umd", Path=Local Domain="khaos", Path=Local Domain="img.umd", Path=Local Domain="img", Path=Local Domain="[128.8.143.10]", Path=Local Domain="[128.8.143.25]", Path=Local Domain="[128.8.143.26]", Path=Local Domain="[128.8.143.52]", Path=Local Domain="[128.8.143.28]", Path=Local Domain="*.UUCP", Path=SMTP, Route="uunet.uu.net" Domain="*.BITNET", Path=Jnet Domain="*", Path=SMTP Aliases: LocalName="Postmaster", Address="postmaster@umaip.umd.edu" LocalName="POSTMAST", Address="postmaster@umaip.umd.edu" SMTP agent settings: Retry interval: 0 00:30:00.00 Maximum number of retries: 96 Number of DNS failure retries: 12 Accounting: disabled Default router: (none) LOCAL agent settings: DECnet delivery retry interval: 0 00:30:00.00 Maximum number of retries: 96 Accounting disabled. Top headers: FROM,SENDER,TO,RESENT_TO,CC,RESENT_CC,BCC,RESENT_BCC,MESSAGE_ID, RESENT_MESSAGE_ID,IN_REPLY_TO,REFERENCES,KEYWORDS,SUBJECT, ENCRYPTED,DATE,REPLY_TO,RECEIVED,RESENT_REPLY_TO,RESENT_FROM, RESENT_SENDER,RESENT_DATE,RETURN_PATH,OTHER Bottom headers: (none) ROUTER agent settings: Automatic percent-hack handling: enabled JNET agent settings: Automatic percent-hack handling: enabled BSMTP replies: disabled Accounting: disabled Lenient about gatewaying mail: yes DECnet_SMTP agent settings: Retry interval: 0 00:30:00.00 Maximum number of retries: 96 Accounting disabled. SITE agent settings: Retry interval: 0 00:30:00.00 Maximum number of retries: 96 MCP> EXIT ================================================================================ Archive-Date: Tue, 18 Feb 1992 17:35:03 EST Date: Tue, 18 Feb 92 16:50:04 -0500 From: bleau@delphi.umd.edu (LAWRENCE R BLEAU) Reply-To: bleau@delphi.umd.edu (LAWRENCE R BLEAU) Message-ID: <9202182150.AA26452@delphi.umd.edu> To: mx-list@vms.ecs.rpi.edu Subject: test ================================================================================ Archive-Date: Wed, 19 Feb 1992 11:41:46 EST Sender: Date: Wed, 19 Feb 1992 11:41:58 EST From: CHANT Reply-To: CHANT To: mx-list@vms.ecs.rpi.edu CC: chant@enp.umd.edu Message-ID: <00956638.AFE1CBA0.20082@enp.umd.edu> Subject: JNET not running ..... I am running MX 3.0 on a VAXcluster (vms 5.4) consisting of 4000 and 3900 dual host servers with various VAXstation clients. We have SMTP_SERVERS on all nodes and JNET 3.5 on the 3900. Both servers run the ROUTER, SMTP and LOCAL processes. Occasionally the MX_JNET.EXE sends the message " Jnet was stopped" (see below) However, on logging on to the 3900 server running JNET, I can send mail using the JNET% protocol. Rebooting the 3900 usually restores JNET capbilities to MX. Unfortunately, I don't (yet) have appropriate log files. In the interim, can someone tell me what triggers the "Jnet was stopped" message from Postmaster and/or advise on what to look for? Thanks, Nick Chant ====================================================================== From: MX%"Postmaster@enp.umd.edu" 18-FEB-1992 14:22:26.47 To: BREUER CC: Subj: JNET delivery error Return-Path: <> Date: Tue, 18 Feb 1992 14:16:40 EST From: Postmaster@enp.umd.edu (JNET delivery agent) To: Subject: JNET delivery error Note: this message was generated automatically. A problem occurred during JNET delivery of your message. Error(s) occurred when sending to the following user(s): : Jnet was stopped Message follows. Received: by enp.umd.edu (MX V3.0) id 19920; Tue, 18 Feb 1992 14:16:08 EST Sender: Date: Tue, 18 Feb 1992 14:16:06 EST From: breuer@enp.umd.edu To: bauer@hutruu51.bitnet CC: breuer@enp.umd.edu Message-ID: <00956585.0DF67880.19920@enp.umd.edu> Subject: your visit Hallo Thomas, Phil wuerde gerne wissen, ob der Termin fuer Dein Seminar fest ist und was der Titel ist. Den Termin habe ich Dir vor einiger Zeit per Mail mitgeteilt, ich habe ihn im Augenblick nicht bei mir. Herbert ________________________________________________________________________________ N. S. Chant | chant@umdenp bitnet Dept. of Physics | chant@enp.umd.edu internet University of Maryland | umhep0::51201::chant hepnet College Park, MD 20742 | umaip::51201::chant span 1-(301)-405-6104 | -------------------------------------------------------------------------------- ================================================================================ Archive-Date: Wed, 19 Feb 1992 15:28:31 EST To: mx-list@vms.ecs.rpi.edu Date: Wed, 19 Feb 1992 19:42:56 GMT From: HELMUT@bonnie.physik.uni-stuttgart.de (Helmut Springer) Reply-To: HELMUT@bonnie.physik.uni-stuttgart.de (Helmut Springer) Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Feb19.194256.24390@rusmv1.rus.uni-stuttgart.de> Subject: getting 'invalid media address' We're running MX 3.0a under VMS 5.2 and CMU-Tek 6.5-2 on a VAX-cluster. One machine is running SMTP-Server and Local-agent, another one runs the Router and the SMTP-agent. The one running the Router is our brigde connecting our subnet with the backbone, and therefore has two ethernet cards. With some email-addresses I sometimes get the error 'invalid media address' from the SMTP-agent, although I've tested this email-addresses sucessfullly on a unix-machine. And sometimes mails sent to the same addresses are routed via the default-router and succeed (therefore no 'invalid media address' occurs)... So what does 'invalid media address' mean, and why is it so unpredictable ?? thanx for every help in advance... Helmut ================================================================================ Archive-Date: Wed, 19 Feb 1992 16:04:33 EST Date: Thu, 20 Feb 1992 06:05:04 EST From: hasegawa@jpntuhep Reply-To: hasegawa@jpntuhep To: MX-List@vms.ecs.rpi.edu CC: hasegawa@jpntuhep Message-ID: <009566D2.CA055480.135@jpntuhep> Subject: MX troubles Hi folks, As written at page B-2 of CMUTEK, I've installed Matt's MX023. Then, it turned out to cause two problems. Would you help me again, please? 1. in% can not refer NAMRES. Should we use MX% instead of IN%? 2. Most of income mails are written in JIS(Japan Industrial Standard) Kanji code. Kevin of innosoft had implemented kanji-code conversion option, but MX doesn't seem to have this function. How can I use it? Thank you. Regards, Katsuo ================================================================================ Archive-Date: Wed, 19 Feb 1992 16:29:44 EST Sender: Date: Wed, 19 Feb 1992 16:14:10 EST From: Marc Shannon Reply-To: Marc Shannon To: mx-list@vms.ecs.rpi.edu Message-ID: <0095665E.B69BA3A0.6402@CMUTEK.CC.CMU.EDU> Subject: FWD: MX troubles This message was sent to me, but I think that the MX-List is the better forum for this. His address is HASEGAWA@JPNTUHEP.Bitnet. --Marc CMU-TEK guy Return-Path: Received: from AWAVAX.AWA.TOHOKU.AC.JP by JUPITR.CC.CMU.EDU (MX V3.0A) with SMTP; Wed, 19 Feb 1992 15:26:53 EST Received: by jpntuhep (MX V2.3) id 123; Thu, 20 Feb 1992 05:30:18 EST Date: Thu, 20 Feb 1992 05:30:18 EST From: hasegawa@jpntuhep To: synful@cmutek.cc.cmu.edu CC: hasegawa@jpntuhep Message-ID: <009566CD.EEDEDEC0.123@jpntuhep> Subject: MX troubles Hi Marc, As written at page B-2, I've installed Matt's MX023. Then, it turned out to cause two problems. Would you help me again, please? 1. in% can not refer NAMRES. Should we use MX% instead of IN%? 2. Most of income mails are written in JIS(Japan Industrial Standard) Kanji code. Kevin of innosoft had implemented kanji-code conversion option, but MX doesn't seem to have this function. How can I use it? Should I post this mail to MX newsgroup? Thank you. Regards, Katsuo ================================================================================ Archive-Date: Wed, 19 Feb 1992 16:56:45 EST Sender: Date: Wed, 19 Feb 1992 13:55:36 PST From: "John F. Sandhoff" Reply-To: sandhoff@csus.edu To: hasegawa@jpntuhep.bitnet CC: mx-list@vms.ecs.rpi.edu, syssand@CCVAX.CCS.CSUS.EDU Message-ID: <0095664B.5B0321C0.16055@CCVAX.CCS.CSUS.EDU> Subject: re: MX troubles Hi folks, > As written at page B-2 of CMUTEK, I've installed Matt's MX023. Go grab 3.0A; anonymous-FTP to vms.ecs.rpi.edu > 1. in% can not refer NAMRES. Should we use MX% instead of IN%? Unless you've done something special, you should use MX%. > 2. Most of income mails are written in JIS(Japan Industrial Standard) > Kanji code. I defer to the experts Now a question of my own. From the original header: Date: Thu, 20 Feb 1992 06:05:04 EST From: hasegawa@jpntuhep Reply-To: hasegawa@jpntuhep To: MX-List@vms.ecs.rpi.edu From my VAX this (I believe) is an unreplyable addresss (yes, I know I can define a rewrite that will append .BITnet automatically. But I haven't, ok?). What mailer is at fault here? I suspect the Internet- BITnet gateway that the message first went thru? John F. Sandhoff, Network Support California State University, Sacramento sandhoff@csus.edu ================================================================================ Archive-Date: Thu, 20 Feb 1992 06:19:46 EST Date: Thu, 20 Feb 1992 08:12:56 EST From: edson@VAX.IFT.UNESP.BR (EDSON YOSHIMITSU SHIMABUKO \(XYKO\)) Reply-To: edson@VAX.IFT.UNESP.BR (EDSON YOSHIMITSU SHIMABUKO \(XYKO\)) To: mx-list@vms.ecs.rpi.edu Message-ID: <009566e4.a766da40.186@VAX.IFT.UNESP.BR> Subject: subscribe mx-list SUBSCRIBE ================================================================================ Archive-Date: Thu, 20 Feb 1992 09:22:37 EST Date: Thu, 20 Feb 1992 11:19:54 EST From: edson@VAX.IFT.UNESP.BR (EDSON YOSHIMITSU SHIMABUKO \(XYKO\)) Reply-To: edson@VAX.IFT.UNESP.BR (EDSON YOSHIMITSU SHIMABUKO \(XYKO\)) To: MX-LIST@VMS.ECS.RPI.EDU Message-ID: <009566fe.c53ca4e0.199@VAX.IFT.UNESP.BR> Subject: LIST LIST ================================================================================ Archive-Date: Thu, 20 Feb 1992 14:12:56 EST Sender: Date: Thu, 20 Feb 1992 12:10:24 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: <00956705.D38B31E0.31869@hg.uleth.ca> Subject: LOCAL delivery problem Hi: I have run into a serious problem with the LOCAL delivery agent. I am running MX V3.0A, UCX 1.3A and VMS 5.4-3. The problem started occurring when I upgraded MX from ver 2.3 to 3.0A, and happens very irregularly, but averages about once every ten days. At the same time as I upgraded, I started using the NAME_CONVERSION facility with my own conversion routines. However, my understanding is that these are used by the ROUTER, not the LOCAL delivery agent, so I don't know if this is significant or not. What happens is that mail stops being delivered to local users. Checking the delivery agents with a SHOW SYSTEM command shows nothing unusual: ------------------------------------------------------------------------------- VAX/VMS V5.4-3 on node MR 20-FEB-1992 09:41:54.22 Uptime 1 01:24:38 Pid Process Name State Pri I/O CPU Page flts Ph.Mem 22800132 MX Router HIB 4 462975 0 00:34:44.71 17876 650 22800134 MX Local HIB 5 368384 0 00:36:28.09 75187 757 22800136 MX SMTP HIB 4 105396 0 00:06:02.09 10339 782 22800138 SMTP Server HIB 5 86850 0 00:09:47.73 17753 659 2280013A MX MLF HIB 4 65106 0 00:03:46.11 985 185 ------------------------------------------------------------------------------- But, when I check the queue file with the FLQU SHOW command this is what I see: ------------------------------------------------------------------------------- 31461 MAIL FIN 1027 HG::PACS-L%UHUPVM1.B HG:: MX_ROUTER 31462 MAIL FIN 615 HG::SAFETY%UVMVM.BIT HG:: MX_ROUTER 31463 MAIL FIN 466 HG::WIN3-L%UICVM.BIT HG:: MX_ROUTER 31464 MAIL FIN 466 HG::WIN3-L%UICVM.BIT HG:: MX_LOCAL 31465 MAIL CAN 195 HG::Postmaster@hg.ul HG:: MX_ROUTER 31466 MAIL FIN 615 HG::SAFETY%UVMVM.BIT HG:: MX_LOCAL 31467 MAIL FIN 1027 HG::PACS-L%UHUPVM1.B HG:: MX_LOCAL 31468 MAIL CAN 197 HG::Postmaster@hg.ul HG:: MX_ROUTER 31469 MAIL CAN 201 HG::Postmaster@hg.ul HG:: MX_ROUTER ------------------------------------------------------------------------------- Note that for every LOCAL delivery entry, there is a CANCELLED entry from the local Postmaster. These are non-delivery notices addressed to the sender of the associated LOCAL delivery entry. The full text of the non-delivery notice nnn.MSG_TEXT file is as follows: ------------------------------------------------------------------------------- Note: this message was generated automatically. The following error(s) occurred during local delivery of your message. Error in delivery to user SMYTHE: error opening !AS as input Message follows. ------------------------------------------------------------------------------- Although it says `Message follows', it doesn't and, unfortunately, there is no indication of what file it was unable to open, or what the error was. To try to analyze the problem I turned on debugging by defining the logical name MX_LOCAL_DEBUG to be TRUE. The debug log files generated showed no problem: ------------------------------------------------------------------------------- 20-FEB-1992 09:43:38.13 Processing queue entry number 31486 20-FEB-1992 09:43:38.44 All done with this entry. ------------------------------------------------------------------------------- With debugging turned on, the CANCELLED Postmaster entries were no longer created, but the mail was still not delivered to the user. When I turned debugging off, it processed another half dozen LOCAL delivery entries and then it started creating the CANCELLED Postmaster entries again. At no time, however, did it actually deliver the mail to the user. This was verified by looking in the users' mail files and also by looking at the LOCAL accounting file: there were no accounting entries for the period when mail was not being delivered. I attempted to clear the problem by entering a MCP RESET LOCAL command, but it didn't help. I eventually shut down the entire MX system and restarted it, which did solve the problem. I don't mind mail being returned, or stacked up for later delivery, but when it just disappears into the bit bucket, I get concerned. Has anybody seen this problem before, or have any idea what is going on? Any help would be greatly appreciated. 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: Thu, 20 Feb 1992 14:17:40 EST Sender: Date: Thu, 20 Feb 1992 14:17:26 EST From: Matt Madison Reply-To: madison@vms.ecs.rpi.edu To: mx-list@vms.ecs.rpi.edu Message-ID: <00956717.927C0DC0.14110@mdmvs.ecs.rpi.edu> Subject: MX V3.1 field test I have put together the first field test kit of MX V3.1. I have about five field test sites right now; anyone else who would like to lend a hand with the test should drop me a line. The release notes currently list the following new features in V3.1 (not all of which have been tested yet): o MX_START has been altered to allow multiple instances of the Router, Local, SMTP, Jnet, and DNSMTP processes on one system. o MX_START has been altered to define logical names for all existing MX directories at startup time, even if the current node is not running the MX agent process that requires the logical to be defined. o A Received: line counter has been added to the SMTP and DECnet-SMTP servers, in order to detect mail loops. When MX sees 10 Received headers from the local system in a message, it assumes that the message is looping and does not accept the message. o The MCP SET JNET command now accepts a /USERNAME qualifier, which has two effects: 1. You no longer have to run the Jnet interface under a special MAILER account. 2. You may set MX to recognize multiple mailer accounts-to assist in the transition period when you change mailer usernames in the BITNET node table. o Support for SMTP over X.25 (using VAX P.S.I.) has been added. o Startup and shutdown of MX processes is now logged in their output files. You may also, optionally, have startup and shutdown messages logged to one or more OPCOM operator classes. The release notes also list the following bug fixes included in V3.1 which were not present in V3.0A: > DECnet addresses containing quotation marks (such as return addresses via MRGATE) were not getting quoted properly when they were translated into RFC822 syntax. This has been corrected. > Several NETLIB bugs have been fixed, and suport for TCPware was added. See the NETLIB release notes for further information. > The mechanism used to shutdown/reset MX agent processes has been improved to eliminate the occasional mysterious disappearances of MX processes. The first bug fix might be of interest to ALL-IN-1 users. The last should be of interest to anyone who has seen MX processes vanish without a trace. There may be a few more new features and bug fixes added over the course of the field test, which I expect will last through about 06 March 1992. Later, -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, 20 Feb 1992 16:00:26 EST Date: Thu, 20 Feb 1992 11:22 -0300(C) From: "EDSON YOSHIMITSU SHIMABUKO (XYKO)" Reply-To: "EDSON YOSHIMITSU SHIMABUKO (XYKO)" Subject: LIST To: MX-LIST@VMS.ECS.RPI.EDU Message-ID: References: ANSP network HEPnet SPAN Bitnet Internet gateway LIST ================================================================================ Archive-Date: Thu, 20 Feb 1992 16:07:05 EST Date: Thu, 20 Feb 92 16:04:27 EST From: Martin Tamm Reply-To: Martin Tamm Message-ID: <9202202104.AA25176@grizzly.nrl.navy.mil> To: MX-List@vms.ecs.rpi.edu Subject: Does MX-Mailer handle MX Mail Addresses? CC: tamm@grizzly.nrl.navy.mil Does the MX Mailer handle mail addresses which are MX records in the Domain Name Service? Martin Tamm tamm@grizzly.nrl.navy.mil ================================================================================ Archive-Date: Thu, 20 Feb 1992 16:17:34 EST Sender: Date: Thu, 20 Feb 1992 15:12:44 CST From: "James F. Burnett--University of Texas-PanAm" Reply-To: BURNETT@PANAM2.PANAM.EDU To: mx-list@vms.ecs.rpi.edu CC: burnett@PANAM1.PANAM.EDU Message-ID: <0095671F.4C2C3360.25649@PANAM1.PANAM.EDU> Subject: What is a .ERROR_MSG file ? Hi, Does anyone know what a .ERROR_MSG file in the queue directory is ? I typed one of these out and what it had in it did not look like an error. It was a BSMTP transaction log for some incoming mail. It looked as though the Jnet interface received some incoming mail, sent it successfully locally and generated the BSMTP error log(with a FROM: address of Postmaster@panam.bitnet). I'm concerned because I've never seen any of these before today and today, they are continually popping up in the queue directory. Are they being sent to the originator(in every case, a MAILER from another site), or are they being generated then deleted without being sent ? Are, indeed, the original messages being delivered locally ? Many thanks in advance to anyone with some info. Meanwhile, I'm going to turn on some logging to see if I can tell what's going on. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | James F. Burnett University of Texas-Pan American | | Systems Programmer I 1201 W. University Dr. | | Edinburg, TX 78539 | | | | | | INTERNET --> BURNETT@PANAM2.PANAM.EDU | | BITNET --> BURNETT@PANAM.BITNET | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ================================================================================ Archive-Date: Thu, 20 Feb 1992 16:43:17 EST Date: Thu, 20 Feb 1992 13:43:16 PST From: "W. Todd Wipke" Reply-To: "W. Todd Wipke" To: mx-list@vms.ecs.rpi.edu Message-ID: <00956712.CD9BCDA0.31763@SECS.UCSC.EDU> Subject: is this list still active? What is the most recent version of MX? Do I recall correctly that a new version handles "full names" on MLIST entries? -todd ================================================================================ Archive-Date: Thu, 20 Feb 1992 17:32:30 EST Date: Thu, 20 Feb 92 17:31:00 EST From: Martin Tamm Reply-To: Martin Tamm Message-ID: <9202202231.AA25676@grizzly.nrl.navy.mil> To: MX-List@vms.ecs.rpi.edu Subject: RE: Does MX-Mailer handle MX Mail Addresses? CC: tamm@grizzly.nrl.navy.mil Thank you all for your answers to the MX records question. Martin Tamm tamm@grizzly.nrl.navy.mil ================================================================================ Archive-Date: Fri, 21 Feb 1992 08:13:52 EST Message-ID: <9202211213.AA11556@infohh.rmi.de> From: lifra@infohh.rmi.de (Lahmeyer International GmbH) Date: 21.02.92 13:13:15 To: mx-list@vms.ecs.rpi.edu Subject: strange behaviour of mx30 Reply-To: lifra@infohh.rmi.de (Lahmeyer International GmbH) Hello dear mx-experts, I'm a beginner with MX, so please forgive me, if my problem is too simple... I requested all the parts of MX, puzzeled them together, installed the whole things, read (some) mx-manuals, and tried to send some local mail to me - without success. There ist absolutely no action from mx, no error messages, no bouncing mail,... I tried to send to mx%"sys_hjk" and to mx%"sys_hjk@lifra.lif.de". sys_hjk is my local username, lifra.lif.de is the name of the local host, a VAX-8530 with VMS-5.4-1 and multinet 3.0. The message itself was empty. The only thing I could discover was a strange output from mcp, see below. In addition, sending of thwo mail gives four entries in the mail queue... The following text has been converted to printable characters to avoid mail problems, i.e. the text "" means a binary "0". The very long lines in "Recipient" have been wrapped to several lines to avoid too long lines in this mail. ----------------------------------------------------------------------- MCP> que show/all/full Entry: 13, Origin: [Local] Status: FINISHED, size: 0 bytes Created: 20-FEB-1992 15:33:56.61, expires 21-MAR-1992 15:33:56.61 Last modified 20-FEB-1992 15:34:08.63 Recipient #1: Entry: 14, Origin: [Local] <> Status: FINISHED, size: 236 bytes Created: 20-FEB-1992 15:34:06.51, expires 21-MAR-1992 15:34:06.51 Last modified 20-FEB-1992 15:34:08.88 Recipient #1: s-Joachim"(: `"@lifra.lif.dee>NT : % @:%@:"@ Status: FINISHED, size: 0 bytes Created: 20-FEB-1992 15:34:31.19, expires 21-MAR-1992 15:34:31.19 Last modified 20-FEB-1992 15:34:42.89 Recipient #1: Entry: 16, Origin: [Local] <> Status: FINISHED, size: 236 bytes Created: 20-FEB-1992 15:34:41.21, expires 21-MAR-1992 15:34:41.21 Last modified 20-FEB-1992 15:34:43.28 Recipient #1: s-Joachim"(:2@Can't identify a route for this address.0:B@Message routing erro rter" @:P (#R ----------------------------------------------------------------------- If you have any ideas, suggestions, need more specific information... please drop me a mail. I prefer email, because I'm not sure, if the gatewayed messages to vmsnet.mail.mx will all arrive in germany (the list of messages is very short). I am reading and writing this stuff at an external mailbox, because our system does't have any connections to the outside world (but will have soon, hopefully). Thank you very much for any help. Hans-Joachim Koch Computer department of Lahmeyer International, Frankfurt lifra@infohh.rmi.de ================================================================================ Archive-Date: Fri, 21 Feb 1992 08:36:14 EST Sender: Date: Fri, 21 Feb 1992 08:36:06 EST From: Matt Madison Reply-To: madison@vms.ecs.rpi.edu To: mx-list@vms.ecs.rpi.edu Message-ID: <009567B1.0DAB7320.14252@mdmvs.ecs.rpi.edu> Subject: Compatibility of MX V3.0 with VMS V5.5, etc. I've been getting a number of inquiries about whether or not MX V3.0 will run on VMS V5.5. Unfortunately, I don't have V5.5 yet, and I'm not sure I'll be able to install it when I do get it (since it is documented as requiring at least 120MB on the system disk when you use DECwindows). I would expect MX to run just fine on V5.5. Has anyone tried it? Have you had any problems? By the way, I received one report that the SMTP-over-DECnet support I put into MX V3.0 does interoperate with PMDF. Can anyone else confirm or refute that? -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, 21 Feb 1992 08:54:04 EST Sender: goathunter%WKUVX1.BITNET@vms.ecs.rpi.edu Date: Fri, 21 Feb 1992 07:49:24 EST From: "Hunter Goatley, WKU" Reply-To: "Hunter Goatley, WKU" To: mx-list@vms.ecs.rpi.edu, madison@vms.ecs.rpi.edu Message-ID: <009567AA.878920E0.20114@WKUVX1.BITNET> Subject: RE: Compatibility of MX V3.0 with VMS V5.5, etc. Matt Madison writes: > >I've been getting a number of inquiries about whether or not MX V3.0 >will run on VMS V5.5. Unfortunately, I don't have V5.5 yet, and I'm >not sure I'll be able to install it when I do get it (since it is >documented as requiring at least 120MB on the system disk when you use >DECwindows). > >I would expect MX to run just fine on V5.5. Has anyone tried it? Have >you had any problems? > I hadn't even thought to post a message about it. MX v3.0 works just fine on VMS v5.5. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Fri, 21 Feb 1992 09:57:55 EST Date: Fri, 21 Feb 92 09:56:07 EST From: Martin Tamm Reply-To: Martin Tamm Message-ID: <9202211456.AA27537@grizzly.nrl.navy.mil> To: MX-List@vms.ecs.rpi.edu Subject: RE: Does MX-Mailer handle MX Mail Addresses? CC: tamm@grizzly.nrl.navy.mil The answer that I received concerning MX-Mailer handling Domain Name Service MX mail addresses is that it does. Martin Tamm ================================================================================ Archive-Date: Fri, 21 Feb 1992 10:10:59 EST Sender: Date: Fri, 21 Feb 1992 09:01:20 CST From: "George D. Greenwade" Reply-To: "George D. Greenwade" To: madison@vms.ecs.rpi.edu CC: mx-list@vms.ecs.rpi.edu Message-ID: <009567B4.9458A7A0.9423@SHSU.edu> Subject: RE: Compatibility of MX V3.0 with VMS V5.5, etc. In <009567B1.0DAB7320.14252@mdmvs.ecs.rpi.edu> (MX-List, Fri, 21 Feb 1992 08:36:06 EST), Matt Madison asked: > I've been getting a number of inquiries about whether or not MX V3.0 will > run on VMS V5.5. Unfortunately, I don't have V5.5 yet, and I'm not sure > I'll be able to install it when I do get it (since it is documented as > requiring at least 120MB on the system disk when you use DECwindows). > > I would expect MX to run just fine on V5.5. Has anyone tried it? Have you > had any problems? We just upgraded to 5.5 on Wednesday and, so far, everything appears to be working fine. We've got Jnet and SMTP under UCX on one node, SMTP under MultiNet on naother node, and MLF and NETLIB on both (as well as NETLIB but no MX on yet another node). Note that these are the old NETLIB versions (the ones originally included in MX 3.0). Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ================================================================================ Archive-Date: Fri, 21 Feb 1992 14:25:36 EST Date: Fri, 21 Feb 1992 10:40:08 EST From: Irv Eisen Reply-To: Irv Eisen To: mx-list@vms.ecs.rpi.edu Message-ID: <009567C2.619A3460.485@ccstat.mc.duke.edu> Subject: MX with VMS v5.5 We have been running MX version 2.3 on a VAX 4000 Model 500 with VMS version 5.5 for about a month now and have seen no problems. We might upgrade to MX 3.0 when other things in general, not related to either MX or 5.5, settle down. ========================================================================= | Irv Eisen, Systems Manager Bitnet : EISEN001@DUKEMC | | Cancer Center Internet: EISEN001@DUKEMC.MC.DUKE.EDU | | Box 3958 | | Duke University Medical Center Voice : (919) 286-7774 | | Durham, NC 27710 Fax : (919) 286-3956 | ========================================================================= ================================================================================ Archive-Date: Sat, 22 Feb 1992 20:58:40 EST Date: Sat, 22 Feb 92 17:59:42 -0800 Message-ID: <9202230159.AA04711@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: MX Router keeps crashing I know this isn't much to go on, but I'm finding that the MX Router process on my VAX 8650 keeps crashing about once a day. It's getting an access violation at the same line each time. Can anyone give me a hint about what I might look for? Here's the contents of the log file : %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=FFFFFFFF, PC=0007551C, PSL=03C00004 %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel PC abs PC 0007551C 0007551C 000746D3 000746D3 00073C8E 00073C8E PROCESS PROCESS 263 000002D1 00002ABC MX_ROUTER MX_ROUTER 178 00000217 00001C17 I'm running v3.0A under VMS 5.4, using SMTP. Bob Marshall marshall@force.ssd.lmsc.lockheed.com ================================================================================ Archive-Date: Sat, 22 Feb 1992 21:28:22 EST Sender: Date: Sat, 22 Feb 1992 18:25:45 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: <009568CC.97BB7670.3392@force.ssd.lmsc.lockheed.com> Subject: MX Router Crashing - addendum As a follow-up to my previous question about the MX Router process dying with an access violation, right after I posted the question I was able to duplicate the problem at will. I have patched SYS$LIBRARY:MAILSHR.EXE using the patch supplied with the MX v3.0A software; this patch allows a user to specify an address without prepending MX% and enclosing the address in quotes. Unfortunately, before I installed MX we were using a DECNET mail gateway to send outgoing internet mail. Using this gateway, we sent internet mail using VAXMail addresses like EAGLE::"user@host". After installing MX v3.0a and patching MAILSHR.EXE with the contributed patch in the [CONTRIB] directory, I find that if I specify an address like EAGLE::user@host (i.e., doing it the "old" way, but forgetting to enclose user@host in quotes) then the router process crashes. However, if I put back the original MAILSHR image, then of course the address is rejected as an invalid address. I'd like to be able to use the patch, since I've already gone and widely advertised it to my users. But I can't use it if it has the potential for crashing the router. Any ideas? (I know, "you get what you pay for"...) Bob Marshall marshall@force.ssd.lmsc.lockheed.com ================================================================================ Archive-Date: Mon, 24 Feb 1992 08:28:44 EST Sender: Date: Mon, 24 Feb 1992 14:31:25 MET From: Eckart Meyer Reply-To: Eckart Meyer To: MX-LIST@VMS.ECS.RPI.EDU Message-ID: <00956A3E.30861D20.1984@ifn.ing.tu-bs.de> Subject: RE: MX 3.1 > o Support for SMTP over X.25 (using VAX P.S.I.) has > been added. Whow! Unfortunately I have only one PSI-Node to play with to test it. 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: Wed, 26 Feb 1992 02:44:17 EST To: mx-list@vms.ecs.rpi.edu Date: 25 Feb 92 21:45:32 CST From: brodie@fps.mcw.edu Reply-To: brodie@fps.mcw.edu Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Feb25.214532.544@fps.mcw.edu> References: <009567AA.878920E0.20114@WKUVX1.BITNET> Subject: RE: Compatibility of MX V3.0 with VMS V5.5, etc. In article <009567AA.878920E0.20114@WKUVX1.BITNET>, goathunter%WKUVX1.BITNET@vms.ecs.rpi.edu (Hunter Goatley, WKU) writes: > Matt Madison writes: >> >>I've been getting a number of inquiries about whether or not MX V3.0 >>will run on VMS V5.5. Unfortunately, I don't have V5.5 yet, and I'm >>not sure I'll be able to install it when I do get it (since it is >>documented as requiring at least 120MB on the system disk when you use >>DECwindows). >> >>I would expect MX to run just fine on V5.5. Has anyone tried it? Have >>you had any problems? >> > I hadn't even thought to post a message about it. MX v3.0 works just > fine on VMS v5.5. ditto. Matt, you were aware I was on vms 5.5! (forget so soon??) anyway, works fine. -- Kent C. Brodie - Sr. Systems Manager InterNet: brodie@fps.mcw.edu Faculty Physicians & Surgeons uucpNet: fps.mcw.edu!brodie Medical College of Wisconsin MaBellNet: +1 414 266 5080 "Researchers have shown that people who drink four or more cups of coffee a day are 40% more prone to heart attacks.... I guess we all now know what happened to *MISTER* Olson...." -Jay Leno ================================================================================ Archive-Date: Wed, 26 Feb 1992 15:10:49 EST To: mx-list@vms.ecs.rpi.edu Date: 26 Feb 92 10:55:54 CST From: brodie@fps.mcw.edu Reply-To: brodie@fps.mcw.edu Sender: mx-list-request@vms.ecs.rpi.edu Message-ID: <1992Feb26.105555.545@fps.mcw.edu> Subject: need UUCP rewrite ruiles I need some help with rewrite rules for UUCP. Basically, I don't REALLY want to map a!b!c paths to ... .UUCP paths, because then the routing gets all screwed up. My rewrite path for uucp looks like DEFINE REWRITE "<@{route}:{host}!{user}@fps.mcw.edu>" - "<@{route}:{host}!{user}@fps.mcw.edu>" ! i.e., no-op DEFINE REWRITE "<{host}!{user}@fps.mcw.edu>" "<{user}@{host}.UUCP>" DEFINE PATH *.UUCP UUCP which *sort* of works, but doesn't, really. Basically, what I want to accomplish is, *if* I see any kind of BANG path, then sent it off to the UUCP router which then goes to DECUS UUCP. However, I want to leave the path *alone*. Can anyone help with this? (the original above came from Matt, but it still needs a litte work..) -- Kent C. Brodie - Sr. Systems Manager InterNet: brodie@fps.mcw.edu Faculty Physicians & Surgeons uucpNet: fps.mcw.edu!brodie Medical College of Wisconsin MaBellNet: +1 414 266 5080 "Researchers have shown that people who drink four or more cups of coffee a day are 40% more prone to heart attacks.... I guess we all now know what happened to *MISTER* Olson...." -Jay Leno ================================================================================ Archive-Date: Thu, 27 Feb 1992 04:06:34 EST Sender: Date: Wed, 26 Feb 1992 22:59:44 CST From: Glamdring Reply-To: Glamdring To: mx-list@vms.ecs.rpi.edu Message-ID: <00956C17.87FADCA0.357@abel.incstar.com> Subject: Problem with MX mail outbound via uucp When sending mail out via MX and then DECUS uucp I am experiencing a problem with the way the header is being built. In particular, when it arrives at adjoining uucp sites, the header looks like: |From incstar!!incstar.com!lhotka Wed, 26 Feb 92 22:35:14 CDT ^^^ NOTE THE DOUBLE BANGS |Received: by threa.incstar.com (V1.13/Amiga) | id AA00000; Wed, 26 Feb 92 22:35:14 CDT |Received: by abel.incstar.com (DECUS UUCP /1.3-1/2.5/); | Wed, 26 Feb 92 22:35:44 CST |Received: by abel.incstar.com (MX X3.1) id 336; Wed, 26 Feb 1992 22:35:29 CST |Sender: lhotka@abel.incstar.com |Date: Wed, 26 Feb 1992 22:35:24 CST |Message-ID: 00956C14.2192C3E0.336@abel.incstar.com |From: Glamdring |To: lhotka@threa |Subject: new testing | The same thing happens when sending to UUPC/extended, so it is not a problem with the receiving machine, it is getting munged before leaving the VAX. This did not happen prior to my use of MX, and still does not happen if mail is sent out via UUCP%"..." Anyone have any ideas on a cause/solution? Thanks. Rockford Lhotka INCSTAR Corp Applications Project Leader 1990 Industrial Blvd lhotka@incstar.com PO Box 285 612/779-1701 Stillwater, MN 55082 ================================================================================ Archive-Date: Thu, 27 Feb 1992 10:17:07 EST To: mx-list@vms.ecs.rpi.edu Date: 27 Feb 92 14:08:30 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: <1992Feb27.090830.2057@dayton.saic.com> References: <00956C17.87FADCA0.357@abel.incstar.com> Subject: Re: Problem with MX mail outbound via uucp In article <00956C17.87FADCA0.357@abel.incstar.com>, lhotka@abel.incstar.com (Glamdring) writes: > When sending mail out via MX and then DECUS uucp I am experiencing a problem > with the way the header is being built. > > In particular, when it arrives at adjoining uucp sites, the header looks like: > > |From incstar!!incstar.com!lhotka Wed, 26 Feb 92 22:35:14 CDT > ^^^ NOTE THE DOUBLE BANGS > This did not happen prior to my use of MX, and still does not happen if mail is > sent out via UUCP%"..." Anyone have any ideas on a cause/solution? Thanks. This is a problem with the interaction between MX and DECUS UUCP. Actually it is a DECUS UUCP problem. There is a fix for it. You are running the 1.3-1 mailshr image. 1.3-2 fixes it. I was hoping that Jamie and company would have a new release for the Fall 1991 VAX SIG tape that would fix it. It looks like they didn't make it. You might bring it up in the vmsnet.uucp group to see if they are willing to release just the new mailshr instead of having you wait til the next full release. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake SPAN: 28284::ake