Archive-Date: Sat, 01 Feb 1997 00:01:41 EST Sender: owner-mx-list@wku.edu Date: Sat, 01 Feb 1997 00:01:27 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@LISTS.WKU.EDU Message-ID: <009AF35B.887E9083.47@wku.edu> Subject: MX-LIST Administrivia: Monthly Post Posting statistics for list MX-LIST during January 1997 Total number of posts: 69 Total number of posters: 36 Total number of subscribers: 298 Last modified: 28-SEP-1995 13:33 (Updated digest info) Welcome to MX-List@LISTS.WKU.EDU, 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. MX-List postings are also available in a daily digest format. To subscribe to the digest, send the following command in the body of a mail message to MXserver@LISTS.WKU.EDU: SUBSCRIBE MX-List-Digest "Your real name here" The MX-List archives are maintained at ARCHIVES@LISTS.WKU.EDU. To get a copy of any month's postings, send an e-mail message with the body SEND MX-List.yyyy-mm to ARCHIVES@LISTS.WKU.EDU, 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. MX itself is available via anonymous ftp from ftp.spc.edu in [.MX.MX041]. You can also get it via e-mail by sending the commands SEND MX and SEND FILESERV_TOOLS on separate lines in the body of a mail message to FILESERV@LISTS.WKU.EDU. To remove yourself from the mailing list, send the following command to MXserver@LISTS.WKU.EDU: SIGNOFF MX-List MXserver 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 DIGEST - to switch to digest mode SET MX-List NODIGEST - to switch to non-digest mode 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, Sr. OpenVMS Systems Programmer goathunter@MadGoat.com Process Software P.O. Box 51745 Bowling Green, KY 42102-6745 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ================================================================================ Archive-Date: Sat, 01 Feb 1997 13:38:58 EST Sender: owner-mx-list@wku.edu Date: Sat, 1 Feb 1997 11:38:48 -0800 From: DWING@TGV.COM (Dan Wing) Reply-To: MX-List@MadGoat.com To: RANDREW@cctr.UMKC.Edu, MX-LIST@WKUVX1.WKU.EDU Message-ID: <970201113848.202a556a@tgv.com> Subject: Re: Reply is broken In article <009AF2EE.30FD629D.1633@CCTR.UMKC.EDU>, Andy Rupf writes: > >Here is an eiree thing. >We have headers turned down but not quite off. >Has anyone seen anything like this before? > > #7 31-JAN-1997 08:43:45.87 NEWMAIL >From: IN%"INFO-CSTP@CSTP.UMKC.EDU",IN%"lhsin@CSTP.UMKC.EDU" >To: IN%"info-cstp@CSTP.UMKC.EDU" >CC: >Subj: the directory > > [truncated for brevity] > >MAIL> reply >To: IN%"INFO-CSTP@CSTP.UMKC.EDU"",IN%""lhsin@CSTP.UMKC.EDU" >%MAIL-E-USERSPEC, invalid user specification '",IN%""lhsin@CSTP.UMKC.EDU"' > >This is happening on all our lists (at least) that include two >addresses on the TO: line (with reply_to=(sender,list) for instance) > > Andy Rupf > RANDREW@CCTR.UMKC.EDU > Programmer/Analyst ----- University of Missouri-Kansas City > Life is an uncertified flight mode. The "From" line you show us (above) has the correct number of quotes around the address. However, the addresses displayed in the REPLY don't have the correct number of quotes. I also noticed it shows IN% -- are you running PMDF, or have you modified MX's logicals to show IN% instead of MX% for mail received by MX?? -Dan Wing dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Mon, 03 Feb 1997 09:18:50 EST Sender: owner-mx-list@wku.edu Date: Mon, 03 Feb 1997 09:18:09 CST From: Andy Rupf Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF53B.A2E77B7E.142@CCTR.UMKC.EDU> Subject: Re: Reply is broken <>From: IN%"INFO-CSTP@CSTP.UMKC.EDU",IN%"lhsin@CSTP.UMKC.EDU" <>To: IN%"info-cstp@CSTP.UMKC.EDU" <>CC: <>Subj: the directory <> <> [truncated for brevity] <> <>MAIL> reply <>To: IN%"INFO-CSTP@CSTP.UMKC.EDU"",IN%""lhsin@CSTP.UMKC.EDU" <>%MAIL-E-USERSPEC, invalid user specification '",IN%""lhsin@CSTP.UMKC.EDU"' <> <>This is happening on all our lists (at least) that include two <>addresses on the TO: line (with reply_to=(sender,list) for instance) Date: Mon, 03 Feb 1997 08:21:25 -0600 To: MX-List@MadGoat.com From: Tom Dolan Reply-To: MX-List@MadGoat.com Subject: Footers MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" MX-Listers, Does anyone know how to put a "footer" on the bottom of every message posted to any specific mailing list? For example I want to put the following at the bottom of every TICTALK@Bible.acu.edu message: To unsubscribe from Tictalk send a message to Tictalk-Request@Bible.acu.edu with the word unsubscribe in it. I'm using MX 4.2 with VAX/VMS 6.1 Thanks! Tom Dolan Dolan@Bible.acu.edu 915.674.3706 202 Bible Building Systems Manager ACU Box 29454 College of Biblical and Family Studies Abilene, TX 79699 Abilene Christian University FAX 915.674.3776 ================================================================================ Archive-Date: Mon, 03 Feb 1997 09:47:33 EST Sender: owner-mx-list@wku.edu Date: Mon, 03 Feb 1997 09:47:19 CST From: Gary Lee McDonald Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF53F.B6010A46.159@CCTR.UMKC.EDU> Subject: RE: Footers Date sent: 3-FEB-1997 09:42:41 Tom, >MX-Listers, > >Does anyone know how to put a "footer" on the bottom of every >message posted to any specific mailing list? > >For example I want to put the following at the bottom of every >TICTALK@Bible.acu.edu message: > >To unsubscribe from Tictalk send a message to >Tictalk-Request@Bible.acu.edu with the word unsubscribe in it. We have a symbol, SETUP_MAIL, which invokes the following. Hope this is of somne help. :-) ================== $ set noverify $ ! $ ! Setup_Mail.Com - Ron Rockwell 09/08/94 $ ! $ ! $ esc[0,8]=27 $ clreol = esc+"[K " $ bold = esc+"[1m" $ blink = esc+"[5m" $ plain = esc+"[0m" $ type sys$input This procedure sets up the mail environment in a semi-custom manner, with a signature file, MAIL subdirectory, forward editing, mouse options and the EVE editor. This procedure may be run more than once if necessary. $ inquire/nopunc dummy "Would you like to proceed? [y]: " $ if dummy .eqs. "" then dummy = "Y" $ if dummy .nes. "Y" then exit $ ! $ ! Set up the mail environment, and our environment in this command file. $ ! $ clear $ write sys$output "Working. . . one moment please." $ old_default = f$environment("DEFAULT") $ set default sys$login $ $! node_name = f$element(0," ",f$getsyi("NODENAME")) $ node_name = "CCTR" $ domain = "UMKC.EDU" $ $ mail :== mail/edit=(send,reply=extract,forward) $ $ define/user_mode sys$output sys$scratch:_$_createmail_$_.err $ mail set mail_directory [.mail] $ delete/nolog/noconfirm sys$scratch:_$_createmail_$_.err;* $ deassign sys$output $ $ acct = f$environment("default") $ acct = f$extract(0,f$locate("]",acct),acct)+".mail]" $ define/nolog mail_root 'acct' $ define/nolog mail$edit mail_root:mailedit.com $ new_sig :== @mail_root:new_sig.com" $ set broadcast=all $ ! $ ! Set up the mailing environment for future logins. $ ! This loop creates a login.com if none exists, then opens the $ ! login.com and a temporary file, reads the login.com line per $ ! line writing each line to the temporary file. It will exclude $ ! writing any lines that refer to mail, the var ACCT or broadcast $ ! and upon reaching the end of the file or an exit, inserts the $ ! necessary lines for mail-setup therein. When through, the tempfile $ ! is renamed to login.com and then login.com is purged. $ ! $ ! $ set on $ on control_y then continue $ present = f$search("LOGIN.COM") $ if present .eqs. "" $ then $ open/write ofile login.com $ write ofile "$ if f$mode() .nes. ""INTERACTIVE"" then exit" $ write ofile "$ show quota" $ write ofile "$ write sys$output """"" $ close ofile $ endif $ first_pass = 0 $ blind = 0 $ open/read ifile login.com $ open/write ofl sys$scratch:_$_createmail_$_.tmp $ read_loop: $ read/end_of_file=insert ifile line $ pline = f$edit(line,"LOWERCASE") $ lsize = f$length(pline) $ ! $ ! Currently: $ ! skips until a first char of $ if it sees sys$input. $ ! skips the line if it contains mention of "mail" $ ! passes anything with "f$mode" even though it may have "exit" $ ! otherwise inserts before 1st line containing @ or exit. $ ! $ if blind .eq. 1 $ then $ if f$extract(0,1,pline) .eqs. "$" then blind = 0 $ endif $ if f$locate("mail",pline) .lt. lsize then goto skipit $ if first_pass .gt. 0 then goto no_insert $ if f$locate("sys$input",pline) .lt. lsize then blind = 1 $ if blind .eq. 1 then goto no_insert $ if f$locate("f$mode",pline) .lt. lsize $ then $ write ofl line $ write ofl "$ inquire/nopunc what ""Press Return to continue."" ! mail" $ goto skipit $ endif $ if f$locate("call ",pline) .lt. lsize then goto insert $ if f$locate("gosub ",pline) .lt. lsize then goto insert $ if f$locate("@",pline) .lt. lsize then goto insert $ if f$locate("exit",pline) .lt. lsize then goto insert $ no_insert: $ write ofl line $ skipit: $ line = "$$$$$" $ goto read_loop $ insert: $ if first_pass .gt. 0 then goto done_deal $ first_pass = 1 $ write ofl "$ ! mail" $ write ofl "$ mail :== mail/edit=(send,reply=extract,forward) ! mail" $ write ofl "$ acct = f$environment(""default"") ! mail" $ write ofl "$ acct = f$extract(0,f$locate(""]"",acct),acct)+"".mail]"" ! mail" $ write ofl "$ define/nolog mail_root 'acct' ! mail" $ write ofl "$ define/nolog mail$edit mail_root:mailedit.com ! mail" $ write ofl "$ new_sig :== @mail_root:new_sig.com ! mail" $ write ofl "$ ! mail" $ done_deal: $ if line .eqs. "$$$$$" then goto closeit $ write ofl line $ line = "$$$$$" $ goto read_loop $ closeit: $ close ifile $ close ofl $ rename/noconfirm sys$scratch:_$_createmail_$_.tmp login.com $ ! $ ! Create the EVE command file. (this calls eve in various ways $ ! depending on whether user is replying or not, etc...) $ ! $ open/write file mail_root:mailedit.com $ write file "$ set noverify" $ write file "$ define/user tpu$section mail_tpu$section" $ write file "$ define/user sys$input 'f$trnlnm(""sys$output"")" $ write file "$ if p1 .eqs. """" then goto noinput" $ write file "$ edit/tpu/init=mail_root:mailedit.ini/output='p2 'p1" $ write file "$ exit $ write file "$ noinput: $ write file "$ edit/tpu/nocommand/init=mail_root:mailedit.ini 'p2" $ write file "$ exit" $ close file $ purge/nolog/noconfirm mail_root:mailedit.com $ ! $ ! Create the EVE initializing file. (Instructions for EVE on start up) $ ! This file does the insert, and turns of the mouse for EVE, then $ ! tosses in the signature file. $ ! $ type sys$input When using an Xterminal, the mouse may be used to copy portions of the screen into your mail, or may be used to control the cursor position only. The next question will decide how the EVE editor is initialized. If you wish to cut and paste with your mouse, then answer "y", if you wish to point with your mouse, answer "n". $ inquire/nopunc copy_mouse "Do you wish to cut and paste with your mouse? [y]: " $ if copy_mouse .eqs. "" then copy_mouse = "y" $ type sys$input When forwarding and replying to MAIL, the original message will be included in the forward or reply so that its portions may be referenced if necessary. When this insertion is performed a character such as a ">" is inserted at the beginning of each line so that the reader may know that it was text that was included as reference. You may pick any character you wish to denote references. $ read/prompt="What character would you like? [>]: " sys$command char $ lent = f$string(f$length(char)) $ if lent .eq. 0 $ then $ char = ">" $ lent = 1 $ endif $ open/write file mail_root:mailedit.ini $ if copy_mouse then write file "tpu set(mouse,off)" $ write file "tpu insert_repeat(""''char'"",''lent')" $ write file "bottom" $ write file "include file mail_root:SIGNATURE.TXT" $ close file $ purge/nolog/noconfirm mail_root:mailedit.ini $ ! $ ! Create the Signature Editor file. $ ! $ open/write file mail_root:new_sig.com $ write file "$ set noverify" $ write file "$ define/nolog/user_mode sys$input sys$command $ write file "$ eve mail_root:signature.txt" $ write file "$ purge/nolog/noconfirm mail_root:signature.txt" $ close file $ purge/nolog/noconfirm mail_root:new_sig.com $ ! $ ! Create a default signature file. $ ! $ present = f$search("SIGNATURE.TXT") $ if present .nes. "" then rename/noconfirm signature.txt [.mail]signature.txt $ $ name_again: $ type sys$input This procedure requires your name as you wish it to appear in your signature file. The signature file will be automatically included in all of your outgoing mail. $ myname = f$edit(f$getjpi("","username"),"TRIM") $ read/prompt="What is your first name: " sys$command fname $ read/prompt="What is your last name: " sys$command lname $ $ if f$length(fname) .lt. 2 then goto name_again $ if f$length(lname) .lt. 2 then goto name_again $ fname=f$edit(fname,"TRIM") $ lname=f$edit(lname,"TRIM") $ first=f$extract(0,1,fname) $ last=f$extract(1,f$length(fname)-1,fname) $ first=f$edit(first,"UPCASE") $ fname=first+last $ first=f$extract(0,1,lname) $ last=f$extract(1,f$length(lname)-1,lname) $ first=f$edit(first,"UPCASE") $ lname=first+last $ $ rname = fname + " " + lname $ $ next_step: $ rname = rname + f$fao("!78* ") $ myname = myname + "@"+ node_name + "." + domain + f$fao("!78* ") $ myname = " "+f$extract(0,43,myname)+"University of Missouri, Kansas City" $ $ pass = 0 $ write sys$output " " $ write sys$output "''fname', please tell me . . ." $ tellme: $ type sys$input How would you like your title to be specified? This next question will fill in an area in your signature file, as well. If you cannot think of anything, answer with your department name, a slogan, or your nickname, or fill in the blank: "I wished to be referred to as a ________ ." $ inquire/nopunc mytitle "Title for your signature file: " $ if mytitle .nes. "" then goto finish $ write sys$output " " $ pass = pass + 1 $ if pass .eq. 1 then write sys$output "Please ''fname', don't be shy," $ if pass .eq. 2 then write sys$output "I am waiting, ''fname'," $ if pass .eq. 3 then write sys$output "Don't force me to default, ''fname'" $ if pass .lt. 4 then goto tellme $ mytitle = "Unemployed Hobo" $ $ finish: $ if f$length(mytitle) .gt. 32 then mytitle = f$extract(0,32,mytitle) $ mytitle = " "+f$edit(mytitle,"LOWERCASE") $ x = 0 $ capitalize: $ if f$extract(x,1,mytitle) .nes. " " then goto smaller $ y = x + 1 $ z = x + 2 $ first = f$extract(0,y,mytitle) $ mid = f$extract(y,1,mytitle) $ last = f$extract(z,f$length(mytitle)-z,mytitle) $ mytitle = first + f$edit(mid,"UPCASE") + last $ smaller: $ x = x + 1 $ if x .lt. f$length(mytitle) then goto capitalize $ mytitle = " "+f$extract(1,f$length(mytitle)-1,mytitle) $ rname = " "+f$extract(0,42,rname) + mytitle $ $ new_file = 0 $ present = f$search("MAIL_ROOT:SIGNATURE.TXT") $! goto killoldfile $ if present .nes. "" $ then $ again: $ clear $ write sys$output bold,"OLD FILE FOUND:",plain,clreol $ type mail_root:signature.txt $ write sys$output " " $ write sys$output " " $ write sys$output bold,"NEW FILE:",plain,clreol $ write sys$output " " $ write sys$output " ",f$fao("!78*-") $ write sys$output rname $ write sys$output myname $ write sys$output " ",f$fao("!78*-") $ write sys$output " " $ type sys$input A previous signature file was found in your account. It is shown above. An automatic signature file may be furnished for you now, it is shown below the old version. Would you like to keep your OLD file, replace it with the NEW file, or REDISPLAY the two files? A one letter response is sufficient. If you simply want to CHANGE your Name and Title press "C". $ inquire iwant " (Old/New/Change/Redisplay)" $ iwant = f$edit(f$extract(0,1,iwant),"UPCASE") $ if iwant .eqs. "O" then new_file = 2 $ if iwant .eqs. "N" then new_file = 1 $ if iwant .eqs. "C" then goto name_again $ if new_file .lt. 1 then goto again $ else $ new_file = 1 $ endif $ killoldfile: $ !new_file = 1 $ if new_file .eq. 1 $ then $ open/write file mail_root:signature.txt $ write file "" $ write file " ",f$fao("!78*-") $ write file rname $ write file myname $ write file " ",f$fao("!78*-") $ close file $ purge/nolog/noconfirm mail_root:signature.txt $ endif $ $ clear $ type mail_root:signature.txt $ type sys$input Your signature file is shown above. For easy access to edit it, the command NEW_SIG has been added to your account. If you want to edit the signature file, and purge the old copy, just type in NEW_SIG at your DCL prompt. This command has been added to your login for easy maintenance of the signature file. Your LOGIN.COM has been rewritten to enable changes. The old version has not been purged. All modifications made by this procedure are labeled with the comment "! mail". $ write sys$output "Setup_Mail.Com v.2.9 - 2/8/96 RR" $ write sys$output "" $ set def 'old_default' ==================== > >I'm using MX 4.2 with VAX/VMS 6.1 > >Thanks! > > >Tom Dolan Dolan@Bible.acu.edu 915.674.3706 202 Bible Building >Systems Manager ACU Box 29454 >College of Biblical and Family Studies Abilene, TX 79699 >Abilene Christian University FAX 915.674.3776 UMKC GaryM. 5100 Rockhill Road Univ. of Mo. at K.C. Cockefair Hall (816) 235-1183 (work) 346-3447 (pager) Room 2, Gary Lee McDonald MCDONALD @ CCTR.UMKC.EDU Kansas City, Mo. 64110 POSTMASTER @ CCTR.UMKC.EDU ================================================================================ Archive-Date: Mon, 03 Feb 1997 10:16:42 EST Sender: owner-mx-list@wku.edu Date: Mon, 03 Feb 1997 10:16:36 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF543.CCCFD458.7@ALPHA.WKU.EDU> Subject: Re: Reply is broken Andy Rupf writes: > > > Thanks, but I'd figured that part out unfortunately. > More explicitly, do you know what can I do about it? > Nothing you can do about it, as far as I can tell. The problem is in VMS MAIL. It apparently doesn't expect there to be more than one address on the To: line for a REPLY. This is under OpenVMS Alpha V7.0: MAIL> repl To: MX%"goathunter@MadGoat.com"",MX%""goathunter@goat.process.com" Invalid user specification '",MX%""goathunter@goat.process.com"' VMS MAIL is apparently doubling up the quotes in the quoted message without realizing that there are two separate addresses there. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Mon, 03 Feb 1997 10:21:07 EST Sender: owner-mx-list@wku.edu Date: Mon, 03 Feb 1997 10:20:58 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@LISTS.WKU.EDU Message-ID: <009AF544.69805C2C.14@ALPHA.WKU.EDU> Subject: Searchable MX-List archives are available again! FYI, the MX-List archives are now available for searching via the WWW. The Gopher search was taken down a couple of months ago. Last weekend, I finally made the time to get them going under the WWW. For the next two weeks, they're running on an experimental WWW server running on port 81 at www2.wku.edu. Use this URL: http://www2.wku.edu:81/scripts/mxarchive/as_init.com?MX-List On February 14th, this server will be moved to port 80 (the default WWW server port). Until then, the server on port 81 may or may not be running, but you can try it. After 14-FEB-1997, the URL will be: http://www2.wku.edu/scripts/mxarchive/as_init.com?MX-List Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Mon, 03 Feb 1997 10:42:53 EST Sender: owner-mx-list@wku.edu Message-ID: <3.0.32.19970203104521.00867470@Bible.acu.edu> Date: Mon, 03 Feb 1997 10:45:23 -0600 To: MX-List@MadGoat.com From: Tom Dolan Reply-To: MX-List@MadGoat.com Subject: RE: Footers MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Gary, I need a system that will automatically add a "footer" to outgoing MX MLF mailing list posts that are never handled by VMS Mail and its editing functions. It doesn't look like any of the SETUP_MAIL procedures from your site will work within MX.... Thanks anyway! >We have a symbol, SETUP_MAIL, which invokes the following. Hope this is of >somne help. :-) Tom Dolan Dolan@Bible.acu.edu 915.674.3706 202 Bible Building Systems Manager ACU Box 29454 College of Biblical and Family Studies Abilene, TX 79699 Abilene Christian University FAX 915.674.3776 ================================================================================ Archive-Date: Mon, 03 Feb 1997 10:51:23 EST Sender: owner-mx-list@wku.edu Date: Mon, 03 Feb 1997 10:51:06 CST From: Andy Rupf Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF548.9F0A7BCF.180@CCTR.UMKC.EDU> Subject: Re: Reply is broken <> <> Thanks, but I'd figured that part out unfortunately. <> More explicitly, do you know what can I do about it? <> repl Subject: Messages from List Owner not being executed Dear list members, I'm having a problem sending commands to the MXSERVER from what is supposed to be the list owner. What makes it interesting is that the messages are not executed, but are instead echoed to the complete SYSTEM_USERS list. I have defined the list as such: MCP> sh list inside Mailing lists: Name: INSIDE Owner: "Postmaster@USNEWS.COM" Reply-to: NOList, Sender Add message: CDS:[DATA.LISTSERV]INSIDE_ADD_MESSAGE.TXT Remove message: CDS:[DATA.LISTSERV]INSIDE_REMOVE_MESSAGE.TXT Description: U.S.News Internal Mailing List Errors-to: Postmaster@usnews.com Strip header: NOReceived, NOOther Private list: No Case sensitive: No Digest support: No Protection: (SYSTEM:RWED,OWNER:RWED,GROUP:RWED,WORLD) The owner "Postmaster@USNEWS.COM" is a VMS alias pointing to another account. My system users list does NOT contain "Postmaster@USNEWS.COM". I'm sending my control messages from Eudora, which has a return address configured as Postmaster@USNEWS.COM. (I even duplicated the capitalization, in case that were the problem.) I send the message from Eudora, which never recieves a response (or bounce). All the system users then recieve the message: #1 3-FEB-1997 11:46:02.88 NEWMAIL From: SMTP%"Postmaster@USNEWS.COM" "Ralph Broom" To: SMTP%"mxserver@usnews.com" CC: Subj: Test REMOVE (second attempt) remove /nonotify INSIDE BHENNING@USNEWS.COM remove /nonotify INSIDE KACQUARO@USNEWS.COM -------------------------------------------------------------------------------- Return-Path: Received: from CDS_RBROOM.dc.usnews.com ([10.1.2.26]) by dino.usnews.com (MX V4.2 AXP) with SMTP; Mon, 03 Feb 1997 11:45:38 -0500 Message-ID: <2.2.16.19970203164537.0ae70b98@pop3.usnews.com> X-Sender: postman@pop3.usnews.com X-Mailer: Windows Eudora Pro Version 2.2 (16) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 03 Feb 1997 11:45:37 -0500 To: mxserver@usnews.com From: Ralph Broom Subject: Test REMOVE (second attempt) I am at a loss as to what I'm doing wrong. According to my reading of the text, this should work like a charm. Does anyone have a suggestion, or perhaps see something I've missed? I can provide more information if required. Thank you, -Ralph Broom- Operator, U.S.News & World Report ================================================================================ Archive-Date: Mon, 03 Feb 1997 11:55:47 EST Sender: owner-mx-list@wku.edu Date: Mon, 03 Feb 1997 12:55:24 EST From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: Dolan@Bible.acu.edu, hardis@garnet.nist.gov Message-ID: <009AF559.FC896C00.1@garnet.nist.gov> Subject: RE: Footers > Does anyone know how to put a "footer" on the bottom of every > message posted to any specific mailing list? Take my oft-repeated recipie for making a mailing list moderated, using the SITE agent. As the message passes through SITE, use the APPEND command to add your "footer" to the end of the message. Instead of sending the message to an actual moderator, have SITE finish the job of sending the message on its way. - Jonathan P.S. -- I am extraordinarily busy this week, and this is all the elaboration I can offer. ================================================================================ Archive-Date: Mon, 03 Feb 1997 13:08:26 EST Sender: owner-mx-list@wku.edu Date: Mon, 03 Feb 1997 13:08:20 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF55B.CA9C0B5F.3@ALPHA.WKU.EDU> Subject: RE: Messages from List Owner not being executed BROOM@USNEWS.COM writes: > >I'm having a problem sending commands to the MXSERVER from what is supposed to >be the list owner. What makes it interesting is that the messages are not >executed, but are instead echoed to the complete SYSTEM_USERS list. > This happens when you make the Postmaster the owner of a list. MX MLF has a special test in it to detect mail that bouncing around inside a host. If the message is from the POSTMASTER on the local node, it gets forwarded to the system users. Basically, you need to use some other address besides "Postmaster" as the owner of your lists. I don't remember if this is mentioned in the MX docs or not. Probably not, though I should add that..... Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Tue, 04 Feb 1997 08:54:28 EST Sender: owner-mx-list@wku.edu Message-ID: <199702041449.JAA29509@redstone.interpath.net> From: "Rich Hill" To: MX-List@MadGoat.com Date: Tue, 4 Feb 1997 09:47:43 -0400 Subject: Re: Messages from List Owner not being executed Reply-To: MX-List@MadGoat.com Content-Type: text > >I'm having a problem sending commands to the MXSERVER from what is supposed to > >be the list owner. What makes it interesting is that the messages are not > >executed, but are instead echoed to the complete SYSTEM_USERS list. > > > This happens when you make the Postmaster the owner of a list. MX MLF > has a special test in it to detect mail that bouncing around inside a > host. If the message is from the POSTMASTER on the local node, it > gets forwarded to the system users. > > Basically, you need to use some other address besides "Postmaster" as > the owner of your lists. > > I don't remember if this is mentioned in the MX docs or not. Probably > not, though I should add that..... I am having this same problem on one of my lists BUT postmaster is NOT the list owner. Here is the output from an MCP SHOW LIST command: Name: xxx-xxxxxxxx-xxxxxx-xxxxx Owner: "xxx@COMPORTS.COM" "nnnnn.nnnn@COMPUSERVE.COM" Reply-to: NOList, Sender Archive: SIM_INFO: Description: xxxxxxxxxxxxxxxxxxxxxxxxxxx Errors-to: xxx@comports.com Strip header: Received, Other Private list: Yes Case sensitive: No Digest support: No Protection: (SYSTEM:RWED,OWNER:RWED,GROUP,WORLD) When the owner sends messages to the list (and the -request address) those are forwarded to the SYSTEM_USERS list. When I, as a member of the SYSTEM_USERS list send the messages, all is fine. Any other suggestions? Is the list name too long? TIA, Rich Hill -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rich Hill S I M Rich.Hill@sim.org Systems Engineer b y EasyLink: 62923838 SIM USA, Inc. P r a y e r Phone: 1-704-587-1462 Charlotte, NC since 1893 FAX: 1-704-587-1518 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- [SC] Smiley captioned for the humor impaired. ================================================================================ Archive-Date: Tue, 04 Feb 1997 09:58:59 EST Sender: owner-mx-list@wku.edu Date: Tue, 04 Feb 1997 09:58:51 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF60A.7CCCA76D.23@ALPHA.WKU.EDU> Subject: Re: Messages from List Owner not being executed "Rich Hill" writes: > >When the owner sends messages to the list (and the -request address) >those are forwarded to the SYSTEM_USERS list. When I, as a member of the >SYSTEM_USERS list send the messages, all is fine. Any other suggestions? >Is the list name too long? > No. The best thing to do in all cases like this is to enable debug logs for MX Router and MX MLF: $ define/system/exec mx_router_debug true $ define/system/exec mx_mlf_debug true Executing those commands will cause log files to be created in MX_ROUTER_DIR: and MX_MLF_DIR: that should show you exactly what's going on. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Tue, 04 Feb 1997 10:37:48 EST Sender: owner-mx-list@wku.edu Message-ID: <3.0.32.19970204094003.0086dde0@Bible.acu.edu> Date: Tue, 04 Feb 1997 09:40:05 -0600 To: MX-List@MadGoat.com From: Tom Dolan Reply-To: MX-List@MadGoat.com Subject: Re: Messages from List Owner not being executed MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Rich et al, It's been my experience that MX list owner entries are case sensitive (MX4.2 in VMS 6.1) For example if sho list says: Name: xxx-xxxxxxxx-xxxxxx-xxxxx Owner: "DOLAN@COMPORTS.COM" But my email header says: To: xxx-requset@xxx.xxx From: Dolan@COMPORTS.COM Subject: MX does not recognize me as a valid list owner. I usually set myself up with two or three listowner entries so I can send commands from several systems (email client positions - ie VMSMail, Eudora etc.): Name: xxx-xxxxxxxx-xxxxxx-xxxxx Owner: "DOLAN@COMPORTS.COM" "Dolan@COMPORTS.COM" "dolan@COMPORTS.COM" Also don't forget to reset or restart MX processes after adding a new list owner or it won't recognize the new owner: MLF>reset/cluster mlf,router Tom Dolan At 09:47 AM 2/4/97 -0400, you wrote: >> >I'm having a problem sending commands to the MXSERVER from what is supposed to >> >be the list owner. What makes it interesting is that the messages are not >> >executed, but are instead echoed to the complete SYSTEM_USERS list. >> > >> This happens when you make the Postmaster the owner of a list. MX MLF >> has a special test in it to detect mail that bouncing around inside a >> host. If the message is from the POSTMASTER on the local node, it >> gets forwarded to the system users. >> >> Basically, you need to use some other address besides "Postmaster" as >> the owner of your lists. >> >> I don't remember if this is mentioned in the MX docs or not. Probably >> not, though I should add that..... > >I am having this same problem on one of my lists BUT postmaster is NOT >the list owner. Here is the output from an MCP SHOW LIST command: > > Name: xxx-xxxxxxxx-xxxxxx-xxxxx > Owner: "xxx@COMPORTS.COM" > "nnnnn.nnnn@COMPUSERVE.COM" > Reply-to: NOList, Sender > Archive: SIM_INFO: > Description: xxxxxxxxxxxxxxxxxxxxxxxxxxx > Errors-to: xxx@comports.com > Strip header: Received, Other > Private list: Yes > Case sensitive: No > Digest support: No > Protection: (SYSTEM:RWED,OWNER:RWED,GROUP,WORLD) > >When the owner sends messages to the list (and the -request address) >those are forwarded to the SYSTEM_USERS list. When I, as a member of the >SYSTEM_USERS list send the messages, all is fine. Any other suggestions? >Is the list name too long? > >TIA, >Rich Hill > >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=- >Rich Hill S I M Rich.Hill@sim.org >Systems Engineer b y EasyLink: 62923838 >SIM USA, Inc. P r a y e r Phone: 1-704-587-1462 >Charlotte, NC since 1893 FAX: 1-704-587-1518 >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- =-=-=-=-=- >[SC] Smiley captioned for the humor impaired. > > > Tom Dolan Dolan@Bible.acu.edu 915.674.3706 202 Bible Building Systems Manager ACU Box 29454 College of Biblical and Family Studies Abilene, TX 79699 Abilene Christian University FAX 915.674.3776 ================================================================================ Archive-Date: Tue, 04 Feb 1997 14:10:14 EST Sender: owner-mx-list@wku.edu Date: Tue, 04 Feb 1997 21:09:46 CET From: Adam Reply-To: MX-List@MadGoat.com To: MX-LIST@WKUVX1.WKU.EDU Message-ID: <009AF668.36B36840.43@dtalk.inf.elte.hu> Subject: A minor forwarding error in MX4.2 (VMS6.2) Hello, There is a minor forwarding error in MX4.2 This error exists in MicroVax 3100 with VMS 6.2 UCX 4.0 (total of 900 users, average 10 interactive, 20 Mailing lists) (dtalk.inf.elte.hu) And VAX6520-VAX9410 cluster with VMS6.2 and UCX 4.0 - MultiNet 4.0 (total of 6000 users, average 110 interactive, ANU NEWS, 30 Mailing lists) (ludens.elte.hu) Problem description: 1, define /ssystem/exec MAIL$INTERNET_TRANSPORT MX (MAIL$TRANSPORT_MX is defined, or not; MAIL$TRANSPORT_SMTP is defined or not) MAIL> m To: user@host.domain works well. MAIL> set forward "MX%""user@host.domain""" works well. MAIL> set forward user@host.domain works, but not well... In this case the local, or decnet mail says: %MAIL-E-USERSPEC, invalid user specification '@host.domain' But the ingoing Internet message is forwarding, but something (I thing the VMSMAIL) inserted an empty line to smtp header :( This empy line prevents forwaarding loop detecting, and prevents understanding MIME attachments, etc. 2., Nor MAIL$INTERNET_TRANSPORT neither MAIL$TRANSPORT_SMTP neither SMTP_MAILSHR are defined in LNM$SYSTEM_TABLE. In sylogin.com there is: define MAIL$INTERNET_TRANSPORT MX or define MAIL$TRANSPORT_SMTP MX_MAILSHR or define SMTP_MAILSHR MX_MAILSHR MAIL> m To: user@host.domain works well. MAIL> set forward "MX%""user@host.domain" works well. MAIL> set forward user@host.domain is betther then the previous, because doesn't work:-) The local or decnet mail says %MAIL-E-USERSPEC, invalid user specification '@host.domain' The ingoing Internet message is not forwarding. (I posted a message from maulis@ludens.elte.hu to maulis@dtalk.elte.hu and maulis@dtalk.inf.elte.hu had a forwarding address: MAULIS@LUDENS.ELTE.HU ) ============================================================================= From: MX%"Postmaster@dtalk.inf.elte.hu" To: MX%"maulis@ludens.elte.hu" CC: Subj: LOCAL delivery error Return-Path: Received: from dtalk.inf.elte.hu by ludens.elte.hu (MX V4.2 VAX) with SMTP; Tue, 04 Feb 1997 20:02:02 +0100 Date: Tue, 04 Feb 1997 20:02:54 CET From: Local delivery agent To: Subject: LOCAL delivery error X-Report-Type: Nondelivery; boundary="> Error description:" Note: this message was generated automatically. An error was detected while processing the enclosed message. A list of the affected recipients follows. This list is in a special format that allows software like LISTSERV to automatically take action on incorrect addresses; you can safely ignore the numeric codes. --> Error description: Error-For: "maulis@ludens.elte.hu"@dtalk.inf.elte.hu Error-Code: 2 Error-Text: Error in delivery to user MAULIS@LUDENS.ELTE.HU %MAIL-E-ERRACTRNS, error activating transport SMTP %LIB-E-ACTIMAGE, error activating image DTALK$DKA200:[SYS0.SYSCOMMON .][SYSLIB]SMTP_MAILSHR.EXE; -RMS-E-FNF, file not found -ECWP-W-NORMAL, normal successful completion Error-End: 1 error detected ------------------------------ Rejected message ------------------------------ Received: from ludens.elte.hu by dtalk.inf.elte.hu (MX V4.2 VAX) with SMTP; Tue, 04 Feb 1997 20:02:54 CET Received: by ludens.elte.hu (MX V4.2 VAX) id 5; Tue, 04 Feb 1997 20:01:59 +0100 Sender: maulis@ludens.elte.hu Date: Tue, 04 Feb 1997 20:01:59 +0100 From: Adam To: MAULIS@DTALK.INF.ELTE.HU Message-ID: <009AF65E.BE55E520.5@ludens.elte.hu> test ============================================================================== Problem description end. I think is not a TCP/IP specific problem. I think that the MX_ROUTER looks the user's forwarding address via MAIL$USER_GET_INFO / MAIL$_USER_FORWARDING / or directly vmsmail_profile.data :-) and interprets it. The second case is better than first case, because if 'anything doesn't work' is better then 'works, bat not well' If you have an solution for my problem, please send a mail this list or me. Thanks Adam Maulis system manager of dtalk.inf.elte.hu and operator of ludens.elte.hu Maulis@dtalk.inf.elte.hu http://dtalk.inf.elte.hu/~maulis/ PS: Sorry for my very wrong English. ------------------------------------------------------- PS2: I think that: MAIL$INTERNET_TRANSPORT has a default value SMTP MAIL$TRANSPORT_'prefix' has a default value 'prefix'_MAILSHR 'prefix'_MAILSHR has a default value (of course) sys$library:'prefix'_mailshr.exe And if you write MAIL> To: user@host.domain the vmsmail is looking MAIL$INTERNET_TRANSPORT for prefix, then vmsmail is looking MAIL$TRANSPORT_'prefix' for 'prefix'_mailshr. Is it true? ================================================================================ Archive-Date: Tue, 04 Feb 1997 20:41:47 EST Sender: owner-mx-list@wku.edu Subject: Re: Reply is broken Message-ID: From: levitte@lp.se (Richard Levitte - VMS Whacker) Reply-To: MX-List@MadGoat.com Date: 05 Feb 1997 02:32:13 GMT To: MX-List@WKUVX1.WKU.EDU In article <5d7fhu$qfk@top.mitre.org> lewis@omega.mitre.org (Keith A. Lewis) writes: Isn't multiple origins on an e-mail message a violation of an RFC or something? Nope. As a matter of fact, RFC 821 explicitelly allows it: authentic = "From" ":" mailbox ; Single author / ( "Sender" ":" mailbox ; Actual submittor "From" ":" 1#mailbox) ; Multiple authors ; or not sender You'll note that in the case of multiple authors, a Sender: field is required. Actually, this is the only way to make it possible to send a reply to both a list and the author of a message to that list. -- R Levitte, Levitte Programming; Spannv. 38, I; S-161 43 Bromma; SWEDEN Tel: +46-8-26 52 47; Cel: +46-10-222 64 05; No fax right now PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65 Check http://www.lp.se/~levitte for my public key. bastard@bofh.se ================================================================================ Archive-Date: Wed, 05 Feb 1997 08:26:53 EST Sender: owner-mx-list@wku.edu Date: Wed, 05 Feb 1997 06:23:35 PST From: system@planacc.com Reply-To: MX-List@MadGoat.com To: MX-LIST@MADGOAT.COM Message-ID: <009AF6B5.94498280.5@planacc.com> Subject: MX /Postmaster Config question Greetings, We are setting up an UUCP email link to our 4 VAX WAN. ALL has went well thanks to the great MX product. My problem is that i am in a conflict with the other 2 computer types over 2 issues. 1. Should all users on the system get an alias so they can be known to the world as something other than their username. Around 100 users. This just seems messy to me but i can ride with it if need be. 2. And the real question! Should we disable the MX mail function of return to sender on No Such User and have all mail (whether to actual username or alias) drop into the postmasters mail box. It seems dumb to me to disable mail bounce and allow anything@company.com to drop into postmasters mail box before return to sender happens. Does this cause a loop or just more work for the postmaster? I need to here from some of you long time postmasters and E-mail systems designers if i am to have enough pull to get this set up properly. Thanks to you all in advance! CT_Land@Planacc.com ================================================================================ Archive-Date: Wed, 05 Feb 1997 09:11:17 EST Sender: owner-mx-list@wku.edu Date: Wed, 05 Feb 1997 10:09:42 EST From: "Charles T. Smith, Jr." Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF6D5.2B3FA7E0.126@dragon.com> Subject: Problem doing backup SMTP One of our downstream sites has a IP connection to our network, but for various and sundry reasons are off time from time to time. What we'd like to do is have MX records similar to the following: IN MX 10 downstream.host IN MX 20 our.host So that if the downstream host is offline, the mail will come to our host, and wait until their host comes back on line and then be delivered by SMTP. When we've tried this, the mail loops over and over to our host...is there any way to do this? ================================================================================ Archive-Date: Wed, 05 Feb 1997 09:25:47 EST Sender: owner-mx-list@wku.edu Date: Wed, 05 Feb 1997 09:25:40 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: SYSTEM@PLANACC.COM Message-ID: <009AF6CF.04591C38.12@ALPHA.WKU.EDU> Subject: RE: MX /Postmaster Config question system@planacc.com writes: > >1. Should all users on the system get an alias so they can be known >to the world as something other than their username. Around 100 users. >This just seems messy to me but i can ride with it if need be. > If you're going to do this, I'd recommend doing it with the ADDRESS_REWRITER example you can find on FTP.WKU.EDU in [.MX.EXAMPLES]. It's pretty efficient at handling lots of aliases (WKU uses it for 1750 aliases). >2. And the real question! Should we disable the MX mail function of >return to sender on No Such User and have all mail (whether to actual username >or alias) drop into the postmasters mail box. It seems dumb to me >to disable mail bounce and allow anything@company.com to drop into postmasters >mail box before return to sender happens. Does this cause a loop or >just more work for the postmaster? > More work for the postmaster, and a delay in letting the sender know that they have a bad address. You can't completely disable the return anyway, but you can have copies sent to the postmaster (MCP SET LOCAL/CC_POSTMASTER). Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Wed, 05 Feb 1997 09:41:06 EST Sender: owner-mx-list@wku.edu Date: Wed, 05 Feb 1997 09:21:16 CST From: Andy Rupf Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF6CE.66B65DA7.189@CCTR.UMKC.EDU> Subject: The Case of the Dieing Local [Names have been changed to protect the parties involved] Members of the Jury: User mail forwarding has taken a sinister turn. With the recent upgrade of our VMS operating system to V7.0 and our continued use of MX V 4.1 there have been numerous incidents of petty larceny on behalf of the "undocumented features" of both the system and MX. In this case though, it turned bloody as local MX delivery processes were ruthlessly gunned down by their cold blooded assailant. After some tense research this morning I believe I have traced the local process assassin to yet another ignorant user. In this case a student (username: *THE-USER*). A search of the copius debugging logs yeilded 19 improper exits of which 18 terminated when delivery was attempted to this username. I believe it was the high traffic on the MX mailing list Assistant that led to the rapid anihilation of our local procs. The trail begins here, in the last MX_LOCAL_LOG.LOG that was recorded upon the death of the final local proc. I have extracted a piece of it to show the unusual section. 5-FEB-1997 00:00:02.88 Checking local name: USER1 5-FEB-1997 00:00:02.99 LOCAL_USER: User USER1 definitely local. 5-FEB-1997 00:00:02.99 This is a regular delivery. 5-FEB-1997 00:00:02.99 Checking local name: *THE-USER* 5-FEB-1997 00:00:03.08 LOCAL_USER: Non-MX fwdg address *THE-USER*@CSTP.UMKC.EDU; treat as local. 5-FEB-1997 00:00:03.08 This is a regular delivery. 5-FEB-1997 00:00:03.08 Checking local name: USER2 5-FEB-1997 00:00:03.28 LOCAL_USER: User USER2 definitely local. 5-FEB-1997 00:00:03.28 This is a regular delivery. I noted that *THE-USER* appeared different from the other checks. On its own this did not even raise suspicion. It was not until I saw the end of the log that I was certain I had found the cause. 5-FEB-1997 00:00:37.14 DELIVER: Delivering to USER4 5-FEB-1997 00:00:37.75 DELIVER: Status=00000001 from MAIL$ routines 5-FEB-1997 00:00:37.81 DELIVER: Delivering to USER1 5-FEB-1997 00:00:39.04 DELIVER: Status=00000001 from MAIL$ routines 5-FEB-1997 00:00:39.33 DELIVER: Delivering to *THE-USER*@CSTP.UMKC.EDU These last few lines, after which the log terminates, indicate to me that the process was unable to make delivery to this user. Otherwise, would it not have continued on to the next user? Sure enough, of the 19 logs that showed an unusual termination, 18 stopped dead on *THE-USER*. By this time I was relatively certain I had found the culprit. My next question was why, and how this user was able to kill 6 local procs in less time than it takes superman to run a 50 yard dash? For this answer I looked in two places. The first was the mail forwards. The second was the large array of unusual temp files stashed at the top of the MX_LOCAL_DIR: At this point we will take the second part first. The .TMP files of the type LCL_EBEA31EB_009AF65C_26806857.TMP;1 turned out to be numerous dumps of mail messages. Most were targeted at the SA's lists like Helpers, or Assistant, or SA. All of which are subscribed to by *THE-USER*. AXP1-$ type LCL_9F37F685_009AF648_26805C56.TMP;1 Date: Mon, 03 Feb 1997 19:00:44 CST From: Problem Reporter To: PROBLEM_REPORT@CCTR.UMKC.EDU Subject: Problem Report - Bloch School (Room 4) Username of staff member : USER3 Time and date of report : 19:00:22 Monday February 1997 Location : Bloch School (Room 4) Machine/part type, number: DOS (PC), 4-37 row #5 Description ___________ DisK error. The forwards showed a common mistake. *THE-USER*'s forward lacked the required internet envelope. *THE-USER* *THE-USER*@CSTP.UMKC.EDU Usually I would think of this as no big deal. The evidence seems, in this case however, to indicate that a simple mistake on the mail forward led to the death and dismemberment of all of our local delivery agents. This brings up the following questions: 1) Does anyone happen to know a way to block access in VMS mail to the ability to set forwards? 2) Is there a patch or update for MX 4.1 that will allow it to survive a hit like this? 3) Is it known whether this is still a problem under MX 4.2? I thank you for your time. Andy Rupf RANDREW@CCTR.UMKC.EDU Programmer/Analyst ----- University of Missouri-Kansas City Life is an uncertified flight mode. ================================================================================ Archive-Date: Wed, 05 Feb 1997 09:58:05 EST Sender: owner-mx-list@wku.edu Date: Wed, 05 Feb 1997 10:57:32 EST From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: cts@dragon.com, hardis@garnet.nist.gov Message-ID: <009AF6DB.DA00D780.21@garnet.nist.gov> Subject: RE: Problem doing backup SMTP > One of our downstream sites has a IP connection to our network, but for > various and sundry reasons are off time from time to time. What we'd > like to do is have MX records similar to the following: > > .... > > When we've tried this, the mail loops over and over to our host...is > there any way to do this? Make sure that the PATH statements on our.host don't identify downstream.host as LOCAL. - Jonathan ================================================================================ Archive-Date: Wed, 05 Feb 1997 13:53:01 EST Sender: owner-mx-list@wku.edu Date: Wed, 05 Feb 1997 13:52:50 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: RANDREW@CCTR.UMKC.EDU Message-ID: <009AF6F4.570877C3.10@ALPHA.WKU.EDU> Subject: RE: The Case of the Dieing Local Andy Rupf writes: > > The forwards showed a common mistake. *THE-USER*'s forward lacked the > required internet envelope. > > *THE-USER* *THE-USER*@CSTP.UMKC.EDU > > Usually I would think of this as no big deal. The evidence seems, in > this case however, to indicate that a simple mistake on the mail forward > led to the death and dismemberment of all of our local delivery agents. > > This brings up the following questions: > > 1) Does anyone happen to know a way to block access in > VMS mail to the ability to set forwards? > Not that I know of. > 2) Is there a patch or update for MX 4.1 that will allow > it to survive a hit like this? > > 3) Is it known whether this is still a problem under MX 4.2? > I had no such trouble under MX V4.2, but that's also under VMS V7.0, which recognizes Internet-style addresses. I'm not sure where the problem really is here. In fact, under VMS V7.0, you apparently *can't* specify a transport anymore---setting a forward using: MAIL> set forward "MX%""user@node""" results in a LIB$TABLE_PARSE error under V7.0. And omitting the "MX%" causes two sets of headers to be created as the message is forwarded back through MX. I don't remember what the release notes said about SET FORWARD, but there's clearly some weird stuff going on here. In any case, I would recommend you upgrade to MX V4.2 because it does fix problems that caused the agents to die in other places. Someday when I have some time (yeah, sure), I'll look into this more. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Wed, 05 Feb 1997 14:41:34 EST Sender: owner-mx-list@wku.edu From: dwing@cisco.com (Dan Wing) Subject: RE: The Case of the Dieing Local Date: 5 Feb 1997 20:22:32 GMT Message-ID: <5daq68$jja@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <009AF6F4.570877C3.10@ALPHA.WKU.EDU>, Hunter Goatley writes: >I had no such trouble under MX V4.2, but that's also under VMS V7.0, >which recognizes Internet-style addresses. I'm not sure where the >problem really is here. In fact, under VMS V7.0, you apparently >*can't* specify a transport anymore---setting a forward using: > > MAIL> set forward "MX%""user@node""" > >results in a LIB$TABLE_PARSE error under V7.0. And omitting the "MX%" >causes two sets of headers to be created as the message is forwarded >back through MX. MAIL> SET FORWARD MX%"user@node" works fine (drop the DCL-style mess of ugly quotes). -Dan Wing dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Wed, 05 Feb 1997 16:04:59 EST Sender: owner-mx-list@wku.edu Date: Wed, 05 Feb 1997 16:03:05 CST From: Ron Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF706.8905DD05.672@CCTR.UMKC.EDU> Subject: RE: The Case of the Dieing Local =-> =-> MAIL> SET FORWARD MX%"user@node" =-> =->works fine (drop the DCL-style mess of ugly quotes). =-> =->-Dan Wing =-> dwing@cisco.com =-> cisco Systems, Inc. thanks Dan, good to know. Ron Rockwell - CCTR/Systems Programmer rrockwell@umkc.edu University of Missouri at Kansas City ================================================================================ Archive-Date: Wed, 05 Feb 1997 17:28:57 EST Sender: owner-mx-list@wku.edu Date: Wed, 05 Feb 1997 18:27:15 EST From: "Charles T. Smith, Jr." Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF71A.ACFE5340.99@dragon.com> Subject: RE: Problem doing backup SMTP > Make sure that the PATH statements on our.host don't identify > downstream.host as LOCAL. It's not; the system attempts to deliver, over and over, accepting smtp to itself. ================================================================================ Archive-Date: Wed, 05 Feb 1997 22:27:44 EST Sender: owner-mx-list@wku.edu Date: Wed, 05 Feb 1997 23:27:26 EST From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: cts@dragon.com, hardis@garnet.nist.gov Message-ID: <009AF744.9C475B80.4@garnet.nist.gov> Subject: RE: Problem doing backup SMTP >> Make sure that the PATH statements on our.host don't identify >> downstream.host as LOCAL. > It's not; the system attempts to deliver, over and over, > accepting smtp to itself. My mistake -- I should have thought about this a bit more. You need: DEFINE PATH "downstream.host" SMTP/ROUTE="downstream.host" I think this will force the "A" record to be used (rather than the MX record). However, it this isn't the case, don't use DNS at all: DEFINE PATH "downstream.host" SMTP/ROUTE="[123.45.67.89]" Alternatively, DEFINE PATH "downstream.host" SMTP/ROUTE="private-name.host" Where private-name.host has the same IP number as downstream.host, but without the additional MX record baggage. Please note that I've tried none of these, and your results may vary. - Jonathan ================================================================================ Archive-Date: Thu, 06 Feb 1997 11:20:49 EST Sender: owner-mx-list@wku.edu From: dwing@cisco.com (Dan Wing) Subject: RE: Problem doing backup SMTP Date: 6 Feb 1997 00:00:24 GMT Message-ID: <5db6uo$agf@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <009AF71A.ACFE5340.99@dragon.com>, "Charles T. Smith, Jr." writes: >> Make sure that the PATH statements on our.host don't identify >> downstream.host as LOCAL. > >It's not; the system attempts to deliver, over and over, accepting >smtp to itself. Post the output from SHOW PATH and the names of the hosts (remote and local), as well as output from NSLOOKUP to your local nameserver, and someone will have a chance of finding the configuration problem. I used to use a configuration similar to yours almost three years ago and it worked. -Dan Wing dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Fri, 07 Feb 1997 11:03:45 EST Sender: owner-mx-list@wku.edu Date: Fri, 07 Feb 1997 11:03:13 CST From: Gary Lee McDonald Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF86E.F9F162AA.368@CCTR.UMKC.EDU> Subject: SMTP server error...? Date sent: 7-FEB-1997 10:57:25 Greetings, Our normal MX maintainer is off today. I noticed that the smtp_server wasn't running so I tried to start it the normal way, but got the following error in the log file ========== 7-FEB-1997 10:49:45.25: MX SMTP Server (pid 26815980) starting 7-FEB-1997 10:49:45.87: MX SMTP Server (pid 26815980) exiting, status = 100000A4 ========= $ wr sys$output f$mess(%x100000a4) %SYSTEM-F-FILALRACC, file already accessed on channel I then did an mcp shutdown and then @sys$startup:mx_startup, but got same error. If someone could point me in right direction, it would be *greatly* appreciated! UMKC GaryM. 5100 Rockhill Road Univ. of Mo. at K.C. Cockefair Hall (816) 235-1183 (work) 346-3447 (pager) Room 2, Gary Lee McDonald MCDONALD @ CCTR.UMKC.EDU Kansas City, Mo. 64110 POSTMASTER @ CCTR.UMKC.EDU ================================================================================ Archive-Date: Fri, 07 Feb 1997 11:52:46 EST Sender: owner-mx-list@wku.edu From: Ted Spencer PhD Reply-To: MX-List@MadGoat.com Content-Type: text/plain To: MX-List@MadGoat.com Subject: MX Versions MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Fri, 07 Feb 1997 11:52:40 EST Hi. We are new to this list; I noticed a question about version numbers, but I missed the answer somehow. What is the latest release of MX? We obtained version 4.1 for VMS and have it installed and running. If version 4.2 (which I have seen mentioned here) is out, what are its new features? Forgive me if I missed the answer recently, but I have been monitoring for about 2 weeks now. __________________________________________________ Ted Spencer, PhD tspencer@scassn.org Publications Manager & Webmaster 703-750-0533 Speech Communication Assn fax 703-914-9471 http://www.scassn.org ================================================================================ Archive-Date: Fri, 07 Feb 1997 12:32:16 EST Sender: owner-mx-list@wku.edu Date: Fri, 7 Feb 1997 12:31:57 -0600 (CST) From: Gary Lee McDonald Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: MCDONALD@POP.UMKC.EDU Message-ID: <970207123157.212192b8@POP.UMKC.EDU> Subject: Smtp server problem Date sent: 7-FEB-1997 11:59:47 Greetings, I tried sending this earlier but it was from the node that's havine the problem, so I'm sending this from my workstation that uses Multinet's smtp... I noticed this morning the on node CCTR (which runs MX) that the smtp server was missing. I tried to start it using @mx_root:[alpha_exe]mx_start smtp_server and got the following in the log: ========== 7-FEB-1997 11:50:42.12: MX SMTP Server (pid 2681899C) starting 7-FEB-1997 11:50:42.73: MX SMTP Server (pid 2681899C) exiting, status = 100000A4 ============ Did the following: $ wr sys$output f$mess(%x100000a4) %SYSTEM-F-FILALRACC, file already accessed on channel Then tried $ mcp shutdown and @sys$startup:mx_startup, but got same results. Regular maintainer is off today, so I'd appreciate pointers. Just upgraded to OpenVMS v.7.0 and running MX version id is: MX V4.1 AXP. Thanks! UMKC GaryM. 5100 Rockhill Road Univ. of Mo. at K.C. Cockefair Hall (816) 235-1183 (work) 346-3447 (pager) Room 2, Gary Lee McDonald MCDONALD @ ATLAS.UMKC.EDU Kansas City, Mo. 64110 POSTMASTER @ ATLAS.UMKC.EDU ================================================================================ Archive-Date: Fri, 07 Feb 1997 12:43:25 EST Sender: owner-mx-list@wku.edu Date: Fri, 07 Feb 1997 12:43:15 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF87C.F382BD69.24@ALPHA.WKU.EDU> Subject: RE: MX Versions Ted Spencer PhD writes: > >If version 4.2 (which I have seen mentioned here) is out, what are its new >features? > V4.2 has been out for over a year. You can find the release notes via the WWW using: http://www2.wku.edu/www/madgoat/mx/MX042.RELEASE_NOTES General MX information can be found via: http://www2.wku.edu/www/madgoat/mx.html Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Fri, 07 Feb 1997 12:49:48 EST Sender: owner-mx-list@wku.edu Date: Fri, 07 Feb 1997 12:49:41 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF87D.D94CCB87.12@ALPHA.WKU.EDU> Subject: RE: SMTP server error...? Gary Lee McDonald writes: > >Date sent: 7-FEB-1997 10:57:25 > >Greetings, > > Our normal MX maintainer is off today. I noticed that the smtp_server wasn't >running so I tried to start it the normal way, but got the following error in >the log file >========== > 7-FEB-1997 10:49:45.25: MX SMTP Server (pid 26815980) starting > 7-FEB-1997 10:49:45.87: MX SMTP Server (pid 26815980) exiting, > status = 100000A4 >========= > >$ wr sys$output f$mess(%x100000a4) >%SYSTEM-F-FILALRACC, file already accessed on channel > I think that means there's already some process listening on the SMTP channel. You didn't say what TCP/IP package you had, but NETCU SHOW CONNECTIONS (TCPware) or MULTINET SHOW/CONNECTIONS (Multinet) should show if there's another process listening on the SMTP port (25). "Duplicate name" can also be returned in that case. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Fri, 07 Feb 1997 13:28:44 EST Sender: owner-mx-list@wku.edu Date: Fri, 7 Feb 1997 13:28:34 -0600 (CST) From: Gary Lee McDonald Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: MCDONALD@POP.UMKC.EDU Message-ID: <970207132834.212192b8@POP.UMKC.EDU> Subject: RE: SMTP server error...? >Gary Lee McDonald writes: >> >>Date sent: 7-FEB-1997 10:57:25 >> >>Greetings, >> >> Our normal MX maintainer is off today. I noticed that the smtp_server wasn't >>running so I tried to start it the normal way, but got the following error in >>the log file >>========== >> 7-FEB-1997 10:49:45.25: MX SMTP Server (pid 26815980) starting >> 7-FEB-1997 10:49:45.87: MX SMTP Server (pid 26815980) exiting, >> status = 100000A4 >>========= >> >>$ wr sys$output f$mess(%x100000a4) >>%SYSTEM-F-FILALRACC, file already accessed on channel >> >I think that means there's already some process listening on the SMTP >channel. You didn't say what TCP/IP package you had, but NETCU SHOW >CONNECTIONS (TCPware) or MULTINET SHOW/CONNECTIONS (Multinet) should >show if there's another process listening on the SMTP port (25). Thanks, Hunter! Mu sh/conn gives the following: ======= MultiNet Active Connections: Proto Rcv-Q Snd-Q Local Address (Port) Foreign Address (Port) State ----- ----- ----- -------------------------------------------- TCP 0 56 AXP1.UMKC.EDU(SMTP) 199.191.130.38(33357) CLOSING ========= Using /conn=pid gives as pid. What reasons would cause it to stay in closing state? > >"Duplicate name" can also be returned in that case. > >Hunter >------ >Hunter Goatley, Process Software Corporation (TCPware) > http://www.wku.edu/www/madgoat/hunter.html > UMKC GaryM. 5100 Rockhill Road Univ. of Mo. at K.C. Cockefair Hall (816) 235-1183 (work) 346-3447 (pager) Room 2, Gary Lee McDonald MCDONALD @ ATLAS.UMKC.EDU Kansas City, Mo. 64110 POSTMASTER @ ATLAS.UMKC.EDU ================================================================================ Archive-Date: Fri, 07 Feb 1997 13:54:59 EST Sender: owner-mx-list@wku.edu Date: Fri, 07 Feb 1997 13:51:42 EST5EDT4,M4.1.0,M10.5.0 From: Scott McNeilly Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF886.83886060.60@fred.bridgew.edu> Subject: RE: MX Versions >From: Ted Spencer PhD > >Hi. We are new to this list; I noticed a question about version numbers, but >I missed the answer somehow. What is the latest release of MX? We obtained >version 4.1 for VMS and have it installed and running. > The latest release is 4.2. >If version 4.2 (which I have seen mentioned here) is out, what are its new >features? You can find out all about the new features in the Release Notes at: http://www.wku.edu/www/madgoat/mx/mx_DOCS.HTML -------------------------------------------------------------------- Scott Mc Neilly email: smcneilly@bridgew.edu Assistant Director Phone: 508-697-1236 Information Services FAX: 508-697-1774 Bridgewater State College Bridgewater, MA 02325 --------------------------------------------------------------------- ================================================================================ Archive-Date: Sat, 08 Feb 1997 13:49:42 EST Sender: owner-mx-list@wku.edu Date: Sat, 08 Feb 1997 14:47:51 EST From: "Charles T. Smith, Jr." Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AF957.85F2E4C0.40@dragon.com> Subject: PATH LOCAL or rewrite rule? We have a number of domains that we serve that route to our machine (eg, the MX record points to our machine). To date, we've served most of these via an address rewrite, such that the address is rewritten to our host. Would it be cleaner to do this via setting each of these domains as a local path? Does anyone see any advantages (performance, etc) either way? ================================================================================ Archive-Date: Sat, 08 Feb 1997 17:39:44 EST Sender: owner-mx-list@wku.edu Date: Sat, 08 Feb 1997 17:39:35 CST From: Ron Reply-To: MX-List@MadGoat.com To: MX-LIST@MADGOAT.COM Message-ID: <009AF96F.838844CE.17@CCTR.UMKC.EDU> Subject: Caching and split roots Hunter, All, Curious about running MX on two clustered nodes, but specifying two separate MX_ROOT logicals. i.e. on one AXP1, MX_ROOT pointing to DISKA:[MX_MAIL.A] and on AXP2 MX_ROOT pointing to DISKA:[MX_MAIL.B] i notice that at about 4800 max messages in the queue i get the following sizes for queue directorys: 0.DIR;1 85/108 1.DIR;1 75/108 2.DIR;1 75/164 <---- oops how did that happen? 3.DIR;1 86/108 4.DIR;1 79/108 5.DIR;1 83/108 6.DIR;1 84/108 7.DIR;1 76/108 8.DIR;1 87/108 9.DIR;1 86/108 we see a lot of contention running both nodes over the same queue. i am wondering whether running two queues on the two machines would allow twice the size while still keeping our directorys under the cache limit. Would this necessarily baffle MX's queue handling or delivery procedures? Ron Rockwell - CCTR/Systems Programmer rrockwell@umkc.edu University of Missouri at Kansas City ================================================================================ Archive-Date: Sun, 09 Feb 1997 00:57:37 EST Sender: owner-mx-list@wku.edu Subject: Re: PATH LOCAL or rewrite rule? Message-ID: From: levitte@lp.se (Richard Levitte - VMS Whacker) Reply-To: MX-List@MadGoat.com Date: 08 Feb 1997 20:47:21 GMT To: MX-List@WKUVX1.WKU.EDU In article <009AF957.85F2E4C0.40@dragon.com> "Charles T. Smith, Jr." writes: We have a number of domains that we serve that route to our machine (eg, the MX record points to our machine). To date, we've served most of these via an address rewrite, such that the address is rewritten to our host. First of all, I find it simpler to use PATH LOCAL for such things. I reserve rewrites for the cases where the username part needs to be rewritten. -- R Levitte, Levitte Programming; Spannv. 38, I; S-161 43 Bromma; SWEDEN Tel: +46-8-26 52 47; Cel: +46-10-222 64 05; No fax right now PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65 Check http://www.lp.se/~levitte for my public key. bastard@bofh.se ================================================================================ Archive-Date: Mon, 10 Feb 1997 08:55:55 EST Sender: owner-mx-list@wku.edu Date: Mon, 10 Feb 1997 09:29:17 EST From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: rrockwell@umkc.edu Message-ID: <009AFABD.59A52880.20@swdev.si.com> Subject: RE: Caching and split roots Ron Rockwell (rrockwell@umkc.edu) writes: >2.DIR;1 75/164 <---- oops how did that happen? This is still under the cache size, since it is the Used size (not the Allocated size) that affects the cache. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman_brian@si.com Smiths Industries, Inc. | tillman@swdev.si.com 4141 Eastern Ave., MS239 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Mon, 10 Feb 1997 21:23:30 EST Sender: owner-mx-list@wku.edu Date: Mon, 10 Feb 1997 21:23:25 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: RROCKWELL@CCTR.UMKC.EDU Message-ID: <009AFB21.1D71371F.22@ALPHA.WKU.EDU> Subject: RE: Caching and split roots Ron writes: > > we see a lot of contention running both nodes over the same queue. > > i am wondering whether running two queues on the two machines would allow >twice the size while still keeping our directorys under the cache limit. >Would this necessarily baffle MX's queue handling or delivery procedures? > They will not be able to function as a single MX cluster, if you do this, but otherwise, yes, you could do this and it might help. Or not. A lot of it depends on what else the systems and disk are doing, etc. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Tue, 11 Feb 1997 17:06:44 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: Re: MX Local dying Date: 11 Feb 97 10:41:06 -0500 Message-ID: <1997Feb11.104106.1@aspen> To: MX-List@WKUVX1.WKU.EDU We have been following the saga of the dying MX local for some time, because we are badly affected too. Now, I have come upon something, which I dare to post out of "intelligent ignorance". It may be very right, or very wrong. For reasons other than the "dying" problem, I decided to look at MAILUAF_PROFILE.DATA, using what is probably an old version of a somewhat popular tool, MAILUAF.COM . When using its command LIST, in order to see forwarding addresses, it processed about 100 names, and then aborted with "illegal item code 14 found in record". Could it be that this contamination of MAILUAF-PROFILE.DATA is causing the problem? I note by SHOW DEV/FILE that the above file is in use both by individual users (no trouble ever noticed) and by various processes known to MCP STAT . And, while I have your attention, how do I fix the contamination? It is aggravating that, for starters, the file is locked, so I cannot even make a copy of it to practice on. Plus, I am terrible on RMS, but am willing to do binary editting, or do a rewrite of MAILUAF.COM to catch and fix the bad record. Another thing which I though might help is a template which Hein posted for cleaning up SYSUAF.DAT . Since the files are perhaps similar, would that approach work (it uses CONVERT)? -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Tue, 11 Feb 1997 17:46:10 EST Sender: owner-mx-list@wku.edu Date: Tue, 11 Feb 1997 17:46:03 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AFBCB.E9D45569.2@ALPHA.WKU.EDU> Subject: Re: MX Local dying welchb@woods.uml.edu (Brendan Welch, W1LPG) writes: > > For reasons other than the "dying" problem, I decided to look >at MAILUAF_PROFILE.DATA, using what is probably an old version of a >somewhat popular tool, MAILUAF.COM . When using its command LIST, in >order to see forwarding addresses, it processed about 100 names, and >then aborted with "illegal item code 14 found in record". > > Could it be that this contamination of MAILUAF-PROFILE.DATA >is causing the problem? Yes, it's possible, if the callable MAIL routines don't handle it correctly. I have seen this before---a corrupted record causes the callable MAIL routines to generate an access violation. > And, while I have your attention, how do I fix the contamination? You should be able to just: $ open/share/write tmp sys$system:vmsmail_profile.data $ read/key="username"/delete tmp line where "username" is the username of the offending record. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Wed, 12 Feb 1997 04:54:28 EST Sender: owner-mx-list@wku.edu Date: Wed, 12 Feb 1997 10:53:06 GMT From: Andy Harper - KCL Systems manager Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: A.HARPER@kcl.ac.uk Message-ID: <009AFC5B.644BD000.2087@alder.cc.kcl.ac.uk> Subject: Re: MX Local dying >> Could it be that this contamination of MAILUAF-PROFILE.DATA >>is causing the problem? > >Yes, it's possible, if the callable MAIL routines don't handle it >correctly. I have seen this before---a corrupted record causes the >callable MAIL routines to generate an access violation. Can the access violation be avoided by use of a MAIL$_NOSIGNAL flag in the corresponding callable mail routine within MX LOCAL? This is supposed to tell callable MAIL to not signal an error but just return the status code. However an ACCVIO may abort it anyway. On a related note, there are a number of interesting bugs in callable mail I discovered while developing an interface for PINE on VMS. Here's just a couple of the interesting ones: 1. Despite what the manual says, you CAN create an empty mail folder (by exploiting a callable mail bug that I won't reveal; but I have reported it to Digital). You can detect one by going into VMS MAIL and saying SELECT folder If it says: 'selected 0 messages' rather: 'no such folder' Then it's corrupted. This may or may not cause later problems with VMS MAIL or MX LOCAL. You can NOT delete this empty folder except by copying all messages to a new mail file and then deleting the original. 2. Again, despite what the manual says of about a maximum record length of 256, longer records can be delivered into the mail file. VMS MAIL will crash when it tried to read the record (as will MX LOCAL I expect). I had a message with a single record of over 4000 bytes recently and all attempts to read it successfulyl with callabale mail failed (it will NOT let you specify a buffer bigger than 256). All of these are under either VMS 5.5-2, VMS 6.1 or VMS 6.2. I can't speak for VMS 7.x or greater. Andy Harper Kings College London ================================================================================ Archive-Date: Wed, 12 Feb 1997 07:02:45 EST Sender: owner-mx-list@wku.edu Date: Wed, 12 Feb 1997 07:02:40 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AFC3B.32F7BDBD.5@ALPHA.WKU.EDU> Subject: Re: MX Local dying Andy Harper - KCL Systems manager writes: > > Can the access violation be avoided by use of a MAIL$_NOSIGNAL flag in the > corresponding callable mail routine within MX LOCAL? This is supposed to > tell callable MAIL to not signal an error but just return the status code. > However an ACCVIO may abort it anyway. > Yes, it aborts anyway. MX uses MAIL$_NOSIGNAL when it calls the routines. > 2. Again, despite what the manual says of about a maximum record length of > 256, longer records can be delivered into the mail file. VMS MAIL will > crash when it tried to read the record (as will MX LOCAL I expect). I > had a message with a single record of over 4000 bytes recently and all > attempts to read it successfulyl with callabale mail failed (it will > NOT let you specify a buffer bigger than 256). > What's interesting about this is that the callable MAIL routines will read in records longer than 255 characters, but: a) won't return it if the first record is longer than 255 b) won't return any other lines longer than that, even though it has already read them into its own in-memory copy There is a way to reach those longer records---the MAIL source listings show you how. But if the first record is longer than 255, there's still no way to retrieve it via callable MAIL. (Actually, that limit varies depending on the version of VMS---some will read up to 510 bytes). Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Wed, 12 Feb 1997 09:22:31 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: Re: MX Local dying Date: 12 Feb 97 10:01:03 -0500 Message-ID: <1997Feb12.100103.1@aspen> To: MX-List@WKUVX1.WKU.EDU >> And, while I have your attention, how do I fix the contamination? > > You should be able to just: > > $ open/share/write tmp sys$system:vmsmail_profile.data > $ read/key="username"/delete tmp line > > where "username" is the username of the offending record. > But I am having difficulty finding the offender's name. The MAILUAF>LIST gave the name of the last good user; so I messed around with SET VER, and got what I thought was the next person. (Part of the problem, I suspect, is that because of ages of "dead wood", there may be some names in SYSUAF which are not in the mail profile, and vice versa.) I used BECOME to become each of those users. Except for what is unfortunately a quite commonly found inattention to mail cleanup, both of those users are within their quota, their mail is working, and their accounts seem ok. Being your staunch defender of user rights (= a chicken of an administrator) I did not want to delete anything. And that scared feeling arises again when I see that magic word "/delete" in your advice above. Because I do not know what RMS is doing, I fear I might delete a whole passel of things instead of just an offending record. -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Wed, 12 Feb 1997 10:13:42 EST Sender: owner-mx-list@wku.edu Date: Wed, 12 Feb 1997 10:13:37 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AFC55.DFD6214C.13@ALPHA.WKU.EDU> Subject: Re: MX Local dying welchb@woods.uml.edu (Brendan Welch, W1LPG) writes: > >Being your staunch defender of user rights (= a chicken of an administrator) >I did not want to delete anything. And that scared feeling arises again >when I see that magic word "/delete" in your advice above. Because I >do not know what RMS is doing, I fear I might delete a whole passel of >things instead of just an offending record. That command will cause RMS to delete the record that matches the specified key. That's all. That does mean, of course, that all mail information for that user will be lost, as each record in the VMSMAIL_PROFILE.DATA contains the mail profile info for a user. And yes, it's quite likely that there's a lot of deadwood in the file, so it may not be a current user record that's causing the problem. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Wed, 12 Feb 1997 10:32:10 EST Sender: owner-mx-list@wku.edu Date: Wed, 12 Feb 1997 11:16 EST From: DEL@intranet.com (G. Del Merritt) Reply-To: MX-List@MadGoat.com Message-ID: <009AFC5EAA7BD412.1CC4@intranet.com> To: MX-List@madgoat.com Subject: Re: MX Local dying In-reply-to: "Hunter Goatley "'s message of 12-FEB-1997 07:59:28.16 >What's interesting about this is that the callable MAIL routines will >read in records longer than 255 characters, but: > > a) won't return it if the first record is longer than 255 > b) won't return any other lines longer than that, even though it > has already read them into its own in-memory copy > >There is a way to reach those longer records---the MAIL source >listings show you how. But if the first record is longer than 255, >there's still no way to retrieve it via callable MAIL. (Actually, >that limit varies depending on the version of VMS---some will read up >to 510 bytes). Hmm. So VMS MAIL doesn't use the callable MAIL interface for /FOREIGN processing, I take it. Interesting. -- Del Merritt del@IntraNet.com IntraNet, Inc., One Gateway Center #700, Newton, MA 02158 Voice: 617-527-7020; FAX: 617-527-1761 Just say no to Clipper. You may not add me to a commercial mailing list or send me commercial advertising without my consent. NERD PRIDE is a registered trademark of the MIT ================================================================================ Archive-Date: Wed, 12 Feb 1997 10:41:07 EST Sender: owner-mx-list@wku.edu Date: Wed, 12 Feb 1997 17:10:40 +0100 From: Alberto Meregalli (DIF) Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: meregalli@cesi.it Message-ID: <009AFC90.22DF49F0.17@cesi.it> Subject: Re: MX Local dying >But I am having difficulty finding the offender's name. >The MAILUAF>LIST gave the name of the last good user; so I messed around with >SET VER, and got what I thought was the next person. >(Part of the problem, I suspect, is that because of ages of "dead wood", >there may be some names in SYSUAF which are not in the mail profile, >and vice versa.) ... >-- >Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu > You only need this procedure to read all the vmsmail_profile.data users: $ OPEN /READ /SHARE=WRITE ml sys$system:vmsmail_profile.data $loop: $ READ /END=fine ml riga $ user = f$extract (0, 12, riga) $ WRITE sys$output user $ GOTO loop $ $fine: $ CLOSE ml and you only need the mail command MAIL> REMOVE user to remove a user entry from it. --------------------------------------------------------------------------- Alberto Meregalli, DIF tel. +39 2 2125 249 CESI, Centro Elettrotecnico Sperimentale Italiano fax +39 2 2125 520 Via Rubattino, 54 - I 20134 Milano E-mail: meregalli@cesi.it ================================================================================ Archive-Date: Wed, 12 Feb 1997 11:29:15 EST Sender: owner-mx-list@wku.edu Date: Wed, 12 Feb 1997 12:28:56 EST From: Scott McNeilly Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AFC68.C790E080.8@fred.bridgew.edu> Subject: Re: MX Local dying >From: welchb@woods.uml.edu (Brendan Welch, W1LPG) ... > For reasons other than the "dying" problem, I decided to look >at MAILUAF_PROFILE.DATA, using what is probably an old version of a >somewhat popular tool, MAILUAF.COM . When using its command LIST, in >order to see forwarding addresses, it processed about 100 names, and >then aborted with "illegal item code 14 found in record". MAILUAF.DAT was used with old versions (4.7) of VMS. What version are you running? With VMS 5.5 and later, the file is VMSMAIL_PROFILE.DATA. Is that what you mean? > And, while I have your attention, how do I fix the contamination? >It is aggravating that, for starters, the file is locked, so I cannot >even make a copy of it to practice on. Plus, I am terrible on RMS, but >am willing to do binary editting, or do a rewrite of MAILUAF.COM to >catch and fix the bad record. You can make a copy using this command: BACKUP /IGNORE=INTERLOCK VMSMAIL_PROFILE.DAT VMSMAIL_PROFILE.TEST I don't know how to "fix" the contamination, but if you can identify the record that is contaminated, you could delete it and create a new one. -------------------------------------------------------------------- Scott Mc Neilly email: smcneilly@bridgew.edu Assistant Director Phone: 508-697-1236 Information Services FAX: 508-697-1774 Bridgewater State College Bridgewater, MA 02325 --------------------------------------------------------------------- ================================================================================ Archive-Date: Thu, 13 Feb 1997 07:52:16 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: Re: MX local dying Date: 13 Feb 97 08:44:45 -0500 Message-ID: <1997Feb13.084445.1@willow> To: MX-List@WKUVX1.WKU.EDU I hereby combine a followup to postings by Hunter Goatley, Scott McNeilly, and Alberto Meregalli, since they all have related aspects. And, most of you probably do not want to bother reading any of this; but it just might be helpful. Our version of MAILUAF.COM does indeed deal with VMSMAIL_PROFILE.DATA; we happen to have it moved off of the system disk, but it is correctly pointed to by the logical VMSMAIL_PROFILE. I am embarrassed to say I had forgotten about using BACKUP to copy a busy file; that procedure is right there in what Hein had posted for SYSUAF. But, after making a copy, I was unsuccessful in doing with it what I wanted to (due to my own ignorance). As Hunter says, using "/delete" will possibly ruin only that one user. Thus, I have to go through a lengthy, interactive-by-hand procedure of capturing all of that user's settings and unread-mail-count, before I remove him and then add him back. Alberto points out a way to read the entire file. Indeed I did the equivalent of this by modifying MAILUAF.COM, and saving the output, for 2 reasons. This gives a complete list of those in MAILUAF, for later comparison with SYSUAF; but more immediately it helps me find the bad usernames when MAILUAF.COM (unmodified) hangs up with an error 14; I have to look at the name just before the hangup, and realize that the next name on this list is the bad one (; that bad name can still successfully be using mail, even simultaneous with my working on his file). I am in the midst of doing this, but I keep uncovering more bad ones; I have alphabetically reached the "C's" in a few hours, and we have 8000 users. You will be surprised at my belief that I am doing this more efficiently by hand than if I automated it. And here locally we have a 3rd purpose in this, pertaining to our previous use of DecMailWorks, which required each user to set forwarding to an MRGATE address; I am finding some relics of these. In summary, what you readers might most want to get out of all this is: With few exceptions, the list of mail users in VMSMAIL_PROFILE should agree with SYSUAF.DAT. You all realize that new users should be added to both correctly because you would immediately hear complaints if they were not. But it is possible that great attention should be made to the correct and timely deletion of users from both places, when users leave or expire. (Hmmm, how about DISUSERed customers?) -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Thu, 13 Feb 1997 10:38:12 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: Re: MX local dying Date: 13 Feb 97 11:28:20 -0500 Message-ID: <1997Feb13.112820.1@aspen> To: MX-List@WKUVX1.WKU.EDU As a followup to my own posting: I now find many crazy things going on. The worst of these is that after I successfully fixed the records of some users early in the alphabet, and am busy finding and fixing later users, those early one come up bad again. I have documented evidence of several occurrences of the above. There are other little things going on, such as 1)mail error messages that eventually go away, 2)REMOVEing a user only to find he is still there, 3)doing a LIST but getting strange but non-fatal error messages (bad command on line), 4) doing a LIST with ctrl-o (to quickly get further down the list) only to find the screen displaying again, as if I had pressed ctrl-o again myself. So, now part of my question are these: If I use REMOVE, does this take effect out in the real world; could there be some caching going on, or some difference between a permanent setting and a temporary one? Can some bad effect be caused by a user (whose account I think I have fixed, and have sent mail to and from him) actually logging in again? or because he changes some mail settings? -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Thu, 13 Feb 1997 11:38:18 EST Sender: owner-mx-list@wku.edu From: dwing@cisco.com (Dan Wing) Subject: Re: Mail Header Too Large Date: 13 Feb 1997 17:21:07 GMT Message-ID: <5dvii3$qk0@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <5dt13i$f9p@hobbes.cc.uga.edu>, lebo@bscr.uga.edu (Richard Lebo) writes: > Once again I'm having the problem where incoming mail messages with >headers that are too large are causing the SMTP_SERVER process to crash. I'm >not having much luck getting the sender to cease and desist, so, is there >anyway to tell MX to reject mail from a particular host? Hopefully this >rejection would take place prior to the SMTP_SERVER process getting its hands >on the mail. Create a black-hole route to that host using the IP software on your VMS machine, or block SMTP traffic from that host at your router. -Dan Wing dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Thu, 13 Feb 1997 11:59:24 EST Sender: owner-mx-list@wku.edu Date: Thu, 13 Feb 1997 11:59:15 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: LEBO@BSCR.UGA.EDU Message-ID: <009AFD2D.CC5A7115.10@ALPHA.WKU.EDU> Subject: Re: Mail Header Too Large dwing@cisco.com (Dan Wing) writes: > >In article <5dt13i$f9p@hobbes.cc.uga.edu>, lebo@bscr.uga.edu (Richard Lebo) writes: >> Once again I'm having the problem where incoming mail messages with >>headers that are too large are causing the SMTP_SERVER process to crash. I'm >>not having much luck getting the sender to cease and desist, so, is there >>anyway to tell MX to reject mail from a particular host? Hopefully this >>rejection would take place prior to the SMTP_SERVER process getting its hands >>on the mail. > >Create a black-hole route to that host using the IP software on your >VMS machine, or block SMTP traffic from that host at your router. > Or install the new SMTP_SERVER image you can find on ftp.madgoat.com in [.MX.MX042.PATCHES]. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Fri, 14 Feb 1997 10:28:28 EST Sender: owner-mx-list@wku.edu Date: Fri, 14 Feb 1997 10:28:19 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@LISTS.WKU.EDU Message-ID: <009AFDEA.4254E8C4.22@ALPHA.WKU.EDU> Subject: New MX_LOCAL patch available These things always seem to come in groups. Lately, there have been several sites reporting that their MX Local process was dying with an access violation when sending to users with a bad forwarding address. This morning, I was able to duplicate the problem and fix it. There was a bug in the condition handler MX Local establishes to catch mail delivery problems. The nature of the bug was such that it worked for most errors, but didn't for some (most notably, LIB$_SYNTAX_ERR, an error from LIB$TPARSE while parsing an address). This bug has now been corrected (for all error conditions). You can find a new patched version of MX_LOCAL for both VAX and Alpha via anonymous FTP from FTP.MADGOAT.COM (or FTP.WKU.EDU) in [.MX.MX042.PATCH]. This patch should work under MX V4.1, too, but I haven't tested that. ftp://ftp.madgoat.com/mx/mx042/patch/mx_local.exe ftp://ftp.madgoat.com/mx/mx042/patch/mx_local.alpha_exe Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Fri, 14 Feb 1997 12:12:23 EST Sender: owner-mx-list@wku.edu Date: Fri, 14 Feb 1997 11:11:49 MST -0700 From: Allen Porter Reply-To: MX-List@MadGoat.com To: MX-List@LISTS.WKU.EDU Message-ID: <009AFDF0.569CF669.8@msu.oscs.montana.edu> Subject: Messages to owner-listname We have a list defined like this: Name: BUS31104 Owner: "ibmst@MONTANA.EDU" Reply-to: NOList, Sender Add message: MSU_ADD_POST_MESSAGE Remove message: MSU_REMOVE_MESSAGE Description: Information Systems (Section 04) Errors-to: ahporter@MONTANA.EDU Strip header: NOReceived, NOOther Private list: Yes Case sensitive: No Digest support: No Protection: (SYSTEM:RWED,OWNER:RWED,GROUP:RWD,WORLD:E) When users send a message to owner-bus31104, the message is forwarded by MX to the Errors-to address and not the Owner. This is not our intent; we do want the errors to go as specified, but it seems that messages to owner-listname should go to the owner. A quick look at the source shows that indeed FORWARD_TO_LIST_OWNER uses the Errors-to address. We suspect that this behavior is probably not correct; at least it certainly violates the rule of least astonishment. Comments? Fixes? Allen H Porter ahporter@montana.edu Information Technology Center Montana State University-Bozeman Phone (406)994-5088 PO Box 173240, Bozeman, MT 59717-3240 FAX (406)994-4600 ================================================================================ Archive-Date: Fri, 14 Feb 1997 14:26:23 EST Sender: owner-mx-list@wku.edu Date: Fri, 14 Feb 1997 14:26:14 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AFE0B.7F38621A.19@ALPHA.WKU.EDU> Subject: RE: Messages to owner-listname Allen Porter writes: > >When users send a message to owner-bus31104, the message is forwarded by >MX to the Errors-to address and not the Owner. This is not our intent; >we do want the errors to go as specified, but it seems that messages to >owner-listname should go to the owner. A quick look at the source shows >that indeed FORWARD_TO_LIST_OWNER uses the Errors-to address. We >suspect that this behavior is probably not correct; at least it >certainly violates the rule of least astonishment. > Maybe. Part of this is historical. In the beginning, there wasn't any real standard for how to route errors. Then, a few years ago, the "owner-listname" convention came into use as the address to use for all errors. Since MX made a distinction between "owner" and "errors-to", I selected "owner-listname" to be the errors-to address. The "/OWNER" is still the guy who adds and removes addresses. It would have been better if the convention had included a "errors-listname", but it didn't. (There's no RFC for this, as far as I know.) Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Sun, 16 Feb 1997 07:09:24 EST Sender: owner-mx-list@wku.edu Date: Sunday, February 16, 1997, 07:00 AM CST From: Reply-To: MX-List@MadGoat.com To: mx-list@ALPHA.WKU.EDU Subject: Emergency... Inbound mail, but Host Lookup errors on all outbound using: CISCO MultiNet V4.0 Rev A, AlphaServer 2100 4/200, OpenVMS AXP V7.0 i am sending this via port 25 telnet.... i just installed MX 4.2 and it cannot resolve any hosts except for ones defined in the paths. i am receiving inbound mail... but nothing will go outbound. NSLOOKUP on the same hostnames responds just fine. example: $ mu nslookup Default Server: LOCALHOST Address: 127.0.0.1 > pop Server: LOCALHOST Address: 127.0.0.1 Non-authoritative answer: Name: POP.UMKC.EDU Address: 134.193.14.35 Entry: 3, Origin: [Local] Status: IN-PROGRESS, size: 0 bytes Created: 16-FEB-1997 06:24:50.42, expires 18-MAR-1997 06:24:50.42 Last modified 16-FEB-1997 06:24:51.93 SMTP entry #4, status: READY, size: 0 bytes, waiting for retry until 16-FEB-19 97 08:24:52.40 Created: 16-FEB-1997 06:24:51.59, expires 18-MAR-1997 06:24:50.42 Last modified 16-FEB-1997 06:24:52.40 Recipient #1: , Route=POP.UMKC.EDU DNS errors=1 Last error: %MX-F-NOHOST, no such host I tried both installing the new local and smtp servers and without... not that it would make much difference... Would mail$system_flags have anything to do with this? any advice would be appreciated. Thanx in advance... -Ron rrockwell@cctr.umkc.edu <<----just in case i sent this wrong... ================================================================================ Archive-Date: Sun, 16 Feb 1997 07:46:02 EST Sender: owner-mx-list@wku.edu Date: Sun, 16 Feb 1997 07:41:47 To: From: Reply-To: MX-List@MadGoat.com Subject: More input From the Debugger on Failing DNS on 4.2 Here is the debug... looks like NSLOOKUP is working just fine, the extended status though has failed... "end of file?" .... 16-FEB-1997 07:39:23.95 Processing queue entry number 60 on node AXP1 16-FEB-1997 07:39:24.18 Recipient: , route=POP.UMKC.ED U 16-FEB-1997 07:39:24.18 Recipient: , route=pop.umkc.ed u 16-FEB-1997 07:39:24.18 SMTP_SEND: looking up host name POP.UMKC.EDU 16-FEB-1997 07:39:24.19 SMTP_SEND: DNS_MXLOOK status is 00000001 16-FEB-1997 07:39:24.20 SMTP_SEND: Failed, sts=00000870 16-FEB-1997 07:39:24.20 SMTP_SEND: looking up host name CCTR.UMKC.EDU 16-FEB-1997 07:39:24.20 SMTP_SEND: DNS_MXLOOK status is 00000001 16-FEB-1997 07:39:24.21 SMTP_SEND: Failed, sts=00000870 16-FEB-1997 07:39:24.21 SMTP send failed, sts=0C278024, sts2=00000870 16-FEB-1997 07:39:24.21 Recipient status=0C278024 for 16-FEB-1997 07:39:24.21 Recipient status=0C278024 for 16-FEB-1997 07:39:24.91 2 rcpts need retry, next try 16-FEB-1997 09:39:24.91 16-FEB-1997 07:39:24.94 *** End of processing pass *** $ write sys$output f$message(%x00000870) %SYSTEM-W-ENDOFFILE, end of file can anyone tell me what this suggests? Failed, sts=00000870 Hunter are you alive on Sundays? ================================================================================ Archive-Date: Sun, 16 Feb 1997 10:51:53 EST Sender: owner-mx-list@wku.edu Date: Sun, 16 Feb 1997 17:51:37 CET-DST From: "Rok Vidmar, NUK Ljubljana" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AFFBA.84E01940.3@NUK.Uni-Lj.Si> Subject: RE: Emergency... Inbound mail, but Host Lookup errors on all outbound > CISCO MultiNet V4.0 Rev A, AlphaServer 2100 4/200, OpenVMS AXP V7.0 > > i am sending this via port 25 telnet.... i just installed MX 4.2 and > it cannot resolve any hosts except for ones defined in the paths. > > i am receiving inbound mail... but nothing will go outbound. > > NSLOOKUP on the same hostnames responds just fine. Grab the latest NETLIB from Hunter's server, install it, and restart MX. > I tried both installing the new local and smtp servers and without... not > that it would make much difference... They solve another problems - stick to the new ones! > Would mail$system_flags have anything to do with this? No. > any advice would be appreciated. Thanx in advance... NETLIB in MX's distribution is not working properly with MultiNet from V3.5B on (if memory serves me right). Hunter, would it pay off to build new distribution of V4.2? Regards, Rok Vidmar Internet: rok.vidmar@uni-lj.si National and University Library Phone: +386 61 125 4218 Turjaska 1, 1000 Ljubljana Fax: +386 61 125 5007 Slovenia ================================================================================ Archive-Date: Sun, 16 Feb 1997 11:30:21 EST Sender: owner-mx-list@wku.edu Date: Sun, 16 Feb 1997 11:29:57 CST From: Ron Reply-To: MX-List@MadGoat.com To: JAVIER@KJSL.COM, ROK.VIDMAR@NUK.UNI-LJ.SI CC: MX-LIST@MADGOAT.COM Message-ID: <009AFF85.33CD0426.35@CCTR.UMKC.EDU> Subject: Success. Thanks so much! Emergency squashed! i had TCPDUMP going, and had looked up the IO error in the io-status block, and was ready to start patching the source! Both of your messages came in at about the same time. If you all receive this message, (i have already tested other addresses, so no doubt), then you can pat yourselves on the back for doing me a big favor! 8^) BTW, i noticed that WKU is running MX version 4.3.... heh heh.... you find those things out when you are forced to send your mail via telnet.... 8^) Thanx so much for your help. Ron Rockwell - CCTR/Systems Programmer rrockwell@umkc.edu University of Missouri at Kansas City ================================================================================ Archive-Date: Sun, 16 Feb 1997 12:37:56 EST Sender: owner-mx-list@wku.edu Date: Sun, 16 Feb 1997 12:37:33 CST From: Ron Reply-To: MX-List@MadGoat.com To: MX-LIST@MADGOAT.COM Message-ID: <009AFF8E.A557C0FF.108@CCTR.UMKC.EDU> Subject: MAIL$SYSTEM_FLAGS Curious about whether or not these affect the MX-mailer, particularly the new added bit/vector that came along with Decnet/OSI. Ron Rockwell - CCTR/Systems Programmer rrockwell@umkc.edu University of Missouri at Kansas City ================================================================================ Archive-Date: Sun, 16 Feb 1997 13:05:44 EST Sender: owner-mx-list@wku.edu Date: Sun, 16 Feb 1997 14:05:26 EST From: Jim Bender Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AFF9A.EC128A1E.2569@bdsnet.com> Subject: Re: MX local dying Hi.... I've been following the recent thread on the dying MX_LOCAL because this recently started happening to us also. I installed the new MX_LOCAL.EXE figuring it would cure our problem also. No such luck. It appears that something else is wrong with the MX_LOCAL module, as shown by the output below. This is apparently being caused by poorly formatted messages from Netscape (the company). This is evidenced by the fact that there are a bunch of .TMP files lying around in the .LOCAL directory, and the ones containing the bad message from Netscape all have a max record size of 816, which matches the error below. Has anyone else seen anything like this? The Netscape server seems pretty persistent, since we loose all four MX_LOCAL processes within a short time of putting them back up. MX_WATCHDOG has been handling the process restoration, so the problem isn't critical, it's just very very annoying. I'd like to avoid blocking SMTP connections from Netscape. :-) Thanks! Jim Bender jbender@bdsnet.com =============================================================== %MX-F-MEMALLOC, error allocating memory from zone TXTZONE -LIB-F-INSVIRMEM, insufficient virtual memory %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel PC abs PC 0009ABF5 0009ABF5 DELIVER ADD_TO_QUEUE 937 00000010 00006E84 831E53F5 831E53F5 DELIVER MAIL_ERR_HANDLER 881 0000002A 00006E00 DELIVER SEND_MESSAGE 1037 0000003A 00006F41 ----- above condition handler called with exception 0000000C: %SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=7FFE0260, PC=00048198, PSL=03C00000 ----- end of exception message 00000000 00000000 000488DB 000488DB ----- above condition handler called with exception 007E820A: %MAIL-E-READERR, error reading MX_ROOT:[LOCAL]LCL_CC8C013E_009AFF8B_20A06DC5.TMP;1 -RMS-W-RTB, 816 byte record too large for user's buffer ----- end of exception message 00048177 00048177 8325E155 8325E155 000454C9 000454C9 0004565A 0004565A 00048680 00048680 000410C6 000410C6 0004120B 0004120B DELIVER SEND_MESSAGE 1032 00000025 00006F2C DELIVER MAIL_TO_RECIPIENTS 1175 000001DC 0000711E DELIVER DELIVER 796 00000AC2 00006C6A PROCESS PROCESS 382 0000064E 00003FEF MX_LOCAL MX_LOCAL 31 000003D5 00002DD9 ================================================================================ Archive-Date: Sun, 16 Feb 1997 14:52:21 EST Sender: owner-mx-list@wku.edu Date: Sun, 16 Feb 1997 14:52:03 CST From: Ron Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009AFFA1.6F457995.11@CCTR.UMKC.EDU> Subject: Re: MX local dying The problem with a bad local address that is on a mailing list has still not been fixed it seems. The new patch of local on 4.2 under 7.0 (finally) still dies on things like a local address with a bad mailing forward in the vms mail profile. =->From: IN%"MX-List@MadGoat.com" 16-FEB-1997 13:14:21.40 =->To: IN%"MX-List@MadGoat.com" =->CC: =->Subj: Re: MX local dying =-> =->Return-Path: =->Received: from axp1.wku.edu by axp1.umkc.edu (MX V4.2 AXP) with SMTP; Sun, 16 =-> Feb 1997 13:14:17 CST =->X-ListName: Message Exchange Discussion List =->Warnings-To: <> =->Errors-To: owner-mx-list@wku.edu =->Sender: owner-mx-list@wku.edu =->Date: Sun, 16 Feb 1997 14:05:26 EST =->From: Jim Bender =->Reply-To: MX-List@MadGoat.com =->To: MX-List@MadGoat.com =->Message-ID: <009AFF9A.EC128A1E.2569@bdsnet.com> =->Subject: Re: MX local dying =-> =->Hi.... =-> =->I've been following the recent thread on the dying MX_LOCAL because =->this recently started happening to us also. I installed the new =->MX_LOCAL.EXE figuring it would cure our problem also. No such luck. =-> =->It appears that something else is wrong with the MX_LOCAL module, as =->shown by the output below. =-> =->This is apparently being caused by poorly formatted messages from =->Netscape (the company). This is evidenced by the fact that there =->are a bunch of .TMP files lying around in the .LOCAL directory, and =->the ones containing the bad message from Netscape all have a max =->record size of 816, which matches the error below. =-> =->Has anyone else seen anything like this? The Netscape server seems =->pretty persistent, since we loose all four MX_LOCAL processes within =->a short time of putting them back up. MX_WATCHDOG has been handling =->the process restoration, so the problem isn't critical, it's just very =->very annoying. =-> =->I'd like to avoid blocking SMTP connections from Netscape. :-) =-> =->Thanks! =->Jim Bender =->jbender@bdsnet.com =-> =->=============================================================== =-> =->%MX-F-MEMALLOC, error allocating memory from zone TXTZONE =->-LIB-F-INSVIRMEM, insufficient virtual memory =->%TRACE-F-TRACEBACK, symbolic stack dump follows =->module name routine name line rel PC abs PC =-> =-> 0009ABF5 0009ABF5 =->DELIVER ADD_TO_QUEUE 937 00000010 00006E84 =-> 831E53F5 831E53F5 =->DELIVER MAIL_ERR_HANDLER 881 0000002A 00006E00 =->DELIVER SEND_MESSAGE 1037 0000003A 00006F41 =->----- above condition handler called with exception 0000000C: =->%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=7FFE0260, PC=00048198, PSL=03C00000 =->----- end of exception message =-> 00000000 00000000 =-> 000488DB 000488DB =->----- above condition handler called with exception 007E820A: =->%MAIL-E-READERR, error reading MX_ROOT:[LOCAL]LCL_CC8C013E_009AFF8B_20A06DC5.TMP;1 =->-RMS-W-RTB, 816 byte record too large for user's buffer =->----- end of exception message =-> 00048177 00048177 =-> 8325E155 8325E155 =-> 000454C9 000454C9 =-> 0004565A 0004565A =-> 00048680 00048680 =-> 000410C6 000410C6 =-> 0004120B 0004120B =->DELIVER SEND_MESSAGE 1032 00000025 00006F2C =->DELIVER MAIL_TO_RECIPIENTS 1175 000001DC 0000711E =->DELIVER DELIVER 796 00000AC2 00006C6A =->PROCESS PROCESS 382 0000064E 00003FEF =->MX_LOCAL MX_LOCAL 31 000003D5 00002DD9 Ron Rockwell - CCTR/Systems Programmer rrockwell@umkc.edu University of Missouri at Kansas City ================================================================================ Archive-Date: Mon, 17 Feb 1997 08:51:50 EST Sender: owner-mx-list@wku.edu Date: Mon, 17 Feb 1997 08:51:43 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: JBENDER@BDSNET.COM Message-ID: <009B0038.42FD4374.4@ALPHA.WKU.EDU> Subject: Re: MX local dying Jim Bender writes: > >This is apparently being caused by poorly formatted messages from >Netscape (the company). This is evidenced by the fact that there >are a bunch of .TMP files lying around in the .LOCAL directory, and >the ones containing the bad message from Netscape all have a max >record size of 816, which matches the error below. > Can anyone SEND/FOREIGN the following files to me concerning this: - a .TMP file from MX_LOCAL_DIR: - the corresponding .MSG_TEXT, .HDR_INFO, and .SRC_INFO for that message Thanks. >%MX-F-MEMALLOC, error allocating memory from zone TXTZONE >-LIB-F-INSVIRMEM, insufficient virtual memory >%TRACE-F-TRACEBACK, symbolic stack dump follows >module name routine name line rel PC abs PC > > 0009ABF5 0009ABF5 >DELIVER ADD_TO_QUEUE 937 00000010 00006E84 > 831E53F5 831E53F5 >DELIVER MAIL_ERR_HANDLER 881 0000002A 00006E00 >DELIVER SEND_MESSAGE 1037 0000003A 00006F41 >----- above condition handler called with exception 0000000C: >%SYSTEM-F-ACCVIO, access violation, reason mask=00, virtual address=7FFE0260, PC=00048198, PSL=03C00000 >----- end of exception message > 00000000 00000000 > 000488DB 000488DB >----- above condition handler called with exception 007E820A: >%MAIL-E-READERR, error reading MX_ROOT:[LOCAL]LCL_CC8C013E_009AFF8B_20A06DC5.TMP;1 >-RMS-W-RTB, 816 byte record too large for user's buffer >----- end of exception message > 00048177 00048177 Note that MAIL signals the error, then MAIL generates the access violation (so it appeares, based on the PC addressess), then MX does with the "Insufficient virtual memory". Not really sure why MX is getting that error, but getting the original files might help. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Mon, 17 Feb 1997 09:28:21 EST Sender: owner-mx-list@wku.edu Date: Mon, 17 Feb 1997 09:28:15 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MadGoat-Announce@MadGoat.com CC: MX-List@LISTS.WKU.EDU Message-ID: <009B003D.5D7E474B.6@ALPHA.WKU.EDU> Subject: www.madgoat.com and other Web things This past weekend, WKU switched from the OSU HTTP Server to Process Software's Purveyor server. As a result of that, a number of enhancements have been made. The new address for the MadGoat Software WWW page is: http://www.madgoat.com/ The old WKU address still works as well. The new www.madgoat.com address is handled by Purveyor's virtual server capability. Also, you can now search the MX-List and Info-MadGoat mailing list archives. You can reach them through pages on the MadGoat page, or you can use: http://www.madgoat.com/scripts/mxarchive/as_init.com?MX-List http://www.madgoat.com/scripts/mxarchive/as_init.com?Info-MadGoat For more information on Purveyor, check out http://www.process.com/. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Mon, 17 Feb 1997 11:00:37 EST Sender: owner-mx-list@wku.edu Date: Mon, 17 Feb 1997 10:59:46 CST From: Andy Rupf Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B004A.265C2662.138@CCTR.UMKC.EDU> Subject: SMTP_server crash I debugged our smtp_server for a while today and found that there was one message that was always incomplete in the logs when it died. I was wondering what you folks thought of it. The error seemed to be "illegal string class". 17-FEB-1997 09:45:00.75 STM[13]: Send "220 axp1.umkc.edu MX V4.2 AXP SMTP server ready at Mon, 17 Feb 1997 09:45:00 CST" 17-FEB-1997 09:45:03.70 STM[13]: Receive "Helo ATLAS.UMKC.EDU" 17-FEB-1997 09:45:03.74 STM[13]: Send "250 Hello, ATLAS.UMKC.EDU" 17-FEB-1997 09:45:03.78 STM[13]: Receive "MAIL FROM:" 17-FEB-1997 09:45:03.92 STM[13]: Send "250 MAIL command accepted." 17-FEB-1997 09:45:04.70 STM[13]: Receive "RCPT TO:" 17-FEB-1997 09:45:04.70 STM[13]: Send "250 Recipient okay (at least in form)" 17-FEB-1997 09:45:05.53 STM[13]: Receive "RCPT TO:" 17-FEB-1997 09:45:05.53 STM[13]: Send "250 Recipient okay (at least in form)" 17-FEB-1997 09:45:06.13 STM[13]: Receive "DATA" 17-FEB-1997 09:45:06.33 STM[13]: Send "354 Start mail input; end with . " 17-FEB-1997 09:45:06.61 STM[13]: Receive "Received: from nd.edu by ATLAS.UMKC. EDU with SMTP;" 17-FEB-1997 09:45:06.70 STM[13]: Receive " Sun, 16 Feb 1997 21:41:26 -0600 (CST)" 17-FEB-1997 09:45:06.88 STM[13]: Receive "Received: from nd.edu (actually res0103.student.nd.edu) by nd.edu with ND-SMTP (PP); Sun, 16 Feb 1997 22:21:11 -0500" 17-FEB-1997 09:45:07.48 STM[13]: Receive "X-Sender: mary.r.volland.1@nd.edu" 17-FEB-1997 09:45:07.48 STM[13]: Receive "X-Mailer: Windows Eudora Version 2.0.3" 17-FEB-1997 09:45:07.82 STM[13]: Receive "Mime-Version: 1.0" 17-FEB-1997 09:45:07.83 STM[13]: Receive "Content-Type: text/plain; charset= "us-ascii"" 17-FEB-1997 09:45:07.83 STM[13]: Receive "Date: Sun, 16 Feb 1997 22:24:59 -0500" 17-FEB-1997 09:45:08.45 STM[13]: Receive "To: beckerje@sluvca.slu.edu,dough eem@flyernet.udayton.edu,carri@inlink.com,asmont@mail.wm.edu,egtolod@holycr oss.edu,35E4BraunC@VMS.CSD.MU.edu,,ermilt@mail.wm.edu,,obri9156@saintmarys. edu,AEM12@cornell.edu,,c665046@ Andy Rupf RANDREW@CCTR.UMKC.EDU Programmer/Analyst ----- University of Missouri-Kansas City Life is an uncertified flight mode. ================================================================================ Archive-Date: Mon, 17 Feb 1997 11:49:36 EST Sender: owner-mx-list@wku.edu Date: Mon, 17 Feb 1997 11:49:30 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: RANDREW@CCTR.UMKC.EDU Message-ID: <009B0051.191A6071.3@ALPHA.WKU.EDU> Subject: RE: SMTP_server crash Andy Rupf writes: > > >I debugged our smtp_server for a while today and found >that there was one message that was always incomplete >in the logs when it died. I was wondering what you folks >thought of it. The error seemed to be "illegal string class". > This problem was fixed several weeks ago with the release of the new SMTP_SERVER image in [.MX.MX042.PATCH] on FTP.MADGOAT.COM. Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Mon, 17 Feb 1997 13:18:13 EST Sender: owner-mx-list@wku.edu Date: Mon, 17 Feb 1997 14:17:43 +500 From: Harry Laufman Reply-To: MX-List@MadGoat.com To: mx-list@wku.edu Message-ID: <009B0065.CDBA7EC0.134@agvax2.ag.ohio-state.edu> Subject: POP3 Processes not terminating Hello, This morning our VAX was in the mud. Log in took 3-4 minutes, commands likewise. SHO SYS showed the below ouput. We run MX 2.1, Multinet 3.2., VMS 5.4-3. A very simple machine, really just mail. User Johnson has 11 POP3 processes still running with many page faults, lots of memory used, minutes of CPU time. The user Johnson had be inadvertently mailbombed, she was sent two 3-Megabyte files as an attachement. So Johnson's diskquota was overdrawn. Johnson's Eudora failed to fetch the mail. She tried "a few times". These attempts were over a PPP based connection we establish for dialins with a DecServer 700. Disk space on all our disks was adequate, 81% used (normal) on system, the rest ranging from 30 to 70% used. I rebooted, removed Johnson's monster messages, and all seems well now, 3 hours out. I need some insight into what happened here. First what does the Process State of RWMPB mean? How can I prevent this recurring? Why don't these processes die when Johnson disconnects? I can't find anything on POP3 in Multinet's documentation (this might be me, not Multinet). Is there a way to refuse mail over a certain size? With MX, with Multinet, with VMS? [An aside, Eudora attachments will be the death of me. More and more frequently people are blithely sending 10-15 megabyte attachments.MX-List@wku.edu] Thanks for any help. SHO SYS during the bad times: VAX/VMS V5.4-3 on node AGVAXT 17-FEB-1997 08:04:10.61 Uptime 1 17:37:56 Pid Process Name State Pri I/O CPU Page flts Ph.Mem 00000081 SWAPPER HIB 16 0 0 05:26:47.36 0 0 00000085 CONFIGURE HIB 8 22 0 00:00:00.07 106 183 00000087 ERRFMT HIB 8 1283 0 00:00:04.17 84 143 00000088 OPCOM LEF 7 738 0 00:00:01.49 306 178 00000089 AUDIT_SERVER HIB 10 360 0 00:00:04.53 1362 475 0000008A JOB_CONTROL HIB 9 9750 0 00:00:10.55 317 533 0000008B IPCACP HIB 10 7 0 00:00:00.10 78 157 0000008C TP_SERVER HIB 10 9703 0 00:00:10.06 169 271 0000008D NETACP HIB 9 1755 0 00:00:15.59 488 675 0000008E EVL HIB 6 242 0 00:00:00.73 39601 80 N 0000008F REMACP HIB 13 8 0 00:00:00.04 72 66 00000090 LATACP HIB 14 8 0 00:00:02.50 250 174 00000091 MULTINET_SERVER LEF 9 95984 0 00:01:30.32 1768 1401 00000092 MX FLQ Manager HIB 9 46479 0 00:01:29.15 1174 1107 00000093 MX Router LEF 8 29890 0 00:02:07.75 1654 1953 00000094 MX Local LEF 4 92170 0 00:05:54.51 897 1565 00000095 MX SMTP HIB 9 3425 0 00:00:05.52 439 756 00000096 MX SMTP#2 HIB 9 2581 0 00:00:05.07 491 778 00000097 MX SMTP#3 HIB 9 2727 0 00:00:05.15 464 726 00000099 MX SMTP#4 HIB 9 2137 0 00:00:05.10 446 704 0000009A MX SMTP#5 HIB 9 3741 0 00:00:05.24 456 724 0000009B MX SMTP#6 HIB 9 12682 0 00:00:19.07 895 1075 0000009C MX SMTP#7 HIB 8 3633 0 00:00:05.81 458 731 0000009D MX SMTP#8 HIB 9 4181 0 00:00:06.36 482 752 0000009E MX SMTP Server LEF 4 69595 0 00:03:47.72 883 1590 0000009F MX MLF RWMPB 6 10028 0 00:00:13.27 10059 3000 000000A0 SYMBIONT_0001 HIB 9 43 0 00:00:00.83 284 73 000000A1 RDMS_MONITOR LEF 15 18 0 00:00:00.27 2375 70 000000A2 RPC$SWL HIB 13 21 0 00:00:00.11 130 205 000000A3 BULLCP RWMPB 6 30034 0 00:01:25.85 846 981 000000A4 Watcher HIB 4 507 0 00:00:22.25 142 217 000000A6 SYSTEM LEF 7 216 0 00:00:01.23 1059 486 00001132 FOURMAN LEF 6 185 0 00:00:01.06 1053 386 00000E36 RWMPB 6 513 0 00:03:15.20 68865 4096 N 00000E38 RWMPB 8 513 0 00:02:56.51 68929 4096 N 00001139 LEF 5 135 0 00:00:00.95 913 357 N 00000E3A RWMPB 8 513 0 00:02:15.47 65192 4096 N 00000E3B RWMPB 8 513 0 00:02:06.50 66149 4096 N 00000E3D RWMPB 6 502 0 00:01:42.75 62471 4096 N 00000E3F RWMPB 6 468 0 00:01:44.62 62615 4096 N 00000E40 RWMPB 6 441 0 00:01:44.54 62531 4096 N 000010C1 GEAU LEF 10 402 0 00:00:03.27 2033 909 00000E42 RWMPB 6 393 0 00:01:44.32 63363 4096 N 00001145 LEF 7 97 0 00:00:00.77 723 744 N 00000E46 RWMPB 8 320 0 00:01:43.09 62658 4096 N 00001147 BENNETTM LEF 6 111 0 00:00:00.81 879 780 00001149 GRIFFITHS RWMPB 6 77 0 00:00:00.42 539 360 00000E4A RWMPB 8 314 0 00:01:23.46 59971 4096 N 0000114B LEF 5 138 0 00:00:00.82 868 334 N 000010CC PUBS RWMPB 6 289 0 00:00:02.74 1572 701 0000114D LEF 9 88 0 00:00:00.69 691 763 N 0000114E RWMPB 8 79 0 00:00:00.52 439 414 N 00001152 RWMPB 6 81 0 00:00:00.43 421 600 N 00000E54 LEF 10 107 0 00:00:01.02 894 916 N 00001155 RWMPB 6 70 0 00:00:00.41 398 373 N 00001156 HOFMEISTER LEF 6 42 0 00:00:00.17 213 287 00001158 OPERATOR CUR 5 152 0 00:00:00.71 547 424 00001159 STONEA LEF 5 41 0 00:00:00.28 263 329 0000115B RWMPB 8 32 0 00:00:00.17 190 270 N 0000115C _LTA5291: LEF 8 0 0 00:00:00.02 115 168 0000115D LEF 4 0 0 00:00:00.02 103 166 N 0000115E LEF 4 0 0 00:00:00.04 103 166 N SHO SYS during good times: VAX/VMS V5.4-3 on node AGVAXT 17-FEB-1997 12:04:31.39 Uptime 0 03:32:42 Pid Process Name State Pri I/O CPU Page flts Ph.Mem 0000081 SWAPPER HIB 16 0 0 00:00:11.09 0 0 00000085 CONFIGURE HIB 8 26 0 00:00:00.07 106 180 00000087 ERRFMT HIB 8 183 0 00:00:00.41 84 143 00000088 OPCOM HIB 9 316 0 00:00:00.83 298 171 00000089 AUDIT_SERVER HIB 10 195 0 00:00:00.75 1393 440 0000008A JOB_CONTROL HIB 9 4162 0 00:00:05.10 285 482 0000008B IPCACP HIB 10 7 0 00:00:00.06 78 157 0000008C TP_SERVER HIB 10 880 0 00:00:02.03 169 271 0000008D NETACP HIB 10 195 0 00:00:04.26 485 677 0000008E EVL HIB 6 248 0 00:00:00.43 3918 73 N 0000008F REMACP HIB 8 8 0 00:00:00.04 71 63 00000090 LATACP HIB 14 8 0 00:00:00.45 246 171 00000091 MULTINET_SERVER HIB 5 60519 0 00:00:58.03 1608 1130 00000092 MX FLQ Manager HIB 6 36511 0 00:01:13.03 926 896 00000095 MX Router HIB 5 23507 0 00:02:30.68 3559 2343 00000097 MX Local COM 4 138646 0 00:08:20.05 2525 2455 00000098 MX SMTP HIB 4 6980 0 00:00:10.12 548 868 0000009B MX SMTP#2 HIB 4 5824 0 00:00:10.21 466 739 0000009D MX SMTP#3 HIB 4 5346 0 00:00:10.37 569 836 0000009E MX SMTP#4 HIB 4 6007 0 00:00:10.30 538 809 0000009F MX SMTP#5 HIB 4 2856 0 00:00:06.82 486 761 000000A2 MX SMTP#6 HIB 4 3861 0 00:00:08.41 498 763 000000A3 MX SMTP#7 HIB 4 4931 0 00:00:09.05 566 788 000000A4 MX SMTP#8 HIB 4 6345 0 00:00:10.82 534 822 000000A5 MX SMTP Server HIB 5 43745 0 00:02:13.00 718 1386 000000A7 MX MLF HIB 5 8261 0 00:00:11.79 6977 3000 000000A9 SYMBIONT_0001 HIB 4 42 0 00:00:00.20 283 70 000000AB RDMS_MONITOR LEF 15 18 0 00:00:00.22 390 69 000000AD RPC$SWL HIB 9 23 0 00:00:00.08 129 205 000000AF BULLCP HIB 6 2593 0 00:00:07.53 788 861 000000B1 Watcher HIB 4 55 0 00:00:02.07 161 236 00000142 OPERATOR CUR 4 39202 0 00:01:28.76 36518 343 00000647 CURTNER LEF 4 917 0 00:00:02.57 2023 243 00000AD3 WARRIX1 LEF 7 512 0 00:00:02.29 1741 798 00000AE0 WMYERS LEF 4 218 0 00:00:01.75 1105 387 Regards, Harry Laufman ================================================================================ Archive-Date: Mon, 17 Feb 1997 14:24:41 EST Sender: owner-mx-list@wku.edu Message-ID: <2.2.32.19970217202408.00a27234@celia.kjsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Feb 1997 12:24:08 -0800 To: MX-List@MadGoat.com From: Javier Henderson Reply-To: MX-List@MadGoat.com Subject: Re: POP3 Processes not terminating At 02:17 PM 2/17/97 +500, you wrote: >I need some insight into what happened here. First what does the Process State >of RWMPB mean? How can I prevent this recurring? Why don't these processes >die when Johnson disconnects? I can't find anything on POP3 in Multinet's >documentation (this might be me, not Multinet). Is there a way to refuse >mail over a certain size? With MX, with Multinet, with VMS? With MultiNet, you can tell the mailer to observe disk quotas (in fact, it's the default behavior). I'm not sure about MX's observance of disk quotas. In your case, since you're running MX, the MultiNet SMTP mailer is not a part of the picture. Incidentally, you may want to consider upgrading to a more current version of MultiNet, we fixed several bugs and added UIDL support later on. The current version is 4.0a, with 4.0b to be released in a couple of weeks. Javier Henderson, MultiNet/VMS support javier@tgv.com (work) javier@kjsl.com (home) ================================================================================ Archive-Date: Mon, 17 Feb 1997 22:15:27 EST Sender: owner-mx-list@wku.edu Date: Mon, 17 Feb 1997 22:15:17 CST From: rrockwell@CCTR.UMKC.EDU Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B00A8.84AF9984.73@CCTR.UMKC.EDU> Subject: RE: SMTP_server crash =->Andy Rupf writes: =->> =->> =->>I debugged our smtp_server for a while today and found =->>that there was one message that was always incomplete =->>in the logs when it died. I was wondering what you folks =->>thought of it. The error seemed to be "illegal string class". =->> =->This problem was fixed several weeks ago with the release of the =->new SMTP_SERVER image in [.MX.MX042.PATCH] on FTP.MADGOAT.COM. =-> =->Hunter =->------ =->Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com =-> http://www.madgoat.com/hunter.html Hunter, i applied that very patch. er... is ftp.madgoat.com the same as ftp.wku.edu?? if not, then i suppose i had better got and reapply the patch... oops. Ron Rockwell - CCTR/Systems Programmer rrockwell@umkc.edu University of Missouri at Kansas City ================================================================================ Archive-Date: Mon, 17 Feb 1997 22:23:18 EST Sender: owner-mx-list@wku.edu Date: Mon, 17 Feb 1997 22:23:11 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B00A9.9F923AFA.9@ALPHA.WKU.EDU> Subject: RE: SMTP_server crash rrockwell@CCTR.UMKC.EDU writes: > >=->This problem was fixed several weeks ago with the release of the >=->new SMTP_SERVER image in [.MX.MX042.PATCH] on FTP.MADGOAT.COM. >=-> > > i applied that very patch. er... is ftp.madgoat.com the same as >ftp.wku.edu?? if not, then i suppose i had better got and reapply >the patch... oops. > Currently, FTP.MADGOAT.COM does point to FTP.WKU.EDU. If that ever changes, the files will still be maintained on both addresses, so it matters not which one you use. Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Mon, 17 Feb 1997 22:23:30 EST Sender: owner-mx-list@wku.edu Date: Mon, 17 Feb 1997 22:18:40 CST From: rrockwell@CCTR.UMKC.EDU Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B00A8.FDEC2EBB.151@CCTR.UMKC.EDU> Subject: RE: SMTP_server crash =->Andy Rupf writes: =->> =->>I debugged our smtp_server for a while today and found =->>that there was one message that was always incomplete =->>in the logs when it died. I was wondering what you folks =->>thought of it. The error seemed to be "illegal string class". =->> =->This problem was fixed several weeks ago with the release of the =->new SMTP_SERVER image in [.MX.MX042.PATCH] on FTP.MADGOAT.COM. =-> =->Hunter =->------ =->Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com =-> http://www.madgoat.com/hunter.html okay, just to make sure, i am downloading the patches from scratch. If this is still a problem, Andy will certainly let you know by tomorrow. Ron Rockwell - CCTR/Systems Programmer rrockwell@umkc.edu University of Missouri at Kansas City ================================================================================ Archive-Date: Tue, 18 Feb 1997 00:50:28 EST Sender: owner-mx-list@wku.edu From: dwing@cisco.com (Dan Wing) Subject: Re: MAIL$SYSTEM_FLAGS Date: 17 Feb 1997 18:43:00 GMT Message-ID: <5ea8rk$osu@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <009AFF8E.A557C0FF.108@CCTR.UMKC.EDU>, Ron writes: > >Curious about whether or not these affect the MX-mailer, particularly >the new added bit/vector that came along with Decnet/OSI. MX makes calls into the VMS-supplied MAIL$ routines which interpret the MAIL$SYSTEM_FLAGS logical. -Dan Wing dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Tue, 18 Feb 1997 11:37:00 EST Sender: owner-mx-list@wku.edu Date: Tue, 18 Feb 1997 11:36:24 CST From: rrockwell@CCTR.UMKC.EDU Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B0118.6F62CA22.198@CCTR.UMKC.EDU> Subject: RE: SMTP_server crash =->rrockwell@CCTR.UMKC.EDU writes: =->> =->>=->This problem was fixed several weeks ago with the release of the =->>=->new SMTP_SERVER image in [.MX.MX042.PATCH] on FTP.MADGOAT.COM. =->>=-> =->> =->> i applied that very patch. er... is ftp.madgoat.com the same as =->>ftp.wku.edu?? if not, then i suppose i had better got and reapply =->>the patch... oops. =->> =->Currently, FTP.MADGOAT.COM does point to FTP.WKU.EDU. If that ever =->changes, the files will still be maintained on both addresses, so it =->matters not which one you use. =-> =->Hunter =->------ =->Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com =-> http://www.madgoat.com/hunter.html Well, Andy is on vacation now... lucky devil... and this is a brand new installation of 4.2 on VMS7.0, using both the new local and new smtp server patches. They still die at asynchronous intervals, usually in under an hours time, regularly. We get a pretty wide variety of mail-types since we get a pretty large quantity for a very diverse userbase. So it is understandable that if there is an error to occur, it WILL occur at our site. I was in high expectation that the 4.2+7.0 combination would finally be a winner and we could finally get back to other business at hand. 8^( Ron Rockwell - CCTR/Systems Programmer rrockwell@umkc.edu University of Missouri at Kansas City ================================================================================ Archive-Date: Tue, 18 Feb 1997 12:06:58 EST Sender: owner-mx-list@wku.edu Date: Tue, 18 Feb 1997 12:06:53 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B011C.B1451D41.18@ALPHA.WKU.EDU> Subject: RE: SMTP_server crash rrockwell@CCTR.UMKC.EDU writes: > >Well, Andy is on vacation now... lucky devil... and this is a brand new >installation of 4.2 on VMS7.0, using both the new local and new smtp >server patches. They still die at asynchronous intervals, usually in under >an hours time, regularly. Well, you know what to do: - enable debugging for the appropriate agents - run the agents interactively to capture the full tracedump when they die - send them directly to me so I can try to figure out what's going on The only outstanding problems I know about right now are when: - a node has an improperly specified MX record (no host) - Widener.edu sends you mail with ".Widener.edu" on the HELO line >We get a pretty wide variety of mail-types since >we get a pretty large quantity for a very diverse userbase. So it is >understandable that if there is an error to occur, it WILL occur at >our site. > The same can be said for WKU, and they've experienced none of the problems. With the log files, perhaps I can make better sense of what's going on. Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Tue, 18 Feb 1997 13:28:06 EST Sender: owner-mx-list@wku.edu Date: Tue, 18 Feb 1997 19:33:26 GMT0 From: Mark Iline Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B015B.12FD1F74.1@dredd.meng.ucl.ac.uk> Subject: RE: www.madgoat.com and other Web things From: Hunter Goatley > This past weekend, WKU switched from the OSU HTTP Server to Process > Software's Purveyor server. As a result of that, a number of > enhancements have been made. > The new address for the MadGoat Software WWW page is: > > http://www.madgoat.com/ > > The old WKU address still works as well. The new www.madgoat.com > address is handled by Purveyor's virtual server capability. Just for information, but the OSU server has virtual server capability as well. http://www2.lp.se/how.html tells you how, if anyone's interested. Sorry this is a bit off-topic. Mark Mark Iline Sys Mgr Dept Mech Eng University College London UK system@meng.ucl.ac.uk MAG (UK) NC Internet Bod ================================================================================ Archive-Date: Tue, 18 Feb 1997 15:26:53 EST Sender: owner-mx-list@wku.edu Message-ID: <3.0.1.32.19970218132221.008d8100@stargate.lbcc.cc.or.us> Date: Tue, 18 Feb 1997 13:22:21 -0800 To: MX-List@MadGoat.com From: Dan Sugalski Reply-To: MX-List@MadGoat.com Subject: MX 4.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Someone else on the list mentioned seeing that wku's running v4.3 of MX. I just double-checked, and it is. Cool. Is this just the ID of the patched SMTP server, or are they really running a full MX 4.3 release. If so, any scoop on when it'll be out and what's in it? Dan ---------------------------------------------------------------------- Dan Sugalski even samurai Programmer/SysAdmin have teddy bears Linn-Benton Community College and even the teddy bears sugalsd@stargate.lbcc.cc.or.us get drunk ================================================================================ Archive-Date: Tue, 18 Feb 1997 15:33:11 EST Sender: owner-mx-list@wku.edu Date: Tue, 18 Feb 1997 15:33:06 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B0139.80317D84.19@ALPHA.WKU.EDU> Subject: RE: MX 4.3 Dan Sugalski writes: > >Someone else on the list mentioned seeing that wku's running v4.3 of MX. I >just double-checked, and it is. Cool. Is this just the ID of the patched >SMTP server, or are they really running a full MX 4.3 release. If so, any >scoop on when it'll be out and what's in it? > I should be better able to address this question in the next couple of days. WKU *is* running an MX V4.3, but the release of that version has not yet been scheduled. I hope to have more to say about this later this week. Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Wed, 19 Feb 1997 09:58:17 EST Sender: owner-mx-list@wku.edu From: Ted Spencer PhD Reply-To: MX-List@MadGoat.com Content-Type: text/plain To: MX-List@wku.edu Subject: priority headers MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Wed, 19 Feb 1997 09:58:13 EST (I'm still new at this, so bear with me, please!) One of our list subscribers ("he") sent one of our managers ("she") this message: "Can you turn down the message priority flag assigned to the message on the list? All of your messages are coming though as "Highest Priority" which fouls up my e-mail directory." I checked her e-mail to me, and it showed "X-Priority: Normal"; also, the messages coming into my mailbox from our lists do not have any priority markings. (I use Pronto Mail 96 and now 97 beta as my PC's mailer, and it does support priority settings.) Could this a problem in our MX setup? We are running MX 4.1 on Open VMS Version 5.5. Thanks for your help! __________________________________________________ Ted Spencer, PhD tspencer@scassn.org Publications Manager & Webmaster 703-750-0533 Speech Communication Assn fax 703-914-9471 http://www.scassn.org ================================================================================ Archive-Date: Wed, 19 Feb 1997 10:39:43 EST Sender: owner-mx-list@wku.edu Date: Wed, 19 Feb 1997 10:39:37 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B01D9.AAC735B7.17@ALPHA.WKU.EDU> Subject: RE: priority headers Ted Spencer PhD writes: > >I checked her e-mail to me, and it showed "X-Priority: Normal"; also, the >messages coming into my mailbox from our lists do not have any priority >markings. (I use Pronto Mail 96 and now 97 beta as my PC's mailer, and it >does support priority settings.) > >Could this a problem in our MX setup? We are running MX 4.1 on Open VMS >Version 5.5. > MX does not add an "X-Priority:" or a "Precendence:" header (at least, not yet). Someone's software somewhere must be adding it if it's not there. Or else they're being passed through MX MLF, which is why I define my lists with /STRIP=(RECEIVED,OTHER). Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Wed, 19 Feb 1997 23:55:44 EST Sender: owner-mx-list@wku.edu From: dwing@cisco.com (Dan Wing) Subject: Re: MX Local dying Date: 19 Feb 1997 21:17:03 GMT Message-ID: <5efqkf$ka2@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <1997Feb11.104106.1@aspen>, welchb@woods.uml.edu (Brendan Welch, W1LPG) writes: > We have been following the saga of the dying MX local >for some time, because we are badly affected too. Now, I have come upon >something, which I dare to post out of "intelligent ignorance". It >may be very right, or very wrong. > > For reasons other than the "dying" problem, I decided to look >at MAILUAF_PROFILE.DATA, using what is probably an old version of a >somewhat popular tool, MAILUAF.COM . When using its command LIST, in >order to see forwarding addresses, it processed about 100 names, and >then aborted with "illegal item code 14 found in record". > > Could it be that this contamination of MAILUAF-PROFILE.DATA >is causing the problem? I note by SHOW DEV/FILE that the above file >is in use both by individual users (no trouble ever noticed) and >by various processes known to MCP STAT . See if: $ MAIL MAIL> SHOW FORWARD/USER=* indicates any problems, too. > And, while I have your attention, how do I fix the contamination? The file is a normal RMS indexed file. You could use CONVERT to save all but the unreadable records. >It is aggravating that, for starters, the file is locked, so I cannot >even make a copy of it to practice on. $ BACKUP/IGNORE=INTERLOCK/LOG infile outfile >Plus, I am terrible on RMS, but >am willing to do binary editting, or do a rewrite of MAILUAF.COM to >catch and fix the bad record. > Another thing which I though might help is a template which Hein >posted for cleaning up SYSUAF.DAT . Since the files are perhaps similar, >would that approach work (it uses CONVERT)? Try something like: $ BACKUP/IGNORE=INTERLOCK/LOG SYS$SYSTEM:VMSMAIL_PROFILE.DATA SYS$LOGIN: $ SET DEFAULT SYS$LOGIN: $ ANALYZE/RMS/FDL VMSMAIL_PROFILE.DATA (which generates a VMSMAIL_PROFILE.FDL file, which is plain text) $ CONVERT/FDL=VMSMAIL_PROFILE.FDL/EXCEPT=VMSMAIL_PROFILE.EXC - VMSMAIL_PROFILE.DATA VMSMAIL_PROFILE.NEW (which should convert the file and skip the bad records) -Dan Wing dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Wed, 19 Feb 1997 23:56:16 EST Sender: owner-mx-list@wku.edu Date: Wed, 19 Feb 1997 10:50:33 MST -0700 From: "Michael L. Hitch" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B01DB.31E99AD5.20@msu.oscs.montana.edu> Subject: RE: New MX_LOCAL patch available Hunter Goatley writes: > These things always seem to come in groups. Lately, there have been > several sites reporting that their MX Local process was dying with > an access violation when sending to users with a bad forwarding > address. > > This morning, I was able to duplicate the problem and fix it. There > was a bug in the condition handler MX Local establishes to catch mail > delivery problems. The nature of the bug was such that it worked for > most errors, but didn't for some (most notably, LIB$_SYNTAX_ERR, an > error from LIB$TPARSE while parsing an address). This bug has now > been corrected (for all error conditions). There still appears to be a situation which will cause MX Local to die, even with this new version of MX_LOCAL.EXE. I've run into this several times now, because we have been allowing users to change their account names. When a username gets changes, a forwarding entry for the old username is created that forwards to the new username. If that new username is later forwarded to an MX% address, the MX Local process will die when mail delivery is attempted to the old username. I just captured another example of this (which wasn't from a username change, but has the same configuration). ] SWIFT:RTA3 $ type mx_local_log.log ] 19-FEB-1997 09:24:19.20 Processing queue entry number 5 ] 19-FEB-1997 09:24:19.39 Checking local name: WATERCENTER ] 19-FEB-1997 09:24:19.43 LOCAL_USER: Non-MX fwdg address AWRPG; treat as local. ] 19-FEB-1997 09:24:19.43 This is a regular delivery. ] 19-FEB-1997 09:24:19.54 DELIVER: mime_headers = 25 ] 19-FEB-1997 09:24:19.54 DELIVER: fdlstr = "" ] 19-FEB-1997 09:24:19.56 DELIVER: Using MX%"box@televar.com",MX%"751@televar.com",MX%"Okanogan@televar.com" as VMS MAIL From address. ] 19-FEB-1997 09:24:19.57 DELIVER: Using MX%"watercenter@swift.oscs.montana.edu" as VMS MAIL To address. ] 19-FEB-1997 09:24:19.57 DELIVER: Using as VMS MAIL CC address. ] 19-FEB-1997 09:24:19.57 DELIVER: Using "Watering Gauge" as subject. ] 19-FEB-1997 09:24:19.58 DELIVER: Attempting decode on quoted-printable file. ] 19-FEB-1997 09:24:19.71 DELIVER: $CREATE status = 00010001, STS = 00000000, STV = 00000000. ] 19-FEB-1997 09:24:20.11 DELIVER: Delivering to AWRPG ] ] SWIFT:RTA3 $ type mx_local_swift.log ] 19-FEB-1997 09:23:49.05: MX Local (pid 00001D33) starting ] 19-FEB-1997 09:24:46.24: MX Local (pid 00001D33) exiting, status = 1C278034 ] ] SWIFT:RTA3 $ set message mx_exe:mx_msg ] SWIFT:RTA3 $ write sys$output f$message(%x1C278034) ] %MX-F-MEMALLOC, error allocating memory from zone !AS ] ] SWIFT:RTA3 $ mail ] MAIL> show forward/user=watercenter ] WATERCENTER has mail forwarded to AWRPG ] ] MAIL> show forward/user=awrpg ] AWRPG has mail forwarded to MX%"WWWRC@GEMINI.OSCS.MONTANA.EDU" ] ] MAIL> exit Michael --- Michael L. Hitch mhitch@msu.oscs.montana.edu Computer Consultant, Information Technology Center Montana State University, Bozeman, MT USA ================================================================================ Archive-Date: Wed, 19 Feb 1997 23:56:22 EST Sender: owner-mx-list@wku.edu Date: Wed, 19 Feb 1997 17:53:34 CET From: Adam Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B0216.49F85820.50@dtalk.inf.elte.hu> Subject: 2nd repost: A minor forwarding error in MX4.2 (VMS6.2) Hello, Has anybody read this message? I posted it on the 4-FEB-1997. Hello, I found a minor forwarding error in MX4.2. This error exists in MicroVax 3100 with VMS 6.2 UCX 4.0 (total of 900 users, average 10 interactive, 20 Mailing lists) (dtalk.inf.elte.hu) and VAX6520-VAX9410 cluster with VMS6.2 and UCX 4.0 - MultiNet 4.0 (total of 6500 users, average 110 interactive, ANU NEWS, 30 Mailing lists) (ludens.elte.hu) Problem description: 1, define /system/exec MAIL$INTERNET_TRANSPORT MX (MAIL$TRANSPORT_MX is defined, or not; MAIL$TRANSPORT_SMTP is defined or not) MAIL> m To: user@host.domain works well. MAIL> set forward "MX%""user@host.domain""" works well. MAIL> set forward user@host.domain works, but not well... In this case the local, or decnet mail says: %MAIL-E-USERSPEC, invalid user specification '@host.domain' But the ingoing Internet message is forwarding, but something (I thing the VMSMAIL) inserted an empty line to smtp header :-( This empy line prevents forwaarding loop detecting, and prevents understanding MIME attachments, etc. 2., Nor MAIL$INTERNET_TRANSPORT neither MAIL$TRANSPORT_SMTP neither SMTP_MAILSHR are defined in LNM$SYSTEM_TABLE. In sylogin.com there is: define MAIL$INTERNET_TRANSPORT MX or define MAIL$TRANSPORT_SMTP MX_MAILSHR or define SMTP_MAILSHR MX_MAILSHR MAIL> m To: user@host.domain works well. MAIL> set forward "MX%""user@host.domain" works well. MAIL> set forward user@host.domain is betther then the previous, because doesn't work:-) The local or decnet mail says %MAIL-E-USERSPEC, invalid user specification '@host.domain' The ingoing Internet message is not forwarding. (I posted a message from maulis@ludens.elte.hu to maulis@dtalk.elte.hu and maulis@dtalk.inf.elte.hu had a forwarding address: MAULIS@LUDENS.ELTE.HU ) ============================================================================= From: MX%"Postmaster@dtalk.inf.elte.hu" To: MX%"maulis@ludens.elte.hu" CC: Subj: LOCAL delivery error Return-Path: Received: from dtalk.inf.elte.hu by ludens.elte.hu (MX V4.2 VAX) with SMTP; Tue, 04 Feb 1997 20:02:02 +0100 Date: Tue, 04 Feb 1997 20:02:54 CET From: Local delivery agent To: Subject: LOCAL delivery error X-Report-Type: Nondelivery; boundary="> Error description:" Note: this message was generated automatically. An error was detected while processing the enclosed message. A list of the affected recipients follows. This list is in a special format that allows software like LISTSERV to automatically take action on incorrect addresses; you can safely ignore the numeric codes. --> Error description: Error-For: "maulis@ludens.elte.hu"@dtalk.inf.elte.hu Error-Code: 2 Error-Text: Error in delivery to user MAULIS@LUDENS.ELTE.HU %MAIL-E-ERRACTRNS, error activating transport SMTP %LIB-E-ACTIMAGE, error activating image DTALK$DKA200:[SYS0.SYSCOMMON .][SYSLIB]SMTP_MAILSHR.EXE; -RMS-E-FNF, file not found -ECWP-W-NORMAL, normal successful completion Error-End: 1 error detected ------------------------------ Rejected message ------------------------------ Received: from ludens.elte.hu by dtalk.inf.elte.hu (MX V4.2 VAX) with SMTP; Tue, 04 Feb 1997 20:02:54 CET Received: by ludens.elte.hu (MX V4.2 VAX) id 5; Tue, 04 Feb 1997 20:01:59 +0100 Sender: maulis@ludens.elte.hu Date: Tue, 04 Feb 1997 20:01:59 +0100 From: Adam To: MAULIS@DTALK.INF.ELTE.HU Message-ID: <009AF65E.BE55E520.5@ludens.elte.hu> test ============================================================================== Problem description end. I think is not a TCP/IP specific problem. If you have an solution for my problem, please send a mail this list or me. Thanks Adam Maulis Maulis@dtalk.inf.elte.hu http://dtalk.inf.elte.hu/~maulis/ PS: Sorry for my very wrong English. ================================================================================ Archive-Date: Thu, 20 Feb 1997 04:40:09 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 10:38:54 GMT From: Andy Harper - KCL Systems manager Reply-To: MX-List@MadGoat.com To: MX-LIST@MADGOAT.COM CC: A.HARPER@kcl.ac.uk Message-ID: <009B02A2.BB8AF240.425@alder.cc.kcl.ac.uk> Subject: RE: MX LOCAL dying Since installing the latest MX_LOCAL patch for MX 4.2, I too have been experiencing a large number of MX LOCAL crashes. Before the patch, this happened only infrequently. This is with openVMS 6.2 on both VAX 4100A and AlphaServer 2100/4 Here's an example from the MX_LOCAL_node_n.LOG file: %MX-F-MEMALLOC, error allocating memory from zone TXTZONE -LIB-F-INSVIRMEM, insufficient virtual memory I shall turn on full debugging and see what comes to light; in the meantime, I might go back to the previous image and see if that makes a difference. Regards, Andy Harper Kings College London ================================================================================ Archive-Date: Thu, 20 Feb 1997 04:59:24 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 11:58:52 CET-DST From: "Rok Vidmar, NUK Ljubljana" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B02AD.E77E8D20.1@NUK.Uni-Lj.Si> Subject: RE: priority headers > MX does not add an "X-Priority:" or a "Precendence:" header (at least, > not yet). Someone's software somewhere must be adding it if it's not > there. Or else they're being passed through MX MLF, which is why I > define my lists with /STRIP=(RECEIVED,OTHER). While we are at the headers: is it possible to exclude MIME headers from the OTHER class so they can be passed to PC mailers and let the other stuff get filtered out? Regards, Rok Vidmar Internet: rok.vidmar@uni-lj.si National and University Library Phone: +386 61 125 4218 Turjaska 1, 1000 Ljubljana Fax: +386 61 125 5007 Slovenia ================================================================================ Archive-Date: Thu, 20 Feb 1997 05:01:14 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 03:00:58 PST From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009B0262.C2D23BC0.1@sacto.mp.usbr.gov> Subject: RE: 2nd repost: A minor forwarding error in MX4.2 (VMS6.2) > From: MX%"MX-List@MadGoat.com" 19-FEB-1997 23:05:14.46 > Subj: 2nd repost: A minor forwarding error in MX4.2 (VMS6.2) > Hello, > > Has anybody read this message? I posted it on the 4-FEB-1997. > > > > Hello, > > I found a minor forwarding error in MX4.2. > > This error exists in MicroVax 3100 with VMS 6.2 UCX 4.0 > (total of 900 users, average 10 interactive, 20 Mailing lists) > (dtalk.inf.elte.hu) > > and VAX6520-VAX9410 cluster with VMS6.2 and UCX 4.0 - MultiNet 4.0 > (total of 6500 users, average 110 interactive, ANU NEWS, 30 Mailing lists) > (ludens.elte.hu) > > Problem description: > > 1, > define /system/exec MAIL$INTERNET_TRANSPORT MX > (MAIL$TRANSPORT_MX is defined, or not; > MAIL$TRANSPORT_SMTP is defined or not) > > MAIL> m > To: user@host.domain > > works well. > > MAIL> set forward "MX%""user@host.domain""" > > works well. > > MAIL> set forward user@host.domain > > works, but not well... > > In this case the local, or decnet mail says: > %MAIL-E-USERSPEC, invalid user specification '@host.domain' > > But the ingoing Internet message is forwarding, but > something (I thing the VMSMAIL) inserted an empty line to smtp header :-( > > This empy line prevents forwaarding loop detecting, and > prevents understanding MIME attachments, etc. > > 2., > > Nor MAIL$INTERNET_TRANSPORT neither MAIL$TRANSPORT_SMTP neither > SMTP_MAILSHR are defined in LNM$SYSTEM_TABLE. > > In sylogin.com there is: > define MAIL$INTERNET_TRANSPORT MX > or > define MAIL$TRANSPORT_SMTP MX_MAILSHR > or > define SMTP_MAILSHR MX_MAILSHR > > MAIL> m > To: user@host.domain > > works well. > > MAIL> set forward "MX%""user@host.domain" > > works well. > > MAIL> set forward user@host.domain > > is betther then the previous, because doesn't work:-) > > The local or decnet mail says > %MAIL-E-USERSPEC, invalid user specification '@host.domain' > > > The ingoing Internet message is not forwarding. > (I posted a message from maulis@ludens.elte.hu to maulis@dtalk.elte.hu > and maulis@dtalk.inf.elte.hu had a forwarding address: > MAULIS@LUDENS.ELTE.HU ) > > ============================================================================= > > From: MX%"Postmaster@dtalk.inf.elte.hu" > To: MX%"maulis@ludens.elte.hu" > CC: > Subj: LOCAL delivery error > > Return-Path: > Received: from dtalk.inf.elte.hu by ludens.elte.hu (MX V4.2 VAX) with SMTP; > Tue, 04 Feb 1997 20:02:02 +0100 > Date: Tue, 04 Feb 1997 20:02:54 CET > From: Local delivery agent > To: > Subject: LOCAL delivery error > X-Report-Type: Nondelivery; boundary="> Error description:" > > Note: this message was generated automatically. > > An error was detected while processing the enclosed message. A list of > the affected recipients follows. This list is in a special format that > allows software like LISTSERV to automatically take action on incorrect > addresses; you can safely ignore the numeric codes. > > --> Error description: > Error-For: "maulis@ludens.elte.hu"@dtalk.inf.elte.hu > Error-Code: 2 > Error-Text: Error in delivery to user MAULIS@LUDENS.ELTE.HU > %MAIL-E-ERRACTRNS, error activating transport SMTP > %LIB-E-ACTIMAGE, error activating image DTALK$DKA200:[SYS0.SYSCOMMON > .][SYSLIB]SMTP_MAILSHR.EXE; > -RMS-E-FNF, file not found > -ECWP-W-NORMAL, normal successful completion > > Error-End: 1 error detected > > ------------------------------ Rejected message ------------------------------ > Received: from ludens.elte.hu by dtalk.inf.elte.hu (MX V4.2 VAX) with SMTP; Tue, > 04 Feb 1997 20:02:54 CET > Received: by ludens.elte.hu (MX V4.2 VAX) id 5; Tue, 04 Feb 1997 20:01:59 +0100 > Sender: maulis@ludens.elte.hu > Date: Tue, 04 Feb 1997 20:01:59 +0100 > From: Adam > To: MAULIS@DTALK.INF.ELTE.HU > Message-ID: <009AF65E.BE55E520.5@ludens.elte.hu> > > test > ============================================================================== > > > > Problem description end. > > I think is not a TCP/IP specific problem. > If you have an solution for my problem, please send a mail this list or me. > > > Thanks > Adam Maulis > > Maulis@dtalk.inf.elte.hu http://dtalk.inf.elte.hu/~maulis/ > > PS: > Sorry for my very wrong English. > > This is the way VMSMAIL works. It hits the '@' and that stops the normal parsing process. You need to set up forwarding in a method that you described above as working - I usually use: MAIL> SET FORWARD mx%"""user@host.domain""" Good luck, -HWM ================================================================================ Archive-Date: Thu, 20 Feb 1997 05:43:47 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 12:43:25 CET From: Adam Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B02B4.20710BC0.17@dtalk.inf.elte.hu> Subject: RE: 2nd repost: A minor forwarding error in MX4.2 (VMS6.2) Hi! I want that SET FORWARD user@host.domain and SET FORWARD "MX%""user@host.domain"" works some. I cannot tell the correct set forward syntax to every 6500 users. A patch of MX that does it would be helpfull for me. Good Luck, Adam Maulis ================================================================================ Archive-Date: Thu, 20 Feb 1997 07:18:22 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 05:18:05 PST From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009B0275.EA571BEE.52@sacto.mp.usbr.gov> Subject: RE: 2nd repost: A minor forwarding error in MX4.2 (VMS6.2) > From: MX%"MX-List@MadGoat.com" 20-FEB-1997 04:11:31.47 > Subj: RE: 2nd repost: A minor forwarding error in MX4.2 (VMS6.2) > Hi! > > I want that SET FORWARD user@host.domain > and SET FORWARD "MX%""user@host.domain"" works some. > > I cannot tell the correct set forward syntax to every 6500 users. > > A patch of MX that does it would be helpfull for me. > > > Good Luck, > Adam Maulis It IS NOT an MX issue - it is a VMSMAIL issue. VMSMAIL is blowing you out of the water before you ever hit the MX transport. As far as resetting the the correct forwarding for 6500 users, yeas you can. You can dump the VMSMAIL Profile data to an ASCII file, massage it with editor and turn it into a command procedure to be excuted by VMS Mail. -HWM ================================================================================ Archive-Date: Thu, 20 Feb 1997 07:22:29 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 07:22:23 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B0287.47C55F49.27@ALPHA.WKU.EDU> Subject: RE: MX LOCAL dying Andy Harper - KCL Systems manager writes: > >I shall turn on full debugging and see what comes to light; in the meantime, I >might go back to the previous image and see if that makes a difference. > Can you also try running MX_LOCAL interactively to get the full dump? And are you running the VMS Mail patch that lets you omit MX%? I've tried and tried, and I cannot duplicate this problem. Any additional info from you would be appreciated. Thanks, Andy. Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Thu, 20 Feb 1997 07:41:25 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 05:41:09 PST From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009B0279.2325ED4E.14@sacto.mp.usbr.gov> Subject: Re: MX Local dying > From: MX%"MX-List@MadGoat.com" 19-FEB-1997 22:40:36.55 > Subj: Re: MX Local dying Dan, > In article <1997Feb11.104106.1@aspen>, welchb@woods.uml.edu (Brendan Welch, W1LPG) writes: > > We have been following the saga of the dying MX local > >for some time, because we are badly affected too. Now, I have come upon > >something, which I dare to post out of "intelligent ignorance". It > >may be very right, or very wrong. > > > > For reasons other than the "dying" problem, I decided to look > >at MAILUAF_PROFILE.DATA, using what is probably an old version of a > >somewhat popular tool, MAILUAF.COM . When using its command LIST, in > >order to see forwarding addresses, it processed about 100 names, and > >then aborted with "illegal item code 14 found in record". > > > > Could it be that this contamination of MAILUAF-PROFILE.DATA > >is causing the problem? I note by SHOW DEV/FILE that the above file > >is in use both by individual users (no trouble ever noticed) and > >by various processes known to MCP STAT . > > See if: > > $ MAIL > MAIL> SHOW FORWARD/USER=* > > indicates any problems, too. > > > And, while I have your attention, how do I fix the contamination? > > The file is a normal RMS indexed file. You could use CONVERT to save > all but the unreadable records. > > >It is aggravating that, for starters, the file is locked, so I cannot > >even make a copy of it to practice on. > > $ BACKUP/IGNORE=INTERLOCK/LOG infile outfile > Maybe the custom MX on the Cisco/TGV systems is a litle different, but I had to shut down MX Local before I could even do this... > >Plus, I am terrible on RMS, but > >am willing to do binary editting, or do a rewrite of MAILUAF.COM to > >catch and fix the bad record. > > Another thing which I though might help is a template which Hein > >posted for cleaning up SYSUAF.DAT . Since the files are perhaps similar, > >would that approach work (it uses CONVERT)? > > Try something like: > > $ BACKUP/IGNORE=INTERLOCK/LOG SYS$SYSTEM:VMSMAIL_PROFILE.DATA SYS$LOGIN: > $ SET DEFAULT SYS$LOGIN: > $ ANALYZE/RMS/FDL VMSMAIL_PROFILE.DATA > (which generates a VMSMAIL_PROFILE.FDL file, which is plain text) > > $ CONVERT/FDL=VMSMAIL_PROFILE.FDL/EXCEPT=VMSMAIL_PROFILE.EXC - > VMSMAIL_PROFILE.DATA VMSMAIL_PROFILE.NEW > (which should convert the file and skip the bad records) > > -Dan Wing > dwing@cisco.com > cisco Systems, Inc. > -------------------------------------------------------------------------------- > Return-Path: > Received: from axp1.wku.edu by sacusr.mp.usbr.gov (MX V4.2A VAX) with SMTP; > Wed, 19 Feb 1997 22:40:29 PST > X-ListName: Message Exchange Discussion List > Warnings-To: <> > Errors-To: owner-mx-list@wku.edu > Sender: owner-mx-list@wku.edu > From: dwing@cisco.com (Dan Wing) > X-Newsgroups: vmsnet.mail.mx > Subject: Re: MX Local dying > Date: 19 Feb 1997 21:17:03 GMT > Organization: cisco Systems, Inc. > Lines: 55 > Message-ID: <5efqkf$ka2@cronkite.cisco.com> > Reply-To: MX-List@MadGoat.com > To: MX-List@WKUVX1.WKU.EDU > X-Gateway-Source-Info: USENET ================================================================================ Archive-Date: Thu, 20 Feb 1997 08:09:38 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 14:08:06 GMT From: Andy Harper - KCL Systems manager Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: A.HARPER@kcl.ac.uk Message-ID: <009B02BF.F53CAAC0.2039@alder.cc.kcl.ac.uk> Subject: RE: MX LOCAL dying >Can you also try running MX_LOCAL interactively to get the full dump? >And are you running the VMS Mail patch that lets you omit MX%? I am running VMS 6.2, which implicitly allows the omission of MX%, on all systems; the logical name MAIL$INTERNET_TRANSPORT is defined to "MX" >I've tried and tried, and I cannot duplicate this problem. Any >additional info from you would be appreciated. I have set up an interactive MX_LOCAL which I'll try to leave running. I'll pass on any debugging info. As a slight aside, could MX 4.3 include something to allow an interactive run of the server to print diagnostics to the screen? It would be quite helpful in cases like this. It may well be a peculiar mail message in the queue. And, of course, now that I've noted it to the list, MX LOCAL isn't falling down any more! Maybe it's more prevalent overnight because we get a huge flood of info-vax and other lists then, whereas there's not a lot happening during the day (relatively speaking..) Regards, Andy Harper Kings College London ================================================================================ Archive-Date: Thu, 20 Feb 1997 08:16:53 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 08:16:40 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B028E.DCA81739.12@ALPHA.WKU.EDU> Subject: RE: MX LOCAL dying Andy Harper - KCL Systems manager writes: > >>I've tried and tried, and I cannot duplicate this problem. Any >>additional info from you would be appreciated. > > I have set up an interactive MX_LOCAL which I'll try to leave running. Since posting that a few minutes ago, I *have* just now duplicated the problem on a MicroVAX II running VMS V5.4. Callable mail isn't handling the forward very well. I'm trying to debug it now.... > I'll pass on any debugging info. As a slight aside, could MX 4.3 include > something to allow an interactive run of the server to print diagnostics to > the screen? It would be quite helpful in cases like this. > You can define MX_LOCAL_LOG to be TT: to get the debug log files displayed on your screen instead. Still, more information would be useful. I'll see what I can do. Thanks! Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Thu, 20 Feb 1997 08:27:56 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 09:27:00 EST From: John Hasstedt Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B0298.B069C3B4.28@nuclear.physics.sunysb.edu> Subject: RE: 2nd repost: A minor forwarding error in MX4.2 (VMS6.2) > From: "Henry W. Miller" > Subject: RE: 2nd repost: A minor forwarding error in MX4.2 (VMS6.2) > > > I want that SET FORWARD user@host.domain > > and SET FORWARD "MX%""user@host.domain"" works some. > > > > I cannot tell the correct set forward syntax to every 6500 users. > > > > A patch of MX that does it would be helpfull for me. > > It IS NOT an MX issue - it is a VMSMAIL issue. VMSMAIL is > blowing you out of the water before you ever hit the MX transport. > > As far as resetting the the correct forwarding for 6500 users, > yeas you can. You can dump the VMSMAIL Profile data to an ASCII file, > massage it with editor and turn it into a command procedure to be > excuted by VMS Mail. Somewhat easier then dumping the file is to do: $ DEFINE SYS$OUTPUT Z.COM $ MAIL MAIL> SHOW FORWARD/USER=* MAIL> EXIT $ DEASSIGN SYS$OUTPUT then edit Z.COM to fix the forwarding. One thing I don't understand is that when I do DEFINE/USER before the MAIL command, I get an output file with a blank line for each person with a forwarding address instead of the forwarding information. So you have to do the DEFINE and DEASSIGN. ========================================================================== John Hasstedt Internet: John.Hasstedt@sunysb.edu Physics Department Phone: 516-632-8169 or 516-632-8153 State University of New York FAX: 516-632-8573 Stony Brook, NY 11794-3800 ================================================================================ Archive-Date: Thu, 20 Feb 1997 09:22:42 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 09:53:42 EST From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: mhitch@msu.oscs.montana.edu Message-ID: <009B029C.6B18E8E0.14@swdev.si.com> Subject: RE: New MX_LOCAL patch available Michael L. Hitch (mhitch@msu.oscs.montana.edu) writes: > I've run into this several times now, because we have been allowing users >to change their account names. When a username gets changes, a forwarding >entry for the old username is created that forwards to the new username. >If that new username is later forwarded to an MX% address, the MX Local >process will die when mail delivery is attempted to the old username. That's not the problem, I would say. _All_ of our addresses are like that and our MX does not fail and has not since MX V3.2. Here's our setup: User SMITH on VMS has mail forwarded to SMITH_JOHN. SMITH_JOHN in turn is forwarded to MX%"smith_john@smtpgwy". Each platform we use (PCs, Macs, Unix, and VMS) has consistent Email address forms. The PCs and Macs use cc:Mail, which has addresses of the form "lastname, firstname" in its directory. In order to make the Unix and VMS side of things look as close to that as possible, the cc:Mail box generates an alias table that gets mailed to the Unix and VMS postmasters (the latter of whom is I) that converts the names to "lastname_firstname". A batch job adds these to VMSMAIL_PROFILE as forwarding addresses to the cc:Mail/SMTP gateway, to the appropriate Unix machine, or to a VMS Mail address containing an underscore as a leading character (so that a forwarding loop will never occur). Then VMS addresses are forwarded to the "lastname_firstname" alias. Here's an example. ALIAS file from cc:Mail: aarons_dave: aarons_dave@smtpgwy <- cc:Mail gateway system # Aarons, Dave # UK BAS 282-3434 .... anderson_jerry: anderson@donald <- Unix system # Anderson, Jerry # US GR 241-8380 .... getsinger_tracy: getsinger@fp-vax4500 <- VMS system reachable by SMTP # Getsinger, Tracy # US FP (201) 514-4216 .... kyser_buddy: kyser@swdev <- Local system # Kyser, Buddy # US GR 241-7629 ... annear_deborah: dja0118%orcas.dnet@swdev <- VMS system reachable by DECnet # Annear, Deborah # US Boeing These ate translated to SET FORWARD commands that look like this: set forward/user=aarons_dave mx%"""""" set forward/user=anderson_jerry mx%"""""" set forward/user=getsinger_tracy mx%"""""" set forward/user=kyser_buddy _kyser set forward/user=annear_deborah mx%"""""" and, finally, for the local names, we have: MAIL> sho forw/user=kyser KYSER has mail forwarded to KYSER_BUDDY This way, everyone's mail sent to whatever their proper mailbox platform by using pretty much the same address on every platform. I guess this is a long-winded way to say there must be something more to the picture than the forwardings. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman_brian@si.com Smiths Industries, Inc. | tillman@swdev.si.com 4141 Eastern Ave., MS239 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 20 Feb 1997 09:33:18 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 09:33:06 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B0299.8A1C2CD1.1@ALPHA.WKU.EDU> Subject: RE: MX LOCAL dying Andy Harper - KCL Systems manager writes: > > It may well be a peculiar mail message in the queue. And, of course, now that > I've noted it to the list, MX LOCAL isn't falling down any more! Maybe it's > more prevalent overnight because we get a huge flood of info-vax and other > lists then, whereas there's not a lot happening during the day (relatively > speaking..) > OK, I was able to duplicate it using the information Michael Hitch sent in: a user forwarded to another user forwarded to MX%. I don't know why, but callable mail (or MX_MAILSHR) is generating an access violation that's being signalled. And for some reason, after MX Local's error handler has written the error to the error message queue, it gets signalled again by callable mail---and again and again and again and eventually, MX Local runs out of memory for the error message text queue. So the problem is two-fold: why is that error occurring, and why it is signalled over and over and over and over. I hope to have more information later today. Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Thu, 20 Feb 1997 09:52:39 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 10:40:05 EST From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: maulis@dtalk.inf.elte.hu Message-ID: <009B02A2.E59ED1A0.25@swdev.si.com> Subject: RE: 2nd repost: A minor forwarding error in MX4.2 (VMS6.2) Adam Maulis (maulis@dtalk.inf.elte.hu) writes: >I want that SET FORWARD user@host.domain >and SET FORWARD "MX%""user@host.domain"" works some. In OpenVMS V7.1, SET FORWARD has been corrected so that the extra quotes are unnecessary. I.e., the correct SET FORWARD command will be: MAIL> set forward mx%"user@host.domain" Asking for any change in how SET FORWARD works in _not_ an MX issue, but a VMS Mail issue. Ask Digital, not Hunter. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman_brian@si.com Smiths Industries, Inc. | tillman@swdev.si.com 4141 Eastern Ave., MS239 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 20 Feb 1997 09:58:07 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 10:49:13 EST From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B02A4.2C489CC0.7@swdev.si.com> Subject: RE: 2nd repost: A minor forwarding error in MX4.2 (VMS6.2) John Hasstedt (John.Hasstedt@sunysb.edu) writes: >Somewhat easier then dumping the file is to do: > > $ DEFINE SYS$OUTPUT Z.COM > $ MAIL > MAIL> SHOW FORWARD/USER=* > MAIL> EXIT > $ DEASSIGN SYS$OUTPUT > >then edit Z.COM to fix the forwarding. Alternatively, one could put $ set process/priv=sysnam $ mail show forward/user=* $ exit in file called SHOWFORWARD.COM and $ submit/noprint/log=setforward.com showforward and edit the resulting file. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman_brian@si.com Smiths Industries, Inc. | tillman@swdev.si.com 4141 Eastern Ave., MS239 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 20 Feb 1997 11:12:18 EST Sender: owner-mx-list@wku.edu From: Dave Morriss Resent-Message-ID: <199702201711.RAA02130@muttley.cen.hw.ac.uk> Message-ID: <199702201711.RAA02130@muttley.cen.hw.ac.uk> To: MX-List@madgoat.com Reply-To: MX-List@MadGoat.com References: <009B0298.B069C3B4.28@nuclear.physics.sunysb.edu> Subject: Re: 2nd repost: A minor forwarding error in MX4.2 (VMS6.2) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 20 Feb 1997 17:07:07 +0000 Resent-To: MX-List@madgoat.com Resent-Date: Thu, 20 Feb 1997 17:11:49 +0000 Resent-From: "David J. Morriss" On Thu, 20 Feb 1997 09:27:00 EST John Hasstedt wrote: > Somewhat easier then dumping the file is to do: > > $ DEFINE SYS$OUTPUT Z.COM > $ MAIL > MAIL> SHOW FORWARD/USER=* > MAIL> EXIT > $ DEASSIGN SYS$OUTPUT > > then edit Z.COM to fix the forwarding. > > One thing I don't understand is that when I do DEFINE/USER before the MAIL > command, I get an output file with a blank line for each person with a > forwarding address instead of the forwarding information. So you have > to do the DEFINE and DEASSIGN. I struggled with the problem of incorrect forwarding addresses a few months back, although in our case a creeping wave of disk corruptions was regularly mangling the VMSMAIL_PROFILE.DATA file, thereby compounding the problem greatly. I particularly wanted to be able to spot the bad addresses as soon as possible after they occurred (where I defined "bad" as syntactically incorrect or just plain daft). What I came up with was a housekeeping tool which I run nightly to read the file, extract the forwarding addresses and perform some analysis, looking for badly specified addresses. When I get the report I use another command procedure to fix it up (using SET FORWARD/USER=x) which also sends a standard message to the user to tell them what was wrong. I had hoped to make the code clever enough to fix some of the problems itself, but never got round to it. If any of this is of any use to anyone, I'd be happy to make it available. It's written in DCL and uses gawk to analyse the ASCII addresses. I could post it here if that's acceptable. -- David Morriss, Computing Services, | Tel: +44 (0)131 451 3262 (DDI) Heriot-Watt University, Edinburgh, EH14 4AS, | FAX: +44 (0)131 451 3261 Scotland, UK | D.J.Morriss@hw.ac.uk ================================================================================ Archive-Date: Thu, 20 Feb 1997 18:48:26 EST Sender: owner-mx-list@wku.edu Date: Thu, 20 Feb 1997 18:46:55 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@LISTS.WKU.EDU Message-ID: <009B02E6.E846FB3D.15@ALPHA.WKU.EDU> Subject: New MX_LOCAL images OK, I've tracked down the problem and partially corrected it, I think. The problem is two-fold: 1. MX_LOCAL was dying because the callable MAIL routines were signalling an access violation, which called MX's error handler, which did its thing and returned SS$_CONTINUE to callable MAIL, which proceeded to signal another access violation, calling MX's error handler, ad infinitum until MX_LOCAL ran out of memory trying to add text to the error text queue. I've modified MX_LOCAL so that its error handler unwinds the stack after an access violation, which means control is not returned to callable MAIL, and the loop is avoided. Errors are now returned to the sender with "access violation" in the error text. 2. This problem occurs on mail that is received with multiple addresses on the From: line going to an account that is forwarded through MX. The access violation described above is occurring when callable MAIL calls MX_MAILSHR and it generates the access violation because there are multiple "sender" addresses (the multiple addresses on the From: line). I've applied the fix to "1" and am still trying to figure out what to do for "2". In the meantime, new MX_LOCAL images can be found on FTP.MADGOAT.COM (or FTP.WKU.EDU) in [.MX.MX042.PATCH]. I'm sure you'll let me know if it keeps dying.... ;-) But I don't think it will anymore. Still, the messages described in 2 will bounce until I can figure out how to handle them in MX_MAILSHR. Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Fri, 21 Feb 1997 15:08:06 EST Sender: owner-mx-list@wku.edu Message-ID: <3.0.32.19970221151026.0090d250@Bible.acu.edu> Date: Fri, 21 Feb 1997 15:10:29 -0600 To: MX-List@MadGoat.com From: Tom Dolan Reply-To: MX-List@MadGoat.com Subject: owner-cell-church MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" How does the owner-listname@host.domain work? For example when I send a message to owner-olm@bible.acu.edu my message is forwarded to the address defined as the owner of the list. However when I send a message to owner-cell-church@Bible.acu.edu, the message is not forwarded to the addresses defined as owner. The only difference is that olm has one defined owner address and cell-church has four defined co-owner addresses. The cell-church owners want potential subscribers to send an application (available on the web) to "owner-cell-church@bible.acu.edu" for processing - is this possible? Tom Dolan Dolan@Bible.acu.edu 915.674.3706 202 Bible Building Systems Manager ACU Box 29454 College of Biblical and Family Studies Abilene, TX 79699 Abilene Christian University FAX 915.674.3776 ================================================================================ Archive-Date: Fri, 21 Feb 1997 15:10:53 EST Sender: owner-mx-list@wku.edu From: Ted Corning Reply-To: MX-List@MadGoat.com Subject: Delivery Error, Event Flags Date: 21 Feb 1997 14:04:22 GMT Message-ID: <5eka16$bna@hydra.umb.edu> To: MX-List@WKUVX1.WKU.EDU Hi, Over the past week or so, I've started seeing mail not being delivered with the following error: --> Error description: Error-For: sysmgr@umbsky.cc.umb.edu Error-Code: 2 Error-Text: Error in delivery to user SYSMGR illegal event flag cluster Error-End: 1 error detected Since my machines have been severely overloaded, I suspect it may be a VMS resource problem, but I am at a loss as to where to start looking. Any thoughts? Thanks! Ted -- Ted Corning UMass/Boston Computing Services kismet@trantor.cc.umb.edu ================================================================================ Archive-Date: Fri, 21 Feb 1997 17:58:53 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: Re: MX local dying (maybe even important!) Date: 21 Feb 97 11:58:42 -0500 Message-ID: <1997Feb21.115842.1@aspen> To: MX-List@WKUVX1.WKU.EDU There are 9 ways in which I played around with modifying a contaminated vmsmail_profile.data. I would probably attack it differently if I knew then what I know now. 1) MAILUAF.COM, an older version which I had on hand; it is useful. 2) my own modification to the above, so that when LISTing, a code of 14 goes to a newly created line called FL14: which will print out that it went there, instead of bombing out. 3) MAILUAF_V5.COM, probably more correct, but has less commands than the above 4) MAILUAF.EXE, which I got from anonymous FTP.SPC.EDU somewhere along the line of events; but the help file would not install correctly, so I just printed out mailuaf.hlp 5) VMS, using $MAIL from a privileged account. The commands can only do a few management things (see Mail>help mail_ ) like show forward/user=xxx set forward/user=xxx yyy !if xxx is not in sysuaf, the name will still get created in mail, also true in some methods above. N.B. This seems to be a way of letting an employee who quits his job still get his old mail forwarded to the new job, without keeping his old account active. I am surprised that this is the only mail management tool which DEC supplies, and how crippled it is compared to the above ones. (I did not yet read the release notes.) 6) BECOME, which gives you access as if you had logged in with a user's username and password (N.B. omits his login.com). This lets you see mail in the way the user really sees it; Mail>show all Mail>set ... (One problem I keep running into is that I read people's mail by accident by innocently hitting RETURN, thinking I am continuing the output of DIR) 7) MCP commands get used a lot, especially >que stat !are we overloaded? >stat !has any of our 22 processes died? also >que synch/reset/log >show que !works (?), but not explained in help >que show/br 8) $set def [.mx.queue] $dir/tot [...] with maybe /sin to see if the count more or less is consistent with "que stat". 9) CONVERT, as explained in a Dan Wing posting. I think that to be safe, this would require shutting off all users and mail processes. (?) Using the above tools (I simplify) I did things like --- get a list of all names in mail --- get a list of all names which are forwarding --- get a list of all names which previously caused MAILUAF to bomb out; maybe not useful at all --- get a list of all "fictitious names"; they may be there on purpose (old employee forwarding to new job; a commonly mispelled name forwarded to the correct account); they may be there because of errors in ancient history of account removal; they may be misspellings. --- get a list of all users whose MAIL.MAI is not in the subdirectory where you might most expect it to be --- remove all obvious mis-forwardings --- check all names against AUTHORIZE, and remove most fictitious names --- try to clean up things, in some case by simply removing the name (but first make sure you know ALL their mail settings) and then adding it back. WAS IT ALL WORTH IT? Yes, probably. There are "some indications" that our problems are disappearing. We have temporarily turned off our jobs (scheduled every 5 minutes), and within a few hours of limited experience, no MX process has died. So it is (entirely) possible that this whole bugaboo of MX Local dying has indeed been caused by a contaminated mail file. But, if I may editorialize, I think (suspect) it is a good thing, for starters, that every manager use one of the MAILUAF's to get a list of forwarding addresses, and remove those which are obviously bad. And I mean this in a VMS mail sense, regardless of MX or any other system. I learned a lot about users (who need training) and saw some crazy forwardings, which regardless of MX are causing trouble. E.g. if you see a forwarding address of OFF, it is because the user said "set forward off" instead of "set noforward". Look for circular rat-races, self-forwarding, or for uses of a long form "set forward jones@woods.uml.edu" instead of just "set forw jones" since we are already on woods. Less common, a fictious name becomes a real name when a real name is re-issued in sysuaf; forwarding is now wrong (?). Thus, when an old user is removed, delete all of his files (after backup), remove him from mail, and (a human weakness in a computerized system) make note of any forwarding, when it should expire, and disallow recreation of that name. P.S.: Generally speaking, and especially when using BECOME, have a couple of screen sessions going, or several separate terminals running, maybe with an attached printer. Because of our situation here, I can get interrupted by phone calls and lots of other things, right in the middle of being logged in as a mere user, on a single terminal; then when I come back I think I am my old self (privileged). or start sending email, or get timed out by our WATCHER. If you get mail.mai not found, or errors from dir/fold, send mail to the user himself, to create mail.mai. =========================================================================== ADDENDUM (several hours later in the day): We can add another useful tool: 10) monitor proc/topcpu !on any pertinent nodes In our case it showed that about 75% of the cpu activity was being devoted to various MX processes (on one particular node). I regret to say that the count (mcp que stat) still crept higher, near 900. And mcp stat, when repeated an hour later, showed that almost all the activity is in the SMTP's, and they were still processing the very same messages. So I presumed that some "race" condition was in effect, and decided to shutdown the MX system and restart. As has happened in the past, you just can't kill it. MCP SHUTDOWN/CLUSTER even when repeated and repeated left some processes extant, finally requiring $stop/id=nnnnnnnn. $@sys$startup:mx_startup was performed on one node; not much improvement, if any. Then, when performed on the other, activity started (and I received some mail I personally had been awaiting). HOWEVER, now for the first time in many hours, an SMTP process died. Thus, cleaning up the file vmsmail_profile.data did not infallibly cure the overall problem. =========================================================================== another ADDENDUM (the next day): We have been having tragic mx mail difficulties. The mail queue seems to feed back onto itself. With the kind help of Hunter Goatley, we have started a brand new message que, and will try to salvage 2000+ messages which would otherwise be lost forever. (And, to make things more difficult, our news feed has been down for several days. But, if you can read this, the news is working again.) However, in the spirit of this posting, at least it SEEMS that everything I said far above is true; I HOPE there is no relationship between the problems, and that it still is a good idea to fix up vmsmail_profile.data -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Fri, 21 Feb 1997 19:30:36 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: RE: MX LOCAL dying (important(?)) Date: 21 Feb 97 12:35:01 -0500 Message-ID: <1997Feb21.123501.1@aspen> To: MX-List@WKUVX1.WKU.EDU There are 9 ways in which I played around with modifying a contaminated vmsmail_profile.data. I would probably attack it differently if I knew then what I know now. 1) MAILUAF.COM, an older version which I had on hand; it is useful. 2) my own modification to the above, so that when LISTing, a code of 14 goes to a newly created line called FL14: which will print out that it went there, instead of bombing out. 3) MAILUAF_V5.COM, probably more correct, but has less commands than the above 4) MAILUAF.EXE, which I got from anonymous FTP.SPC.EDU somewhere along the line of events; but the help file would not install correctly, so I just printed out mailuaf.hlp 5) VMS, using $MAIL from a privileged account. The commands can only do a few management things (see Mail>help mail_ ) like show forward/user=xxx set forward/user=xxx yyy !if xxx is not in sysuaf, the name will still get created in mail, also true in some methods above. N.B. This seems to be a way of letting an employee who quits his job still get his old mail forwarded to the new job, without keeping his old account active. I am surprised that this is the only mail management tool which DEC supplies, and how crippled it is compared to the above ones. (I did not yet read the release notes.) 6) BECOME, which gives you access as if you had logged in with a user's username and password (N.B. omits his login.com). This lets you see mail in the way the user really sees it; Mail>show all Mail>set ... (One problem I keep running into is that I read people's mail by accident by innocently hitting RETURN, thinking I am continuing the output of DIR) 7) MCP commands get used a lot, especially >que stat !are we overloaded? >stat !has any of our 22 processes died? also >que synch/reset/log >show que !works (?), but not explained in help >que show/br 8) $set def [.mx.queue] $dir/tot [...] with maybe /sin to see if the count more or less is consistent with "que stat". 9) CONVERT, as explained in a Dan Wing posting. I think that to be safe, this would require shutting off all users and mail processes. (?) Using the above tools (I simplify) I did things like --- get a list of all names in mail --- get a list of all names which are forwarding --- get a list of all names which previously caused MAILUAF to bomb out; maybe not useful at all --- get a list of all "fictitious names"; they may be there on purpose (old employee forwarding to new job; a commonly mispelled name forwarded to the correct account); they may be there because of errors in ancient history of account removal; they may be misspellings. --- get a list of all users whose MAIL.MAI is not in the subdirectory where you might most expect it to be --- remove all obvious mis-forwardings --- check all names against AUTHORIZE, and remove most fictitious names --- try to clean up things, in some case by simply removing the name (but first make sure you know ALL their mail settings) and then adding it back. WAS IT ALL WORTH IT? Yes, probably. There are "some indications" that our problems are disappearing. We have temporarily turned off our jobs (scheduled every 5 minutes), and within a few hours of limited experience, no MX process has died. So it is (entirely) possible that this whole bugaboo of MX Local dying has indeed been caused by a contaminated mail file. But, if I may editorialize, I think (suspect) it is a good thing, for starters, that every manager use Mail> show forward /user=* to get a list of forwarding addresses, and remove those which are obviously bad. And I mean this in a VMS mail sense, regardless of MX or any other system. I learned a lot about users (who need training) and saw some crazy forwardings, which regardless of MX are causing trouble. E.g. if you see a forwarding address of OFF, it is because the user said "set forward off" instead of "set noforward". Look for circular rat-races, self-forwarding, or for uses of a long form "set forward jones@woods.uml.edu" instead of just "set forw jones" since we are already on woods. Less common, a fictious name becomes a real name when a real name is re-issued in sysuaf; forwarding is now wrong (?). Thus, when an old user is removed, delete all of his files (after backup), remove him from mail, and (a human weakness in a computerized system) make note of any forwarding, when it should expire, and disallow recreation of that name. P.S.: Generally speaking, and especially when using BECOME, have a couple of screen sessions going, or several separate terminals running, maybe with an attached printer. Because of our situation here, I can get interrupted by phone calls and lots of other things, right in the middle of being logged in as a mere user, on a single terminal; then when I come back I think I am my old self (privileged). or start sending email, or get timed out by our WATCHER. If you get mail.mai not found, or errors from dir/fold, send mail to the user himself, to create mail.mai. =========================================================================== ADDENDUM (several hours later in the day): We can add another useful tool: 10) monitor proc/topcpu !on any pertinent nodes In our case it showed that about 75% of the cpu activity was being devoted to various MX processes (on one particular node). I regret to say that the count (mcp que stat) still crept higher, near 900. And mcp stat, when repeated an hour later, showed that almost all the activity is in the SMTP's, and they were still processing the very same messages. So I presumed that some "race" condition was in effect, and decided to shutdown the MX system and restart. As has happened in the past, you just can't kill it. MCP SHUTDOWN/CLUSTER even when repeated and repeated left some processes extant, finally requiring $stop/id=nnnnnnnn. $@sys$startup:mx_startup was performed on one node; not much improvement, if any. Then, when performed on the other, activity started (and I received some mail I personally had been awaiting). HOWEVER, now for the first time in many hours, an SMTP process died. Thus, cleaning up the file vmsmail_profile.data did not infallibly cure the overall problem. =========================================================================== another ADDENDUM (several more hours later in the day): We have been having tragic mx mail difficulties. The mail queue seems to feed back onto itself. With the kind help of Hunter Goatley, we have started a brand new message que, and will try to salvage 2000+ messages which would otherwise be lost forever. (And, to make things more difficult, our news feed has been down for several days. But, if you can read this, the news is working again.) However, in the spirit of this posting, at least it SEEMS that everything I said far above is true; I HOPE there is no relationship between the problems, and that it still is a good idea to fix up vmsmail_profile.data -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Sat, 22 Feb 1997 11:24:18 EST Sender: owner-mx-list@wku.edu From: Ted Spencer PhD Reply-To: MX-List@MadGoat.com Content-Type: text/plain To: MX-List@wku.edu Subject: errors-to question MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Date: Sat, 22 Feb 1997 11:24:16 EST We are running MX 4.1 on Vax/VMS 5.5. I have just established a very large list (900 names) with a list owner off- site and defined errors-to to go to her address. And yet I (as postmaster, it appears) get scores of undeliverable mail messages from this list. (Addresses were added from our database, so we anticipated that there would be a number of bouncebacks.) Did I misunderstand the use of the /errors-to definition? Or are there different kinds of errors? Here is a sample of an error message: Date: Sat, 22 Feb 1997 05:58:25 EST From: SMTP delivery agent Subject: SMTP delivery error To: Note: this message was generated automatically. An error was detected while processing the enclosed message. A list of the affected recipients follows. This list is in a special format that allows software like LISTSERV to automatically take action on incorrect addresses; you can safely ignore the numeric codes. --> Error description: Error-For: ZENML@HAL-PC.ORD Error-Code: 2 Error-Text: %MX-F-NOHOST, no such host -Retry count exceeded -(Via HAL-PC.ORD) Error-End: 1 error detected __________________________________________________ Ted Spencer, PhD tspencer@scassn.org Publications Manager & Webmaster 703-750-0533 Speech Communication Assn fax 703-914-9471 http://www.scassn.org ================================================================================ Archive-Date: Sat, 22 Feb 1997 20:52:09 EST Sender: owner-mx-list@wku.edu Date: Sat, 22 Feb 1997 21:35:38 EST From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B0490.CEE70500.13@swdev.si.com> Subject: Re: MX local dying (maybe even important!) In addition to Brendan Welch's list of tools, I offer this one, BAD_MAIL_NAMES.COM: $ if f$mode() .eqs. "BATCH" then set noverify $!------------------------------------------------------------------------------ $! $! Bad_Mail_Names.Com $! $! p1 = NOCOM shows non-existent usernames and forwarding address $! = anything else creates remove-bad-mail-names.com as part of the $! mail message $! $! Examine the VMSMAIL_PROFILE.DAT file and compare it to a list of valid $! VMS users. Report any non-existent users in the VMSMAIL_PROFILE file, $! showing their mail forwarding address, since using VMSMAIL_PROFILE info for $! forwarding _is_ a legitimate use of an entry without a corresponding $! SYSUAF username. $! $! By default, within the mail meassage that "bad-mail-names.com" sends you $! is the command procedure "remove-bad-mail-names.com". Extract it from $! mail and delete the usernames you want to keep. $! $! Lines with site-specific definitions are preceded with a comment line $! containing $!!!! $! $! 18-Jul-1990 Chris Simon $! $! Modifications: $! $! 23-Aug-1990 Bruce Dow $! STS Consultants, Ltd. $! Northbrook, IL $! (708) 272-6520 actual STS office $! (217) 328-7221 home telecommuter $! $! adapted to use the features of VMS 5.* mail, so that the $! mailuaf.com is not required. less site-specific definitions $! needed. $! $! 24-Aug-1990 Bruce Dow $! $! format "non-existent" usernames as remove-bad-mail-names.com. $! $! 22-May-1992 Chris Simon $! FMC Corp., Dallas, TX $! $! fix for variable number of header lines in mailuaf.lis. $!------------------------------------------------------------------------------ $! $ privs_needed = "sysprv" ! or system uic $ ss$_nopriv = 36 $ old_default = f$environment("default") $ old_privs = f$getjpi("", "curpriv") $ if .not. f$priv(privs_needed) then junk = f$setprv(privs_needed) $ if .not. f$priv(privs_needed) .and. f$getjpi("","grp") .gt. f$getsyi("maxsysgroup") then - exit ss$_nopriv $ write_commandfile = p1 .nes. "NOCOM" $ $ on control_y then goto done $ on error then goto done_reset $! set noon $!!!! $ define/nolog bad_mail_complaint_dept "tillman" $ $ set default sys$scratch $ if f$search("mailuaf.dir") .eqs. "" then create/directory/nolog [.mailuaf] $ set default [.mailuaf] $! $! delete previous files $! $ delete/nolog mailuaf.lis.* $ delete/nolog sysuaf.lis.* $ delete/nolog bad_mail_names.*.*/excl=.com $! $! Create input files $! $ mcr authorize list/brief * exit $ define/user sys$output []mailuaf.lis $ mail show forward/all/user=* $! $ open/read mailuaf mailuaf.lis $ open/read sysuaf sysuaf.lis $! $! Read header lines from input files $! $more_header_lines: $ read mailuaf mailline_header $ if f$extract(0,8,mailline_header) .nes. "Username" then goto more_header_lines $ read sysuaf sysline $ read sysuaf sysline $! $! Read first real data line from input files $! $ read mailuaf mailline $ read sysuaf sysline $! $! Open output file $! $ open/write outfile bad_mail_names.lis $ if write_commandfile $ then $ write outfile "$! remove-bad-mail-names.com" $ write outfile "$!" $ write outfile "$! 1) extract from mail message" $ write outfile "$! 2) delete the usernames you want to keep" $ write outfile "$!" $ write outfile "$ x = f$verify(""yes"")" $ write outfile "$ mail" $ write outfile f$fao("!!") $ write outfile f$fao("!!!_!AS", mailline_header) $ else $ write outfile mailline_header $ endif $ count = 0 $! $top: $ mailname = f$edit(f$extract(0,31,mailline),"TRIM") $! write sys$output " " $! write sys$output "MAILUAF name = ",mailname $ forward_address = f$edit(f$extract(32,999,mailline),"TRIM") $! write sys$output "MAILUAF forward address = ",forward_address $look_for_sysname: $ sysname = f$edit(f$extract(21,12,sysline),"TRIM") $! write sys$output "SYSUAF name = ",sysname $ if sysname .gts. mailname then goto not_found $ if sysname .eqs. mailname then goto found $ read/end=done sysuaf sysline $ goto look_for_sysname $found: $! write sys$output f$fao("!_!12AS !_found in SYSUAF file", mailname) $ read/end=done sysuaf sysline $ read/end=done mailuaf mailline $ goto top $not_found: $ if write_commandfile $ then $ if forward_address .eqs. "None" $ then write outfile f$fao(" remove!_ !31AS", mailname) $ else write outfile f$fao(" remove!_ !31AS!_!_!_!! !AS", mailname, - forward_address) $ endif $ else $ write outfile " ",mailline $ endif $ count = count + 1 $! write sys$output f$fao("!_!31AS !_NOT found in SYSUAF file", mailname) $ read/end=done mailuaf mailline $ goto top $done: $ close mailuaf $ close sysuaf $ if write_commandfile $ then $ write outfile " exit" $ write outfile "$ x = f$verify(x) $ write outfile "$ exit $ write outfile "$! end of remove-bad-mail-names.com" $ endif $ close outfile $ if count .gt. 0 $ then $ write sys$output f$fao("!_- !SL non-existent username!%S were found.", count) $ open/write tmpfile bad_mail_names.tmp $ write tmpfile "''f$fao(" The following !SL username!%S in the MAILUAF file", count)" $ write tmpfile " were not found in SYSUAF." $ write tmpfile " " $ close tmpfile $ append bad_mail_names.lis bad_mail_names.tmp $ $ mail/subj="Non-existent users in MAILUAF file" bad_mail_names.tmp; bad_mail_complaint_dept $ else $ write sys$output f$fao("!_- NO non-existent usernames were found.") $ mail/subj="NO Non-existent users in MAILUAF file" nl: bad_mail_complaint_dept $ endif $ delete/nolog bad_mail_names.lis;* $ purge/nolog bad_mail_names.tmp $ purge/nolog sysuaf.lis $ purge/nolog mailuaf.lis $ $done_reset: $ set default 'old_default' $ set process/privilege=(noall, 'old_privs') $ exit ================================================================================ Archive-Date: Mon, 24 Feb 1997 08:47:16 EST Sender: owner-mx-list@wku.edu Message-ID: <3.0.32.19970224082223.0092f250@Bible.acu.edu> Date: Mon, 24 Feb 1997 08:22:30 -0600 To: mx-list@wku.edu From: Tom Dolan Reply-To: MX-List@MadGoat.com Subject: filter incoming messages MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" One of my listowners is moving from majordomo on another system to MX on my system - in majordomo they had a system that would filter out messages (not post them to the list) if they had a command in the first line (like SUBSCRIBE, SET etc.) Is there a way to get MX to filter out messages with commands in them? Tom Dolan Dolan@Bible.acu.edu 915.674.3706 202 Bible Building Systems Manager ACU Box 29454 College of Biblical and Family Studies Abilene, TX 79699 Abilene Christian University FAX 915.674.3776 ================================================================================ Archive-Date: Mon, 24 Feb 1997 09:04:59 EST Sender: owner-mx-list@wku.edu Date: Mon, 24 Feb 1997 09:04:52 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B05BA.423D3E99.3@ALPHA.WKU.EDU> Subject: RE: filter incoming messages Tom Dolan writes: > >One of my listowners is moving from majordomo on another system to >MX on my system - in majordomo they had a system that would filter >out messages (not post them to the list) if they had a command in >the first line (like SUBSCRIBE, SET etc.) > >Is there a way to get MX to filter out messages with commands in them? > No. MX V4.2 will not post the message if the subject contains commands like that, but it does not scan the message text for possible commands. You could, of course, use the MX SITE interface to write a filter for stuff like that. Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Mon, 24 Feb 1997 09:14:39 EST Sender: owner-mx-list@wku.edu Date: Mon, 24 Feb 1997 09:14:33 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B05BB.9CA41FD7.13@ALPHA.WKU.EDU> Subject: RE: Delivery Error, Event Flags Ted Corning writes: > > Over the past week or so, I've started seeing mail not being delivered > with the following error: [...] >Error-Text: Error in delivery to user SYSMGR > illegal event flag cluster [...] > Since my machines have been severely overloaded, I suspect it may be a > VMS resource problem, but I am at a loss as to where to start looking. > A search of the MX-List archives shows that this problem appears to be related to problems in either Pathworks or UCX. You can check the archives for more information: http://www.madgoat.com/scripts/mxarchive/as_init.com?MX-List I searched for "illegal event flag cluster". Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Mon, 24 Feb 1997 09:20:25 EST Sender: owner-mx-list@wku.edu Date: Mon, 24 Feb 1997 09:20:16 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: TSPENCER@SCASSN.ORG Message-ID: <009B05BC.69033635.18@ALPHA.WKU.EDU> Subject: RE: errors-to question Ted Spencer PhD writes: > >We are running MX 4.1 on Vax/VMS 5.5. >I have just established a very large list (900 names) with a list owner off- >site and defined errors-to to go to her address. And yet I (as postmaster, >it appears) get scores of undeliverable mail messages from this list. Without knowing more, I can't say why this happens. Turning on MX_MLF_DEBUG and MX_ROUTER_DEBUG should help show what's going on, though. Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Mon, 24 Feb 1997 10:57:01 EST Sender: owner-mx-list@wku.edu Message-ID: <3.0.32.19970224105918.0083e120@Bible.acu.edu> Date: Mon, 24 Feb 1997 10:59:20 -0600 To: MX-List@wku.edu From: Tom Dolan Reply-To: MX-List@MadGoat.com Subject: owner-list@host.domain MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" How does owner-list@host.domain work? For example when I send a message to owner-olm@bible.acu.edu my message is forwarded to the address defined as the owner of the list. However when I send a message to owner-cell-church@Bible.acu.edu, the message is not forwarded to the addresses defined as owner. The only difference is that olm has one defined owner address and cell-church has four defined co-owner addresses. The cell-church owners want potential subscribers to send an application (available on the web) to "owner-cell-church@bible.acu.edu" for processing - is this possible? Tom Dolan Dolan@Bible.acu.edu 915.674.3706 202 Bible Building Systems Manager ACU Box 29454 College of Biblical and Family Studies Abilene, TX 79699 Abilene Christian University FAX 915.674.3776 ================================================================================ Archive-Date: Mon, 24 Feb 1997 15:36:10 EST Sender: owner-mx-list@wku.edu Date: Mon, 24 Feb 1997 22:37:40 +0100 From: Kurt Schumacher +41 1 342 42 54 Reply-To: MX-List@MadGoat.com To: MX-LIST@WKU.EDU CC: k_schumacher@decus.ch Message-ID: <009B062B.CE1CAAD9.10@elias.decus.ch> Subject: Multiple mail domain hosting using MX.... Hello I am trying to find out a way to host multiple mail domains on our MX system, for example xxxx@decus.ch AND xxxx@schumi.ch. DNS stuff is under control and works fine, but mail not sent to the "normal" address starts looping, for example send to xxxx@schumi.ch loops around elias.decus.ch, until... From: MX%"Postmaster@decus.ch" "SMTP delivery agent" To: MX%"k_schumacher@decus.ch" CC: Subj: SMTP delivery error Return-Path: <> Date: Mon, 24 Feb 1997 22:04:15 +0100 From: SMTP delivery agent To: Subject: SMTP delivery error X-Report-Type: Nondelivery; boundary="> Error description:" Note: this message was generated automatically. An error was detected while processing the enclosed message. A list of the affected recipients follows. This list is in a special format that allows software like LISTSERV to automatically take action on incorrect addresses; you can safely ignore the numeric codes. --> Error description: Error-For: KURT.SCHUMACHER@SCHUMI.CH Error-Code: 2 Error-Text: %MX_SMTP-F-TRANSACTION_FAI, transaction failed -(Via SCHUMI.CH) -Transcript: -Rcvd: 220 elias.decus.ch MX V4.2 AXP SMTP server ready at Mon, 24 Feb 1997 22:04:15 +0100 -Sent: HELO elias.decus.ch -Rcvd: 250 Hello, elias.decus.ch -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 elias.decus.ch Service closing transmission channel Error-End: 1 error detected ------------------------------ Rejected message ------------------------------ Received: from elias.decus.ch by elias.decus.ch (MX V4.2 AXP) with SMTP; Mon, 24 Feb 1997 22:04:14 +0100 Received: from elias.decus.ch by elias.decus.ch (MX V4.2 AXP) with SMTP; Mon, 24 Feb 1997 22:04:12 +0100 Received: from elias.decus.ch by elias.decus.ch (MX V4.2 AXP) with SMTP; Mon, 24 Feb 1997 22:04:11 +0100 Received: from elias.decus.ch by elias.decus.ch (MX V4.2 AXP) with SMTP; Mon, 24 Feb 1997 22:04:09 +0100 Received: from elias.decus.ch by elias.decus.ch (MX V4.2 AXP) with SMTP; Mon, 24 Feb 1997 22:04:08 +0100 Received: from elias.decus.ch by elias.decus.ch (MX V4.2 AXP) with SMTP; Mon, 24 Feb 1997 22:04:06 +0100 Received: from elias.decus.ch by elias.decus.ch (MX V4.2 AXP) with SMTP; Mon, 24 Feb 1997 22:04:05 +0100 Received: from elias.decus.ch by elias.decus.ch (MX V4.2 AXP) with SMTP; Mon, 24 Feb 1997 22:04:03 +0100 Received: by elias.decus.ch (MX V4.2 AXP) id 32; Mon, 24 Feb 1997 22:04:02 +0100 Sender: k_schumacher@decus.ch Date: Mon, 24 Feb 1997 22:04:02 +0100 From: Kurt Schumacher +41 1 342 42 54 Reply-To: k_schumacher@decus.ch To: KURT.SCHUMACHER@SCHUMI.CH CC: k_schumacher@decus.ch Message-ID: <009B0627.1B3EE46C.32@elias.decus.ch> Subject: test rewrite test only, ignore. --- Any ideas? Thanks Kurt A. Schumacher (Kurt.Schumacher@decus.ch) +------------------------------------------------------------------------+ | Kurt Schumacher E-Mail: Kurt.Schumacher@decus.ch | | PSI-Mail: PSI%022847911312::K_SCHUMACHER | | Riedhofstrasse 303 Voice: +41 1 342 42 54 | | CH-8049 Zürich FAX: +41 1 342 42 54 | +------------------------------------------------------------------------+ ================================================================================ Archive-Date: Mon, 24 Feb 1997 15:42:45 EST Sender: owner-mx-list@wku.edu Date: Mon, 24 Feb 1997 22:44:29 +0100 From: Kurt Schumacher +41 1 342 42 54 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: k_schumacher@decus.ch Message-ID: <009B062C.C1E0CE0C.6@elias.decus.ch> Subject: RE: Multiple mail domain hosting using MX.... uuups. Thinking first might help, here my own answer: MCP> define path "schumi.ch" Local MCP> define path "*.schumi.ch" Local MCP> reset This should do it. Kurt Sorry for the noise. +------------------------------------------------------------------------+ | Kurt Schumacher E-Mail: Kurt.Schumacher@decus.ch | | PSI-Mail: PSI%022847911312::K_SCHUMACHER | | Riedhofstrasse 303 Voice: +41 1 342 42 54 | | CH-8049 Zürich FAX: +41 1 342 42 54 | +------------------------------------------------------------------------+ ================================================================================ Archive-Date: Mon, 24 Feb 1997 17:29:00 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: Re: MX local dying; bad names Date: 24 Feb 97 11:00:27 -0500 Message-ID: <1997Feb24.110027.1@aspen> To: MX-List@WKUVX1.WKU.EDU In article <009B0490.CEE70500.13@swdev.si.com>, "Brian Tillman, x8425" writes: > In addition to Brendan Welch's list of tools, I offer this one, > BAD_MAIL_NAMES.COM: > > $ if f$mode() .eqs. "BATCH" then set noverify > $!------------------------------------------------------------------------------ > $! > $! Bad_Mail_Names.Com > $! > $! p1 = NOCOM shows non-existent usernames and forwarding address . . Having perfromed by hand, over several hours, the equivalent of the above, I ran it anyway, out of curiosity. (see note below) One case which it caught, but not perfectly, is the occasion where the fictitious username has a blank in it. (Surprisingly I _had_ found some by hand.) The suggested output, in email, from the above program gave remove KAY !I knew about her; the only fictitous name !we were keeping. remove XXX !one I had practiced with, and forgot to remove; remove USER BENI !the way to do so is Mail>remove "user beni" !This reminds me of the case I mentioned earlier, where a user must have said SET FORWARD OFF . Trouble with syntax, and semantic confusion over what constitutes literal text will always be with us, when reading instructions; in this case it just leads to strange places. Also, I reiterate my surprise at DEC: Mail>show forward/user=gobbledygook !from priv'd account, of course; !comes back with "No forwarding set for user GOBBLEDYGOOK" instead of stating that no such user exists either in mail_profile or sysuaf. ================== Note: I changed Brian's program a little bit, having screwed it up (didn't read instructions well enough) by running it from my private account. I moved it all to a separate scratch disk we have locally, and added some output cautioning a future user that he would have to wait patiently for completion. -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Mon, 24 Feb 1997 18:22:28 EST Sender: owner-mx-list@wku.edu Date: Mon, 24 Feb 1997 16:22:10 PST From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009B05F7.59B471BA.42@sacto.mp.usbr.gov> Subject: Re: MX local dying; bad names > From: MX%"MX-List@MadGoat.com" 24-FEB-1997 15:55:33.67 > Subj: Re: MX local dying; bad names Brendan, > In article <009B0490.CEE70500.13@swdev.si.com>, "Brian Tillman, x8425" writes: > > In addition to Brendan Welch's list of tools, I offer this one, > > BAD_MAIL_NAMES.COM: > > > > $ if f$mode() .eqs. "BATCH" then set noverify > > $!------------------------------------------------------------------------------ > > $! > > $! Bad_Mail_Names.Com > > $! > > $! p1 = NOCOM shows non-existent usernames and forwarding address > . > . > > Having perfromed by hand, over several hours, the equivalent of the above, > I ran it anyway, out of curiosity. (see note below) > > One case which it caught, but not perfectly, is the occasion where the > fictitious username has a blank in it. (Surprisingly I _had_ found > some by hand.) > > The suggested output, in email, from the above program gave > > remove KAY !I knew about her; the only fictitous name > !we were keeping. > remove XXX !one I had practiced with, and forgot to remove; > remove USER BENI !the way to do so is Mail>remove "user beni" > !This reminds me of the case I mentioned > earlier, where a user must have said SET FORWARD OFF . Trouble with syntax, > and semantic confusion over what constitutes literal text will always be with > us, when reading instructions; in this case it just leads to > strange places. > > Also, I reiterate my surprise at DEC: > Mail>show forward/user=gobbledygook !from priv'd account, of course; > !comes back with > "No forwarding set for user GOBBLEDYGOOK" instead of stating that no > such user exists either in mail_profile or sysuaf. > Actually, I'm glad it works this way - in this manner, I can set up a forwarding address for a user who does not have an address in the VAX Cluster, but I can set the forwarding so that the generic address: user@mp.usbr.gov will work. -HWM > ================== > Note: I changed Brian's program a little bit, having screwed it up > (didn't read instructions well enough) by running it from my private account. > I moved it all to a separate scratch disk we have locally, and added some > output cautioning a future user that he would have to wait patiently > for completion. > -- > Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Tue, 25 Feb 1997 09:17:37 EST Sender: owner-mx-list@wku.edu Message-ID: <3.0.32.19970225092000.008cd500@Bible.acu.edu> Date: Tue, 25 Feb 1997 09:20:17 -0600 To: MX-List@wku.edu From: Tom Dolan Reply-To: MX-List@MadGoat.com Subject: RE: owner-list@host.domain MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >>How does owner-list@host.domain work? > check the MX-List archives for the >reply: Hunter, I missed the implications of that discussion! I get it now - mail sent to Owner-Listname@host.domain is forwarded to the address in that listnames ERRORS TO: field. Is there a way to send errors to a group - could the error address be a private MX mailing list on the same machine that has world write privileges? (I tried this and it didn't seem to work.) Perhaps I could send errors to a private mailing list on another system...... Tom Dolan Dolan@Bible.acu.edu 915.674.3706 202 Bible Building Systems Manager ACU Box 29454 College of Biblical and Family Studies Abilene, TX 79699 Abilene Christian University FAX 915.674.3776 ================================================================================ Archive-Date: Tue, 25 Feb 1997 15:32:25 EST Sender: owner-mx-list@wku.edu From: dwing@tgv.com (Dan Wing) Subject: Re: Multiple mail domain hosting using MX.... Date: 25 Feb 1997 20:57:39 GMT Message-ID: <5evjo3$bah@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <009B062B.CE1CAAD9.10@elias.decus.ch>, Kurt Schumacher +41 1 342 42 54 writes: >I am trying to find out a way to host multiple mail domains on our >MX system, for example xxxx@decus.ch AND xxxx@schumi.ch. DNS stuff is >under control and works fine, but mail not sent to the "normal" address >starts looping, for example send to xxxx@schumi.ch loops around >elias.decus.ch, until... Do: $ RUN MX_EXE:MCP MCP> DEFINE PATH newdomain LOCAL MCP> SAVE MCP> RESET/CLUSTER/ALL -Dan Wing dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Tue, 25 Feb 1997 16:32:53 EST Sender: owner-mx-list@wku.edu From: dwing@cisco.com (Dan Wing) Subject: Re: SMTP & SMTP Server problem Date: 25 Feb 1997 21:42:13 GMT Message-ID: <5evmbl$erk@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <1997Feb25.121846@nntp.tkm.mb.ca>, system@nntp.tkm.mb.ca writes: >I am using MX 4.2, and am having some problems with SMTP and SMTP Server >crashing. I start MX, the processes create, and I can't even get a full SHOW >SYS in before both MX SMTP and MX SMTP Server have crashed. I have tried >defining the debugging logicals, but all the log files give me are: > >MX_SMTP_ALPHA.LOG > >25-FEB-1997 10:17:05.24: MX SMTP (pid 00001835) starting > >SMTP_SERVER_ALPHA.LOG > >25-FEB-1997 10:17:06.67: MX SMTP Server (pid 00001936) starting >25-FEB-1997 10:17:07.78: MX SMTP Server (pid 00001936) exiting, status=100182 > >The status indicator does not appear in the MX documentation, so could someone >please let me know what it is/how to remedy this situation? Try running the images from the command line and see if you get more information. Error 0x100182 is "%RMSREC-E-IVTIME, invalid time", for whatever that is worth. -Dan Wing dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Tue, 25 Feb 1997 21:14:46 EST Sender: owner-mx-list@wku.edu From: dwing@cisco.com (Dan Wing) Subject: RE: errors-to question Date: 26 Feb 1997 03:04:26 GMT Message-ID: <5f097q$9m4@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <009B05BC.69033635.18@ALPHA.WKU.EDU>, Hunter Goatley writes: >Ted Spencer PhD writes: >> >>We are running MX 4.1 on Vax/VMS 5.5. >>I have just established a very large list (900 names) with a list owner off- >>site and defined errors-to to go to her address. And yet I (as postmaster, >>it appears) get scores of undeliverable mail messages from this list. > >Without knowing more, I can't say why this happens. Turning on >MX_MLF_DEBUG and MX_ROUTER_DEBUG should help show what's going on, >though. Or send us a copy of one of the normal messages sent by the list. Also, you (as postmaster) might be getting noise from MX because you're the first System (privileged) user. Subscription requests and other related stuff is bounced to the first MX system user. I've set up things here so the first system user is mx-relay@tgv.com which goes directly to a file (which I ignore most of the time). -Dan Wing dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Thu, 27 Feb 1997 02:31:14 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: What is happening? Date: 26 Feb 97 09:44:56 -0500 Message-ID: <1997Feb26.094456.1@aspen> To: MX-List@WKUVX1.WKU.EDU We just upgraded to MX V4.2, and now were able to get some auditting. My boss told me to watch the files as they grew, in [MX.LOCAL], mostly because he wanted to get some idea of how many messages we actually process per day. I noticed in real time that .TMP files were getting created and disappearing, with sizes of approximately 2000 blocks. Trying to understand what the system is doing, and what the content of the files might be, I captured one. Here is the contents of that lengthy file. Notice that the times run backwards, usually spaced every 10 seconds. Why is a file which is appearing at 9:11am showing a history of what happened in the previous 6 hours, and then disappearing almost immediately? ===================================================================== Return-Path: Received: by woods.uml.edu (MX V4.2 VAX) id 42; Wed, 26 Feb 1997 09:10:19 EST5EDT4,M4.1.0,M10.5.0 Date: Wed, 26 Feb 1997 09:10:12 EST5EDT4,M4.1.0,M10.5.0 From: drum@teleport.com To: drum-digest@brandx.rain.com Message-ID: <009B074D.55E997C0.42@woods.uml.edu> Subject: drum-digest V1 #952 Return-Path: Received: by woods.uml.edu (MX V4.2 VAX) id 10; Wed, 26 Feb 1997 09:10:07 EST5EDT4,M4.1.0,M10.5.0 Date: Wed, 26 Feb 1997 09:10:00 EST5EDT4,M4.1.0,M10.5.0 From: drum@teleport.com To: drum-digest@brandx.rain.com Message-ID: <009B074D.4E77C520.10@woods.uml.edu> Subject: drum-digest V1 #952 Return-Path: Received: by woods.uml.edu (MX V4.2 VAX) id 1; Wed, 26 Feb 1997 09:09:55 EST5EDT4,M4.1.0,M10.5.0 . . . <<<< many lines removed . <<<< in so far as I have inspected, they contain . <<<< the same repetition of the same 7 lines, except . <<<< for the time change, until we get to the earliest . <<<< one, near 3am; it contains full text. . . Return-Path: Received: by woods.uml.edu (MX V4.2 VAX) id 29; Wed, 26 Feb 1997 03:11:01 EST5EDT4,M4.1.0,M10.5.0 Date: Wed, 26 Feb 1997 03:11:00 EST5EDT4,M4.1.0,M10.5.0 From: drum@teleport.com To: drum-digest@brandx.rain.com Message-ID: <009B071B.27FDAF40.29@woods.uml.edu> Subject: drum-digest V1 #952 Return-Path: Received: from desiree.teleport.com by willow.uml.edu (MX V4.2 VAX) with SMTP; Wed, 26 Feb 1997 03:10:58 EST5EDT4,M4.1.0,M10.5.0 Received: from localhost (daemon@localhost) by desiree.teleport.com (8.8.5/8.7.3) with SMTP id AAA22914; Wed, 26 Feb 1997 00:09:34 -0800 (PST) Received: by desiree.teleport.com (bulk_mailer v1.5); Wed, 26 Feb 1997 00:04:27 -0800 Received: (from daemon@localhost) by desiree.teleport.com (8.8.5/8.7.3) id AAA21477 for drum-digest-outgoing; Wed, 26 Feb 1997 00:04:27 -0800 (PST) Received: from brandx.rain.com (ip-pdx03-03.teleport.com [206.163.123.68]) by desiree.teleport.com (8.8.5/8.7.3) with ESMTP id AAA21364 for ; Wed, 26 Feb 1997 00:04:08 -0800 (PST) Received: (from majordomo@localhost) by brandx.rain.com (8.8.5/8.8.5) id XAA17822 for drum-digest-outgoing; Tue, 25 Feb 1997 23:05:31 -0800 Date: Tue, 25 Feb 1997 23:05:31 -0800 Message-ID: <199702260705.XAA17822@brandx.rain.com> X-Authentication-Warning: brandx.rain.com: majordomo set sender to owner-drum-digest using -f From: owner-drum-digest@brandx.rain.com To: drum-digest@brandx.rain.com Subject: drum-digest V1 #952 Sender: owner-drum-digest@teleport.com Reply-To: drum@teleport.com drum-digest Tuesday, 25 February 1997 Volume 01 : Number 952 In this issue: Re: power shifter Re: Ear-plugs? Drum Kit Question Re: Marching--Cadences Paiste 602 hi hats Silicone grease Re:bassoon doble Gene Hoglan (fwd) Re: Zildjian Factory Re: Cowbell Stand Re: g Love & Special Sauce Re: cowbell stand troubles Technical info double bass PARADIDDLES Re: free improv ---------------------------------------------------------------------- From: "Willard L. Abernathy" Date: Wed, 19 Feb 1997 18:08:05 -0500 Subject: Re: power shifter > Does anybody know about these Power Shifter Pedals by Pearl? I for one can vouch for the power shifter pedals. I play double base and have two. I have used tama, DW, and Yamaha and I feel that the Pearl not only has the best feel, but also is the most adjustable. In this case your dealer is right. Buy it. It's the best for the money. _______________________________________________________________________ This has been a message from the Drums and Percussion mailing list. Send administrative requests to drum-request@brandx.rain.com. ------------------------------ . . . <<<< text lines removed . <<<< for brevity . . . This has been a message from the Drums and Percussion mailing list. Send administrative requests to drum-request@brandx.rain.com. ------------------------------ End of drum-digest V1 #952 ************************** ===================================================================== -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Thu, 27 Feb 1997 02:31:18 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: Re: What is happening? (additional info) Date: 26 Feb 97 10:25:28 -0500 Message-ID: <1997Feb26.102528.1@aspen> To: MX-List@WKUVX1.WKU.EDU The .TMP file which I described earlier keeps re-appearing, every 10 seconds or so. It is slightly larger each time, because it has additional entries at the top, from times during this morning sofar. I used SHOW DEV/FILE, which reveals that this file is used by MX LOCAL (of course, of course). There are other much shorter .TMP files which appear, apparently randomly, every minute or so. I have not yet been able to devise a BACKUP or TYPE command which is quick enough to identify and lock onto these short files before they disappear, so I have no idea of their text content. These may be used by MX LOCAL#1, or there may be an interaction between the LOCALs. -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Thu, 27 Feb 1997 02:31:24 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: Re: What is happening? (warning) Date: 26 Feb 97 11:48:19 -0500 Message-ID: <1997Feb26.114819.1@aspen> To: MX-List@WKUVX1.WKU.EDU I found a way to capture the quickly-vanishing .TMP files in [mx.local], but I must warn you against using it. Because the files have names which are too long to type (more rapidly than the files disappear), I used $rename/log *.tmp *.sav But I now see some flaws in that. (It apparently depends on timing.) 1) The system cannot find the .TMP file, to forward it to its proper recipient, so you may have to go in by hand, inspect the file, and send it along with an apology. 2) I am suspicious that this failure to be able to delete a message may now put the delivery agent in a confused state. I see (MCP STAT) that MX LOCAL has been waiting for a certain message for a very long time; however, $MCP SHOW message-number does not show any correspondence to any .TMP file. -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Thu, 27 Feb 1997 07:06:05 EST Sender: owner-mx-list@wku.edu Date: Thu, 27 Feb 1997 07:05:59 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: WELCHB@WOODS.UML.EDU Message-ID: <009B0805.260DC52D.17@ALPHA.WKU.EDU> Subject: RE: What is happening? welchb@woods.uml.edu (Brendan Welch, W1LPG) writes: > >We just upgraded to MX V4.2, and now were able to get some auditting. >My boss told me to watch the files as they grew, in [MX.LOCAL], mostly >because he wanted to get some idea of how many messages we actually >process per day. > Just turn on MX LOCAL accounting for that: MCP SET LOCAL/ACCOUNTING >I noticed in real time that .TMP files were getting created and >disappearing, with sizes of approximately 2000 blocks. Trying to >understand what the system is doing, and what the content of the >files might be, I captured one. > >Here is the contents of that lengthy file. Notice that the times >run backwards, usually spaced every 10 seconds. > >Why is a file which is appearing at 9:11am showing a history of >what happened in the previous 6 hours, and then disappearing almost >immediately? Because you have a user on your system who has done a VMS MAIL SET FORWARD back to himself---MX is delivering the mail via callable mail, which is sending it right back to MX in an infinite loop. And because VMS Mail adds the blank line before the headers, MX doesn't detect that it's seen the message before. You can find out what user this is by enabling MX Local debugging: $ define/system/exec mx_local_debug true That'll create log files in MX_LOCAL_DIR: that will show you exactly what's happening. Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Thu, 27 Feb 1997 08:33:06 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: RE: What is happening? Date: 27 Feb 97 09:15:43 -0500 Message-ID: <1997Feb27.091543.1@aspen> To: MX-List@WKUVX1.WKU.EDU In article <009B0805.260DC52D.17@ALPHA.WKU.EDU>, Hunter Goatley writes: >> >>Why is a file which is appearing at 9:11am showing a history of >>what happened in the previous 6 hours, and then disappearing almost >>immediately? > > Because you have a user on your system who has done a VMS MAIL SET > FORWARD back to himself---MX is delivering the mail via callable mail, > which is sending it right back to MX in an infinite loop. And because > VMS Mail adds the blank line before the headers, MX doesn't detect > that it's seen the message before. > > You can find out what user this is by enabling MX Local debugging: > > $ define/system/exec mx_local_debug true > I finally figured it out, using the moral equivalent (brute-force searches). The culprit was someone whose forwarding I had turned off a week ago. I received mail from him today; he thought that forwarding to self was the normal state. He (pretend his name is jones) had not said "set forward jones" but "set forward jones@woods.uml.edu" . I realize that VMS mail cannot do everything, but I am coming to the opinion that it is essential to DEC's survival: When a user sets mail forwarding, the system should check it syntactically and even dynamically; and it should issue an immediate warning message, regardless, that whenever the user sets forwarding, he should send a test message and verify that it went where he thought it should and would go. [I post here via a newsgroup, not a mailing list; and because of multiple technical problems I was not even sure my postings were making it out.] -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Thu, 27 Feb 1997 08:55:32 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: Re: MX local dying; warning! Date: 27 Feb 97 09:42:48 -0500 Message-ID: <1997Feb27.094248.1@aspen> To: MX-List@WKUVX1.WKU.EDU If the death of MX LOCAL can be caused by certain bad messages (e.g. bad forwarding), here is a situation which can arise for those who have a Scheduled job which tries to restart MX periodically. I admit that this death is a very big "if", which has been the subject of several postings here, and needs more definitive work. There are several cyclical things happening: -- the re-try of the message, typically with a spacing of 30 minutes, and an original time-zero of when the message first happened by chance to appear -- the restart, which in our case has been 30 minutes apart, with an original time-zero of when it arbitrarily happened to get created. -- if the restart is done not by the Scheduler but by a self-submitting process, the time-zero could be related to the instant of reboot. -- in any case, the Scheduling could be done by various methods of absolute or relative time. Consider the scenario of this possible timing: 1) The restart takes place, and as a result, all processes are running. 2) A few seconds later, the bad message appears and zaps a process. Thus, that process is missing until the restart occurs. 3) That attempted restart occurs 29.9 minutes later than 2). 4) A few seconds later, because of the 30-minute spacing, the bad message appears. As a result of this worst-case scenario, the process exists only for a few seconds, because every restart is followed immediately by a deathly appearance. And if you went to other timings which are a sub-multiple of 30 minutes (2,5,6,10,15), let us say 15 in this next scenario, the worst-case- timing would still leave the process up only half the time. One solution would be to use a crazy number like 25 minutes or 35 minutes, so you would roll through a large number of statistically-possible scenarios in a typical day. --- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Thu, 27 Feb 1997 09:02:09 EST Sender: owner-mx-list@wku.edu Date: Thu, 27 Feb 1997 09:02:03 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: WELCHB@WOODS.UML.EDU Message-ID: <009B0815.5CBF6D65.3@ALPHA.WKU.EDU> Subject: Re: MX local dying; warning! welchb@woods.uml.edu (Brendan Welch, W1LPG) writes: > >If the death of MX LOCAL can be caused by certain bad messages >(e.g. bad forwarding), here is a situation which can arise for those who >have a Scheduled job which tries to restart MX periodically. The best thing is to install the latest MX_LOCAL image that I posted about last week. I've heard nothing back from anybody about it, so I assume that it's working for those who were having problems?? Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Thu, 27 Feb 1997 09:07:47 EST Sender: owner-mx-list@wku.edu Date: Thu, 27 Feb 1997 15:06:17 GMT From: Andy Harper - KCL Systems manager Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: A.HARPER@kcl.ac.uk Message-ID: <009B0848.3ECEB9C0.133@alder.cc.kcl.ac.uk> Subject: Re: MX local dying; warning! >>If the death of MX LOCAL can be caused by certain bad messages >>(e.g. bad forwarding), here is a situation which can arise for those who >>have a Scheduled job which tries to restart MX periodically. > >The best thing is to install the latest MX_LOCAL image that I posted >about last week. I've heard nothing back from anybody about it, so I >assume that it's working for those who were having problems?? I can confirm that I've had no problems since the patch was installed. Thanks Hunter. Regards, Andy Harper Kings College London ================================================================================ Archive-Date: Thu, 27 Feb 1997 09:29:21 EST Sender: owner-mx-list@wku.edu Date: Thu, 27 Feb 1997 15:30:53 BST From: John Powers Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: john.powers@blackwell.co.uk Message-ID: <009B084B.AE655E80.117@blackwell.co.uk> Subject: Re: MX local dying; warning! > >welchb@woods.uml.edu (Brendan Welch, W1LPG) writes: >> >>If the death of MX LOCAL can be caused by certain bad messages >>(e.g. bad forwarding), here is a situation which can arise for those who >>have a Scheduled job which tries to restart MX periodically. > >The best thing is to install the latest MX_LOCAL image that I posted >about last week. I've heard nothing back from anybody about it, so I >assume that it's working for those who were having problems?? > >Hunter >------ >Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com > http://www.madgoat.com/hunter.html I can confirm that I have installed the new MX_LOCAL on our VAX-VMS V5.5-2 system and we have had no more problems.. Cheers. John. ----------------------------------------------------------------------------- John Powers - Blackwell's, Oxford - - "fee issuing thirty mails" (anag.) john.powers@blackwell.co.uk (Internet) Blackwells Booksellers - Visit our PSI%234284400179::TJGP (PSImail) home page: http://www.blackwell.co.uk/ ----------------------------------------------------------------------------- ================================================================================ Archive-Date: Thu, 27 Feb 1997 09:53:20 EST Sender: owner-mx-list@wku.edu Date: Thu, 27 Feb 1997 10:42:42 EST From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: welchb@woods.uml.edu Message-ID: <009B0823.6C6E57C0.21@swdev.si.com> Subject: RE: What is happening? Brendan Welch (welchb@woods.uml.edu_) writes: >I realize that VMS mail cannot do everything, but I am coming to the opinion >that it is essential to DEC's survival: When a user sets mail forwarding, >the system should check it syntactically and even dynamically; and it >should issue an immediate warning message, regardless, that whenever the user >sets forwarding, he should send a test message and verify that it went where he >thought it should and would go. That's a tall order, considering that VMS Mail knows _nothing_ about SMTP. If you forward to yourselv using ordinary VMS Mail address, Mail _does_ check and will not allow the forwarding (even though it doesn't tell you): MAIL> set forward tillman MAIL> show forward You have not set a forwarding address. If you forward via DECnet, even, VMS Mail can detect that: MAIL> set forw swdev::tillman MAIL> sho forw Your mail is being forwarded to SWDEV::TILLMAN. MAIL> send/noed To: tillman %MAIL-E-FORWLOOP, infinite forwarding detected sending to user TILLMAN This is possible because the MAIL-11 protocol has DECnet built in. SMTP, on the other hand is a "foreign protocol"; hence, all you have are the MAIL-11 hooks, which link you user-supplied routines. It's up to the user-supplied routines to handle everything after being passed the mail. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman_brian@si.com Smiths Industries, Inc. | tillman@swdev.si.com 4141 Eastern Ave., MS239 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 27 Feb 1997 10:28:41 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: RE: What is happening? Date: 27 Feb 97 11:02:25 -0500 Message-ID: <1997Feb27.110225.1@aspen> To: MX-List@WKUVX1.WKU.EDU In article <009B0823.6C6E57C0.21@swdev.si.com>, "Brian Tillman, x8425" writes: > That's a tall order, considering that VMS Mail knows _nothing_ about SMTP. If > you forward to yourselv using ordinary VMS Mail address, Mail _does_ check and > will not allow the forwarding (even though it doesn't tell you): . > > MAIL> set forward tillman > MAIL> show forward > You have not set a forwarding address. But it does not detect set forward tillman@swdev.si.com if you are doing this forwarding from swdev. It does not detect embedded blanks, nor errors of the form NODE:USER (which have only one colon). -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Thu, 27 Feb 1997 14:58:42 EST Sender: owner-mx-list@wku.edu From: Ted Spencer PhD Reply-To: MX-List@MadGoat.com Content-Type: text/plain To: MX-List@wku.edu Subject: Fw: Re: Updating e-mail addresses for Masscomm list Content-Transfer-Encoding: 7bit Date: Thu, 27 Feb 1997 14:58:38 EST Here is a problem that was just reported to me; apparently messages going out from MX do not care a Date line. Is this because I may have set the list to Strip Headers (both received and other)? I got a similar message from someone else telling me that my e-mail messages to him (handled through MX) do not carry Date headers, but that they are sorted by Date Received (so far as I could understand his description of the problem). Any help would be appreciated. -----Begin Included Message ----- Date: Wed, 26 Feb 1997 9:04:40 EST From: Subject: Re: Updating e-mail addresses for Masscomm list To: tspencer@scassn.org Both your messages came in without dates. Messages reaching me in this way go to the end of a very lengthy disply of aliases. Please see if that can be adjusted. I wouldn't want to miss anything important. ---- End Included Message ---- __________________________________________________ Ted Spencer, PhD tspencer@scassn.org Publications Manager & Webmaster 703-750-0533 Speech Communication Assn fax 703-914-9471 http://www.scassn.org ================================================================================ Archive-Date: Thu, 27 Feb 1997 15:34:00 EST Sender: owner-mx-list@wku.edu Date: Thu, 27 Feb 1997 15:33:54 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: TSPENCER@SCASSN.ORG Message-ID: <009B084C.1A752F25.1@ALPHA.WKU.EDU> Subject: RE: Fw: Re: Updating e-mail addresses for Masscomm list Ted Spencer PhD writes: > >Here is a problem that was just reported to me; apparently messages going >out from MX do not care a Date line. Is this because I may have set the list >to Strip Headers (both received and other)? I got a similar message from >someone else telling me that my e-mail messages to him (handled through MX) >do not carry Date headers, but that they are sorted by Date Received (so far >as I could understand his description of the problem). Any help would be >appreciated. > All messages originating from MX include Date: lines. The problem is that not all clients do, specifically, Eudora clients don't always add a Date: line. Technically speaking, it's against the RFCs for MX to add one if it's missing, but I added that functionality to MX MLF in MX V4.2. Is that what you're running? Note that non-mailing list messages routed through MX will not get a Date: added, though MX V4.3 will let you make the SMTP Server add the Date: line to incoming messages if it's missing. Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Thu, 27 Feb 1997 16:08:54 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: ?30 day expiration Date: 27 Feb 97 11:08:36 -0500 Message-ID: <1997Feb27.110836.1@aspen> To: MX-List@WKUVX1.WKU.EDU Since I have taken over this newsgroup (when posting works) 8-) here is a question(s) which has arisen from my scrutiny of messages in queues, logs, and accounting files. I see that there is a message expiration of 30 days, apparently overridden by MX typical choice of 96 tries spaced 30 minutes apart (= 2 days). Does this 30 days come attached to each message, perhaps chosen by each sending site? Is it specified in a RFC? Is it manageable by MX, someplace in the source code, or elsewhere? -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Thu, 27 Feb 1997 16:16:30 EST Sender: owner-mx-list@wku.edu Date: Thu, 27 Feb 1997 16:16:23 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B0852.0985FEF5.5@ALPHA.WKU.EDU> Subject: RE: ?30 day expiration welchb@woods.uml.edu (Brendan Welch, W1LPG) writes: > >I see that there is a message expiration of 30 days, apparently overridden >by MX typical choice of 96 tries spaced 30 minutes apart (= 2 days). > >Does this 30 days come attached to each message, perhaps chosen by >each sending site? > Nope. >Is it specified in a RFC? > Nope. >Is it manageable by MX, someplace in the source code, or elsewhere? Yes, the logical MX_FLQ_EXPIRY_THRESHOLD controls that time. That's an undocumented logical. Basically, it's never really used, as the retries take care of expiring messages, normally. In fact, a quick check through the sources reveals that it's never used by the code, so I wouldn't worry about trying to change it. (It was a feature that was never fully implemented.) Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Thu, 27 Feb 1997 18:48:55 EST Sender: owner-mx-list@wku.edu Date: Thu, 27 Feb 1997 16:44:54 PST From: system@planacc.com Reply-To: MX-List@MadGoat.com To: MX-LIST@MADGOAT.COM Message-ID: <009B0856.05E5AF20.3@planacc.com> Subject: Address_rewriter Greetings All, We are running VMS6.1 and MX 4.2 . I have installed the bliss version taken from address_rewriter.zip date 8/96. When i turn on Router debug i get this: 27-FEB-1997 16:23:44.97 %PROCESS, Processing entry number 5 27-FEB-1997 16:23:45.01 %PROCESS, Status from READ_INFO was 00000001 27-FEB-1997 16:23:45.01 %PROCESS, Message originated in VMS Mail. 27-FEB-1997 16:23:45.03 %PROCESS, ... Header rewrite of chat_l@ore.gvnw. com failed 001582FC 27-FEB-1997 16:23:45.03 %PROCESS, ... Header rewrite of SYSTEM@ORE.GVNW. COM failed 00000000 The top error code translates to : $ WRITE SYS$OUTPUT F$MESSAGE(%x001582FC) %LIB-F-KEYNOTFOU, key not found in tree The file mx_aliases_addresses.txt is in the mx_dir: the one entry in it is chat_l@ore.gvnw.com CLand@GVNW.COM What am i missing? And BTW the mcp reset router command does not restart the router since i have isntalled address_rewriter. Thanks for all of your time, CT_Land@Planacc.com ================================================================================ Archive-Date: Thu, 27 Feb 1997 19:54:49 EST Sender: owner-mx-list@wku.edu Date: Thu, 27 Feb 1997 19:54:43 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: SYSTEM@PLANACC.COM Message-ID: <009B0870.89F3B8FD.4@ALPHA.WKU.EDU> Subject: RE: Address_rewriter system@planacc.com writes: > >And BTW the mcp reset router command does not restart the router since >i have isntalled address_rewriter. > It should still cause the Router to reset and reload the aliases file. Perhaps that the key to why the address isn't found---maybe there's some other reason the file isn't read in? You might try running MX_ROUTER interactively after doing this: $ set watch file/class=major $ run mx_exe:mx_router That should show you the file opens and whether or not they're successful. Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Fri, 28 Feb 1997 03:02:37 EST Sender: owner-mx-list@wku.edu Date: Fri, 28 Feb 1997 01:02:15 PST From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009B089B.809D01D8.6@sacto.mp.usbr.gov> Subject: RE: What is happening? > From: MX%"MX-List@MadGoat.com" 27-FEB-1997 07:12:58.88 > Subj: RE: What is happening? > In article <009B0805.260DC52D.17@ALPHA.WKU.EDU>, Hunter Goatley writes: > >> > >>Why is a file which is appearing at 9:11am showing a history of > >>what happened in the previous 6 hours, and then disappearing almost > >>immediately? > > > > Because you have a user on your system who has done a VMS MAIL SET > > FORWARD back to himself---MX is delivering the mail via callable mail, > > which is sending it right back to MX in an infinite loop. And because > > VMS Mail adds the blank line before the headers, MX doesn't detect > > that it's seen the message before. > > > > You can find out what user this is by enabling MX Local debugging: > > > > $ define/system/exec mx_local_debug true > > > > I finally figured it out, using the moral equivalent (brute-force searches). > The culprit was someone whose forwarding I had turned off a week ago. > I received mail from him today; he thought that forwarding to self was > the normal state. He (pretend his name is jones) had not said > "set forward jones" but "set forward jones@woods.uml.edu" . > > I realize that VMS mail cannot do everything, but I am coming to the opinion > that it is essential to DEC's survival: When a user sets mail forwarding, > the system should check it syntactically and even dynamically; and it > should issue an immediate warning message, regardless, that whenever the user > sets forwarding, he should send a test message and verify that it went where he > thought it should and would go. > Brendan, That would be nice in theory, but difficult in practice as VMSMAIL did not have "built-in" Internet mail support as TOPS20 had. Internet style addressing is possible because DEC did leave the hooks in for third party mail transports. Of course, someone could write a syntax checking utility, which would be the gratefully received I'm sure by the Internet VMS community... > [I post here via a newsgroup, not a mailing list; and because of multiple > technical problems I was not even sure my postings were making it out.] > -- > Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu -HWM ================================================================================ Archive-Date: Fri, 28 Feb 1997 08:46:14 EST Sender: owner-mx-list@wku.edu Date: Fri, 28 Feb 1997 09:43:09 -0500 From: Joe Macewicz Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B08E4.44DC69C4.103@usnews.com> Subject: Should SMTP try all sites in the DNS ================================================================================ Archive-Date: Fri, 28 Feb 1997 08:47:26 EST Sender: owner-mx-list@wku.edu Date: Fri, 28 Feb 1997 09:44:19 -0500 From: Joe Macewicz Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B08E4.6EDF8CC4.177@usnews.com> Subject: Should SMTP try all Sites before failing I cannot send mail to a site when one of the three servers (the primary) fails to respond to helo sent form my MX server. Should MX try the other two servers before failing? When ever we send to usatoday.com it fails as indicated in the log. I checked the DNS for servers, the manually connected to port 25 on each of them and the one that fails is the primary. Any ideas outside of contacting usatoday (in the process of that now). Thanks! Joe __________________________________________________________________________ 28-FEB-1997 09:10:50.53 Processing queue entry number 78 on node ASTRO 28-FEB-1997 09:10:51.13 Recipient: , route=usatoday.com 28-FEB-1997 09:10:51.13 SMTP_SEND: looking up host name usatoday.com 28-FEB-1997 09:10:51.14 SMTP_SEND: DNS_MXLOOK status is 00000001 28-FEB-1997 09:10:51.32 SMTP_SEND: Attempting to start session with dns1.ganne tt.com [192.234.102.20] 28-FEB-1997 09:10:51.33 SMTP_SEND: Connected 28-FEB-1997 09:12:06.32 SMTP send failed, sts=0C27804A, sts2=000020EC 28-FEB-1997 09:12:06.32 Recipient status=0C27804A for 28-FEB-1997 09:12:07.63 1 rcpts need retry, next try 28-FEB-1997 09:42:07.63 28-FEB-1997 09:12:07.74 *** End of processing pass *** ___________________________________________________________________________ Nslookup returns the following for usatoday Non-authoritative answer: usatoday.com preference = 100, mail exchanger = mail.uu.net usatoday.com preference = 5, mail exchanger = dns1.gannett.com usatoday.com preference = 10, mail exchanger = smtpgate.gannett.com ___________________________________________________________________________ Manual connectios to port 25 ( all but dns1 worked) $telnet /port=25 smtpgate.gannett.com Trying... Connected to SMTPGATE.GANNETT.COM. helo 220 smtpgate.gannett.com Smail3.1.29.1 #1 ready at Fri, 28 Feb 97 08:36 EST 250 smtpgate.gannett.com Hello usnews.com quit 221 smtpgate.gannett.com closing connection Connection closed by Foreign Host $ $telnet /port=25 mail.uu.net Trying... Connected to MAIL.UU.NET. 220 relay1.UU.NET ESMTP helo 250 relay1.UU.NET Hello mail.usnews.com [208.131.212.2], pleased to meet you quit 221 relay1.UU.NET closing connection Connection closed by Foreign Host $ $telnet /port=25 mail.uu.net $telnet /port=25 dns1.gannett.com Trying... Connected to DNS1.GANNETT.COM. helo quit _______________________________________________________________________ ================================================================================ Archive-Date: Fri, 28 Feb 1997 08:54:32 EST Sender: owner-mx-list@wku.edu Date: Fri, 28 Feb 1997 08:54:26 EST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B08DD.76BC5E5F.11@ALPHA.WKU.EDU> Subject: RE: Should SMTP try all Sites before failing Joe Macewicz writes: > >I cannot send mail to a site when one of the three servers (the primary) >fails to respond to helo sent form my MX server. Should MX try the other two >servers before failing? > As far as I remember from the RFCs, you only try the other systems listed in the MX records if you can't connect to the first system. In your case, the actual connection is made, but then the remote node never responds. As far as MX sees, the connection was made, therefore, the other systems aren't tried. >28-FEB-1997 09:10:51.32 SMTP_SEND: Attempting to start session with dns1.ganne >tt.com [192.234.102.20] >28-FEB-1997 09:10:51.33 SMTP_SEND: Connected >28-FEB-1997 09:12:06.32 SMTP send failed, sts=0C27804A, sts2=000020EC 20ec is "%SYSTEM-F-LINKDISCON, network partner disconnected logical link". I agree that it would be nice to force that behavior in cases like this, but it's not there now. Hunter ------ Hunter Goatley, Process Software (TCPware for OpenVMS), http://www.process.com http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Fri, 28 Feb 1997 09:38:56 EST Sender: owner-mx-list@wku.edu Date: Fri, 28 Feb 1997 07:38:29 PST From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009B08D2.DAC19E08.20@sacto.mp.usbr.gov> Subject: RE: Should SMTP try all Sites before failing > From: MX%"MX-List@MadGoat.com" 28-FEB-1997 07:33:28.05 > Subj: Should SMTP try all Sites before failing Joe, > I cannot send mail to a site when one of the three servers (the primary) > fails to respond to helo sent form my MX server. Should MX try the other two > servers before failing? > It should - are you using the latest MX and the latest NETLIB? > When ever we send to usatoday.com it fails as indicated in the log. I > checked the DNS for servers, the manually connected to port 25 on each of > them and the one that fails is the primary. > Have you confirmed that the servers are indeed reachable via: $ TELNET/PORT=25 hostname ??? > Any ideas outside of contacting usatoday (in the process of that now). > Find an address that works and do a "DEFINE PATH" with MCP? (I use this often to shunt mail from my main machine to a secondary mail machine if certain addresses are unreachable for a long period of time.) > Thanks! > Joe > -HWM > __________________________________________________________________________ > 28-FEB-1997 09:10:50.53 Processing queue entry number 78 on node ASTRO > 28-FEB-1997 09:10:51.13 Recipient: , route=usatoday.com > 28-FEB-1997 09:10:51.13 SMTP_SEND: looking up host name usatoday.com > 28-FEB-1997 09:10:51.14 SMTP_SEND: DNS_MXLOOK status is 00000001 > 28-FEB-1997 09:10:51.32 SMTP_SEND: Attempting to start session with dns1.ganne > tt.com [192.234.102.20] > 28-FEB-1997 09:10:51.33 SMTP_SEND: Connected > 28-FEB-1997 09:12:06.32 SMTP send failed, sts=0C27804A, sts2=000020EC > 28-FEB-1997 09:12:06.32 Recipient status=0C27804A for > 28-FEB-1997 09:12:07.63 1 rcpts need retry, next try 28-FEB-1997 09:42:07.63 > 28-FEB-1997 09:12:07.74 *** End of processing pass *** > > ___________________________________________________________________________ > > Nslookup returns the following for usatoday > > Non-authoritative answer: > usatoday.com preference = 100, mail exchanger = mail.uu.net > usatoday.com preference = 5, mail exchanger = dns1.gannett.com > usatoday.com preference = 10, mail exchanger = smtpgate.gannett.com > > ___________________________________________________________________________ > > Manual connectios to port 25 ( all but dns1 worked) > > $telnet /port=25 smtpgate.gannett.com > Trying... > Connected to SMTPGATE.GANNETT.COM. > helo > 220 smtpgate.gannett.com Smail3.1.29.1 #1 ready at Fri, 28 Feb 97 08:36 EST > 250 smtpgate.gannett.com Hello usnews.com > quit > 221 smtpgate.gannett.com closing connection > Connection closed by Foreign Host > > > $ > $telnet /port=25 mail.uu.net > Trying... > Connected to MAIL.UU.NET. > 220 relay1.UU.NET ESMTP > helo > 250 relay1.UU.NET Hello mail.usnews.com [208.131.212.2], pleased to meet you > quit > 221 relay1.UU.NET closing connection > Connection closed by Foreign Host > > > $ > $telnet /port=25 mail.uu.net > $telnet /port=25 dns1.gannett.com > Trying... > Connected to DNS1.GANNETT.COM. > helo > quit > > > _______________________________________________________________________ > > -------------------------------------------------------------------------------- > Return-Path: > Received: from axp1.wku.edu by sacusr.mp.usbr.gov (MX V4.2A VAX) with SMTP; > Fri, 28 Feb 1997 07:32:00 PST > X-ListName: Message Exchange Discussion List > Warnings-To: <> > Errors-To: owner-mx-list@wku.edu > Sender: owner-mx-list@wku.edu > Date: Fri, 28 Feb 1997 09:44:19 -0500 > From: Joe Macewicz > Reply-To: MX-List@MadGoat.com > To: MX-List@MadGoat.com > Message-ID: <009B08E4.6EDF8CC4.177@usnews.com> > Subject: Should SMTP try all Sites before failing ================================================================================ Archive-Date: Fri, 28 Feb 1997 17:24:53 EST Sender: owner-mx-list@wku.edu From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: RE: What is happening? Date: 28 Feb 97 15:19:17 -0500 Message-ID: <1997Feb28.151917.1@aspen> To: MX-List@WKUVX1.WKU.EDU In article <009B089B.809D01D8.6@sacto.mp.usbr.gov>, "Henry W. Miller" writes: > > That would be nice in theory, but difficult in practice as > VMSMAIL did not have "built-in" Internet mail support as TOPS20 had. > Internet style addressing is possible because DEC did leave the hooks in > for third party mail transports. > > Of course, someone could write a syntax checking utility, which > would be the gratefully received I'm sure by the Internet VMS > community... I agree, but here is something I find a little frustrating or aggravating (!): nothing beats a human. I was looking in our que (mcp que show/full), looking at the errors which were going to be re-tried for 2 days. Several causes are mistakes of spelling or keystroking, which are obvious to humans, such as --- address is aol.comm !misspell of com --- address is xxxxx.edu\ !finger slipped onto \ It is "frustrating" because the answer is so easy to the human, but will waste the computer's time. Human minds have a hierarchy of thought processes and of evaluation of importance that is so built-in, that we are unaware of it. It takes expensive and large "expert" software to approximate it. -- Brendan Welch, system analyst, UMass/Lowell, W1LPG, welchb@woods.uml.edu