Archive-Date: Tue, 01 Sep 1992 00:07:42 CDT Date: Tue, 01 Sep 1992 00:06:30 CDT From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <0095FF12.D6F28540.20198@WKUVX1.BITNET> Subject: MX-LIST Administrivia: Monthly Post Last modified: 2-JUL-1992 00:40 01:26 (Created) Welcome to MX-List@WKUVX1.BITNET, an electronic mailing list established for the discussion of the Message Exchange mail software. This is a routine posting you will see from time to time on MX-List. The MX-List archives are maintained at ARCHIVES@WKUVX1.BITNET. To get a copy of any month's postings, send an e-mail message with the body SEND MX-List.yyyy-mm to ARCHIVES@WKUVX1.BITNET, where "yyyy" is the year and "mm" is the numeric representation of the month. For example, the message SENDME MX-List.1992-04 will send the archives for April 1992. To remove yourself from the mailing list, send the following command to LISTSERV@WKUVX1.BITNET: SIGNOFF MX-List LISTSERV supports a few other commands for your convenience. The following commands can be handled automatically by the list processor: SIGNOFF MX-List - to remove yourself from the list REVIEW MX-List - to get a list of subscribers QUERY MX-List - to get the status of your entry on the list SET MX-List NOMAIL - to remain on the list but not receive mail SET MX-List MAIL - to resume receiving mail from the list SET MX-List CONCEAL - to not report your address in a REVIEW SET MX-List NOCONCEAL - to report your address in a REVIEW SET MX-List REPRO - to receive posts you make to MX-List SET MX-List NOREPRO - to not receive posts you make to MX-List LIST - to get a list of mailing lists served by WKUVX1 HELP - to receive a help file By default, subscriptions are set to MAIL, REPRO, NOCONCEAL. If you have any questions, comments, or suggestions about MX-List, please contact the list owner at the address below. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Hunter Goatley, VAX Systems Programmer goathunter@WKUVX1.BITNET Western Kentucky University Academic Computing, STH 226 (502) 745-5251 Bowling Green, KY 42101 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ================================================================================ Archive-Date: Tue, 01 Sep 1992 06:23:12 CDT Date: Tue, 01 Sep 1992 07:18:54 EDT From: "JAMES R. GRIFFIN(GRIFFIN@ADELPHI-HDLSIG1.ARMY.MIL)" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095FF4F.3EA6B620.4150@adelphi-hdlsig1.army.mil> Subject: RE: UCX SMTP vs MX UCX or as it's now also called, does support SMTP. Am installing it tonight and will let you know tomorrow whether any problems arise. Will also see if MX can be used with UCX 2.0 as well. ================================================================================ Archive-Date: Tue, 01 Sep 1992 07:17:04 CDT Sender: spinillo@MARYWOOD1.MARYWOOD.EDU Date: Tue, 01 Sep 1992 08:14:38 EDT From: spinillo@MARYWOOD1.MARYWOOD.EDU Reply-To: MX-List@WKUVX1.BITNET To: MX-List@RPIECSVX.BITNET Message-ID: <0095FF57.07FAC3C0.1550@MARYWOOD1.MARYWOOD.EDU> Subject: SUBSCRIBE PLEASE ADD ME THE THE MX LIST THANK YOU ================================================================================ Archive-Date: Tue, 01 Sep 1992 10:34:35 CDT Date: Tue, 01 Sep 1992 09:24:23 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: bg@dymaxion.ns.ca CC: mx-list@WKUVX1.BITNET Message-ID: <0095FF60.C62D7960.22770@swdev.si.com> Subject: RE: UCX SMTP vs MX I haven't received my copy of UCX V2.0 yet. When I do, I'll look over the SMTP facility. However, I suspect we'll continue to run MX even with a native SMTP. It won't be any more work maintaining two products than it is right now, since everyone using MX with UCX maintains two products already. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Tue, 01 Sep 1992 13:53:58 CDT From: meadows@cslvax.weeg.uiowa.edu Subject: Mailing List Problems Message-ID: <1992Sep1.175403.17428@news.weeg.uiowa.edu> Sender: (News) Reply-To: MX-List@WKUVX1.BITNET Date: Tue, 1 Sep 1992 17:54:03 GMT To: MX-List@WKUVX1.BITNET I posted yesterday regarding a mailing list I set up successfully, but have been unable to get things like HELP file to be sent to subscribers. I have turned on debug for MLF, ROUTER, and SMTP. The MLF logs look good, but the ROUTER and SMTP logs both complain about Postmaster@cslvax.weeg.uiowa.edu being an "invalid address"!? - I have an alias set up in MCP for Postmaster, but it still complains & will not send out HELP files (or REVIEWs). Here are the logs from ROUTER and SMTP: ======================= MX_ROUTER_LOG.LOG ================================= 1-SEP-1992 12:45:07.07 %PROCESS, Processing entry number 2063 1-SEP-1992 12:45:08.49 %PROCESS, Status from READ_INFO was 00000001 1-SEP-1992 12:45:08.49 %PROCESS, Recipient #0: Postmaster@cslvax.weeg.uiowa.edu 1-SEP-1992 12:45:08.50 %PROCESS, Invalid address: Postmaster@cslvax.weeg.uiowa. edu 1-SEP-1992 12:45:08.50 %PROCESS, Beginning ERRORQ processing. 1-SEP-1992 12:45:08.50 %PROCESS, RETURN_MESSAGE status was 00000001 1-SEP-1992 12:45:08.50 %PROCESS, Marking this entry as finished. ======================= MX_SMTP_LOG.LOG ==================================== 1-SEP-1992 12:45:02.26 Processing queue entry number 2062 on node CSLVAX 1-SEP-1992 12:45:03.41 Recipient: , route=vaxa.we eg.uiowa.edu 1-SEP-1992 12:45:03.41 SMTP_SEND: looking up host name vaxa.weeg.uiowa.edu 1-SEP-1992 12:45:03.59 SMTP_SEND: Attempting to start session with vaxa.weeg. uiowa.edu. [128.255.58.2] 1-SEP-1992 12:45:03.60 SMTP_SEND: Connected 1-SEP-1992 12:45:03.75 SMTP_SEND: Rcvd: 220 vaxa.weeg.uiowa.edu MX V3.1C SMTP server ready at Tue, 01 Sep 1992 12:45:04 CST 1-SEP-1992 12:45:03.91 SMTP_SEND: Sent: HELO cslvax.weeg.uiowa.edu 1-SEP-1992 12:45:04.08 SMTP_SEND: Rcvd: 250 Hello, cslvax.weeg.uiowa.edu 1-SEP-1992 12:45:04.08 SMTP_SEND: Sent: MAIL FROM:Postmaster@cslvax.weeg.uiow a.edu 1-SEP-1992 12:45:04.09 SMTP_SEND: Rcvd: 501 Invalid address: Postmaster@cslva x.weeg.uiowa.edu 1-SEP-1992 12:45:04.22 SMTP send failed, sts=0C27804A, sts2=0C26806C 1-SEP-1992 12:45:04.22 Recipient status=0C26806C for 1-SEP-1992 12:45:06.54 Entry now completely processed, no retries needed. 1-SEP-1992 12:45:06.72 *** End of processing pass *** If you can give me any clues as to what I must do, please reply directly by e-mail to meadows@cslvax.weeg.uiowa.edu. Thanks, Howard *************************************************************************** * Howard Meadows Sr. Systems Programmer Weeg Computing Center * * University Of Iowa Iowa City, Iowa 52242 Phone: 319-335-5519 * * email: howard-meadows@uiowa.edu * *************************************************************************** ================================================================================ Archive-Date: Tue, 01 Sep 1992 18:12:22 CDT From: meadows@cslvax.weeg.uiowa.edu Subject: RE: Mailing List Problems Message-ID: <1992Sep1.214617.3400@news.weeg.uiowa.edu> Date: 1 Sep 92 21:46:17 GMT Sender: (News) Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Just thought the group would like to know that Matt Madison sent me a message that cured the problems I was talking about the last couple of days regarding problems with an "invalid address" of Postmaster@mynode... As usual, Matt was able to pin down the problem & offer an easy fix. In case anyone else runs into this, here's my latest posting & his answer: >>******** My posting ********** >> I posted yesterday regarding a mailing list I set up successfully, but >>have been unable to get things like HELP file to be sent to subscribers. I >>have turned on debug for MLF, ROUTER, and SMTP. The MLF logs look good, but >>the ROUTER and SMTP logs both complain about Postmaster@cslvax.weeg.uiowa.edu >>being an "invalid address"!? - I have an alias set up in MCP for Postmaster, >>but it still complains & will not send out HELP files (or REVIEWs). >> >> Here are the logs from ROUTER and SMTP: >> >>======================= MX_ROUTER_LOG.LOG ================================= >> 1-SEP-1992 12:45:07.07 %PROCESS, Processing entry number 2063 >> 1-SEP-1992 12:45:08.49 %PROCESS, Status from READ_INFO was 00000001 >> 1-SEP-1992 12:45:08.49 %PROCESS, Recipient #0: >>Postmaster@cslvax.weeg.uiowa.edu >> 1-SEP-1992 12:45:08.50 %PROCESS, Invalid address: >>Postmaster@cslvax.weeg.uiowa.edu >> 1-SEP-1992 12:45:08.50 %PROCESS, Beginning ERRORQ processing. >> 1-SEP-1992 12:45:08.50 %PROCESS, RETURN_MESSAGE status was 00000001 >> 1-SEP-1992 12:45:08.50 %PROCESS, Marking this entry as finished. >> >>======================= MX_SMTP_LOG.LOG ==================================== >> 1-SEP-1992 12:45:02.26 Processing queue entry number 2062 on node CSLVAX >> 1-SEP-1992 12:45:03.41 Recipient: , >>route=vaxa.weeg.uiowa.edu >> 1-SEP-1992 12:45:03.41 SMTP_SEND: looking up host name vaxa.weeg.uiowa.edu >> 1-SEP-1992 12:45:03.59 SMTP_SEND: Attempting to start session with >>vaxa.weeg.uiowa.edu. [128.255.58.2] >> 1-SEP-1992 12:45:03.60 SMTP_SEND: Connected >> 1-SEP-1992 12:45:03.75 SMTP_SEND: Rcvd: 220 vaxa.weeg.uiowa.edu MX V3.1C >>SMTP >> server ready at Tue, 01 Sep 1992 12:45:04 CST >> 1-SEP-1992 12:45:03.91 SMTP_SEND: Sent: HELO cslvax.weeg.uiowa.edu >> 1-SEP-1992 12:45:04.08 SMTP_SEND: Rcvd: 250 Hello, cslvax.weeg.uiowa.edu >> 1-SEP-1992 12:45:04.08 SMTP_SEND: Sent: MAIL >>FROM:Postmaster@cslvax.weeg.uiowa.edu >> 1-SEP-1992 12:45:04.09 SMTP_SEND: Rcvd: 501 Invalid address: >>Postmaster@cslvax.weeg.uiowa.edu >> 1-SEP-1992 12:45:04.22 SMTP send failed, sts=0C27804A, sts2=0C26806C >> 1-SEP-1992 12:45:04.22 Recipient status=0C26806C for >> >> 1-SEP-1992 12:45:06.54 Entry now completely processed, no retries needed. >> 1-SEP-1992 12:45:06.72 *** End of processing pass *** >> >> >> If you can give me any clues as to what I must do, please reply directly >>by e-mail to meadows@cslvax.weeg.uiowa.edu. >> >> >***** Matt's Answer: >> >> server ready at Tue, 01 Sep 1992 12:45:04 CST >> 1-SEP-1992 12:45:03.91 SMTP_SEND: Sent: HELO cslvax.weeg.uiowa.edu >> 1-SEP-1992 12:45:04.08 SMTP_SEND: Rcvd: 250 Hello, cslvax.weeg.uiowa.edu >> 1-SEP-1992 12:45:04.08 SMTP_SEND: Sent: MAIL FROM:Postmaster@cslvax.weeg.u > ^^^^^^ > >Bingo. This should read MAIL FROM:. Without >the angle brackets, it's invalid. > >I suspect what's happening is that in composing the message to be sent to the >user, MLF is trying to use the first address in the DEFINE SYSTEM_USERS list >as the envelope FROM address, but you don't have any system_users defined, >so it's defaulting to Postmaster... but it's not formatting the address >correctly. If you add > > DEFINE SYSTEM_USERS "Postmaster@cslvax.weeg.uiowa.edu" > >to your configuration, you should be ok. > and, as usual, he was exactly right! After adding the above command via MCP, everything worked wonderfully! *************************************************************************** * Howard Meadows Sr. Systems Programmer Weeg Computing Center * * University Of Iowa Iowa City, Iowa 52242 Phone: 319-335-5519 * * email: howard-meadows@uiowa.edu * *************************************************************************** ================================================================================ Archive-Date: Wed, 02 Sep 1992 13:47:44 CDT Message-ID: <0096004B.C2A8FBC0.16949@uwwvax.uww.edu> Date: Wed, 02 Sep 1992 13:26:29 CDT From: hunterl@uwwvax.uww.edu Reply-To: MX-List@WKUVX1.BITNET Subject: Protocol errors To: mx-list@WKUVX1.BITNET I am seeing many messages waiting in the queue due to a protocol error. They are to IBM mainframes and after many re-tries leave the queue. Is anyone else seeing these? Does anyone have a clue as to way it is happening? We use CMU 6.6-2 on a VAX 4000. Lyle Hunter Computer Center University Wisconsin-Whitewater hunterl@uwwvax.uww.edu ================================================================================ Archive-Date: Wed, 02 Sep 1992 17:28:28 CDT Sender: ebates@uop.edu Date: Wed, 02 Sep 1992 14:12:14 PDT From: Ed Bates Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00960052.26995660.2026@vms1.cc.uop.edu> Subject: RE: Protocol errors On Wed, 02 Sep 1992 13:26:29 CDT hunterl@uwwvax.uww.edu writes: >I am seeing many messages waiting in the queue due to a protocol >error. They are to IBM mainframes and after many re-tries leave the >queue. Is anyone else seeing these? Does anyone have a clue as to >way it is happening? We use CMU 6.6-2 on a VAX 4000. I have seen protocol errors. They appeared after I messed with the configuration files. They disappeared after I reinstalled MX to repair my "fixes". You might check the validity of the destination address as MX is trying to send it. -- Ed - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Edwin J. (Ed) Bates VAX Administrator/Postmaster . . _ _ Technical Support Specialist Internet: ebates@uop.edu | | / \ | \ Office of Computing Services AppleLink: U1441 | | | | |_/ University of the Pacific Telephone: (209) 946-2251 | | | | | Stockton, CA 95211 Fax: (209) 946-2898 \_/ \_/ | %MAIL-W-NOFNCYQTE, no fancy quote or joke found in signature file ================================================================================ Archive-Date: Fri, 04 Sep 1992 11:07:20 CDT From: meadows@cslvax.weeg.uiowa.edu Subject: FILESERV Transaction Logs Message-ID: <1992Sep4.151434.27363@news.weeg.uiowa.edu> Sender: (News) Reply-To: MX-List@WKUVX1.BITNET Date: Fri, 4 Sep 1992 15:14:34 GMT To: MX-List@WKUVX1.BITNET Now that we've got our Mailing List & File Server going well, and everyone likes it, there has been one question I have not been able to find in the docs (maybe this is not possible). Is there any way to disable the sending of the FILESERV transaction log to users who request files? Ideally, we'd like to turn it off on an individual subscriber basis, but even globally would be ok. Is this possible? - If so, what do I need to do? Thanks, Howard *************************************************************************** * Howard Meadows Sr. Systems Programmer Weeg Computing Center * * University Of Iowa Iowa City, Iowa 52242 Phone: 319-335-5519 * * email: howard-meadows@uiowa.edu * *************************************************************************** ================================================================================ Archive-Date: Fri, 04 Sep 1992 13:41:08 CDT From: Subject: Re: MX 3.1c and UCX 2.0 - Do they work? Message-ID: <00960214.77E69500@evax.tuwien.ac.at> Sender: news@email.tuwien.ac.at Reply-To: MX-List@WKUVX1.BITNET References: <1992Aug27.141711.9810@magnus.acs.ohio-state.edu> Date: Fri, 4 Sep 1992 18:55:44 GMT To: MX-List@WKUVX1.BITNET In article <1992Aug27.141711.9810@magnus.acs.ohio-state.edu>, GAYNOR@agvax2.ag.ohio-state.edu (Jim Gaynor) writes: > >Just got ahold of UCX 2.0. However, I haven't installed it yet. >Among other things, I'm wondering if MX 3.1c will work properly with >UCX 2.0. At the moment, I'm running MX 3.0 (and some revision letter >I can't recall right now), and UCX 1.3a. I figure that if this does >work out, I'll upgrade UCX and MX in one swell foop. :-) > >So, does anyone have any first-hand experience on MX 3.1c and UCX 2.0? > I've got UCX 2.0 some days ago. I encountered some problems in sending smtp mails with UCX 2.0 SMTP, especially to hosts running the MX-software. We discovered, that UCX uses in the receipt field only the form user@host, host without domain extension (e.g: xyz@foo.bar.none becomes xyz@foo) We tried to install MX 3.1c. After disabling UCX SMTP-Support, the MX-Software took over all the mail delivery work successfully. -------------------------------------------------------------------------------- Peter Hoffmann Computing Services Technical University Vienna VAX System Manager Wiedner Hauptstrasse 8 - 10 / 020 INTERNET: hoffmann@evax.tuwien.ac.at A-1040 Vienna, Austria UNA: EVAX::HOFFMANN Tel. (++43 1) 58801 / 5487 PSI: 02322623106032::HOFFMANN FAX (++43 1) 587 42 11 ================================================================================ Archive-Date: Wed, 09 Sep 1992 02:10:09 CDT Date: Tue, 08 Sep 1992 10:46:39 MDT From: "Mark geib@vistanm.com" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@RPIECSVX.BITNET CC: geib@vistanm.com Message-ID: <009604EC.6D84A180.631@vistanm.com> Subject: Help for MX Is there a mail list which I can subscribe to which I can direct questions regarding MX. I am having trouble with a few areas and need to ask soe questions of current MX users. Thanks. Mark Geib Vista Control Systems, Inc. ================================================================================ Archive-Date: Wed, 09 Sep 1992 02:39:45 CDT Subject: Re: FILESERV Transaction Logs Message-ID: <1992Sep5.082433.4491@dmc.com> From: Reply-To: MX-List@WKUVX1.BITNET Date: 5 Sep 92 08:24:33 EDT References: <1992Sep4.151434.27363@news.weeg.uiowa.edu> To: MX-List@WKUVX1.BITNET In article <1992Sep4.151434.27363@news.weeg.uiowa.edu>, meadows@cslvax.weeg.uiowa.edu writes: > Now that we've got our Mailing List & File Server going well, and > everyone likes it, there has been one question I have not been able to > find in the docs (maybe this is not possible). > > Is there any way to disable the sending of the FILESERV transaction > log to users who request files? Ideally, we'd like to turn it off on > an individual subscriber basis, but even globally would be ok. Is this > possible? - If so, what do I need to do? > > Thanks, > Howard > Howard, In short, no. I just looked at the code and the transaction log is wired in pretty well. It would be a fair amount of work even to allow it to be turned off globally. If you have a Bliss compiler, you could give it a try though. It's a good idea. Dick -- Dick Munroe Internet: munroe@dmc.com Doyle Munroe Consultants, Inc. UUCP: ...uunet!thehulk!munroe 267 Cox St. Office: (508) 568-1618 Hudson, Ma. FAX: (508) 562-1133 GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection. ================================================================================ Archive-Date: Wed, 09 Sep 1992 15:35:31 CDT Date: Wed, 09 Sep 1992 21:31:00 EDT From: "J.C. Higgins, Sys Mgr CsVax1, UCC , Eire" Reply-To: MX-List@WKUVX1.BITNET Subject: Trapping bounced mail messages. To: MX-LIST@WKUVX1.BITNET Message-ID: <0096060F.9B610020.6329@CSVAX1.UCC.IE> Hi, Is there any logical (or any other method for that matter) that allows a copy of any mail that is in the process of being bounced to be sent to the postmaster. .sig invisible, cause this is an annoying line editor...must change Bulletin editor... Chris. Chris@csvax1.ucc.ie ================================================================================ Archive-Date: Wed, 09 Sep 1992 18:53:55 CDT Sender: wilton@hg.uleth.ca Date: Wed, 09 Sep 1992 09:07:09 MDT From: "Russ Wilton, Systems Manager" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: wilton@hg.uleth.ca Message-ID: <009605A7.B1640D80.16247@hg.uleth.ca> Subject: MX hangs if FLQ_DIR is unavailable Hi: I run MX on a mixed interconnect cluster with three timeshared nodes and a bunch of workstations. VMS 5.5-1 and MX 3.0A. To get the file traffic associated with FLQ_DIR off our HSC and shared disk, I moved the ROUTER, LOCAL and MLF processes to a workstation and put the FLQ_DIR on the workstation's attached disk. This works quite well and seems to put a minimal load on the workstation - it's disk doesn't have anything else on it except page and swap files. Now for the problem. :-) When the work station is down for any reason, the FLQ_DIR is unavailable to the other nodes. Users on the other nodes trying to send mail have their process hang immediately after entering an MX%"..." type address. And the process is well and truely hung - it does not respond to ^C or ^Y. It would be a lot more friendly to have the MX mailshr processes detect the fact that the FLQ_DIR is not available and just give the users a message saying that MX Mail is not currently available. Please consider this as a suggested improvement for the next version. If this is alerady fixed in MX 3.1 please ignore the above - I'll be going to 3.1C in the near future. 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: Wed, 09 Sep 1992 20:56:23 CDT Date: Wed, 09 Sep 1992 20:34:39 EDT From: "J.C. Higgins, Sys Mgr CsVax1, UCC , Eire" Reply-To: MX-List@WKUVX1.BITNET Subject: Trapping bounced mail. To: mx-list@RPIECSVX.BITNET Message-ID: <00960607.BBD47880.6252@CSVAX1.UCC.IE> Hi, Is there any way that I can have a copy of mail that is to be 'bounced' back to the sender sent to the POSTMASTER. Is there anything 'special' about the address that is used to return the bounced message.. because if there is something unique about it, then I could try a rewrite rule to send it to a site procedure that would send it to the real user, and a copy to the postmaster.... If it is not possible, then what are the chances of having the option in the next version.. (You reading this Hunter and Matt :) Chris. + J.C. Higgins, Sys Admin + If you love something, set it free. If it doesn't + CHRIS@csvax1.ucc.ie + come back to you, hunt it down and KILL it. If + SCCS6002@iruccvax.ucc.ie + that doesn't work, then GIVE UP peacefully. ================================================================================ Archive-Date: Wed, 09 Sep 1992 21:38:55 CDT Date: Wed, 09 Sep 1992 16:36:25 CDT From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <009605E6.74ECEEA0.7680@SHSU.edu> Subject: Re: FILESERV Transaction Logs On 5 Sep 92 08:24:33 EDT, Dick Munroe posted: > In article <1992Sep4.151434.27363@news.weeg.uiowa.edu>, > meadows@cslvax.weeg.uiowa.edu writes: > > Now that we've got our Mailing List & File Server going well, and > > everyone likes it, there has been one question I have not been able to > > find in the docs (maybe this is not possible). > > > > Is there any way to disable the sending of the FILESERV transaction > > log to users who request files? Ideally, we'd like to turn it off on > > an individual subscriber basis, but even globally would be ok. Is this > > possible? - If so, what do I need to do? > > In short, no. I just looked at the code and the transaction log is wired > in pretty well. It would be a fair amount of work even to allow it to be > turned off globally. > > If you have a Bliss compiler, you could give it a try though. It's a good > idea. Depends on how you define good idea. If you server is set to serve only during specified times, or is set to serve certain thresholds at certain times, or the files requested are larger than the transaction log, the verification ought to be sent as soon as something is processed. You can't necessarily say thsi about the files being served. While it is a little more overhead and bandwidth, at least the log tells the user is everything was successful or not (if not, what was bad is reported), as well as everything to expect. The extra log file shouldn't cause a user to go over quota (if so, they are dangerously close anyway) and they are consistently labelled in the Subj: line, so two keystrokes (d [RETURN]) get rid of them quite easily. The information generated for the end user is well worth any annoyance they might feel, IMO. If you're an even moderately heavily used site, this precludes extra requests, which are even more overhead and bandwidth, that may arise if a the end user is unaware that anything has been done or has no idea what to expect. Regards (and off my soapbox), 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, 09 Sep 1992 22:40:52 CDT Date: Wed, 09 Sep 1992 13:45:56 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <009605CE.A347EC40.27198@swdev.si.com> Subject: MCP access violates I've had MCP QUEUE SHOW/ALL/FULL access violate on me several times in the last few days. If I enter the command again immediately after, it works. It seems to me that it might be happening when something in MX has the queue file tied up and MCP doesn't handle this correctly. Has anyone else observed this behavior? On another note, people have been using MAILQUEUE to view any messages they may have pending. If they have no messages, MAILQUEUE shows nothing. Is there a way to entice MAILQUEUE to show all of the messages for the person running it so that they have confirmation their messages have been processed? On a third note, I dumped the MAILQUEUE image and saw references to X400_INFO and X.400. If this a feature that will possibly appear later (an X.400 agent)? -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 10 Sep 1992 01:22:37 CDT Date: Wed, 09 Sep 1992 23:09:26 PDT From: "W. Todd Wipke" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@RPIECSVX.BITNET Message-ID: <0096061D.5B595DC0.23695@SECS.UCSC.EDU> Subject: disk full situation we recently had the disk on which the MX Queue was located fill up, plus the system disk of the machine that runs most of the servers had a board failure. Fixing the board brought everything to life (without reboot, ah the tolerance of VMS!!!) but the MX Local server kept terminating. It happened because MX had made an entry in the Queue (which required no new disk blocks), but could not make the file for the headers and src, etc. It required manual comparison and canceling entries for which no files existed in order to get MX Local out of critical condition and on its feet. A couple years ago I had a similar problem for a different reason, msgs couldn't go out for a while and the body of the msgs got deleted but the entries in the queue remained. It seems like there should be greater rigor to assure that no files get deleted unless the entry is removed. Or to help people recover and do validity checking, have an mcp queue function that checks each entry in the queue against required files in the queue and if there is an entry without a file, cancel the entry in the queue. Perhaps this account will inform people of things to look for when things don't seem right and deamons die repeatedly. MX debug for MX Local was helpful, but process accounting was also necessary. I thing a queue validity analysis would be very useful, and rather simple. MX is great! I looked for Matt Madison and the TGV gang at the Capitola Sand Castle contest but there were no computer themes there. -Todd wipke UCSC ================================================================================ Archive-Date: Thu, 10 Sep 1992 05:42:58 CDT Sender: goathunter@WKUVX1.BITNET Date: Thu, 10 Sep 1992 05:42:16 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00960654.3C37AE60.13396@WKUVX1.BITNET> Subject: RE: Trapping bounced mail. "J.C. Higgins, Sys Mgr CsVax1, UCC , Eire" writes: > >Is there any way that I can have a copy of mail that is to be 'bounced' >back to the sender sent to the POSTMASTER. > Currently, there's not.... >If it is not possible, then what are the chances of having the option >in the next version.. (You reading this Hunter and Matt :) > I think it'd be a useful option to have, and have already planned to add that sometime. FYI: the big project that I'm working on that's still keeping me from MX work is planned for completion *before* January 1, so you should expect a new version of MX before or around that date. Sorry to have to put everybody on hold, but MX V3.1C seems to be very stable.... Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Thu, 10 Sep 1992 05:44:19 CDT Sender: goathunter@WKUVX1.BITNET Date: Thu, 10 Sep 1992 05:43:41 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00960654.6EF703A0.13398@WKUVX1.BITNET> Subject: RE: MCP access violates "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: > >I've had MCP QUEUE SHOW/ALL/FULL access violate on me several times in the last >few days. If I enter the command again immediately after, it works. It seems >to me that it might be happening when something in MX has the queue file tied up >and MCP doesn't handle this correctly. Has anyone else observed this behavior? > I've seen it occasionally, but it's rare and very hard to reproduce, as you've seen. >On another note, people have been using MAILQUEUE to view any messages they may >have pending. If they have no messages, MAILQUEUE shows nothing. Is there a >way to entice MAILQUEUE to show all of the messages for the person running it so >that they have confirmation their messages have been processed? > Currently, there's not, though I agree that it would be a very useful addition. I've added it to the list.... >On a third note, I dumped the MAILQUEUE image and saw references to X400_INFO >and X.400. If this a feature that will possibly appear later (an X.400 agent)? > Got me.... Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Thu, 10 Sep 1992 06:02:32 CDT Sender: goathunter@WKUVX1.BITNET Date: Thu, 10 Sep 1992 06:01:52 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00960656.F941EDC0.13402@WKUVX1.BITNET> Subject: RE: disk full situation "W. Todd Wipke" writes: > >we recently had the disk on which the MX Queue was located fill up, plus >the system disk of the machine that runs most of the servers had a board >failure. Fixing the board brought everything to life (without reboot, ah >the tolerance of VMS!!!) but the MX Local server kept terminating. It happened >because MX had made an entry in the Queue (which required no new disk blocks), >but could not make the file for the headers and src, etc. It required manual [...] > It seems like there should be greater rigor to assure that no files >get deleted unless the entry is removed. Or to help people recover and do [...] >also necessary. I thing a queue validity analysis would be very useful, and >rather simple. > I've added this to the list (it was probably on Matt's list already). Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Thu, 10 Sep 1992 08:44:40 CDT Sender: goathunter@WKUVX1.BITNET Date: Thu, 10 Sep 1992 08:44:01 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096066D.A0625840.13476@WKUVX1.BITNET> Subject: RE: MX hangs if FLQ_DIR is unavailable "Russ Wilton, Systems Manager" writes: > > I run MX on a mixed interconnect cluster with three timeshared nodes and >a bunch of workstations. VMS 5.5-1 and MX 3.0A. To get the file traffic >associated with FLQ_DIR off our HSC and shared disk, I moved the ROUTER, >LOCAL and MLF processes to a workstation and put the FLQ_DIR on the >workstation's attached disk. [...] > When the work station is down for any reason, the FLQ_DIR is unavailable >to the other nodes. Users on the other nodes trying to send mail have their >process hang immediately after entering an MX%"..." type address. And the >process is well and truely hung - it does not respond to ^C or ^Y. > It would be a lot more friendly to have the MX mailshr processes detect >the fact that the FLQ_DIR is not available and just give the users a message >saying that MX Mail is not currently available. Please consider this as >a suggested improvement for the next version. [...] I've added this to the wish list. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Thu, 10 Sep 1992 14:26:55 CDT Date: Thu, 10 Sep 1992 14:20:31 CDT From: "James F. Burnett--University of Texas-PanAm" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <0096069C.A2990300.10430@PANAM1.PANAM.EDU> Subject: Username Lengths-Looking for an Explanation Hello, Yesterday, something unusual happened here that I need to find an explanation for, both for my own sake and that of others I will need to explain it to. I'm posting to this list since MX, BITNET, and INTERNET are closely interrelated and I'm not sure wherein lie the origins of the problem. We created a new user with a 9 character username. That user logged in and subscribed to a couple of mailing lists(both very active lists) and began receiving mail--well, almost began receiving mail. The mail reached here just fine, but somewhere along the route, the username was truncated to 8 characters. MX attempted to find the truncated username here, was unable to do so, generated an error reply, and sent it back where it came from. I fixed the problem by defining an alias for that user but began wondering/thinking about how many other usernames we have that are 8+ characters long and about the poor soul who replaces me when I decide to leave here who generates 1000 student usernames one semester that are each 10 characters long. WOW ! I need an explanation of why this is happening. Is it related to BITNET, INTERNET, MX, all of the above, none of the above, or what ? I've been aware for quite some time that the length of the POSTMAST(ER) account has been an issue but never had thought of it in terms of other usernames. Is there a more convenient way to deal with the problem than having to remember to limit usernames to 8 or less characters or defining aliases ? After all, VMS allows 12 character usernames. I noticed in earlier postings that someone had suggested sending bounced mail messages to the local postmaster also. I think that's an excellent idea and am glad Hunter has agreed. I only have time to look at MX occassionally and wouldn't have even noticed this problem if another user hadn't called me concerning another potential problem with MX. I manage to log into the POSTMASTER account about once a day. -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + James F. Burnett INTERNET: BURNETT@PANAM.EDU + + Systems Programmer I BITNET : BURNETT@PANAM.BITNET + + University of Texas-Pan American Edinburg, TX (512)381-2561 + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ================================================================================ Archive-Date: Thu, 10 Sep 1992 14:40:23 CDT Sender: goathunter@WKUVX1.BITNET Date: Thu, 10 Sep 1992 14:39:20 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096069F.43998660.13609@WKUVX1.BITNET> Subject: RE: Username Lengths-Looking for an Explanation "James F. Burnett--University of Texas-PanAm" writes: > >We created a new user with a 9 character username. That user logged >in and subscribed to a couple of mailing lists(both very active lists) >and began receiving mail--well, almost began receiving mail. The mail >reached here just fine, but somewhere along the route, the username >was truncated to 8 characters. MX attempted to find the truncated >username here, was unable to do so, generated an error reply, and sent >it back where it came from. > [...] >I need an explanation of why this is happening. Is it related to >BITNET, INTERNET, MX, all of the above, none of the above, or >what ? It's a BITNET problem. More specifically, it's a problem with the mailer that sent the messages out. Or else it's really your problem! 8-) The mailer serving those lists sent you a regular Jnet file, not a BSMTP message. That can happen when: a) the other mailer doesn't handle BSMTP b) the other mailer's copy of XMAILER.NAMES is out-of-date c) your entry in XMAILER.NAMES doesn't indicate that you are BSMTP-compatible For regular Jnet files, the usernames get truncated to 8 characters. That's the part that makes it a BITNET problem. The solution: make sure your entry is OK in XMAILER.NAMES, then, if it is, perhaps contact the postmaster at the remote node and (gently?) ask if they are up-to-date on XMAILER.NAMES. >I've been aware for quite some time that the length of the >POSTMAST(ER) account has been an issue but never had thought of it in >terms of other usernames. Is there a more convenient way to deal with >the problem than having to remember to limit usernames to 8 or less >characters or defining aliases ? After all, VMS allows 12 character >usernames. > I've kept the limit to 8 (with the exception of my own---and I have an alias set up). >I noticed in earlier postings that someone had suggested sending >bounced mail messages to the local postmaster also. I think that's >an excellent idea and am glad Hunter has agreed. I only have time >to look at MX occassionally and wouldn't have even noticed this >problem if another user hadn't called me concerning another potential >problem with MX. I manage to log into the POSTMASTER account about >once a day. > POSTMASTER doesn't have to be a real account---you can set up a forwarding address for it in mail using SET FORWARD/USER=POSTMAST(ER) or define an alias in MCP for POSTMASTER. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Thu, 10 Sep 1992 15:06:39 CDT Date: Thu, 10 Sep 1992 15:45:56 EDT From: kliu@ccl4.eng.ohio-state.edu Reply-To: MX-List@WKUVX1.BITNET To: mx-list@RPIECSVX.BITNET Message-ID: <009606A8.918CE200.392@ccl4.eng.ohio-state.edu> Subject: Need Help Hi: I installed CMUTEK 6.6 and MX 2.3 on VMS 5.5. The MX is great except one problem. I define the logic name SONNET to MX%. DEFINE/SYSTEM/EXEC SONNET MX% Then I use the follwowing steps to send mails: $MAIL MAIL> SEND TO: SONNET"kliu@magnus.acs.ohio-state.edu" The receiver will get the mail but have X-Mx-Warning as following: ___________________________________________________________________________ From kliu@ccl4.eng.ohio-state.edu Thu Sep 10 14:23:13 1992 Received: from ccl4.eng.ohio-state.edu by top.magnus.acs.ohio-state.edu (5.65/3. 910213) id AA05369; Thu, 10 Sep 92 14:23:10 -0400 Received: by ccl4.eng.ohio-state.edu (MX V2.3) id 386; Thu, 10 Sep 1992 14:22:31 EDT Date: Thu, 10 Sep 1992 14:22:31 EDT From: kliu@ccl4.eng.ohio-state.edu X-Mx-Warning: Warning -- Invalid "To" header. To: magnus.acs.ohio-state.edu"@ccl4.eng.ohio-state.edu Message-Id: <0096069C.EA336520.386@ccl4.eng.ohio-state.edu> Subject: test with sonnet Status: OR ____________________________________________________________________________ Can anyone give me some advises? Thank you! Kuo-Ching Liu E-mail: kliu@ccl4.eng.ohio-state.edu ================================================================================ Archive-Date: Thu, 10 Sep 1992 21:17:43 CDT Subject: Re: Username Lengths-Looking for an Explanation Message-ID: <1992Sep11.024504.1@sejnet.sunet.se> From: Date: 11 Sep 92 02:45:04 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: news@sunic.sunet.se References: <0096069C.A2990300.10430@PANAM1.PANAM.EDU> To: MX-List@WKUVX1.BITNET In article <0096069C.A2990300.10430@PANAM1.PANAM.EDU>, "James F. Burnett--University of Texas-PanAm" writes: > We created a new user with a 9 character username. That user logged > in and subscribed to a couple of mailing lists(both very active lists) Users with login names longer than 8 bytes MUST subscribe via mail, not SEND. The protocol used by BITNET supports userids of up to 8 bytes only. > I fixed the problem by defining an alias for that user but began > wondering/thinking about how many other usernames we have that are > 8+ characters long and about the poor soul who replaces me when I decide > to leave here who generates 1000 student usernames one semester that > are each 10 characters long. WOW ! I suspect the 8-bytes prefix was not unique in the case of this particular user. That is, there were several UAF entries starting with these 8 bytes. Eric ================================================================================ Archive-Date: Fri, 11 Sep 1992 00:58:07 CDT Date: Fri, 11 Sep 92 07:51+0000 Message-ID: <4955500711091992/A03609/RHEA/116959F12200*> From: Robert Heinze Reply-To: MX-List@WKUVX1.BITNET To: MX-List Subject: RE: NEED HELP > I installed CMUTEK 6.6 and MX 2.3 on VMS 5.5. The MX is great >except one problem. I define the logic name SONNET to MX%. > > DEFINE/SYSTEM/EXEC SONNET MX% > >Then I use the follwowing steps to send mails: > > $MAIL > MAIL> SEND > TO: SONNET"kliu@magnus.acs.ohio-state.edu" Hello Kuo-Ching Liu Try : DEFINE/SYSTEM/EXEC SONNET MX% $MAIL MAIL> SEND TO: SONNET::"kliu@magnus.acs.ohio-state.edu" Robert Heinze ,Fachhochschule Kiel, FB-Maschinenwesen ,Rechenzentrum Sokratesstr.1 ,D-2300 Kiel, Germany X.400 : C=de;A=dbp;P=fh-kiel;OU=maschinenwesen;S=heinze RFC-822 : heinze@maschinenwesen.fh-kiel.dbp.de ================================================================================ Archive-Date: Fri, 11 Sep 1992 07:12:46 CDT Date: Fri, 11 Sep 1992 14:05:23 EDT From: "J. Muz" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@RPIECSVX.BITNET Message-ID: <00960763.AFA9DCA0.19@mpabas.mpa.uni-stuttgart.de> Subject: subscribe SUBSCRIBE ================================================================================ Archive-Date: Fri, 11 Sep 1992 08:59:03 CDT Message-ID: <00960737.6B94ADA0.30359@uwwvax.uww.edu> Date: Fri, 11 Sep 1992 08:48:31 CDT From: hunterl@uwwvax.uww.edu Reply-To: MX-List@WKUVX1.BITNET Subject: NOREPRO feature on MLF To: mx-list@WKUVX1.BITNET Can the option NOREPRO be set globally for a given list? Preferably when defining the list. Lyle Hunter Computer Center University Wisconsin-Whitewater hunterl@uwwvax.uww.edu ================================================================================ Archive-Date: Fri, 11 Sep 1992 10:02:42 CDT From: Subject: Re: MCP access violates Message-ID: <1992Sep10.170529.10720@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <009605CE.A347EC40.27198@swdev.si.com> Date: Thu, 10 Sep 1992 17:05:29 GMT To: MX-List@WKUVX1.BITNET In article <009605CE.A347EC40.27198@swdev.si.com>, "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: >On a third note, I dumped the MAILQUEUE image and saw references to X400_INFO >and X.400. If this a feature that will possibly appear later (an X.400 agent)? Because adding support in the queue entry structures requires a recompile of all the MX source code, the last time I added some I added fields to handle all of the additional delivery mechanisms I was considering at the time. I never did any work on an X.400 agent, though. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Fri, 11 Sep 1992 10:05:02 CDT Subject: RE: Trapping bounced mail. Message-ID: <1992Sep10.182509.19950@cco.caltech.edu> From: Date: 10 Sep 92 18:25:09 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: news@cco.caltech.edu References: <00960654.3C37AE60.13396@WKUVX1.BITNET> To: MX-List@WKUVX1.BITNET In article <00960654.3C37AE60.13396@WKUVX1.BITNET>, Hunter Goatley writes: >"J.C. Higgins, Sys Mgr CsVax1, UCC , Eire" writes: >> >>Is there any way that I can have a copy of mail that is to be 'bounced' >>back to the sender sent to the POSTMASTER. >> >Currently, there's not.... > >>If it is not possible, then what are the chances of having the option >>in the next version.. (You reading this Hunter and Matt :) >> >I think it'd be a useful option to have, and have already planned to >add that sometime. I think that having the ability to have a copy of the HEADERS of all bounced mail forwarded to the POSTMASTER would be a nice feature. However, I don't think the body of the message need be forwarded as well. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Fri, 11 Sep 1992 10:05:22 CDT From: osymh%msu.oscs.montana.edu@MTSUNIX1.BITNET Sender: osymh%msu.oscs.montana.edu@MTSUNIX1.BITNET Date: Thu, 10 Sep 1992 14:09:44 MDT From: "Michael L. Hitch" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096069B.212B9400.21016@trex.oscs.montana.edu> Subject: RE: Username Lengths-Looking for an Explanation "James F. Burnett--University of Texas-PanAm" writes: => We created a new user with a 9 character username. That user logged => in and subscribed to a couple of mailing lists(both very active lists) => and began receiving mail--well, almost began receiving mail. The mail => reached here just fine, but somewhere along the route, the username => was truncated to 8 characters. MX attempted to find the truncated => username here, was unable to do so, generated an error reply, and sent => it back where it came from. ... => I need an explanation of why this is happening. Is it related to => BITNET, INTERNET, MX, all of the above, none of the above, or => what ? I've been aware for quite some time that the length of the => POSTMAST(ER) account has been an issue but never had thought of it in => terms of other usernames. Is there a more convenient way to deal with => the problem than having to remember to limit usernames to 8 or less => characters or defining aliases ? After all, VMS allows 12 character => usernames. We have this kind of problem quite frequently. It is probably caused by the 8 character restriction on BITNET. All files transferred across the BITNET links are limited to 8 characters for the file name, user name, and the node names. If a BITNET site is running a reasonably smart mailer, it can package a mail message up and send it as a BSMTP (Batch Simple Mail Transfer Protocl) file. This BSMTP file has the complete mail address inside the file so nothing gets lost. If a BITNET site is running a mailer that justs sends the mail as a file to a user at the remote node, the destination user name is limited to 8 characters. We are running UREP 3.5 (I think) which will catch an attempt to have a user name longer than 8 characters and return an error message [the error message is mis-leading, since it just says that user name doesn't exist - the urep error log file indicates why]. An earlier version of UREP did not do this, it just truncated the name to 8 characters and sent the file on it's merry way. Part of the problem may be that a BITNET site may not have updated it's mailer tables to know that PANAM.BITNET will accept BSMTP mail and attempts to send the mail file using the user name as the destination user. --- Michael L. Hitch osymh@msu.oscs.montana.edu Computer Consultant OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA ================================================================================ Archive-Date: Fri, 11 Sep 1992 13:24:16 CDT Date: Fri, 11 Sep 1992 19:19:06 EDT From: "J.C. Higgins, Sys Mgr CsVax1, UCC , Eire" Reply-To: MX-List@WKUVX1.BITNET Subject: RE: Trapping bounced mail. To: MX-LIST@WKUVX1.BITNET Message-ID: <0096078F.82C0F580.8133@CSVAX1.UCC.IE> In a previous article, carl@SOL1.GPS.CALTECH.EDU wrote: >Subject: RE: Trapping bounced mail. > >In article <00960654.3C37AE60.13396@WKUVX1.BITNET>, Hunter Goatley > writes: >>"J.C. Higgins, Sys Mgr CsVax1, UCC , Eire" writes: >>> >>>Is there any way that I can have a copy of mail that is to be 'bounced' >>>back to the sender sent to the POSTMASTER. >>> >>Currently, there's not.... >> >I think that having the ability to have a copy of the HEADERS of all bounced >mail forwarded to the POSTMASTER would be a nice feature. However, I don't >think the body of the message need be forwarded as well. >------------------------------------------------------------------------------- - >Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL > No, I think that it would be better to have the whole message forwarded to the POSTMASTER. I know that brings in some ethical problems, (reading someone elses mail), but if the mail was bounced because the sender made some sort of obvious typo on the destination address then the POSTMASTER would be able to forward the message to the user. Or take the case where the message is notification to an account that has been removed from the system, that it has been unsubscribed from a mailing list. Wouldn't it be nice for the POSTMASTER to be able to see that the account has been unsubscribed, and not have to manually unsubcribe the account. (Which has been already removed from the list). Chris. + J.C. Higgins, Sys Admin + If you love something, set it free. If it doesn't + CHRIS@csvax1.ucc.ie + come back to you, hunt it down and KILL it. If + SCCS6002@iruccvax.ucc.ie + that doesn't work, then GIVE UP peacefully. ================================================================================ Archive-Date: Fri, 11 Sep 1992 14:02:17 CDT Date: Fri, 11 Sep 1992 19:55:46 EDT From: "J.C. Higgins, Sys Mgr CsVax1, UCC , Eire" Reply-To: MX-List@WKUVX1.BITNET Subject: RE: Trapping bounced mail. To: MX-LIST@WKUVX1.BITNET Message-ID: <00960794.A203A320.8161@CSVAX1.UCC.IE> In a previous article, carl@SOL1.GPS.CALTECH.EDU wrote: >Subject: RE: Trapping bounced mail. > >In article <00960654.3C37AE60.13396@WKUVX1.BITNET>, Hunter Goatley > writes: >>"J.C. Higgins, Sys Mgr CsVax1, UCC , Eire" writes: >>> >>>Is there any way that I can have a copy of mail that is to be 'bounced' >>>back to the sender sent to the POSTMASTER. >>> >>Currently, there's not.... >> >>>If it is not possible, then what are the chances of having the option >>>in the next version.. (You reading this Hunter and Matt :) >>> >>I think it'd be a useful option to have, and have already planned to >>add that sometime. > >I think that having the ability to have a copy of the HEADERS of all bounced >mail forwarded to the POSTMASTER would be a nice feature. However, I don't >think the body of the message need be forwarded as well. >------------------------------------------------------------------------------- - >Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL > No, I think that it would be better to have the whole message forwarded to the POSTMASTER. I know that brings in some ethical problems, (reading someone elses mail), but if the mail was bounced because the sender made some sort of obvious typo on the destination address then the POSTMASTER would be able to forward the message to the user. Or take the case where the message is notification to an account that has been removed from the system, that it has been unsubscribed from a mailing list. Wouldn't it be nice for the POSTMASTER to be able to see that the account has been unsubscribed, and not have to manually unsubcribe the account. (Which has been already removed from the list). Chris. + J.C. Higgins, Sys Admin + If you love something, set it free. If it doesn't + CHRIS@csvax1.ucc.ie + come back to you, hunt it down and KILL it. If + SCCS6002@iruccvax.ucc.ie + that doesn't work, then GIVE UP peacefully. ================================================================================ Archive-Date: Sun, 13 Sep 1992 18:08:51 CDT Sender: ault@max.queens.edu Date: Sun, 13 Sep 1992 19:05:08 EDT From: Richard Ault Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: ault@max.queens.edu Message-ID: <0096091F.E4735C00.12104@max.queens.edu> Subject: Setting host names for Sender and Return path Is there any way to get MX 3.1c to set Return Path and Sender host names to something other than the local host FQDN? I have set MX_VMSMAIL_REPLY and the like so that my From and Reply to headers refer to me as @queens.edu, but the Return Path and Sender still use @host.queens.edu. I want to be able to get certain recalcitrant listserv's (info-vax and lanworks, to name two) to send to me @queens.edu. My local host name is not going to be stable in the next few months, but @queens.edu will always be valid (at least as long as I'm here, since it's my baliwick). We're a relatively new Internet site and I'd like to get some way of doing subscriptions that won't use local host names before turning our users loose and having to re-subscribe the world when we change host names. Note that we don't have a local DNS so I can't diddle DNS settings at will. Thanks ----------------------------------------------------------------------- Richard H. Ault, Computing Services Center ault@queens.edu Queens College, 1900 Selwyn Ave ault@alumni.caltech.edu Charlotte, NC 28274-0001 (704) 337-2303 ================================================================================ Archive-Date: Mon, 14 Sep 1992 06:01:17 CDT Date: Mon, 14 Sep 1992 11:45:03 EDT From: "J.C. Higgins, Sys Mgr CsVax1, UCC , Eire" Reply-To: MX-List@WKUVX1.BITNET Subject: RE: Setting host names for Sender and Return path To: MX-LIST@WKUVX1.BITNET Message-ID: <009609AB.94341FE0.9195@CSVAX1.UCC.IE> In a previous article, wrote: >Subject: Setting host names for Sender and Return path > >I want to be able to get certain recalcitrant listserv's (info-vax and >lanworks, to name two) to send to me @queens.edu. My local host name is not >going to be stable in the next few months, but @queens.edu will always be valid >(at least as long as I'm here, since it's my baliwick). We're a relatively new >Internet site and I'd like to get some way of doing subscriptions that won't >use local host names before turning our users loose and having to re-subscribe >the world when we change host names. Note that we don't have a local DNS so I >can't diddle DNS settings at will. > >Thanks >----------------------------------------------------------------------- >Richard H. Ault, Computing Services Center ault@queens.edu >Queens College, 1900 Selwyn Ave ault@alumni.caltech.edu >Charlotte, NC 28274-0001 (704) 337-2303 I can think of two possible things you could do. 1. Presumably all mail is routed through QUEENS.EDU, you could change the rewrite rules there on mail messages. So that @host.queens.edu becomes @queens.edu 2. Use MLFAKE to do the subscriptions to whatever lists you want to subscribe to. The first one would do the job, if @queens.edu has some way of knowing which local host you are on, or if you have an account on it. I get the impression from your message, that you want EVERYONE on the local hosts to have a return address @queens.edu, if this is so, then this would seem to be your only option. If you only want to do it for certain users, or certain lists. then it might be easier/better to ue MLFAKE. Of course I could be wrong. It is early in the morning. (Well, relatively) :) Chris. + J.C. Higgins, Sys Admin + If you love something, set it free. If it doesn't + CHRIS@csvax1.ucc.ie + come back to you, hunt it down and KILL it. If + SCCS6002@iruccvax.ucc.ie + that doesn't work, then GIVE UP peacefully. ================================================================================ Archive-Date: Mon, 14 Sep 1992 09:51:50 CDT Date: Sat, 12 Sep 1992 13:56:20 PDT From: "W. Todd Wipke" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@RPIECSVX.BITNET Message-ID: <0096082B.96C1D620.24214@SECS.UCSC.EDU> Subject: Access violations mx 3.1 I have had SMTP Server, MX Smtp, and MX Router dying on one node. With image accounting I observed Router died due to access violation after running 27 minutes. I can't find any debug logs that indicate anything special was happening at that time. I noticed some tmp msgs in the MLF directory like: MX_ROOT:[000000.MLF]FSV_E32F8A60_009606FB_21601B2D.TMP;1 Command: SENDME INSTR.TEX* File INSTR.TEX_PSFONTS has been sent. Error sending INSTR.TEX_SAMPLE: assign channel system service request failed I am wondering if creating a new queue might be worth a try, other than that, what? wipke@secs.ucsc.edu ================================================================================ Archive-Date: Mon, 14 Sep 1992 11:35:19 CDT Date: Mon, 14 Sep 1992 09:30:50 PDT From: "Bob Johns, (604)363-6520" Reply-To: MX-List@WKUVX1.BITNET To: MX-List%wkuvx1.BITNET@cunyvm.cuny.edu Message-ID: <00960998.D4193860.16812@ccs.ios.bc.ca> Subject: RE: Trapping bounced mail. The key thing I would like to see, if this "forward to POSTMASTER" should be implemented, is to have it configurable. I don't have the resources to intervene, so want a fully automatic "black box". I would disable this feature for our site. ------------------------------------------------------------------------ | Bob Johns | | | Manager, Central Systems & Networks | Internet: bob@ios.bc.ca | | Scientific Computing | | | Institute of Ocean Sciences | Tel : (604)363-6520 | | 9860 West Saanich Rd., Sidney, B.C. | FAX : (604)363-6390 | | Canada V8L 4B2 | | ------------------------------------------------------------------------ ================================================================================ Archive-Date: Mon, 14 Sep 1992 11:39:31 CDT Date: Mon, 14 Sep 1992 11:34:13 CDT From: Larry Horn Reply-To: MX-List@WKUVX1.BITNET To: Info-VAX@sri.com CC: MX-List@WKUVX1.BITNET Message-ID: <009609AA.11092260.15850@okra.millsaps.edu> Subject: Re: setting up news at mixed Ultrix/VMS site Thanks to all of you who replied to my query. Since most, if not all, of the information was posted as replies to the lists or covered in other traffic, I won't summarize at this time. I'd hoped to have something substantial to report by now, but other projects have consumed my time. Once I can get back on this project, I'll post, as requested, a summary of my experiences. - ---------------------------------- signed: 14-SEP-1992 11:33 C*T (USA) --- - Larry Horn / Millsaps College / Jackson, MS / hornlo@okra.millsaps.edu - -------------------------------------------------------------------------- - ================================================================================ Archive-Date: Mon, 14 Sep 1992 11:40:56 CDT Sender: goathunter@WKUVX1.BITNET Date: Mon, 14 Sep 1992 11:39:17 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <009609AA.C5A7D7C0.14617@WKUVX1.BITNET> Subject: RE: Trapping bounced mail. "Bob Johns, (604)363-6520" writes: > >The key thing I would like to see, if this "forward to POSTMASTER" should >be implemented, is to have it configurable. I don't have the resources >to intervene, so want a fully automatic "black box". I would disable >this feature for our site. > If/when I do it, it'll be completely optional and you'll be able to specify whether or not the message body should be included in bounced mail. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Mon, 14 Sep 1992 11:52:37 CDT Sender: ebates@uop.edu Date: Mon, 14 Sep 1992 09:36:47 PDT From: Ed Bates Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00960999.A9433A40.5671@vms1.cc.uop.edu> Subject: RE: Setting host names for Sender and Return path "J.C. Higgins, Sys Mgr CsVax1, UCC , Eire" wrote: >In a previous article, wrote: >>Subject: Setting host names for Sender and Return path >> >>I want to be able to get certain recalcitrant listserv's (info-vax and >>lanworks, to name two) to send to me @queens.edu. My local host name is not >>going to be stable in the next few months, but @queens.edu will always be valid >>(at least as long as I'm here, since it's my baliwick). We're a relatively new >>Internet site and I'd like to get some way of doing subscriptions that won't >>use local host names before turning our users loose and having to re-subscribe >>the world when we change host names. Note that we don't have a local DNS so I >>can't diddle DNS settings at will. >> >>Thanks >>----------------------------------------------------------------------- >>Richard H. Ault, Computing Services Center ault@queens.edu >>Queens College, 1900 Selwyn Ave ault@alumni.caltech.edu >>Charlotte, NC 28274-0001 (704) 337-2303 > >I can think of two possible things you could do. >1. Presumably all mail is routed through QUEENS.EDU, you could change the > rewrite rules there on mail messages. So that @host.queens.edu becomes > @queens.edu >2. Use MLFAKE to do the subscriptions to whatever lists you want to subscribe > to. We had desired to do the same thing, Richard. The way we did it, though the documentation discourages it, is by changing the MX_VMSMAIL_LOCALHOST logical in MX_LOGICALS.DAT. In our case, the local computer is VMS1.CC.UOP.EDU. Defining the logical to "@uop.edu" caused all messages from the local computer to appear to be from UOP.EDU. If there is a better way, I would like to know about it... -- Ed - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Edwin J. (Ed) Bates VAX Administrator/Postmaster . . _ _ Technical Support Specialist Internet: ebates@uop.edu | | / \ | \ Office of Computing Services AppleLink: U1441 | | | | |_/ University of the Pacific Telephone: (209) 946-2251 | | | | | Stockton, CA 95211 Fax: (209) 946-2898 \_/ \_/ | %MAIL-W-NOFNCYQTE, no fancy quote or joke found in signature file ================================================================================ Archive-Date: Wed, 16 Sep 1992 03:53:33 CDT Date: Tue, 15 Sep 1992 17:40:37 EDT From: Shakil Khan Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: khan@QCVAXA.BITNET Message-ID: <00960AA6.6A82BC00.11299@qcvaxa.acc.qc.edu> Subject: signon SIGNON MX-LIST ================================================================================ Archive-Date: Wed, 16 Sep 1992 04:01:27 CDT Date: Mon, 14 Sep 1992 19:43:17 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: madison@tgv.com CC: mx-list@WKUVX1.BITNET Message-ID: <009609EE.63679E80.29883@swdev.si.com> Subject: Re: MCP access violates Matt Madison (madison@tgv.com) writes: >Because adding support in the queue entry structures requires a recompile >of all the MX source code, the last time I added some I added fields to >handle all of the additional delivery mechanisms I was considering at the >time. I never did any work on an X.400 agent, though. It sure would be nice to see one added (Hunter? Consider this a hint). -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Wed, 16 Sep 1992 09:06:07 CDT Sender: sysback@MARYWOOD1.MARYWOOD.EDU Date: Wed, 16 Sep 1992 09:59:39 EDT From: sysback@MARYWOOD1.MARYWOOD.EDU Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00960B2F.2F588FE0.909@MARYWOOD1.MARYWOOD.EDU> Subject: subscribe please add my name to the MX mailing list. thank you Anthony Spinillo - Tech Services Marywood College 717 348 6215 Scranton, PA 19509 spinillo@marywood1.marywood.edu ================================================================================ Archive-Date: Wed, 16 Sep 1992 09:38:56 CDT From: Subject: MX on OpenVMS Alpha ? Message-ID: <1992Sep16.132755.14748@aragorn.unibe.ch> Sender: news@aragorn.unibe.ch Reply-To: MX-List@WKUVX1.BITNET Date: Wed, 16 Sep 1992 13:27:55 GMT To: MX-List@WKUVX1.BITNET Hi, has anybody looked into the MX code (BLISS) for a possible conversion to OpenVMS Alpha BLISS? We hope to get Alpha machines next spring, will there be any available MX version? Thanks, Martin ******************************************************************************* Martin Egger, Ph.D., Computing Services - System and User Support Group University of Bern, P.O. Box, Laenggassstrasse 51, CH-3012 Bern, Switzerland Phone: ++41 (0)31 65 38 45, Fax: ++41 (0)31 65 38 65, Telex: 753 112 unib ch RFC: egger@id.unibe.ch, X.400: S=egger;OU=id;O=unibe;P=switch;A=arcom;C=ch; HEPNET/SPAN: 20579::49203::egger, DECnet (Switzerland): 49203::egger ******************************************************************************* ================================================================================ Archive-Date: Wed, 16 Sep 1992 09:49:53 CDT Date: Wed, 16 Sep 1992 07:47:55 MDT From: "Mark geib@vistanm.com" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: geib@vistanm.com Message-ID: <00960B1C.C92C1E60.929@vistanm.com> Subject: upgrading from MX 2.3 I have just got MX running pretty well having received it with the most current release of CMU-TEK. The version of MX is 2.3. What is the best source for getting an update kit to the current version. Thanks, Mark Geib Vista Control Systems, Inc. Los Alamos, NM ================================================================================ Archive-Date: Wed, 16 Sep 1992 10:33:02 CDT Sender: spinillo@MARYWOOD1.MARYWOOD.EDU Date: Wed, 16 Sep 1992 11:25:01 EDT From: spinillo@MARYWOOD1.MARYWOOD.EDU Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00960B3B.1CF395A0.984@MARYWOOD1.MARYWOOD.EDU> Subject: PROHIBITING ACCESS TO MX IS THERE AN EASY WAY TO SELECTIVELY PREVENT USERS FROM ACCESSING MX? AT THIS TIME FACULTY AND STAFF ARE USING MX BUT I WANT TO RESTRICT STUDENTS TO LOCAL VMS MAIL ONLY. THANKS Anthony Spinillo - Tech Services Marywood College 717 348 6215 Scranton, PA 19509 spinillo@marywood1.marywood.edu ================================================================================ Archive-Date: Wed, 16 Sep 1992 12:47:16 CDT Date: 16 Sep 1992 10:26:00 -0600 (MDT) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: Re: PROHIBITING ACCESS TO MX To: MX-List@WKUVX1.BITNET CC: spinillo@marywood1.marywood.edu Message-ID: <01GOUKC96WWI0000CG@VAXF.COLORADO.EDU> Anthony Spinillo, spinillo@marywood1.marywood.edu, writes: >IS THERE AN EASY WAY TO SELECTIVELY PREVENT USERS FROM ACCESSING MX? >AT THIS TIME FACULTY AND STAFF ARE USING MX BUT I WANT TO RESTRICT >STUDENTS TO LOCAL VMS MAIL ONLY. (Wow - all uppercase!) $ SET DEFAULT SYS$SYSTEM $ MCR AUTHORIZE UAF> ADD/ID MX_ACCESS UAF> GRANT/ID MX_ACCESS username UAF> GRANT/ID MX_ACCESS username ... UAF> GRANT/ID MX_ACCESS username UAF> EXIT $ SET PROTECTION=W MX_MAILSHR $ SET ACL/ACL=(IDENTIFIER=MX_ACCESS,ACCESS=READ+EXECUTE) MX_MAILSHR If you already have a FACULTY or STAFF identifier, or if they're already all in the same (or in a few) UIC group, you could forgo creating (and maintaining) another identifier. Of course, you'll get a security alarm every time someone tries to access MX_MAILSHR, so you can go after those nasty students. Minor flame: As a former student at a University that restricted BITNET access to students, I hope that you've closely examined your reasons for restricting access. Flame off (before I get carried away). -Dan Wing, DWING@UH01.Colorado.EDU or WING_D@UCOLMCC.BITNET (DGW11) Systems Programmer, University Hospital, Denver ================================================================================ Archive-Date: Wed, 16 Sep 1992 13:08:54 CDT Sender: spinillo@MARYWOOD1.MARYWOOD.EDU Date: Wed, 16 Sep 1992 13:57:59 EDT From: spinillo@MARYWOOD1.MARYWOOD.EDU Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00960B50.7B3D42E0.1114@MARYWOOD1.MARYWOOD.EDU> Subject: PROHIBITING ACCESS TO MX Thanks for everbody's help on my problem. I am implementing the suggestions now. tony Anthony Spinillo - Tech Services Marywood College 717 348 6215 Scranton, PA 19509 spinillo@marywood1.marywood.edu ================================================================================ Archive-Date: Wed, 16 Sep 1992 13:09:10 CDT Date: Wed, 16 Sep 1992 09:39:54 PDT From: "John F. Sandhoff" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: spinillo@marywood1.marywood.edu, syssand@CCVAX.CCS.CSUS.EDU Message-ID: <00960B2C.6D58C880.30489@CCVAX.CCS.CSUS.EDU> Subject: RE: PROHIBITING ACCESS TO MX > Is there an easy way to selectively prevent users from accessing MX? One crude way would be to set an ACL on an important file (MX_MAILSHR perhaps, or maybe the queue file or entire directory). For instance, create an identifier 'mx_user' and set the ACL to grant access permission to holders of this identifier. Then assign the identifier to all authorized accounts. Those not authorized will get a nasty error message, but they won't get to run MX either... John F. Sandhoff, University Network Support California State University, Sacramento - USA sandhoff@csus.edu ================================================================================ Archive-Date: Wed, 16 Sep 1992 16:00:21 CDT Date: Wed, 16 Sep 1992 15:45:54 CDT From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00960B5F.8E89E9C0.30063@SHSU.edu> Subject: RE: PROHIBITING ACCESS TO MX On Wed, 16 Sep 1992 11:25:01 EDT, Anthony Spinillo posted: > IS THERE AN EASY WAY TO SELECTIVELY PREVENT USERS FROM ACCESSING MX? AT > THIS TIME FACULTY AND STAFF ARE USING MX BUT I WANT TO RESTRICT STUDENTS TO > LOCAL VMS MAIL ONLY. This is a largely irreverant reply as the ACL issue has already been addressed. However, it raises a question which maybe someone could answer. Why would you wish to restrict students from having access? I can understand restricting known abusers, but why take it away from a whole class of users? When we were a BITNET-only site, before we had a mailer, etc. (in the dark ages), usernames gave us problems (as recently discussed). Students, by the design of their usernames at the time, could not be reliably answered (or even report a reliable From: -- the usernames were between 7 and 9 characters). No one here could really think of a justification to disallow use by students and, ultimately, we re-designed student usernames so that they were between 6 and the magic 8 characters. This is largely irrelevant at our site now that we use MX and we have added Internet to BITNET for network options (but the username of not more than 8 still comes in handy for interactive messages, file requests, etc., on BITNET). Our site is still somewhat unique in that we don't run accounting against users, funny money is unheard of, and the goal of our Computer Services really seems to be one aimed at meeting whatever demands it faces, but.... If a university is around to service students, why would it knowingly take away one of the more dynamic communications options available to them, especially when the school is already connected (and with a mailer as nice as MX to boot!)? I'm neither questioning nor flaming anyone's local policy options; I'd really like to know! In wonderment, 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, 16 Sep 1992 16:54:07 CDT Date: Wed, 16 Sep 1992 17:09:59 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: spinillo@marywood1.marywood.edu CC: mx-list@WKUVX1.BITNET Message-ID: <00960B6B.4D702600.32691@swdev.si.com> Subject: RE: PROHIBITING ACCESS TO MX Anthony Spinillo (spinillo@marywood1.marywood.edu) writes: >IS THERE AN EASY WAY TO SELECTIVELY PREVENT USERS FROM ACCESSING MX? >AT THIS TIME FACULTY AND STAFF ARE USING MX BUT I WANT TO RESTRICT >STUDENTS TO LOCAL VMS MAIL ONLY. You could grant faculty and staff a rights identifier, say, MX_ACCESS. Place this identifier on MX_MAILSHR prior to INSTALLing it. Then, anyone without the identifier will receive a privilege violation if they try to use it. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Wed, 16 Sep 1992 18:08:32 CDT Sender: "cvse::mckeetr"@CORTEX.PROSPECT.COM Date: Wed, 16 Sep 1992 18:49:18 EDT From: "Tim McKee, 803-366-2620" <"cvse::mckeetr"@CORTEX.PROSPECT.COM> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00960B79.2D551F20.8371@CORTEX.PROSPECT.COM> Subject: FWD: CONFIGURATION FOR A NEWCOMER My apologies if this question seems elementary, but I have just started using MX and currently know little outside of VAX/VMS and DECNET. I need to set up a distributed network configuration as follows: NODE: INTNET is the bridge between our WAN and INTERNET. CVSE is a remote 'part-time' member of the DECNET WAN. It dials up a connection and expects to have messages downloaded to it. By itself, this is not a problem. SNM is another remote 'part-time' member of the DECNET WAN. It dials up a connection to the CVSE member and expects to have its messages downloaded from there. The connection from CVSE to INTNET may not (most likely WILL not) coincide with it. The CVSE node must function as a store and forward router. Messages from INTNET to SNM must be transferred to CVSE for further forwarding and vice- versa. Nodes CVSE and SNM have MX installed with LOCAL transport only. I have read the manual and haven't seen any obvious references to forcing message travel from one MX to another. Is MX capable of doing this and if so, what would the address syntax be to go from INTNET to SNM via CVSE? Should the configuration be changed? ================================================================================ Archive-Date: Wed, 16 Sep 1992 19:44:38 CDT Date: Wed, 16 Sep 1992 16:00:34 MDT From: "Mark geib@vistanm.com" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: geib@vistanm.com Message-ID: <00960B61.9AEDB000.973@vistanm.com> Subject: FWD: Problem with addresses. After getting MX up I have had two users report the same problem. They both were replying to Email addresses of the form user@site.bitnet, the mail failed with the following message: _______________________________________________________________________________ From: MX%"postmaster@uunet.ca" 5-SEP-1992 04:20:44.21 To: CLOUT CC: Subj: Invalid message envelope information Return-Path: Received: by vistanm.com (MX V2.3-1) with UUCP; Sat, 05 Sep 1992 04:20:39 MDT Received: from mail.uunet.ca (via uunet.ca) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA23674; Sat, 5 Sep 92 06:17:36 -0400 Received: by mail.uunet.ca id <10410>; Sat, 5 Sep 1992 06:17:28 -0400 To: clout@vistanm.com From: The Post Office Sender: mailer-daemon@uunet.ca Subject: Invalid message envelope information CC: The Post Office Message-ID: <92Sep5.061728edt.10410@mail.uunet.ca> Date: Sat, 5 Sep 1992 06:17:13 -0400 The following message arrived with illegal envelope data, typically a mangled address that doesn't obey the RFC822/976 protocol specification. If you do not recognize the source of the bad header, perhaps you should contact a Postmaster at your site and ask why your mail was rejected. Your message is being returned unprocessed. The following annotated envelope headers illustrate the error(s): Error in "from" envelope address: ^-illegal word in localpart The entire original message file follows. ----------------------------------------- external rcvdfrom relay2.UU.NET ([137.39.1.7]) with SMTP from to Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA05623; Sat, 5 Sep 92 06:17:09 -0400 Received: from vistanm.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 061621.22953; Sat, 5 Sep 1992 06:16:21 EDT Received: by vistanm.com (DECUS UUCP /1.3-1/2.5/); Fri, 4 Sep 92 17:15:23 MDT Received: by vistanm.com (MX V2.3-1) id 540; Fri, 04 Sep 1992 17:15:18 MDT Date: Fri, 04 Sep 1992 17:15:18 MDT From: clout@vistanm.com To: EPCS@CERNVM.BITNET Cc: clout@vistanm.com Message-Id: <009601FE.0F067200.540@vistanm.com> Subject: RE: 11th EPCS Boardmeeting ________________________________________________________________________________ In fact, I have found that I can not reply to this mail list address which includes the MX%. To get the mail to go I have to use UUCP% rather than MX. All other addresses work fine. All non-local mail goes through UUCP. Any ideas ?? Mark Geib ================================================================================ Archive-Date: Thu, 17 Sep 1992 10:04:21 CDT Date: Thu, 17 Sep 1992 09:12:37 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00960BF1.C7F8E5C0.471@swdev.si.com> Subject: Enticing DEBUG information from MX In order to see debug information in MX, I realize I need to define the MX_*_DEBUG logical names. My question is, once I define these names, must I restart MX to get them to take effect? This leads to a second question: if debug information logging is active, can I turn it off by simply deassigning the debug logicals, or must I shut MX down for it to take effect? -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 17 Sep 1992 10:46:50 CDT Sender: goathunter@WKUVX1.BITNET Date: Thu, 17 Sep 1992 10:46:29 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00960BFE.E518B9C0.15973@WKUVX1.BITNET> Subject: RE: Enticing DEBUG information from MX "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: > >In order to see debug information in MX, I realize I need to define the >MX_*_DEBUG logical names. My question is, once I define these names, must I >restart MX to get them to take effect? This leads to a second question: if >debug information logging is active, can I turn it off by simply deassigning the >debug logicals, or must I shut MX down for it to take effect? > Just define them and deassign them---no starting or stopping of MX is required. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Thu, 17 Sep 1992 11:55:09 CDT Message-ID: <00960C02.7BCB7E40.9206@uwwvax.uww.edu> Date: Thu, 17 Sep 1992 11:12:11 CDT From: hunterl@uwwvax.uww.edu Reply-To: MX-List@WKUVX1.BITNET Subject: Re: Enticing DEBUG information from MX To: MX-List@WKUVX1.BITNET => In order to see debug information in MX, I realize I need to define the => MX_*_DEBUG logical names. My question is, once I define these names, must I => restart MX to get them to take effect? This leads to a second question: if => debug information logging is active, can I turn it off by simply deassigning the => debug logicals, or must I shut MX down for it to take effect? => No they take effect now. Deassigning works for me. Lyle Hunter Computer Center University Wisconsin-Whitewater hunterl@uwwvax.uww.edu ================================================================================ Archive-Date: Thu, 17 Sep 1992 12:39:52 CDT Date: Thu, 17 Sep 1992 11:32:31 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00960C05.53650EA0.551@swdev.si.com> Subject: Rewrite rules I'd like to get something straight in my own mind that, so far, has eluded me. Does MX apply rewrite rules only on outbound messages, or does it also apply them to inbound messages? I've been able to successfully rewrite outbound addresses, but inbound addresses don't seem to be affected. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 17 Sep 1992 12:46:02 CDT Date: Thu, 17 Sep 1992 10:36:33 PDT From: "W. Todd Wipke" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@RPIECSVX.BITNET Message-ID: <00960BFD.81BEE080.523@SECS.UCSC.EDU> Subject: What logicals can be defined in logicals.dat? I have a problem. I have 7 vaxes, 2 of which are at 5.3-1 and the remainder at 5.5 vms. I have one common queue, and would like one mx_root area so accounting and debug and log info and mailing list, fileserver stuff is in one place. The difficulty is mx_exe and the two versions of vms. It appears to work with the 5.5 systems executing 5.3 linked exe's, but not vice versa. Wondered if anyone else has solved that. I could let there be two mx_exe's, but all other logicals point to a common area by defining them in mx_logicals.dat carefully? Todd Wipke University of California Santa Cruz (home of the award winning mascot, the Banana Slug) ================================================================================ Archive-Date: Thu, 17 Sep 1992 14:54:56 CDT Date: Thu, 17 Sep 1992 13:22:19 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00960C14.A9D842C0.631@swdev.si.com> Subject: Agent accounting I have accounting enabled on my LOCAL and SMTP MX agents. They append to the MX_*_DIR:MX_*_ACC.DAT files. How can I get MX to create new versions of these files so I can analyze and archive older data? Do I need to shut MX down? -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 17 Sep 1992 15:39:05 CDT Subject: Re: FWD: Problem with addresses. Message-ID: <1992Sep17.130127.4548@dmc.com> From: Reply-To: MX-List@WKUVX1.BITNET Date: 17 Sep 92 13:01:27 EDT References: <00960B61.9AEDB000.973@vistanm.com> To: MX-List@WKUVX1.BITNET In article <00960B61.9AEDB000.973@vistanm.com>, "Mark geib@vistanm.com" writes: > Any ideas ?? > > Mark Geib Mark, This is actually a bug in the UUCP/MX interface, I forget exactly where. What you should do is: 1. Upgrade to MX 3.1C as soon as is reasonable and 2. Upgrade to DECUS UUCP V2.0 ditto and the problem will go away. -- Dick Munroe Internet: munroe@dmc.com Doyle Munroe Consultants, Inc. UUCP: ...uunet!thehulk!munroe 267 Cox St. Office: (508) 568-1618 Hudson, Ma. FAX: (508) 562-1133 GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection. ================================================================================ Archive-Date: Thu, 17 Sep 1992 17:09:45 CDT Sender: goathunter@WKUVX1.BITNET Date: Thu, 17 Sep 1992 17:04:31 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00960C33.B4453BE0.16153@WKUVX1.BITNET> Subject: RE: MX on OpenVMS Alpha ? writes: > >has anybody looked into the MX code (BLISS) for a possible conversion to >OpenVMS Alpha BLISS? We hope to get Alpha machines next spring, will there >be any available MX version? > I hope so. I've looked into it some. The biggest problem is that MX uses LIB$TPARSE a *whole* lot, and LIB$TPARSE doesn't exist under OpenVMS Alpha. There is a comparable routine, though, so it may just be a matter of changing those calls. As far as I can tell, nothing else in MX is so VAX specific that it won't work under Alpha. Of course, I haven't really tried to compile it yet, so.... That is definitely a goal of mine by next spring, though. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Thu, 17 Sep 1992 17:09:57 CDT Sender: goathunter@WKUVX1.BITNET Date: Thu, 17 Sep 1992 17:06:25 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: geib@vistanm.com CC: mx-list@WKUVX1.BITNET Message-ID: <00960C33.F84168A0.16159@WKUVX1.BITNET> Subject: FWD: upgrading from MX 2.3 "Mark geib@vistanm.com" writes: > >I have just got MX running pretty well having received it with the most current >release of CMU-TEK. The version of MX is 2.3. What is the best source for >getting an update kit to the current version. > You can get it via anonymous ftp from ftp.spc.edu in [.MX]. To get it via e-mail, send the following commands in the body of a mail message to MXSERVER@WKUVX1.BITNET: SEND MX031 SEND FILESERV_TOOLS It's a huge package and, because of BITNET delays, make take a few days for all the pieces to arrive. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Thu, 17 Sep 1992 18:47:18 CDT Date: Thu, 17 Sep 1992 17:18:57 CDT From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: tillman@swdev.si.com Message-ID: <00960C35.B8C02AC0.1142@SHSU.edu> Subject: RE: Agent accounting On Thu, 17 Sep 1992 13:22:19 EDT, "Brian Tillman" asked: > I have accounting enabled on my LOCAL and SMTP MX agents. They append to > the MX_*_DIR:MX_*_ACC.DAT files. How can I get MX to create new versions > of these files so I can analyze and archive older data? Do I need to shut > MX down? Use: $ MCP RESET SMTP/ACCOUNTING[/CLUSTER] $ MCP RESET LOCAL/ACCOUNTING[/CLUSTER] See pp. MCP-35--MCP-36 (in the 3.1B distribution set, the C set may differ slightly -- yeah, we're gonna update someday) in MX_DOC:MGMT_GUIDE.TXT for details. 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: Thu, 17 Sep 1992 23:02:43 CDT Date: Thu, 17 Sep 1992 10:10:15 EDT From: Shakil Khan Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00960BF9.D4F9C7A0.17572@qcvaxa.acc.qc.edu> Hi, I have many users who have registered different mailing-lists and receive hundreds of files every day. Recently, over the Labor day week end, SMTP server and couple of other MX processes stopped working. Hundreds of messages were back logged. At the restart of MX and the Jnet interface, there are still many messages dated sep6-8, which have not been delivered. 1) How can these be delivered? 2) The counter of the messages is being repeated, For example, 12050.MSG-text;1 3block 7-sep-1992 12050.MSG-text;2 22block 16-sep-1992 Any work around. Can I just purge the [mx.queue] directory? 3) I have compressed the index-file called SYSTEM_QUEUE.FLQ_CTL. However, many old messages are still in the [mx.queue] directory. Configuration: MX V3.1C Mx router mx local mx mlf mx smtp smtp server mx jnet intfc Jnet V3.5, router v5.10, jcp v2.10 shakil khan systems administrator queens college, city univ of ny ================================================================================ Archive-Date: Sat, 19 Sep 1992 03:12:12 CDT Date: Fri, 18 Sep 1992 10:15:55 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: khan@QCVAXA.BITNET CC: mx-list@WKUVX1.BITNET Message-ID: <00960CC3.CB105680.1469@swdev.si.com> Subject: RE: MX queue piled up. Shakil Khan (khan@QCVAXA.BITNET) writes: >I have many users who have registered different mailing-lists and receive >hundreds of files every day. Recently, over the Labor day week end, SMTP >server and couple of other MX processes stopped working. Hundreds of messages >were back logged. At the restart of MX and the Jnet interface, there are >still many messages dated sep6-8, which have not been delivered. The exact thing happened to us this past weekend. Once we restarted MX, it began to deliver the mail again, but very slowly. We had about 2,500 messages waiting to be delivered. We saw the duplicate .MSG_TEXT files as well. What I did was to just let MX process messages for the rest of the day (slowly!) and then, that evening, I stopped MX, compressed the SYSTEM_QUEUE.FLQ_CTL file, and recreated the [MX.QUEUE] directory by creating a [.QUEUE1] directory, renaming the [.QUEUE] files to [.QUEUE1], deleting QUEUE.DIR, and renaming QUEUE1.DIR to QUEUE.DIR. Compressing the queue file is only half the battle. Much of the slowness was the result of RMS' handling of directories whose used size is over 128 blocks. There is a well-known (to many) problem with directories that large. The directory cache for any one directory is only 512 blocks. When directories are less that 128 blocks in size, VMS can fit location information for all files in the cache. Once the directory exceeds 128 blocks, the caching information needs to be truncated and more sequential searches of the directory on disk must be performed in order to locate the files to be accessed. This really hurts performance as the directory grows larger. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Sat, 19 Sep 1992 03:21:42 CDT Sender: sysmail@MNSMC1 Date: Fri, 18 Sep 1992 11:32:46 CDT From: sysmail@MNSMC1.MNSMC.EDU Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00960CCE.8640FA40.14674@MNSMC1> Subject: send error: conn net object rej I cannot send mail to one host. This host is unique in having a MX record in our network domain records which redirects mail to another mail receiver, in this case to a charon gateway. It seems that MX is attempting to send to the host without checking the network records. Can MX be directed to verify the domain records of the host before sending? Here is the bounced error message: Thanks for any help, Dan. =============================================================== From: MX%"Postmaster@MNSMC1" 17-SEP-1992 07:05:53.97 To: SYSTEM CC: Subj: SMTP delivery error Return-Path: <> Date: Thu, 17 Sep 1992 07:05:50 CDT From: SMTP delivery agent To: Subject: SMTP delivery error Note: this message was generated automatically. A problem occurred during SMTP delivery of your message. Error occurred sending to the following user(s): (via REX.MNSMC.EDU): %MX-F-RETRYEXCD, retry count exceeded -SYSTEM-F-REJECT, connect to network object rejected ================================================================================ Archive-Date: Sat, 19 Sep 1992 05:37:21 CDT Date: Fri, 18 Sep 1992 23:58:07 PDT From: RON WELKER Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: welker@gtewd.mtv.gsc.gte.com Message-ID: <00960D36.A6800040.7436@GTEWD> Subject: Problem with MX and a Macintosh mail program I'm having a problem sending mail from a Macintosh running a shareware program named LeeMail V1.2.4 and MX 3.1C. When the Mac sends mail, once connected to the target machine, it only sends the username portion of the address and leaves off the @HOST.DOMAIN portion. MX doesn't accept it, although U*ix systems do. I made several attemps at setting up rewrite rules to no avail. It seemed that an appropriate rewrite rule would be <{user}> => <{user}@host.domain> (where host.domain is the fully qualified domain name) and that didn't work. I fiddled a bit with paths, but nothing there seemed to work either. Does anyone know how to deal with this? It's probably a simple problem, but I'm new to all this, and the solution escapes me. Ron Welker (415) 966-2900 Internet: US Mail: welker@gtewd.mtv.gsc.gte.com 100 Ferguson Dr. M/S 5G09 welker@ns2.mtv.gsc.gte.com Mt. View, CA 94039 ================================================================================ Archive-Date: Sat, 19 Sep 1992 08:06:15 CDT Date: Sat, 19 Sep 1992 08:59:31 EDT From: ANIL KHULLAR Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00960D82.480D5016.23321@cunyvms1.gc.cuny.edu> Subject: RE: send error: conn net object rej From DNS records it seems that host REX has both an A record and MX pointing to host SAM. I assume that SAM is the Charon gateway. From my understanding of Charon-Gateway system, I'd assume that REX is a Novell-Netware host ? If so then remove the A record and let SAM to the translation or rewrite rule to deliver mail to REX. We run Charon here too; However, our VMS host does all the rewrite rules and passes it on to the gateway. anil PS: If you need specifics of our set-up send me mail directly at anil@eleni.gc.cuny.edu sysmail@MNSMC1.MNSMC.EDU writes > I cannot send mail to one host. This host is unique in > having a MX record in our network domain records which > redirects mail to another mail receiver, in this case > to a charon gateway. It seems that MX is attempting to > send to the host without checking the network records. > > Can MX be directed to verify the domain records of the > host before sending? > > Here is the bounced error message: > > Thanks for any help, Dan. > =============================================================== > > From: MX%"Postmaster@MNSMC1" 17-SEP-1992 07:05:53.97 > To: SYSTEM > CC: > Subj: SMTP delivery error > > Return-Path: <> > Date: Thu, 17 Sep 1992 07:05:50 CDT > From: SMTP delivery agent > To: > Subject: SMTP delivery error > > Note: this message was generated automatically. > > A problem occurred during SMTP delivery of your message. > > Error occurred sending to the following user(s): > (via REX.MNSMC.EDU): > %MX-F-RETRYEXCD, retry count exceeded > -SYSTEM-F-REJECT, connect to network object rejected > ================================================================================ Archive-Date: Mon, 21 Sep 1992 11:34:51 CDT Date: Mon, 21 Sep 1992 10:28:42 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00960F21.12CF20A0.2631@swdev.si.com> Subject: Where are the MX errors documented? This time, I read the manuals before I posted this message. I was unable to locate the answers on my own. Those of you who find my asking to be a waste of their time, please disregard this message and don't further waste your time by responding. If there is anyone who doesn't fit this description, I'd appreciate it if you could help me. Where are the MX errors MAILQUEUE or MCP QUEUE SHOW displays documented. For example, right now, I have IN-PROGRESS messages that show one or the other of the following messages: Last error: %SYSTEM-F-TIMEOUT, device timeout Last error: %MX-E-PROTOERR, protocol error? How do I determine whether this is an MX problem or a problem on the destination system? What does each of these messages mean? What other errors are possible, and what can I do about them if I see them? If there is a file somewhere that describes the messages, their meanings, and what I can do about them, please point me to it. Thanks. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Mon, 21 Sep 1992 15:43:21 CDT From: Subject: Re: Where are the MX errors documented? Message-ID: <1992Sep21.174407.4374@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <00960F21.12CF20A0.2631@swdev.si.com> Date: Mon, 21 Sep 1992 17:44:07 GMT To: MX-List@WKUVX1.BITNET In article <00960F21.12CF20A0.2631@swdev.si.com>, "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: >Where are the MX errors MAILQUEUE or MCP QUEUE SHOW displays documented. For >example, right now, I have IN-PROGRESS messages that show one or the other of >the following messages: > > Last error: %SYSTEM-F-TIMEOUT, device timeout > Last error: %MX-E-PROTOERR, protocol error? They aren't documented, except in the source code -- and not really there, either. SS$_TIMEOUT is used to indicate that a connection timed out -- i.e., MX was expecting something from the remote SMTP server and nothing arrived within the timeout period (which varies depending on the SMTP command that was sent, but is not less than 5 minutes for most, if not all, commands). MX__PROTOERR is a catch-all error status that indicates an unexpected response from the remote SMTP sender or receiver -- including premature connection termination. Your best bet if mail isn't going through and you can't figure out why is to turn on debugging in the delivery agent you're having trouble with, and look at the trace. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Mon, 21 Sep 1992 18:13:47 CDT Date: Mon, 21 Sep 1992 13:21:58 PDT From: "John F. Sandhoff" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: welker@gtewd.mtv.gsc.gte.com, syssand@CCVAX.CCS.CSUS.EDU Message-ID: <00960F39.4728B100.2433@CCVAX.CCS.CSUS.EDU> Subject: RE: Problem with MX and a Macintosh mail program > I'm having a problem sending mail from a Macintosh running a shareware > program named LeeMail V1.2.4 and MX 3.1C. > > When the Mac sends mail, once connected to the target machine, it > only sends the username portion of the address and leaves off the > @HOST.DOMAIN portion. MX doesn't accept it, although U*ix systems do. This has been discussed in the past and as I recall the answer is that MX is doing the "right thing". A hostname by itself is not valid (per the appropriate RFCs) and MX will reject the initial connection sequence if the domainname is not provided. This is a security feature (though some would argue about the security of SMTP :-) ). The U*ix systems are obeying the 'be liberal' line of thinking, but I'm not sneering at MX - I personally like the fact that it requires some authentication. The author of LeeMail needs to be persuaded to send a complete machine name... John F. Sandhoff, University Network Support California State University, Sacramento - USA sandhoff@csus.edu ================================================================================ Archive-Date: Mon, 21 Sep 1992 23:15:50 CDT Date: Mon, 21 Sep 1992 18:47:38 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: madison@tgv.com CC: mx-list@WKUVX1.BITNET Message-ID: <00960F66.C62B3680.2962@swdev.si.com> Subject: Re: Where are the MX errors documented? Matthew Madison (madison@tgv.com) writes: >They [the possible MX errors reported by MCP or MAILQUEUE] aren't documented, >except in the source code -- and not really there, either. Thanks, Matt. Hunter, any change of adding the documentation of these errors to your wish list? Thanks. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Mon, 21 Sep 1992 23:53:29 CDT Date: Mon, 21 Sep 1992 21:48:24 PDT From: RON WELKER Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: welker@gtewd.mtv.gsc.gte.com Message-ID: <00960F80.06A67080.7783@GTEWD> Subject: RE: Problem with MX and a Macintosh mail program > This has been discussed in the past and as I recall the answer is that > MX is doing the "right thing". A hostname by itself is not valid (per > the appropriate RFCs) and MX will reject the initial connection sequence > if the domainname is not provided. This is a security feature (though some > would argue about the security of SMTP :-) ). The U*ix systems are obeying > the 'be liberal' line of thinking, but I'm not sneering at MX - I personally > like the fact that it requires some authentication. > > The author of LeeMail needs to be persuaded to send a complete machine > name... Thanks for the info John. I talked to him and he's going to try to fix it. He doesn't have any VMS systems, only U*ix, so he wasn't aware of the problem. It's not that it sends the hostname by itself, it only sends the username (i.e. instead of sending to , it sends to , not . I think I could understand the address being valid if the domain part were missing, but I'm not sure that when mail comes in for a valid username that MX should be quite so picky either. I'm not really up on the mail RFC's, but was going to dig into when my net fell apart and couldn't get to NIC to get a couple. At any rate, thanks for the response. Ron Welker (415) 966-2900 Internet: US Mail: welker@gtewd.mtv.gsc.gte.com 100 Ferguson Dr. M/S 5G09 welker@ns2.mtv.gsc.gte.com Mt. View, CA 94039 ================================================================================ Archive-Date: Tue, 22 Sep 1992 15:46:09 CDT Date: Tue, 22 Sep 1992 13:07:29 PDT From: "John F. Sandhoff" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: syssand@CCVAX.CCS.CSUS.EDU Message-ID: <00961000.6B8AC7A0.3559@CCVAX.CCS.CSUS.EDU> Subject: RE: send error: conn net object rej > From DNS records it seems that host REX has both an A record and > MX pointing to host SAM. I assume that SAM is the Charon gateway. > From my understanding of Charon-Gateway system, I'd assume > that REX is a Novell-Netware host ? If so then remove the > A record and let SAM to the translation or rewrite rule to > deliver mail to REX. No, no, no. Certain mailers REQUIRE that a target machine have an A address (I won't mention names). Also, if the NetWare machine is supporting IP connectivity then it needs to have the A record. MX-Mail will use the DNS MX records to send to the appropriate host. We too have a Charon/NetWare implementation and have no problem sending mail to it. The error you're seeing: %MX-F-RETRYEXCD, retry count exceeded -SYSTEM-F-REJECT, connect to network object rejected sounds like a problem with MX getting out. Is this Vax directly connected to the internet, or is it on the end of a DECnet or PSI hookup? John F. Sandhoff, University Network Support California State University, Sacramento - USA sandhoff@csus.edu ================================================================================ Archive-Date: Wed, 23 Sep 1992 08:54:47 CDT Date: Wed, 23 Sep 1992 08:12:40 CDT From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: "shsu::horn"@SHSU.BITNET CC: mx-list@WKUVX1.BITNET Message-ID: <009610A0.66AB1BE0.20958@SHSU.edu> Subject: Change in OA$LIB:SPECIAL.COM for All-in-1 On Tuesday, 22 September 1992 10:55:01.86 CDT, "James T. Horn" (our local VMS guru) posted the following to me: > I made a change to the SPECIAL.COM for All-in-1 because it was not > working as was: > > $ SEND_IT: > $ WRITE OAMAILBOX "OA GET #MAILADDR" > $ @DCLMAILBOX: > $ TO := "''NODE'''RESULT'" > $ TO = TO - "MX%" > $ LOOP1: > > > The line was added to takeout the mx% because it is added later in > the command file. I am attaching the SPECIAL.COM file as we now use it here, which incorporates the changes made to my original post of 17 Apr 91 00:17:56 GMT (included in [CONTRIB]ALL-IN-1_TO_MX.TXT), as modified by Rob McMillan on 10 May 91 01:43:56 GMT (included in [CONTRIB]ALL-IN-1_TO_MX_2.TXT). Rob noted that the solution was equally applicable to PMDF; whether or not this specific modification is equally applicable, I have no idea (my guess is yes, but I can't verify it). Hunter, possibly this needs to be added to [CONTRIB] as well? 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 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% $ ! OALIB:SPECIAL.COM V2.1A Last edited: 4-Nov-1985 $ ! Electronic Mail Subsystem $ ! Deliver mail to the "SPECIAL" destination $ ! $ 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'" $ TO = TO - "MX%" $ 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 $ TO = "MX%" + """""" + F$EDIT(TO,"LOWERCASE") + """""" $ OPEN/WRITE OUTFILE SPECIAL_TEMP.COM $ WRITE OUTFILE "$MAIL" $! WRITE OUTFILE "SEND/NOEDIT/NOSELF ''FILE'" $ WRITE OUTFILE "SEND/NOEDIT/NOSELF/NOCC ''FILE'" $ WRITE OUTFILE "''TO'" $ WRITE OUTFILE "''SUBJ'" $ WRITE OUTFILE "EXIT" $ WRITE OUTFILE "$EXIT" $ CLOSE OUTFILE $ @SPECIAL_TEMP $ DELETE/NOCONFIRM SPECIAL_TEMP.COM.* $! MAIL/SUBJ="''SUBJ'" 'FILE' 'TO' $! IF $STATUS THEN GOTO DONE $! $! NOT_SENT: $! Status = '$STATUS $! WRITE OAMAILBOX "OA GET OA$STATUS=""''STATUS'""" $! @DCLMAILBOX: $ DONE: $ SET DEFAULT 'ORIG_DIR $ EXIT ================================================================================ Archive-Date: Wed, 23 Sep 1992 16:49:19 CDT Date: Wed, 23 Sep 1992 12:16:38 PDT From: "John F. Sandhoff" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: syssand@CCVAX.CCS.CSUS.EDU Message-ID: <009610C2.7B44BA80.4781@CCVAX.CCS.CSUS.EDU> Subject: Timely bouncing of messages Stop-me-if-I'm-wrong-department: MX doesn't seem to follow a 'rule' that I thought existed as pertains to mail delivery (and if the following scenario isn't a rule, IMHO it should be :-) ): If the destination hostname cannot be resolved, then: if the resolution is not possible because of a DNS connection error (a reply from the DNS cannot be obtained), then: queue the entry for subsequent retry else if the DNS provides a reply saying "no such domain" then: bounce the message What I'm seeing is the sender mistypes the recipient host name, then the message goes thru its 3-day retry period before finally being rejected. This in spite of the DNS explicitly saying 'no such address'. If this is a bug, please place it on the bug-fix list otherwise please place it on the features-to-consider list. And as a workaround, is there some way to force a queued message to be prematurely returned to the sender? I can grab it from the queue and manually return it but that goes against the inherent lazy streak present in any good network administrator :-) John F. Sandhoff, University Network Support California State University, Sacramento - USA sandhoff@csus.edu ================================================================================ Archive-Date: Wed, 23 Sep 1992 19:28:51 CDT From: Subject: Re: Timely bouncing of messages Message-ID: <1992Sep23.234915.2856@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <009610C2.7B44BA80.4781@CCVAX.CCS.CSUS.EDU> Date: Wed, 23 Sep 1992 23:49:15 GMT To: MX-List@WKUVX1.BITNET In article <009610C2.7B44BA80.4781@CCVAX.CCS.CSUS.EDU>, "John F. Sandhoff" writes: >MX doesn't seem to follow a 'rule' that I thought existed >as pertains to mail delivery (and if the following scenario >isn't a rule, IMHO it should be :-) ): > >If the destination hostname cannot be resolved, then: > if the resolution is not possible because of a DNS connection > error (a reply from the DNS cannot be obtained), then: > queue the entry for subsequent retry > else > if the DNS provides a reply saying "no such domain" then: > bounce the message > >What I'm seeing is the sender mistypes the recipient host name, >then the message goes thru its 3-day retry period before finally >being rejected. This in spite of the DNS explicitly saying 'no >such address'. The reason MX does not bounce right away when the DNS replies with "no such domain" is that sometimes the DNS response can be wrong. This usually happens when network connectivity is spotty -- especially when the target domain has a less-than-robust setup of DNS servers. That's why I added the SET SMTP/DNS_RETRIES setting in MCP, so you can set the number of retries that should be taken in the case of name resolution problems. I thought I set the default to 6, which should be about a 3-hour retry period. If you complete confidence in everybody's DNS setup and network connectivity 100% of the time, you can always crank that down to zero. ;-) -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Wed, 23 Sep 1992 19:29:01 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: Change in OA$LIB: SPECIAL.COM for All-in-1 Message-ID: <1992Sep23.235155.13976@magnus.acs.ohio-state.edu> Sender: news@magnus.acs.ohio-state.edu References: <009610A0.66AB1BE0.20958@SHSU.edu> Date: Wed, 23 Sep 1992 23:51:55 GMT To: MX-List@WKUVX1.BITNET In <009610A0.66AB1BE0.20958@SHSU.edu> "George writes: > On Tuesday, 22 September 1992 10:55:01.86 CDT, "James T. Horn" > (our local VMS guru) posted the following to me: > > I made a change to the SPECIAL.COM for All-in-1 because it was not > > working as was: Something to (always) add to any commentary about the custom SPECIAL.COM. (Why do I feel qualified/obligated to do this? Because I was the person who initially unleashed this crufty hack.) If your users use All-In-1 as their primary enviroment, and have thair VMSmail forwarded to MRGATE::A1::, then you will have problems when users begin to reply to messages that have been handled by MX. A message is sent to the user from another site, and is received via MX, and then forwarded to the user's All-In-1 account. The user will be able to reply, the message the user generates with an "ANSWER" will have a "from" address that cannot be replied to by the recipient. This is due to the quotations that are added by both MX and MRGATE. There is no way around this that I know of, save to buy a commercial package such as WIN/TCP or Multinet that has a SMTP<->All-In-1 transport for Message Router. Finally, some personal commentary. If you're running All-In-1, and you are not running any vital apps that are only available via All-In-1, consider dropping it. I did. Saves me several thousand dollars per year, gives me an extra 300 megatbytes of disk space, decreases system load, and has made my users happier. (I created a custom DCL-based menu based on Harry Flowers' MENU.COM) --- Jim Gaynor | "Man-of-Many-Beeping-Sounds-and-Flashing-Lights" - KAJ OSU/ACS/FMS/OCES | or Disclaimer: Everything stated here and above is -my- opinion. Mine mine mine! "We're here as the official representatives of the Y chromosome" - M Silverberg ================================================================================ Archive-Date: Thu, 24 Sep 1992 03:43:44 CDT Date: Thu, 24 Sep 92 10:30:53 +0100 From: besserve@opgc.univ-bpclermont.fr Reply-To: MX-List@WKUVX1.BITNET Message-ID: <9209240930.AA19733@opgc.univ-bpclermont.fr> To: MX-List@RPIECSVX.BITNET, send@opgc.univ-bpclermont.fr Subject: MX-list-requests subscribe ================================================================================ Archive-Date: Thu, 24 Sep 1992 06:01:23 CDT Date: Thu, 24 Sep 1992 10:37:47 EDT From: FRANCOISE BESSERVE (33) 73407354 Reply-To: MX-List@WKUVX1.BITNET To: MX-List@RPIECSVX.BITNET CC: besserve@OPGCF1.UNIV-BPCLERMONT.FR Message-ID: <0096117D.D77128A0.1974@OPGCF1.UNIV-BPCLERMONT.FR> Subject: Help LIST ================================================================================ Archive-Date: Thu, 24 Sep 1992 08:23:22 CDT Date: Thu, 24 Sep 1992 09:06:54 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00961171.24B7CB80.5393@swdev.si.com> Subject: When does Postmaster receive mail? I realize that if someone has problems with mail at a site, they can usually send a message to POSTMASTER asking for help. MX defines a POSTMASTER alias which, it seems, forwards mail addressed to POSTAMSTER to an actual person. Under what, if any, circumstances does POSTMASTER get an automatically generated message? I have seen some mail packages that, when mail is undeliverable, send the message back to the original sender with POSTMASTER as the reply address and, at the same time, send the same message to the POSTMASTER alias so that the real postmaster is notified of the problem at the same time. Now, I don't believe MX does this at message expiration time, but why else would MX require a POSTMASTER alias defined? Why not just a VMS Mail forwarding address for a username POSTMASTER that forwards to the real person? -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 24 Sep 1992 12:39:44 CDT Date: Thu, 24 Sep 1992 10:03:20 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00961179.066FBEA0.5445@swdev.si.com> Subject: Why was RETURN-PATH chosen? For some time now, when people receive Internet mail on the VAX through MX (transported from the Internet by UUNET and UUCP on a Unix system), people would have the Return-Path set as the VMS Mail reply address. This is because UUNET munged the From and Reply-To addresses into bang paths, making them non-RFC822 compliant. The MX Users' Guide explains that MX examines the Reply-To, From, Sender, and Return-Path headers, in that order, to determine the address to which the mail should return. Since no header except Return-Path was valid, that's the one that was chosen. Now, however, we have a new version of Smail on our Unix mail router, which allows a setting of STRICT at startup which causes Smail to add "@localhost" (where "localhost" is the name of our mail router) to the end of the From and Sender addresses, making them RFC822 compliant. For most of the mail we now receive, the reply address is now the From address, which is exactly what we want. However, for a few mailing lists, the Return-Path address is still being used and I can't determine why. Comparison of the various headers doesn't yield any clues to me, but they might to you, so here are the relevant headers from a messages that "works" and from one that doesn't: Headers that work: Return-Path: From: uunet!rutgers.edu!spcvxb!terry@esseye.si.com (Terry Kennedy, Operations Mgr.) Sender: uunet!kl.sri.com!info-vax-request@esseye.si.com The above produce MX%"uunet!rutgers.edu!spcvxb!terry@esseye.si.com" as the VMS Mail reply address, as I would expect. Notice, however, that there is no Reply-To. However, Headers that don't work: Return-Path: From: FRANCOISE BESSERVE (33) 73407354 Reply-To: uunet!WKUVX1.BITNET!MX-List This produces a VMS Mail reply address of MX%"uunet!WKUVX1.BITNET!list-mgr@esseye.si.com" Here there is a Reply-to, and MX warns that it's not valid. Now, even though the Reply-To isn't valid, the From matches the form of the successfully used From in the first example. Can someone who knows MX's internals (Matt? Hunter?) explain why, in the second case, MX seems to be skipping the From header in its selection? Thanks. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 24 Sep 1992 13:27:47 CDT From: Subject: Statistics from MX accounting files with SAS Message-ID: <1992Sep24.160655.19835@aragorn.unibe.ch> Sender: news@aragorn.unibe.ch Reply-To: MX-List@WKUVX1.BITNET Date: Thu, 24 Sep 1992 16:06:55 GMT To: MX-List@WKUVX1.BITNET Hi a student of mine has written two procedures to generate statistic reports from the MX LOCAL and SMTP accounting files. These procedures use the SAS statistic package, perhaps somebody can use them also. Short remark: as we send all leaving mail to a default routing system, there will be no reports generated about the receivers of leaving mail, but this should be very easy to include, if needed. Martin $! ------------------ CUT HERE ----------------------- $ v='f$verify(f$trnlnm("SHARE_UNPACK_VERIFY"))' $! $! This archive created by VMS_SHARE Version 8.1 $! On 24-SEP-1992 17:57:04.59 By user SYSTEM $! $! The VMS_SHARE software that created this archive $! was written by Andy Harper, Kings College London UK $! -- September 1992 $! $! Credit is due to these people for their original ideas: $! James Gray, Michael Bednarek $! $! TO UNPACK THIS SHARE FILE, CONCATENATE ALL PARTS IN ORDER $! AND EXECUTE AS A COMMAND PROCEDURE ( @name ) $! $! THE FOLLOWING FILE(S) WILL BE CREATED AFTER UNPACKING: $! 1. MX_LOCAL.SAS;10 $! 2. MX_SMTP.SAS;11 $! $set="set" $set symbol/scope=(nolocal,noglobal) $f=f$parse("SHARE_UNPACK_TEMP","SYS$SCRATCH:."+f$getjpi("","PID")) $e="write sys$error ""%UNPACK"", " $w="write sys$output ""%UNPACK"", " $ if .not. f$trnlnm("SHARE_UNPACK_LOG") then $ w = "!" $ ve=f$getsyi("version") $ if ve-f$extract(0,1,ve) .ges. "4.4" then $ goto start $ e "-E-OLDVER, Must run at least VMS 4.4" $ v=f$verify(v) $ exit 44 $unpack: subroutine ! P1=filename, P2=checksum, P3=attributes $ if f$search(P1) .eqs. "" then $ goto file_absent $ e "-W-EXISTS, File ''P1' exists. Skipped." $ delete 'f'* $ exit $file_absent: $ if f$parse(P1) .nes. "" then $ goto dirok $ dn=f$parse(P1,,,"DIRECTORY") $ w "-I-CREDIR, Creating directory ''dn'" $ create/dir 'dn' $ if $status then $ goto dirok $ e "-E-CREDIRFAIL, Unable to create ''dn' File skipped." $ delete 'f'* $ exit $dirok: $ w "-I-UNPACK, Unpacking file ''P1'" $ n=P1 $ if P3 .nes. "" then $ n=f $ if .not. f$verify() then $ define/user sys$output nl: $ EDIT/TPU/NOSEC/NODIS/COM=SYS$INPUT 'f'/OUT='n' PROCEDURE GetHex LOCAL x1,x2;x1:=INDEX(t,ERASE_CHARACTER(1))-1;x2:=INDEX(t, ERASE_CHARACTER(1))-1;RETURN 16*x1+x2;ENDPROCEDURE; PROCEDURE SkipPartsep LOOP EXITIF INDEX(ERASE_LINE,"-+-+-+-+-+-+-+-+")=1; ENDLOOP;ENDPROCEDURE; PROCEDURE ExpandChar CASE CURRENT_CHARACTER FROM ' ' TO 'z' ["`"] :ERASE_CHARACTER(1);COPY_TEXT(ASCII(GetHex));[" "]:ERASE_CHARACTER(1);[ OUTRANGE,INRANGE]:MOVE_HORIZONTAL(1);ENDCASE;ENDPROCEDURE; PROCEDURE ProcessLine s:=ERASE_CHARACTER(1);LOOP EXITIF CURRENT_OFFSET>=LENGTH( CURRENT_LINE);ExpandChar;ENDLOOP;IF s="V" THEN APPEND_LINE;ENDIF;ENDPROCEDURE; PROCEDURE AdvanceLine MOVE_HORIZONTAL(-CURRENT_OFFSET);MOVE_VERTICAL(1); ENDPROCEDURE;PROCEDURE Decode POSITION(BEGINNING_OF(b));LOOP EXITIF MARK(NONE)= END_OF(b);IF INDEX(CURRENT_LINE,"+-+-+-+-+-+-+-+-")=1 THEN SkipPartSep; ELSE ProcessLine;AdvanceLine;ENDIF;ENDLOOP;ENDPROCEDURE;SET(FACILITY_NAME, "UNPACK");SET(SUCCESS,OFF);SET(INFORMATIONAL,OFF);t:="0123456789ABCDEF";f:= GET_INFO(COMMAND_LINE,"file_name");b:=CREATE_BUFFER(f,f);Decode;WRITE_FILE(b, GET_INFO(COMMAND_LINE,"output_file"));QUIT; $ if p3 .eqs. "" then $ goto dl $ open/write fdl &f $ write fdl "RECORD" $ write fdl P3 $ close fdl $ w "-I-CONVRFM, Converting record format to ", P3 $ convert/fdl=&f &f-1 &P1 $dl: delete 'f'* $ if P2 .eqs. "" then $ goto ckskip $ checksum 'P1' $ if checksum$checksum .nes. P2 then $ - e "-E-CHKSMFAIL, Checksum of ''P1' failed." $ exit $ckskip: e "-W-CHKSUMSKIP, checksum validation unavailable for ''P1'" $ endsubroutine $start: $! $ create 'f' X X`09/* X`09`09Generate`20mail`20accounting`20listing`20from X`09`09MX`20LOCAL`20accounting`20records X X`20`20`20`20`20`20`20`20`20`20`09V`201.1 X`09`09Fl`20/`2021.7.92:`20original`20code X`09`09Eg`20/`2024.9.92:`20cleanup X`09`09`09`09`09`09`20`20`20`20`20`20`09*/ X X`09/*`20libraries`20*/ X X`20`20`20`20`20`20`20`20libname`20lib`20'sys$scratch'`20;`20 X X`09/*`20Read`20data`20*/ X X`20`20`20`20`20`20`20`09data`20lib.acc_mx;`20 X`20`20`20`20`20`20`20`20`20`20`20infile`20'mx_local_dat'`20; X`20`20`20`20`20`20`20`20`20`20`20format`20source`20$`20char60.`20; X`20`20`20`20`20`20`20`20`20`20`20format`20user`20$`20char24.`20; X`20 X`20`20`20`20`20`20`20`20`20`20`20input`20 X`20`20`20`20`20`20`20`20`20`20`20@'"<'`20source`20$`20`20`20 X`20`20`20`20`20`20`20`20`20`20`20@'USER='`20user`20$ X`20`20`20`20`20`20`20`20`20`20`20@'SIZE='`20bytes; X X`09`20`20`20if`20source='>",'`20then`20do`20; X`09`20`20`20`20`20`20source='Postmaster@ubeclu.unibe.ch'`20; X`20`20`20`20`20`20`20`20`20`20`20end; X`09`20`20`20source=upcase(source); X`20`20`20`20`20`20`20`20`20`20`20source=compress(source,'>",'); X`20`20`20`20`20`20`20`20`20`20`20user=upcase(user); X`20`20`20`20`20`20`20`20`20`20`20user=compress(user,','); X X`20`20`20`20`20`20`20`20`20`20`20label`20source='Source*------'; X`20`20`20`20`20`20`20`20`20`20`20label`20user='User*----'; X`20`20`20`20`20`20`20`20`20`20`20label`20bytes='Size*----'; X X X`09/*`20generate`20the`20reports`20*/ X X`20`20`20`20`20`20`20`20/*`20source`20*/ X X`20`20`20`20`20`20`20`20proc`20sort`20data=lib.acc_mx`20out=lib.sour; X`20`20`20`20`20`20`20`20`20`20`20by`20source`20user`20bytes; X X`20`20`20`20`20`20`20`20proc`20means`20noprint`20n`20data=lib.sour; X`20`20`20`20`20`20`20`20`20`20`20by`20source; X`20`20`20`20`20`20`20`20`20`20`20var`20bytes; X`20`20`20`20`20`20`20`20`20`20`20output`20out=lib.sou`20sum=bytes; X X`20`20`20`20`20`20`20`20proc`20print`20noobs`20label`20uniform`20split='*'`20; V X`20`20`20`20`20`20`20`20`20`20`20var`20source`20_freq_`20bytes; X`20`20`20`20`20`20`20`20`20`20`20sum`20bytes; X`20`20`20`20`20`20`20`20`20`20`20title`20`20'Incoming`20mail:`20sender`20of V`20messages'; X`20`20`20`20`20`20`20`20 X`20`20`20`20`20`20`20`20/*`20local`20receiver`20*/ X X`20`20`20`20`20`20`20`20proc`20sort`20data=lib.acc_mx`20out=lib.user; X`20`20`20`20`20`20`20`20`20`20`20by`20user`20source`20bytes; X`20 X`20`20`20`20`20`20`20`20proc`20means`20sum`20noprint`20n`20data=lib.user; X`20`20`20`20`20`20`20`20`20`20`20by`20user; X`20`20`20`20`20`20`20`20`20`20`20var`20bytes; X`20`20`20`20`20`20`20`20`20`20`20output`20out=lib.user`20sum=bytes; X X`20`20`20`20`20`20`20`20proc`20print`20uniform`20label`20noobs`20split='*'; V`20`20`20`20`20`20`20`20`20`20`20`20 X`20`20`20`20`20`20`20`20`20`20`20var`20user`20_freq_`20bytes; X`20`20`20`20`20`20`20`20`20`20`20sum`20bytes;`20`20 X`20`20`20`20`20`20`20`20`20`20`20title`20`20'Incoming`20mail:`20local`20receiv Ver`20of`20messages'; X`20`20`20`20`20`20`20`20 X`20`20`20`20`20`20`20`20/*`20top`2045`20sources`20`26`20local`20receiver`20*/ V`20 X`20`20`20`20`20`20`20`20`20 X`20`20`20`20`20`20`20`20proc`20sort`20data=lib.sou`20out=lib.tops`20; X`20`20`20`20`20`20`20`20`20`20`20by`20descending`20bytes; X X`20`20`20`20`20`20`20`20proc`20print`20data=lib.tops`20(obs=45)`20label`20noob Vs`20uniform`20split='*'; X`20`20`20`20`20`20`20`20`20`20`20var`20source`20_freq_`20bytes; X`20`20`20`20`20`20`20`20`20`20`20sum`20bytes; X`20`20`20`20`20`20`20`20`20`20`20title`20`20'Incoming`20mail:`20sender`20of V`20messages`20(top`2045)'; X X`20`20`20`20`20`20`20`20proc`20sort`20data=lib.user`20out=lib.topu`20; X`20`20`20`20`20`20`20`20`20`20`20by`20descending`20bytes; X X`20`20`20`20`20`20`20`20proc`20print`20data=lib.topu`20(obs=45)`20label`20noob Vs`20uniform`20split='*'; X`20`20`20`20`20`20`20`20`20`20`20var`20user`20_freq_`20bytes; X`20`20`20`20`20`20`20`20`20`20`20sum`20bytes; X`20`20`20`20`20`20`20`20`20`20`20title`20`20'Incoming`20mail:`20local`20receiv Ver`20of`20messages`20(top`2045)'; X`20`20`20`20`20`20`20`20`20`20`20 X`20`20`20`20`20`20`20`20/*`20average`20message`20size`20*/`20`20`20 X X`20`20`20`20`20`20`20`20proc`20means`20data=lib.acc_mx;`20`20`20`20`20`20`20 V`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20 X`20`20`20`20`20`20`20`20`20`20`20output`20out=lib.aver`20mean=; X`20`20`20`20`20`20`20`20`20`20`20title`20'Mean`20incoming`20message`20size'; X`20`20`20`20`20`20`20`20`20 $ call unpack MX_LOCAL.SAS;10 471300261 "" $! $ create 'f' X X`09/* X`09`09Generate`20mail`20accounting`20listing`20from X`09`09MX`20SMTP`20accounting`20records X X`20`20`20`20`20`20`20`20`20`20`09V`201.1 X`09`09Fl`20/`2021.7.92:`20Original`20Code X`09`09Eg`20/`2024.9.92:`20Cleanup X`09`09`09`09`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`09*/ X X`09/*`20libraries`20*/ X X`20`20`20`20`20`20`20`20libname`20lib`20'sys$scratch'`20;`20 X X`09/*`20read`20data`20*/ X X`20`20`20`20`20`20`20`09data`20lib.smtp_mx;`20 X`20`20`20`20`20`20`20`20`20`20`20infile`20'mx_smtp_dat'`20; X`20`20`20`20`20`20`20`20`20`20`20format`20source`20$`20char60.`20; X`20`20`20`20`20`20`20`20`20`20`20format`20host`20$`20char20.`20; X`20 X`20`20`20`20`20`20`20`20`20`20`20input`20 X`20`20`20`20`20`20`20`20`20`20`20@'"<'`20source`20$`20`20`20 X`20`20`20`20`20`20`20`20`20`20`20@'HOST="'`20host`20$ X`20`20`20`20`20`20`20`20`20`20`20@'BYTES='`20bytes; X X`20`20`20`20`20`20`20`20/*`20cut`20the`20strings`20*/ X X`09if`20source='>",'`20then`20do`20; X`09`20`20`20source='Postmaster@ubeclu.unibe.ch'`20; X`20`20`20`20`20`20`20`20end; X`09source=upcase(source); X`20`20`20`20`20`20`20`20source=compress(source,'>",'); X`20`20`20`20`20`20`20`20host=compress(host,'",'); X X`20`20`20`20`20`20`20`20/*`20labels`20for`20printings`20*/ X X`20`20`20`20`20`20`20`20label`20source='Source*------'; X`20`20`20`20`20`20`20`20label`20host='Host*----'; X`20`20`20`20`20`20`20`20label`20bytes='Bytes*sent*----'; X X X`09/*`20generate`20reports`20*/ X X`20`20`20`20`20`20`20`20/*`20local`20sender`20*/ X X`20`20`20`20`20`20`20`20proc`20sort`20data=lib.smtp_mx`20out=lib.sour; X`20`20`20`20`20`20`20`20`20`20`20by`20source`20host`20bytes; X X`20`20`20`20`20`20`20`20proc`20means`20noprint`20n`20data=lib.sour; X`20`20`20`20`20`20`20`20`20`20`20by`20source; X`20`20`20`20`20`20`20`20`20`20`20var`20bytes; X`20`20`20`20`20`20`20`20`20`20`20output`20out=lib.sou`20sum=bytes; X X`20`20`20`20`20`20`20`20proc`20print`20noobs`20label`20uniform`20split='*'`20; V X`20`20`20`20`20`20`20`20`20`20`20var`20source`20_freq_`20bytes; X`20`20`20`20`20`20`20`20`20`20`20sum`20bytes; X`20`20`20`20`20`20`20`20`20`20`20title`20`20'Leaving`20mail:`20local`20sender V`20of`20messages'; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 X`20`20`20`20`20`20`20`20/*`20top`2045`20local`20senders`20*/`20 X`20`20`20`20`20`20`20`20`20 X`20`20`20`20`20`20`20`20proc`20sort`20data=lib.sou`20out=lib.tops`20; X`20`20`20`20`20`20`20`20`20`20`20by`20descending`20bytes; X X`20`20`20`20`20`20`20`20proc`20print`20data=lib.tops`20(obs=45)`20label`20noob Vs`20uniform`20split='*'; X`20`20`20`20`20`20`20`20`20`20`20var`20source`20_freq_`20bytes; X`20`20`20`20`20`20`20`20`20`20`20sum`20bytes; X`20`20`20`20`20`20`20`20`20`20`20title`20`20'Leaving`20mail:`20local`20sender V`20of`20messages`20(top`2045)'; X X`20`20`20`20`20`20`20`20/*`20average`20message`20size`20*/`20`20`20 X X`20`20`20`20`20`20`20`20proc`20means`20data=lib.smtp_mx;`20`20`20`20`20`20`20 V`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20 X`20`20`20`20`20`20`20`20`20`20`20output`20out=lib.aver`20mean=; X`20`20`20`20`20`20`20`20`20`20`20title`20'Mean`20sent`20message`20size'; X`20`20`20`20`20`20`20 $ call unpack MX_SMTP.SAS;11 1180465700 "" $ v=f$verify(v) $ exit ******************************************************************************* Martin Egger, Ph.D., Computing Services - System and User Support Group University of Bern, P.O. Box, Laenggassstrasse 51, CH-3012 Bern, Switzerland Phone: ++41 (0)31 65 38 45, Fax: ++41 (0)31 65 38 65, Telex: 753 112 unib ch RFC: egger@id.unibe.ch, X.400: S=egger;OU=id;O=unibe;P=switch;A=arcom;C=ch; HEPNET/SPAN: 20579::49203::egger, DECnet (Switzerland): 49203::egger ================================================================================ Archive-Date: Thu, 24 Sep 1992 13:47:40 CDT From: leesw@logica.co.uk Reply-To: MX-List@WKUVX1.BITNET Subject: Validating HELO ? Message-ID: <1992Sep24.164232.179@logica.co.uk> Date: 24 Sep 92 16:42:32 GMT To: MX-List@WKUVX1.BITNET When another machine contacts MX, is there a way of getting MX to do a DNS lookup to verify that the machine actually is who it says it is? The reason is that we are a new site and my machine is being passed mail to relay by a number of machines which are not properly configured. I would like to be able to bounce their mail, or at least get some kind of log, if they have not managed to get theor host name into the DNS or have not configured their mail system correctly - otherwise I risk routing mail on to the Net which cannot be replied to. Thanks William ================================================================================ Archive-Date: Thu, 24 Sep 1992 16:26:27 CDT Subject: Re: When does Postmaster receive mail? Message-ID: <1992Sep24.163837.3202@news.arc.nasa.gov> From: Date: Thu, 24 Sep 1992 16:38:37 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: usenet@news.arc.nasa.gov References: <00961171.24B7CB80.5393@swdev.si.com> To: MX-List@WKUVX1.BITNET In article <00961171.24B7CB80.5393@swdev.si.com>, "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: >I realize that if someone has problems with mail at a site, they can usually >send a message to POSTMASTER asking for help. In fact, that's a requirement for all Internet and BITNET sites. > Now, I don't >believe MX does this at message expiration time, but why else would MX require a >POSTMASTER alias defined? Why not just a VMS Mail forwarding address for a >username POSTMASTER that forwards to the real person? A VMS Mail forwarding address for POSTMASTER, or even a real POSTMASTER account would be just fine. There isn't a requirement for a Poastmaster _alias_, per se. I just didn't want to assume that the installer would take the initiative and set up the alias outside MX (in early versions I did). -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Thu, 24 Sep 1992 17:18:45 CDT From: Subject: Re: Validating HELO ? Message-ID: <1992Sep24.174520.5223@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <1992Sep24.164232.179@logica.co.uk> Date: Thu, 24 Sep 1992 17:45:20 GMT To: MX-List@WKUVX1.BITNET In article <1992Sep24.164232.179@logica.co.uk>, leesw@logica.co.uk writes: >When another machine contacts MX, is there a way of getting MX to do a DNS >lookup to verify that the machine actually is who it says it is? It does, but it doesn't use the information to determine acceptance/rejection, it simply notes any discrepancy in the Received: header for the message. About the only thing I could suggest would be to track your mail relaying, either by logging the incoming SMTP sessions (turning on MX_SMTP_SERVER_DEBUG) or by enabling outbound SMTP accounting. Then periodically you could go through that information and test the names yourself (or write a program to do that). -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Thu, 24 Sep 1992 18:42:13 CDT From: Subject: Re: Why was RETURN-PATH chosen? Message-ID: <1992Sep24.195340.8231@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <00961179.066FBEA0.5445@swdev.si.com> Date: Thu, 24 Sep 1992 19:53:40 GMT To: MX-List@WKUVX1.BITNET In article <00961179.066FBEA0.5445@swdev.si.com>, "Brian Tillman, Smiths Industries, VAX Support, x8425" writes about a discrepancy between the MX documentation: >The MX Users' Guide explains that MX examines the Reply-To, From, >Sender, and Return-Path headers, in that order, to determine the address to >which the mail should return. and this observed behaviour: >Headers that don't work: > >Return-Path: >From: FRANCOISE BESSERVE (33) 73407354 > >Reply-To: uunet!WKUVX1.BITNET!MX-List > >This produces a VMS Mail reply address of >MX%"uunet!WKUVX1.BITNET!list-mgr@esseye.si.com" The documentation isn't explaining things quite right. What happens is this: MX first goes through the 822 headers. An initial selection of return address is made from the Reply-To, From, and Sender headers, in that order. If none are present the envelope return address (which also becomes the Return-Path header) is used. After making its initial return address selection, it then parses that address to make sure it's valid. If it is, then fine. Otherwise it reverts to using the envelope return address, as a last-ditch effort to get something in the VMS Mail From string. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Thu, 24 Sep 1992 20:50:24 CDT From: Subject: Re: Where are the MX errors documented? Date: 24 Sep 1992 23:54:00 GMT Message-ID: <19tkeoINN53v@gap.caltech.edu> References: <00960F66.C62B3680.2962@swdev.si.com> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <00960F66.C62B3680.2962@swdev.si.com>, "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: >Matthew Madison (madison@tgv.com) writes: > >>They [the possible MX errors reported by MCP or MAILQUEUE] aren't documented, >>except in the source code -- and not really there, either. > >Thanks, Matt. > >Hunter, any change of adding the documentation of these errors to your wish >list? Thanks. OK, Brian, since you seem incapable of understanding what either I or Matt told you, here's a first cut at it: -TIMEOUT: Something timed out. Enable debugging of the appropriate agent and then look at the trace to find out what. -PROTOCOL_VIOLATION: Something violated a protocol. Enable debugging of the appropriate agent and look at the trace to find out what. ANY_OTHER_ERROR: Something caused an error which will be reported generically by MCP QUEUE SHOW/FU. If you want to find out what the underlying error is, then enable debugging and look at the trace. How many more times do you have to be told this before you believe it, nitwit? The error messages you see in the output from MCP QUEUE SHOW are fairly generic. You really shouldn't give a damn exactly what THEY mean. If they're persistent, THEN ENABLE DEBUGGING AND LOOK FOR THE MORE SPECIFIC ERROR INVOLVED. If they're not persistent, then there's no problem, is there? -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Fri, 25 Sep 1992 02:00:54 CDT Date: Fri, 25 Sep 92 02:44:11 -0400 Message-ID: <9209250644.AA10492@genrad.com> From: Reply-To: MX-List@WKUVX1.BITNET X-MX-Warning: Warning -- Invalid "To" header. To: "mx-list%wkuvx1.bitnet@ukcc.uky.edu" CC: Subject: Re: Validating HELO ? > From: CDCLU1::CO6301::"@UKCC.uky.edu:list-mgr@WKUVX1.BITNET" 24-SEP-1992 20:15:59.78 > To: WKUVX1.BITNET::MX-List > CC: > Subj: Validating HELO ? > > When another machine contacts MX, is there a way of getting MX to do a DNS > lookup to verify that the machine actually is who it says it is? The > reason is that we are a new site and my machine is being passed mail to relay > by a number of machines which are not properly configured. I would like to be > able to bounce their mail, or at least get some kind of log, if they have > not managed to get theor host name into the DNS or have not configured their > mail system correctly - otherwise I risk routing mail on to the Net which > cannot be replied to. > > Thanks > > William You should be applauded for considering the problem of mail that "cannot be replied to", however, it seems that due to the number of routers and their variations, there is already a lot of mail that cannot be replied to. For example, your message, as I received it, is quoted in full above; there is no way that I can even determine where you are, and 'manually' construct a personal reply; a 'program' reply would (presumably) get bounced by list-mgr! This is why there are continual exhortations for people to put their mail address into their signatures. -------------------------------------------------------------------------------- Name : Derek Dongray, Systems Manager, GenRad Ltd. Phone : 061 486 1511 ext 166 InterNet : Dongray@GenRad.com UKnet : Derek.Dongray@GenRad.co.uk PSS : 234261600119::Dongray CompuServe : 70374,2745 Address : Monmouth House, Monmouth Road, Cheadle Hulme, Cheshire, SK8 7AY, UK. ================================================================================ Archive-Date: Fri, 25 Sep 1992 09:08:46 CDT Date: Fri, 25 Sep 1992 08:53:09 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: madison@tgv.com CC: mx-list@WKUVX1.BITNET Message-ID: <00961238.62F09180.6133@swdev.si.com> Subject: Re: Why was RETURN-PATH chosen? Matt Madison (madison@tgv.com) writes: >The documentation isn't explaining things quite right. What happens is this: >MX first goes through the 822 headers. An initial selection of return >address is made from the Reply-To, From, and Sender headers, in that order. >If none are present the envelope return address (which also becomes the >Return-Path header) is used. Thanks, Matt. I'd like to request that the current developers (Hunter) consider using the headers in a hierarchy that follows the documentation, as opposed to the current behavior of trying to use only one of the Reply-To, From, or Sender headers and if it can't defaulting to the Return-Path. What I mean is, if MX can't use the Reply-To, then it should try the From. If it can't use that, then it should try the Sender. If that's no good, then use Return-Path. If other SMTP mail experts see a problem with this approach, please leave your thoughts in this list. I certainly wouldn't want to suggest something that violates an RFC somewhere. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Fri, 25 Sep 1992 13:17:44 CDT Sender: p_rand@luke.spu.edu Date: Fri, 25 Sep 1992 11:11:40 EDT From: "Phil Rand, Computer Services, 281-2428" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096124B.BCD018C0.2491@luke.spu.edu> Subject: Confused about mx on clusters Hi all, I'm confused about how MX works on VAXclusters. We use SMTP over TCP/IP (UCX 1.3), on one standalone system running VMS 5.5-1, and on a two-node cluster running 5.3-1. Twice, now, I've attempted to run all the agents on both nodes of the cluster, only to discover that no SMTP mail was getting through to either node. When I reconfigured to have only one node run the agents, mail started coming through again. (I didn't think to check the queue, to see if messages were making it there and just not being delivered to the user). Could this be explained by the fact that I hadn't defined the MAIL$SYSTEM_FLAGS? I just define/system/exec'd this as 7 on both nodes. Is this going to make it safe to try reconfiguring to use both cluster nodes, or have I got another problem as well? Possibly related other factor: We want to have all SMTP mail be routed through our Ultrix 4.2 machine, paul.spu.edu, which will has a master /etc/aliases file with an alias for every mail user on our campus. We have DNS mail exchanger (MX) records pointing to paul.spu.edu for all of our other hosts. This way, when a user moves from one host to another, we can just change his alias on paul. We tell our users to give their internet mail addresses as user@spu.edu, leaving out the host name. Is this the right way to to this? Are there better ways? Risks? ----------------------------------------------------------------------- Phil Rand, Computer & Information Systems, Seattle Pacific University 3307 3rd Ave W, Seattle, WA 98119 p_rand@spu.edu (206) 281-2428 ----------------------------------------------------------------------- ================================================================================ Archive-Date: Fri, 25 Sep 1992 17:52:32 CDT Sender: ebates@uop.edu Date: Fri, 25 Sep 1992 10:22:48 PDT From: Ed Bates Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00961244.E90FC7C0.9743@vms1.cc.uop.edu> Subject: Re: Where are the MX errors documented? writes: >OK, Brian, since you seem incapable of understanding what either I or Matt told >you, here's a first cut at it: >[...] >How many more times do you have to be told this before you believe it, nitwit? >[...] I appreciate the information you passed on to us, Carl. However, not everyone is quite the techno-wiz that you, Matt, and others are. It has not been made clear to me that one has to have a complete understanding of VAX/VMS system management, TCP/IP, or even basic networking in order to receive assistance from people who may know the answers. If that is true, can we make a separate distribution list for people who want to know things that long-time VAX managers know without disturbing the balance of techno-wiz discussions? Perhaps it could be called "MX-Nitwit-List". :-( -- Ed - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Edwin J. (Ed) Bates VAX Administrator/Postmaster . . _ _ Technical Support Specialist Internet: ebates@uop.edu | | / \ | \ Office of Computing Services AppleLink: U1441 | | | | |_/ University of the Pacific Telephone: (209) 946-2251 | | | | | Stockton, CA 95211 Fax: (209) 946-2898 \_/ \_/ | ================================================================================ Archive-Date: Fri, 25 Sep 1992 17:52:50 CDT Subject: MX SITE, and performance problems Message-ID: From: Reply-To: MX-List@WKUVX1.BITNET Date: 25 Sep 92 17:05:18 GMT Sender: (News system) To: MX-List@WKUVX1.BITNET Mx-ers, I use the MX SITE interface to a mail gateway to our home grown mailing system, named ELLA. The problem is, that MX calls SITE_DELIVER.COM with the same message as many times as many SITE interface recipients receive the message. In other words the temporary file (parameter p3), that contains the recipents's addresses contains always just one line. I am surprised by this because in the other direction the corresponding file may contain more addresses. The bandwith to the ELLA system happens to be rather small. To transfer a 30 K message takes cca. a minute. The case is, that a lot of users (between 30-40) receive the very same messages regurarily from a mailing list. The message size is usually about 30 K. This results in a 30-40 minute transfer time, instead of one minute ! What's worse, the traffic is rather heavy - several thousands of messages per day - and the message queue is dangerously large. MX_ROOT:QUEUE.DIR is sometimes more then 300 blocks ! I think that the situation could be much better, if SITE_DELIVER.COM could get more addresses at once. I am afraid that more users will subscribe to more lists, and my system will not be able to keep up. Any piece of advice is welcome. Pasztor Miklos pasztor@hugbox.bitnet MTA SZTAKI/ASZI Institute for Computation and Automation Hungarian Academy if Sciences, Budapest ================================================================================ Archive-Date: Fri, 25 Sep 1992 18:33:30 CDT From: Subject: Re: MX SITE, and performance problems Message-ID: <1992Sep25.201737.20520@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: Date: Fri, 25 Sep 1992 20:17:37 GMT To: MX-List@WKUVX1.BITNET In article , miklos@ub40.sztaki.hu (Pasztor Miklos) writes: > The problem is, that MX calls SITE_DELIVER.COM with the same message > as many times as many SITE interface recipients receive the message. > In other words the temporary file (parameter p3), that contains > the recipents's addresses contains always just one line. SITE used to pass all of the destination addresses in that file at once. It was changed to do one at at time so that the success or failure for each recipient could be recorded... the current interface only provides for one status indication returned from each invocation of SITE_DELIVER.COM. I guess the best solution would be for MX_SITE to provide some other mechanism for per-recipient status indication. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Fri, 25 Sep 1992 18:33:48 CDT From: Subject: Re: Confused about mx on clusters Message-ID: <1992Sep25.203835.21298@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <0096124B.BCD018C0.2491@luke.spu.edu> Date: Fri, 25 Sep 1992 20:38:35 GMT To: MX-List@WKUVX1.BITNET In article <0096124B.BCD018C0.2491@luke.spu.edu>, "Phil Rand, Computer Services, 281-2428" writes: >Twice, now, I've attempted to run all the agents on both nodes of the >cluster, only to discover that no SMTP mail was getting through to >either node. When I reconfigured to have only one node run the >agents, mail started coming through again. (I didn't think to check >the queue, to see if messages were making it there and just not being >delivered to the user). As long as you've got a homogeneous environment*, there's no reason why you shouldn't be able to run any or all of the delivery agents on multiple nodes in your cluster. I'd need to know more about your cluster configuraiton, MX configuration, and DNS configuration to be able to tell you more. More information on specific examples of the problem would be helpful, too. *homogeneous defined as: 1. All nodes sharing same SYSUAF 2. Low-order two bits of MAIL$SYSTEM_FLAGS set 3. All nodes have access to the disk containing the message queue and the MX directories -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Sat, 26 Sep 1992 10:40:12 CDT Date: Sat, 26 Sep 1992 16:37:46 EDT From: "J.C. Higgins, Sys Mgr CsVax1, UCC , Eire" Reply-To: MX-List@WKUVX1.BITNET Subject: RE: MX SITE, and performance problems To: MX-LIST@WKUVX1.BITNET Message-ID: <00961342.75757680.18176@CSVAX1.UCC.IE> In a previous article, miklos@ub40.sztaki.hu wrote: >Date: 25 Sep 92 17:05:18 GMT >From: miklos@ub40.sztaki.hu >Subject: MX SITE, and performance problems >Reply-To: MX-List@WKUVX1.BITNET > > I use the MX SITE interface to a mail gateway to our home grown mailing > system, named ELLA. > [text deleted...] > > I think that the situation could be much better, if SITE_DELIVER.COM > could get more addresses at once. > I am afraid that more users will subscribe to more lists, and my > system will not be able to keep up. > > Any piece of advice is welcome. > Pasztor Miklos pasztor@hugbox.bitnet > MTA SZTAKI/ASZI > Institute for Computation and Automation > Hungarian Academy if Sciences, Budapest > I think that if you changed your approach to the problem, you might find an easy solution. It is unlikely that you will find a program that will directly solve your problem (as I understand it). What I would suggest you do is the following. Setup a bulletin board on your destination machine. So that the your users can have any busy lists, or any popular lists fed into the bulletin board, rather than having several copies delivered personally to your users. That way, everyone can get at the information on the lists, and you only have one copy of each message being delivered. I've being doing this on this machine for quite a while. It cuts down on bandwidth, and allows users to browse the messages at their ease, WITHOUT using any of their diskquota. If they want any particular message, then they just extract it from the bulletin board.. Hope this helps. Chris. + J.C. Higgins, Sys Admin + If you love something, set it free. If it doesn't + CHRIS@csvax1.ucc.ie + come back to you, hunt it down and KILL it. If + SCCS6002@iruccvax.ucc.ie + that doesn't work, then GIVE UP peacefully. ================================================================================ Archive-Date: Sat, 26 Sep 1992 15:32:51 CDT From: Subject: Re: Where are the MX errors documented? Date: 26 Sep 1992 19:45:19 GMT Message-ID: <1a2ekfINNik@gap.caltech.edu> References: <00961244.E90FC7C0.9743@vms1.cc.uop.edu> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <00961244.E90FC7C0.9743@vms1.cc.uop.edu>, Ed Bates writes: > writes: >>OK, Brian, since you seem incapable of understanding what either I or Matt told >>you, here's a first cut at it: >>[...] >>How many more times do you have to be told this before you believe it, nitwit? >>[...] > >I appreciate the information you passed on to us, Carl. However, >not everyone is quite the techno-wiz that you, Matt, and others are. OK, let me try to make my position clear: The status values we're talking about here, in one sense should need no documentation within MX: If you don't know what a timeout is, the MX documentation isn't the place to learn it. If you don't understand the term "protocol violation," the MX documentation isn't the place to learn what that means. Likewise for most of the other status values you'll see in the queues (the main exception is for the LOCAL delivery agent: It generally involves VMS MAIL status values; again, the MX documentation isn't the place to document these). In no case that I can think of offhand does the status value you see with the MCP QUEUE SHOW command give you enough information to do anything useful: It's just a rather general description of the sort of problem that's occurring (except in the case of the LOCAL delivery agent, in which case the status might be specific, but in that case it's usually one of the status values that take text arguments (e.g., which machine was unreachable, and these values aren't dealt with by the MCP QUEUE SHOW command). So there's really not much point in documenting these values. The ONLY way you can figure out what the problem is is to enable debugging and look at the trace. Now, at THAT point, it's a good idea to know how the various protocols are supposed to work. Again, that's not something that should be put in the MX documentation. You should get a copy of the appropriate protocol definitions from whomever maintains them (in the case of SMTP, you can get RFC822 from NIC.DDN.MIL via anonymous FTP; you should also check for other RFCs that modify RFC822). It WOULD be nice if the documentation for MX contained directions on where to find the protocol specifications. Now, of course Hunter could expand the number of error statuses for each of the agents so that there's a unique error status for each possible sort of error. However, I suspect that doing this for, e.g., protocol violations, would result in more unique error values than are allowed to any one utility. Documenting all of them would take either several man months of effort, or a computer program to run through all invalid action/response pairs possible in the protocol. Either way, the documentation at such a level would be meaningless if you didn't understand the protocol in question, and unnecessary if you DID understand the protocol. >It has not been made clear to me that one has to have a complete >understanding of VAX/VMS system management, TCP/IP, or even basic >networking in order to receive assistance from people who may know >the answers. If that is true, can we make a separate distribution >list for people who want to know things that long-time VAX managers >know without disturbing the balance of techno-wiz discussions? Brian received assistance from us. He chose repeatedly to ignore it. He was told at least twice that the error statuses he wants documented were nearly meaningless by themselves, and that the appropriate thing to do is enable debugging and look at the trace. He believed, apparently, neither Matt nor myself when we told him this. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Sun, 27 Sep 1992 22:41:16 CDT Date: Sun, 27 Sep 1992 23:32:59 EDT From: Shakil Khan Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: khan@QCVAXA.BITNET Message-ID: <00961445.A1599520.9053@qcvaxa.acc.qc.edu> Subject: Access Violation MCP> QUEUE SHOW/ALL At the above command I get Access Violation and register dump. Is any one else experiencing the same as well? I am running MX3.1c. Any pointers, work around??? shakil ================================================================================ Archive-Date: Mon, 28 Sep 1992 07:01:06 CDT Subject: Re: Validating HELO ? Message-ID: <1992Sep28.104530.182@logica.co.uk> From: leesw@logica.co.uk Reply-To: MX-List@WKUVX1.BITNET Date: 28 Sep 92 10:45:30 GMT References: <9209250644.AA10492@genrad.com> To: MX-List@WKUVX1.BITNET In article <9209250644.AA10492@genrad.com>, writes: > ..example, your message, as I received it, is quoted in full above; there is no > way that I can even determine where you are, and 'manually' construct a > personal reply; a 'program' reply would (presumably) get bounced by list-mgr! Derek, Thanks for pointing this out! I must admit I had assumed that the header would be preserved... Anyway, I hope I have now addressed the problem. --------------------------------------------------- William Lees, Logica International Ltd, London UK Internet: leesw@logica.co.uk CompuServe: 75300,250 ================================================================================ Archive-Date: Mon, 28 Sep 1992 07:01:14 CDT Date: Mon, 28 Sep 1992 06:04:01 EDT From: John Hasstedt Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096147C.4162E9A0.3170@nuclear.physics.sunysb.edu> Subject: RE: Access Violation Shakil Khan says >MCP> QUEUE SHOW/ALL > >At the above command I get Access Violation and register dump. Is any one >else experiencing the same as well? I am running MX3.1c. Any pointers, work >around??? > shakil I got these errors when I installed MX3.1C on a new computer. I quit getting them after a while. The only explanation I have for them going away is that they were related to some system parameter and they went away after I ran AUTOGEN with feedback several times. ========================================================================== 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: Tue, 29 Sep 1992 17:11:29 CDT Date: Tue, 29 Sep 1992 17:10:57 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <009615A2.97ABC3A0.8441@swdev.si.com> Subject: Notifying senders of message retries Is there a way for MX to notify the author of an outbound mail message when it is retrying the delivery of that message? If a message isn't immediately deliverable and MX requeues it for retry, I'd like to have MX let the original sender know that the message couldn't be sent at that time, but is queued for retry. I couldn't find any references to this in the docs, so I anticipate it's not an inherent feature. However, perhaps there is a way to do it with the SITE agent. Any suggestions (germaine to this topic)? -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Tue, 29 Sep 1992 18:57:07 CDT Sender: kish@DRWHO.IAC.HONEYWELL.COM Date: Tue, 29 Sep 1992 16:55:13 EDT From: kish@DRWHO.IAC.HONEYWELL.COM Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: kish@DRWHO.IAC.HONEYWELL.COM Message-ID: <009615A0.64C3C2A0.2296@DRWHO.IAC.HONEYWELL.COM> Subject: Return Address for MX Im shure this is in the DOC set but I cant seem to locate it. How is the return address determined? Is it from the first PATH=LOCAL or is from the transport. My problem is that we are being reorganized and I need to change the primairy name for our host but I would like to leave the onld name in the name space. I have got that all working but I cant figure how to change our from address to our current actual address. Karl ================================================================================ Archive-Date: Wed, 30 Sep 1992 06:55:20 CDT Date: Wed, 30 Sep 92 06:49:33 -0400 Message-ID: <9209301049.AA09816@genrad.com> From: Reply-To: MX-List@WKUVX1.BITNET X-MX-Warning: Warning -- Invalid "To" header. To: "mx-list%wkuvx1.bitnet@ukcc.uky.edu" Subject: Protocol errors between Vaxcluster? I have two Vaxclusters both runnning UCX 1.3A and MX 3.1C on VMS 5.5-1. Both clusters are configured so that a boot node runs almost everything (local, smtp, smtp_server, router, etc.) and some, but not all, satelites run smtp_servers. The clusters are configured to have cluster IP addresses as well as several nodes having individual addresses. On cluster 1, there is a mailing list which includes several entries for cluster 2. Quite frequently, these fail with protocol error and eventually get abandoned after the retry count runs out. Mail on the same list to local Suns (Unix) and Vaxes running DNSMTP is delivered ok. and test mail from cluster 1 to cluster 2 is also delivered ok. Debugging produces the following SMTP log on cluster 1. There don't appear to be any debug logs on cluster 2. 30-SEP-1992 12:05:56.47 Processing queue entry number 3666 on node CD4000 30-SEP-1992 12:05:58.21 Recipient: , route=CDCLU2 [...some entries deleted...] 30-SEP-1992 12:05:58.31 Recipient: , route=CDCLU2 30-SEP-1992 12:05:58.50 SMTP_SEND: looking up host name CDCLU2 30-SEP-1992 12:05:59.23 SMTP_SEND: Attempting to start session with CDCLU2 [128.1.0.42] 30-SEP-1992 12:05:59.25 SMTP_SEND: Connected 30-SEP-1992 12:06:02.36 SMTP_SEND: Rcvd: 30-SEP-1992 12:06:02.81 SMTP send failed, sts=0C27804A, sts2=0C278042 30-SEP-1992 12:06:02.85 Recipient status=0C27804A for [...some entries deleted...] 30-SEP-1992 12:06:02.86 Recipient status=0C27804A for 30-SEP-1992 12:06:04.28 16 rcpts need retry, next try 30-SEP-1992 12:36:04.28 30-SEP-1992 12:06:04.37 *** End of processing pass *** I have been unable to find a translation for the status codes given. Stopping and restarting MX (and UCX) on both clusters usually clear it for a while, but I would like to know what the problem really is. Any help would be appreciated. Thanks, Derek. -------------------------------------------------------------------------------- Name : Derek Dongray, Systems Manager, GenRad Ltd. Phone : 061 486 1511 ext 166 InterNet : Dongray@GenRad.com UKnet : Derek.Dongray@GenRad.co.uk PSS : 234261600119::Dongray CompuServe : 70374,2745 Address : Monmouth House, Monmouth Road, Cheadle Hulme, Cheshire, SK8 7AY, UK. ================================================================================ Archive-Date: Wed, 30 Sep 1992 10:12:41 CDT From: whiskerp@logica.co.uk Reply-To: MX-List@WKUVX1.BITNET Subject: ""Route too complex"" problem Message-ID: <1992Sep30.141813.191@logica.co.uk> Date: 30 Sep 92 14:18:13 GMT To: MX-List@WKUVX1.BITNET As well as my VMSMail account on our MX node CONDOR::, I have both an All-in-1 and VMSMail account on our node LGMAN. The All-in-1 mailbox is normally redirected to which is the VMSMail mailbox. The problem occurs when I try to send an Internet message through MX to the (redirected) All-in-1 address. The address I use is "whisker%lgman.a1"@logica.co.uk. This works fine and delivers mail to the All-in-1 mail account if it is NOT redirected, but if it is redirected, I get the following bounced message: _______________________________________________________________________________ From: MX%"'condor::mrgate::\'LGMAN::MRGATE\''@condor.logica.co.uk" 30-SEP-1992 11:57:16.31 To: WHISKERP CC: Subj: Message Router VMSmail Gateway nondelivery notification Return-Path: <"condor::mrgate::\"LGMAN::MRGATE\""@condor.logica.co.uk> Received: by condor.logica.co.uk (MX V3.1C) id 1338; Wed, 30 Sep 1992 11:57:06 GMT Date: Wed, 30 Sep 1992 11:57:03 GMT From: "condor::mrgate::\"LGMAN::MRGATE\""@condor.logica.co.uk To: whiskerp@condor.logica.co.uk X-VMSmail-To: MX%"whiskerp@condor.logica.co.uk" Message-ID: <0096163F.E8730080.1338@condor.logica.co.uk> Subject: Message Router VMSmail Gateway nondelivery notification Delivery of this message through the Gateway had the following results: Invalid reply path generated - Route too complex Unable to deliver to : WHISKER The original message follows: From: NAME: MX%"whiskerp@condor.logica.co.uk" Subject: mx%"whisker%lgman.a1@logica.co.uk" To: whisker@AM@lgman Return-Path: Received: by condor.logica.co.uk (MX V3.1C) id 1336; Wed, 30 Sep 1992 11:48:10 GMT Date: Wed, 30 Sep 1992 11:48:08 GMT From: Peter Whisker (WCt/1 ext 4408) To: whisker%lgman.a1@logica.co.uk CC: whiskerp@condor.logica.co.uk Message-ID: <0096163E.A9768A60.1336@condor.logica.co.uk> Subject: mx%"whisker%lgman.a1@logica.co.uk" mx%"whisker%lgman.a1@logica.co.uk" is the address used Date: 30-Sep-1992 Posted-date: 30-Sep-1992 VMSmail To information: MRGATE::"lgman::AM::whisker" _______________________________________________________________________________ There seems to be some problem in generating a valid reply address. Does anybody know what might be happening ???? Many thanks in advance ! -- Peter Whisker | X400: Logica DCG Ltd. | Internet: Cobham, Surrey, UK | ================================================================================ Archive-Date: Wed, 30 Sep 1992 15:35:00 CDT Date: Wed, 30 Sep 1992 12:31:02 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00961644.A73BCDE0.9163@swdev.si.com> Subject: MX headers and mail logical names. I have some mail logical names, defined as follows: "JON" = "DIEKEMA_JON" (LNM$PROCESS_TABLE) "JIM" = "KERSJES_JAMES" (LNM$PROCESS_TABLE) "KENT" = "MCPHERSON_KENT" (LNM$PROCESS_TABLE) "PAUL" = "MILLER_PAUL" (LNM$PROCESS_TABLE) In turn, the names on the right above are entries in VMSMAIL_PROFILE that are placeholders for SET FORWARD commands. They are: DIEKEMA_JON has mail forwarded to MX%"" KERSJES_JAMES has mail forwarded to MX%"" MCPHERSON_KENT has mail forwarded to MX%"" MILLER_PAUL has mail forwarded to MX%"" When I send mail To: Jon,Jim,Kent,Paul This work well. Each gets his copy of the message. Those of them who have the ability to "reply to all recipients" can do so. Great. The header MX adds looks like this: To: diekema_jon@swdev.si.com, kersjes_james@swdev.si.com, mcpherson_kent@swdev.si.com, miller_paul@swdev.si.com The node SWDEV is our MX system on our cluster. Now, I also have a logical name as follows: "EWG" = "Jon,Jim,Kent,Paul" (LNM$PROCESS_TABLE) When I send mail To: EWG again, each person gets the mail and can reply, but cannot reply to all recipients. The header looks like this: To: "Jon,Jim,Kent,Paul"@swdev.si.com Can you explain to me why the To: header would be different for these two cases, since the logical names are all iteratively translated? (They must be, because everyone gets his mail.) Is there a way to have both of these cases appear the same on the receiving end, or should I just refrain from using the short-hand EWG name? Perhaps there is another way to express the logicals. Since I know where the mail aliases are really forwarded, I tried to define my logicals like this: "JON" = "MX%"DIEKEMA_JON@MAILTALK"" (LNM$PROCESS_TABLE) "JIM" = "MX%"KERSJES_JAMES@MAILTALK"" (LNM$PROCESS_TABLE) "KENT" = "MX%"MCPHERSON_KENT@MAILTALK"" (LNM$PROCESS_TABLE) "PAUL" = "MX%"MILLER_PAUL@MAILTALK"" (LNM$PROCESS_TABLE) so that no extra forwarding look-up needed to occur. Again, each received his mail, but once again the To: header looked as before. Thanks. I appreciate your comments on this subject. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Wed, 30 Sep 1992 18:38:48 CDT From: Subject: Re: MX headers and mail logical names. Message-ID: <1992Sep30.215015.20227@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <00961644.A73BCDE0.9163@swdev.si.com> Date: Wed, 30 Sep 1992 21:50:15 GMT To: MX-List@WKUVX1.BITNET In article <00961644.A73BCDE0.9163@swdev.si.com>, Brian Tillman writes: >Now, I also have a logical name as follows: > > "EWG" = "Jon,Jim,Kent,Paul" (LNM$PROCESS_TABLE) > >When I send mail > >To: EWG > >again, each person gets the mail and can reply, but cannot reply to all >recipients. The header looks like this: > >To: "Jon,Jim,Kent,Paul"@swdev.si.com Because MX_MAILSHR isn't parsing that string "correctly" (i.e., the way VMS Mail does). If you defined EWG as $ DEFINE EWG "Jon","Jim","Kent","Paul" you should get the correct results. Looks like VMS Mail automatically deals with the comma-separated list, whereas MX_MAILSHR does not. Looks like MX_MAILSHR needs some additional code to handle this. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA