Archive-Date: Thu, 02 Jul 1992 00:43:40 CDT Date: Thu, 02 Jul 1992 00:43:05 CDT From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <0095CF28.D813B760.34@WKUVX1.BITNET> Subject: Administrivia: MX-List monthly 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: Thu, 02 Jul 1992 09:22:33 CDT Date: Thu, 02 Jul 1992 09:35:15 EDT From: "Brian Tillman, Facilities, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: tillman@heinhu.si.com Message-ID: <0095CF73.2FD27C80.3298@heinhu.si.com> Subject: MX running in a cluster If MX is running in a cluster and more than one node is running a compatible TCP/IP, can I have multiple nodes actively route mail and still have mail appear to come from one node? How about having mail appear as coming from the cluster name? Now, how about when mail comes in. Must it be addressed to one of the specific nodes in the cluster or can it be addressed to the cluster alias? We are running a non-MX compatible TCP/IP on two nodes in the cluster. I want to start migrating people away from that IP's mailer toward MX. Is there a way I can, on a per-user basis, have the other mailer's protocol name (let's face it, it's WINS%) be interpreted as MX%? In a cluster where MX is running on multiple nodes, when mail comes in, how is it decided which node is going to deliver the mail to the local user? If mail is sitting in the outbound queue, how is it decided which node is going to send the mail on? If I send mail to another node in the IP network, will it always go through the node defined in the SMTP agent as the default router or will it go directly to the target node, assuming the target node's address is available to the sending node? -----------------------------+--------------------------------- Brian Tillman | Internet: tillman@heinhu.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, 02 Jul 1992 12:45:15 CDT From: Subject: Re: MX running in a cluster Message-ID: <1992Jul2.162116.26652@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <0095CF73.2FD27C80.3298@heinhu.si.com> Date: Thu, 2 Jul 1992 16:21:16 GMT To: MX-List@WKUVX1.BITNET In article <0095CF73.2FD27C80.3298@heinhu.si.com>, "Brian Tillman, Facilities, x8425" writes: >If MX is running in a cluster and more than one node is running a compatible >TCP/IP, can I have multiple nodes actively route mail and still have mail appear >to come from one node? How about having mail appear as coming from the cluster >name? You can have mail appear to be from any name you wish, more or less. You get prompted for the "MX network node name" when installing the base software. If you want to change that for an existing installation, edit the file MX_DIR:MX_LOGICALS.DAT to change the definitions of MX_NODE_NAME and MX_VMSMAIL_LOCALHOST. You can have the MX processes run on multiple nodes in your cluster by answering the questions asked at installation time, also. To change an existing installation, edit the file MX_DIR:MX_STARTUP_INFO.DAT. Just be careful when doing it. I believe I included some documentation on this file in the Management Guide. >Now, how about when mail comes in. Must it be addressed to one of the specific >nodes in the cluster or can it be addressed to the cluster alias? As long as you have a DEFINE PATH LOCAL for each name you want MX to recognize as local, you can use any set of names you like. The other side of this, of course, is to make sure you have appropriate mail exchanger (MX) records in the Domain Name System. >We are running a non-MX compatible TCP/IP on two nodes in the cluster. I want >to start migrating people away from that IP's mailer toward MX. Is there a way >I can, on a per-user basis, have the other mailer's protocol name (let's face >it, it's WINS%) be interpreted as MX%? $ DEFINE/SYSTEM/EXEC MAIL$PROTOCOL_WINS MX_MAILSHR >In a cluster where MX is running on multiple nodes, when mail comes in, how is >it decided which node is going to deliver the mail to the local user? If mail >is sitting in the outbound queue, how is it decided which node is going to send >the mail on? There is no priority scheme among delivery agents. All agents of a particular type get notified when there is a queue entry waiting to be processed, and whichever one gets to that entry first does the processing. >If I send mail to another node in the IP network, will it always go through the >node defined in the SMTP agent as the default router or will it go directly to >the target node, assuming the target node's address is available to the sending >node? If you mean the default router as set by SET SMTP/DEFAULT_ROUTER, then the latter case you describe holds. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Thu, 02 Jul 1992 13:29:08 CDT Date: Thu, 02 Jul 1992 10:21:43 PST From: Carl J Lydick Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX running in a cluster Sender: carl@SOL1.GPS.CALTECH.EDU To: MX-List@WKUVX1.BITNET Message-ID: <0095CF79.AD14C620.29762@SOL1.GPS.CALTECH.EDU> >We are running a non-MX compatible TCP/IP on two nodes in the cluster. I want >to start migrating people away from that IP's mailer toward MX. Is there a way >I can, on a per-user basis, have the other mailer's protocol name (let's face ------------------- >it, it's WINS%) be interpreted as MX%? $ DEFINE/SYSTEM/EXEC MAIL$PROTOCOL_WINS MX_MAILSHR Doesn't sound per-user to me :-). You simply have to add the line: $ DEFINE MAIL$PROTOCOL_WINS MX_MAILSHR to the LOGIN.COM of the user in question. ================================================================================ Archive-Date: Sat, 04 Jul 1992 01:05:40 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX running in a cluster Message-ID: <1992Jul2.184246.6070@dayton.saic.com> Date: 2 Jul 92 18:42:46 EDT References: <0095CF73.2FD27C80.3298@heinhu.si.com> <1992Jul2.162116.26652@news.arc.nasa.gov> To: MX-List@WKUVX1.BITNET In article <1992Jul2.162116.26652@news.arc.nasa.gov>, madison@Octavia.TGV.COM (Matt Madison) writes: > In article <0095CF73.2FD27C80.3298@heinhu.si.com>, "Brian Tillman, Facilities, x8425" writes: >>In a cluster where MX is running on multiple nodes, when mail comes in, how is >>it decided which node is going to deliver the mail to the local user? If mail >>is sitting in the outbound queue, how is it decided which node is going to send >>the mail on? > > There is no priority scheme among delivery agents. All agents of a particular > type get notified when there is a queue entry waiting to be processed, and > whichever one gets to that entry first does the processing. If you are using a cluster alias then it doesn't matter what node the mail is delivered from. See the NCP manual for cluster alias and also look for the mail flags so all nodes on the cluster will get notification when mail is delivered. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake NSI-DECnet (SPAN): 28284::ake ================================================================================ Archive-Date: Sat, 04 Jul 1992 01:05:55 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX running in a cluster Message-ID: <1992Jul2.183421.6069@dayton.saic.com> Date: 2 Jul 92 18:34:21 EDT References: <0095CF79.AD14C620.29762@SOL1.GPS.CALTECH.EDU> To: MX-List@WKUVX1.BITNET In article <0095CF79.AD14C620.29762@SOL1.GPS.CALTECH.EDU>, Carl J Lydick writes: >>We are running a non-MX compatible TCP/IP on two nodes in the cluster. I want >>to start migrating people away from that IP's mailer toward MX. Is there a way >>I can, on a per-user basis, have the other mailer's protocol name (let's face > ------------------- >>it, it's WINS%) be interpreted as MX%? > > $ DEFINE/SYSTEM/EXEC MAIL$PROTOCOL_WINS MX_MAILSHR > > Doesn't sound per-user to me :-). You simply have to add the line: > $ DEFINE MAIL$PROTOCOL_WINS MX_MAILSHR > to the LOGIN.COM of the user in question. Actually what I believe he needs is to define the above on the nodes that are running MX. This way users can still use win% but it will go through MX. Thanks not the question he asked but I think it should have been knowing what he wants to do. After a specific period of time tell the users that win% will be going away and then force them to use mx%. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake NSI-DECnet (SPAN): 28284::ake ================================================================================ Archive-Date: Sat, 04 Jul 1992 09:03:28 CDT Date: Sat, 04 Jul 1992 15:55:25 +0200 From: Helmut Springer Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <0095D13A.A06E9DC0.8380@bonnie.physik.uni-stuttgart.de> list ================================================================================ Archive-Date: Mon, 06 Jul 1992 08:21:59 CDT Sender: hornlo@okra.millsaps.edu Date: Mon, 06 Jul 1992 07:37:46 CDT From: Larry Horn - Mgr Sys and Ops - x1142 Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: hornlo@okra.millsaps.edu Message-ID: <0095D287.6FFDA700.9540@okra.millsaps.edu> Subject: Re: Insert angle brackets in MAIL replies with TPU >> To: mx-list@vms.ecs.rpi.edu >> Date: 20 Apr 92 14:23:47 GMT >> From: dvbig@dymaxion.ns.ca >> >> I am running MX on VMS 5.4. I would like to be able to automatically insert >> angle brackets in front of replied-to or forwarded messages. It is not obvious >> to me how this is done. My guess is that it would require specifying a TPU >> command file to execute whenever MAIL invokes TPU, but there doesn't appear >> to be any way to do this via logical names or MAIL settings. >> - --- >> Ben Armstrong, Software Development bus: (902)422-1973 >> Dymaxion Research Ltd., fax: (902)421-1267 >> Halfiax, Nova Scotia, Canada B3J 1R2 Internet: bg@dymaxion.ns.ca This is rather a late reply, but I just got around to setting up something like this for myself. I'd saved Armstrong's message in case no one else provided an answer. I believe you can just put the procedure in TPU$COMMAND.TPU and it will be loaded automatically. However, I have a customized section file, so I'll give directions for that. to install 1. load this message into an EVE buffer, stripping all but the TPU code 2. press 3. enter EXTEND THIS 4. press 5. enter SAVE SYS$LOGIN:EVE$SECTION 6. exit EVE 7. in MAIL --> SET EDITOR TPU 8. in LOGIN.COM --> $ define [/job] TPU$SECTION SYS$LOGIN:EVE$SECTION 9. in LOGIN.COM --> $ MAI*L == "MAIL/EDIT=(FORWARD,REPLY=EXTRACT,SEND)" 10. @LOGIN [ deassign any MAIL$EDIT logical you have so the internal editor setting will take affect ] to use [this works inside ANYTHING that uses EVE, not just mail] 1. press 2. enter COMM [the EVE_ prefix on the procedure turns it into builtin] 3. enter brackets or whatever you can make it always do brackets if you don't want the prompt, but this is convenient if you're quoting a quote, or, as I do, use it for other things besides mail this puts ">> " (assuming that's what you entered) in front of EVERY line in the current buffer note that it remembers your current position and restores your cursor to it modifying it to use a select range is an exercise for the reader ----- cut here --------------------------------------------------------------- procedure EVE_comments ! Last edit: 25-JUN-1992 09:09:23.69 !--------------------------------------------------------------------- ! ! This procedure inserts the text at the ! beginning of each line of the current buffer. ! ! If you would prefer that it not prompt for the marker, ! just delete (or comment out) the LOOP - END LOOP section ! that prompts for the comment marker ! ! [sent to MX-List 6-JUL-1992 07:17:27.83] ! Larry Olin Horn / Systems Manager ! Millsaps College / Computer Services / 1701 N State St / Jackson, MS 39202 USA ! Internet: hornlo@okra.millsaps.edu (VMS) / hornlo@uw1301.millsaps.edu (Ultrix) ! !--------------------------------------------------------------------- local saved_pos, test_pos, saved_timer, saved_timed_message, flag, comment_string, line_count, total_lines; on_error [OTHERWISE] : message(Error_Text); endon_error; saved_pos := mark(none); saved_timer := get_info(system,"timer"); saved_timed_message := get_info(system,"timed_message"); position(beginning_of(current_buffer)); set(timer,on,"[commenting]"); line_count := 0; ! *** edit the following line to put in your favorite comment marker ! *** this will be overridden by the prompt below comment_string := ">> "; ! *** comment out or delete this LOOP/ENDLOOP section if you don't ! *** want to be prompted for the marker at all flag := 0; loop exitif flag; flag := eve$prompt_string("", comment_string, "Comment marker: ", "Please enter a comment marker string" ); endloop; ! *** end prompting section loop position( line_begin ); test_pos := mark( none ); exitif test_pos = end_of( current_buffer ); line_count := line_count + 1; copy_text( comment_string ); move_vertical( 1 ); endloop; total_lines := get_info(current_buffer,"record_count"); message( fao("Commented !ZL of !ZL line!%S", line_count, total_lines) ); if saved_timer then set(timer, ON, saved_timed_message); else set(timer, OFF, saved_timed_message); endif; position(saved_pos); endprocedure; ================================================================================ Archive-Date: Mon, 06 Jul 1992 09:05:59 CDT Sender: hornlo@okra.millsaps.edu Date: Mon, 06 Jul 1992 08:01:35 CDT From: Larry Horn - Mgr Sys and Ops - x1142 Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: hornlo@okra.millsaps.edu Message-ID: <0095D28A.C3A3CEE0.9561@okra.millsaps.edu> Subject: Re: MX and VAXclusters Thanks for the suggestions on getting a cluster alias to work with MX. It turns out that adding the proper MX records on our nameserver helps a lot . It didn't work before because I didn't increment the "serial number" for the database. The following (edited) configuration makes a vanilla MX V3.1 installation work with either of these: user@okra.millsaps.edu user@millsaps.edu without having to separately define any logicals or rewrite rules. ----------- @ IN SOA uw1301.millsaps.edu. postmaster.uw1301.millsaps.edu. ( 9207043 ; Serial 300 ; Refresh - 5 minutes 60 ; Retry - 1 minute 1209600 ; Expire - 2 weeks 43200 ) ; Minimum - 12 hours IN NS uw1301.millsaps.edu. IN NS noc.sura.net. >> IN MX 10 okra01.millsaps.edu. >> IN MX 20 okra02.millsaps.edu. >> IN MX 30 mirage.millsaps.edu. ; ; Ultrix workstation uw1301 IN A 151.160.8.12 >> IN MX 0 uw1301.millsaps.edu. ; VAXcluster alias okra IN A 151.160.8.99 >> IN MX 10 okra01.millsaps.edu. >> IN MX 20 okra02.millsaps.edu. >> IN MX 30 mirage.millsaps.edu. ; ; VAXcluster nodes okra01 IN A 151.160.8.8 >> IN MX 0 okra01.millsaps.edu. okra02 IN A 151.160.8.11 >> IN MX 0 okra02.millsaps.edu. mirage IN A 151.160.8.3 >> IN MX 0 mirage.millsaps.edu. ================================================================================ Archive-Date: Mon, 06 Jul 1992 09:18:21 CDT Date: Mon, 06 Jul 1992 09:50:46 EDT From: "Brian Tillman, Facilities, x8425" Reply-To: MX-List@WKUVX1.BITNET To: ake@dayton.saic.com CC: mx-list@WKUVX1.BITNET Message-ID: <0095D29A.0484DB20.3626@swdev.si.com> Subject: Re: MX running in a cluster >That's not the question he asked but I think it should have >been knowing what he wants to do. I'm completely aware of the system-wide logical name that will make MX recognize the WINS% prefix. I want to ask a few, select people to try MX, without making them change all of the mail logical names they have established (all of which contain WINS%) and solicit their comments prior to informing the general populous of MX's availability. I wanted a logical name that those individuals could define that would make MX recognize WINS% for their process only. Apparently, it doesn't exist. -----------------------------+-------------------------------- 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: Mon, 06 Jul 1992 10:10:25 CDT Date: Mon, 06 Jul 1992 09:56:49 CDT From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095D29A.DCD30060.20556@SHSU.edu> Subject: Re: MX running in a cluster On Mon, 06 Jul 1992 09:50:46 EDT, Brian Tillman posted: > I'm completely aware of the system-wide logical name that will make MX > recognize the WINS% prefix. I want to ask a few, select people to try MX, > without making them change all of the mail logical names they have > established (all of which contain WINS%) and solicit their comments prior > to informing the general populous of MX's availability. I wanted a logical > name that those individuals could define that would make MX recognize WINS% > for their process only. Apparently, it doesn't exist. The story changes once again. If you have the specific people in mind, simply include in *their* LOGIN.COM files: DEFINE MAIL$PROTOCOL_WINS MX_MAILSHR As an alternate, maybe place in everyone's LOGIN.COM file: $!! DO NOT REMOVE OR ALTER THE FOLLOWING LINES UNDER ANY CIRCUMSTANCES $!! THESE SHOULD BE THE LAST THREE LINES OF YOUR LOGIN.COM FILE. $ @SYS$SYSTEM:SPECIAL_SYSTEM_LOGIN and in SYS$SYSTEM:SPECIAL_SYSTEM_LOGIN.COM include something along the lines of: $ user = f$edit(f$getjpi("","username"),"upcase,trim,collapse") $ if user .eqs. "BED_GDG" then goto special_wins $ ....... $ EXIT $SPECIAL_WINS: $ DEFINE MAIL$PROTOCOL_WINS MX_MAILSHR This is not something we do here, nor is it standard DEC stuff, but I think it ought to be. This allows for user-specific changes, by node if you are on a cluster since SYS$SYSTEM points to a searchpath of node-specific, then cluster-wide. This will allow what you are after without a problem (well, a problem to get it in place, but once in place, you've got the freedom to play, by user and by node, to your heart's content). While I have indicated these as the last three lines, it might be better to use these as the first three lines, before the $ IF F$MODE() types of strings, but I haven't really thought about that (seems as if placing them at the start might be better, but at the end will be good for interactive use, where I expect it matters). 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: Mon, 06 Jul 1992 11:33:13 CDT Date: Mon, 06 Jul 1992 12:11:37 EDT From: "Brian Tillman, Facilities, x8425" Reply-To: MX-List@WKUVX1.BITNET To: bed_gdg@SHSU.edu CC: mx-list@WKUVX1.BITNET Message-ID: <0095D2AD.B128BD20.3660@swdev.si.com> Subject: Re: MX running in a cluster >The story changes once again. If you have the specific people in mind, >simply include in *their* LOGIN.COM files: > DEFINE MAIL$PROTOCOL_WINS MX_MAILSHR Well, actually the story didn't change again, because what I asked for the second time is what I stated in the original posting as well. According to the MX manuals, MAIL$PROTOCOL_xxx must be an executive mode logical name. Do you know for sure, because you've actually tried it, that the above suggestion will work? When a logical name is defined in executive mode, there's usually a good reason for it (Matt, Hunter, can you say what the reason is?). -----------------------------+-------------------------------- 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: Mon, 06 Jul 1992 11:42:21 CDT Date: Mon, 06 Jul 1992 11:42:08 CDT From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: tillman@swdev.si.com Message-ID: <0095D2A9.92A6D200.6211@WKUVX1.BITNET> Subject: Re: MX running in a cluster "Brian Tillman, Facilities, x8425" writes: > >>If you have the specific people in mind, >>simply include in *their* LOGIN.COM files: >> DEFINE MAIL$PROTOCOL_WINS MX_MAILSHR > [...] >According to the MX manuals, MAIL$PROTOCOL_xxx must be an executive mode logical >name. Do you know for sure, because you've actually tried it, that the above >suggestion will work? When a logical name is defined in executive mode, there's >usually a good reason for it (Matt, Hunter, can you say what the reason is?). > It will work if it's not an executive-mode logical. In general, the reason that some logicals are required to be defined in executive mode is to ensure that users can't override the values. Some applications specifically translate logical names specifying executive mode, since privileges (CMEXEC) are required to define such a logical. Some software also specifically checks for the executive mode logical in the *system* logical name table, because that requires still more privileges (SYSNAM and others). MAIL does *not* require a system, executive-mode logical for the MAIL$PROTOCOL_xxxxx logical, so defining it as above will work OK. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Mon, 06 Jul 1992 15:36:44 CDT Date: Mon, 06 Jul 1992 16:30:00 EDT From: "Jonathan E. Hardis" Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX running in a cluster To: MX-List@WKUVX1.BITNET CC: hardis@vax844.phy.nist.gov Message-ID: <0095D2D1.CA1417C0.3292@vax844.phy.nist.gov> > As an alternate, maybe place in everyone's LOGIN.COM file: > $!! DO NOT REMOVE OR ALTER THE FOLLOWING LINES UNDER ANY CIRCUMSTANCES > $!! THESE SHOULD BE THE LAST THREE LINES OF YOUR LOGIN.COM FILE. > $ @SYS$SYSTEM:SPECIAL_SYSTEM_LOGIN > and in SYS$SYSTEM:SPECIAL_SYSTEM_LOGIN.COM include something along the lines > of: > $ user = f$edit(f$getjpi("","username"),"upcase,trim,collapse") > $ if user .eqs. "BED_GDG" then goto special_wins > $ ....... > $ EXIT > $SPECIAL_WINS: > $ DEFINE MAIL$PROTOCOL_WINS MX_MAILSHR Can't you do the same basic thing in SYS$MANAGER:SYLOGIN.COM, without the need for altering individual LOGIN.COM files? ================================================================================ Archive-Date: Mon, 06 Jul 1992 18:24:59 CDT From: Subject: Re: MX running in a cluster Message-ID: <1992Jul6.215303.1214@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <0095D2A9.92A6D200.6211@WKUVX1.BITNET> Date: Mon, 6 Jul 1992 21:53:03 GMT To: MX-List@WKUVX1.BITNET In article <0095D2A9.92A6D200.6211@WKUVX1.BITNET>, "Hunter Goatley, WKU" writes: >"Brian Tillman, Facilities, x8425" writes: >>According to the MX manuals, MAIL$PROTOCOL_xxx must be an executive mode logical >>name. Do you know for sure, because you've actually tried it, that the above >>suggestion will work? When a logical name is defined in executive mode, there's >>usually a good reason for it (Matt, Hunter, can you say what the reason is?). >> >It will work if it's not an executive-mode logical. [...] >MAIL does *not* require a system, executive-mode logical for the >MAIL$PROTOCOL_xxxxx logical, so defining it as above will work OK. It used to have to be an exec-mode logical, back when MX required you to install MAIL.EXE with privileges, because the image activator uses exec-mode- only logical name translation when merging a new image in with one that's installed with privileges. If you currently have MAIL.EXE installed with privileges for the benefit of another mailer, or you're running a version of MX prior to V3.0, then you will probably have to use an exec-mode logical. It doesn't have to be in the system logical name table, though. It can be in a process logical name table and still be effective. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Mon, 06 Jul 1992 21:16:40 CDT Date: Mon, 06 Jul 1992 18:12:12 PST From: Carl J Lydick Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX running in a cluster Sender: carl@SOL1.GPS.CALTECH.EDU To: MX-List@WKUVX1.BITNET Message-ID: <0095D2E0.10CC00C0.29896@SOL1.GPS.CALTECH.EDU> >>That's not the question he asked but I think it should have >>been knowing what he wants to do. >I'm completely aware of the system-wide logical name that will make MX recogniz e >the WINS% prefix. I want to ask a few, select people to try MX, without making >them change all of the mail logical names they have established (all of which >contain WINS%) and solicit their comments prior to informing the general >populous of MX's availability. I wanted a logical name that those individuals >could define that would make MX recognize WINS% for their process only. >Apparently, it doesn't exist. Somehow, then, you missed my message on the subject. The logical name does NOT have to be in the system table. If you define it in the user's process table, that will suffice. ================================================================================ Archive-Date: Mon, 06 Jul 1992 21:25:10 CDT Date: Mon, 06 Jul 1992 18:17:41 PST From: Carl J Lydick Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX running in a cluster Sender: carl@SOL1.GPS.CALTECH.EDU To: MX-List@WKUVX1.BITNET Message-ID: <0095D2E0.D4A55500.29898@SOL1.GPS.CALTECH.EDU> >On Mon, 06 Jul 1992 09:50:46 EDT, Brian Tillman posted: >> I'm completely aware of the system-wide logical name that will make MX >> recognize the WINS% prefix. I want to ask a few, select people to try MX, >> without making them change all of the mail logical names they have >> established (all of which contain WINS%) and solicit their comments prior >> to informing the general populous of MX's availability. I wanted a logical >> name that those individuals could define that would make MX recognize WINS% >> for their process only. Apparently, it doesn't exist. >The story changes once again. If you have the specific people in mind, >simply include in *their* LOGIN.COM files: > DEFINE MAIL$PROTOCOL_WINS MX_MAILSHR >As an alternate, maybe place in everyone's LOGIN.COM file: > $!! DO NOT REMOVE OR ALTER THE FOLLOWING LINES UNDER ANY CIRCUMSTANCES > $!! THESE SHOULD BE THE LAST THREE LINES OF YOUR LOGIN.COM FILE. > $ @SYS$SYSTEM:SPECIAL_SYSTEM_LOGIN >and in SYS$SYSTEM:SPECIAL_SYSTEM_LOGIN.COM include something along the lines >of: > $ user = f$edit(f$getjpi("","username"),"upcase,trim,collapse") > $ if user .eqs. "BED_GDG" then goto special_wins > $ ....... > $ EXIT > $SPECIAL_WINS: > $ DEFINE MAIL$PROTOCOL_WINS MX_MAILSHR >This is not something we do here, nor is it standard DEC stuff, but I think >it ought to be. This allows for user-specific changes, by node if you are >on a cluster since SYS$SYSTEM points to a searchpath of node-specific, then >cluster-wide. This will allow what you are after without a problem (well, >a problem to get it in place, but once in place, you've got the freedom to >play, by user and by node, to your heart's content). While I have >indicated these as the last three lines, it might be better to use these as >the first three lines, before the $ IF F$MODE() types of strings, but I >haven't really thought about that (seems as if placing them at the start >might be better, but at the end will be good for interactive use, where I >expect it matters). Or, you could do it the supported way: Instead of having LOGIN.COM call back to a system-wide procedure, put the stuff you want done for all users in a procedure pointed to by the system logical name SYS$SYLOGIN. This procedure will be executed before their LOGIN.COM, and there's no way for them to avoid having the procedure run. ================================================================================ Archive-Date: Mon, 06 Jul 1992 21:28:45 CDT Date: Mon, 06 Jul 1992 18:23:03 PST From: Carl J Lydick Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX running in a cluster Sender: carl@SOL1.GPS.CALTECH.EDU To: xxxx%"Mx-List@WKUVX1.BITNET"@SOL1.GPS.CALTECH.EDU Message-ID: <0095D2E1.949BC9C0.29903@SOL1.GPS.CALTECH.EDU> >>The story changes once again. If you have the specific people in mind, >>simply include in *their* LOGIN.COM files: >> DEFINE MAIL$PROTOCOL_WINS MX_MAILSHR >Well, actually the story didn't change again, because what I asked for the >second time is what I stated in the original posting as well. >According to the MX manuals, MAIL$PROTOCOL_xxx must be an executive mode logica l >name. Do you know for sure, because you've actually tried it, that the above >suggestion will work? When a logical name is defined in executive mode, there' s >usually a good reason for it (Matt, Hunter, can you say what the reason is?). Yes, I've actually tried it, as I told you the first time I said it would work. Just to convince you, I defined MAIL$PROTOCOL_XXXX to be MX_MAILSHR as a supervisor-mode logical name. This message is being sent to XXXX%"MX-LIST@WKUVX1.BITNET" ================================================================================ Archive-Date: Mon, 06 Jul 1992 22:30:43 CDT Date: Mon, 06 Jul 1992 22:24:18 CDT From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095D303.48E02720.22785@SHSU.edu> Subject: Re: MX running in a cluster On Mon, 06 Jul 1992 18:17:41 PST, Carl J Lydick posted: > Or, you could do it the supported way: Instead of having LOGIN.COM call > back to a system-wide procedure, put the stuff you want done for all users > in a procedure pointed to by the system logical name SYS$SYLOGIN. This > procedure will be executed before their LOGIN.COM, and there's no way for > them to avoid having the procedure run. The idea I was attempting to get at was to put it at the end of their LOGIN.COM. I am well aware of the "supported" way. I am also aware of how many strange things get in a user's LOGIN.COM from Lord knows where which can re-define quite a few things ("but my friend at Somewhere U sent me his LOGIN.COM, which I copied verbatim -- why can't I do..... it's properly defined, he said"; unfortunately, it is indeed properly defined for his system, but you've seriously mucked up anything on *our* system in your account for you to be able to do that!). I wish there was some supported way to have a POST_SYS$SYSLOGIN.COM to do this. The only way I am aware to achieve this is to put it in the user's LOGIN.COM. That was what I was after. If you know of a supported way to handle this, as a post-LOGIN.COM procedure, I'd love to see it. 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: Tue, 07 Jul 1992 02:44:42 CDT Date: Tue, 07 Jul 1992 08:45:49 EDT From: Peter Kobe Reply-To: MX-List@WKUVX1.BITNET To: MX-List%WKUVX1.bitnet@ibm.rhrz.uni-bonn.de Message-ID: <0095D35A.1BC4FDE0.25345@PIB1.physik.uni-bonn.de> Subject: Re: MX running in a cluster I didn't follow the whole discussion. So excuse, if I am on the wrong train. The %-construct in VMS-Mail directs Mail to call sys$library:xxx_mailshr.exe if xxx was the protocol-prefix (PSI% calls PSI_MAILSHR, MX% calls MX_MAILSHR etc.) So if you want to keep the old habbit of using WIN% but want to use the MX routines, just copy mx_mailshr.exe to win_mailshr.exe and you get what you want. I didn't look for the xxx_mailshrP routines, so there may be a conflict. Peter ===================================================================== Peter Kobe Internet: system@pib1.physik.uni-bonn.de Physikalisches Institut HEPNET: 13562::SYSTEM Universitaet Bonn Tel: (49) 228 73 3222 D 53 Bonn ================================================================================ Archive-Date: Wed, 08 Jul 1992 08:57:50 CDT Date: Wed, 08 Jul 1992 09:13:02 EDT From: "Brian Tillman, Facilities, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <0095D427.13A23BA0.3962@swdev.si.com> Subject: FWD: MX Mail, re routing messages I'm forwarding this question from the Info-VAX list: ------------------------------------------------------------- I have a question about the MX mail software, we have just installed it and it seems very nice. But, what can one do to re-route messages which have come in while the path rules were set incorrectly. Messages don't seem to be re-processed when you correct the rules, or maybe I've still got the rules wrong. I'm trying to forward messages addressed to: (yes I did do an mcp reset) user%gih@grv.grace.cri.nz to: gih::user (via decnet) The entry is not only now stuck wrong, but also seems to crash SMTP every time it tries to process this message. Any help/suggestions will be appreciated, if there is interest I will summarize. Chris Pugmire, srghcxp@grace.cri.nz Details follow: $ type mx*log.log; 6-JUL-1992 15:58:12.86 Processing queue entry number 1818 on node GRV 6-JUL-1992 15:58:13.42 Recipient: , route= 6-JUL-1992 15:58:13.42 SMTP_SEND: looking up host name $ $ mcp que show 1818 /full Entry: 1814, Origin: [SMTP] Status: IN-PROGRESS, size: 471 bytes Created: 3-JUL-1992 15:19:23.99, expires 2-AUG-1992 15:19:23.99 Last modified 6-JUL-1992 15:58:13.16 SMTP entry #1818, status: IN-PROGRESS, size: 471 bytes Created: 3-JUL-1992 15:19:41.74, expires 2-AUG-1992 15:19:23.99 Last modified 6-JUL-1992 15:58:12.69 Recipient #1: $ $ mcp show path Domain-to-path mappings: Domain="grv.grace.cri.nz", Path=Local Domain="grv.dsir.govt.nz", Path=Local, Route="GRV.GRACE.CRI.NZ" Domain="grace.dsir.govt.nz", Path=Local, Route="GRV.GRACE.CRI.NZ" Domain="grace.grace.cri.nz", Path=Local, Route="GRV.GRACE.CRI.NZ" Domain="grace.cri.nz", Path=Local, Route="GRV.GRACE.CRI.NZ" Domain="grv::*", Path=Local, Route="GRV.GRACE.CRI.NZ" Domain="gih::*", Path=Local, Route="GRV.GRACE.CRI.NZ" Domain="[131.203.8.2]", Path=Local Domain="[131.203.8.1]", Path=Local Domain="*.UUCP", Path=SMTP, Route="uunet.uu.net" Domain="*.BITNET", Path=SMTP, Route="cunyvm.cuny.edu" Domain="*", Path=SMTP $ mcp show rewrite Address-rewriting rules: Rewrite "<{u}@GIH>" => "" Rewrite "<{u}%GIH@grv.grace.cri.nz>" => "" Chris Pugmire, srghcxp@grace.cri.nz or srghcxp@grv.dsir.govt.nz -------------------------------------------------------------------------------- -----------------------------+-------------------------------- 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, 08 Jul 1992 13:24:47 CDT Date: Wed, 8 Jul 92 14:18:13 -0400 From: Kuo-ching Liu Reply-To: MX-List@WKUVX1.BITNET Message-ID: <9207081818.AA17044@bottom.magnus.acs.ohio-state.edu> it produces the following error messages: ****************************************************************************** %INSTALL-E-FAIL, failed to CREATE entry for DISK$CCL4:MX_MAILSHR.EXE -SYSTEM-F-SECTBLFUL, section table (process/global) is full %INSTALL-E-FAIL, failed to CREATE entry for DISK$CCL4:FLQ_SHR.EXE -SYSTEM-F-SECTBLFUL, section table (process/global) is full %INSTALL-E-FAIL, failed to CREATE entry for DISK$CCL4:DOMAIN_EXPANSION.E XE -SYSTEM-F-SECTBLFUL, section table (process/global) is full %SYSTEM-W-NOSUCHFILE, no such file \MX_EXE:MAILQUEUE.EXE\ %INSTALL-E-FAIL, failed to CREATE entry for DISK$CCL4:MAILQUEUE.EXE -INSTALL-E-EXISTS, Known File Entry for a version of this file already exists %DCL-W-IVVERB, unrecognized command verb - check validity and spelling \QUIT\ ******************************************************************************* Can you give me some ideas to fix the problems? Thank you! E-mail: kliu@magnus.acs.ohio-state.edu ~ Kuo-Ching Liu ~ ================================================================================ Archive-Date: Wed, 08 Jul 1992 13:42:32 CDT Subject: Re: strange SMTP adress errors Message-ID: <1992Jul8.160019.27025@news.arc.nasa.gov> From: Date: Wed, 8 Jul 1992 16:00:19 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: usenet@news.arc.nasa.gov References: To: MX-List@WKUVX1.BITNET In article , felix@smoky.ikf.physik.uni-frankfurt.de (Felix the double Helix) writes: >i have a problem with MX031c. It appears that the SMTP_SERVER is not >accepting some legal Mail-Adresses, in general the ones that come without >a hostname. [...] That's because addresses without hostnames are _not_ legal. That's one of the areas where MX is absolutely inflexible -- probably too much so. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Wed, 08 Jul 1992 13:58:17 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: strange SMTP adress errors Date: 8 Jul 92 09:56:06 GMT Message-ID: Sender: (Usenet News Account) To: MX-List@WKUVX1.BITNET Hi! i have a problem with MX031c. It appears that the SMTP_SERVER is not accepting some legal Mail-Adresses, in general the ones that come without a hostname. This is a screen snapshot: 220 IKF007.IKF.PHYSIK.UNI-FRANKFURT.DE MX V3.1C SMTP server ready at Wed, 08 Jul 1992 11:56:46 EDT HELO c3000 250 Hello, c3000 MAIL FROM: 250 MAIL command accepted. RCPT TO: 501 Syntax error in address also, it rejects adresses such as ikf007!user. i'm not a VMS expert, and it might be that i've overlooked something in the manual, but what can be done to fix this? there are lots of mailers that are generating just the user id for the RCPT TO: line in the mail and MX is rejecting all of them. thanx for any information and so long, felix -- Felix Gaehtgens, IKF Postmaster Institut fuer Kernphysik, August Euler-Str. 2-6 Frankfurt/Main 90, West Germany EMAIL: felix@smoky.ikf.physik.uni-frankfurt.de ================================================================================ Archive-Date: Wed, 08 Jul 1992 14:17:57 CDT Date: 08 Jul 1992 13:04:55 -0600 (MDT) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX Installation problems To: MX-List@WKUVX1.BITNET CC: kliu@magnus.acs.ohio-state.edu Message-ID: <01GM4XQJCAW20000AQ@VAXF.COLORADO.EDU> Kuo-ching Liu wrote: >it produces the following error messages: > >****************************************************************************** > >%INSTALL-E-FAIL, failed to CREATE entry for DISK$CCL4:MX_MAILSHR.EXE >-SYSTEM-F-SECTBLFUL, section table (process/global) is full >%INSTALL-E-FAIL, failed to CREATE entry for DISK$CCL4:FLQ_SHR.EXE >-SYSTEM-F-SECTBLFUL, section table (process/global) is full >%INSTALL-E-FAIL, failed to CREATE entry for DISK$CCL4:DOMAIN_EXPANSION. E >XE >-SYSTEM-F-SECTBLFUL, section table (process/global) is full >%SYSTEM-W-NOSUCHFILE, no such file > \MX_EXE:MAILQUEUE.EXE\ >%INSTALL-E-FAIL, failed to CREATE entry for DISK$CCL4:MAILQUEUE.EXE >-INSTALL-E-EXISTS, Known File Entry for a version of this file already exists >%DCL-W-IVVERB, unrecognized command verb - check validity and spelling > \QUIT\ > >******************************************************************************* > > Can you give me some ideas to fix the problems? Thank you! $ HELP ERRORS SECTBLFUL Errors SECTBLFUL section table (process/global) is full Facility: SYSTEM, VMS System Services Explanation: The system space allocated to maintain information about sections is full; no more sections can be created. User Action: If you have created many private sections, you may have to delete sections when they are no longer needed. If the error occurs while a global section, in particular a system global section, is being created, this message may indicate that not enough space is allocated at system generation for the section tables. Notify the system manager of the deficiency. Arrgh - another "Notify the system manager ...". You need to increase the SYSGEN parameter GBLSECTIONS (modify MODPARAMS.DAT, AUTOGEN the system, and reboot). -Dan Wing, DWING@UH01.Colorado.EDU, WING_D@UCOLMCC.BITNET, (DGW11) Systems Programmer, University Hospital, Denver ================================================================================ Archive-Date: Wed, 08 Jul 1992 14:45:49 CDT Date: Wed, 08 Jul 1992 15:02:18 EDT From: Ta Fuh Chiam Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095D457.DE69B2C0.31259@VULCAN.CBA.OHIOU.EDU> Subject: RE: > >it produces the following error messages: > >****************************************************************************** > >%INSTALL-E-FAIL, failed to CREATE entry for DISK$CCL4:MX_MAILSHR.EXE >-SYSTEM-F-SECTBLFUL, section table (process/global) is full >%INSTALL-E-FAIL, failed to CREATE entry for DISK$CCL4:FLQ_SHR.EXE >-SYSTEM-F-SECTBLFUL, section table (process/global) is full >%INSTALL-E-FAIL, failed to CREATE entry for DISK$CCL4:DOMAIN_EXPANSION.E >XE >-SYSTEM-F-SECTBLFUL, section table (process/global) is full >%SYSTEM-W-NOSUCHFILE, no such file > \MX_EXE:MAILQUEUE.EXE\ >%INSTALL-E-FAIL, failed to CREATE entry for DISK$CCL4:MAILQUEUE.EXE >-INSTALL-E-EXISTS, Known File Entry for a version of this file already exists >%DCL-W-IVVERB, unrecognized command verb - check validity and spelling > \QUIT\ > >******************************************************************************* > > Can you give me some ideas to fix the problems? Thank you! > YOu need to increase the SYSGEN parameter GBLSECTIONS. Do this in MODPARAMS.DAT and run AUTOGEN, of course. Ta Fuh Chiam ============================================================================ Ta Fuh Chiam Ohio University, College of Business Administration / Phone: (614)593-2088 Management Information Systems FAX: (614)593-1388 Copeland Hall 22 INTERNET : chiam@vulcan.cba.ohiou.edu Athens, Ohio 45701, U.S.A. or : chiam@ouvaxa.ucls.ohiou.edu BITNET : CHIAM@OUACCVMB Use my first Internet address if at all possible. Disclaimer: What I have said are my opinions, not of anyone else. ============================================================================ ================================================================================ Archive-Date: Wed, 08 Jul 1992 15:53:54 CDT Date: Wed, 08 Jul 1992 22:42:10 +0200 From: Helmut Springer Reply-To: MX-List@WKUVX1.BITNET To: MX-List%WKUVX1.BITNET@rusvm1.rus.uni-stuttgart.de Message-ID: <0095D498.1C7D9F00.8756@bonnie.physik.uni-stuttgart.de> Subject: RE: FWD: MX Mail, re routing messages >But, what can one do to re-route messages which have come in while >the path rules were set incorrectly. Messages don't seem to be >re-processed when you correct the rules, or maybe I've still got the >rules wrong. I'm trying to forward messages addressed to: >(yes I did do an mcp reset) > > user%gih@grv.grace.cri.nz >to: > gih::user (via decnet) > >The entry is not only now stuck wrong, but also seems to crash SMTP >every time it tries to process this message. > I think the rewritten address must also be an internet-style address... I'm running MX as VMS-Mail-SMTP-gate here on BONNIE with the following rewrite-rule : "<{USER}%{HOST}.DNET@BONNIE.PHYSIK.UNI-STUTTGART.DE>" => "<""{HOST}::{USER}""@BONNIE.PHYSIK.UNI-STUTTGART.DE>" ^^^^^^^^^^^^^^^^^^ Note the double "" around the host::user-term in the rule. I found them necessary to keep this address intact when the router recognizes BONNIE as local and passes the mail to the LOCAL-agent which sends it to the address host::user via decnet. (the domain .DNET for decnet-nodes is just local convention...) hope this helps Helmut PS: If you want to use your node as gate from decnetmail to smtp, (e.g. to use the address mx_node::mx%"user@internet.node") in VMS-Mail, a sender-address is generated that needs another rewrite-rule to be replyable.... I can send you this one also if you need it... -- Helmut Springer University of Stuttgart, FRG User HelpDesk Computing Center CipPool Physics Department springer@rus.uni-stuttgart.de helmut@bonnie.physik.uni-stuttgart.de phone: +49 711 685-4828 1291::helmut (BelWue) %SYSTEM-W-MAILONSYS, there is real mail installed on this system ================================================================================ Archive-Date: Wed, 08 Jul 1992 17:11:07 CDT Sender: jabii%pvii@ethel.cray.com Date: Wed, 08 Jul 1992 15:03:19 PDT From: jabii@pvii.ethel.cray.com Reply-To: MX-List@WKUVX1.BITNET To: MX-List@RPIECSVX.BITNET Message-ID: <0095D458.02F048C0.11457@pvii.ethel.cray.com> HELP ================================================================================ Archive-Date: Wed, 08 Jul 1992 17:11:18 CDT Sender: jabii%pvii@ethel.cray.com Date: Wed, 08 Jul 1992 15:04:36 PDT From: jabii@pvii.ethel.cray.com Reply-To: MX-List@WKUVX1.BITNET To: MX-LIST@WKUVX1.BITNET Message-ID: <0095D458.30832780.11459@pvii.ethel.cray.com> HELP ================================================================================ Archive-Date: Wed, 08 Jul 1992 17:29:18 CDT Sender: jabii%pvii@ethel.cray.com Date: Wed, 08 Jul 1992 15:21:40 PDT From: jabii@pvii.ethel.cray.com Reply-To: MX-List@WKUVX1.BITNET To: MX-LIST@RPIECSVX.BITNET Message-ID: <0095D45A.9301C680.11465@pvii.ethel.cray.com> HELP ================================================================================ Archive-Date: Wed, 08 Jul 1992 17:29:29 CDT Sender: jabii%pvii@ethel.cray.com Date: Wed, 08 Jul 1992 15:22:21 PDT From: jabii@pvii.ethel.cray.com Reply-To: MX-List@WKUVX1.BITNET To: MX-LIST@WKUVX1.BITNET Message-ID: <0095D45A.AB504F40.11467@pvii.ethel.cray.com> HELP ================================================================================ Archive-Date: Wed, 08 Jul 1992 18:22:06 CDT Date: Thu, 09 Jul 1992 01:11:39 +0200 From: Helmut Springer Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <0095D4AC.FE1C03C0.8801@bonnie.physik.uni-stuttgart.de> Subject: RE: MX Mail re routing MISTAKE !! >I'm running MX as VMS-Mail-SMTP-gate here on BONNIE with the following >rewrite-rule : > >"<{USER}%{HOST}.DNET@BONNIE.PHYSIK.UNI-STUTTGART.DE>" > => "<""{HOST}::{USER}""@BONNIE.PHYSIK.UNI-STUTTGART.DE>" > ^^^^^^^^^^^^^^^^^^ > >Note the double "" around the host::user-term in the rule. argl.....here I made a mistake....forgot something You have to type in tripple """ in MCP to get double "" !!! sorry Helmut -- Helmut Springer University of Stuttgart, FRG User HelpDesk Computing Center CipPool Physics Department springer@rus.uni-stuttgart.de helmut@bonnie.physik.uni-stuttgart.de phone: +49 711 685-4828 1291::helmut (BelWue) %SYSTEM-W-MAILONSYS, there is real mail installed on this system ================================================================================ Archive-Date: Wed, 08 Jul 1992 19:48:28 CDT Sender: kish@DRWHO.IAC.HONEYWELL.COM Date: Wed, 08 Jul 1992 17:40:51 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: <0095D46E.04B5C480.1115@DRWHO.IAC.HONEYWELL.COM> Subject: DECNET SMTP Question? Clearly I am missing something. How do you address DECnet nodes running MX? How are they addressed from the TCP/IP side? Im shure this is a FAQ but I have lost the pointer to the archives since the move. Where is this list archived for FTP access? KISH@IASDV1.IASD.HONEYWELL.COM ================================================================================ Archive-Date: Thu, 09 Jul 1992 01:19:43 CDT From: Subject: Re: DECNET SMTP Question? Message-ID: <1992Jul9.055828.10188@cco.caltech.edu> Sender: news@cco.caltech.edu Reply-To: MX-List@WKUVX1.BITNET References: <0095D46E.04B5C480.1115@DRWHO.IAC.HONEYWELL.COM> Date: Thu, 9 Jul 1992 05:58:28 GMT To: MX-List@WKUVX1.BITNET In article <0095D46E.04B5C480.1115@DRWHO.IAC.HONEYWELL.COM>, kish@DRWHO.IAC.HONEYWELL.COM writes: >Clearly I am missing something. How do you address >DECnet nodes running MX? However you want to, as long as you've got a PATH specified in your MX configuration that matches whatever you've chosen to call the sites and which specifies that the path is via DNSMTP. >How are they addressed from the TCP/IP side? The preferred way is to have an MX record placed in a nameserver that direct mail to them through the machine you're using as an SMTP/DNSMTP gateway. If you can't do this, then address them as: user%dnsmtp_host@smtp_dnsmtp_gateway or @smtp_dnsmtp_gateway:user@dnsmtp_host -------------------------------------------------------------------------------- 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: Thu, 09 Jul 1992 01:19:49 CDT From: Subject: RE: FWD: MX Mail, re routing messages Message-ID: <1992Jul9.054718.9848@cco.caltech.edu> Sender: news@cco.caltech.edu Reply-To: MX-List@WKUVX1.BITNET References: <0095D498.1C7D9F00.8756@bonnie.physik.uni-stuttgart.de> Date: Thu, 9 Jul 1992 05:47:18 GMT To: MX-List@WKUVX1.BITNET In article <0095D498.1C7D9F00.8756@bonnie.physik.uni-stuttgart.de>, Helmut Springer writes: >>But, what can one do to re-route messages which have come in while >>the path rules were set incorrectly. Messages don't seem to be >>re-processed when you correct the rules, or maybe I've still got the >>rules wrong. I'm trying to forward messages addressed to: >>(yes I did do an mcp reset) >> >> user%gih@grv.grace.cri.nz >>to: >> gih::user (via decnet) >> >>The entry is not only now stuck wrong, but also seems to crash SMTP >>every time it tries to process this message. >> >I think the rewritten address must also be an internet-style address... > >I'm running MX as VMS-Mail-SMTP-gate here on BONNIE with the following >rewrite-rule : > >"<{USER}%{HOST}.DNET@BONNIE.PHYSIK.UNI-STUTTGART.DE>" > => "<""{HOST}::{USER}""@BONNIE.PHYSIK.UNI-STUTTGART.DE>" Well, several people have told him how to set up his rewrite rules, but nobody's addressed his original question: He's got these files sitting in FLQ_DIR. They've already been processed by the ROUTER, and, because of his earlier erroneous rewrite rules, they now have invalid addresses, and he wants to know how to get them delivered. OK, here's what you do: 1) Use FLQU to cancel the local, smtp, etc. queue entries (but NOT the router entries); 2) Use FLQU to ready the ROUTER entries. This will cause the ROUTER to reprocess the readied entries, this time making use of your updated rewrite rules. -------------------------------------------------------------------------------- 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: Thu, 09 Jul 1992 10:14:08 CDT Date: Thu, 09 Jul 1992 11:07:25 EDT From: "Jonathan E. Hardis" Reply-To: MX-List@WKUVX1.BITNET Subject: RE: DECNET SMTP Question? To: MX-List@WKUVX1.BITNET CC: kish@DRWHO.IAC.HONEYWELL.COM, hardis@vax844.phy.nist.gov Message-ID: <0095D500.390605A0.3359@vax844.phy.nist.gov> In Message-ID: <0095D46E.04B5C480.1115@DRWHO.IAC.HONEYWELL.COM> KISH@IASDV1.IASD.HONEYWELL.COM asks: > Where is this list archived for FTP access? The archives are available from ARCHIVES@WKUVX1.BITNET (send a message containing SEND MX-LIST.yyyy-mm, where "yyyy" is the year and "mm" is the month. For more info, send HELP.) The archives are also available via anonymous ftp from ftp.spc.edu in directory [.MACRO32.LISTS.MX]. ================================================================================ Archive-Date: Thu, 09 Jul 1992 10:26:50 CDT Date: Thu, 09 Jul 1992 10:21:58 CDT From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095D4F9.DF826E20.30711@SHSU.edu> Subject: RE: FWD: MX Mail, re routing messages On Thu, 9 Jul 1992 05:47:18 GMT, Carl J Lydick posted: > Well, several people have told him how to set up his rewrite rules, but > nobody's addressed his original question: He's got these files sitting in > FLQ_DIR. They've already been processed by the ROUTER, and, because of his > earlier erroneous rewrite rules, they now have invalid addresses, and he > wants to know how to get them delivered. > > OK, here's what you do: > 1) Use FLQU to cancel the local, smtp, etc. queue entries (but NOT > the router entries); > 2) Use FLQU to ready the ROUTER entries. > > This will cause the ROUTER to reprocess the readied entries, this time > making use of your updated rewrite rules. If you're running MX 3.x (with MCP :== $MX_EXE:MCP), the command: MCP QUEUE READY router_entry_number will take care of this on one fell swoop for each entry you wish to reset. If you are on any version, Carl's outline above will work -- if you're still on any version prior to 3.x, it's the *only* way to do it. Quick qualifier -- definitely on the version 3.1 family and, if I recall correctly, also in 3.0. I don't recall exactly when Matt put this functionality into MCP, but I believe it was one major justification for moving the version number from 2.x to 3.x. 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, 09 Jul 1992 14:55:18 CDT Date: Thu, 09 Jul 1992 15:48:06 EDT From: Matt The Midnight Mortician Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: harttree@vax1.elon.edu Message-ID: <0095D527.6E8D90E0.879@vax1.elon.edu> Subject: A COUPLE OF QUESTIONS...... Elon College has just joined the Internet and our VAX 8350 running VMS 5.5 is using MX 3.1C and CMU/TEK version 6.6 to communicate with the "real world" Excuse my ignorance or lack of finesse in asking the following: 1. What is / are the most popular or common improvements you have done on your system to improve the efficiency/speed of MX 2. Is there "freeware" front-ends to VMS MAIL that can improve or make more appealing using MAIL/MX. 3. Is there a facility like ELM for the vax that will allow VMS MAIL to translate long user/Internet names into simple no brainers like DOUG would be in real life DOUG@EAST.PODUNK.EDU I would prefer something with a manageable interface that would be pain less to use. Logicals cause headaches if some one defines the wrong one. 4. Off the subject but...... What are good lists to join or resources to query for system managers starting out on the internet for example: A. A info-vax list or something like such. B. A programming forum or place to grab utilities (FTP) for the vax C. How have you offered NEWS/newsgroups/usenet to your users??? Any help/comments - time of day - etc. would be appreciated Including interesting places to show students about Internet. Thanks Matt "System security is a state of mind. Real security is a warm blanket." Matthew T. Harttree HARTTREE@VAX1.ELON.EDU +919-584-2295 / +919-570-8120 (voice mail) / +919-584-2575 (FAX) ------------------------------ [insert famous libility release statement here!] ================================================================================ Archive-Date: Thu, 09 Jul 1992 15:21:29 CDT Date: 09 Jul 1992 14:11:13 -0600 (MDT) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: Re: A COUPLE OF QUESTIONS...... To: MX-List@WKUVX1.BITNET Message-ID: <01GM6E8UX1Z60000AQ@VAXF.COLORADO.EDU> Matthew T. Harttree, HARTTREE@VAX1.ELON.EDU, wrote: [... I deleted questions I couldn't answer ...] > 3. Is there a facility like ELM for the vax that will allow VMS > MAIL to translate long user/Internet names into simple no brainers > like DOUG would be in real life DOUG@EAST.PODUNK.EDU > I would prefer something with a manageable interface that would be pain > less to use. Logicals cause headaches if some one defines the wrong > one. You could setup a front-end that would allow for reasonable logical names that could then be executed by SYS$SYLOGIN everytime a user logs in. I just put a "$" in front of all of my logial names I use as aliases, like: $ DEFINE/NOLOG $INFOVAX VAXF::IN%"""INFO-VAX@SRI.COM""" and haven't had any problems (yes, I know $'s are reserved for DIGITAL). > 4. Off the subject but...... > What are good lists to join or resources to query for system managers > starting out on the internet for example: > A. A info-vax list or something like such. The INFO-VAX list can be found at LISTSERV@UGA.BITNET. If there is a site closer to you, the LISTSERV software knows it and will forward your request to that site. > B. A programming forum or place to grab utilities (FTP) for the vax INFO-VAX is a good place. There is a monthly software list -- I'll send it to you after this message. -Dan Wing, DWING@UH01.Colorado.EDU, WING_D@UCOLMCC.BITNET, (DGW11) Systems Programmer, University Hospital, Denver ================================================================================ Archive-Date: Thu, 09 Jul 1992 15:44:28 CDT Sender: syssand@CCVAX.CCS.CSUS.EDU Date: Thu, 09 Jul 1992 13:33:17 PDT From: "John F. Sandhoff" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: HARTTREE@VAX1.ELON.EDU, syssand@CCVAX.CCS.CSUS.EDU Message-ID: <0095D514.98F457A0.13040@CCVAX.CCS.CSUS.EDU> Subject: RE: A COUPLE OF QUESTIONS...... 1. What is / are the most popular or common improvements you have done on your system to improve the efficiency/speed of MX > 2. Is there "freeware" front-ends to VMS MAIL that can improve or make more appealing using MAIL/MX. One nifty routine is MAIL_EDIT.COM, which allows for nifty replying to messages (automatically inserts '>' in the original message, etc etc). The author was posting an updated version but I have temporarily lost track of a) the author's name (SORRY! he *really* deserves credit too) b) where I got it from - probably the [...contrib] directory when Matt ran the archives - try looking on ftp.spc.edu c) MY copy of it. I did some major housekeeping on my account and...oops > 4. Off the subject but...... > What are good lists to join or resources to query for system managers > starting out on the internet for example: > A. A info-vax list or something like such. Yeah, there's one of them - but I left my brain at home and don't remember where it is :-) > B. A programming forum or place to grab utilities (FTP) for the vax Ahh! Here's one I can answer! FTP to rml2.sri.com and grab VAX_LIST.TXT! Really nifty routines can be found off this list! > C. How have you offered NEWS/newsgroups/usenet to your users??? Check out both Matt Madison's NEWSRDR and ANU-NEWS > Any help/comments - time of day - etc. would be appreciated It's 1:30 PM PDT John F. Sandhoff, University Network Support California State University, Sacramento sandhoff@csus.edu ================================================================================ Archive-Date: Thu, 09 Jul 1992 16:27:01 CDT Sender: westerm@aclcb.purdue.edu Date: Thu, 09 Jul 1992 16:12:48 EDT From: Rick Westerman Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095D52A.E1C64D60.28856@bchm1.aclcb.purdue.edu> Subject: RE: A COUPLE OF QUESTIONS...... 1. What is / are the most popular or common improvements you have done on your system to improve the efficiency/speed of MX There is a program modification that allows users not to have to use the 'MX%"address"' form but rather just 'address'. This should be available on the MX anonymous FTP server or you can send me mail. -- Rick Rick Westerman System Manager of the AIDS Center Laboratory westerm@aclcb.purdue.edu for Computational Biochemistry (ACLCB), BCHM (317) 494-0505 bldg., Purdue University, W. Lafayette, IN 47907 ================================================================================ Archive-Date: Fri, 10 Jul 1992 11:51:43 CDT Date: Fri, 10 Jul 1992 11:51:34 CDT From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <0095D5CF.8E0497E0.15214@WKUVX1.BITNET> Subject: New e-mail fileserver: MXSERVER@WKUVX1.BITNET OK, I'm setting up an experiment.... Some of you have been asking about getting MX031 via e-mail because you don't have access to anonymous ftp. Well, I (finally) packaged up MX031 and created a new file server on my system. To the new file server is MXSERVER@WKUVX1.BITNET. MX will *not* be available from FILESERV because I want to try to limit when the files go out. MX031 is a VMS_SHARE file in 113 parts (60 blocks)---that's pretty big. Unlike the way Matt used to set it up, I've (for the time being) created one big .MFTU file containing all the VMSINSTAL savesets. The only caveat at the moment is that MXSERVER files are only sent between 5PM CDT and 6AM CDT. If very many people request MX031, my poor 9600-baud BITNET link will take a while to let everything go through. SO: a) please be patient---it may take several days for everything to make it through b) MX_REVC_UPGRADE031 has also been moved from FILESERV to MXSERVER (use SEND MX_REVC_UPGRADE031) c) don't everybody ask for it at once d) this is an experiment---depending on how things go, I may have to limit the number of files a person can get in a day, etc. Of course, MX is available via ftp from ftp.spc.edu in [.MX]. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Fri, 10 Jul 1992 22:14:21 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: MX 3.1C Deleting Trailing Spaces? Message-ID: <1992Jul9.172220.9293@calspan.com> Sender: usenet@calspan.com Date: Thu, 9 Jul 1992 17:22:20 GMT To: MX-List@WKUVX1.BITNET We are running MX V3.1C on a VAXcluster using TGV's Multinet. We are using MX's SMTP server, and Multinet's is disabled (I just checked). We had problems with a mail message containing a uuencoded file. When the message was sent to the VAX, it was corrupted; when it was sent to a Sun, it was OK. We determined that the reason is that trailing spaces are being deleted at some point during the transfer to the VAX. I checked the .MSG_TEXT file for the message in [MX.QUEUE]. The trailing spaces are gone at that point, so I believe I have narrowed it down to the MX SMTP server. I doubt that the Sun is doing this. Is this a known problem/feature? Is there a fix? Thanks in advance for any help. -- Dave Yearke, yearke@calspan.com "The First Amendment is a tragic amendment because everyone is going to have his or her feelings hurt and your government is not here to protect you from having your feelings hurt." --- Kurt Vonnegut ================================================================================ Archive-Date: Sat, 11 Jul 1992 08:24:55 CDT From: roseberry@taney.uscghq.uscg.mil Reply-To: MX-List@WKUVX1.BITNET Subject: 250 Verification fails for HELO Message-ID: <1992Jul11.002016.43@taney.uscghq.uscg.mil> Date: 11 Jul 92 00:20:16 EST To: MX-List@WKUVX1.BITNET I am having some problems using TELNET and port 25 to come back into my VAX running MX 3.1C and CMU/TEK 6.6-3. I am logged into a privileged account and coming back into the same VAX called node TANEY. Here is what I see: $ TELNET TANEY /PORT=25 220 TANEY.USCGHQ.USCG.MIL MX V3.1C SMTP server ready at Fri, 10 Jul 1992 23:59:25 EDT HELO g-ate 250 Verification failed for g-ate Even though I am logged into node TANEY, I am "pretending" to be node G-ATE so as to see why the mail doesn't work. I am assuming that the verification that fails is done by seeing if there is a proper entry in the HOSTS.TXT file. In that file I have: HOST:152.119.253.3:g-ate,g-ate.uscghq.uscg.mil,g-ate.uscghq.gov:UNISYS:BTOS:: What is my next step in determining why the verification fails ? Thanks. - Bert Roseberry roseberry@taney.uscghq.uscg.mil US Coast Guard ================================================================================ Archive-Date: Sat, 11 Jul 1992 16:34:53 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX 3.1C Deleting Trailing Spaces? Message-ID: <1992Jul11.113349.6077@dayton.saic.com> Date: 11 Jul 92 11:33:48 EDT References: <1992Jul9.172220.9293@calspan.com> To: MX-List@WKUVX1.BITNET In article <1992Jul9.172220.9293@calspan.com>, yearke@calspan.com (Dave Yearke) writes: > We are running MX V3.1C on a VAXcluster using TGV's Multinet. We are > using MX's SMTP server, and Multinet's is disabled (I just checked). > > We had problems with a mail message containing a uuencoded file. When > the message was sent to the VAX, it was corrupted; when it was sent to > a Sun, it was OK. We determined that the reason is that trailing spaces > are being deleted at some point during the transfer to the VAX. > > I checked the .MSG_TEXT file for the message in [MX.QUEUE]. The trailing > spaces are gone at that point, so I believe I have narrowed it down to > the MX SMTP server. I doubt that the Sun is doing this. There might be a problem with the server but what is really wrong is you are using an outdated version of uuencode that relies on some trailing spaces. I have an updated copy that uses a different character instead and is still compatable with other uuencode programs. It is written in C and I can send the source to you if you desire. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation (EFA1) ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake NSI-DECnet (SPAN): 28284::ake ================================================================================ Archive-Date: Sat, 11 Jul 1992 16:34:58 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX 3.1C Deleting Trailing Spaces? Message-ID: <1992Jul11.115949.6078@dayton.saic.com> Date: 11 Jul 92 11:59:49 EDT References: <1992Jul9.172220.9293@calspan.com> <1992Jul11.113349.6077@dayton.saic.com> To: MX-List@WKUVX1.BITNET In article <1992Jul11.113349.6077@dayton.saic.com>, ake@dayton.saic.com (Earle Ake) writes: > In article <1992Jul9.172220.9293@calspan.com>, yearke@calspan.com (Dave Yearke) writes: >> We are running MX V3.1C on a VAXcluster using TGV's Multinet. We are >> using MX's SMTP server, and Multinet's is disabled (I just checked). >> >> We had problems with a mail message containing a uuencoded file. When >> the message was sent to the VAX, it was corrupted; when it was sent to >> a Sun, it was OK. We determined that the reason is that trailing spaces >> are being deleted at some point during the transfer to the VAX. >> >> I checked the .MSG_TEXT file for the message in [MX.QUEUE]. The trailing >> spaces are gone at that point, so I believe I have narrowed it down to >> the MX SMTP server. I doubt that the Sun is doing this. > > There might be a problem with the server but what is really wrong is > you are using an outdated version of uuencode that relies on some trailing > spaces. I have an updated copy that uses a different character instead and > is still compatable with other uuencode programs. It is written in C and I > can send the source to you if you desire. I just ran am experiment and the problem is not the smtp server but somewhere else within MX. As the following shows the server sees the trailing spaces but indeed when it is delivered and also in the .msg_text file the trailing spaces have been deleted. I would think they should be preserved. -Earle STM[1]: Send "220 DAYVC.DAYTON.SAIC.COM MX V3.1C SMTP server ready at Sat, 11 Jul 1992 11:49:46 EDT" STM[1]: Receive "HELO MVB.SAIC.COM" STM[1]: Send "250 Hello, MVB.SAIC.COM" STM[1]: Receive "MAIL FROM:" STM[1]: Send "250 MAIL command accepted." STM[1]: Receive "RCPT TO:" STM[1]: Send "250 Recipient okay (at least in form)" STM[1]: Receive "DATA" STM[1]: Send "354 Start mail input; end with ." STM[1]: Receive "Received: from MVB.SAIC.COM by MVB.SAIC.COM (CHCS-MailMan V7.2) with SMTP" STM[1]: Receive " id 7306499; Sat, 11 Jul 1992 08:35:11 PDT" STM[1]: Receive "Received: from DAYVAX.SAIC.COM by MVB.SAIC.COM with DECnet;" STM[1]: Receive " Sat, 11 Jul 1992 08:35:11 PDT" STM[1]: Receive "Subject: test message" STM[1]: Receive "Date: Sat, 11 Jul 1992 08:35:11" STM[1]: Receive "Message-ID: <7306499@MVB.SAIC.COM>" STM[1]: Receive "From: Earle Ake " STM[1]: Receive "X-VMS-TO: MVB::"ake@dayton.saic.com"" STM[1]: Receive "To: ake@dayton.saic.com" STM[1]: Receive "" STM[1]: Receive "This is a test " STM[1]: Receive "with trailing spaces " STM[1]: Receive "" STM[1]: Receive "" STM[1]: Receive "-Earle " STM[1]: Receive "." STM[1]: Send "250 Message received and queued." STM[1]: Receive "QUIT" STM[1]: Send "221 DAYVC.DAYTON.SAIC.COM Service closing transmission channel" STM[1]: Receive "QUIT" ================================================================================ Archive-Date: Sat, 11 Jul 1992 20:28:47 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: 250 Verification fails for HELO Message-ID: <1992Jul11.203701.6079@dayton.saic.com> Date: 11 Jul 92 20:37:01 EDT References: <1992Jul11.002016.43@taney.uscghq.uscg.mil> To: MX-List@WKUVX1.BITNET In article <1992Jul11.002016.43@taney.uscghq.uscg.mil>, roseberry@taney.uscghq.uscg.mil writes: > > I am having some problems using TELNET and port 25 to come back > into my VAX running MX 3.1C and CMU/TEK 6.6-3. I am logged into > a privileged account and coming back into the same VAX called > node TANEY. Here is what I see: > > $ TELNET TANEY /PORT=25 > 220 TANEY.USCGHQ.USCG.MIL MX V3.1C SMTP server ready at Fri, 10 > Jul 1992 23:59:25 EDT > HELO g-ate > 250 Verification failed for g-ate > > Even though I am logged into node TANEY, I am "pretending" to be > node G-ATE so as to see why the mail doesn't work. > > I am assuming that the verification that fails is done by seeing if > there is a proper entry in the HOSTS.TXT file. In that file I have: > > HOST:152.119.253.3:g-ate,g-ate.uscghq.uscg.mil,g-ate.uscghq.gov:UNISYS:BTOS:: Try changing your HOST entry to have your FQDN first in the list! HOST:152.119.253.3:g-ate.uscghq.uscg.mil,g-ate.uscghq.gov,g-ate:UNISYS:BTOS:: I don't think MX likes it if you send it a HELO without a FQDN. Try sending it this and I bet it will work: $ TELNET TANEY /PORT=25 220 TANEY.USCGHQ.USCG.MIL MX V3.1C SMTP server ready at Fri, 10 Jul 1992 23:59:25 EDT HELO g-ate.uscghq.uscg.mil -Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation (EFA1) ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake NSI-DECnet (SPAN): 28284::ake ================================================================================ Archive-Date: Sun, 12 Jul 1992 02:49:25 CDT From: Subject: Re: MX 3.1C Deleting Trailing Spaces? Message-ID: <2040@fnnews.fnal.gov> Date: 12 Jul 92 05:54:07 GMT References: <1992Jul9.172220.9293@calspan.com>,<1992Jul11.113349.6077@dayton.saic.com> Sender: news@fnnews.fnal.gov Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <1992Jul11.113349.6077@dayton.saic.com>, ake@dayton.saic.com (Earle Ake) writes: >In article <1992Jul9.172220.9293@calspan.com>, yearke@calspan.com (Dave Yearke) writes: >> (somewhere in the process of getting mail through MX, trailing spaces >> are dropped) >> > There might be a problem with the server but what is really wrong is >you are using an outdated version of uuencode that relies on some trailing >spaces. I have an updated copy that uses a different character instead and >is still compatable with other uuencode programs. It is written in C and I >can send the source to you if you desire. Since one cannot always control what program uuENcoded the file one wants to read, the standard fix (at least amongst the newer PC versions) is to have a smarter uuDEcode program that looks at the first letter in the uuencoded line which contains the "this line contains this number of characters", and if the line actually has fewer than that number, defaults to the assumption that they were blanks which were stripped. Obviously, if there are fewer than the appropriate number of characters in a line for some other reason and the originals weren't spaces, then the result is a corrupted file, but you would have gotten that anyway if the uudecode had just given up before trying the fill-the-line-out-with-spaces method. When _sending_ an encoded file, you have the option of using a brighter uuENcode or a "table" section which replaces the space with something else (just as one should use something like xxencode or MFTU if one knows that the route the message will take will pass through an EBCDIC-using machine on the way). When _receiving_ a file, your only hope is uuDEcode software bright enough to avoid the most common problems (the other main one being file-type incompatibilities: record delimiters being various combinations of CR's and LF's on various machines). Now that I've said this, does anyone know of such a "bright uuDEcode" for a VMS system? The VMS version of uudecode I use here is plain vanilla (executable, no source) and tolerates no disagreement between character count as advertised and as it really is, so I've occasionally had the same difficulty as Mr. Yearke (but wasn't clever enough to figure out that it was MX's fault :-). I've ended up either re-adding the trailing spaces by hand or downloading to a PC and letting the smarter uudecode there handle it (depending on where the file was going to end up anyway). Thanks. ------------------------------------------------------------------------ George J Perkins gjperkins@fnal.fnal.gov perkins@msupa.pa.msu.edu ================================================================================ Archive-Date: Sun, 12 Jul 1992 14:48:38 CDT From: Subject: Re: 250 Verification fails for HELO Message-ID: <1992Jul12.191739.28266@cco.caltech.edu> Sender: news@cco.caltech.edu Reply-To: MX-List@WKUVX1.BITNET References: <1992Jul11.002016.43@taney.uscghq.uscg.mil>,<1992Jul11.203701.6079@dayton.saic. com> Date: Sun, 12 Jul 1992 19:17:39 GMT To: MX-List@WKUVX1.BITNET In article <1992Jul11.203701.6079@dayton.saic.com>, ake@dayton.saic.com (Earle Ake) writes: >In article <1992Jul11.002016.43@taney.uscghq.uscg.mil>, roseberry@taney.uscghq.uscg.mil writes: >> >> I am having some problems using TELNET and port 25 to come back >> into my VAX running MX 3.1C and CMU/TEK 6.6-3. I am logged into >> a privileged account and coming back into the same VAX called >> node TANEY. Here is what I see: >> >> $ TELNET TANEY /PORT=25 >> 220 TANEY.USCGHQ.USCG.MIL MX V3.1C SMTP server ready at Fri, 10 >> Jul 1992 23:59:25 EDT >> HELO g-ate >> 250 Verification failed for g-ate >> >> Even though I am logged into node TANEY, I am "pretending" to be >> node G-ATE so as to see why the mail doesn't work. >> >> I am assuming that the verification that fails is done by seeing if >> there is a proper entry in the HOSTS.TXT file. In that file I have: >> >> HOST:152.119.253.3:g-ate,g-ate.uscghq.uscg.mil,g-ate.uscghq.gov:UNISYS:BTOS:: > > Try changing your HOST entry to have your FQDN first in the list! > >HOST:152.119.253.3:g-ate.uscghq.uscg.mil,g-ate.uscghq.gov,g-ate:UNISYS:BTOS:: > > I don't think MX likes it if you send it a HELO without a FQDN. Try >sending it this and I bet it will work: > >$ TELNET TANEY /PORT=25 >220 TANEY.USCGHQ.USCG.MIL MX V3.1C SMTP server ready at Fri, 10 >Jul 1992 23:59:25 EDT >HELO g-ate.uscghq.uscg.mil No, the problem is that he's trying to pretend to be sending from a different node than he really is. MX checks the node name against the node address. If there's a conflict, it complains about a verification failure. -------------------------------------------------------------------------------- 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: Mon, 13 Jul 1992 02:37:30 CDT From: Subject: Re: MX 3.1C Deleting Trailing Spaces? Message-ID: <2041@fnnews.fnal.gov> Date: 13 Jul 92 05:16:54 GMT References: <1992Jul9.172220.9293@calspan.com>,<1992Jul11.113349.6077@dayton.saic.com>,<204 0@fnnews.fnal.gov> Sender: news@fnnews.fnal.gov Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <2040@fnnews.fnal.gov>, after mentioning some desireable features for "brighter" uudecode programs, I asked: >Now that I've said this, does anyone know of such a "bright uuDEcode" for >a VMS system? The VMS version of uudecode I use here is plain vanilla >(executable, no source) and tolerates no disagreement between character >count as advertised and as it really is,... Well, not being totally helpless, I decided to check on what's in the usual VMS ftp sites. Now that I have done so, I am pleased to report that there is at least one solution available. Since this has drifted far off the subject of MX, I am going to attempt to set Followup-to: to vmsnet.misc on the off chance that somebody might want to reply (I haven't tried to re-direct replies before, so I hope NEWSRDR does this as well as the rest of Matt Madison'F programs do their stuff :-). You folks getting this via mailing-list can just skip the rest if you're not interested. --- A package that works --- At black.cerritos.edu, in [.mailserv.uuencode_decode], there is a vms_share file with VAX-C source for uuencode and uudecode. The uuencode is smart enough to put a guard-character (lower-case 'a') after the last meaningful letter on each uuencoded line, to avoid blank-stripping in the first place, while the uudecode seems to be smart enough to handle stripped blanks (at least it worked on the test files I intentionally abused). It is not quite smart enough to totally ignore all non-uue stuff in the middles of files (such as mail headers when concatenating split uue files extracted from e-mail or netnews), but it seems to at least *try*. The fact that in my tests it did not always succeed (and did not always complain when it failed in this way) is just a warning that one should strip off such junk either manually or by some other procedure. The output of uudecode is in stream-LF mode, so you have to run it through some program (such as the bilf program which comes with the ZOO archiver) to restore fixed-record- length binaries. (bilf is limited to fixed-length-of-512; I'm not sure what one would use for any other fixed length, but there are probably utilities out there willing to do it [FILE ?]). --- comments on other available packages --- Less promising were the VAX-C files in [.mailserv.uuencode] at cerritos. Therse look like the plain vanilla versions I originally had just the executables to, or their near relatives. No blank-padding, etc. The compressed Backup saveset at ftp.spc.edu contained two packages, one the same as the "plain" VAX-C version at cerritos, and the other a Pascal version which uses an SMG$... screen-drawing interface. Unfortunately my tests showed that a file-->uuencode-->uudecode cycle with the Pascal version did not result in a file identical to the one I started with. There seem to be bugs in handling the ends of binary files both in encoding and in decoding. The .uue files the uuencode produced had a different next-to-"end" line compared with the ones produced by the uuencode from the first package I mentioned (which did reproduce the original file). It appears that it is somehow counting the number of characters incorrectly at the very end of the input file. The same number of characters appeared in the line as with the other package's .uue file, but the "how many characters in this line" character was different. Also, the uudecode tacked on a block of junk at the end of the output binary file both when decoding the .uue of its own uuencode and that of the other package's uuencode. This block seemed to consist of some nulls followed by a repeat of part of the true last record of the file, so I suspect that there is some bug in the buffer-cleanup at the end of the process. It does have the nice feature that it will restore a binary file as a fixed-length-record file without having to go through a conversion step, but since it doesn't do it quite right, I can hardly recommend it. Unlike the first package, which nicely skipped the mail-header stuff before the "begin" statement and only had a hard time making sense of the mail header I "carelessly" left in the middle of one of my test .uue files, this version of uuencode bit the big one even before reaching the "begin" or "table" lines, dying on an access violation while still chewing on mail-header. This package is labeled UUENCODE V1.8 and UUDECODE V1.9 by Christian Bode in its screen interface. If there are newer versions somewhere which address the problems I have mentioned, they would be worth a try, as it seems to be an otherwise nice implementation (the uuencode's default conversion table doesn't use spaces at all, replacing them with accent graves "`", AND it posts guard characters at the ends of lines; and while servicing the screen display probably slows the whole process down somewhat, it at least gives you something to watch while you're waiting ;-). ------------------------------------------------------------------------ George J Perkins gjperkins@fnal.fnal.gov perkins@msupa.pa.msu.edu ================================================================================ Archive-Date: Mon, 13 Jul 1992 10:16:00 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX 3.1C Deleting Trailing Spaces? Message-ID: <1992Jul12.090547.6080@dayton.saic.com> Date: 12 Jul 92 09:05:46 EDT References: <1992Jul9.172220.9293@calspan.com>,<1992Jul11.113349.6077@dayton.saic.com> <2040@fnnews.fnal.gov> To: MX-List@WKUVX1.BITNET In article <2040@fnnews.fnal.gov>, gjperkins@FNALA.FNAL.GOV (George J Perkins) writes: > Now that I've said this, does anyone know of such a "bright uuDEcode" for > a VMS system? The VMS version of uudecode I use here is plain vanilla > (executable, no source) and tolerates no disagreement between character > count as advertised and as it really is, so I've occasionally had the same > difficulty as Mr. Yearke (but wasn't clever enough to figure out that it > was MX's fault :-). I've ended up either re-adding the trailing spaces by > hand or downloading to a PC and letting the smarter uudecode there handle > it (depending on where the file was going to end up anyway). I just made the smarter uuencode/uudecode available for FTP. I have put the C sources, a command procedure to build it, and executables linked under VMS 4.7 up for anonymous FTP on dayton.saic.com [139.121.26.194]. UUDECODE.C;1 12/12 UUDECODE.EXE;1 7/9 UUENCODE.C;1 9/9 UUENCODE.EXE;1 7/9 UU_MAKE.COM;1 1/3 If you don't have FTP access, the sources can be mailed to you. Just send me an e-mail message. Have at it! Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation (EFA1) ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake NSI-DECnet (SPAN): 28284::ake ================================================================================ Archive-Date: Mon, 13 Jul 1992 11:06:09 CDT Sender: goathunter@WKUVX1.BITNET Date: Mon, 13 Jul 1992 11:05:49 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095D824.A940B460.496@WKUVX1.BITNET> Subject: Re: MX 3.1C Deleting Trailing Spaces? writes: > >In article <2040@fnnews.fnal.gov>, gjperkins@FNALA.FNAL.GOV (George J Perkins) > writes: >> Now that I've said this, does anyone know of such a "bright uuDEcode" for >> a VMS system? The VMS version of uudecode I use here is plain vanilla >> (executable, no source) and tolerates no disagreement between character [...] > > I just made the smarter uuencode/uudecode available for FTP. I have >put the C sources, a command procedure to build it, and executables linked >under VMS 4.7 up for anonymous FTP on dayton.saic.com [139.121.26.194]. > Not to be outdone 8-), I just added them to my UUCODE package (along with Christian Bode's Pascal version and the C version from Cerritos). I prefer Christian Bode's version, when I can use it. I use UUCAT from the Cerritos version to clean out all the junk. In any case, I've also included the EXEs and OBJs MFTU'ed for e-mail sites. You can find it on ftp.spc.edu; you'll need the following files: [.MACRO32]LZDCMP.EXE [.MACRO32]AAAREADME.TXT [.MACRO32.SAVESETS]UUCODE.BCK_Z You can get it via e-mail by sending the following commands in the body of a mail message to FILESERV@WKUVX1.BITNET: SEND UUCODE SEND FILESERV_TOOLS >If you don't have FTP access, the sources can be mailed to you. Just send me >an e-mail message. Have at it! > Thankes, Earle! Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Mon, 13 Jul 1992 11:50:04 CDT Sender: kish@DRWHO.IAC.HONEYWELL.COM Date: Mon, 13 Jul 1992 09:17:25 EDT From: kish@DRWHO.IAC.HONEYWELL.COM Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095D815.844F7380.1178@DRWHO.IAC.HONEYWELL.COM> Subject: Re: MX 3.1C Deleting Trailing Spaces? As an alternative load the VMS POSIX which has UUENCODE AND DECODE as part of it. Its Free except for distributeion media :) Karl ================================================================================ Archive-Date: Tue, 14 Jul 1992 15:26:15 CDT Sender: murphy@hal.hahnemann.edu Date: Tue, 14 Jul 1992 16:22:19 EDT From: murphy@hal.hahnemann.edu Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: murphy@hal.hahnemann.edu Message-ID: <0095D91A.0B0BFD80.8237@hal.hahnemann.edu> Subject: SMTP over DECnet questions There are several VAX systems on our network that are not running TCP/IP and have no access to the Internet. We would like to use one of our Internet-connected VAX hosts as a mail gateway for these systems. We have gotten SMTP over DECnet working between several of these systems and are quite happy with it. We are looking for advice on how to set up MX records and/or rewrite rules so that the outside world can send mail to these systems through our main system via SMTP over DECnet. The "gateway" system is currently running MX 3.0 and some of the "clients" are running MX 3.1C. The CONFIG.MCP file for the gateway system look like: ------------------------------------------------------------------------------- ! MX_ROOT:[000000]CONFIG.MCP;11 ! Created: 14-JUL-1992 09:44:02.32 by MXCONFIG ! DEFINE PATH "hal.hahnemann.edu" LOCAL DEFINE PATH "hannet.hahnemann.edu" LOCAL DEFINE PATH "hal" LOCAL DEFINE PATH "hannet" LOCAL DEFINE PATH "hahnemann.edu" LOCAL DEFINE PATH "[192.54.238.37]" LOCAL DEFINE PATH *.UUCP SMTP/ROUTE="uunet.uu.net" DEFINE PATH *.BITNET SMTP/ROUTE="cunyvm.cuny.edu" DEFINE PATH "hannet.dnet.hahnemann.edu" LOCAL DEFINE PATH "hannet.dnet" LOCAL DEFINE PATH "*.dnet.hahnemann.edu" DECNET_SMTP ! NOTE: The next path definition should always be LAST. DEFINE PATH * SMTP ! ! Done with routing information. ! DEFINE ALIAS "Postmaster" "murphy@hal.hahnemann.edu" DEFINE ALIAS "POSTMAST" "murphy@hal.hahnemann.edu" ! for BITNET compatibility ------------------------------------------------------------------------------- The Internet host name is hal and the DECnet node name is HANNET. The names are different because this system is due to be replaced by a new system which will have another DECnet node name (ie. HAL). We would like to have mail from the outside world, addressed as user@DECnet_host.hahnemann.edu to be delivered to user@DECnet_host.dnet.hahnemann.edu via the gateway system. I know that we will need to set up some MX records in our nameserver database and will probably need some rewrite rules for MX on the gateway. The documentation is a little sketchy in this area and I am hoping that someone might be able to point me in the right direction. Any help, suggestions, or commiserations will be greatly appreciated! Thanks! John ----------------------------------------------------------------------------- |John Murphy |Internet: murphy@hal.hahnemann.edu / / / /|Library System Manager |VMS Mail: HANNET::MURPHY, LIB::MURPHY /---/ / / |Hahnemann University |Voice: (215) 448-1042 / / /___/ |245 N. 15th St., MS 449 |Fax: (215) 448-8180 |Phila., PA 19102-1192 |Time,etc: (215) 846-1212 ----------------------------------------------------------------------------- "The shortest distance between two points is usually under repair..." ================================================================================ Archive-Date: Tue, 14 Jul 1992 20:08:28 CDT From: simons/G=Vic/S=Pittman/O=SE.Consultants/OU=ATLANTA@mhs.attmail.com Reply-To: MX-List@WKUVX1.BITNET Date: Tue Jul 14 17:21:24 GMT 1992 Subject: MX subscribe To: attmail!internet!MX-List@RPIECSVX.BITNET SUBSCRIBE ================================================================================ Archive-Date: Wed, 15 Jul 1992 03:42:41 CDT Sender: sys_hjk@lifra.lif.de Date: Wed, 15 Jul 1992 10:30:35 CET From: "Koch,Hans-Joachim" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@RPIECSVX.BITNET CC: sys_hjk@lifra.lif.de Message-ID: <0095D9B2.11F717E0.2253@lifra.lif.de> Subject: Update questions Hello dear mx-experts, I am running MX 3.0 since several months without problems. Now I want to update to the recent version 3.1c. Please help me with the following questions. Please forgive me, if these are FAQs, but I couldn't find answers to my problems in the Usenet mx group. 1. Is there some upgrade package from 3.0 to 3.1c? (I suppose: no) 2. I copied the new version 3.1 from the french DecusVAX (compressed savesets, mftu coded) and got one crc error for every saveset. The savesets seem to be ok (BACK/LIS works). Should I install it? 3. I got the REVC_UPDATE from MXSERVER. The description says: update from MX031A/B to version C. Can I use it for 3.1 (no A or B)? 4. Or should I forget about all upgrade problems and order the new version 3.1c completely from MXSERVER (a LOT of mails...)? Thank you very much for your help. -- Hans-Joachim Koch, Computer department of Lahmeyer International Lyoner Strasse 22, POB 71 06 51, D-6000 Frankfurt (Main) 71, Germany Phone: +49 69 6677-642, Fax: +49 69 6677-765, Tx: 413478 li d Email: koch@lifra.lif.de (or sys_hjk@lifra.lif.de or lifra@infohh.rmi.de) ================================================================================ Archive-Date: Wed, 15 Jul 1992 07:11:34 CDT From: edgecomb@ccrs.emr.ca Reply-To: MX-List@WKUVX1.BITNET From: Message-ID: <9207151202.AA21783@nova.ccrs.emr.ca> Subject: MX and SMTP mean non-delivery from non-priv user To: mx-list@WKUVX1.BITNET Date: Wed, 15 Jul 92 8:02:16 EDT I sent the following article to the newsgroup; it did not generate any replies. So I'm trying again via the mailing list address. I hope someone out there does know what's going on. --john Article 554 of vmsnet.mail.mx: Newsgroups: vmsnet.mail.mx Path: emr1!edgecomb From: edgecomb@ccrs.emr.ca (John Edgecombe) Subject: Re: MX (SMTP) and VMS Mail from remote node mean non-delivery Message-ID: <1992Jul9.153145.18521@emr1.emr.ca> Sender: news@emr1.emr.ca Nntp-Posting-Host: nova.ccrs.emr.ca Organization: Canada Centre for Remote Sensing, Ottawa References: <1992Jul9.114252.7861@emr1.emr.ca> Distribution: world Date: Thu, 9 Jul 1992 15:31:45 GMT In article <1992Jul9.114252.7861@emr1.emr.ca> edgecomb@ccrs.emr.ca (John Edgecom >There appears to be a bug in the MX interface between DECnet VMSmail and >SMTP (either Multinet or UCX) in the router module. > >A request received by VMS Mail from a different node does not get any >recipients when processed by MX. > >Example: on node ARTIST I give the command: > $ mail nl:a.b cloud::mx%edgecombe/subj=testing > >and the ROUTER debug file on CLOUD contains: > 9-JUL-1992 07:21:37.06 %PROCESS, Processing entry number 677 > 9-JUL-1992 07:21:37.22 %PROCESS, Status from READ_INFO was 00000001 > 9-JUL-1992 07:21:37.22 %PROCESS, Message originated in VMS Mail. > 9-JUL-1992 07:21:37.23 %PROCESS, will run domain expander on envelope address > 9-JUL-1992 07:21:37.23 %PROCESS, will run domain expander on message headers. > 9-JUL-1992 07:21:38.09 %PROCESS, Finished VMSmail-origin preprocessing. > 9-JUL-1992 07:21:38.09 %PROCESS, Marking this entry as finished. > >The result of MCP> QUEUE SHOW/ALL/FULL are: > Entry: 677, Origin: [Local] <"artist::edgecombe"@cloud.ccrs.emr.ca> > Status: FINISHED, size: 0 bytes > Created: 9-JUL-1992 07:21:35.81, expires 8-AUG-1992 07:21:35.81 > Last modified 9-JUL-1992 07:21:38.09 > > >I had discussed this with Matt a month and a half ago; at that time we >stopped using the SMTP (TCP/IP) interface; Matt suggested that >"since you're not running TCP/IP, you should delete the >domain expander that's currently being used." and the problem went >away. Now we are running TCP/IP (UCX); I re-installed MX from scratch >(version 3.1C), and the problem is back again. > >Matt mentioned that he had made some changes in the domain expander; I >think they are post-3.1C and do not know if they are relevant to this >problem. > >(The previous incarnation of this problem had been noticed with mailing >list handling, this incarnation is not restricted to that subset.) > >Any help would be greatly appreciated; we cannot afford TCP on all our >VMS machines, nor would it work, as we are connected to some sites by >DECNET routers (DECSA), that do not handle TCP/IP. To follow up with further information: This is not JUST a DECnet delivery of VMS MAIL, it also affects normal (i.e. unprivileged) users -- they also get no recipients for mail messages. This begins to look like a privilege problem -- should MX_MAILSHR[P] be installed with privileges (which?) for the gatewaying to take effect? --john John Edgecombe Canada Centre for Remote Sensing alternate Ottawa, Ontario, Canada ================================================================================ Archive-Date: Wed, 15 Jul 1992 07:54:48 CDT Sender: goathunter@WKUVX1.BITNET Date: Wed, 15 Jul 1992 07:54:36 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095D99C.473578E0.880@WKUVX1.BITNET> Subject: RE: Upgrading to MX v3.1C Someone, I've forgotten who, asked about upgrading to MX v3.1C from an earlier version of MX. If you get MX031 from either ftp.spc.edu or MXSERVER, you'll get MX v3.1C. There's no need to mess with the upgrade kit unless you're already running MX v3.1, v3.1A, or v3.1B. You can get MX v3.1C via anonymous ftp from ftp.spc.edu in [.MX]. You can also get it via the MX file server here. To get it, send the following commands in the body of a mail message to MXSERVER@WKUVX1.BITNET: SEND MX031 SEND FILESERV_TOOLS Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Wed, 15 Jul 1992 13:08:29 CDT From: edgecomb@ccrs.emr.ca Reply-To: MX-List@WKUVX1.BITNET From: Message-ID: <9207151757.AA19981@nova.ccrs.emr.ca> Subject: Re: MX and SMTP mean non-delivery from non-priv user To: mx-list@WKUVX1.BITNET Date: Wed, 15 Jul 92 13:57:47 EDT Even more information: I had set up my system so that I am running UCX 1.3A on only one node of my six-node VAXcluster (STORM). That node is running all the MX stuff (MX Router, MX Local, SMTP Server, MX MLF). I run all but SMTP Server on a second node (SNOW) for availability purposes, although that is presumably irrelevant, since the cluster hangs without quota if STORM goes down. This morning I changed the way reboot startups are done, resulting in SNOW not executing the MX startup file upon reboot (a bug) Now everything works fine -- DECnet mail delivered from other nodes to MX gets properly delivered, local non-privileged jobs can send mail properly, list and file servers work as expected, etc. Perhaps I should not run Router (specifically) on the node that does not have TCP/IP? --john John Edgecombe Canada Centre for Remote Sensing alternate Ottawa, Ontario, Canada ================================================================================ Archive-Date: Wed, 15 Jul 1992 19:07:05 CDT Subject: MX 3.1-C with UCX 1.3 Installation questions. Message-ID: <1429fnINNrlj@agate.berkeley.edu> From: Reply-To: MX-List@WKUVX1.BITNET Date: 15 Jul 92 22:39:51 GMT Keywords: incoming message acceptance problem. To: MX-List@WKUVX1.BITNET I've just finished installing MX3.1C on a machine running ucx1.3, and outgoing mail is delivered with no problem. Incoming mail, however, has a problem. As I am new to VMS, smtp, and MX, I don't know what to make of the error message that bounced back to my test mail site. I've looked in some of the MX docs to no avail. Anyway, here's the error message. Vince Reed UCSF Cardiothoracic Surgery (415)476-3437 From Wed Jul 15 14:08:20 1992 Date: Wed, 15 Jul 1992 14:11:11 PDT 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 jsrvx1.ucsf.edu): %MX_SMTP-F-TRANSACTION_FAI, transaction failed Transcript: Rcvd: 220 jsrvx1.ucsf.EDU MX V3.1C SMTP server ready at Wed, 15 Jul 1992 14:10:59 PDT Sent: HELO jsrvx1.ucsf.EDU Rcvd: 250 Hello, jsrvx1.ucsf.EDU Sent: MAIL FROM: Rcvd: 250 MAIL command accepted. Sent: RCPT TO: Rcvd: 250 Recipient okay (at least in form) Sent: DATA Rcvd: 354 Start mail input; end with . Rcvd: 554 Received too many times by this host. Sent: QUIT Rcvd: 221 jsrvx1.ucsf.EDU Service closing transmission channel ======================================================================== Message follows. Received: from jsrvx1.ucsf.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 Jul 1992 14:10:43 PDT Received: from jsrvx1.ucsf.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 Jul 1992 14:10:21 PDT Received: from jsrvx1.ucsf.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 Jul 1992 14:09:58 PDT Received: from jsrvx1.ucsf.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 Jul 1992 14:09:37 PDT Received: from jsrvx1.ucsf.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 Jul 1992 14:09:16 PDT Received: from jsrvx1.ucsf.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 Jul 1992 14:08:56 PDT Received: from jsrvx1.ucsf.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 Jul 1992 14:08:36 PDT Received: from cory.Berkeley.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 Jul 1992 14:08:19 PDT Received: by cory.Berkeley.EDU (5.57/Ultrix3.0-C) id AA23501; Wed, 15 Jul 92 14:05:00 -0700 Date: Wed, 15 Jul 92 14:05:00 -0700 From: breaux@cory.berkeley.edu (Charles Breaux) Message-ID: <9207152105.AA23501@cory.Berkeley.EDU> To: vince@jsrvx1.ucsf.edu Subject: Testing Just a test ================================================================================ Archive-Date: Wed, 15 Jul 1992 20:46:13 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: SMTP over DECnet questions Message-ID: <1992Jul15.195326.6084@dayton.saic.com> Date: 15 Jul 92 19:53:26 EDT References: <0095D91A.0B0BFD80.8237@hal.hahnemann.edu> To: MX-List@WKUVX1.BITNET In article <0095D91A.0B0BFD80.8237@hal.hahnemann.edu>, murphy@hal.hahnemann.edu writes: > We would like to have mail from the outside world, addressed as > > user@DECnet_host.hahnemann.edu > > to be delivered to > > user@DECnet_host.dnet.hahnemann.edu > > via the gateway system. > > I know that we will need to set up some MX records in our nameserver > database and will probably need some rewrite rules for MX on the gateway. > The documentation is a little sketchy in this area and I am hoping that > someone might be able to point me in the right direction. Any help, > suggestions, or commiserations will be greatly appreciated! Let's say you have node "hahnemann.edu" running the full MX and nodes "client1", and "client2" running SMTP over DECnet. First you setup MX on hahnemann.edu to know what to do with the mail: MCP> DEFINE PATH "client1.hahnemann.edu" DECnet_SMTP /ROUTE="Client1" MCP> DEFINE PATH "client2.hahnemann.edu" DECnet_SMTP /ROUTE="Client2" This will tell MX that for mail addressed to those nodes send them on via the DECnet_SMTP channel. Now for the MX records in the DNS: $ORIGIN hahnemann.edu. ; ; The mail for client1 is sent to hahnemann.edu ; client1 IN MX 10 hahnemann.edu ; ; The mail for client2 is sent to hahnemann.edu ; client2 IN MX 10 hahnemann.edu I think that might get you started. -Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation (EFA1) ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake NSI-DECnet (SPAN): 28284::ake ================================================================================ Archive-Date: Thu, 16 Jul 1992 07:35:26 CDT Date: Thu, 16 Jul 1992 08:29:28 EDT From: Irv Eisen <"ccstat::irv"@canctr.mc.duke.edu> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095DA6A.50D654E0.294@canctr.mc.duke.edu> Subject: RE: MX 3.1-C with UCX 1.3 Installation questions. <>Vince Reed <>UCSF Cardiothoracic Surgery <>(415)476-3437 <> <> Transcript: <> Rcvd: 220 jsrvx1.ucsf.EDU MX V3.1C SMTP server ready at Wed, 15 Jul 1992 <> 14:10:59 PDT <> Sent: HELO jsrvx1.ucsf.EDU <> Rcvd: 250 Hello, jsrvx1.ucsf.EDU <> Sent: MAIL FROM: <> Rcvd: 250 MAIL command accepted. <> Sent: RCPT TO: <> Rcvd: 250 Recipient okay (at least in form) <> Sent: DATA <> Rcvd: 354 Start mail input; end with . <> Rcvd: 554 Received too many times by this host. <> Sent: QUIT <> Rcvd: 221 jsrvx1.ucsf.EDU Service closing transmission channel I had a problem similar to this in Dec. Here is what Matt Madison said about it: -------------------------------------------------------------------------------- - >from CANCTR.MC.DUKE.EDU by CANCTR.MC.DUKE.EDU (MX V2.3) with SMTP; Mon, 09 Dec 1991 10:02:15 EST >by canctr.mc.duke.edu (MX V2.3) id 9327; Mon, 09 Dec 1991 10:01:59 EST >Mon, 09 Dec 1991 10:01:59 EST >Irv Eisen >irv@LOCALHOST ^^^^^^^^^ See this? Looks like maybe your UCX local host table is a bit screwy. I posted a message to MX-list a while back (and reposted it again very recently - check the archives) that describes what you need to check out as far as ensuring that your fully-qualified domain name is set up as your primary host name in your UCX host table. If you can't figure it out right now, turn off the domain expander (by renaming MX_EXE:DOMAIN_EXPANSION.EXE , deassigning MX_SITE_DOM_EXPANSION, and restarting the Router) - that will work around the problem until you get things straightened out. -Matt -------------------------------------------------------------------------------- - ================================================================================ Archive-Date: Thu, 16 Jul 1992 08:30:36 CDT Date: Thu, 16 Jul 1992 09:26:11 EDT From: Mighty Firebreather Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: breaux@cory.Berkeley.EDU Message-ID: <0095DA72.3D274B40.5811@nscvax.princeton.edu> Subject: RE: MX 3.1-C with UCX 1.3 Installation questions. > > >I've just finished installing MX3.1C on a machine running ucx1.3, and outgoing >mail is delivered with no problem. Incoming mail, however, has a problem. As I >am new to VMS, smtp, and MX, I don't know what to make of the error message >that bounced back to my test mail site. I've looked in some of the MX docs to >no avail. Anyway, here's the error message. > > >Vince Reed >UCSF Cardiothoracic Surgery >(415)476-3437 > > >From Wed Jul 15 14:08:20 1992 >Date: Wed, 15 Jul 1992 14:11:11 PDT >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 jsrvx1.ucsf.edu): > %MX_SMTP-F-TRANSACTION_FAI, transaction failed > > Transcript: > Rcvd: 220 jsrvx1.ucsf.EDU MX V3.1C SMTP server ready at Wed, 15 Jul 1992 > 14:10:59 PDT > Sent: HELO jsrvx1.ucsf.EDU > Rcvd: 250 Hello, jsrvx1.ucsf.EDU > Sent: MAIL FROM: > Rcvd: 250 MAIL command accepted. > Sent: RCPT TO: > Rcvd: 250 Recipient okay (at least in form) > Sent: DATA > Rcvd: 354 Start mail input; end with . > Rcvd: 554 Received too many times by this host. > Sent: QUIT > Rcvd: 221 jsrvx1.ucsf.EDU Service closing transmission channel >======================================================================== > >Message follows. > >Received: from jsrvx1.ucsf.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 > Jul 1992 14:10:43 PDT >Received: from jsrvx1.ucsf.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 > Jul 1992 14:10:21 PDT >Received: from jsrvx1.ucsf.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 > Jul 1992 14:09:58 PDT >Received: from jsrvx1.ucsf.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 > Jul 1992 14:09:37 PDT >Received: from jsrvx1.ucsf.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 > Jul 1992 14:09:16 PDT >Received: from jsrvx1.ucsf.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 > Jul 1992 14:08:56 PDT >Received: from jsrvx1.ucsf.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, 15 > Jul 1992 14:08:36 PDT >Received: from cory.Berkeley.EDU by jsrvx1.ucsf.EDU (MX V3.1C) with SMTP; Wed, > 15 Jul 1992 14:08:19 PDT >Received: by cory.Berkeley.EDU (5.57/Ultrix3.0-C) id AA23501; Wed, 15 Jul 92 > 14:05:00 -0700 >Date: Wed, 15 Jul 92 14:05:00 -0700 >From: breaux@cory.berkeley.edu (Charles Breaux) >Message-ID: <9207152105.AA23501@cory.Berkeley.EDU> >To: vince@jsrvx1.ucsf.edu >Subject: Testing > > Just a test Be sure that your "hosts" file for UCX, has your fully qualified domain name *FIRST*; e.g. jsrvx1.ucsf.edu, jsrvx1 works and jsrvx1, jsrvx1.ucsf.edu does not! I'm not sure exactly what UCX calls the hosts file nor where it's kept. The hosts file is the one that equates ip addresses and host names. ************************************************************************* * * * Here, there be dragons! * * dragon@nscvax.princeton.edu * * * * Richard B. Gilbert * ************************************************************************* ================================================================================ Archive-Date: Mon, 20 Jul 1992 12:07:24 CDT Sender: goathunter@WKUVX1.BITNET Date: Mon, 20 Jul 1992 12:07:02 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095DDAD.5EFE69E0.1679@WKUVX1.BITNET> Subject: RE: Update questions Well, it took me a week to answer these, though I sort of answered part of it last week. FYI: "Koch,Hans-Joachim" writes: > [...] >1. Is there some upgrade package from 3.0 to 3.1c? (I suppose: no) > Installing MX v3.1C will do the trick. >2. I copied the new version 3.1 from the french DecusVAX (compressed > savesets, mftu coded) and got one crc error for every saveset. The > savesets seem to be ok (BACK/LIS works). Should I install it? > They're probably OK. Some LZCOMPs use CHECKSUMs, some don't, same with LZDCMP. If you can BACKUP/LIST it OK, then everything should be fine. >3. I got the REVC_UPDATE from MXSERVER. The description says: update > from MX031A/B to version C. Can I use it for 3.1 (no A or B)? > It'll work for V3.1, v3.1A, and v3.1B. >4. Or should I forget about all upgrade problems and order the new > version 3.1c completely from MXSERVER (a LOT of mails...)? > Or that. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Mon, 20 Jul 1992 21:41:06 CDT From: Patrice.Legoux@gsi.fr Reply-To: MX-List@WKUVX1.BITNET Date: 15 Jul 92 12:34:52 GMT+00.00 Message-ID: _25434151702991/1605 GSIDP To: MX-LIST/#l#A#r#WKUVX1.bitnet//FR/ATLAS/////@sirius.gsi.fr Subject: ADDRESSING PROBLEM Does someone known what is the Internet translation for this address : uunet.UU.NET!apexepa!jcj Thanks, Patrice Legoux. +--------------------------------------+---------------------------------------+ | Patrice LEGOUX | e-mail : Patrice.Legoux@gsi.fr | +--------------------------------------+---------------- | | 38 Rue Jacques IBERT +---------------------------------------+ | BP 108 | Tel : (33.1) 47.48.18.19 | | 75821 PARIS Cedex 17 | Fax : (33.1) 47.48.04.83 | | France | Telex : 611 581 F | +--------------------------------------+---------------------------------------+ | X400 : C=FR; ADMD=ATLAS; PRMD=GSIDISTPAR; S=LEGOUX; G=PATRICE | +------------------------------------------------------------------------------+ ================================================================================ Archive-Date: Tue, 21 Jul 1992 08:25:38 CDT Date: Tue, 21 Jul 1992 09:23:16 EDT From: Mighty Firebreather Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095DE5F.A8DE7B60.6477@nscvax.princeton.edu> Subject: RE: ADDRESSING PROBLEM Patrice LEGOUX writes: > >Does someone known what is the Internet translation for this address : > > uunet.UU.NET!apexepa!jcj > Try jcj@apexepa.uunet.UU.NET. ************************************************************************* * * * Here, there be dragons! * * dragon@nscvax.princeton.edu * * * * Richard B. Gilbert * ************************************************************************* ================================================================================ Archive-Date: Tue, 21 Jul 1992 09:28:57 CDT Date: Tue, 21 Jul 1992 09:44:36 EDT From: "Jonathan E. Hardis" Reply-To: MX-List@WKUVX1.BITNET Subject: RE: ADDRESSING PROBLEM To: MX-List@WKUVX1.BITNET CC: Patrice.Legoux@gsi.fr, hardis@vax844.phy.nist.gov Message-ID: <0095DE62.A3EBF940.3533@vax844.phy.nist.gov> >> Does someone known what is the Internet translation for this address : >> uunet.UU.NET!apexepa!jcj > Try jcj@apexepa.uunet.UU.NET Better, try: jcj%apexepa@uunet.uu.net ================================================================================ Archive-Date: Tue, 21 Jul 1992 10:28:33 CDT Date: Tue, 21 Jul 1992 10:26:06 CDT From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: Patrice.Legoux@gsi.fr Message-ID: <0095DE68.70030960.25715@SHSU.edu> Subject: RE: ADDRESSING PROBLEM Patrice LEGOUX asked: > Does someone known what is the Internet translation for this address : > > uunet.UU.NET!apexepa!jcj > To which Richard B. Gilbert (Mighty Firebreather) replied: > Try jcj@apexepa.uunet.UU.NET. Followed by Jonathan E. Hardis , who said: > Better, try: jcj%apexepa@uunet.uu.net Okay, I'll play stupid on this -- by the MX defaults, wouldn't: be the appropriate address since .uucp routes back through @UUNET.UU.NET:? 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: Tue, 21 Jul 1992 22:03:54 CDT From: bhp116@phys.anu.edu.au Reply-To: MX-List@WKUVX1.BITNET Subject: Outgoing mail problems Message-ID: <1992Jul22.121331.1@phys.anu.edu.au> Date: 22 Jul 92 12:13:31 GMT Sender: news@newshost.anu.edu.au To: MX-List@WKUVX1.BITNET I have just installed MX v3.1 on a 4000/60 (vms 5.5). Mail arriving to the machine is not a problems. However, sending mail only works if you are running as SYSTEM. i.e. Ordinary accounts (having only NETMBX & TMPMBX privs) attempting to send mail, fail. There is no error message, nothing. An entry is made in the queue directory, but the files are empty. I have check the protections, but no luck. Has anyone run into this problem ? ================================================================================ Archive-Date: Wed, 22 Jul 1992 02:13:28 CDT Date: Wed, 22 Jul 1992 02:59:44 EDT From: Matt The Midnight Mortician Reply-To: MX-List@WKUVX1.BITNET To: Mx-List@WKUVX1.BITNET Message-ID: <0095DEF3.3F1D6D00.2112@vax1.elon.edu> Subject: help!!! list serrver HI! I really need some help: Is there a better listserver program around with more features than the one currently in use by MX. As much as I like Mx the listserver program leaves me green with envy for the Listserv program for internet. Is there a port of this available by FTP for CMU/TEK??? I would like something that is easy to administrate and has a better set of commands. TIME IS TIGHT ON THIS!! I would really appreciate your help. Thanks in advance! MATT FAQ possibly but it is overdue..... P.S. Is Matt Madison still alive?? (address at rpi is returned to me- I have old manuals!!!) I owe him a public thanks for creating Mx and Watcher and etc... Our vax is slowly becoming a beachfront for his warez! THANKS! "System security is a state of mind. Real security is a warm blanket." Matthew T. Harttree HARTTREE@VAX1.ELON.EDU +919-584-2295 / +919-570-8120 (voice mail) / +919-584-2575 (FAX) ------------------------------ [insert famous libility release statement here!] ================================================================================ Archive-Date: Wed, 22 Jul 1992 10:18:16 CDT Date: Wed, 22 Jul 1992 10:08:21 CDT From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: harttree@vax1.elon.edu Message-ID: <0095DF2F.1FE5D260.29056@SHSU.edu> Subject: RE: help!!! list serrver On Wed, 22 Jul 1992 02:59:44 EDT, Matt (The Midnight Mortician) Harttree posted: > Is there a better listserver program around with more features than the one > currently in use by MX. As much as I like Mx the listserver program leaves > me green with envy for the Listserv program for internet. Is there a port > of this available by FTP for CMU/TEK??? I would like something that is > easy to administrate and has a better set of commands. If you mean Eric Thomas' VM/CMS based LISTSERV, no. If you mean the listserv sets run on Unix machines which have been posted to various newsgroups on Usenet, no. If I am wrong on this, someone please correct me!! Among the three, Eric's LISTSERV is (quite possibly) the best (known, certainly, if not in features and functionality, as well), although the features added by Matt Madison in the latest iterations of MX, when combined with the file server capabilities come very close. From reports I have seen (no I haven't loaded it and actually test driven it -- yet), the Unix-based nice tries at listserv are just that -- nice tries; however, I know they are making progress. Question (to give food for thought in development): What specific aspects of "easy to administrate and ... better set of commands" might you be looking for? I believe that Hunter would have an interest in this as he and I have exchanged some ideas for future development in the MLF processor. Which leads to: > P.S. Is Matt Madison still alive?? (address at rpi is returned to me- I > have old manuals!!!) I owe him a public thanks for creating Mx and Watcher > and etc... Our vax is slowly becoming a beachfront for his warez! Matt has moved on to different (if not greener or more pleasantly climatic) pastures. He is now associated with TGV -- the MultiNet folks of VMS TCP/IP fame and fortune. His address is now . Matt turned over MX development and maintenance to the very competent hands of Hunter Goatley , who now receives all of the mail with development suggestions from me which previously went to Matt. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ================================================================================ Archive-Date: Wed, 22 Jul 1992 11:54:17 CDT Date: Wed, 22 Jul 1992 11:57:38 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <0095DF3E.63BA2E00.8114@swdev.si.com> Subject: A question and an enhancement request. The question is this: is it typical for MX to lock the SYSTEM_QUEUE.FLQ_CTL file when it is receiving mail? I've noticed a few times that when mail is incoming from SMTP and I try to send a message outbound, I get a message from mail that it can't send mail and that the error is: %RMS-E-FLK, file currently locked by another user. At the same time, if I go to a terminal and say MCP QUE SHOW/ALL/FULL, it also reports: %MCP-E-QOPENERR, error occurred opening system message queue -RMS-E-FLK, file currently locked by another user Once the inbound mail gets delivered, all is well again. Can I expect to see more and more instances of this as my use of MX grows? If so, it's a fairly sizable drawback. My enhancement request is that MX open the log files differently, like VMS opens log files, so that one can TYPE the current log file to see what's going on. Riht now, I can see previous versions of the log, but when I try to type the current version, I get: $ typ mx_local_dir:mx_local_*.log %TYPE-W-OPENIN, error opening MX_ROOT:[LOCAL]MX_LOCAL_NODE1.LOG;14 as input -RMS-E-FLK, file currently locked by another user $ typ mx_router_dir:mx_router_*.log %TYPE-W-OPENIN, error opening MX_ROOT:[ROUTER]MX_ROUTER_NODE1.LOG;13 as input -RMS-E-FLK, file currently locked by another user %TYPE-W-OPENIN, error opening MX_ROOT:[ROUTER]MX_ROUTER_NODE2.LOG;5 as input -RMS-E-FLK, file currently locked by another user $ typ mx_smtp_dir:mx_smtp_*.log %TYPE-W-OPENIN, error opening MX_ROOT:[SMTP]MX_SMTP_NODE1.LOG;13 as input -RMS-E-FLK, file currently locked by another user %TYPE-W-OPENIN, error opening MX_ROOT:[SMTP]MX_SMTP_NODE2.LOG;5 as input -RMS-E-FLK, file currently locked by another user It would be nice if MX would take out a different kind of lock on the log files. -----------------------------+-------------------------------- 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, 22 Jul 1992 12:36:59 CDT Date: Wed, 22 Jul 1992 13:34 EST From: "DAVID L. CUSTER" Reply-To: MX-List@WKUVX1.BITNET Subject: Bitnet to Mailer problem To: mx-list@WKUVX1.BITNET Our BITNET node's "server1 tag" identifies us as having a mailer called "MAILER". We are running UCX V1.3, MX V3.0 and Jnet V3.5. All the MX processes run under the MAILER account. Our problem is that none of the mail arriving over BITNET gets distributed to the intended user. It all ends up as mail for user Mailer. Is this as it should be? If not, can anyone suggest a possible solution to our problem? Thank you. Dave Custer ================================================================================ Archive-Date: Wed, 22 Jul 1992 15:00:09 CDT From: Subject: Re: A question and an enhancement request. Message-ID: <1992Jul22.184203.4586@cco.caltech.edu> Sender: news@cco.caltech.edu Reply-To: MX-List@WKUVX1.BITNET References: <0095DF3E.63BA2E00.8114@swdev.si.com> Date: Wed, 22 Jul 1992 18:42:03 GMT To: MX-List@WKUVX1.BITNET In article <0095DF3E.63BA2E00.8114@swdev.si.com>, "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: >My enhancement request is that MX open the log files differently, like VMS opens >log files, so that one can TYPE the current log file to see what's going on. >Riht now, I can see previous versions of the log, but when I try to type the >current version, I get: > >$ typ mx_local_dir:mx_local_*.log >%TYPE-W-OPENIN, error opening MX_ROOT:[LOCAL]MX_LOCAL_NODE1.LOG;14 as input >-RMS-E-FLK, file currently locked by another user >It would be nice if MX would take out a different kind of lock on the log files. It's not a matter of "tak[ing] out a different kind of lock," it's a matter of opening the files with SHR=GET. -------------------------------------------------------------------------------- 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: Wed, 22 Jul 1992 15:09:24 CDT Sender: goathunter@WKUVX1.BITNET Date: Wed, 22 Jul 1992 15:07:55 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095DF58.F8ED38E0.2159@WKUVX1.BITNET> Subject: Re: A question and an enhancement request. writes: > >>My enhancement request is that MX open the log files differently, like VMS [...] > >It's not a matter of "tak[ing] out a different kind of lock," it's a matter of >opening the files with SHR=GET. > Yes, and it's something I plan to do. Just so you know what's going on: I'm trying to finish up a couple of major projects I've got going on. Once those are complete, I'll be spending some time on MX development. Hopefully, this'll start within the next two or three months.... Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Wed, 22 Jul 1992 18:58:46 CDT Sender: syssand@CCVAX.CCS.CSUS.EDU Date: Wed, 22 Jul 1992 16:52:20 PDT From: "John F. Sandhoff" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: tillman@swdev.si.com, syssand@CCVAX.CCS.CSUS.EDU Message-ID: <0095DF67.8F00AF20.23290@CCVAX.CCS.CSUS.EDU> Subject: RE: A question and an enhancement request. > The question is this: is it typical for MX to lock the SYSTEM_QUEUE.FLQ_CTL > file when it is receiving mail? My system is what I consider busy (typically over 1000 messages a day) and I don't recall seeing this problem. I seem to recall that ONCE I got a 'currently locked' error from FLQU SHOW but other than that I don't see locks. CPU speed may have a lot to do with it - MX runs on an 8820 here (though sometimes at priority 1 - ouch!) > My enhancement request is that MX open the log files differently, like VMS > opens log files, so that one can TYPE the current log file... Yes, frustrating. There's a workaround if you really want to see the file: $ BACKUP/IGNORE=INTERLOCK MX_LOCAL_DIR:MX_LOCAL_NODE1.LOG FOOLOG.LOG $ TYPE/PAGE FOOLOG.LOG $ DELETE/ERASE FOOLOG.LOG Be *sure* you're careful with the output file spec so you don't clobber a real log file :-) Note: requires SYSPRV to work. We all have that, right? :-) John F. Sandhoff, University Network Support California State University, Sacramento - USA sandhoff@csus.edu ================================================================================ Archive-Date: Wed, 22 Jul 1992 20:45:40 CDT Date: Wed, 22 Jul 1992 16:39:07 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <0095DF65.B682BCC0.8149@swdev.si.com> Subject: Re: A question and an enhancement request. What about my problem: the "file locked by another user" for the queue file when receiving and trying to send mail at the same time? This has nothing to do with the log files. Actually, I could live without the latest logs, but the denial of mail sending is a problem. -----------------------------+-------------------------------- 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, 23 Jul 1992 08:24:09 CDT Date: Thu, 23 Jul 1992 08:56:24 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: sandhoff@csus.edu CC: mx-list@WKUVX1.BITNET Message-ID: <0095DFEE.3D3CE820.8428@swdev.si.com> Subject: RE: A question and an enhancement request. John F. Sandhoff (sandhoff@csus.edu) writes: >My system is what I consider busy (typically over 1000 messages a day) and >I don't recall seeing this problem. I seem to recall that ONCE I got >a 'currently locked' error from FLQU SHOW but other than that I don't >see locks. CPU speed may have a lot to do with it - MX runs on an 8820 >here (though sometimes at priority 1 - ouch!) Well, we use MX a *whole* lot less (about six people) and it's happened twice in the past month. Now, that may seem very little, but it seems that if we release MX to all 500 of our accounts, we could very well see this much more frequently. This would mark MX in the minds of the Email people here as a flawed product and we would be forced to use our previous SMTP mailer (yuck!). John, if you still use FLQU, then you must still be using V2.x. Perhaps this problem didn't exist in versions prior to V3.x (we're using V3.1C). At any rate, thanks for the comments. If anyone else can comment on incoming mail locking SYSTEM_QUEUE.FLQ_CTL in such a way as to elicit file locked errors from VMS mail when trying to *send* using MX% as the transport, please comment as well. -----------------------------+-------------------------------- 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, 23 Jul 1992 08:37:28 CDT Sender: goathunter@WKUVX1.BITNET Date: Thu, 23 Jul 1992 08:37:08 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095DFEB.8B9CB7A0.2279@WKUVX1.BITNET> Subject: RE: A question and an enhancement request. "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: > >>My system is what I consider busy (typically over 1000 messages a day) and >>I don't recall seeing this problem. I seem to recall that ONCE I got >>a 'currently locked' error from FLQU SHOW but other than that I don't >>see locks. CPU speed may have a lot to do with it - MX runs on an 8820 >>here (though sometimes at priority 1 - ouch!) > [...] >John, if you still use FLQU, then you must still be using V2.x. Perhaps this >problem didn't exist in versions prior to V3.x (we're using V3.1C). > >At any rate, thanks for the comments. > >If anyone else can comment on incoming mail locking SYSTEM_QUEUE.FLQ_CTL in such >a way as to elicit file locked errors from VMS mail when trying to *send* using >MX% as the transport, please comment as well. > In all the time I've been using MX, I've seen what you're describing once or twice. MX here processes well over 2000 messages a day and I've never heard of a user complaining about this problem. In fact, I haven't seen it since v2.x, so I'm not sure what to tell you. Maybe Matt has some ideas? Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Thu, 23 Jul 1992 08:51:57 CDT Date: Thu, 23 Jul 1992 09:44:53 EDT From: "Steve Thompson, Cheme System Mangler" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: olin@cheme.tn.cornell.edu Message-ID: <0095DFF5.02DFF120.23813@cheme.tn.cornell.edu> Subject: RE: A question and an enhancement request. Brian Tillman (tillman@swdev.si.com) writes: > >John F. Sandhoff (sandhoff@csus.edu) writes: > >>My system is what I consider busy (typically over 1000 messages a day) and >>I don't recall seeing this problem. I seem to recall that ONCE I got >>a 'currently locked' error from FLQU SHOW but other than that I don't >>see locks. CPU speed may have a lot to do with it - MX runs on an 8820 >>here (though sometimes at priority 1 - ouch!) > >Well, we use MX a *whole* lot less (about six people) and it's happened twice in >the past month. Now, that may seem very little, but it seems that if we release >MX to all 500 of our accounts, we could very well see this much more frequently. >This would mark MX in the minds of the Email people here as a flawed product and >we would be forced to use our previous SMTP mailer (yuck!). > We run MX 3.1 on a 4000/500 which has about 600 accounts on it, with usually 90-200 active processes for 25-40 users (there's a lot of X terminals attached). MX mail traffic volume is approximately 500 messages per day. I see the 'locked' message about once every month. I've used the WIN/TCP mailer before MX, so I suggest that you don't try it! >John, if you still use FLQU, then you must still be using V2.x. Perhaps this >problem didn't exist in versions prior to V3.x (we're using V3.1C). > >At any rate, thanks for the comments. > >If anyone else can comment on incoming mail locking SYSTEM_QUEUE.FLQ_CTL in such >a way as to elicit file locked errors from VMS mail when trying to *send* using >MX% as the transport, please comment as well. Well, I've seen it twice in about a year. Only one other person on my system has complained to me about this. I don't consider it a big problem. Steve ================================================================================ Archive-Date: Thu, 23 Jul 1992 10:03:14 CDT Message-ID: <0095DFF6.ECCA0860.29487@uwwvax.uww.edu> Date: Thu, 23 Jul 1992 09:58:35 CDT From: hunterl@uwwvax.uww.edu Reply-To: MX-List@WKUVX1.BITNET Subject: Re: A question and an enhancement request. To: MX-List@WKUVX1.BITNET The only time we have seen a locked message is when it is compressing or purging. Lyle Hunter Computer Center University Wisconsin-Whitewater hunterl@uwwvax.uww.edu ================================================================================ Archive-Date: Thu, 23 Jul 1992 11:20:03 CDT Date: Thu, 23 Jul 1992 11:55:00 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: hunterl@uwwvax.uww.edu CC: mx-list@WKUVX1.BITNET Message-ID: <0095E007.30064D40.8452@swdev.si.com> Subject: Re: A question and an enhancement request. Lyle Hunter (hunterl@uwwvax.uww.edu) writes: >The only time we have seen a locked message is when it is compressing >or purging. This may be the case with us. I know how to determine how *frequently* the queue file gets compresses, but how does one determine *when* the compression occurs. I'd like to make sure the compression occurs during the wee hours of the night when the possibility of outbound mail is slight. -----------------------------+-------------------------------- 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, 23 Jul 1992 11:20:13 CDT From: Subject: Re: A question and an enhancement request. Message-ID: <1992Jul23.154513.18269@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <0095DFF6.ECCA0860.29487@uwwvax.uww.edu> Date: Thu, 23 Jul 1992 15:45:13 GMT To: MX-List@WKUVX1.BITNET In article <0095DFF6.ECCA0860.29487@uwwvax.uww.edu>, hunterl@uwwvax.uww.edu writes: >The only time we have seen a locked message is when it is compressing >or purging. Lyle has hit on what is the likely source of the problem -- trying to access queue file while a CONVERT/RECLAIM is being done by the Router process. That's about the only time that the file will be inaccessible to others. What I probably should have done was modified the code that opens the queue file so that it tries several times before giving up. Currently it tries just once. Brian's case is the first I've heard of that seems to be a frequent occurrence... maybe the disk on which the queue file resides is excessively fragmented or excessively busy, causing the reclaim passes to take a long time? -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Thu, 23 Jul 1992 11:32:47 CDT Sender: goathunter@WKUVX1.BITNET Date: Thu, 23 Jul 1992 11:32:29 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095E004.0B0BC720.2336@WKUVX1.BITNET> Subject: Re: A question and an enhancement request. "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: > >This may be the case with us. I know how to determine how *frequently* the >queue file gets compresses, but how does one determine *when* the compression >occurs. I'd like to make sure the compression occurs during the wee hours of >the night when the possibility of outbound mail is slight. > It *should* only compress once a day, by default. The interval is controlled by the logical FLQ_RECLAIM_WAIT, which defaults to "1 00:00:00.00". The other logicals are FLQ_CHECK_WAIT and FLQ_PURGE_WAIT---they're described in section 6.1 of the MX manager's guide. Because I run JANTIDY every night at 3:45, I always bring MX down and do the CONVERT myself, then bring MX back up. I had to set FLQ_RECLAIM_WAIT to "2 00:00:00", though, because occasionally the interval would expire before JANTIDY got finished with its business. In case anyone is interested, I've include my MX_JANTIDY.COM below. I call it from JANTIDY right before Jnet is restarted. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 $ set noon $ say := write sys$output $ mcp := $mx_exe:mcp.exe/file=mx_dir:mx_config.mxcfg $ say "Shutting down MX" $ mcp shutdown $ wait 00:00:30 !Wait for them to shutdown $ convert/fdl=flq_dir:system_queue flq_dir:system_queue.flq_ctl - flq_dir:system_queue.flq_ctl; $ purge flq_dir:system_queue.flq_ctl $ rename flq_dir:system_queue.flq_ctl; ;1 $ say "" $ say "Restarting MX" $ submit/user=mxmailer sys$startup:mx_startup.com $ wait 00:00:30 $ exit ================================================================================ Archive-Date: Thu, 23 Jul 1992 20:45:29 CDT Date: Thu, 23 Jul 1992 16:02:27 CDT From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095E029.C20869E0.1045@SHSU.edu> Subject: RE: A question and an enhancement request. On Thu, 23 Jul 1992 08:56:24 EDT, Brian Tillman posted: > John F. Sandhoff (sandhoff@csus.edu) writes: > > >My system is what I consider busy (typically over 1000 messages a day) and > >I don't recall seeing this problem. I seem to recall that ONCE I got > >a 'currently locked' error from FLQU SHOW but other than that I don't > >see locks. CPU speed may have a lot to do with it - MX runs on an 8820 > >here (though sometimes at priority 1 - ouch!) > > Well, we use MX a *whole* lot less (about six people) and it's happened > twice in the past month. Now, that may seem very little, but it seems that > if we release MX to all 500 of our accounts, we could very well see this > much more frequently. This would mark MX in the minds of the Email people > here as a flawed product and we would be forced to use our previous SMTP > mailer (yuck!). I guess we're lucky -- in two-plus years of use, I've only seen or heard of this happening once (when MX 3.0 was still in beta), and we viewed it as a chance occurrence (I'm sure Ken or someone looked at it hard, but as I recall chance was the final verdict). We are a busy site, I think -- we run 15 processes under MX on three nodes, our FILESERV handles over 300 outbounds a day (it's been months since we've handled fewer than 200 in a day; last month we handled 16,871 files, not including the verification messages and error replies) and we have three quasi-active lists with over 100 subscribers, another with 300+ and still another with around 500 (which is probably the most active of all of our lists). That's even before getting to our local users. The MCP/FLQ count can easily go up 8,500-11,000 in a normal school day (yes, I know MX generates 2-4 per message, but that's still quite a few). Hunter already shared our approach -- we don't allow MX to ever compress the file; instead, we shut it down each morning around 0100, then do the compression in a daily batch job (the SYSTEM_QUEUE.FLQ_CTL file generally goes from 7000+ blocks back down to <300 during this process). Each of the 3 nodes has its own batch queue and its own restart file called by the main file, verifying JNET, doing things to help in the FILESERV directories, which are also our anonymous ftp directories, etc. The main file even waits to see if SYSTEM_QUEUE is locked before it does its thing: $loop: $ open/read file SYSTEM_QUEUE.FLQ_CTL/error=not_yet $ back/ign=int SYSTEM_QUEUE.FLQ_CTL.0 SYSTEM_QUEUE.FLQ_opt.0 $ OPT SYSTEM_QUEUE.FLQ_opt !OPT calls a command file to optimize the file $ copy SYSTEM_QUEUE.FLQ_opt SYSTEM_QUEUE.FLQ_Ctl $ close file $not_yet: $wait 00:00:10 $goto loop At 0100, with all processes down, this is relatively safe, and it allows all open processes to complete prior to doing anything. > John, if you still use FLQU, then you must still be using V2.x. Perhaps > this problem didn't exist in versions prior to V3.x (we're using V3.1C). Huh???? The two tools give different information. I commonly use FLQ to get a quick look at the queue, then take given numbers from it to MCP QUE SHO/ALL. FLQ, at least in our environment, is far superior for a quick look; MCP QUEUE has better features -- you (or we) really need both. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ================================================================================ Archive-Date: Fri, 24 Jul 1992 16:31:05 CDT Date: 24 Jul 1992 15:24:15 -0600 (MDT) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: MX and TCPware To: mx-list@WKUVX1.BITNET Message-ID: <01GMRF554SEA000AVK@VAXF.COLORADO.EDU> Is anyone sucessfully using MX with Process Software's "TCPware for VMS"? Did you purchase their SMTP mailer? Comments on this software/company/support? -Dan Wing, DWING@UH01.Colorado.EDU or WING_D@UCOLMCC.BITNET (DGW11) Systems Programmer, University Hospital, Denver ================================================================================ Archive-Date: Fri, 24 Jul 1992 22:50:16 CDT Subject: RE: A question and an enhancement request. Message-ID: <1992Jul24.175905@mccall.com> From: Date: Fri, 24 Jul 1992 17:59:05 CST Reply-To: MX-List@WKUVX1.BITNET References: <0095E029.C20869E0.1045@SHSU.edu> To: MX-List@WKUVX1.BITNET In article <0095E029.C20869E0.1045@SHSU.edu>, "George D. Greenwade" writes: >Hunter already shared our approach -- we don't allow MX to ever compress >the file; instead, we shut it down each morning around 0100, then do the >compression in a daily batch job (the SYSTEM_QUEUE.FLQ_CTL file generally >goes from 7000+ blocks back down to <300 during this process). But since doing the reclaim while MX is up is the standard way the system works, it'd be nice if the other components of MX were aware of this and tolerant of it. Perhaps a lock could be used for access to the file? That way, the router could lock it exclusive and spawn the convert/reclaim, so that everyone else would wait for it rather than dying. It's real frustrating to lose a message because when you finished it and sent it, the mailer died. Also, there's a set of circumstances (see the VMS 5.4-3 release notes) in which convert/reclaim is very unsafe. Does anyone know if MX is in danger from this? If so, I may just follow Hunter and George's lead and do the convert with MX down. It'd be a pain though. This hasn't happened to me, but then, I just installed MX today. :-) I've had other mailers die on me, and I hate it. BTW, while I'm here, I'm a little unclear on when you need to shutdown and restart MX or just reset it when you change things from MCP. Does it always require a shutdown and restart, or just a reset, or what? -- Terry Poot The McCall Pattern Company (uucp: ...!rutgers!depot!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA ================================================================================ Archive-Date: Mon, 27 Jul 1992 01:14:36 CDT Date: Mon, 27 Jul 1992 02:09:04 EDT From: Matt The Midnight Mortician Reply-To: MX-List@WKUVX1.BITNET To: MX-list@WKUVX1.BITNET Message-ID: <0095E2D9.FEF46D60.2723@vax1.elon.edu> Subject: help!! need information on lists on MX V3.1c I have the CMU/TEK manual featuring the docs to MX v 2.3 I am running MX v 3.1C I am lost! I need to get a copy of the MX manual via FTP how can I do so??? What can (beyond the stupid and reaching into the FAQ area) y'all tell me about setting up and maintaining lists under MX v 3.1C. I really am lost on this! How do I set up a list(s) ANY AND ALL REPLIES ARE WELCOME Thanks, Matt "System security is a state of mind. Real security is a warm blanket." Matthew T. Harttree HARTTREE@VAX1.ELON.EDU +919-584-2295 / +919-570-8120 (voice mail) / +919-584-2575 (FAX) ------------------------------ [insert famous libility release statement here!] ================================================================================ Archive-Date: Mon, 27 Jul 1992 02:39:35 CDT Date: Mon, 27 Jul 1992 09:34:24 +0200 From: Helmut Springer Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095E318.3570E880.9816@bonnie.physik.uni-stuttgart.de> Subject: RE: help!! need information on lists on MX V3.1c sorry for sending the reply to the list, forgot that this list creates it's address as sender 8-( helmut -- Helmut Springer University of Stuttgart, FRG User HelpDesk Computing Center CipPool Physics Department springer@rus.uni-stuttgart.de helmut@bonnie.physik.uni-stuttgart.de phone: +49 711 685-4828 1291::helmut (BelWue) %SYSTEM-W-MAILONSYS, there is real mail installed on this system ================================================================================ Archive-Date: Mon, 27 Jul 1992 02:40:12 CDT Date: Mon, 27 Jul 1992 09:31:36 +0200 From: Helmut Springer Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095E317.D1807F20.9814@bonnie.physik.uni-stuttgart.de> Subject: RE: help!! need information on lists on MX V3.1c Hi Matt, >I need to get a copy of the MX manual via FTP how can I do so??? ftp to ftp.spc.edu and get the file mx031.k_z (and eventually the unpacker lzdcmp.exe), contaons the whole docu... >How do I set up a list(s) it's easy, MLF-guide appended 8-) enjoy helmut _____________________________________cut here_____________________________ Message Exchange Mailing List/File Server Guide March, 1992 This manual describes the management and operation of Message Exchange, electronic mail software for VMS systems. Revision/Update Information: This is a revised manual. Revision bars indicate changes made since the last version of the software. Operating System and Version: VMS V5.0 or later Software Version: Message Exchange V3.1 Engineering Computing Services Rensselaer Polytechnic Institute Troy, New York ________________________ 10 March 1992 Permission is granted to copy and redistribute this document for no commercial gain. This document is still under construction. Comments and suggestions for improvements may be forwarded to MX-List@vms.ecs.rpi.edu. The information in this document is subject to change without notice and should not be construed as a commitment by Rensselaer Polytechnic Institute. Rensselaer assumes no responsibility for any errors that may appear in this document. DISCLAIMER: The software described in this document is provided "as is". No guarantee is made by the author or the author's employer as to the suitability, reliability, security, usefulness, or performance of this software. The following are trademarks of Digital Equipment Corporation: DEC DECnet ULTRIX VAX VAXcluster VMS Jnet is a trademark of Joiner Associates, Inc. MultiNet is a trademark of SRI International and TGV, Inc. TCPware is a trademark of Process Software Corporation. __________ Copyright )1992 Rensselaer Polytechnic Institute _______________________________________________________ Contents _________________________________________________ PREFACE vii _______________________________________________________ CHAPTER 1 THE MAILING LIST/FILE SERVER 1-1 _________________________________________________ 1.1 MAILING LISTS 1-1 _________________________________________________ 1.2 FILE SERVERS 1-2 _______________________________________________________ CHAPTER 2 USING MLF_CONFIG.COM 2-1 _________________________________________________ 2.1 LIST SERVER MANAGERS 2-1 _________________________________________________ 2.2 MAILING LISTS 2-2 _________________________________________________ 2.3 FILE SERVERS 2-2 _________________________________________________ 2.4 USING THE RESULTS 2-3 _______________________________________________________ CHAPTER 3 MAILING LISTS 3-1 _________________________________________________ 3.1 ARCHIVES 3-1 iii Contents _________________________________________________ 3.2 PROTECTION CODES 3-2 _________________________________________________ 3.3 AUTOMATIC REQUEST HANDLING 3-4 3.3.1 Control Commands ______________ 3-7 _________________________________________________ 3.4 USER NOTIFICATION MESSAGES 3-7 _________________________________________________ 3.5 VMS MAIL FORWARDING 3-9 _________________________________________________ 3.6 USING THE ADD AND REMOVE COMMANDS 3-10 3.6.1 ADD ___________________________ 3-10 3.6.2 REMOVE ________________________ 3-11 _________________________________________________ 3.7 DELETING A MAILING LIST 3-12 _______________________________________________________ CHAPTER 4 FILE SERVERS 4-1 _________________________________________________ 4.1 PACKAGES 4-1 _________________________________________________ 4.2 HELP FILE 4-2 _________________________________________________ 4.3 FILE SERVER COMMANDS 4-3 iv Contents _______________________________________________________ APPENDIX A TROUBLESHOOTING MLF PROBLEMS A-1 _________________________________________________ A.1 CASE SENSITIVITY A-1 _______________________________________________________ APPENDIX B EXAMPLE: MAILING LIST WITH ARCHIVE SERVER B-1 _______________________________________________________ TABLES 3-1 Mailing list protection classes _______________________ 3-2 3-2 Mailing list protection codes _ 3-2 3-3 Typical protection codes ______ 3-3 3-4 MLF -Request commands _________ 3-4 3-5 MLF LISTSERV commands _________ 3-5 3-6 User notification messages ____ 3-7 v _______________________________________________________ Preface This guide describes the management and operation of the Message Exchange Mailing List/File Server (MX MLF). __________________________________________________________________ Intended Audience This manual is intended for use by the system manager or any individual responsible for installing and maintaining MX, and for users responsible for creating or managing MX-based mailing lists and file servers. The reader should be generally familiar with VMS system concepts, electronic mail systems and networking terminology. __________________________________________________________________ Document Structure This guide consists of Chapter 1 Contains a general description of MLF. Chapter 2 Describes how to use the MLF_CONFIG procedure. Chapter 3 Describes how to manage a mailing list. Chapter 4 Describes how to manage a file server. __________________________________________________________________ Related Documents You can find additional information in the following documents: o Message Exchange Management Guide describes how to manage MX and contains the command dictionary for the MX Control Program (MCP). vii Preface o Message Exchange User's Guide describes MX features available to general users. viii _______________________________________________________ 1 The Mailing List/File Server Message Exchange (MX) includes a program called the Mailing List/File Server (MLF). This program provides the services needed to distribute messages to mailing lists and manage those lists through mailed commands. It also provides services for distributing packages of files by electronic mail. __________________________________________________________________ 1.1 Mailing Lists When talking about electronic mail, the term mailing list is generally used to describe an E-mail address that forwards messages to one or more subscribers. Mailing lists abound on the Internet and BITNET, on a wide variety of technical and non-technical topics. Unfortunately, there are no standards on the implementation of mailing lists, so their use will vary depending on the systems on which the mailing lists are set up. For the most part however, mailing lists can be broken down into two basic types: Internet and BITNET. For an Internet-style mailing list, there are generally two addresses: one for the mailing list itself, and one for "administrivia" (subscription requests, etc.). The administrative address is usually the mailing list name with "-request" added. For example, the mailing list for discussing Message Exchange is MX-List@vms.ecs.rpi.edu. Subscription requests, removals, or comments about the list are sent to MX-List-request@vms.ecs.rpi.edu. 1-1 The Mailing List/File Server Most mailing lists on BITNET hosts are implemented using Eric Thomas's LISTSERV, a package developed specifically for automated handling of mailing lists. One LISTSERV on a system, at address LISTSERV@hostname, manages all the mailing lists offered on that system, and provides automatic administrative request handling. MLF provides support for both the Internet -request interface and the BITNET LISTSERV interface for its automatic command handling. __________________________________________________________________ 1.2 File Servers As with mailing lists, there are no standards for file servers. There are several file server implementations in existence: LISTSERV, VMSSERV, MAILSERV, and several others. Some of these file servers accept commands via BITNET immediate messages, some only by E-mail messages. Some take commands on the subject line of a message, and some in the body of a message. The way files are distributed can also vary from server to server. The MLF file server command interface accepts commands by E-mail only, and returns files only by E-mail. 1-2 _______________________________________________________ 2 Using MLF_CONFIG.COM MLF comes with a command procedure, MLF_CONFIG.COM, which is placed at installation time in the MX_DIR: directory. This command procedure uses a simple question-and-answer script to develop the MCP commands needed to create mailing lists and file servers. __________________________________________________________________ 2.1 List Server Managers MLF_CONFIG begins by reading in your current MX configuration and checking to see if you have any list server managers (called SYSTEM_USERS in MCP) defined. If not, MLF_CONFIG will prompt you first for the primary list server manager's address, followed by any other users who should be given manager access to mailing lists. List server managers are granted control access to all mailing lists on the system, allowing them to use the ADD and REMOVE commands. In addition, they are granted access through the SYSTEM protection class on all mailing lists. Note: The mailing list processor is case sensitive when matching the username portion of addresses. Be sure to enter the list manager addresses using the correct case. MX, by default, converts all usernames to lower case for local users, so you should generally use lower case when specifying local list managers' addresses. 2-1 Using MLF_CONFIG.COM Primary List Server Manager The first address on the SYSTEM_USERS list is for the primary list server manager. The primary list server manager's address is used as the return address for non-list-related mail messages sent by MLF. If you would rather not have an actual person's E-mail address be used for that purpose, you should set up an alias. __________________________________________________________________ 2.2 Mailing Lists Once you have defined your list server managers, or if they were already defined before you ran MLF_CONFIG, you can then set up one or more mailing lists. MLF_ CONFIG will prompt you for the name of the mailing list and the address of the owner of the list, which are required. It will then prompt you for the optional information related to the list. To move on to the File Server section of MLF_CONFIG, just press RETURN when prompted for a mailing list name. Note: The mailing list processor is case sensitive when matching the username portion of addresses. Be sure to enter the owner addresses using the correct case. MX, by default, converts all usernames to lower case for local users, so you should generally use lower case when specifying local owner addresses. __________________________________________________________________ 2.3 File Servers After the mailing lists phase, MLF_CONFIG will ask you about file servers. To create a file server, you must specify the name, manager's address, and the device and directory that will serve as the root of the file server. MLF_CONFIG will prompt you for this information, and will create the root directory for 2-2 Using MLF_CONFIG.COM you, if you wish. It will then prompt for optional information regarding the file server. __________________________________________________________________ 2.4 Using the Results When MLF_CONFIG finishes, it leaves you with an MCP command file, called MX_DIR:MLF_CONFIG.MCP by default. You should review the contents of that file; if satisfied with the results, you should then execute the command file in MCP, save the resulting configuration information, then reset the Router and MLF processes to have the new mailing lists and file servers recognized: $ MCP MCP> @MLF_CONFIG.MCP MCP> SAVE MCP> RESET/CLUSTER ROUTER,MLF Your newly-created mailing lists and file servers will then be ready. 2-3 _______________________________________________________ 3 Mailing Lists The MCP DEFINE LIST command is used to create a mailing list. The mailing list processor supports the automatic archiving of mailing list messages, automatic subscription processing, and limited remote control of mailing lists. In addition, mailing lists can be protected in a variety of ways to restrict the automatic subscription facility as well as postings to the list. Two local addresses are set up for each mailing list: one for the list itself and a request address (list- name-REQUEST). The mailing list processor accepts subscription requests and other control messages on a list's request address. The list of subscribers is maintained by the MLF agent in the file MX_MLIST_DIR:list-name.MAILING_LIST. The format used for this file is not readable by humans; you should use the list server command interface or the MCP REVIEW command to examine subscriber list. __________________________________________________________________ 3.1 Archives A mailing list is archived automatically by the mailing list processor when the /ARCHIVE qualifier is used on the DEFINE LIST command. You must specify at least a device and directory for the archive. The file name for the archive defaults to the name of the mailing list, and the file type for the archive defaults to yyyy-mm, the current year and month. By keeping with the default, a new archive file will be created every month. 3-1 Mailing Lists __________________________________________________________________ 3.2 Protection Codes The standard VMS protection code syntax is used to describe access to mailing lists. Table 3-1 describes how each of the protection classes relates to mailing lists, and Table 3-2 describes the protection codes. Table_3-1__Mailing_list_protection_classes_____________ Class_______Description________________________________ SYSTEM any address matching one of the addresses on the system user list (see DEFINE SYSTEM_USERS) OWNER any address matching one of the owner addresses specified on the /OWNER qualifier GROUP any address matching one the addresses on the subscriber list for the mailing list WORLD_______any_other_address__________________________ Table_3-2__Mailing_list_protection_codes_______________ Code________Description________________________________ R (Read) allows the use of the REVIEW command W (Write) allows the user to post messages to the list E (Enroll) allows the automatic handling of the SUBSCRIBE command D (Delete) allows the automatic handling of the ____________SIGNOFF_command____________________________ Note that Enroll access is only meaningful to WORLD- class users, and Delete access is only meaningful 3-2 Mailing Lists to GROUP-class users. For most, if not all, mailing lists, you should grant RWED access to both SYSTEM and OWNER classes. SYSTEM and OWNER also implicitly have Control access, allowing them to add and remove other users from the mailing list. Some typical protection codes for GROUP and WORLD users are given in Table 3-3. Table_3-3__Typical_protection_codes____________________ (G:RWED,W:RWE) Public list. Anyone can subscribe, sign off, and review the list; anyone can post to the list. (G:RWED,W:E) Semi-public list. Anyone can subscribe and sign off the list, but only subscribers can review or post to the list. (G:W,W) Private list. Only subscribers can post to the list, and all subscription requests are screened by the owners of the mailing list. (G,W) One-way list. Only the owners can post to the list, and they also _________________screen_all_the_subscription_requests._ Note: Since electronic mail can readily be forged, you should not depend on this protection scheme for absolute security of your mailing lists. The mailing list processor attempts no authentication of addresses when it receives messages. 3-3 Mailing Lists __________________________________________________________________ 3.3 Automatic Request Handling MLF will answer requests automatically at both a list's -Request address and through the LISTSERV interface. The commands it recognizes through the - Request interface are listed in Table 3-4. LISTSERV commands are listed in Table 3-5. Table_3-4__MLF_-Request_commands_______________________ Command____________________Description_________________ ADD address[,...] Control command: allows list owner to add other users to the list. HELP Sends file MX_MLIST_ DIR:MLIST_HELP.TXT. LIST Lists all available mailing lists. QUERY Returns the subscriber's status on the list. REMOVE address[,...] Control command: allows list owner to remove other users from the list. | | REVIEW Returns the list of | subscribers. SET [NO]MAIL Enables/disables receipt of list messages. | | SET [NO]CONCEAL Controls whether subscriber | is concealed from view in | REVIEW listings. 3-4 Mailing Lists | Table_3-4_(Cont.)__MLF_-Request_commands_______________ | | Command____________________Description_________________ | | SET [NO]REPRO Controls whether subscriber | receives a posting s/he | makes to the mailing list. SIGNOFF Removes the user from the list of subscribers. SUBSCRIBE Adds the user to the ___________________________subscriber_list.____________ Table_3-5__MLF_LISTSERV_commands_______________________ Command____________________Description_________________ ADD list-name Control command: allows address[,...] list owner to add other users to the list. HELP Sends file MX_MLIST_ DIR:MLIST_HELP.TXT. LIST Lists all available mailing lists. QUERY list-name Returns the subscriber's status on the list. REMOVE list-name Control command: allows address[,...] list owner to remove other users from the list. | | REVIEW list-name Returns the list of | subscribers. 3-5 Mailing Lists Table_3-5_(Cont.)__MLF_LISTSERV_commands_______________ Command____________________Description_________________ SET list-name [NO]MAIL Enables/disables receipt of list messages. | | SET list-name [NO]CONCEAL Controls whether subscriber | is concealed from view in | REVIEW listings. | | SET list-name [NO]REPRO Controls whether the | subscriber receives a | posting s/he makes to the | mailing list. SIGNOFF list-name Removes the user from the list of subscribers. SUBSCRIBE list-name Adds the user to the ___________________________subscriber_list.____________ SUBSCRIBE requests are handled automatically only if the WORLD protection class is granted E (Enroll) access to the list. Otherwise, they are forwarded to the list owners for manual handling. SIGNOFF requests are handled automatically only if the GROUP protection class is granted D (Delete) access to the list. Otherwise, they are forwarded to the list owners for manual handling. REVIEW requests are handled automatically only if the requesting user is granted R (Read) access to the list. Read access may be granted only to GROUP (i.e., the subscribers of the list) or to GROUP and WORLD. If access is denied, the request is returned with an error message. 3-6 Mailing Lists ___________________________ 3.3.1 Control Commands The mailing list processor currently supports two control requests: ADD and REMOVE. They may be used by the owners of a mailing list to add and remove other | users to and from the list of subscribers. | | The owners of a mailing list also receive the | full list of subscribers when they REVIEW their | list, regardless of the CONCEAL setting of each | subscriber. Non-owners receive a list consisting of | subscribers who have not set the CONCEAL flag for | their subscription to the list. __________________________________________________________________ 3.4 User Notification Messages You can control the text of the message that is sent to the user when he or she subscribes or signs off from a mailing list, on a per-list and/or global basis. Table 3-6 lists the types of messages you can set up and when they are sent. Table_3-6__User_notification_messages__________________ When Per-list_qualifier____Global_default_____________sent__ /ADD_MESSAGE MLIST_ADD_MESSAGE.TXT when a user is added to a mail- ing list 3-7 Mailing Lists Table_3-6_(Cont.)__User_notification_messages__________ When Per-list_qualifier____Global_default_____________sent__ /REMOVE_MESSAGE MLIST_REMOVE_MESSAGE.TXT when a user is re- moved from a mail- ing list /FORWARD_MESSAGE MLIST_FORWARD_MESSAGE.TXT when a user at- tempts to sub- scribe to a list with no W:E ac- _________________________________________________cess__ The global default message files are located in MX_ MLIST_DIR. You can customize these files to suit your site's needs for all mailing lists, or use them as templates for the per-list files. 3-8 Mailing Lists Customization Variables The text of a notification message can contain references to customization "variables" whose values are supplied by the mailing list processor. Available variables are: {list-address} the RFC822 address of the mailing list {request-address} the RFC822 address of the list's -Request address {list-name} the name of the mailing list (no @hostname) | | {list-desc} the contents of the list | description, as specified by | the /DESCRIPTION qualifier on | the DEFINE LIST command {list-owner} the address of the owner of the mailing list (if there are multiple owner addresses, only the first is used) Note that each variable name must be surrounded by curly braces to be recognized. All other text (including unrecognized variable references) is sent verbatim. __________________________________________________________________ 3.5 VMS Mail Forwarding You can make it easier for local users and DECnet- connected users to send messages to a mailing list by creating a forwarding address in VMS Mail for the list name: $ MAIL MAIL> SET FORWARD/USER=list-name MX%list-name 3-9 Mailing Lists This will allow users to use just the list name when addressing the mailing list, without the MX% prefix. If the list name ever changes or the list is deleted, you should remember to remove the forwarding address from VMS Mail for the list name: MAIL> REMOVE list-name This will prevent a possible mail looping problem from occurring. __________________________________________________________________ 3.6 Using the ADD and REMOVE Commands The list processor provides two commands for use exclusively by list owners and list server managers: ADD and REMOVE. ___________________________ 3.6.1 ADD The ADD command adds other users to a mailing list. The syntax for this command for the -Request interface | is: | | ADD [/NONOTIFY] [/NOMAIL] [/NOCASE] [/CONCEAL] [/NOREPRO] address [,...] The syntax for the LISTSERV interface is: ADD [/NONOTIFY] list-name address [,...] You may specify multiple addresses to be added by separating the list with commas, but note that the entire command must fit on one line in the E-mail message. For address, you should enter the RFC822-type address for the user to be added. It should generally appear exactly as it does on the From line of a message, since the mailing list processor is case sensitive in the username part of addresses. You may include the personal name, if desired. 3-10 Mailing Lists Use the /NONOTIFY qualifier when you do not want the new subscribers to receive the "you have been added" message for the mailing list. The /NOMAIL qualifier is used to add the user to the mailing list as a NOMAIL subscriber. That is, the user is on the list without receiving any mail from the list. NOMAIL subscriptions are used for private mailing lists, where only the subscribers are allowed to post, and for mailing lists that control access to file servers; a subscriber might have multiple addresses and may need access to the list or file | server from any of those addresses. | | The /NOCASE qualifier is used to add the user to the | mailing list while having the list processor disregard | the case of the username portion of the address. | Normally, the list processor is case-sensitive | regarding usernames. | | The /CONCEAL qualifier is used to set the CONCEAL flag | in the subscriber's entry in the list. CONCEALed users | do not appear in REVIEW listings, except for those | requested by the list owners. | | The /NOREPRO qualifier is used to prevent the | subscriber from receiving a copy of postings s/he | makes to the list. | | Note that the LISTSERV ADD command supports only the | /NONOTIFY qualifier. ___________________________ 3.6.2 REMOVE The REMOVE command removes other users from a mailing list. The syntax for this command for the -Request interface is: REMOVE [/NONOTIFY] address [,...] The syntax for the LISTSERV interface is: REMOVE [/NONOTIFY] list-name address [,...] 3-11 Mailing Lists You may specify multiple addresses to be added by separating the list with commas, but note that the entire command must fit on one line in the E-mail message. For address, you should enter the RFC822-type address for the user to be added. It should appear exactly as it does in the subscriber list (use the REVIEW command to check this). You may include the personal name, if desired, but only the address part is checked when MLF does the removal. Use the /NONOTIFY qualifier when you do not want the new subscribers to receive the "you have been removed" message for the mailing list. __________________________________________________________________ 3.7 Deleting a Mailing List The MCP REMOVE LIST command removes the definition of a mailing list from the MX configuration database. The file containing the list of subscribers will remain after the definition is removed, however. You should delete that file also: $ DELETE MX_MLIST_DIR:list-name.MAILING_LIST;* You should also remember to delete any add, remove, or forward message files you set up for the mailing list at creation time. 3-12 _______________________________________________________ 4 File Servers The MCP DEFINE FILE_SERVER command is used to set up a file server. Each file server can automatically service requests for single files or groups of files. Large files can be delayed to non-prime-time hours, on a per-server basis. You can specify a per-server, per-host, and/or per-user byte count limit, to prevent users from overtaxing the mail system with file server requests. In addition, you can link a file server to a mailing list, so that only those users who are subscribed to the list can gain access to the file server. __________________________________________________________________ 4.1 Packages The file server is designed to handle groups of files, called packages. When you create a package, you create a directory with the name of that package, and all files in that directory must have file names the same as the package name. In addition, you must place a description file above the package directory which is sent when a user requests a listing of available packages. This structure works best when you use a program such as VMS_SHARE to put together your packages. VMS_SHARE is readily available around the Internet and BITNET. It is used to collect together text files, format them so as to improve the chances of their being transferable through most mail systems, and split them up into easily mailable chunks. When all the chunks are put together on the receiving end, they form a DCL command procedure that re-creates the original files. 4-1 File Servers Example To demonstrate the structure used by the file server, let us suppose you have created a package called STUFF. You used VMS_SHARE to create the package, which split the package into three parts. First, you would create a directory for the package: $ CREATE/DIRECTORY disk:[FILESERV.STUFF] Next, you would copy the VMS_SHARE files into that directory. They must have file names the same as the package name: $ COPY STUFF.* disk:[FILESERV.STUFF] Next, you would create a file containing a brief description of the package and place it above the STUFF directory: $ EDIT disk:[FILESERV]STUFF.DESCRIPTION Finally, you would need to set up the file server in MCP: MCP> DEFINE FILE_SERVER FILESERV/ROOT=disk:[FILESERV.] The file server FILESERV will now automatically handle distribution of the STUFF package. __________________________________________________________________ 4.2 Help File The file FILESERV_HELP.TXT, provided by the installation procedure in directory MX_ROOT:[MLF], contains a description of the file service commands. You should update this file to include the address you have chosen for your file server and any other information specific to the file server that you wish to include. Place the edited copy in the root directory of your file server to have it sent when a user sends a HELP command to your file server. 4-2 File Servers __________________________________________________________________ 4.3 File Server Commands The three commands accepted by the file server are SENDME, LIST (or DIRECTORY), and HELP. Each may be abbreviated to the smallest unique string. One command is allowed per line of text in a request message, but several command lines may be sent in one request. SENDME takes either a package name (to have all parts of a package sent) or a file name (to have just one part sent). Large files are delayed until non-prime- time hours if enabled when file service is set up. LIST takes a pattern which is used to match against package names. The description file for each matching package is added to a message that is returned to the requesting user. If no pattern is specified, "*" is used. HELP causes the file FILESERV_HELP.TXT (located in the root directory of the file server) to be sent to the requesting user. 4-3 _______________________________________________________ A Troubleshooting MLF Problems MLF includes a debug mode that displays information about what it is doing when processing mailing list and file server requests. If you are experiencing problems with either a mailing list or a file server, you can enable this debug mode with the command: $ DEFINE/SYSTEM MX_MLF_DEBUG TRUE If you are in a VAXcluster, this logical must be defined on the same node as the currently active MX MLF process to have any effect. Debug log files created by MLF are called MX_MLF_ DIR:MX_MLF_LOG.LOG. __________________________________________________________________ A.1 Case Sensitivity The mailing list processor uses case-sensitive matching on the username part of addresses when | looking up users on the subscriber list (except for | subscribers with the NOCASE flag set), owner list, and SYSTEM_USERS list. Be careful when adding and removing users from these lists that the case of the username part of the address exactly matches what will be in the From: header of the address. Remember that MX automatically converts usernames to lower case, by default, when creating the From: header, so messages originating on the local system will have lower case usernames. A-1 _______________________________________________________ B Example: Mailing List with Archive Server This example creates a mailing list whose archives are made available through a file server. $ CREATE/DIRECTORY SOME_DISK:[ARCHIVES.MAILLIST] $ MCP MCP> DEFINE LIST "MailList" - _MCP> /OWNER="me@myhost.mycompany.ORG"- _MCP> /PROTECTION=(S:RWED,O:RWED,G:RWED,W:RWE)- _MCP> /ARCHIVE=SOME_DISK:[ARCHIVES.MAILLIST] This would set up a public mailing list, with the list owner being user "me", who would also receive all the bounced mail from the mailing list (by default, since no /ERRORS_TO was specified). The archive will be created in directory SOME_DISK:[ARCHIVES.MAILLIST] a file name of MAILLIST (defaulting from the list name) and a file type of yyyy-mm (the year and month). You could then create a file server called Archives: MCP> DEFINE FILE_SERVER "Archives" - _MCP> /MANAGER="me@myhost.mycompany.ORG"- _MCP> /ROOT=SOME_DISK:[ARCHIVES.]- _MCP> /MAILING_LIST=MailList This file server could then respond to requests for sending some or all of the monthly archives for mailing list MailList. The mailing list link prevents those users who are not subscribed to MailList from obtaining the archives. To complete the setup, you would also need to create the files FILESERV_HELP.TXT and MAILLIST.DESCRIPTION to be placed in directory SOME_DISK:[ARCHIVES], to describe the file server and the MailList archive "package". B-1 __________________________cut here______________________________________ -- Helmut Springer University of Stuttgart, FRG User HelpDesk Computing Center CipPool Physics Department springer@rus.uni-stuttgart.de helmut@bonnie.physik.uni-stuttgart.de phone: +49 711 685-4828 1291::helmut (BelWue) %SYSTEM-W-MAILONSYS, there is real mail installed on this system ================================================================================ Archive-Date: Mon, 27 Jul 1992 13:26:42 CDT Subject: Mail problems with MX3.1 & UUCP2.0 Message-ID: <1992Jul27.104946.849@aspentec.com> From: frzmtdb@aspentec.com Reply-To: MX-List@WKUVX1.BITNET Date: 27 Jul 92 10:49:46 EST To: MX-List@WKUVX1.BITNET Has anyone experienced problems with the interface to UUCP from MX? I recently installed UUCP 2.0 onto my system (which had been running MX3.1C and UUCP1.3 just fine. After the upgrade to UUCP2.0 I get the following messages in the uucp_log:uuxqt.log file. Any ideas??? > >$ FAILED_RMAIL: >Attempt to send mail to failed with status %X1000000C >%RENAME-I-RENAMED, USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4798;1 renamed to USER6:[UUCP.SPOOL.ATUK]REMAIL_X.ATUK_A4798;1 >p:uxqt =< h:- [07/27-10:16:01-22404365] Processing (USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4799;1) u:- >p:uxqt << h:atuk [07/27-10:16:02-22404365] Executing (rmail ZIEGLER < UUCP_DISK:[UUCP.SPOOL.atuk]D.ATUK_A4799 > NL:) u:- > Begin X file USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4799;1 at 27-JUL-1992 10:16:03.05 >$ RMAIL USER6:[UUCP.SPOOL.ATUK]D.ATUK_A4799; "ZIEGLER" >%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000072, PC=00030BF0, PSL=03C00021 >%TRACE-F-TRACEBACK, symbolic stack dump follows >module name routine name line rel PC abs PC > > 00030BF0 00030BF0 > 0006FD11 0006FD11 >MX_RMAIL MX_RMAIL 415 00000CC9 000028DD >$ FAILED_RMAIL: >Attempt to send mail to failed with status %X1000000C >%RENAME-I-RENAMED, USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4799;1 renamed to USER6:[UUCP.SPOOL.ATUK]REMAIL_X.ATUK_A4799;1 >p:uxqt =< h:- [07/27-10:16:12-22404365] Processing (USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4800;1) u:- >p:uxqt << h:atuk [07/27-10:16:13-22404365] Executing (rmail HIBDEV < UUCP_DISK:[UUCP.SPOOL.atuk]D.ATUK_A4800 > NL:) u:- > Begin X file USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4800;1 at 27-JUL-1992 10:16:14.12 >$ RMAIL USER6:[UUCP.SPOOL.ATUK]D.ATUK_A4800; "HIBDEV" >%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000072, PC=00030BF0, PSL=03C00021 >%TRACE-F-TRACEBACK, symbolic stack dump follows >module name routine name line rel PC abs PC > > 00030BF0 00030BF0 > 0006FD11 0006FD11 >MX_RMAIL MX_RMAIL 415 00000CC9 000028DD >$ FAILED_RMAIL: >Attempt to send mail to failed with status %X1000000C >%RENAME-I-RENAMED, USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4800;1 renamed to USER6:[UUCP.SPOOL.ATUK]REMAIL_X.ATUK_A4800;1 >p:uxqt =< h:- [07/27-10:16:26-22404365] Processing (USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4801;1) u:- >p:uxqt << h:atuk [07/27-10:16:27-22404365] Executing (rmail MAHONEY < UUCP_DISK:[UUCP.SPOOL.atuk]D.ATUK_A4801 > NL:) u:- > Begin X file USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4801;1 at 27-JUL-1992 10:16:28.25 >$ RMAIL USER6:[UUCP.SPOOL.ATUK]D.ATUK_A4801; "MAHONEY" >%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000072, PC=00030BF0, PSL=03C00021 >%TRACE-F-TRACEBACK, symbolic stack dump follows >module name routine name line rel PC abs PC > > 00030BF0 00030BF0 > 0006FD11 0006FD11 >MX_RMAIL MX_RMAIL 415 00000CC9 000028DD >$ FAILED_RMAIL: ---- Fred R. Ziegler Email: Aspen Technology, Inc. tel: +1-617-497-9010 x262 251 Vassar St. fax: +1-617-497-7806 Cambridge, Ma. 02139 telex: +1-948-038(ASPEN TECH) U.S.A. Internet Society Member (#1315080) since Feb 1992 ================================================================================ Archive-Date: Mon, 27 Jul 1992 14:03:02 CDT Sender: goathunter@WKUVX1.BITNET Date: Mon, 27 Jul 1992 14:05:15 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095E33E.0BD873A0.2870@WKUVX1.BITNET> Subject: RE: Mail problems with MX3.1 & UUCP2.0 frzmtdb@aspentec.com writes: > >Has anyone experienced problems with the interface to UUCP from MX? >I recently installed UUCP 2.0 onto my system (which had been running > MX3.1C and UUCP1.3 just fine. >After the upgrade to UUCP2.0 I get the following messages in the >uucp_log:uuxqt.log file. > I just installed DECUS UUCP v2.0 this morning and have encountered no problems. Not sure what you're seeing, unfortunately. A note for DECUS UUCP users (I don't think this has been mentioned before): v2.0 provides direct support for MX---you no longer have to modify UUXQT_DCL.COM to invoke MX_RMAIL. Instead, you just need to add the following to your UUCP_CFG:CONTROL. file: !+ ! ! -- Define the appropriate logical so the MX is used by UUXQT ! !- UUCP_UUXQT_DCL_RMAIL_MX TRUE Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Mon, 27 Jul 1992 18:25:42 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: Mail problems with MX3.1 & UUCP2.0 Message-ID: <1992Jul27.172454.6101@dayton.saic.com> Date: 27 Jul 92 17:24:54 EDT References: <1992Jul27.104946.849@aspentec.com> To: MX-List@WKUVX1.BITNET In article <1992Jul27.104946.849@aspentec.com>, frzmtdb@aspentec.com writes: > Has anyone experienced problems with the interface to UUCP from MX? > I recently installed UUCP 2.0 onto my system (which had been running > MX3.1C and UUCP1.3 just fine. > After the upgrade to UUCP2.0 I get the following messages in the > uucp_log:uuxqt.log file. > > Any ideas??? > > >> >>$ FAILED_RMAIL: >>Attempt to send mail to failed with status %X1000000C >>%RENAME-I-RENAMED, USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4798;1 renamed to USER6:[UUCP.SPOOL.ATUK]REMAIL_X.ATUK_A4798;1 >>p:uxqt =< h:- [07/27-10:16:01-22404365] Processing (USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4799;1) u:- >>p:uxqt << h:atuk [07/27-10:16:02-22404365] Executing (rmail ZIEGLER < UUCP_DISK:[UUCP.SPOOL.atuk]D.ATUK_A4799 > NL:) u:- >> Begin X file USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4799;1 at 27-JUL-1992 10:16:03.05 >>$ RMAIL USER6:[UUCP.SPOOL.ATUK]D.ATUK_A4799; "ZIEGLER" >>%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000072, PC=00030BF0, PSL=03C00021 Do an anal/image mx_exe:mx_rmail and make sure the image is V3.1. You also might look at the privs that the MX mailer runs under to make sure it meets Matt's standards. You also might try to do the command manually and see what happens. The definition for rmail would be $ rmail :== $mx_exe:mx_rmail Might want to try a file in the uucp_spool directory rather than one below it to see if that makes a difference. Report back to the group on your findings if any. Earle _____________________________________________________________________________ ____ ____ ___ Earle Ake /___ /___/ / / Science Applications International Corporation ____// / / /__ Dayton, Ohio ----------------------------------------------------------------------------- Internet: ake@dayton.saic.com uucp: dayvb!ake NSI-DECnet (SPAN): 28284::ake ================================================================================ Archive-Date: Tue, 28 Jul 1992 06:53:23 CDT Date: Tue, 28 Jul 92 13:46:56 CET From: Adam Szczupal Reply-To: MX-List@WKUVX1.BITNET Subject: List/File Server problem To: MX-LIST Hi , I have an unsolved problem . If anybody help me ? I have 4 VAX-computers running DEC-net and MX programs. The configuration is following: +------+ +-----+ | NASK1| ----- | vax2| +------+ +-----+ | | +----------------------+ +-----+ | GLETO2.TU-GLIW.EDU.PL| ----- | vax3| +----------------------+ +-----+ All of that computers are running VMS V5.4-2 and MX 3.1B (SMTP_OVER_DECNET) Furthermore, a NASK1 host is a LIST/FILE SERVER ( MX MLF). GLETO.TU-GLIW.EDU.PL is a router, because it's running VAX P.S.I and in the future it will be run VMS-ULTRIX Connection (UCX). The MX Mail connection all of computers is efective. Local access to LIST/FILE SERVER ON NASK1 is O.K., and all commands are responsible . Remote access from GLETO2...etc. to LIST/FILE SERVER on NASK1 is unavailable, I don't know why !!! Every message sended from GLETO2.. with SMTP_OVER_DECNET to LIST/FILE SERVER on NASK1 are lost. I attach a MX_ROUTER log file and configuration: MX_DEVICE:[MX.ROUTER]MX_ROUTER_LOG.LOG;11 ( Access from DEC-net) 28-JUL-1992 11:22:38.68 %PROCESS, Processing entry number 153 28-JUL-1992 11:22:39.20 %PROCESS, Status from READ_INFO was 00000001 28-JUL-1992 11:22:39.20 %PROCESS, Recipient #0: Postmaster@nask1.decnet 28-JUL-1992 11:22:39.21 %PROCESS, Invalid address: Postmaster@nask1.decnet 28-JUL-1992 11:22:39.21 %PROCESS, Beginning ERRORQ processing. 28-JUL-1992 11:22:39.21 %PROCESS, RETURN_MESSAGE status was 00000001 28-JUL-1992 11:22:39.21 %PROCESS, Marking this entry as finished. MX_DEVICE:[MX.ROUTER]MX_ROUTER_LOG.LOG;9 (Local access) 28-JUL-1992 11:22:23.30 %PROCESS, Processing entry number 149 28-JUL-1992 11:22:23.54 %PROCESS, Status from READ_INFO was 00000001 28-JUL-1992 11:22:23.54 %PROCESS, Recipient #0: 28-JUL-1992 11:22:23.55 %REWRITE, No rewrite rules matched as 28-JUL-1992 11:21:18.45 %REWRITE, No rewrite rules matched 28-JUL-1992 11:21:18.47 %FINDPATH, domain name NASK1.DECNET matched path pattern 28-JUL-1992 11:21:18.47 %PROCESS, Rewrote as 28-JUL-1992 11:21:13.79 %REWRITE, No rewrite rules matched as Reply-To: MX-List@WKUVX1.BITNET Subject: MX <-> PC connection via dialup modems To: MX-List@WKUVX1.BITNET CC: claus@HERACC.desy.de Message-ID: <0095E40B.36A146C0.691@heracc.desy.de> I want to send and receive mail from one (or more) PC's. The connection VAX<->PC shall be setup by means of dialup modems. I read about MultiTech's new MultiModem II which shall 'support' UUCP. Software on the VAX: VMS 5.4-3 / MX 3.1 and (UUCP ?) Questions: - Where do I get a UUCP version which will also do the dialup? - If dialup is not possible - where can I get the DECUS UUCP 2.0 from? Software on the PC: DOS (sigh) Questions: - Is there a way to get 'something' running under DOS? -how? - If only UNIX is possible - what would be the solution? Thanks for all input! Matthias Clausen Deutsches Elektronen Synchrotron DESY Gruppe: KRYK / F36H Notkestrasse 85 VXHERA::CLAUS W-2000 Hamburg 52 CLAUS@DESYVAX.BITNET Tel: -49 40 8998-3256 claus@heracc.desy.de Fax: -49 40 8998-5388 PSI%(0262)45050354002::CLAUS ---------------------------------------------------------------- Matthias Clausen Deutsches Elektronen Synchrotron Gruppe: KRYK DESY/Hamburg, Germany ================================================================================ Archive-Date: Tue, 28 Jul 1992 07:48:02 CDT Sender: goathunter@WKUVX1.BITNET Date: Tue, 28 Jul 1992 07:50:08 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095E3D2.CF0D9960.2999@WKUVX1.BITNET> Subject: RE: MX <-> PC connection via dialup modems Matthias Clausen DESY -KRYK- / D-Hamburg writes: > >I want to send and receive mail from one (or more) PC's. >The connection VAX<->PC shall be setup by means of dialup modems. >I read about MultiTech's new MultiModem II which shall 'support' UUCP. > >Software on the VAX: VMS 5.4-3 / MX 3.1 and (UUCP ?) > Questions: > - Where do I get a UUCP version which will also do the dialup? > - If dialup is not possible - where can I get the DECUS UUCP 2.0 from? > DECUS UUCP can do both incoming and outgoing calls. You can the latest UUCP via anonymous ftp from: ftp.spc.edu in [.decus_uucp] mis1.mis.mcw.edu ftp.uu.net mvb.saic.com in [.decus_uucp] You can also get it from the latest DECUS VMS SIG tapes, or my U.S. Mail from Kent Brodie (brodie@fps.mcw.edu). Note that you have to send Kent the tape with a SASE. Contact Kent for more details. >Software on the PC: DOS (sigh) > Questions: > - Is there a way to get 'something' running under DOS? -how? > - If only UNIX is possible - what would be the solution? > I use UUPC/extended, which is available from a number of sites, including wuarchive.wustl.edu in "mirrors/msdos/uucp". We've used it for almost a year now to let our Novell LANs exchange e-mail with VMS. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Tue, 28 Jul 1992 16:54:38 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: Problem with mailserv auto notices Message-ID: Sender: (John Isenhour x3401) Date: Tue, 28 Jul 1992 21:03:09 GMT To: MX-List@WKUVX1.BITNET I just installed MX and I am having trouble with MLF not sending the appropriate files in mx_list_dir:*.txt. It will allow subscribe commands and then transfer correctly but it wont mail any kind of confirmation. If you send commands to -request (like help) its accepts them, and I get disk activity on the mx machine, but emailwize it does not return a response. As the list manager on the same node, I have been able to elicit a help message. From any other node it does not work. The only thing that seemed unusual was that the mlf config program did not ask for a disk:dir location for the list, just an archive filename. Any suggestions appreciated. -john ================================================================================ Archive-Date: Tue, 28 Jul 1992 18:59:22 CDT From: frzmtdb@aspentec.com Reply-To: MX-List@WKUVX1.BITNET Subject: Re: Mail problems with MX3.1 & UUCP2.0. SOLVED! DISK QUOTA PROBLEM. Message-ID: <1992Jul28.173013.850@aspentec.com> Date: 28 Jul 92 17:30:12 EST References: <1992Jul27.104946.849@aspentec.com> To: MX-List@WKUVX1.BITNET SOLVED: Thanks for the help... but it was a simple disk-quota problem. The owner of the files in the [mx...] directory tree was system, and it had gone over quota. Once I adjusted the quota... every was all ok. In article <1992Jul27.104946.849@aspentec.com>, frzmtdb@aspentec.com writes: > Has anyone experienced problems with the interface to UUCP from MX? > I recently installed UUCP 2.0 onto my system (which had been running > MX3.1C and UUCP1.3 just fine. > After the upgrade to UUCP2.0 I get the following messages in the > uucp_log:uuxqt.log file. > > Any ideas??? > > >> >>$ FAILED_RMAIL: >>Attempt to send mail to failed with status %X1000000C >>%RENAME-I-RENAMED, USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4798;1 renamed to USER6:[UUCP.SPOOL.ATUK]REMAIL_X.ATUK_A4798;1 >>p:uxqt =< h:- [07/27-10:16:01-22404365] Processing (USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4799;1) u:- >>p:uxqt << h:atuk [07/27-10:16:02-22404365] Executing (rmail ZIEGLER < UUCP_DISK:[UUCP.SPOOL.atuk]D.ATUK_A4799 > NL:) u:- >> Begin X file USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4799;1 at 27-JUL-1992 10:16:03.05 >>$ RMAIL USER6:[UUCP.SPOOL.ATUK]D.ATUK_A4799; "ZIEGLER" >>%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000072, PC=00030BF0, PSL=03C00021 >>%TRACE-F-TRACEBACK, symbolic stack dump follows >>module name routine name line rel PC abs PC >> >> 00030BF0 00030BF0 >> 0006FD11 0006FD11 >>MX_RMAIL MX_RMAIL 415 00000CC9 000028DD >>$ FAILED_RMAIL: >>Attempt to send mail to failed with status %X1000000C >>%RENAME-I-RENAMED, USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4799;1 renamed to USER6:[UUCP.SPOOL.ATUK]REMAIL_X.ATUK_A4799;1 >>p:uxqt =< h:- [07/27-10:16:12-22404365] Processing (USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4800;1) u:- >>p:uxqt << h:atuk [07/27-10:16:13-22404365] Executing (rmail HIBDEV < UUCP_DISK:[UUCP.SPOOL.atuk]D.ATUK_A4800 > NL:) u:- >> Begin X file USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4800;1 at 27-JUL-1992 10:16:14.12 >>$ RMAIL USER6:[UUCP.SPOOL.ATUK]D.ATUK_A4800; "HIBDEV" >>%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000072, PC=00030BF0, PSL=03C00021 >>%TRACE-F-TRACEBACK, symbolic stack dump follows >>module name routine name line rel PC abs PC >> >> 00030BF0 00030BF0 >> 0006FD11 0006FD11 >>MX_RMAIL MX_RMAIL 415 00000CC9 000028DD >>$ FAILED_RMAIL: >>Attempt to send mail to failed with status %X1000000C >>%RENAME-I-RENAMED, USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4800;1 renamed to USER6:[UUCP.SPOOL.ATUK]REMAIL_X.ATUK_A4800;1 >>p:uxqt =< h:- [07/27-10:16:26-22404365] Processing (USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4801;1) u:- >>p:uxqt << h:atuk [07/27-10:16:27-22404365] Executing (rmail MAHONEY < UUCP_DISK:[UUCP.SPOOL.atuk]D.ATUK_A4801 > NL:) u:- >> Begin X file USER6:[UUCP.SPOOL.ATUK]X.ATUK_A4801;1 at 27-JUL-1992 10:16:28.25 >>$ RMAIL USER6:[UUCP.SPOOL.ATUK]D.ATUK_A4801; "MAHONEY" >>%SYSTEM-F-ACCVIO, access violation, reason mask=04, virtual address=00000072, PC=00030BF0, PSL=03C00021 >>%TRACE-F-TRACEBACK, symbolic stack dump follows >>module name routine name line rel PC abs PC >> >> 00030BF0 00030BF0 >> 0006FD11 0006FD11 >>MX_RMAIL MX_RMAIL 415 00000CC9 000028DD >>$ FAILED_RMAIL: > > > ---- > Fred R. Ziegler Email: > Aspen Technology, Inc. tel: +1-617-497-9010 x262 > 251 Vassar St. fax: +1-617-497-7806 > Cambridge, Ma. 02139 telex: +1-948-038(ASPEN TECH) > U.S.A. > Internet Society Member (#1315080) since Feb 1992 ================================================================================ Archive-Date: Thu, 30 Jul 1992 11:18:08 CDT Date: Thu, 30 Jul 1992 09:12:20 PDT From: "Bob Johns, (604)363-6520" Reply-To: MX-List@WKUVX1.BITNET To: MX-List%wkuvx1.BITNET@cunyvm.cuny.edu CC: bob@ccs.ios.bc.ca Message-ID: <0095E570.9F855120.8897@ccs.ios.bc.ca> Subject: Distrib list stripped from "To:" header Can anyone explain why MX displays only my name in the "To:" header when a colleague has sent the message to several names via a distribution list from a Sun workstation? The colleague says on Sun's, the received message's "To:" header shows the complete list. But on MX v3.1B, only one name is shown. By the "To:" header, I mean the actual header as printed within the long list of various headers, not the "To:" extracted for VMSmail and displayed by VMSmail at the top. Not having any indication the message was originally sent to a list is confusing to the recipient. ------------------------------------------------------------------------ | 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: Thu, 30 Jul 1992 13:44:38 CDT From: Subject: Re: Distrib list stripped from "To:" header Message-ID: <1992Jul30.173056.13180@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <0095E570.9F855120.8897@ccs.ios.bc.ca> Date: Thu, 30 Jul 1992 17:30:56 GMT To: MX-List@WKUVX1.BITNET In article <0095E570.9F855120.8897@ccs.ios.bc.ca>, "Bob Johns, (604)363-6520" writes: >Can anyone explain why MX displays only my name in the "To:" header >when a colleague has sent the message to several names via a distribution >list from a Sun workstation? I expect because it was received that way. MX doesn't normally muck around with the RFC822 To: header. Wouldn't surprise me if the Sun was doing so before it sent the message to your system. You can confirm this by turning on debugging in the SMTP server and examining the resulting log file the next time a message of that type is sent. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Thu, 30 Jul 1992 14:26:32 CDT Sender: syssand@CCVAX.CCS.CSUS.EDU Date: Thu, 30 Jul 1992 12:13: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: <0095E589.F382BEC0.28779@CCVAX.CCS.CSUS.EDU> Subject: What's a valid username? Okay all you RFC822 experts, What comprises a valid username? I'm looking at RFC822 and am a little surprised because my interpretation of it is that "#" and "$" are legal characters for a username. Is this in fact correct? (The reason I ask, we're receiving messages from a username that contains an embedded "#" and sendmail is choking on it. I need to know if this is my problem or 'their' problem. And yes, this is on a U*ix system, not MX on our VAXen. So yes, I'm abusing this list by asking a non-MX question, but this is also where a lot of the mail experts live so please accept my apologies...) John F. Sandhoff, University Network Support California State University, Sacramento - USA sandhoff@csus.edu ================================================================================ Archive-Date: Thu, 30 Jul 1992 21:43:44 CDT From: goathunter@WKUVX1.BITNET Reply-To: MX-List@WKUVX1.BITNET Subject: WKUVX1 MXSERVER: Min. DECUS uucp v2.0 available Message-ID: <1992Jul30.165518.1906@wkuvx1.bitnet> Date: 30 Jul 92 16:55:18 CDT To: MX-List@WKUVX1.BITNET OK, I'm running an experiment here---we'll see if my BITNET link can hold up under the strain.... The minimum configuration needed for DECUS UUCP v2.0 and NEWS v6.1 (alpha release) is now available via e-mail from MXSERVER@WKUVX1.BITNET. This release is huge---155 60-block files! And this is only the absolute minimum savesets needed to get you going! *IF* you already have DECUS uucp running and you want to upgrade to v2.0, this is the kit for you. If you need the maps, etc., don't bother, 'cause they're not here. If you don't know what uucp is, don't bother.... This minimum set includes the uucp user's guide (USRGD020.MEM), the boot saveset (UU20BOOT.BKP), and the executables (RUN.BKP). Note that I'm not announcing this in comp.os.vms---just vmsnet.uucp and vmsnet.mail.mx.... Please understand that my BITNET link is still a 9600-baud line, and files *will* take a while to reach your site. Be patient---only request the package once. If several days elapse and you're still missing files, send me mail and I'll see if I can track them down for you. To get the package, send the following commands in the body of a mail message to MXSERVER@WKUVX1.BITNET: SEND UUCP020 SEND FILESERV_TOOLS For info on how to get the full DECUS uucp v2.0 distribution, send the command SEND UUCP020.HOW-TO-GET. If my BITNET link crumples from the strain, this offer may be deemed null and void. 8-) Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Thu, 30 Jul 1992 22:09:40 CDT Date: Thu, 30 Jul 1992 21:57:12 EDT From: Richard Ault Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: ault@max.queens.edu Message-ID: <0095E5DB.791E11A0.5296@max.queens.edu> Subject: Local agent crash with $STR-F-NOMSG (%x1024808C) We have been using MX sucessfully since May and are QUITE pleased with its installation, documentation, and functionality. Today we noted that we didn't seem to be getting any internet mail and noted that the Local agent process on one of our machines had gone away. The log shows nothing beyond the Local agent started message and accounting shows a detached process termination with error code 1024808C (which f$message claims is STR-F_NOMSG). I'm not sure what the STR facility is (string manipulation library?). All other processes were running and when I did MX_STARTUP LOCAL, all our queued up mail came in. Any ideas? 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: Fri, 31 Jul 1992 07:04:44 CDT Date: Fri, 31 Jul 1992 07:55:00 EDT From: Matt The Midnight Mortician Reply-To: MX-List@WKUVX1.BITNET To: MX-list@WKUVX1.BITNET Message-ID: <0095E62E.FC14E680.3339@vax1.elon.edu> Subject: help I appreciate the answers to my original questions about listservers on MX. I have created the following list using mlf_config: ! MX_DEVICE:[MX]MLF_CONFIG.MCP;2 ! Created: 31-JUL-1992 03:51:24.19 by MLF_CONFIG ! DEFINE LIST "emedia"- /OWNER="XXXXXXXXX@vax1.elon.edu"- /ERRORS_TO="XXXXXXXX@vax1.elon.edu"- /DESCRIPTION="Electronic Media Issues in Libraries"- /ARCHIVE=dua5:[emedia]- /PROTECTION=(S:RWED,O:RWED,G:RWED,W:E) XXXXXX=valid username on our system I sent (several) messages to emedia-request with "SUBSCRIBE" as the body and they just sit in the queue. This is a vax 8350 running vms 5.5. Any takers on this one???? also here is the queue listing $ mcp queue show /all /full Entry: 3317, Origin: [Local] Status: IN-PROGRESS, size: 321 bytes Created: 31-JUL-1992 06:21:43.48, expires 30-AUG-1992 06:21:43.48 Last modified 31-JUL-1992 06:28:00.89 MLIST/FSRV entry #3319, status: READY, size: 321 bytes Created: 31-JUL-1992 06:27:59.92, expires 30-AUG-1992 06:21:43.48 Last modified 31-JUL-1992 06:28:00.93 Recipient #1: emedia-request, Route=vax1.elon.edu Entry: 3332, Origin: [Local] Status: IN-PROGRESS, size: 328 bytes Created: 31-JUL-1992 06:54:28.62, expires 30-AUG-1992 06:54:28.62 Last modified 31-JUL-1992 06:55:10.61 MLIST/FSRV entry #3333, status: READY, size: 328 bytes Created: 31-JUL-1992 06:55:09.90, expires 30-AUG-1992 06:54:28.62 Last modified 31-JUL-1992 06:55:10.65 Recipient #1: emedia-request, Route=vax1.elon.edu Entry: 3335, Origin: [Local] Status: IN-PROGRESS, size: 16 bytes Created: 31-JUL-1992 07:17:13.69, expires 30-AUG-1992 07:17:13.69 Last modified 31-JUL-1992 07:17:29.28 MLIST/FSRV entry #3336, status: READY, size: 16 bytes Created: 31-JUL-1992 07:17:28.30, expires 30-AUG-1992 07:17:13.69 Last modified 31-JUL-1992 07:17:29.31 Recipient #1: listserv, Route=vax1.elon.edu I even tried sending it to listserv Entry: 3337, Origin: [Local] Status: IN-PROGRESS, size: 4 bytes Created: 31-JUL-1992 07:17:31.88, expires 30-AUG-1992 07:17:31.88 Last modified 31-JUL-1992 07:17:40.42 MLIST/FSRV entry #3338, status: READY, size: 4 bytes Created: 31-JUL-1992 07:17:39.49, expires 30-AUG-1992 07:17:31.88 Last modified 31-JUL-1992 07:17:40.46 Recipient #1: listserv, Route=vax1.elon.edu HELP!!!!! Thanks in advance, Matt "System security is a state of mind. Real security is a warm blanket." Matthew T. Harttree HARTTREE@VAX1.ELON.EDU +919-584-2295 / +919-570-8120 (voice mail) / +919-584-2575 (FAX) ------------------------------ [insert famous libility release statement here!] ================================================================================ Archive-Date: Fri, 31 Jul 1992 07:10:56 CDT Sender: goathunter@WKUVX1.BITNET Date: Fri, 31 Jul 1992 07:12:49 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0095E629.17924FC0.3596@WKUVX1.BITNET> Subject: RE: help Matt The Midnight Mortician writes: > >I appreciate the answers to my original questions about listservers on >MX. > >I have created the following list using mlf_config: > [...] >I sent (several) messages to emedia-request with "SUBSCRIBE" as the body and >they just sit in the queue. This is a vax 8350 running vms 5.5. Any takers on >this one???? > Sounds like the MLF process may not be running. Is it (MX MLF) there? Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Fri, 31 Jul 1992 12:41:21 CDT Date: 31 Jul 1992 11:43:48 -0400 (EDT) From: "G. Del Merritt" Reply-To: MX-List@WKUVX1.BITNET Subject: MX and match mail To: MX-List@WKUVX1.BITNET Message-ID: <0095E64EF2F88AA0.2F004FCA@giant.IntraNet.com> I've just subscribed to the MX-List 'cause I'm about to install MX - I think. I'd like to run down what I want to do and elicit comments suggestions. (Please respond by mail as well as to the list, since I have yet to receive confirmation that my SUBSCRIBE request "took".) I have a small cluster of VAXen and a single, non-clustered 11/750 on the same ethernet. All have DECnet; one cluster node runs DEC's UCX; another one has Process Software's TCPware for VMS; the others and the 750 will eventually run CMU-TEK IP/TCP. For "security" and compartmentalization reasons, we want to move UUCP (our hook to the outside world) from the cluster to the 750. This makes the 750 the "corporate mail gateway". My question is: can/will MX help me make a gracefull transition? I would like my cluster users, who are used to typing: To: uucp%"JLuser@somecorp.com" to just switch to something equally easy as: To: mx%"JLuser@somecorp.com" Sooo, what's the best/right way to do this? Should I have MX running on the cluster and the 750? Should/could they talk via DECnet, or must it be a TCP/IP? Can MX just mung VAX MAIL addresses, inbound and outbound, to "to the right thing"? I have MX 2.3 (plus the 2.3-1 upgrade) on tape. Would it be more worth my while to drag 3.x off the net? (Since I'm a uucp site without direct FTP access, it would have to come in as encoded/split mail.) Thanks for your thoughts; a pointer to an appropriate FAQ entry would be appreciated. Del Merritt del@IntraNet.com ccavax!giant!del IntraNet, Inc., 255 Washington Street, Newton, MA 02158 Voice: 617-527-7020; FAX: 617-527-6779 ================================================================================ Archive-Date: Fri, 31 Jul 1992 17:54:50 CDT Date: Fri, 31 Jul 1992 15:53:17 PDT From: Tim Hedrick Reply-To: MX-List@WKUVX1.BITNET To: MX-List@RPIECSVX.BITNET Message-ID: <0095E671.CD384E40.290@SYBIL.risc.rockwell.com> Subject: Changing an incorrect destination address in MX 3.1? MX'ers: Does anyone know of a way to change an incorrect destination address once a message has been queued? Is the _best_ approach to edit the message SRC_INFO file? If so, does anyone have a convenient way of doing this? If not, what is the _best_ approach? Any info would be appreciated. Thanks! Tim Hedrick VAX Systems Manager Science Center Rockwell International tkh@risc.rockwell.com