Archive-Date: Tue, 01 Mar 1994 00:05:47 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 01 Mar 1994 00:05:19 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@WKUVX1.WKU.EDU Message-ID: <0097AC1F.21AA94A0.174@WKUVX1.WKU.EDU> Subject: MX-LIST Administrivia: Monthly Post Posting statistics for list MX-LIST during February 1994 Total number of posts: 217 Total number of posters: 89 Total number of subscribers: 219 Total number of digest subscribers: 27 Last modified: 31-MAY-1993 23:55 (Added digest info.) Welcome to MX-List@WKUVX1.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@WKUVX1.WKU.EDU: SUBSCRIBE MX-List-Digest "Your real name here" The MX-List archives are maintained at ARCHIVES@WKUVX1.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@WKUVX1.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.MX033]. You can also get it via e-mail by sending the commands SEND MX033 and SEND FILESERV_TOOLS on separate lines in the body of a mail message to FILESERV@WKUVX1.WKU.EDU. To remove yourself from the mailing list, send the following command to MXserver@WKUVX1.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 NOMAIL - to remain on the list but not receive mail SET MX-List MAIL - to resume receiving mail from the list SET MX-List CONCEAL - to not report your address in a REVIEW SET MX-List NOCONCEAL - to report your address in a REVIEW SET MX-List REPRO - to receive posts you make to MX-List SET MX-List NOREPRO - to not receive posts you make to MX-List LIST - to get a list of mailing lists served by WKUVX1 HELP - to receive a help file By default, subscriptions are set to MAIL, REPRO, NOCONCEAL. If you have any questions, comments, or suggestions about MX-List, please contact the list owner at the address below. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Hunter Goatley, VAX Systems Programmer goathunter@WKUVX1.WKU.EDU Western Kentucky University Academic Computing, STH 226 (502) 745-5251 Bowling Green, KY 42101 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ================================================================================ Archive-Date: Tue, 01 Mar 1994 03:38:09 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: RE: wishlist for MX Message-ID: <1994Feb28.160953.1168@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 28 Feb 94 16:09:52 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097ABE5.D1F9BF78.22606@CVAX.IPFW.INDIANA.EDU>, koenig@CVAX.IPFW.INDIANA.EDU writes: >>From: "Brian Tillman" >>Subj: RE: wishlist for MX >> >>George D. Greenwade (bed_gdg@SHSU.edu) writes: >> >>>With all due respect, why don't you bother the QuickMail people about this? >>>Matt, first, and now Hunter went to great pains to make MX about the most >>>RFC-compliant mailer available for *any* platform anywhere. How MX handles >>>personal name strings is not a problem following any standards. >> >>While I agree with the first two sentences, I'll disagree with the third >>somewhat. MX will not handle a reply a From: line that looks like this: >> >>From: Some Body >> >>From what I understand, this _should_ be acceptable. > >I don't think it is. I was wondering about this last week during the problem >that I was working on and checked RFC 822. See if you agree: Well, there are examples in RFC822, such as section A.2.1, which show the following, which, I assume (as it is shown as an example, was intended to be valid): From: George Jones >From what I read, "authentic" is the first choice, so it's a "From:" followed >by a "mailbox". "Mailbox" is obviously not a "local-part@domain" since it has >text in front, so it must be the "phrase route-addr" choice. The "phrase" >part has to be one or more "word" items which could either be an "atom" or >a "quoted-string". Since it's not a "quoted-string" let's look at the "atom" >definition. An "atom" is defined as one or more CHAR except specials, SPACE, >or CTLs. So, the space in the proposed atom at the beginning invalidates it >as an atom and we find that we must use a "quoted-string" instead. But section 3.1.4 reads: 3.1.4. STRUCTURED FIELD BODIES To aid in the creation and reading of structured fields, the free insertion of linear-white-space (which permits folding by inclusion of CRLFs) is allowed between lexical tokens. Rather than obscuring the syntax specifications for these structured fields with explicit syntax for this linear-white- space, the existence of another "lexical" analyzer is assumed. This analyzer does not apply for unstructured field bodies that are simply strings of text, as described above. The analyzer provides an interpretation of the unfolded text composing the body of the field as a sequence of lexical sym- bols. >Do you agree? I'm still uncertain that I'm reading the BNF exactly correctly, >so I very well could be incorrect. If I am correct, however, MX is doing >exactly what it is supposed to be doing. You read the BNF just fine, but the "space" is excluded from the BNF! However, back to Brian's original statement that MX can't handle addresses of the form: From: Some Body I don't know where the failure's ocurring (I mean, I can TELNET to port 25 of my system and issue a From: line like this and things work out with no problem....?). -d -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Tue, 01 Mar 1994 05:55:39 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 1 Mar 94 06:51:36 -0500 Message-ID: <9403011151.AA12632@genrad.com> From: dongray@genrad.com (Derek Dongray) Reply-To: MX-List@WKUVX1.WKU.EDU X-MX-Warning: Warning -- Invalid "To" header. To: "mx-list@wkuvx1.wku.edu" CC: Subject: RE: wishlist for MX >>From: Some Body >> >>From what I understand, this _should_ be acceptable. > > I don't think it is. I was wondering about this last week during the problem > that I was working on and checked RFC 822. See if you agree: > > authentic = "From" ":" mailbox ; Single author > / ("Sender" ":" mailbox ; Actual submittor > "From" ":" 1#mailbox) ; Multiple authoris > ; or not sender > > mailbox = addr-spec ; simple address > / phrase route-addr ; name & addr-spec > > addr-spec = local-part "@" domain ; global address > > phrase = 1*word > > word = atom / quoted-string > > route-addr = "<" [route] addr-spec ">" > > From what I read, "authentic" is the first choice, so it's a "From:" followed > by a "mailbox". "Mailbox" is obviously not a "local-part@domain" since it has > text in front, so it must be the "phrase route-addr" choice. The "phrase" > part has to be one or more "word" items which could either be an "atom" or ^^^^^^^^^^^ > a "quoted-string". Since it's not a "quoted-string" let's look at the "atom" > definition. An "atom" is defined as one or more CHAR except specials, SPACE, > or CTLs. So, the space in the proposed atom at the beginning invalidates it > as an atom and we find that we must use a "quoted-string" instead. You give the answer yourself. The space simply makes the phrase consist of more than one atom. No problem. >>Brian >>tillman_brian@si.com > Greg Koenig koenig@cvax.ipfw.indiana.edu ------------------------------------------------------------------------------ Name :Derek Dongray, Systems Manager, GenRad Ltd. Phone :061 486 1511 InterNet : Dongray@GenRad.com UKnet : Derek.Dongray@GenRad.co.uk PSS : 234261600119::Dongray CompuServe : 70374,2745 Address : Monmouth House, Monmouth Road, Cheadle Hulme, Cheshire, SK8 7AY, UK. ================================================================================ Archive-Date: Tue, 01 Mar 1994 10:03:46 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 01 Mar 1994 09:40:21 CST From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: koenig@cvax.ipfw.indiana.edu, tillman_brian@si.com Message-ID: <0097AC6F.76DDBE20.8697@SHSU.edu> Subject: RE: wishlist for MX Didn't mean to start a technical mini-flame war, but it seems we do this about every 18 months or so...... so........ On Mon, 28 Feb 1994 17:15:04 EST, Greg Koenig posted: > >From: "Brian Tillman" > >Subj: RE: wishlist for MX > > > >George D. Greenwade (bed_gdg@SHSU.edu) writes: > > > >>With all due respect, why don't you bother the QuickMail people about this? > >>Matt, first, and now Hunter went to great pains to make MX about the most > >>RFC-compliant mailer available for *any* platform anywhere. How MX handles > >>personal name strings is not a problem following any standards. > > > >While I agree with the first two sentences, I'll disagree with the third > >somewhat. MX will not handle a reply a From: line that looks like this: > > > >From: Some Body > > > >From what I understand, this _should_ be acceptable. > > I don't think it is. I was wondering about this last week during the > problem that I was working on and checked RFC 822. See if you agree: [definitions from RFC 822 removed] > > From what I read, "authentic" is the first choice, so it's a "From:" > followed by a "mailbox". "Mailbox" is obviously not a "local-part@domain" > since it has text in front, so it must be the "phrase route-addr" choice. > The "phrase" part has to be one or more "word" items which could either be > an "atom" or a "quoted-string". Since it's not a "quoted-string" let's > look at the "atom" definition. An "atom" is defined as one or more CHAR > except specials, SPACE, or CTLs. So, the space in the proposed atom at the > beginning invalidates it as an atom and we find that we must use a > "quoted-string" instead. > > Accordingly, we could have: > > From: Somebody > > as long as there was no space in it because the whole name would be > considered an atom. > > Do you agree? I'm still uncertain that I'm reading the BNF exactly > correctly, so I very well could be incorrect. If I am correct, however, MX > is doing exactly what it is supposed to be doing. Greg is correct in that > From: Somebody would be valid. However, unless our implementation is different that Brian's, I really (and respectfully) doubt that he has ever had a MX-reported error or warning about > >From: Some Body being a bad address. From RFC822 (line 906, et seq.) The one exception to this rule is that a single SPACE is assumed to exist between contiguous words in a phrase, and this interpretation is independent of the actual number of LWSP-chars that the creator places between the words. To include more than one SPACE, the creator must make the LWSP- chars be part of a quoted-string. Further, the address > >From: Some Z Body should be fine. Were MX issues a warning about a bad From: line is when it alternately reads: > >From: Some Z. Body due to the presence of the period following the Z above. This is hinted at in lines 819, et seq.: 3.4.2. WHITE SPACE Note: In structured field bodies, multiple linear space ASCII characters (namely HTABs and SPACEs) are treated as single spaces and may freely surround any symbol. In all header fields, the only place in which at least one LWSP-char is REQUIRED is at the beginning of continua- tion lines in a folded field. When passing text to processes that do not interpret text according to this standard (e.g., mail protocol servers), then NO linear-white-space characters should occur between a period (".") or at-sign ("@") and a . Exactly ONE SPACE should be used in place of arbitrary linear-white-space and comment sequences. Since the period is explicitly NOT included as an exception and may be used to separate atoms. Thus, while: > >From: Some Z. Body is an erroneous From line, > >From: "Some Z. Body" is not. It is between these two items that MX will complain since the first does not meet requirements for long line handling of comments, but the second does. This is one of the nicer features of VMSmail personal name string handling -- automatic quoting of these strings which users never have to even be aware of. Few other mail systems attaching personal names provide this safety net -- it is those that do not which create MX complaints you often see. Which is another reason that using the personal name string algorithm of VMSmail/MX is the way to go -- it is pre-idiot-proofed, correct, and consistent unlike very few other approaches. Refer to some of the discussion in Appendix A to RFC 822 and tie it in with a laboriously close reading of how it illustrates the requiments set out in the RFC and you'll see that this is correct (in concept, if not precisely in the technical jargon used in that document). Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ================================================================================ Archive-Date: Tue, 01 Mar 1994 10:05:50 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: RE: wishlist for MX Message-ID: <1994Mar1.084949.1169@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 1 Mar 94 08:49:48 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <1994Feb28.160953.1168@buckie.hsc.colorado.edu>, dwing@uh01.Colorado.EDU (Dan Wing) writes: >However, back to Brian's original statement that MX can't handle addresses >of the form: > > From: Some Body > >I don't know where the failure's ocurring (I mean, I can TELNET to port 25 >of my system and issue a From: line like this and things work out with >no problem....?). Brian reminded me of the problem (which I mentioned on MX-LIST previously, I believe) with MX. The problem usually shows up when mail is attempted from BULLETIN, as when you're using BULLETIN's "news" features it (Bulletin) grabs the contents of the From: header, sticks MX%"" around the contents of the From: header, and tries to mail it. MX doesn't like this; for example: MAIL> send To: mx%"danwing " MX rewrote danwing as Subj: hi Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit: is wrong -- MX should have either dropped the leading text (the "phrase" immediately preceeding the "route-addr", from section 6.1 of RFC822), or MX's router needs to properly handle the presence of a phrase -- the router gets confused and tries to send mail to the address which is an invalid address. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Tue, 01 Mar 1994 11:46:44 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 01 Mar 1994 12:06:29 EST From: "Brian Tillman" Reply-To: MX-List@WKUVX1.WKU.EDU To: SHSU.edu!bed_gdg@esseye.si.com CC: mx-list@wku.edu Message-ID: <0097AC83.E0F5AFC0.10684@swdev.si.com> Subject: MX and valid addresses (was RE: wishlist for MX) George D. Greenwade (bed_gdg@SHSU.edu) writes: >Didn't mean to start a technical mini-flame war, but it seems we do this about >every 18 months or so...... so........ No flames intended. Just some head scratching. Here's a clarification: MX may well recognize a From: line as you describe on an *incoming* message (i.e., received via SMTP). In fact, since you've demonstrated it so well, I'm sure you're correct. What it doesn't recognize, however, is an address of that form on an *outgoing* message (i.e., MX_MAILSHR has a problem). I get a router rejection notice if I try to send a message via VMS Mail addressed like this: MAIL> send To: mx%"Some Body " MX_MAILSHR converts this to: To: SomeBody) Error: Invalid address. Message follows. Received: by swdev.si.com (MX V3.3 VAX) id 10649; Tue, 01 Mar 1994 11:41:22 EST Date: Tue, 01 Mar 1994 11:41:15 EST From: Brian Tillman X-MX-Warning: Warning -- Invalid "To" header. To: SomeBody Subject: Test So, perhaps we're both correct. -- Brian tillman_brian@si.com ================================================================================ Archive-Date: Tue, 01 Mar 1994 13:31:55 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 01 Mar 1994 11:27:25 PST From: "John F. Sandhoff" Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wkuvx1.wku.edu Message-ID: <0097AC7E.6BE474A0.31623@CCVAX.CCS.CSUS.EDU> Subject: VMSMail is NOT idiotproof (was: RE: wishlist for MX) > Didn't mean to start a technical mini-flame war Ah, it's always good to review those RFC's :-) > ...This is one of the nicer features of VMSmail personal > name string handling -- automatic quoting of these strings which users > never have to even be aware of. > > Few other mail systems attaching personal names provide this safety net -- > it is those that do not which create MX complaints you often see. Which is > another reason that using the personal name string algorithm of VMSmail/MX > is the way to go -- it is pre-idiot-proofed, correct, and consistent unlike > very few other approaches. Idiot-proof? VMSMail? Come meet my users! Here's a really quick way to get hosed by VMSMail: MAIL> SET PERSONAL NAME "John F. Sandhoff" Now, being clever I of course quoted the personal name string. But being not-clever-enough I did *not* use the proper command. The command is 'set personal_name' which can be abbreviated 'set pers' so I fed AS AN ARGUMENT the string 'NAME "John F. Sandhoff"': MAIL> SHOW PERS Your personal name is "NAME "John F Sandhoff"". Note the double quotes. And when a message is sent the headers are: Date: Tue, 01 Mar 1994 11:11:57 PST X-MX-Warning: Warning -- Invalid "From" header. From: "NAME John F Sandhoff\\"" The message delivers, but sometimes I *also* get a message from the local (VAX) Postmaster, with a subject of SMTP delivery error, *and* from Unix mailer-daemons that touched the message (Rcvd: 554 Unbalanced '"'). No, I'm not asking for a fix. No, I'm not bashing VMSMail (much). But idiot-proof??? I think not... John F. Sandhoff, University Network Support California State University, Sacramento - USA sandhoff@csus.edu ================================================================================ Archive-Date: Tue, 01 Mar 1994 14:38:10 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 01 Mar 1994 15:32:04 CST From: Ian Vaz Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wkuvx1.wku.edu Message-ID: <0097ACA0.991F01C0.14321@mars.senecac.on.ca> Subject: Sending mail to a uucp node? Hello, I have managed to send mail to a "uucp" machine that is not on the Internet, i.e., To: mx%"username@machine.uucp" Questions: How does MX figure out where on earth to send this message to? I have not implemented any nifty re-write rule, so who does? MX has a default? If so, what is it and how could I have dug this information up myself? Thanks for any advise. Regards, Ian Vaz, Seneca College, Toronto, Ontario (416)491-5050 x 7252 ian@{mars | phobos}.senecac.on.ca ================================================================================ Archive-Date: Tue, 01 Mar 1994 15:13:22 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: david@hccw.com Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Problem installing 3.3 on MicroVax 3100 Message-ID: <1994Feb28.164718.107@hccw.com> Date: 28 Feb 94 16:47:18 PST To: MX-List@WKUVX1.WKU.EDU I just installed MX 3.3 on my MicroVax 3100 running VMS 5.3. Inorder to get it to install, I had to modify KITINSTAL.COM. The problem is in returning the hardware name, I get the string "MicroVax" and the command file is looking for "VAX" (I have another 3100 that does return the string "MicroVAX"). To fix the problem, all I had to do was to convert the hardware name to upper case before looking for the string "VAX". -- David R. Robison VP Development Phone : (702) 364-8633 Health Care Computer Works Fax : (702) 364-8633 Las Vegas, NV EMail : david@hccw.com ================================================================================ Archive-Date: Tue, 01 Mar 1994 16:25:26 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: mark@infocomm.com (Mark Pizzolato 510-837-5600) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Possible SMTP protocol bug Message-ID: <1994Mar1.133339.25785@infopiz> Date: 1 Mar 94 13:33:39 PST To: MX-List@WKUVX1.WKU.EDU I seem to have found a case where MX doesn't conform to the detail of the SMTP spec (RFC821). It happens that the machine doing our SMTP mailing, has more than one network interface. Both interface addresses are available from our dns server to anyone who asks. A particular remote site (ATTMAIL.COM) has an SMTP implementation which is checking the IP address of the current connection with the domain name that is supplied on the SMTP HELO message, and if what it thinks is the "correct" address doesn't match, it returns a "warning" message as part of the "successful" response to the HELO message: A problem occurred during SMTP delivery of your message. Error occurred sending to the following user(s): (via bwm3sf1.attmail.com): %MX_SMTP-F-UNKNOWN_REPLY_C, reply code !UL not known Transcript: Rcvd: 220 pjl53wo.i-p.attmail.com SMTP Service ready Sent: HELO vs4000.infocomm.com Rcvd: 208 WARNING: Invalid calling IP address for vs4000.infocomm.com [192.101.151.1] ======================================================================== Appendix E of RFC821 seems to indicate that MX should take this response as a "successful completion". Am I reading this correctly? If so, can a more flexible interpretation be implemented for the next release? -- Mark Pizzolato - INFO COMM Computer Consulting, Danville, Ca PHONE: (510)837-5600 UUCP: decwrl!infopiz!mark or uunet!lupine!infopiz!mark DOMAIN: mark@infocomm.com RFC 821 August 1982 Simple Mail Transfer Protocol APPENDIX E Theory of Reply Codes The three digits of the reply each have a special significance. The first digit denotes whether the response is good, bad or incomplete. An unsophisticated sender-SMTP will be able to determine its next action (proceed as planned, redo, retrench, etc.) by simply examining this first digit. A sender-SMTP that wants to know approximately what kind of error occurred (e.g., mail system error, command syntax error) may examine the second digit, reserving the third digit for the finest gradation of information. There are five values for the first digit of the reply code: 1yz Positive Preliminary reply The command has been accepted, but the requested action is being held in abeyance, pending confirmation of the information in this reply. The sender-SMTP should send another command specifying whether to continue or abort the action. [Note: SMTP does not have any commands that allow this type of reply, and so does not have the continue or abort commands.] 2yz Positive Completion reply The requested action has been successfully completed. A new request may be initiated. 3yz Positive Intermediate reply The command has been accepted, but the requested action is being held in abeyance, pending receipt of further information. The sender-SMTP should send another command specifying this information. This reply is used in command sequence groups. 4yz Transient Negative Completion reply The command was not accepted and the requested action did not occur. However, the error condition is temporary and the action may be requested again. The sender should [Page 48] Postel RFC 821 August 1982 Simple Mail Transfer Protocol return to the beginning of the command sequence (if any). It is difficult to assign a meaning to "transient" when two different sites (receiver- and sender- SMTPs) must agree on the interpretation. Each reply in this category might have a different time value, but the sender-SMTP is encouraged to try again. A rule of thumb to determine if a reply fits into the 4yz or the 5yz category (see below) is that replies are 4yz if they can be repeated without any change in command form or in properties of the sender or receiver. (E.g., the command is repeated identically and the receiver does not put up a new implementation.) 5yz Permanent Negative Completion reply The command was not accepted and the requested action did not occur. The sender-SMTP is discouraged from repeating the exact request (in the same sequence). Even some "permanent" error conditions can be corrected, so the human user may want to direct the sender-SMTP to reinitiate the command sequence by direct action at some point in the future (e.g., after the spelling has been changed, or the user has altered the account status). The second digit encodes responses in specific categories: x0z Syntax -- These replies refer to syntax errors, syntactically correct commands that don't fit any functional category, and unimplemented or superfluous commands. x1z Information -- These are replies to requests for information, such as status or help. x2z Connections -- These are replies referring to the transmission channel. x3z Unspecified as yet. x4z Unspecified as yet. x5z Mail system -- These replies indicate the status of the receiver mail system vis-a-vis the requested transfer or other mail system action. The third digit gives a finer gradation of meaning in each category specified by the second digit. The list of replies Postel [Page 49] August 1982 RFC 821 Simple Mail Transfer Protocol illustrates this. Each reply text is recommended rather than mandatory, and may even change according to the command with which it is associated. On the other hand, the reply codes must strictly follow the specifications in this section. Receiver implementations should not invent new codes for slightly different situations from the ones described here, but rather adapt codes already defined. ================================================================================ Archive-Date: Tue, 01 Mar 1994 17:25:30 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: Problem installing 3.3 on MicroVax 3100 Message-ID: <1994Mar1.155644.1182@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 1 Mar 94 15:56:43 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <1994Feb28.164718.107@hccw.com>, david@hccw.com writes: >I just installed MX 3.3 on my MicroVax 3100 running VMS 5.3. > >Inorder to get it to install, I had to modify KITINSTAL.COM. >The problem is in returning the hardware name, I get the >string "MicroVax" and the command file is looking for "VAX" >(I have another 3100 that does return the string "MicroVAX"). > >To fix the problem, all I had to do was to convert the hardware >name to upper case before looking for the string "VAX". Funky! The KITINSTAL in MX V4.0-beta fixes this problem by using the value of F$GETSYI("HW_MODEL") to determine the architecture. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Tue, 01 Mar 1994 17:26:05 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: Sending mail to a uucp node? Message-ID: <1994Mar1.155831.1183@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 1 Mar 94 15:58:31 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097ACA0.991F01C0.14321@mars.senecac.on.ca>, Ian Vaz writes: >Hello, >I have managed to send mail to a "uucp" machine that is not on the >Internet, i.e., > To: mx%"username@machine.uucp" >Questions: How does MX figure out where on earth to send this message > to? I have not implemented any nifty re-write rule, so > who does? MX has a default? If so, what is it and how > could I have dug this information up myself? Well, the "normal" rewrite rule, mentioned in the MX_DOC:MGMT_GUIDE.TXT, is: DEFINE PATH *.UUCP SMTP/ROUTE=uunet.uu.net You may have a similar setup. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Tue, 01 Mar 1994 17:39:54 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: Possible SMTP protocol bug Message-ID: <1994Mar1.160556.1184@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 1 Mar 94 16:05:56 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <1994Mar1.133339.25785@infopiz>, mark@infocomm.com (Mark Pizzolato 510-837-5600) writes: > Transcript: > Rcvd: 220 pjl53wo.i-p.attmail.com SMTP Service ready > Sent: HELO vs4000.infocomm.com > Rcvd: 208 WARNING: Invalid calling IP address for vs4000.infocomm.com [192.101.151.1] > ======================================================================== > >Appendix E of RFC821 seems to indicate that MX should take this response >as a "successful completion". > >Am I reading this correctly? FWIW, I think you're right. >If so, can a more flexible interpretation be >implemented for the next release? Hunter's on vacation for the next two weeks, but this should be easy to change in MX, and, IMO, necessary based on: >... > The first digit denotes whether the response is good, bad or > incomplete. An unsophisticated sender-SMTP will be able to > determine its next action (proceed as planned, redo, retrench, > etc.) by simply examining this first digit. >... -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Tue, 01 Mar 1994 21:17:28 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 01 Mar 1994 23:13:32 AST From: "Bruce S." Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097ACE1.10170918.2621@goat.drea.dnd.ca> Subject: Can anybody here tell me the status of BLISS for ALPHAs? Hello, Am I correct in assuming that MX033 for the AXP was built on a VAX using a BLISS Cross Compiler? If I am, perhaps someone can tell me what they've heard from DEC about the availability of this cross-compiler and what the future holds for said cross-compiler. The local DEC office tells me that this cross compiler was part of the Application Migration Toolkit, that it is only available to Application Migration Centers, that it won't run on VMS 6.0 and never will! I know that DEC has a BLISS-64 compiler for AXP, but I have been told that it is not available as a product. I have had a BLISS-32 license since 1985 and I'm not getting good vibes about continued support for BLISS on the AXP's. Can anyone verify or deny any of this? What does the future hold for MX on AXPs? Can someone point me to a copy of the mms rules for building MX on AXP (WKU$ROOT:[DATA]CROSS_ALPHA.MMS)? Regards++ Bruce S. | Bruce S. Skinner | skinner@goat.drea.dnd.ca | | DEFENCE RESEARCH ESTABLISHMENT ATLANTIC | skinner@hoss.drea.dnd.ca | | Dartmouth, Nova Scotia, CANADA, B2Y 3Z7 | (902) 426-3100 (205) | ================================================================================ Archive-Date: Wed, 02 Mar 1994 07:02:24 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: system@orion.cmc.uab.edu (Tim Buckner) Subject: error using mx_post %DCL-E-NOTFR, no transfer address Message-ID: <2MAR199406321160@orion.cmc.uab.edu> Keywords: news to mail gateway Reply-To: MX-List@WKUVX1.WKU.EDU Date: Wed, 2 Mar 1994 12:32:00 GMT To: MX-List@WKUVX1.WKU.EDU I am looking for a way to use mail to read and post Usenet News. My set up includes MX 3.3, Multinet 3.2D, VMS 5.4-2, VNEWS 1.4, and GNU-C 2.3.3. I have tried the MX add-on called MX_POST and get this error in site-deliver.log when I try to post through the mailing list which in this example is called my_list. $ POST MX_ROOT:[SITE]SITE_MSG_7BE9CBA0_0097A79E_00000179.TMP;1 - "my_list@my.node.uni.edu" "newsgroup.to.gateway" - "my_list-Moderator@my.node.uni.edu" %DCL-E-NOTFR, no transfer address Any ideas on what I should do to make MX_POST work? Any other solutions that don't involve a news server? Any other solutions? Anybody else with a similar set up get MX_POST to work? Thanks, -- Tim Buckner - system@orion.cmc.uab.edu - buckner@topaz.decus.org -- Univ. Alabama at Birmingham Center for Macromolecular Crystallography 261 BHSB, Birmingham, AL 35294-0005 USA phone/fax:(205)934-1973/-0480 ================================================================================ Archive-Date: Wed, 02 Mar 1994 09:25:10 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: rbp@brown.edu (bob pasker) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Re: error using mx_post %DCL-E-NOTFR, no transfer address Date: Wed, 02 Mar 1994 10:02:08 -0500 Message-ID: To: MX-List@WKUVX1.WKU.EDU In article <2MAR199406321160@orion.cmc.uab.edu>, system@orion.cmc.uab.edu (Tim Buckner) wrote: > $ POST MX_ROOT:[SITE]SITE_MSG_7BE9CBA0_0097A79E_00000179.TMP;1 - > "my_list@my.node.uni.edu" "newsgroup.to.gateway" - > "my_list-Moderator@my.node.uni.edu" > %DCL-E-NOTFR, no transfer address > > Any ideas on what I should do to make MX_POST work? you have not linked the program correctly! did you misplace the "/SHARE" qualifier on the LINK command??? did you forget a main() function??? -- -- bob pasker -- brown u., dept. of history -- rbp@brown.edu -- ================================================================================ Archive-Date: Wed, 02 Mar 1994 09:40:29 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 2 Mar 94 10:20:39 -0500 Message-ID: <9403021520.AA29893@genrad.com> From: dongray@genrad.com (Derek Dongray) Reply-To: MX-List@WKUVX1.WKU.EDU X-MX-Warning: Warning -- Invalid "To" header. To: "mx-list@wkuvx1.wku.edu" CC: Subject: Re: Problem installing 3.3 on MicroVax 3100 > Funky! The KITINSTAL in MX V4.0-beta fixes this problem by using the value of ^^^^ > F$GETSYI("HW_MODEL") to determine the architecture. > > -Dan Wing, Systems Administrator, University Hospital, Denver > dwing@uh01.colorado.edu or wing@eisner.decus.org Was this previously the 3.4-beta? Or did I miss an announcement? ------------------------------------------------------------------------------ Name :Derek Dongray, Systems Manager, GenRad Ltd. Phone :061 486 1511 InterNet : Dongray@GenRad.com UKnet : Derek.Dongray@GenRad.co.uk PSS : 234261600119::Dongray CompuServe : 70374,2745 Address : Monmouth House, Monmouth Road, Cheadle Hulme, Cheshire, SK8 7AY, UK. ================================================================================ Archive-Date: Wed, 02 Mar 1994 10:09:12 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: Can anybody here tell me the status of BLISS for ALPHAs? Message-ID: <1994Mar2.084007.1188@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 2 Mar 94 08:40:06 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097ACE1.10170918.2621@goat.drea.dnd.ca>, "Bruce S." writes: >Hello, > > Am I correct in assuming that MX033 for the AXP was built on a VAX >using a BLISS Cross Compiler? Yes, it was. > If I am, perhaps someone can tell me what they've heard from DEC >about the availability of this cross-compiler and what the future >holds for said cross-compiler. The local DEC office tells me that >this cross compiler was part of the Application Migration Toolkit, >that it is only available to Application Migration Centers, that it >won't run on VMS 6.0 and never will! > > I know that DEC has a BLISS-64 compiler for AXP, but I have been told >that it is not available as a product. I have had a BLISS-32 license >since 1985 and I'm not getting good vibes about continued support for >BLISS on the AXP's. > > Can anyone verify or deny any of this? What does the future hold >for MX on AXPs? > > Can someone point me to a copy of the mms rules for building MX on AXP >(WKU$ROOT:[DATA]CROSS_ALPHA.MMS)? MX V3.3 source code is available on ftp.spc.edu in [.mx033]. The source code, is full blown and should allow you to build MX from scratch. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Wed, 02 Mar 1994 10:49:38 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: Problem installing 3.3 on MicroVax 3100 Message-ID: <1994Mar2.091118.1190@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 2 Mar 94 09:11:18 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <9403021520.AA29893@genrad.com>, dongray@genrad.com (Derek Dongray) writes: >> Funky! The KITINSTAL in MX V4.0-beta fixes this problem by using the value of > ^^^^ >> F$GETSYI("HW_MODEL") to determine the architecture. >> >> -Dan Wing, Systems Administrator, University Hospital, Denver >> dwing@uh01.colorado.edu or wing@eisner.decus.org > >Was this previously the 3.4-beta? Yes, it was. MX V3.4 was based on a relative queue file; there are apparently some, er, misfeatures of RMS wrt relative files; the relative file in V3.4 is much faster than the indexed queue file (used with all previous versions of MX). MX V4.0 is based on a sequential file for the queue file (using direct access to the queue file), and is even faster than the relative file (used in MX V3.4-beta). >Or did I miss an announcement? The only change is the next version of MX will be called V4.0 (and not V3.4). -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Wed, 02 Mar 1994 11:28:45 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: joel@eddie.fac.cornell.edu (Joel Bender) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Non-registered hosts Date: 2 Mar 1994 16:13:49 GMT Message-ID: To: MX-List@WKUVX1.WKU.EDU I'm doing the installation of MX 3.3 on a node in a VAXcluster that is sitting on the internet but does not have a fully qualified domain name. All the users that need access to the node have the IP address defined in their local host table so they can get to it running applications like Fetch and NCSA Telnet on their Macs. My concept is to set up a mailing list on this cluster that I can use to broadcast update notifications, scheduled shutdowns, etc. I'll be the postmaster (manage subscription requests, etc.), and set it up so the users have access to the list archives and can post messages. Can you see any flaws in this setup? Yes, I understand that keeping the node name off the net isn't a perfect security solution because there are programs out there that seek out nodes to break into (by pinging all of the addresses in a subnet), and the use of MX may be a motivating factor to get at least one of the VAXen named. Joel joel@eddie.fac.cornell.edu #include ================================================================================ Archive-Date: Wed, 02 Mar 1994 12:17:49 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 02 Mar 1994 10:13:11 PST From: robert@dis.ucsf.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097AD3D.36F75C20.4590@dis.ucsf.edu> Subject: personal name Does anyone know of a way to have MX only use a personal name on outgoing mail (in my case, anything with a "@" in the address)? Using personal names in the office drives everyone nuts. Getting inter-office mail from senders like "ROBERT Robert Weiner" is annoying. I realize I could define two symbols for mail, one for internal and one for external, each with different personal names. But I'd have to exit mail each time I switched between the two, or manually reset the personal name. Since I probably get over 100 messages a day this would be a huge pain. Robert Weiner Manager, Development Information Systems UC San Francisco ================================================================================ Archive-Date: Wed, 02 Mar 1994 12:22:17 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 02 Mar 1994 13:17:45 EST From: "Jonathan E. Hardis" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: hardis@garnet.nist.gov Message-ID: <0097AD56.FFBD5560.5385@garnet.nist.gov> Subject: RE: Sending mail to a uucp node? > I have managed to send mail to a "uucp" machine that is not on the > Internet, i.e., To: mx%"username@machine.uucp" > Questions: How does MX figure out where on earth to send this message to? Look in CONFIG.MCP: DEFINE PATH *.UUCP SMTP/ROUTE="uunet.uu.net" UUnet then figures out where on earth to send the message to. - Jonathan ================================================================================ Archive-Date: Wed, 02 Mar 1994 13:09:15 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: Non-registered hosts Message-ID: <1994Mar2.114946.1192@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 2 Mar 94 11:49:46 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article , joel@eddie.fac.cornell.edu (Joel Bender) writes: >I'm doing the installation of MX 3.3 on a node in a VAXcluster that is >sitting on the internet but does not have a fully qualified domain name. >All the users that need access to the node have the IP address defined in >their local host >table so they can get to it running applications like Fetch and NCSA Telnet >on their Macs. > >My concept is to set up a mailing list on this cluster that I can use to >broadcast update notifications, scheduled shutdowns, etc. I'll be the >postmaster (manage subscription requests, etc.), and set it up so the users >have access to the list archives and can post messages. > >Can you see any flaws in this setup? > >Yes, I understand that keeping the node name off the net isn't a perfect >security solution because there are programs out there that seek out nodes >to break into (by pinging all of the addresses in a subnet), and the use of >MX may be a motivating factor to get at least one of the VAXen named. It sounds like your VAX is not entered into your DNS to provide a little security; a better solution, IMO, would be to setup two DNSs -- one is known to the Internet and contains all the "public" hosts you want other sites to see, and the other DNS is what all of your local nodes point to, and contains all of your hosts. That is much, much, much better than having users use IP addresses -- that can get really messy if a host moves to a different building (and would have its IP address changed), for example. In addition to two DNSs, you'd want a firewall system, or at least a configurable router, to prevent incoming ICMP, UDP, and possibly all TCP connections to your internal hosts -- that will help out your security a bit. There is a firewalls mailing list; send mail to Majordomo@GreatCircle.COM with the command "SUBSCRIBE FIREWALLS your_name" to subscribe. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Wed, 02 Mar 1994 13:25:18 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: personal name Message-ID: <1994Mar2.120018.1193@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 2 Mar 94 12:00:18 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097AD3D.36F75C20.4590@dis.ucsf.edu>, robert@dis.ucsf.edu writes: >Does anyone know of a way to have MX only use a personal name on >outgoing mail (in my case, anything with a "@" in the address)? Using >personal names in the office drives everyone nuts. Getting inter-office >mail from senders like "ROBERT Robert Weiner" is annoying. I realize >I could define two symbols for mail, one for internal and one for >external, each with different personal names. But I'd have to exit >mail each time I switched between the two, or manually reset the >personal name. Since I probably get over 100 messages a day this >would be a huge pain. As MX gets the personal name from VMSmail (which gets it from VMSMAIL_PROFILE), no, this isn't possible. You could setup a mail initialization file, and define, say, keys like: DEFINE/KEY/TERMINATE/noECHO PF1 "SEND/EDIT/noPERSONAL_NAME" DEFINE/KEY/TERMINATE/noECHO PF2 "REPLY/EDIT/EXTRACT/noPERSONAL_NAME" DEFINE/KEY/TERMINATE/noECHO PF2 "FORWARD/EDIT/noPERSONAL_NAME" or something similar, and use the PF keys if you're sending internal mail. Or use MX for all of your mail, even your internal mail, and as MX doesn't include your personal name on the "New mail on node XXX from XXXX" broadcast message, hardly anyone will notice you have a personal name for internal mail! -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Wed, 02 Mar 1994 16:00:34 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 02 Mar 1994 15:56:33 CST From: Larry Horn Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: hornlo@okra.millsaps.edu Message-ID: <0097AD6D.2F44FD40.26599@okra.millsaps.edu> Subject: RE: personal name >external, each with different personal names. But I'd have to exit >mail each time I switched between the two, or manually reset the >personal name. Since I probably get over 100 messages a day this Not what you asked for, but it is a workaround.... The SEND and REPLY commands use the /PERSONAL_NAME="xxx" qualifier. Although I've not tried this, you should be able to define keys for internal and external mail: MAIL> define/key PF3 "SEND/PERS=""ext 1234""" MAIL> define/key PF4 "SEND/PERS=""Joe Smith""" Using whatever keys and def/key qualifers you prefer. - ---------------------------------- 2-MAR-1994 15:56 C*T (USA) --- - Larry Horn / Millsaps College / Jackson, MS / hornlo@okra.millsaps.edu - ------------------------------------------------------------------ - ================================================================================ Archive-Date: Wed, 02 Mar 1994 16:43:34 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: wayne@tachyon.com (Wayne Sewell) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Re: VMSMail is NOT idiotproof (was: RE: wishlist for MX) Message-ID: <1994Mar2.135122.1197@tachyon.com> Date: 2 Mar 94 13:51:22 CST To: MX-List@WKUVX1.WKU.EDU In article <0097AC7E.6BE474A0.31623@CCVAX.CCS.CSUS.EDU>, "John F. Sandhoff" writes: [stuff about idiots and vmsmail deleted] > > No, I'm not asking for a fix. No, I'm not bashing VMSMail (much). But > idiot-proof??? I think not... > Absolutely *nothing* is idiot-proof. Anyone who says otherwise is unaware of the caliber of the idiots running loose out there. -- ============================================================================== Wayne Sewell |INET: wayne@tachyon.com Tachyon Software Consulting |UUCP: uupsi!uupsi6!tachyon!wayne P. O. Box 550937, Dallas TX 75355-0937 |Voice: (214)-553-9760, Fax: -553-0077 ============================================================================= To Sharon: "If I said you had a beautiful body, would you hold it against me?" ================================================================================ Archive-Date: Wed, 02 Mar 1994 16:43:59 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: wayne@tachyon.com (Wayne Sewell) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Re: VMSMail is NOT idiotproof (was: RE: wishlist for MX) Message-ID: <1994Mar2.135428.1198@tachyon.com> Date: 2 Mar 94 13:54:28 CST To: MX-List@WKUVX1.WKU.EDU In article <1994Mar2.135122.1197@tachyon.com>, wayne@tachyon.com (Wayne Sewell) writes: > In article <0097AC7E.6BE474A0.31623@CCVAX.CCS.CSUS.EDU>, "John F. Sandhoff" writes: > > [stuff about idiots and vmsmail deleted] > >> >> No, I'm not asking for a fix. No, I'm not bashing VMSMail (much). But >> idiot-proof??? I think not... >> > > Absolutely *nothing* is idiot-proof. Anyone who says otherwise is unaware of > the caliber of the idiots running loose out there. > I forgot to add: the best you can hope for is to make things idiot-resistant. ============================================================================== Wayne Sewell |INET: wayne@tachyon.com Tachyon Software Consulting |UUCP: uupsi!uupsi6!tachyon!wayne P. O. Box 550937, Dallas TX 75355-0937 |Voice: (214)-553-9760, Fax: -553-0077 ============================================================================= To Sharon: "If I said you had a beautiful body, would you hold it against me?" ================================================================================ Archive-Date: Wed, 02 Mar 1994 17:39:08 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: system@orion.cmc.uab.edu (Tim Buckner) Subject: Re: error using mx_post %DCL-E-NOTFR, no transfer address Message-ID: <2MAR199417021691@orion.cmc.uab.edu> Reply-To: MX-List@WKUVX1.WKU.EDU Date: Wed, 2 Mar 1994 23:02:00 GMT To: MX-List@WKUVX1.WKU.EDU >> $ POST MX_ROOT:[SITE]SITE_MSG_7BE9CBA0_0097A79E_00000179.TMP;1 - >> "my_list@my.node.uni.edu" "newsgroup.to.gateway" - >> "my_list-Moderator@my.node.uni.edu" >> %DCL-E-NOTFR, no transfer address >> >> Any ideas on what I should do to make MX_POST work? >> >you have not linked the program correctly! > >did you misplace the "/SHARE" qualifier on the LINK command??? > >did you forget a main() function??? I tried link post/opt and get the tranfer address warning $ link post/opt %LINK-W-USRTFR, image DUA0:[XTAL.MX.MX_POST.TMP]POST.EXE;4 has no user transfer address I tried link/share post/opt and I don't get the tranfer address warning. I get the tranfer address ERROR in site_deliver.log with either method of linking. Yes there is a main $ search post.c main main(argc, argv) If my linking is wrong, which is a still a strong possibility, I would be glad to have a pointer in the right direction. What should I try next? -- Tim Buckner - system@orion.cmc.uab.edu - buckner@topaz.decus.org -- Univ. Alabama at Birmingham Center for Macromolecular Crystallography 261 BHSB, Birmingham, AL 35294-0005 USA phone/fax:(205)934-1973/-0480 ================================================================================ Archive-Date: Thu, 03 Mar 1994 12:27:58 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: Sending mail to a uucp node? Date: 3 Mar 1994 18:17:56 GMT Message-ID: <2l59kk$a19@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097ACA0.991F01C0.14321@mars.senecac.on.ca>, Ian Vaz writes: =I have managed to send mail to a "uucp" machine that is not on the =Internet, i.e., = To: mx%"username@machine.uucp" =Questions: How does MX figure out where on earth to send this message = to? I have not implemented any nifty re-write rule, so = who does? MX has a default? If so, what is it and how = could I have dug this information up myself? Check your path definitions. You might have something like: Domain="*.UUCP", Path=SMTP, Route="UUNET.UU.NET" If this is the case, then when the router encounters an address of the form username@machine.uucp, it will forward it to UUNET.UU.NET for processing. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Thu, 03 Mar 1994 14:13:59 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: wayne@tachyon.com (Wayne Sewell) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Re: error using mx_post %DCL-E-NOTFR, no transfer address Message-ID: <1994Mar3.080012.1207@tachyon.com> Date: 3 Mar 94 08:00:12 CST To: MX-List@WKUVX1.WKU.EDU In article <2MAR199417021691@orion.cmc.uab.edu>, system@orion.cmc.uab.edu (Tim Buckner) writes: >>> $ POST MX_ROOT:[SITE]SITE_MSG_7BE9CBA0_0097A79E_00000179.TMP;1 - >>> "my_list@my.node.uni.edu" "newsgroup.to.gateway" - >>> "my_list-Moderator@my.node.uni.edu" >>> %DCL-E-NOTFR, no transfer address >>> >>> Any ideas on what I should do to make MX_POST work? >>> >>you have not linked the program correctly! >> >>did you misplace the "/SHARE" qualifier on the LINK command??? >> >>did you forget a main() function??? > > I tried link post/opt and get the tranfer address warning > > $ link post/opt > %LINK-W-USRTFR, image DUA0:[XTAL.MX.MX_POST.TMP]POST.EXE;4 has no user > transfer address > If you are using post/opt, you have a file called post.opt in the default directory or a logical name called post that points to an options file. What does that file look like? It may have some linker options that screw things up. > I tried link/share post/opt and I don't get the tranfer address > warning. I get the tranfer address ERROR in site_deliver.log with > either method of linking. > > Yes there is a main > > $ search post.c main > main(argc, argv) This doesn't make sense. If you have a main, you should have a transfer address. Maybe the compiler isn't seeing it. It could be part of a comment or something. Widen the window of your search to see more of the surrounding lines (/wind=30). Or look at it with the editor. Either way, make sure it's a valid C function that is not commented out. Another possibilty is that you aren't actually linking in the object (post.obj) at all. When you say "link post/opt", you are telling the linker to read the contents of the post.opt options file. Unless this file explicity references post.obj, it won't be included in the link! If you have no main, then you have no transfer address. Link with a map (link/map). At the very beginning, it lists the object modules that have been included in the link. You should see post.obj in the list. Look at the post.opt file. If it doesn't mention post.obj, then link this way: link post+post/opt -- ============================================================================== Wayne Sewell |INET: wayne@tachyon.com Tachyon Software Consulting |UUCP: uupsi!uupsi6!tachyon!wayne P. O. Box 550937, Dallas TX 75355-0937 |Voice: (214)-553-9760, Fax: -553-0077 ============================================================================= To Sharon: "If I said you had a beautiful body, would you hold it against me?" ================================================================================ Archive-Date: Thu, 03 Mar 1994 15:03:14 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: error using mx_post %DCL-E-NOTFR, no transfer address Date: 3 Mar 1994 20:45:55 GMT Message-ID: <2l5ia3$a19@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <2MAR199406321160@orion.cmc.uab.edu>, system@orion.cmc.uab.edu (Tim Buckner) writes: =I am looking for a way to use mail to read and post Usenet News. =My set up includes MX 3.3, Multinet 3.2D, VMS 5.4-2, VNEWS 1.4, and =GNU-C 2.3.3. = =I have tried the MX add-on called MX_POST and get this error in =site-deliver.log when I try to post through the mailing list which in =this example is called my_list. = =$ POST MX_ROOT:[SITE]SITE_MSG_7BE9CBA0_0097A79E_00000179.TMP;1 - = "my_list@my.node.uni.edu" "newsgroup.to.gateway" - = "my_list-Moderator@my.node.uni.edu" =%DCL-E-NOTFR, no transfer address = =Any ideas on what I should do to make MX_POST work? Sounds like MX_POST is a shareable, rather than an executable image. The error messages and recovery procedures manual isn't terribly helpful on this one, but, for what it's worth: NOTFR, no transfer address Facility: CLI, Command Language Interpreter (DCL) Explanation: The image file does not have a transfer address User Action: Check that the source program has specified a transfer address and, if necessary, reassemble and relink the program. How did you link the program? -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Thu, 03 Mar 1994 15:27:15 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Thu, 03 Mar 1994 13:22:48 PST From: robert@dis.ucsf.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097AE20.DEAEE760.4825@dis.ucsf.edu> Subject: Return address on MLF messages A member of a mailing list I set up says that the return address on messages from the list shows as system@dis.ucsf.edu, the list owner, rather than quodus@dis.ucsf.edu, the list address. He says that when he replys to a list message the reply only goes to system@dis. This recipient is receiving messages through CompuServe. Other recipients say the return address is correct. Does anyone know if this is a problem with CompuServe or if I need to change something in my list setup? I'm appending the list definition and a header from an outgoing list message that another recipient (who says the return address looks fine on her system) forwarded back to me. Robert Weiner UC San Francisco ================= Mailing lists: Name: quodus Owner: "system@DIS.UCSF.EDU" "robert@DIS.UCSF.EDU" Reply-to: List, NOSender Archive: MX_ROOT:[QUODUS] Add message: MX_ROOT:[QUODUS]QUODUS_ADD.TXT Description: List for Discussion of Quodata Software Errors-to: system@dis.ucsf.edu Strip header: Received Private list: No Protection: (SYSTEM:RWED,OWNER:RWED,GROUP:RWED,WORLD:E) =============== From: SMTP%"quodus@dis.ucsf.edu" 2-MAR-1994 22:29:01.20 To: cb_stu CC: Subj: who shows as the sender of this message? Return-Path: system@dis.ucsf.edu Received: by womenscol.stephens.edu (UCX V2.0-15) Wed, 2 Mar 1994 22:28:57 -0600 X-ListName: List for Discussion of Quodata Software Warnings-To: <> Errors-To: system@dis.ucsf.edu Sender: system@dis.ucsf.edu Date: Wed, 02 Mar 1994 20:29:25 PST From: robert@dis.ucsf.edu Reply-To: quodus@dis.ucsf.edu To: quodus@dis.ucsf.edu Message-ID: <0097AD93.4DBAE200.4689@dis.ucsf.edu> Subject: who shows as the sender of this message? ================================================================================ Archive-Date: Thu, 03 Mar 1994 15:49:16 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Thu, 03 Mar 1994 16:45:23 EST From: Mighty Firebreather Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: robert@dis.ucsf.edu Message-ID: <0097AE3D.2C20E360.2383@nscvax.princeton.edu> Subject: RE: Return address on MLF messages robert@dis.ucsf.edu writes: >A member of a mailing list I set up says that the return address on >messages from the list shows as system@dis.ucsf.edu, the list owner, >rather than quodus@dis.ucsf.edu, the list address. He says that when >he replys to a list message the reply only goes to system@dis. >This recipient is receiving messages through CompuServe. Other >recipients say the return address is correct. Does anyone know if >this is a problem with CompuServe or if I need to change something in >my list setup? I'm appending the list definition and a header from >an outgoing list message that another recipient (who says the return >address looks fine on her system) forwarded back to me. > >Robert Weiner >UC San Francisco >================= > >Mailing lists: > Name: quodus > Owner: "system@DIS.UCSF.EDU" > "robert@DIS.UCSF.EDU" > Reply-to: List, NOSender > Archive: MX_ROOT:[QUODUS] > Add message: MX_ROOT:[QUODUS]QUODUS_ADD.TXT > Description: List for Discussion of Quodata Software > Errors-to: system@dis.ucsf.edu > Strip header: Received > Private list: No > Protection: (SYSTEM:RWED,OWNER:RWED,GROUP:RWED,WORLD:E) > >=============== >From: SMTP%"quodus@dis.ucsf.edu" 2-MAR-1994 22:29:01.20 >To: cb_stu >CC: >Subj: who shows as the sender of this message? > >Return-Path: system@dis.ucsf.edu >Received: by womenscol.stephens.edu (UCX V2.0-15) > Wed, 2 Mar 1994 22:28:57 -0600 >X-ListName: List for Discussion of Quodata Software >Warnings-To: <> >Errors-To: system@dis.ucsf.edu >Sender: system@dis.ucsf.edu >Date: Wed, 02 Mar 1994 20:29:25 PST >From: robert@dis.ucsf.edu >Reply-To: quodus@dis.ucsf.edu >To: quodus@dis.ucsf.edu >Message-ID: <0097AD93.4DBAE200.4689@dis.ucsf.edu> >Subject: who shows as the sender of this message? > It sure looks to me as if CompuServe's mailer is not RFC 822 compliant. They appear to be using the "Sender" field as the reply address whereas section 4.4.4 of RFC 822 states that the "reply-to" field should be used. (See RFC 822 for details -- I'm too busy to type it all in.) Send a message to postmaster@compuserve.com, explain your problem and cite section 4.4.4 of RFC 822. I expect that they will fix it. They are pretty new to the internet mail game. ************************************************************************* * Here, there be dragons! * * dragon@nscvax.princeton.edu * * * * I'm job hunting. Any offers or leads will be appreciated. * * Thanks! * * Richard B. Gilbert * ************************************************************************* ================================================================================ Archive-Date: Thu, 03 Mar 1994 16:28:48 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: system@orion.cmc.uab.edu (Tim Buckner) Subject: Re: error using mx_post %DCL-E-NOTFR, no transfer address Message-ID: <3MAR199416012383@orion.cmc.uab.edu> Reply-To: MX-List@WKUVX1.WKU.EDU Date: Thu, 3 Mar 1994 22:01:00 GMT To: MX-List@WKUVX1.WKU.EDU The solution turned out to be simple. >Look at the post.opt file. If it doesn't mention post.obj, > then link this way: >link post+post/opt Thanks to the following people for helping, with a gold star to Wayne for the above solution. rbp@brown.edu (bob pasker) wayne@tachyon.com (Wayne Sewell) carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) -- Tim Buckner - system@orion.cmc.uab.edu - buckner@topaz.decus.org -- Univ. Alabama at Birmingham Center for Macromolecular Crystallography 261 BHSB, Birmingham, AL 35294-0005 USA phone/fax:(205)934-1973/-0480 ================================================================================ Archive-Date: Thu, 03 Mar 1994 16:54:03 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Thu, 03 Mar 1994 17:49:34 EST From: "Jonathan E. Hardis" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: hardis@garnet.nist.gov Message-ID: <0097AE46.236870E0.5482@garnet.nist.gov> Subject: RE: Return address on MLF messages > A member of a mailing list I set up says that the return address on > messages from the list shows as system@dis.ucsf.edu, the list owner, > rather than quodus@dis.ucsf.edu, the list address. Some badly designed mailers reply to the "Sender," rather then the "Reply-To" address. There is nothing you can do about that, other than to ask your recipient to complain to his management or software vendor. - Jonathan ================================================================================ Archive-Date: Thu, 03 Mar 1994 16:58:56 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Thu, 03 Mar 1994 15:54:30 -0700 From: "Ray Harwood -- Data Basix: (602)721-1988" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: rharwood@Data.Basix.COM Message-ID: <0097AE36.104A97A0.12803@Data.Basix.COM> Subject: RE: Return address on MLF messages > robert@dis.ucsf.edu writes: > > >A member of a mailing list I set up says that the return address on > >messages from the list shows as system@dis.ucsf.edu, the list owner, > >rather than quodus@dis.ucsf.edu, the list address. He says that when > >he replys to a list message the reply only goes to system@dis. > >This recipient is receiving messages through CompuServe. Other > >recipients say the return address is correct. Does anyone know if > >this is a problem with CompuServe or if I need to change something in > >my list setup? [...] > >Mailing lists: > > Name: quodus > > Owner: "system@DIS.UCSF.EDU" > > "robert@DIS.UCSF.EDU" > > Reply-to: List, NOSender > > Archive: MX_ROOT:[QUODUS] > > Add message: MX_ROOT:[QUODUS]QUODUS_ADD.TXT > > Description: List for Discussion of Quodata Software > > Errors-to: system@dis.ucsf.edu > > Strip header: Received > > Private list: No > > Protection: (SYSTEM:RWED,OWNER:RWED,GROUP:RWED,WORLD:E) Mighty Firebreather replied: > It sure looks to me as if CompuServe's mailer is not RFC 822 > compliant. They appear to be using the "Sender" field as the reply address > whereas section 4.4.4 of RFC 822 states that the "reply-to" field should be > used. (See RFC 822 for details -- I'm too busy to type it all in.) I have a list similarly constructed, with several CompuServe users subscribed, and to my knowledge there has been no problem replying to the list: Name: MD-List Owner: "MD-List-Owner@DATA.BASIX.COM" "rharwood@DATA.BASIX.COM" Reply-to: List, NOSender Archive: DUA2:[MD.ARCHIVES]ARCHIVES Add message: DUA2:[MD]MLIST_ADD_MESSAGE.TXT Description: Muscular Dystrophy - Patients, Family, & Friends Errors-to: RHARWOOD@BASIX.COM Strip header: Received Private list: No Protection: (SYSTEM:RWED,OWNER:RWED,GROUP:RWED,WORLD:WE) The only noticeable difference I see is the Prot=W:WE on my list, and only W:E on the quodus list. > Send a message to postmaster@compuserve.com, explain your problem > and cite section 4.4.4 of RFC 822. I expect that they will fix it. They > are pretty new to the internet mail game. CompuServe is NOT all that new to the Internet, and IMHO I doubt they would jump on any "opportunity" to change their code. Ray ----- Ray Harwood | Data Basix | DEC Pro Networking Editor Voice: (602)721-1988 | PO Box 18324 | "Internet Resource Guide" FAX: (602)721-7240 | Tucson, AZ 85731 | Adjunct Faculty, East Campus, RHarwood@Data.Basix.COM | Info@Data.Basix.COM | Pima Community College ================================================================================ Archive-Date: Thu, 03 Mar 1994 17:27:07 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Thu, 03 Mar 1994 16:19:39 -0700 From: "Ray Harwood -- Data Basix: (602)721-1988" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-LIST%WKUVX1.BITNET@ULKYVM.LOUISVILLE.EDU CC: rharwood@Data.Basix.COM Message-ID: <0097AE39.93AD8320.12815@Data.Basix.COM> Subject: "Monthly postings" routine to share? Does anyone have any pre-written routine that will generate a "monthly posting" with the interesting statistics that one often sees? I'd imagine such a thing would do the following. If one doesn't exist, I may write one (with probably a combination of DCL and Pascal, and I'd make the source and .EXEs available): 1. Generates an MCP SHOW LIST * 2. Scans the output for list names and their archive addresses 3. Scans the "last month" archives for message counts and poster's addresses 4. Summarizes message counts, poster counts. 5. Searches for a pre-defined "monthly posting" text file (with such things as how to sign off, how to change to digest & back, etc.) 6. Sends the summary results and text file to the list with the subject "Administrivia: Monthly Posting" 7. Re-submits itself to run on the same queue on the first of the next month. Other suggestions would be welcomed (I reserve the right to implement what *I* think is interesting!). For example, a SECOND posting of a FAQ file taken from a specific file name. Ray ----- Ray Harwood | Data Basix | DEC Pro Networking Editor Voice: (602)721-1988 | PO Box 18324 | "Internet Resource Guide" FAX: (602)721-7240 | Tucson, AZ 85731 | Adjunct Faculty, East Campus, RHarwood@Data.Basix.COM | Info@Data.Basix.COM | Pima Community College ================================================================================ Archive-Date: Thu, 03 Mar 1994 18:51:00 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Thu, 03 Mar 1994 16:47:20 PST From: robert@dis.ucsf.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097AE3D.71C234A0.5081@dis.ucsf.edu> Subject: RE: Return address on MLF messages Actually, I think the difference is that the first owner of Ray's list is the list address itself, whereas the first owner of my list is the system account. Perhaps if I change the primary owner the SENDER will change and CompuServe will handle the mail properly. I'll try this. Thanks for the suggestions. Robert Weiner ================ > > The only noticeable difference I see is the Prot=W:WE on my list, and only W:E > on the quodus list. > > ----- > Ray Harwood | Data Basix | DEC Pro Networking Editor > Voice: (602)721-1988 | PO Box 18324 | "Internet Resource Guide" > FAX: (602)721-7240 | Tucson, AZ 85731 | Adjunct Faculty, East Campus, > RHarwood@Data.Basix.COM | Info@Data.Basix.COM | Pima Community College ================================================================================ Archive-Date: Thu, 03 Mar 1994 23:05:17 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Thu, 03 Mar 1994 22:01:19 -0700 From: "Ray Harwood -- Data Basix: (602)721-1988" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: rharwood@Data.Basix.COM Message-ID: <0097AE69.4E9CB140.12912@Data.Basix.COM> Subject: RE: Return address on MLF messages robert@dis.ucsf.edu wrote: > Actually, I think the difference is that the first owner of Ray's list > is the list address itself, whereas the first owner of my list is the > system account. Perhaps if I change the primary owner the SENDER will > change and CompuServe will handle the mail properly. I'll try this. Actually, you should note that the first owner is not the LIST, but an alias called MD-List-Owner which does indeed point to me directly. It's done that way so that if I want to "pass the baton" to someone else, the list members don't have to remember a new address. I don't think changing the "first owner name" to the list itself will bring you anything but trouble! But I would be wrong... Ray ----- Ray Harwood | Data Basix | DEC Pro Networking Editor Voice: (602)721-1988 | PO Box 18324 | "Internet Resource Guide" FAX: (602)721-7240 | Tucson, AZ 85731 | Adjunct Faculty, East Campus, RHarwood@Data.Basix.COM | Info@Data.Basix.COM | Pima Community College ================================================================================ Archive-Date: Fri, 04 Mar 1994 11:00:58 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Fri, 04 Mar 1994 08:57:21 PST From: robert@dis.ucsf.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-LIST@WKUVX1.WKU.EDU Message-ID: <0097AEC4.F4174DA0.5146@dis.ucsf.edu> Subject: Header from MLF message received by CompuServe Below is the header from an MLF message received by a CompuServe subscriber. This is the first one I've seen where "robert" shows as the FROM address. Headers sent back by other subscribers properly showed "quodus" as the FROM address and REPLY-TO address, with "system" as the SENDER. "robert" is the originator of the message. After the CompuServe header I'm appending the header sent back from a VMS recipient for comparison. Any other ideas on this topic? I've sent mail to CompuServe, as has the subscriber having the problem. Is there anything I could do on my end? Given that CompuServe is treating the message's originator as the sender rather than the list owner, as I had originally understood, changing the primary list owner to be the list address doesn't seem like a solution (plus Ray H. predicts trouble). Robert Weiner Manager, Development Information Systems UC San Francisco ============ COMPUSERVE HEADER: > > Message ID: 223-49218 > Date: 3/2/94 22:33 > From: >INTERNET:robert@dis.ucsf.edu > Subject: who shows as the sender of this message? > > Sender: system@dis.ucsf.edu > Received: from DIS.UCSF.EDU by arl-img-2.compuserve.com (8.6.4/5.930129sam) > id XAA10683; Wed, 2 Mar 1994 23:32:47 -0500 > X-ListName: List for Discussion of Quodata Software > Warnings-To: <> > Errors-To: system@dis.ucsf.edu > Sender: system@dis.ucsf.edu > Date: Wed, 02 Mar 1994 20:29:25 PST > From: robert@dis.ucsf.edu > Reply-To: quodus@dis.ucsf.edu > To: quodus@dis.ucsf.edu > Message-ID: <0097AD93.4DBAE200.4689@dis.ucsf.edu> > Subject: who shows as the sender of this message? > ================ VMS HEADER: > From: SMTP%"quodus@dis.ucsf.edu" 2-MAR-1994 22:29:01.20 > To: cb_stu > CC: > Subj: who shows as the sender of this message? > > Return-Path: system@dis.ucsf.edu > Received: by womenscol.stephens.edu (UCX V2.0-15) > Wed, 2 Mar 1994 22:28:57 -0600 > X-ListName: List for Discussion of Quodata Software > Warnings-To: <> > Errors-To: system@dis.ucsf.edu > Sender: system@dis.ucsf.edu > Date: Wed, 02 Mar 1994 20:29:25 PST > From: robert@dis.ucsf.edu > Reply-To: quodus@dis.ucsf.edu > To: quodus@dis.ucsf.edu > Message-ID: <0097AD93.4DBAE200.4689@dis.ucsf.edu> > Subject: who shows as the sender of this message? ================================================================================ Archive-Date: Fri, 04 Mar 1994 11:04:48 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Fri, 04 Mar 1994 09:00:13 PST From: robert@dis.ucsf.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-LIST@WKUVX1.WKU.EDU Message-ID: <0097AEC5.5AD974A0.5148@dis.ucsf.edu> Subject: reply from CompuServe REPLY FROM COMPUSERVE: > From: MX%"POSTMASTER@CompuServe.COM" 4-MAR-1994 07:56:13.67 > Subj: Re: problem with how CompuServe mail interprets RFC822 headers > Mr. Weiner -- > > You're absolutely right. While our gateway is RFC822-compliant, our internal > mail system is not. Consequently, a reply to a message will go to the > address listed in the From: field. However, error messages are sent to > the Sender: field, as specified in section 4.4.4. > > This problem is one that should go away with time (it is currently being > addressed). > > Sherry Levasseur > postmaster@compuserve.com > ================================================================================ Archive-Date: Fri, 04 Mar 1994 14:07:37 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Fri, 04 Mar 1994 14:06:13 -0600 From: arlen.walker@JCI.Com (Arlen P. Walker) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Message doesn't go anywhere To: mx-list@wkuvx1.wku.edu Message-ID: <01H9KRVUN7XU0019PC@JCI.Com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT I brought MX up and sent out a test message, which has not been delivered. Obviously, I didn't get it right. But it's not obvious to me as to what I didn't get right. Does this info mean anything to anyone out there? Entry: 1, Origin: [Local] Status: IN-PROGRESS, size: 41 bytes Created: 2-MAR-1994 22:33:27.34, expires 1-APR-1994 22:33:27.34 Last modified 4-MAR-1994 13:38:47.77 SMTP entry #2, status: READY, size: 41 bytes, waiting for retry until 4-MAR-1 994 14:08:48.17 Created: 2-MAR-1994 22:33:54.46, expires 1-APR-1994 22:33:27.34 Last modified 4-MAR-1994 13:38:48.17 Recipient #1: , Route=jci.com Error count=79 Last error: %NONAME-E-NOMSG, Message number 08638162 As far as I can tell, it's telling me mail couldn't be delivered, and the error count is climbing, but there's no usable info in the error message. I'll continue on working on this, but I'm hoping it's something simple and obvious to someone out there. Pardon my ignorance, but I'm just getting started in the TCP Mail systems arena. Have Fun, Arlen --------------------------------------------------- This mail message contains 100% recycled electrons --------------------------------------------------- ================================================================================ Archive-Date: Fri, 04 Mar 1994 16:40:18 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Fri, 04 Mar 1994 17:35:55 EST From: "Jonathan E. Hardis" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: arlen.walker@JCI.Com, hardis@garnet.nist.gov Message-ID: <0097AF0D.65AD4940.5626@garnet.nist.gov> Subject: RE: Message doesn't go anywhere > I brought MX up and sent out a test message, which has not been delivered. > Obviously, I didn't get it right. But it's not obvious to me as to what I > didn't get right. Does this info mean anything to anyone out there? It would help tremendously if you enable debugging for some or all of the MX agents. The manual tells you how to enable debugging by setting VMS logical names. After turning on debugging, send another message to a remote site. Also send a message to yourself (MX%"name", that is, without any @address). Compare the logs that result. - Jonathan ================================================================================ Archive-Date: Fri, 04 Mar 1994 18:54:20 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: meadows@cslvax.weeg.uiowa.edu Subject: BASE64 Decoder?? Date: 4 Mar 1994 21:44:14 GMT Message-ID: <2l8a3e$i22@blue.weeg.uiowa.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Is there a BASE64 decoder available somewhere for VMS? I'm trying to deal with mail messages encoded in BASE64 on other systems, but do not have Content-Type: VMS-whatever, so mx passes it through. I can successfully EXTRACT these messages into a file, edit out the headers and other non-BASE64 stuff, ftp it to a UNIX box here, run a program called 'mimencode' with a -u option to decode the file, then ftp it back, and it is fine. I want to eliminate all that ftp-ing by finding a program similar to 'mimencode' on VMS that will decode those BASE64-encoded files. -Howard *************************************************************************** * Howard Meadows Sr. Systems Programmer Weeg Computing Center * * University Of Iowa Iowa City, Iowa 52242 Phone: 319-335-5519 * * email: howard-meadows@uiowa.edu FAX : 319-335-5505 * *************************************************************************** ================================================================================ Archive-Date: Fri, 04 Mar 1994 18:55:38 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: BASE64 Decoder?? Message-ID: <1994Mar4.154534.1218@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 4 Mar 94 15:45:33 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <2l8a3e$i22@blue.weeg.uiowa.edu>, meadows@cslvax.weeg.uiowa.edu writes: > Is there a BASE64 decoder available somewhere for VMS? MultiNet includes one: "$ MULTINET DECODE inputfile outputfile". MX V4.0 will include one; if you'd like the MX_DECODE.EXE from the MX V3.4-beta distribution, Email me directly and I'll send it to ya. >I'm trying >to deal with mail messages encoded in BASE64 on other systems, but >do not have Content-Type: VMS-whatever, so mx passes it through. Neither MultiNet V3.3 nor MX's V3.4-beta/V4.0-beta decode will decode such a file; I don't know if Hunter plans on changing this behavior. >I can successfully EXTRACT these messages into a file, edit out the >headers and other non-BASE64 stuff, ftp it to a UNIX box here, run a >program called 'mimencode' with a -u option to decode the file, then ftp >it back, and it is fine. I want to eliminate all that ftp-ing by finding a >program similar to 'mimencode' on VMS that will decode those BASE64-encoded >files. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Sat, 05 Mar 1994 09:32:02 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Sat, 05 Mar 1994 10:31:17 EST From: Erik Sironen Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wkuvx1.wku.edu CC: esironen@topcat.bsc.mass.edu Message-ID: <0097AF9B.3DA31A40.32487@topcat.bsc.mass.edu> Subject: Can't use File/Extract in Bulletin from captured account Hello, I have users that have captured accounts the accounts have access to bulletin, mail and kermit. In mail you can extract a message and then do a kermit transfer. In bulletin though if you try to extract a message using either the extract or file command you get the following error: ERROR: Command invalid from CAPTIVE account. I have been telling people to mail the message to themselves from bulletin then extract it. What I would like to know is there anyway to give these captured accounts the ability to extract messages from within bulletin. Thanks for your help Erik Sironen Academic Computing (508)697-1236 Bridgewater State College esironen@topcat.bsc.mass.edu Bridgewater, MA 02325 USA <-----------------------------------------------------------------------> <-----------------------------------------------------------------------> ================================================================================ Archive-Date: Sat, 05 Mar 1994 12:38:45 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: Message doesn't go anywhere Date: 5 Mar 1994 18:20:03 GMT Message-ID: <2laigj$46u@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <01H9KRVUN7XU0019PC@JCI.Com>, arlen.walker@JCI.Com (Arlen P. Walker) writes: =I brought MX up and sent out a test message, which has not been delivered. =Obviously, I didn't get it right. But it's not obvious to me as to what I =didn't get right. Does this info mean anything to anyone out there? = Created: 2-MAR-1994 22:33:54.46, expires 1-APR-1994 22:33:27.34 = Last modified 4-MAR-1994 13:38:48.17 = Recipient #1: , Route=jci.com = Error count=79 = Last error: %NONAME-E-NOMSG, Message number 08638162 = =As far as I can tell, it's telling me mail couldn't be delivered, and the =error count is climbing, but there's no usable info in the error message. There's a good chance that the error status is being produced by your TCP/IP software. What package are you using? Also, you'll probably get more information if you enable SMTP debugging: $ DEFINE/SYS/EXEC MX_SMTP_DEBUG TRUE Then send a message, and look at the resulting MX_SMTP_DIR:MX_SMTP_LOG.LOG. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Sun, 06 Mar 1994 09:10:27 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Sun, 06 Mar 1994 08:57:29 EST From: "Steve Thompson, Cheme System Mangler" Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@WKUVX1.WKU.EDU CC: olin@cheme.cornell.edu Message-ID: <0097B057.4D8F7FEA.1132@cheme.cornell.edu> Subject: using a standalone VAX as MX mailing list/file server I have set up a standalone VAX to handle all my MX mailing list and file server traffic. Since mail to these facilities may arrive at my main cluster (which is on the same ethernet), I have added rewrite rules to redirect the traffic to the standalone machine. None of the mailing lists or file servers is defined on the main cluster. If the standalone machine is named VAX, and this machine and the cluster are in the domain "domain", where all cluster members (mixed VAX/AXP) share the same MX databases, then for each mailing list I have added: define rewrite_rule "" "" define rewrite_rule "" "" define rewrite_rule "" "" where "list" is the mailing list name, and for each of the file servers: define rewrite_rule "" "" define rewrite_rule "" "" define rewrite_rule "" "" where "server" is the file server name. Is this correct (it certainly works), and/or is there a better way to do this? All list/file server owners are accounts on the main cluster, which are appropriately named in their definitions (in fact, I suppose I could change the rewrite rule for server-mgr to avoid a trip to the standalone VAX, since the mail would be sent back anyway, but this way I don't have to put the -mgr address in two places). The standalone VAX is an 8250 (hey, it isn't good for anything else). We have had it for nearly 7 years, and it and its RA82 system disk have never had a service call. I just know they'll break next week :-) Traffic is running at around 1000 messages/day. Comments? -Steve --------------------------------------------------------------------------- Steve Thompson, System Mangler Internet: thompson@cheme.cornell.edu School of Chemical Engineering Bitnet: thompson@crnlchme Olin Hall, Cornell University Phone: (607) 255 5573 Ithaca NY 14853 FAX: (607) 255 9166 --------------------------------------------------------------------------- ================================================================================ Archive-Date: Sun, 06 Mar 1994 11:41:09 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Limit of 255 characters Message-ID: <1994Mar6.101713.1221@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 6 Mar 94 10:17:13 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU I just noticed a new DSNlink article which describes a 255-character record limit of callable mail. This, no doubt, explains why MX can't handle long records unless they are encoded in BASE64 (SEND/FOREIGN). -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Sun, 06 Mar 1994 11:41:15 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: Can't use File/Extract in Bulletin from captured account Message-ID: <1994Mar6.102057.1222@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 6 Mar 94 10:20:57 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097AF9B.3DA31A40.32487@topcat.bsc.mass.edu>, Erik Sironen writes: >I have been telling people to mail the message to themselves from bulletin then >extract it. What I would like to know is there anyway to give these captured >accounts the ability to extract messages from within bulletin. I'm not familiar with bulletin; who wrote it? -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Sun, 06 Mar 1994 11:41:20 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: using a standalone VAX as MX mailing list/file server Message-ID: <1994Mar6.102317.1223@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 6 Mar 94 10:23:16 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097B057.4D8F7FEA.1132@cheme.cornell.edu>, "Steve Thompson, Cheme System Mangler" writes: >I have set up a standalone VAX to handle all my MX mailing list and file >server traffic. Since mail to these facilities may arrive at my main >cluster (which is on the same ethernet), I have added rewrite rules to >redirect the traffic to the standalone machine. Why not simply setup MX records for each of the (main) VAXes so they don't have to receive mail and then immediately send it to the standalone VAX for processing? Then the standalone machine could process all mail, except that which is destined for the main cluster; this is handled a lot better in MX V4.0-beta than in previous versions of MX, btw. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Sun, 06 Mar 1994 11:44:25 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: using a standalone VAX as MX mailing list/file server Date: 6 Mar 1994 17:32:06 GMT Message-ID: <2ld42m$fso@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <1994Mar6.102317.1223@buckie.hsc.colorado.edu>, dwing@uh01.Colorado.EDU (Dan Wing) writes: =In article <0097B057.4D8F7FEA.1132@cheme.cornell.edu>, "Steve Thompson, Cheme System Mangler" writes: =>I have set up a standalone VAX to handle all my MX mailing list and file =>server traffic. Since mail to these facilities may arrive at my main =>cluster (which is on the same ethernet), I have added rewrite rules to =>redirect the traffic to the standalone machine. = =Why not simply setup MX records for each of the (main) VAXes so they don't =have to receive mail and then immediately send it to the standalone VAX for =processing? Then the standalone machine could process all mail, except that =which is destined for the main cluster; this is handled a lot better in MX =V4.0-beta than in previous versions of MX, btw. Because if he sets up MX records, then any mail bound for individual users (as opposed to the lists) on the other machines would first have to go through the standalone machine. Chances are that there are more messages intended for individual users than intended for the lists. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Sun, 06 Mar 1994 13:36:06 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: olin@cheme.cornell.edu (Steve Thompson) Subject: Re: using a standalone VAX as MX mailing list/file server Date: 6 Mar 1994 19:07:19 GMT Message-ID: <2ld9l7$2cg@fitz.TC.Cornell.EDU> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <2ld42m$fso@gap.cco.caltech.edu>, carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes: >In article <1994Mar6.102317.1223@buckie.hsc.colorado.edu>, dwing@uh01.Colorado.EDU (Dan Wing) writes: >=In article <0097B057.4D8F7FEA.1132@cheme.cornell.edu>, "Steve Thompson, Cheme System Mangler" writes: >=>I have set up a standalone VAX to handle all my MX mailing list and file >=>server traffic. Since mail to these facilities may arrive at my main >=>cluster (which is on the same ethernet), I have added rewrite rules to >=>redirect the traffic to the standalone machine. >= >=Why not simply setup MX records for each of the (main) VAXes so they don't >=have to receive mail and then immediately send it to the standalone VAX for >=processing? Then the standalone machine could process all mail, except that >=which is destined for the main cluster; this is handled a lot better in MX >=V4.0-beta than in previous versions of MX, btw. > >Because if he sets up MX records, then any mail bound for individual users (as >opposed to the lists) on the other machines would first have to go through the >standalone machine. Chances are that there are more messages intended for >individual users than intended for the lists. >-------------------------------------------------------------------------------- >Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL I have MX records as Dan describes, but they are set up to point to the boot node of the main cluster (a 4000/500). A month or so ago, the 8250 (the standalone machine) was a cluster member, and I set up MX so that all nodes ran only the STMP server, while the 8250 ran the router and all the other stuff. After a day I decided against that; the mail queue was up to 300 entries and rising. It turned out that the 8250/RA82 combination just didn't have the beans to keep up with the load. The 4000/500 doesn't appear to notice. I only wish to redirect mailing list/file server traffic, which is about 5% of the total load. Also, I have site transports that require UAF access, and I don't really want to maintain a copy of the main UAF on the standalone machine, although it would be possible for the standalone machine to periodically fetch the main cluster's UAF (they both speak DFS). -steve --------------------------------------------------------------------------- Steve Thompson, System Mangler Internet: thompson@cheme.cornell.edu School of Chemical Engineering Bitnet: thompson@crnlchme Olin Hall, Cornell University Phone: (607) 255 5573 Ithaca NY 14853 FAX: (607) 255 9166 --------------------------------------------------------------------------- ================================================================================ Archive-Date: Mon, 07 Mar 1994 09:06:30 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 07 Mar 1994 09:04:56 -0600 From: arlen.walker@JCI.Com (Arlen P. Walker) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Re: message never arriving To: mx-list@wkuvx1.wku.edu Message-ID: <01H9OO9FVW06001I6A@JCI.Com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7BIT >> I brought MX up and sent out a test message, which has not been delivered. >> Obviously, I didn't get it right. But it's not obvious to me as to what I >> didn't get right. Does this info mean anything to anyone out there? > >It would help tremendously if you enable debugging for some or all of the >MX agents. The manual tells you how to enable debugging by setting VMS >logical names. > >After turning on debugging, send another message to a remote site. Also >send a message to yourself (MX%"name", that is, without any @address). >Compare the logs that result. > That's just it. When I send a message to myself via mx%"walker" I get no debugging log that provides useful info. The information I posted in that message (after the quoted part) came from the debugging log for the SMTP server. there was no equivalent entry for the local transmission. However, I think I'm closing in on the problem. We've got a minor net inconsistency here. Follow me: Node "a.jci.com" holds the PMDF mail sw which we are using for all internet and SMTP messages currently. Anything addressed to "jci.com" is picked up by it and rerouted to the proper address. We'd like to make all net mail traffic SMTP, hence the experiment with MX on another vax. MX is currently being tested on node "b.corp.jci.com". The DNS that the MX machine looks at for "jci.com" is on node "c.jci.com". Now the anomaly. a.jci.com cannot find b.corp.jci.com by name lookup, only by address. Not surprisingly, b.corp.jci.com also cannot look up the name of a.jci.com. However, c.jci.com can find them both by name, and they can each find it by name. We've gotten something tangled here, obviously. Since the debugging message shows the MX SMTP server failing on the address lookup, I think this is the root of the problem. The lookup problem needs resolving anyway, so we're doing that. I'm expecting the MX problem to dissolve when we've finished. Am I crazy? Could this cause it? Have Fun, Arlen --------------------------------------------------- This mail message contains 100% recycled electrons --------------------------------------------------- ================================================================================ Archive-Date: Mon, 07 Mar 1994 10:32:26 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 07 Mar 1994 11:26:53 EST From: Brett Thompson Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: bthompson@eckert.acadcomp.monroecc.edu, bhoward@eckert.acadcomp.monroecc.edu Message-ID: <0097B135.575859A0.4799@eckert.acadcomp.monroecc.edu> Subject: Problem with Local Delivery Hi, I have a user that reported she was not getting mail from remote sites via SMTP (well she said "I can't get Internet mail"). Anyways I spent a bit of time sending her mail from remote machines and she was right. I checked protections, analyzed/rms her .dir file and .mai file -- I even deleted and recreated her account after I could not find anything else wrong (there were no flags set in sysuaf.dat for her either). I checked for any ALIASes or LOGICALS of KFARRELL (her username) and found nothing. I concluded it was something with MX. The mail is received by MX as indicated in the MCP QUEUE SHOW command. It is not being deliverd so I enabled LOCAL Debuging and here is the MX_LOCAL_DEBUG.LOG File: 7-MAR-1994 11:17:24.85 Processing queue entry number 4792 7-MAR-1994 11:17:25.70 Checking local name: BTHOMPSON 7-MAR-1994 11:17:26.72 LOCAL_USER: User BTHOMPSON definitely local. 7-MAR-1994 11:17:26.72 This is a regular delivery. 7-MAR-1994 11:17:26.72 Checking local name: KFARRELL 7-MAR-1994 11:17:26.90 This is a delivery to MM. 7-MAR-1994 11:17:27.02 DELIVER_MM: Delivering to KFARRELL 7-MAR-1994 11:17:27.84 PERFORM_MM_DELIVERY returned status 00000001 7-MAR-1994 11:17:28.26 DELIVER: mime_base64_fdl = 1 7-MAR-1994 11:17:28.26 DELIVER: fdlstr = "" 7-MAR-1994 11:17:28.29 DELIVER: Using SMTP%"BRT0111@ritvax.isc.rit.edu" as VMS MAIL From address. 7-MAR-1994 11:17:28.29 DELIVER: Using "TEST" as subject. 7-MAR-1994 11:17:28.55 DELIVER: Delivering to BTHOMPSON 7-MAR-1994 11:17:30.02 DELIVER: Status=00000001 from MAIL$ routines 7-MAR-1994 11:17:31.00 All done with this entry. What is "This is a delivery to MM" and "DELIVER_MM: Delivering to KFARRELL" and more importantly how do I get her account to be recognized as a LOCAL_USER?!?!?! Thanks. _____________________________________________________________________________ | Brett R. Thompson Monroe Community College | | Network Manager 1000 East Henrietta Rd. | | Academic Computing Department Rochester, NY 14623-5780 USA | | bthompson@eckert.acadcomp.monroecc.edu Voice: (716) 292-3431 | | SMCCVA::ECKERT::BTHOMPSON (SUNYNet) Fax : (716) 427-2749 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ================================================================================ Archive-Date: Mon, 07 Mar 1994 10:57:21 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 07 Mar 1994 11:53:39 EST From: koenig@CVAX.IPFW.INDIANA.EDU Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B139.143FD108.14837@CVAX.IPFW.INDIANA.EDU> Subject: RE: Problem with Local Delivery >From: Brett Thompson >Subj: Problem with Local Delivery >Hi, Hi! > I have a user that reported she was not getting mail from remote > sites via SMTP (well she said "I can't get Internet mail"). Anyways [stuff deleted] > 7-MAR-1994 11:17:24.85 Processing queue entry number 4792 > 7-MAR-1994 11:17:25.70 Checking local name: BTHOMPSON > 7-MAR-1994 11:17:26.72 LOCAL_USER: User BTHOMPSON definitely local. > 7-MAR-1994 11:17:26.72 This is a regular delivery. > 7-MAR-1994 11:17:26.72 Checking local name: KFARRELL > 7-MAR-1994 11:17:26.90 This is a delivery to MM. > 7-MAR-1994 11:17:27.02 DELIVER_MM: Delivering to KFARRELL > 7-MAR-1994 11:17:27.84 PERFORM_MM_DELIVERY returned status 00000001 > 7-MAR-1994 11:17:28.26 DELIVER: mime_base64_fdl = 1 > 7-MAR-1994 11:17:28.26 DELIVER: fdlstr = "" > 7-MAR-1994 11:17:28.29 DELIVER: Using SMTP%"BRT0111@ritvax.isc.rit.edu" as VM >S MAIL From address. > 7-MAR-1994 11:17:28.29 DELIVER: Using "TEST" as subject. > 7-MAR-1994 11:17:28.55 DELIVER: Delivering to BTHOMPSON > 7-MAR-1994 11:17:30.02 DELIVER: Status=00000001 from MAIL$ routines > 7-MAR-1994 11:17:31.00 All done with this entry. > What is "This is a delivery to MM" and "DELIVER_MM: Delivering to > KFARRELL" and more importantly how do I get her account to be > recognized as a LOCAL_USER?!?!?! You're running Multinet as your TCP/IP package, aren't you? The DELIVER_MM indicates that MX is delivering this user's mail to the "Multinet Mail" mailbox. This is a file in the user's login directory called MAIL.TXT. If you check this file, you'll find all the incoming mail that the user should have received in "Multinet Mail" format. Usually, users get into this problem because they extract a mail message into the commonly-used name MAIL.TXT. MX then assumes that they are using Multinet Mail and delivers everything to the MAIL.TXT file instead. If you delete the MAIL.TXT file, mail will be delivered to the user normally. Also, if you FTP to FTP.SPC.EDU and look around, you'll find a patch to MX's LOCAL and MCP executables that disables delivery to MM. I believe it is called something like MX_NO_MM.ZIP. The next release of MX will have the option for disabling delivery to MM built in. >Thanks. No problem. This one confused me the first time I saw it too. > _____________________________________________________________________________ >| Brett R. Thompson Monroe Community College | >| Network Manager 1000 East Henrietta Rd. | >| Academic Computing Department Rochester, NY 14623-5780 USA | >| bthompson@eckert.acadcomp.monroecc.edu Voice: (716) 292-3431 | >| SMCCVA::ECKERT::BTHOMPSON (SUNYNet) Fax : (716) 427-2749 | > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ---Greg --------------------------------------------------------------------------- Greg Koenig koenig@cvax.ipfw.indiana.edu Systems Programmer koenig@ipfwcvax.bitnet Indiana University - Purdue University koenig@smtplink.ipfw.indiana.edu Fort Wayne, Indiana (219) 481-6031 --------------------------------------------------------------------------- ================================================================================ Archive-Date: Mon, 07 Mar 1994 11:18:43 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: Problem with Local Delivery Message-ID: <1994Mar7.095125.1229@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 7 Mar 94 09:51:25 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097B135.575859A0.4799@eckert.acadcomp.monroecc.edu>, Brett Thompson writes: > What is "This is a delivery to MM" and "DELIVER_MM: Delivering to > KFARRELL" and more importantly how do I get her account to be > recognized as a LOCAL_USER?!?!?! MX V4.0 will handle this better (with a SET LOCAL/noMM_DELIVER command), but the user has a MAIL.TXT file in her login directory; have her delete it. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Mon, 07 Mar 1994 11:28:26 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 07 Mar 1994 11:21:50 CST From: "James F. Burnett" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B134.A25F9D60.28215@PANAM1.PANAM.EDU> Subject: RE: Problem with Local Delivery > >Hi, > > I have a user that reported she was not getting mail from remote > sites via SMTP (well she said "I can't get Internet mail"). Anyways > I spent a bit of time sending her mail from remote machines and she > was right. I checked protections, analyzed/rms her .dir file and > .mai file -- I even deleted and recreated her account after I could > not find anything else wrong (there were no flags set in sysuaf.dat > for her either). I checked for any ALIASes or LOGICALS of KFARRELL > (her username) and found nothing. > > I concluded it was something with MX. The mail is received by > MX as indicated in the MCP QUEUE SHOW command. It is not being > deliverd so I enabled LOCAL Debuging and here is the > MX_LOCAL_DEBUG.LOG File: > > 7-MAR-1994 11:17:24.85 Processing queue entry number 4792 > 7-MAR-1994 11:17:25.70 Checking local name: BTHOMPSON > 7-MAR-1994 11:17:26.72 LOCAL_USER: User BTHOMPSON definitely local. > 7-MAR-1994 11:17:26.72 This is a regular delivery. > 7-MAR-1994 11:17:26.72 Checking local name: KFARRELL > 7-MAR-1994 11:17:26.90 This is a delivery to MM. > 7-MAR-1994 11:17:27.02 DELIVER_MM: Delivering to KFARRELL > 7-MAR-1994 11:17:27.84 PERFORM_MM_DELIVERY returned status 00000001 > 7-MAR-1994 11:17:28.26 DELIVER: mime_base64_fdl = 1 > 7-MAR-1994 11:17:28.26 DELIVER: fdlstr = "" > 7-MAR-1994 11:17:28.29 DELIVER: Using SMTP%"BRT0111@ritvax.isc.rit.edu" as VMS MAIL From address. > 7-MAR-1994 11:17:28.29 DELIVER: Using "TEST" as subject. > 7-MAR-1994 11:17:28.55 DELIVER: Delivering to BTHOMPSON > 7-MAR-1994 11:17:30.02 DELIVER: Status=00000001 from MAIL$ routines > 7-MAR-1994 11:17:31.00 All done with this entry. > > What is "This is a delivery to MM" and "DELIVER_MM: Delivering to > KFARRELL" and more importantly how do I get her account to be > recognized as a LOCAL_USER?!?!?! &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& I'm assuming this is the MM that ships with Multinet. I don't know much about it, other than the fact that there are 2 files with a .TXT(or .TEXT) extension created in the user's default login directory the first time MM is used. From that point on, mail will go to MM. Just type MM at the VMS DCL prompt and read through the help. Once she has read all of the messages or decided what to do with them, she can delete the 2 files mentioned above and mail will return to normal(back to VMSmail, that is). &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& > >Thanks. > > > > _____________________________________________________________________________ >| Brett R. Thompson Monroe Community College | >| Network Manager 1000 East Henrietta Rd. | >| Academic Computing Department Rochester, NY 14623-5780 USA | >| bthompson@eckert.acadcomp.monroecc.edu Voice: (716) 292-3431 | >| SMCCVA::ECKERT::BTHOMPSON (SUNYNet) Fax : (716) 427-2749 | > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- james ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + James F. Burnett INTERNET: BURNETT@PANAM.EDU + + Software Systems Specialist II BITNET : BURNETT@PANAM.BITNET + + University of Texas-Pan American THENET : PANAM::BURNETT + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ================================================================================ Archive-Date: Mon, 07 Mar 1994 12:31:17 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 07 Mar 1994 10:27:26 PST From: robert@dis.ucsf.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B12D.08E9E520.5476@dis.ucsf.edu> Subject: RE: Problem with Local Delivery I had the same problem when I started MX fr the first time. Here's what Hunter said at the time. It worked. Robert Weiner Manager, Development Information Systems UC San Francisco > > The problem you're seeing is that MX (mistakenly) thought you were > using MM because it (probably) found a MAIL.TXT file in your > directory. Old versions of MM did that too. > > You can get a fix that disables delivery via MM by picking up the > appropriate .ZIP file in [.MX.BETA] on ftp.spc.edu. > > Hunter > ------ > Hunter Goatley, VMS Systems Programmer, Western Kentucky University > goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Mon, 07 Mar 1994 12:48:07 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 7 Mar 1994 13:44:12 +0500 From: dbadrak@census.gov (Don Badrak (GEO-CMS)) Reply-To: MX-List@WKUVX1.WKU.EDU Message-ID: <9403071844.AA29100@info.census.gov> To: MX-List@WKUVX1.WKU.EDU CC: dbadrak@census.gov Subject: RE: Problem with Local Delivery > Date: Mon, 07 Mar 1994 11:26:53 EST > From: Brett Thompson > > I have a user that reported she was not getting mail from remote > sites via SMTP (well she said "I can't get Internet mail"). Anyways > I spent a bit of time sending her mail from remote machines and she > was right. I checked protections, analyzed/rms her .dir file and > .mai file -- I even deleted and recreated her account after I could > not find anything else wrong (there were no flags set in sysuaf.dat > for her either). I checked for any ALIASes or LOGICALS of KFARRELL > (her username) and found nothing. > > I concluded it was something with MX. The mail is received by > MX as indicated in the MCP QUEUE SHOW command. It is not being > deliverd so I enabled LOCAL Debuging and here is the > MX_LOCAL_DEBUG.LOG File: > > 7-MAR-1994 11:17:24.85 Processing queue entry number 4792 > 7-MAR-1994 11:17:25.70 Checking local name: BTHOMPSON > 7-MAR-1994 11:17:26.72 LOCAL_USER: User BTHOMPSON definitely local. > 7-MAR-1994 11:17:26.72 This is a regular delivery. > 7-MAR-1994 11:17:26.72 Checking local name: KFARRELL > 7-MAR-1994 11:17:26.90 This is a delivery to MM. > 7-MAR-1994 11:17:27.02 DELIVER_MM: Delivering to KFARRELL > 7-MAR-1994 11:17:27.84 PERFORM_MM_DELIVERY returned status 00000001 > 7-MAR-1994 11:17:28.26 DELIVER: mime_base64_fdl = 1 > 7-MAR-1994 11:17:28.26 DELIVER: fdlstr = "" > 7-MAR-1994 11:17:28.29 DELIVER: Using SMTP%"BRT0111@ritvax.isc.rit.edu" as > VMS MAIL From address. > 7-MAR-1994 11:17:28.29 DELIVER: Using "TEST" as subject. > 7-MAR-1994 11:17:28.55 DELIVER: Delivering to BTHOMPSON > 7-MAR-1994 11:17:30.02 DELIVER: Status=00000001 from MAIL$ routines > 7-MAR-1994 11:17:31.00 All done with this entry. > > What is "This is a delivery to MM" and "DELIVER_MM: Delivering to > KFARRELL" and more importantly how do I get her account to be > recognized as a LOCAL_USER?!?!?! Brett, You're running MultiNet, aren't you? The MultiNet mail program is called MM. It causes message to be sent as SMTP%"user@host", and also has the ability to receive messages into a file called MAIL.TXT in the user's home directory. I haven't managed to figure out how it does this, but here's what I believe is happening: 1. a user extracts a mail message without giving it a filename and it ends up being saved in their home directory with the name MAIL.TXT 2. somehow, the next time this user receives MX mail, it decides it doesn't want to deliver it by itself, but rather will let something else, MM, handle it. Maybe this is part of the undocumented mail routines, where it checks for the existence of a file MAIL.TXT and then does something different. 3. MX passes it off to MM, which creates a file called $HDRS$MAIL.TXT. This file is the "directory" of mail messages. It also appends the message to MAIL.TXT. These messages can be read by using the command MM. I have not figured out why this happens. I have the same problem. I have SMTP disabled in the services configuration, and I've even renamed the executables that do SMTP for MultiNet to .EXE_DONTUSE. But it is still happening. The way I "fix" it is to delete those two files, MAIL.TXT and $HDRS$MAIL.TXT. I hope someone else can provide the reasoning behind what is happening here. (oh, and just as I finished typing this up, I got a reply to this on how to fix permanently. I'm still in search of the "why", though). Don ----------------------------------------------- dbadrak@census.gov Don Badrak Geography Division U.S. Bureau of the Census ================================================================================ Archive-Date: Mon, 07 Mar 1994 15:52:42 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: message never arriving Date: 7 Mar 1994 21:43:57 GMT Message-ID: <2lg76t$419@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <01H9OO9FVW06001I6A@JCI.Com>, arlen.walker@JCI.Com (Arlen P. Walker) writes: =Node "a.jci.com" holds the PMDF mail sw which we are using for all internet =and SMTP messages currently. Anything addressed to "jci.com" is picked up =by it and rerouted to the proper address. We'd like to make all net mail =traffic SMTP, hence the experiment with MX on another vax. MX is currently =being tested on node "b.corp.jci.com". The DNS that the MX machine looks at =for "jci.com" is on node "c.jci.com". Now the anomaly. =a.jci.com cannot find b.corp.jci.com by name lookup, only by address. Not =surprisingly, b.corp.jci.com also cannot look up the name of a.jci.com. =However, c.jci.com can find them both by name, and they can each find it by =name. We've gotten something tangled here, obviously. Since the debugging =message shows the MX SMTP server failing on the address lookup, I think =this is the root of the problem. OK. A.JCI.COM has an MX record pointing to CORE.JCI.COM. CORE.JCI.COM has an A record. There seems to be no DNS record for B.CORP.JCI.COM. Sounds like C.JCI.COM has a hosts database residing somewhere on disk, maybe. JCI.COM has an MX record pointing to CORE.JCI.COM. Is "B.CORP.JCI.COM" some sort of fictitious name you made up for the purposes of describing the problem, or is it supposed to be an actual machine? =The lookup problem needs resolving anyway, so we're doing that. I'm =expecting the MX problem to dissolve when we've finished. Am I crazy? Could =this cause it? If your TCP/IP software can't resolve the name of the machine to which the mail is supposed to be sent, yes, that could cause your problem. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Mon, 07 Mar 1994 16:09:10 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 07 Mar 1994 16:06:09 CST From: system@BEAVER.HS.Bemidji.MSUS.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wkuvx1.wku.edu Message-ID: <0097B15C.5A7DA3C0.620@BEAVER.HS.Bemidji.MSUS.edu> Subject: Forward to an Alias Folks: Certainly this is a FAQ. I set forward with the following command: MAIL> set forw "MX%""DMILLER@BSU""" where BSU is an alias for VAX1.Bemidji.MSUS.edu. Apparently MX doesn't think to much of that idea. Although I don't have any error messages to that effect nothing was forwarded. When using the full address, it forwards ok. No biggie, just curious. dave. ================================================================================ Archive-Date: Mon, 07 Mar 1994 16:13:12 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: Problem with Local Delivery Date: 7 Mar 1994 21:56:44 GMT Message-ID: <2lg7us$419@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097B135.575859A0.4799@eckert.acadcomp.monroecc.edu>, Brett Thompson writes: = What is "This is a delivery to MM" and "DELIVER_MM: Delivering to = KFARRELL" and more importantly how do I get her account to be = recognized as a LOCAL_USER?!?!?! Tell your user that her mail is in the file SYS$LOGIN:MAIL.TXT, if she wants to read it, shell have to use MM, and that if she wants to have internet mail delivered via VMS MAIL, she shouldn't have a file called MAIL.TXT in her login directory. MM is the Multinet Mailer. It puts its mail in SYS$LOGIN:MAIL.TXT. If MX sees such a file, it hands the mail to MM for deliery. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Mon, 07 Mar 1994 23:36:21 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: bg@dymaxion.ns.ca (Ben Armstrong) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Re: BASE64 Decoder?? Message-ID: <1994Mar7.102235.3427@dymaxion.ns.ca> Date: 7 Mar 94 10:22:35 AST To: MX-List@WKUVX1.WKU.EDU In article <1994Mar4.154534.1218@buckie.hsc.colorado.edu>, dwing@uh01.Colorado.EDU (Dan Wing) writes: > In article <2l8a3e$i22@blue.weeg.uiowa.edu>, meadows@cslvax.weeg.uiowa.edu writes: >> Is there a BASE64 decoder available somewhere for VMS? > >>I'm trying >>to deal with mail messages encoded in BASE64 on other systems, but >>do not have Content-Type: VMS-whatever, so mx passes it through. > > Neither MultiNet V3.3 nor MX's V3.4-beta/V4.0-beta decode will decode such a > file; I don't know if Hunter plans on changing this behavior. That is really too bad, because I face the same problem. In my case, I don't even have the appropriate Unix tools to decode such files. When dealing with firewalled Internet or other-net sites where the person at the other end is not on a VMS machine I have trouble finding ways of getting files back and forth. Often, the other person has little expertise with their system, so Mime, which hides a lot of tech details, was my great hope for dealing with them. Ben. P.S. Hmmm... interesting, V3.4-beta went right to V4.0-beta without a full release between? I haven't been following this group lately... What is in store for us in the next full release? -- Ben Armstrong, Medianet Development Group, bus: (902)422-1973 Dymaxion Research Ltd., 5515 Cogswell St., fax: (902)421-1267 Halifax, Nova Scotia, Canada B3J 1R2 Internet: BArmstrong@dymaxion.ns.ca ================================================================================ Archive-Date: Tue, 08 Mar 1994 08:31:46 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 08 Mar 1994 16:48:20 JST From: Tim Burress Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-LIST@WKUVX1.WKU.EDU Message-ID: <0097B22B.69A57CE0.16472@tanuki.twics.com> Subject: Any Workaround for Looping UUCP Agent? We've begun running into this problem where the UUCP agents get stuck in an infinite and very resource-hungry loop, and the only way we can unstick things is to shut down MX, stop the UUCP interface process with STOP, delete the first UUCP job on the MCP queue, and then restart. This is starting to happen several times a day, so I'm wondering if anyone has come up with a workaround. I remember hearing that the culprit was some kind of unexpected data in the headers, but is there a more detailed explanation? I'd gladly dig into UUCP to find/fix it, but surely someone has had a go at it already. Thanks! ================================================================================ Archive-Date: Tue, 08 Mar 1994 09:36:26 CST Sender: List-Mgr@WKUVX1.WKU.EDU MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 9 Mar 1994 00:33:19 +0900 To: mx-list@wkuvx1.wku.edu From: tim@twics.com (Tim Burress) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: How to ignore MM mail delivery with Multinet? We're running the Multinet software and seeing a problem where, if a user has a file MAIL.TXT in their login directory, incoming messages get appended to that file instead of being added to MAIL.MAI. I assumed that the fix would be some logical for Multinet, but the folks at TGV tell me that there's an update kit for MX that will do the job. Could someone tell me what I need to do to get this? Thanks! Tim ================================================================================ Archive-Date: Tue, 08 Mar 1994 10:05:48 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: Forward to an Alias Message-ID: <1994Mar8.084615.1235@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 8 Mar 94 08:46:14 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097B15C.5A7DA3C0.620@BEAVER.HS.Bemidji.MSUS.edu>, system@BEAVER.HS.Bemidji.MSUS.edu writes: >Folks: > >Certainly this is a FAQ. > >I set forward with the following command: > >MAIL> set forw "MX%""DMILLER@BSU""" > >where BSU is an alias for VAX1.Bemidji.MSUS.edu. > >Apparently MX doesn't think to much of that idea. Although I don't have any >error messages to that effect nothing was forwarded. When using the full >address, it forwards ok. > >No biggie, just curious. > >dave. What happens when you send mail to dmiller@bsu ? Does it get there? If it does, and forwarding doesn't work, please enable LOCAL and ROUTER debugging, reset all agents, setup the forwarding, and post the output from the local and router debug logs to vmsnet.mail.mx (MX-LIST). -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Tue, 08 Mar 1994 10:21:18 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: BASE64 Decoder?? Message-ID: <1994Mar8.084948.1237@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 8 Mar 94 08:49:47 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <1994Mar7.102235.3427@dymaxion.ns.ca>, bg@dymaxion.ns.ca (Ben Armstrong) writes: >> Neither MultiNet V3.3 nor MX's V3.4-beta/V4.0-beta decode will decode such a >> file; I don't know if Hunter plans on changing this behavior. > >That is really too bad, because I face the same problem. In my case, >I don't even have the appropriate Unix tools to decode such files. Well, you could add the necessary headers to the BASE64-encoded file to fake it out, of course.... But hard to say if it would be properly decoded... >When dealing with firewalled Internet or other-net sites where the >person at the other end is not on a VMS machine I have trouble finding >ways of getting files back and forth. Often, the other person has >little expertise with their system, so Mime, which hides a lot of tech >details, was my great hope for dealing with them. > >Ben. > >P.S. Hmmm... interesting, V3.4-beta went right to V4.0-beta without a > full release between? I haven't been following this group lately... > What is in store for us in the next full release? V3.4-beta had lots of new features, and used a relative file for the queue file (for better performance). V4.0 is exactly the same as V3.4 except it uses a direct-accessed sequential file for the queue file (which gives even better performance than a relative file). Hunter decided to abandon the relative file because of some apparent misfeatures in RMS wrt relative files. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Tue, 08 Mar 1994 10:21:57 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: RE: Problem with Local Delivery Message-ID: <1994Mar8.090325.1238@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 8 Mar 94 09:03:25 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <9403071844.AA29100@info.census.gov>, dbadrak@census.gov (Don Badrak (GEO-CMS)) writes: > 2. somehow, the next time this user receives MX mail, it > decides it doesn't want to deliver it by itself, but rather > will let something else, MM, handle it. Maybe this is > part of the undocumented mail routines, where it checks > for the existence of a file MAIL.TXT and then does something > different. MX V3.3's "Local" agent has code to explicitly attempt to deliver mail to MultiNet's MM mailer if MAIL.TXT exists; unfortunately, the code isn't quite anal enough to double check for the existence of $HDRS$MAIL.TXT (which would prevent users from accidentally tripping MX's attempt to deliver mail via MM). The source for MX V3.3 is available for anonymous FTP from ftp.spc.edu in [.mx] -- check out the module [.LOCAL]LOCAL_USER.B32, which contains the code that does the MM delivery. The reason the code makes the "mistake" of deliverying to MM is to preserve the behavior of older (pre-V3.2) versions of MultiNet; from the comments in LOCAL_USER.B32: >!++ >! In MultiNet V3.2 and later, MM delivery options are kept in the >! user's MM.INIT file in his/her home directory. >!-- ... >!++ >! If delivery-to-mm flag wasn't in the MM.INIT file, or if MAIL.TXT doesn't >! exist in the user-specified mail directory, then fall back to old-style >! check for MAIL.TXT in MM directory. >!-- MX V4.0-beta contains the following command: >MCP> HELP SET LOCAL/MM_DELIVER >SET > LOCAL > /MM_DELIVER > /MM_DELIVER > /NOMM_DELIVER > Specifies whether or not incoming messages can be delivered via the > MultiNet user agent MM, if the user requests it. By default, > delivery via MM is not allowed (/NOMM_DELIVER). Which should prevent this problem from happening. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Tue, 08 Mar 1994 11:37:51 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 08 Mar 1994 09:34:09 PST From: robert@dis.ucsf.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B1EE.C1AECBE0.5711@dis.ucsf.edu> Subject: RE: How to ignore MM mail delivery with Multinet? Tim, Presumably you somehow missed out on the discussion of this issue that ran all day yesterday. Here's the reply that Hunter sent me when I ran into the same problem, which I posted yesterday. Robert Weiner Manager, Development Information Systems robert@dis.ucsf.edu University of California, San Francisco > > The problem you're seeing is that MX (mistakenly) thought you were > using MM because it (probably) found a MAIL.TXT file in your > directory. Old versions of MM did that too. > > You can get a fix that disables delivery via MM by picking up the > appropriate .ZIP file in [.MX.BETA] on ftp.spc.edu. > > Hunter > ------ > Hunter Goatley, VMS Systems Programmer, Western Kentucky University > goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================== > From: MX%"MX-List@WKUVX1.WKU.EDU" 8-MAR-1994 09:24:11.06 > Subj: How to ignore MM mail delivery with Multinet? > We're running the Multinet software and seeing a problem where, if a user > has a file MAIL.TXT in their login directory, incoming messages get > appended to that file instead of being added to MAIL.MAI. I assumed that > the fix would be some logical for Multinet, but the folks at TGV tell me > that there's an update kit for MX that will do the job. Could someone tell > me what I need to do to get this? > > Thanks! > Tim ================================================================================ Archive-Date: Tue, 08 Mar 1994 11:40:41 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 8 Mar 1994 11:37:09 -0600 (CST) From: "David J. Effa" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-LIST@WKUVX1.WKU.EDU Message-ID: <940308113709.2101743a@comet.cmis.abbott.com> Subject: HELP HELP ================================================================================ Archive-Date: Tue, 08 Mar 1994 11:42:30 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: Any Workaround for Looping UUCP Agent? Message-ID: <1994Mar8.101422.1241@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 8 Mar 94 10:14:22 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097B22B.69A57CE0.16472@tanuki.twics.com>, Tim Burress writes: >We've begun running into this problem where the UUCP agents get stuck in an >infinite and very resource-hungry loop, and the only way we can unstick things >is to shut down MX, stop the UUCP interface process with STOP, delete the first >UUCP job on the MCP queue, and then restart. > >This is starting to happen several times a day, so I'm wondering if anyone has >come up with a workaround. I remember hearing that the culprit was some kind >of unexpected data in the headers, but is there a more detailed explanation? >I'd gladly dig into UUCP to find/fix it, but surely someone has had a go at it >already. You might want to ask the UUCP folks, or is this an MX problem? -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Tue, 08 Mar 1994 11:42:46 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: How to ignore MM mail delivery with Multinet? Message-ID: <1994Mar8.101303.1240@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 8 Mar 94 10:13:03 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <21270093@MVB.SAIC.COM>, tim@twics.com (Tim Burress) writes: >We're running the Multinet software and seeing a problem where, if a user >has a file MAIL.TXT in their login directory, incoming messages get >appended to that file instead of being added to MAIL.MAI. I assumed that >the fix would be some logical for Multinet, but the folks at TGV tell me >that there's an update kit for MX that will do the job. Could someone tell >me what I need to do to get this? Anonymous FTP to ftp.spc.edu, and grab the file [.MX.BETA]MX_NO_MM_AXP.ZIP or [.MX.BETA]MX_NO_MM_VAX.ZIP. You need to Unzip it using the UNZIP.EXE that comes with MX (which should be in your MX_ROOT:[CONTRIB] directory, or you can get it from ftp.spc.edu in [.MX]UNZIP.EXE or UNZIP.ALPHA_EXE: $ UNZIP :== $device:[directory]UNZIP.EXE $ UNZIP MX_NO_MM_VAX.ZIP Which will create two files, MX_LOCAL.EXE and MCP.EXE. You should place these files in the MX_EXE directory, then shutdown the MX Local processes with: MCP> SHUTDOWN LOCAL/CLUSTER and restart the local processes on all nodes in the cluster: $ RUN SYS$SYSTEM:SYSMAN SYSMAN> SET ENVIRONMENT/CLUSTER SYSMAN> DO @SYS$STARTUP:MX_STARTUP.COM SYSMAN> EXIT -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Tue, 08 Mar 1994 12:06:47 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 08 Mar 1994 13:03:09 EST From: "Steve Thompson, Cheme System Mangler" Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wkuvx1.wku.edu Message-ID: <0097B20B.F44F9FDA.5547@cheme.cornell.edu> Subject: MX record problem MX 3.3, VAX/VMS 6.0, Multinet 3.2-D. Today I am having a problem with MX that I cannot figure out. I have a whole bucketload of messages sitting in the queue, with MX showing a last error of "%MX-F-NOHOST, no such host". The delivery attempts from the SMTP log look like: 8-MAR-1994 12:43:41.72 Processing queue entry number 5515 on node VGER 8-MAR-1994 12:43:42.10 Recipient: , route=cornell.edu 8-MAR-1994 12:43:42.16 SMTP_SEND: looking up host name cornell.edu 8-MAR-1994 12:43:46.73 SMTP_SEND: Failed, sts=00000870 8-MAR-1994 12:43:46.73 SMTP send failed, sts=0C278024, sts2=00000870 8-MAR-1994 12:43:46.73 Recipient status=0C278024 for 8-MAR-1994 12:43:47.61 1 rcpts need retry, next try 8-MAR-1994 13:13:47.61 8-MAR-1994 12:43:47.64 *** End of processing pass *** In this case, cornell.edu is not a real host; it is an MX record. There is no A record for cornell.edu; just the MX record which points to a host which does have an A record. If I use NSLOOKUP to query the DNS for the MX record, it is found properly. Looks as if MX is not picking up the MX record. This worked properly yesterday, and I have made no changes since then (really!). Stopping and restarting DNS and/or MX has no effect. Any ideas? -steve --------------------------------------------------------------------------- Steve Thompson, System Mangler Internet: thompson@cheme.cornell.edu School of Chemical Engineering Phone: (607) 255 5573 Olin Hall, Cornell University FAX: (607) 255 9166 Ithaca NY 14853 --------------------------------------------------------------------------- ================================================================================ Archive-Date: Tue, 08 Mar 1994 12:34:52 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 08 Mar 1994 11:09:25 -0700 From: "Ray Harwood -- Data Basix: (602)721-1988" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: rharwood@Data.Basix.COM Message-ID: <0097B1FC.10A91360.15168@Data.Basix.COM> Subject: Other file format changes? dwing@uh01.Colorado.EDU (Dan Wing) writes: > V3.4-beta had lots of new features, and used a relative file for the queue > file (for better performance). V4.0 is exactly the same as V3.4 except it > uses a direct-accessed sequential file for the queue file (which gives even > better performance than a relative file). Hunter decided to abandon the > relative file because of some apparent misfeatures in RMS wrt relative files. Can anyone give me a "heads-up" on other file format changes (as far ahead as MX 4.0)? I've been scoping out writing an MLF tool to give a LOCAL list owner an interactive method of adding, deleting, and modifying subscriber information to a list. I don't want to invest time in figuring out the intricacies of the current file formats if they'll be changed in the next release. TIA, Ray ----- Ray Harwood | Data Basix | DEC Pro Networking Editor Voice: (602)721-1988 | PO Box 18324 | "Internet Resource Guide" FAX: (602)721-7240 | Tucson, AZ 85731 | Adjunct Faculty, East Campus, RHarwood@Data.Basix.COM | Info@Data.Basix.COM | Pima Community College ================================================================================ Archive-Date: Tue, 08 Mar 1994 13:01:02 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: MX record problem Message-ID: <1994Mar8.114145.1243@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 8 Mar 94 11:41:44 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097B20B.F44F9FDA.5547@cheme.cornell.edu>, "Steve Thompson, Cheme System Mangler" writes: >MX 3.3, VAX/VMS 6.0, Multinet 3.2-D. > >Today I am having a problem with MX that I cannot figure out. I have a >whole bucketload of messages sitting in the queue, with MX showing a >last error of "%MX-F-NOHOST, no such host". The delivery attempts from >the SMTP log look like: > > 8-MAR-1994 12:43:41.72 Processing queue entry number 5515 on node VGER > 8-MAR-1994 12:43:42.10 Recipient: , route=cornell.edu > 8-MAR-1994 12:43:42.16 SMTP_SEND: looking up host name cornell.edu > 8-MAR-1994 12:43:46.73 SMTP_SEND: Failed, sts=00000870 > 8-MAR-1994 12:43:46.73 SMTP send failed, sts=0C278024, sts2=00000870 > 8-MAR-1994 12:43:46.73 Recipient status=0C278024 for > 8-MAR-1994 12:43:47.61 1 rcpts need retry, next try 8-MAR-1994 13:13:47.61 > 8-MAR-1994 12:43:47.64 *** End of processing pass *** > >In this case, cornell.edu is not a real host; it is an MX record. There >is no A record for cornell.edu; just the MX record which points to a >host which does have an A record. If I use NSLOOKUP to query the DNS >for the MX record, it is found properly. Looks as if MX is not picking >up the MX record. > >This worked properly yesterday, and I have made no changes since then >(really!). Stopping and restarting DNS and/or MX has no effect. > >Any ideas? Deep back in the MX-LIST archives, I found some stuff. I didn't find an exact answer, though .... Hope this might help you out... -dan ----- =Archive-Date: Wed, 26 May 1993 17:30:36 CDT =Sender: list-mgr@WKUVX1.BITNET =From: =Subject: Re: MX SMTP and UCX domain lookup problems =Message-ID: <1993May26.220111.25132@news.arc.nasa.gov> =Reply-To: MX-List@WKUVX1.BITNET =Date: Wed, 26 May 1993 22:01:11 GMT =To: MX-List@WKUVX1.BITNET = =In article <0096D157.EC8CAA80.14505@WKUVX1.BITNET>, Hunter Goatley = writes: =>Jerry Storrs of NCSU has a problem that has me stumped. He's running =>MX V3.3 and UCX V1.3. All MX SMTP domain lookups are failing. Here's =>a log that is typical of all of them: => =>>21-MAY-1993 15:18:32.88 Processing queue entry number 1000 =>>21-MAY-1993 15:18:33.13 Recipient: , => route=CCVAX1.CC.NCSU.EDU =>>21-MAY-1993 15:18:33.13 SMTP_SEND: looking up host name CCVAX1.CC.NCSU.EDU =>>21-MAY-1993 15:18:33.50 SMTP_SEND: Failed, sts=00000870 =>>21-MAY-1993 15:18:33.50 SMTP send failed, sts=0C278024, sts2=00000870 =>>21-MAY-1993 15:18:33.50 Recipient status=0C278024 for => => =>He does have a name server defined, and TELNET, etc., works just fine. =>But MX always returns this. Do any of you have any suggested courses of =>action? His UCX host info looked fine to me, as did the name =>server(s). The name servers are defined using the IP addresses, and =>the UCX$BIND_SERVER00x logicals look OK. = = =I would recommend defining NETLIB_DEBUG as well as MX_SMTP_DEBUG as TRUE then =re-starting the SMTP delivery agent. The debug log will then include the =MX lookup debugging information as well as the SMTP debugging information. =That might shed some light on what's going on. = =What should be happening is that the SMTP agent should be doing an MX =lookup on CCVAX1.CC.NCSU.EDU, which should fail, then it should be =asking UCX for an address for that host. The address lookup call (which =uses the UCX IO$_ACPCONTROL QIO) is probably what is returning the =end-of-file indicator (which is what UCX uses to mean that the lookup =failed). = =-Matt and =Archive-Date: Wed, 26 May 1993 21:00:40 CDT =Sender: list-mgr@WKUVX1.BITNET =From: =Subject: RE: MX SMTP and UCX domain lookup problems =Message-ID: <1993May26.223856.26428@news.arc.nasa.gov> =Reply-To: MX-List@WKUVX1.BITNET =Date: Wed, 26 May 1993 22:38:56 GMT =To: MX-List@WKUVX1.BITNET = =In article <0096D161.DF256080.14557@WKUVX1.BITNET>, Hunter Goatley = writes: =>> 870 translates to "end of file" while C278024 translates to "no =>>name-nomessage" which means, I guess, that I'm supposed to figure out which =>>message file I need and then do a SET MESSAGE.... =>> =>I think the SS$_ENDOFFILE is returned when the name servers don't =>return any information for the remote node. The question here is why =>is no info returned for MX when it is for Telnet, etc. = =Right. NETLIB tries to use UCX status codes regardless of which TCP/IP =package =you're using -- it translates package-specific codes into UCX codes whenever =it can. If you've got a copy of the UCX docs, you should find an explanation =for SS$_ENDOFFILE. = =-Matt and =Archive-Date: Fri, 28 May 1993 13:16:55 CDT =Sender: list-mgr@WKUVX1.BITNET =From: =Reply-To: MX-List@WKUVX1.BITNET =Subject: Re: MX SMTP and UCX domain lookup problems =Message-ID: <1993May28.184900.7948@rz-berlin.mpg.de> =Date: 28 May 93 18:49:00 +0100 =To: MX-List@WKUVX1.BITNET = =In article <0096D157.EC8CAA80.14505@WKUVX1.BITNET>, Hunter Goatley = writes: => Jerry Storrs of NCSU has a problem that has me stumped. He's running => MX V3.3 and UCX V1.3. All MX SMTP domain lookups are failing. Here's => a log that is typical of all of them: => =>>21-MAY-1993 15:18:32.88 Processing queue entry number 1000 =>>21-MAY-1993 15:18:33.13 Recipient: , => route=CCVAX1.CC.NCSU.EDU =>>21-MAY-1993 15:18:33.13 SMTP_SEND: looking up host name CCVAX1.CC.NCSU.EDU =>>21-MAY-1993 15:18:33.50 SMTP_SEND: Failed, sts=00000870 =>>21-MAY-1993 15:18:33.50 SMTP send failed, sts=0C278024, sts2=00000870 =>>21-MAY-1993 15:18:33.50 Recipient status=0C278024 for => => => He does have a name server defined, and TELNET, etc., works just fine. => But MX always returns this. Do any of you have any suggested courses of => action? His UCX host info looked fine to me, as did the name => server(s). The name servers are defined using the IP addresses, and => the UCX$BIND_SERVER00x logicals look OK. => => Thanks for any suggestions. = =Im also using UCX 1.3 =I got this twice: = =Nameserver works fine, no configuration changes, but MX suddenly fails to =resolve any name. restarting the MX SMTP agent fixes it. = =The first time it hit me, I restarted MX SMTP and just wondered. = =The next time, I was absent and someone else rebootet the system. Another =way to fix it ;-) = =But I was told, that some time before the second event, our primary =nameserver failed. They told me, nslookup on a sun produced a core dump. =So the nameserver was not off totaly, but produced answers, which this =high quality nslookup couldn't parse. So they rebooted the host with the =nameserver on it (lots of reboots, if i am away...) = =Now I could imagine the following events: = =- nameserver goes crazy =- MX wants to send a mail and asks the nameserver for MX-records =- nameserver answers junk (eg. bad name compression) =- MX caches junk as MX-forwarder (with high TTL) = =Even when the nameserver gets back to normal, MX will still find junk =MX-records in its cache and ask the UCX resolver for the address of =an invalid forwarder. UCX will of course answer with %X870. = =If I look at SMTP_OUT.B32 I see => ... => TRACE (' SMTP_SEND: looking up host name !AS', HOSTNM); => ... => STATUS = DNS_MXLOOK (HOSTNM, %REF (MXR_MAX), MXRCNT, MXR); => ... => STATUS = NET_GET_ADDRESS (TCPCTX, SDSC, 32, ADRLST, ADRCNT); => ... => IF .STATUS THEN => ... => END; => IF .STATUS THEN EXITLOOP .STATUS; => TRACE (' SMTP_SEND: Failed, sts=!XL', .STATUS); => ... =So an invalid cached MX-record would never show up in the log. Perhaps another =TRACE before or after NET_GET_ADDRESS could give us a clue. = =Just an idea. = =I'd love to investigate this, but my holliday is only some minutes away. =I would very much appreciate followup or solutions to this problem forwarded =to me by mail, because I won't be able to read news the next week. = =-- =Donald Buczek buczek@FHI-Berlin.MPG.DE "It's a Boo..." Hope this helps.... -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Tue, 08 Mar 1994 13:17:28 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: MX record problem Date: 8 Mar 1994 18:59:25 GMT Message-ID: <2lihud$fmv@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097B20B.F44F9FDA.5547@cheme.cornell.edu>, "Steve Thompson, Cheme System Mangler" writes: =MX 3.3, VAX/VMS 6.0, Multinet 3.2-D. = =Today I am having a problem with MX that I cannot figure out. I have a =whole bucketload of messages sitting in the queue, with MX showing a =last error of "%MX-F-NOHOST, no such host". The delivery attempts from =the SMTP log look like: = = 8-MAR-1994 12:43:41.72 Processing queue entry number 5515 on node VGER = 8-MAR-1994 12:43:42.10 Recipient: , route=cornell.edu = 8-MAR-1994 12:43:42.16 SMTP_SEND: looking up host name cornell.edu = 8-MAR-1994 12:43:46.73 SMTP_SEND: Failed, sts=00000870 = 8-MAR-1994 12:43:46.73 SMTP send failed, sts=0C278024, sts2=00000870 = 8-MAR-1994 12:43:46.73 Recipient status=0C278024 for = 8-MAR-1994 12:43:47.61 1 rcpts need retry, next try 8-MAR-1994 13:13:47.61 = 8-MAR-1994 12:43:47.64 *** End of processing pass *** = =In this case, cornell.edu is not a real host; it is an MX record. There =is no A record for cornell.edu; just the MX record which points to a =host which does have an A record. If I use NSLOOKUP to query the DNS =for the MX record, it is found properly. Looks as if MX is not picking =up the MX record. Hmmm. This is a bit confusing. Status %X870 (%SYSTEM-W-ENDOFFILE, end of file) is the typical response that one gets from CMUIP when the name resolution subsystem has failed. On the other hand, CMUIP doesn't have an NSLOOKUP command). What TCP/IP package are you using? -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Tue, 08 Mar 1994 14:59:28 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: olin@cheme.cornell.edu (Steve Thompson) Subject: Re: MX record problem Date: 8 Mar 1994 20:26:34 GMT Message-ID: <2lin1q$7u9@fitz.TC.Cornell.EDU> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097B20B.F44F9FDA.5547@cheme.cornell.edu>, I said: >MX 3.3, VAX/VMS 6.0, Multinet 3.2-D. >Today I am having a problem with MX that I cannot figure out. I have a >whole bucketload of messages sitting in the queue, with MX showing a >last error of "%MX-F-NOHOST, no such host". The delivery attempts from >the SMTP log look like: > > 8-MAR-1994 12:43:41.72 Processing queue entry number 5515 on node VGER > 8-MAR-1994 12:43:42.10 Recipient: , route=cornell.edu > 8-MAR-1994 12:43:42.16 SMTP_SEND: looking up host name cornell.edu > 8-MAR-1994 12:43:46.73 SMTP_SEND: Failed, sts=00000870 > 8-MAR-1994 12:43:46.73 SMTP send failed, sts=0C278024, sts2=00000870 > 8-MAR-1994 12:43:46.73 Recipient status=0C278024 for > 8-MAR-1994 12:43:47.61 1 rcpts need retry, next try 8-MAR-1994 13:13:47.61 > 8-MAR-1994 12:43:47.64 *** End of processing pass *** > >In this case, cornell.edu is not a real host; it is an MX record. There >is no A record for cornell.edu; just the MX record which points to a >host which does have an A record. If I use NSLOOKUP to query the DNS >for the MX record, it is found properly. Looks as if MX is not picking >up the MX record. Problem is solved. It turned out that the definition of the logical name MULTINET_NAMESERVERS was incorrect on one of my cluster nodes, even though the value shown by MULTINET CONFIGURE was correct. How it got that way I know not (yet). I reset the proper value of the logical name by hand, restarted the Multinet server process, and restarted MX, and all was fine. An essential component in tracking this down was not only MX_SMTP_DEBUG, but also NETLIB_DEBUG, which allows the MX lookups to become visible in the SMTP debug file. It was then obvious. My thanks to Dan Wing and Carl Lydick for their correspondence on this problem. -Steve --------------------------------------------------------------------------- Steve Thompson, System Mangler Internet: thompson@cheme.cornell.edu School of Chemical Engineering Phone: (607) 255 5573 Olin Hall, Cornell University FAX: (607) 255 9166 Ithaca NY 14853 --------------------------------------------------------------------------- ================================================================================ Archive-Date: Tue, 08 Mar 1994 16:55:18 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: olin@cheme.cornell.edu (Steve Thompson) Subject: Re: MX record problem Date: 8 Mar 1994 22:37:02 GMT Message-ID: <2liume$9e4@fitz.TC.Cornell.EDU> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <2lin1q$7u9@fitz.TC.Cornell.EDU>, I said: >Problem is solved. It turned out that the definition of the logical name >MULTINET_NAMESERVERS was incorrect on one of my cluster nodes, even though the >value shown by MULTINET CONFIGURE was correct. How it got that way I know not >(yet). I reset the proper value of the logical name by hand, restarted the >Multinet server process, and restarted MX, and all was fine. An essential >component in tracking this down was not only MX_SMTP_DEBUG, but also >NETLIB_DEBUG, which allows the MX lookups to become visible in the SMTP >debug file. It was then obvious. I'm not sure if this is obvious or not, but perhaps I should mention it anyway. It appeared during my dealings with the problem I mention above that if the nameserver list that Multinet uses is changed, the MX SMTP process appears to require stopping and restarting in order to pick up the changes; it didn't seem to notice automatically. Did I just dream this? -steve --------------------------------------------------------------------------- Steve Thompson, System Mangler Internet: thompson@cheme.cornell.edu School of Chemical Engineering Phone: (607) 255 5573 Olin Hall, Cornell University FAX: (607) 255 9166 Ithaca NY 14853 --------------------------------------------------------------------------- ================================================================================ Archive-Date: Tue, 08 Mar 1994 17:18:19 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: MX record problem Message-ID: <1994Mar8.155906.1251@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 8 Mar 94 15:59:06 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <2liume$9e4@fitz.TC.Cornell.EDU>, olin@cheme.cornell.edu (Steve Thompson) writes: >I'm not sure if this is obvious or not, but perhaps I should mention >it anyway. It appeared during my dealings with the problem I mention >above that if the nameserver list that Multinet uses is changed, >the MX SMTP process appears to require stopping and restarting in >order to pick up the changes; it didn't seem to notice automatically. >Did I just dream this? I "believe" that NETLIB does its own caching of nameserver responses (in fact, I'm pretty sure; I believe defining the logical NETLIB_DEBUG even causes NETLIB to display information about its caching of nameserver responses -- but it could just be displaying the same sortof (caching) information it got from its nameserver, and not that NETLIB is doing the caching itself....), and it is "likely" that the detached process (which is your SMTP client process [for outgoing mail]) runs the NETLIB initialization routines which cause NETLIB to look at certain nameservers. The source code would explain this sortof stuff for sure, though... Just guesses .... -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Wed, 09 Mar 1994 04:31:41 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Problems with the queue Message-ID: <1994Mar9.110651.891@hhcs.gov.au> From: Carl Makin Reply-To: MX-List@WKUVX1.WKU.EDU Date: 9 Mar 94 11:06:51 +1000 To: MX-List@WKUVX1.WKU.EDU Hi, I'm having some problems with the MX queue. I have around 2800 files total in the queue.n directories. The queue purge and queue show commands take a *very* long time to return. Is this normal? The system is a Vaxstation 3100 running Decus UUCP v2.0, MX v3.3 and ANU News v6.1b7. Carl. -- Carl Makin (VK1KCM) "Speaking for myself only!" makinc@hhcs.gov.au (Internet) / vk1kcm@vk1kcm.act.aus.oc (Packet Radio) 'The best book on programming for the layman is "Alice in Wonderland"; but that's because it's the best book on anything for the layman.' ================================================================================ Archive-Date: Wed, 09 Mar 1994 07:48:11 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 9 Mar 94 08:42:49 EST Message-ID: <0097B2B0C0BB5600.000022C3@sim.org> From: "Rich Hill" Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Help with MX Setup To: mx-list@wkuvx1.wku.edu I need some help in determining the best way to setup and use MX. I just received V3.3 from the file server at WKU. I am running two VAXes, MV3100 and a VAX 4000-400. These machines are NOT clustered, but are one the same ethernet LAN. Both are running DECnet, LAT, etc. They both can act as PathWorks servers. We are not running any other networking software (i.e. no TCP/IP, no SMTP, no X.25, etc.) The MV3100 has been used are a software development platform, and is now providing e-mail services. This machine runs the Alisa-Connection software which is a VMS Mail to EasyLink gateway, and DECUS UUCP V2.0. UUCP is used connect us to an internet provider here in NC, as well as providing a hub for connections to some of our offices in West Africa (all within the registered domain sim.org). The VAX 4000-400 is our main production machine, and thus contains all of our user's accounts and application software. I want to use MX as my interface to UUCP, and provide enhancements to VMS Mail. In addition I would like to develop an interface so that it can handle messages to/from the EasyLink gateway. At some point, we would also like to be able to make use of the list server and file server capabilities. So my question is: How do I deploy MX? Do I install it on both machines? Do I keep it on the MV3100? Do I just install portions on the VAX 4000? As far as addressing goes, both of the machines should be seen as the domain simusa.sim.org. ================================================================================ Archive-Date: Wed, 09 Mar 1994 09:05:57 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 09 Mar 1994 10:35:04 AST From: "Bruce S." Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B2C0.6F0CBEF6.7082@goat.drea.dnd.ca> Subject: Need MMS CROSS_ALPHA rules to build MX from scratch. Hello, I want to build MX033 from scratch for my VAXEN and ALPHAs. I have the mx033 source kit. MMS uses a rules file WKU$ROOT:[DATA]CROSS_ALPHA.MMS which I don't see in the kit. Can anybody send or point me to a copy? Regards++ Bruce S. | Bruce S. Skinner | skinner@goat.drea.dnd.ca | | DEFENCE RESEARCH ESTABLISHMENT ATLANTIC | skinner@hoss.drea.dnd.ca | | Dartmouth, Nova Scotia, CANADA, B2Y 3Z7 | (902) 426-3100 (205) | ================================================================================ Archive-Date: Wed, 09 Mar 1994 09:32:01 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 09 Mar 1994 09:47:53 EDT From: "MIKE MCINTYRE, MSM@MCINC.COM" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B2B9.D76196E0.11071@mcinc.com> Subject: automatic digesting software Hi Hunter and MX-List, I am looking for some software to automatically create digests. I am subscribed to MX-List-Digest and I really like that format. Is this software available and what language(s) is it implemented in? What else is out there for digest software? TIA, -mike 8^) The MUMPS Development Committee (MDC) may be reached at: The MUMPS Development Committee Phone: 301-431-4070 c/o MDC Secretariat Fax: 301-431-0017 1738 Elton Road, Suite 205 Silver Spring, MD 20903 Usenet: comp.std.mumps or std-mumps@pfcs.com (moderated) MDC Mailing List: mdc@mvb.saic.com ---- Michael McIntyre | McIntyre Consulting, Inc. | Tel: 508-371-1935 msm@mcinc.com | 336 Baker Ave; Concord,MA 01742-2107 | Fax: 508-369-6693 ================================================================================ Archive-Date: Wed, 09 Mar 1994 09:58:46 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: Problems with the queue Message-ID: <1994Mar9.082659.1253@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 9 Mar 94 08:26:58 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <1994Mar9.110651.891@hhcs.gov.au>, Carl Makin writes: >Hi, > >I'm having some problems with the MX queue. I have around 2800 files >total in the queue.n directories. The queue purge and queue show >commands take a *very* long time to return. > >Is this normal? No; for some reason your mail isn't getting "out" (or being delivered locally). >The system is a Vaxstation 3100 running Decus UUCP v2.0, MX v3.3 and >ANU News v6.1b7. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Wed, 09 Mar 1994 09:59:03 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: Help with MX Setup Message-ID: <1994Mar9.083128.1254@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 9 Mar 94 08:31:28 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097B2B0C0BB5600.000022C3@sim.org>, "Rich Hill" writes: >I am running two VAXes, MV3100 and a VAX 4000-400. These machines are >NOT clustered, but are one the same ethernet LAN. Both are running >DECnet, LAT, etc. They both can act as PathWorks servers. We are not >running any other networking software (i.e. no TCP/IP, no SMTP, no X.25, >etc.) > >The MV3100 has been used are a software development platform, and is now >providing e-mail services. This machine runs the Alisa-Connection >software which is a VMS Mail to EasyLink gateway, and DECUS UUCP V2.0. >UUCP is used connect us to an internet provider here in NC, as well as >providing a hub for connections to some of our offices in West Africa (all >within the registered domain sim.org). > >The VAX 4000-400 is our main production machine, and thus contains all of >our user's accounts and application software. [...] >So my question is: How do I deploy MX? Do I install it on both machines? >Do I keep it on the MV3100? Do I just install portions on the VAX 4000? I'd install MX, with UUCP and SMTP-over-DECnet support on the MicroVAX 3100, and install another copy of MX on the 4000 with SMTP-over-DECnet support. This would allow users on the 4000 to send mail even if your 3100 is down or unavailable; the 4000 would store-and-forward messages to the 3100. >As far as addressing goes, both of the machines should be seen as the >domain simusa.sim.org. How are you going to determine which machine to deliver mail to, or are you going to allow VMS1.simusa.sim.org and VMS2.simusa.sim.org or something like that? -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Wed, 09 Mar 1994 10:30:58 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: automatic digesting software Message-ID: <1994Mar9.091047.1255@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 9 Mar 94 09:10:46 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097B2B9.D76196E0.11071@mcinc.com>, "MIKE MCINTYRE, MSM@MCINC.COM" writes: >Hi Hunter and MX-List, > >I am looking for some software to automatically create digests. I am >subscribed to MX-List-Digest and I really like that format. > >Is this software available and what language(s) is it implemented in? > >What else is out there for digest software? Check out MX_ROOT:[CONTRIB]MX-DIGEST.ZIP (it is on my system running MX V3.4-beta, and might be on previous versions of MX, too -- not sure. If you don't have it, let me know and I'll fire it off to ya). It contains: MX-DIGEST -- Create digests for Message Exchange (MX) mailing lists Submitted by Hunter Goatley Last updated on 14-JAN-1994 Length Date Time Name ("^" ==> case ------ ---- ---- ---- conversion) 9170 05-01-93 01:18 aaareadme.txt 938 01-14-94 20:38 descrip.mms 1634 10-27-92 11:15 mx-digest-build.com 646 10-27-92 10:04 mx-digest-site_deliver.com 3204 01-18-94 11:50 mx_deliver_digests.com 6656 01-14-94 20:37 mx_digest.alpha_exe 15990 01-14-94 20:37 mx_digest.alpha_obj 7544 10-27-92 10:47 mx_digest.c 4096 01-14-94 20:39 mx_digest.exe 740 10-08-92 09:30 mx_digest.h 3676 01-14-94 20:37 mx_digest.obj 2356 05-04-93 08:06 mx_digest_submit.com 14336 01-14-94 20:37 mx_make_digest.alpha_exe 47014 01-14-94 20:37 mx_make_digest.alpha_obj 22477 04-30-93 17:26 mx_make_digest.c 11776 01-14-94 20:39 mx_make_digest.exe 11116 01-14-94 20:38 mx_make_digest.obj 32 01-14-94 20:37 vaxcrtl.opt Contents of AAAREADME.TXT: ** begin ** MX-DIGEST An MX Digest Maker May 1, 1993 The MX-DIGEST package allows MX sites to produce digests for MX mailing lists. The digest contains a copy of each message posted to a list, grouping related messages together in the order in which they were posted. MX_MAKE_DIGEST was written by David A. Curry (davy@intrepid.ecn.purdue.edu) for UN*X and modified by Hunter Goatley (goathunter@WKUVX1.BITNET) to work with Message eXchange (MX) under VMS. MX_DIGEST.C was written by Hunter Goatley. The MX-DIGEST Files ------------------------------ MX-DIGEST consists of the following files: AAAREADME.TXT This file MX-DIGEST-BUILD.COM Command procedure to build executables MX-DIGEST-SITE_DELIVER.COM SITE_DELIVER.COM for MX-DIGEST MX_DELIVER_DIGESTS.COM Command procedure to make and mail digests MX_DIGEST.C C source for program to create .INPUT files MX_DIGEST.EXE Executable linked under VMS v5.5-1 MX_DIGEST.H C include file MX_DIGEST.OBJ Object file created by VAX C v3.2 MX_DIGEST_SUBMIT.COM Command procedure for submitting digest runs MX_MAKE_DIGEST.C C source for program to create the digests MX_MAKE_DIGEST.EXE Executable linked under VMS v5.5-1 MX_MAKE_DIGEST.OBJ Object file created by VAX C v3.2 The comments at the top of MX_MAKE_DIGEST.C have not been modified to reflect how all of this works with MX. The modified version is included below. Building MX-DIGEST ------------------------------ The MX-DIGEST programs are written in C and can be compiled using either VAX C or GNU C. (Tested with VAX C v3.12 and GNU C v2.2.2.) To compile and link them, just run MX-DIGEST-BUILD: $ @MX-DIGEST-BUILD If you don't have either VAX C or GNU C, the .COM file will use the provided .OBJ files. Installing MX-DIGEST ------------------------------ Once the .EXEs are created, copy the following files to MX_EXE: MX_MAKE_DIGEST.EXE MX_DIGEST.EXE MX_DELIVER_DIGESTS.COM Additionally, MX-DIGEST-SITE_DELIVER.COM must be copied to MX_EXE:SITE_DELIVER.COM or merged with the existing SITE_DELIVER.COM. It's a very small file---merging it with an existing file should be straight-forward. MX_DELIVER_DIGESTS.COM should be executed at some regular interval by hand or by submitting it to a batch queue, or a program like DECscheduler or KRONOS. NOTE: It does *NOT* resubmit itself to a batch queue---if you go that route, you'll have to add that code yourself (or call it from an existing daily batch job). A sample command procedure to submit it, MX_DIGEST_SUBMIT.COM, is provided. As delivered, MX_DELIVER_DIGESTS.COM will only create a digest if the .INPUT file is larger than 15 blocks or is older than 3 days. If you want the digest created any time there are messages posted, then simply adjust the following symbol definitions in MX_DELIVER_DIGESTS.COM: $ minimum_digest_size = 15 !# of blocks before digest is sent $ maximum_digest_age = f$cvtime("TODAY-3-") Add the following commands to the MX configuration file using MCP: 1. In MCP, establish a PATH to invoke the SITE delivery agent to add messages to the *-DIGEST.INPUT file, e.g.,: MCP> define path DIGEST.SITE SITE/ROUTE=DIGEST (You only need one path, regardless of the number of lists.) 2. Add a rewrite rule like the following: MCP> DEFINE REWRITE_RULE "<{u}@DIGEST.SITE>" "<{u}@DIGEST.SITE>" Finally, for each list that is to be digested, you should perform the following steps: 1. Create a "-Digest" list. For example, here at WKU, there is an INFO-ZIP list *and* an INFO-ZIP-DIGEST list. Users are free to subscribe to either list---if they subscribe to the "-Digest" list, they will only receive the digests. MX_DELIVER_DIGESTS mails the digest to MX%{list-name}-DIGEST. 2. Create the *-DIGEST.* files in MX_SITE_DIR as decsribed below. Each list *must* have at least a list-DIGEST.INFO file. 3. Add a user to the list whose address is {list-address}@DIGEST.SITE. For example, the following address was added to the Info-Zip mailing list: info-zip@DIGEST.SITE Any message posted to the Info-Zip list will be processed by the SITE delivery agent and added to the INFO-ZIP-DIGEST.INPUT file in MX_SITE_DIR. How MX-DIGEST Works ------------------------------ MX_DIGEST is called by the SITE delivery agent to add the message to a .INPUT file for that list. This file is used instead of the normal MX archives for a number of reasons, the biggest of which is that it's a Stream_LF file, so the C library functions fseek() and ftell() will work on it. MX_MAKE_DIGEST is called by MX_DELIVER_DIGESTS to convert the .INPUT file to a .OUTPUT file, with is then mailed to the {list-name}-Digest list. From MX_MAKE_DIGEST: * This program uses the file "digest.info" to figure out what issue * of the digest it is making. The format of this file is: * * Name of the List # leave out the word "digest" * Host # the host where the digest lives * From # who sends the digest out * To # who the list is sent to * Volume # Volume XX : Issue XXX * Date # Day, dd Mon yy hh:mm:ss ZZZ * NOTE: the MX version does *not* use all of this info (specifically, the host, from, and to are ignored). HOWEVER, all lines should be present in the file. * As an example: * * Foobar * intrepid.ecn.purdue.edu * Dave Curry (The Moderator) * Foobar-List@intrepid.ecn.purdue.edu * Volume 1 : Issue 0 * Mon, 4 Jan 88 20:15:33 EST * * Make sure the "From" line includes a legitimate RFC 822 mail address. * Make sure the issue number starts at zero; it gets incremented BEFORE * generating each digest. Volume numbers must be incremented by hand. * The "digest.info" file gets modified by the program after generation * of each digest. * * The contents of the file "digest.head", if it exists, will be placed * between the list of today's topics and the top of the digest. This * can be used to put information about where to FTP archives from, etc. * * The file "digest.input" should contain a set of mail messages in the * format of a UNIX mailbox. These messages will be read into memory, * and a list of "Today's Topics" generated from the subject lines. The * messages will then be sorted so that all the messages on the same topic * come out together in the digest. Any message whost first word in the * subject line is "Administrivia" will be guaranteed to come out first * in the digest. * * The digest will be left in the file "digest.output". * * There is one problem with the sorting of messages by subject line to get * all the same topic together. The code handles elimination of "Re:" * strings, but if someone changes the subject on you, then things get ugly. * This shouldn't happen too often, though. * * Special thanks to Jon Solomon who sent me his TELECOM digest generating * program. I swiped a lot of ideas from it in writing this one. * * David A. Curry * davy@intrepid.ecn.purdue.edu */ To support multiple lists automatically under MX, this version actually puts "list-" in front of the "digest" files. For example, for the Info-Zip list, the files used are: INFO-ZIP-DIGEST.HEAD INFO-ZIP-DIGEST.INFO INFO-ZIP-DIGEST.INPUT (created by MX_DIGEST) These files are expected to be found in MX_SITE_DIR:. To support digests for multiple lists, just add the appropriate *-DIGEST.* files. Sample files are included below. ----------------------- Sample *-DIGEST.HEAD File ------------------------------ Send digest submissions to. . . . . . . Info-Zip@WKUVX1.BITNET Send add/unsubscribe requests to . . . . LISTSERV@WKUVX1.BITNET (send HELP for more information) Send problems about the list to. . . . . IZip-Mgr@WKUVX1.BITNET Send bug/problem reports about the ZIP or UNZIP programs to. . . . Zip-Bugs@WKUVX1.BITNET If you have trouble reaching WKUVX1, you might try: address%WKUVX1.BITNET@UKCC.UKY.EDU Archives for INFO-ZIP are on quest.jpl.nasa.gov (128.149.75.43). FTP as user "anonymous" with any password; then "cd pub". Zip and UnZip for many platforms can be found there. Past issues of the digest are in the "info-zip/MAIL" directory. ----------------------- Sample *-DIGEST.INFO File ------------------------------ INFO-ZIP WKUVX1.BITNET Hunter Goatley -- INFO-ZIP List Owner INFO-ZIP@WKUVX1.BITNET Volume 1 : Issue 0 Mon, 26 Oct 1992 17:00:27 -------------------------------------------------------------------------------- Questions, comments, or suggestions are welcome. Hunter Goatley, VAX Systems Programmer E-mail: goathunter@WKUVX1.BITNET Academic Computing, STH 226 Voice: (502) 745-5251 Western Kentucky University Bowling Green, KY 42101 ** end ** -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Wed, 09 Mar 1994 11:38:14 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 09 Mar 1994 11:35:05 CST From: Kenny Kon Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B2C8.D0E0B620.25787@bible.acu.edu> Subject: Re: Problems with the queue In article <1994Mar9.110651.891@hhcs.gov.au>, Carl Makin writes: >Hi, > >I'm having some problems with the MX queue. I have around 2800 files >total in the queue.n directories. The queue purge and queue show >commands take a *very* long time to return. > >Is this normal? I had this problem. Solved it by changing my number of outgoing SMTPs from 1 to 4. No problems now. Kenny ----- Kenny Kon, Assistant Systems Manager College of Biblical Studies, Abilene Christian University E-Mail: kenny.kon@BIBLE.ACU.EDU, Postmaster@BIBLE.ACU.EDU ================================================================================ Archive-Date: Wed, 09 Mar 1994 13:10:42 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 09 Mar 1994 13:26:38 EST From: "Brian Tillman" Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wku.edu Message-ID: <0097B2D8.6669D140.16202@swdev.si.com> Subject: External Mime encoding/decoding Several people have asked about a MIME (BASE64 or Quoted-Printable) decoder that can be used outside of MX to encode/decode. Below you will find the sources for such a decoder. I obtained it from Pete Sivia on DECUServe, who in turn obtained it from the MIME base distribution. I've packaged it up as a VMS_SHARE collection. It compiles with VAX C V3.2. The form of the command is: $ mmencode [-u] [-b] [-q] [-p] [-o outfile] [infile] If -u is absent, the infile is encoded. If -u is specified, infile is decoded. If -b is specified, the encoding/decoding is BASE64 If -q is specified, the encoding/decoding is Quoted-Printable If -p is specified, newlines are passed back to the encoding/decoding process (I'm not sure what this used for). If -o outfile is specified, the encoding/decoding is placed in outfile There is also a READ_MIME.COM procedure included to provide an interactive front end to MMENCODE. $! ------------------ CUT HERE ----------------------- $ v='f$verify(f$trnlnm("SHARE_UNPACK_VERIFY"))' $! $! This archive created: $! Name : MMENCODE $! By : tillman@swdev.si.com $! Date : 9-MAR-1994 13:23:10.79 $! Using: VMS_SHARE 8.4, (C) 1993 Andy Harper, Kings College London UK $! $! Credit is due to these people for their original ideas: $! James Gray, Michael Bednarek $! $! TO UNPACK THIS SHARE FILE, CONCATENATE ALL PARTS IN ORDER $! AND EXECUTE AS A COMMAND PROCEDURE ( @name ) $! $! THE FOLLOWING FILE(S) WILL BE CREATED AFTER UNPACKING: $! 1. MMENCODE.C;1 $! 2. CODES.C;1 $! 3. CONFIG.H;1 $! 4. READ_MIME.COM;1 $! $ set="set" $ set symbol/scope=(nolocal,noglobal) $ f=f$parse("SHARE_UNPACK_TEMP","SYS$SCRATCH:."+f$getjpi("","PID")) $ e="write sys$error ""%UNPACK"", " $ w="write sys$output ""%UNPACK"", " $ if .not. f$trnlnm("SHARE_UNPACK_LOG") then $ w = "!" $ if f$getsyi("CPU") .gt. 127 then $ goto start $ ve=f$getsyi("version") $ if ve-f$extract(0,1,ve) .ges. "4.4" then $ goto start $ e "-E-OLDVER, Must run at least VMS 4.4" $ v=f$verify(v) $ exit 44 $unpack: subroutine ! P1=filename, P2=checksum, P3=attributes,P4=size $ if f$parse(P1) .nes. "" then $ goto dirok $ dn=f$parse(P1,,,"DIRECTORY") $ w "-I-CREDIR, Creating directory ''dn'" $ create/dir 'dn' $ if $status then $ goto dirok $ e "-E-CREDIRFAIL, Unable to create ''dn' File skipped" $ delete 'f'* $ exit $dirok: $ x=f$search(P1) $ if x .eqs. "" then $ goto file_absent $ e "-W-EXISTS, File ''P1' exists. Skipped" $ delete 'f'* $ exit $file_absent: $ w "-I-UNPACK, Unpacking ", P5, " of ", P6, " - ", P1, " - ", P4, " Blocks" $ n=P1 $ if P3 .nes. "" then $ n=f $ if .not. f$verify() then $ define/user sys$output nl: $ EDIT/TPU/NOSEC/NODIS/COM=SYS$INPUT/NOJOURNAL 'f'/OUT='n' PROCEDURE GetHex(s,p)LOCAL x1,x2;x1:=INDEX(t,SUBSTR(s,p,1))-1;x2:=INDEX(t, SUBSTR(s,p+1,1))-1;RETURN 16*x1+x2;ENDPROCEDURE;PROCEDURE SkipPartsep LOCAL m; LOOP m:=MARK(NONE);EXITIF m=END_OF(b);DELETE(m);EXITIF INDEX(ERASE_LINE, "-+-+-+-+-+-+-+-+")=1;ENDLOOP;ENDPROCEDURE;PROCEDURE ProcessLine LOCAL c,s,l,b, n,p;c := ERASE_CHARACTER(1);s := ERASE_LINE;IF c = "X" THEN SPLIT_LINE; ENDIF; MOVE_HORIZONTAL(-1);l := LENGTH(s);p := 1;LOOP EXITIF p > l;c := SUBSTR(s,p,1); p := p+1;CASE c FROM ' ' TO '`' ['`']: COPY_TEXT(ASCII(GetHex(s,p))); p:=p+2;[ ' ']: p:=p+1;[INRANGE,OUTRANGE]: COPY_TEXT(c);ENDCASE;ENDLOOP;ENDPROCEDURE; PROCEDURE Decode LOCAL m;POSITION(BEGINNING_OF(b));LOOP m:=MARK(NONE);EXITIF m= END_OF(b);DELETE(m);IF INDEX(CURRENT_LINE,"+-+-+-+-+-+-+-+-")= 1 THEN SkipPartSep;ELSE ProcessLine;MOVE_HORIZONTAL(1);ENDIF;ENDLOOP; ENDPROCEDURE;SET(FACILITY_NAME,"UNPACK");SET(SUCCESS,OFF);SET(INFORMATIONAL, OFF);t:="0123456789ABCDEF";f:=GET_INFO(COMMAND_LINE,"file_name");b:= CREATE_BUFFER(f,f);Decode;WRITE_FILE(b,GET_INFO(COMMAND_LINE,"output_file")); QUIT; $ if p3 .eqs. "" then $ goto dl $ open/write fdl &f $ write fdl "RECORD" $ write fdl P3 $ close fdl $ w "-I-CONVRFM, Converting record format to ", P3 $ convert/fdl=&f &f-1 &P1 $dl: delete 'f'* $ checksum 'P1' $ if checksum$checksum .nes. P2 then $ - e "-E-CHKSMFAIL, Checksum of ''P1' failed." $ exit $ endsubroutine $start: $! $ create 'f' X/* XCopyright`20(c)`201991`20Bell`20Communications`20Research,`20Inc.`20(Bellcore) V X XPermission`20to`20use,`20copy,`20modify,`20and`20distribute`20this`20material V`20 Xfor`20any`20purpose`20and`20without`20fee`20is`20hereby`20granted,`20provided V`20 Xthat`20the`20above`20copyright`20notice`20and`20this`20permission`20notice`20 V Xappear`20in`20all`20copies,`20and`20that`20the`20name`20of`20Bellcore`20not`20 Vbe`20 Xused`20in`20advertising`20or`20publicity`20pertaining`20to`20this`20 Xmaterial`20without`20the`20specific,`20prior`20written`20permission`20 Xof`20an`20authorized`20representative`20of`20Bellcore.`20`20BELLCORE`20 XMAKES`20NO`20REPRESENTATIONS`20ABOUT`20THE`20ACCURACY`20OR`20SUITABILITY`20 XOF`20THIS`20MATERIAL`20FOR`20ANY`20PURPOSE.`20`20IT`20IS`20PROVIDED`20"AS`20IS V",`20 XWITHOUT`20ANY`20EXPRESS`20OR`20IMPLIED`20WARRANTIES. X*/ X#include`20 X#include`20 X#ifdef`20MSDOS X#include`20 X#endif X X#define`20BASE64`201 X#define`20QP`202`20/*`20quoted-printable`20*/ X Xmain(argc,`20argv) Xint`20argc; Xchar`20**argv; X`7B X`20`20`20`20int`20encode`20=`201,`20which`20=`20BASE64,`20i,`20portablenewline Vs`20=`200; X`20`20`20`20FILE`20*fp`20=`20stdin; X`20`20`20`20FILE`20*fpo`20=`20stdout; X X`20`20`20`20for`20(i=1;`20i=`20argc)`20`7B X`09`09`09fprintf(stderr,`20"mimencode:`20-o`20requires`20a`20file`20name.`5Cn" V); X`09`09`09exit(-1); X`09`09`20`20`20`20`7D X`09`09`20`20`20`20fpo`20=`20fopen(argv`5Bi`5D,`20"w"); X`09`09`20`20`20`20if`20(!fpo)`20`7B X`09`09`09perror(argv`5Bi`5D); X`09`09`09exit(-1); X`09`09`20`20`20`20`7D X`09`09`20`20`20`20break; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20case`20'u': X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20encode`20=`200; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20break; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20case`20'q': X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20which`20=`20QP; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20break; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20case`20'p': X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20portablenewlines V`20=`201; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20break; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20case`20'b': X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20which`20=`20BASE64 V; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20break; X`09`09default: X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20fprintf(stderr, X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20"Usage: V`20mmencode`20`5B-u`5D`20`5B-q`5D`20`5B-b`5D`20`5B-p`5D`20`5B-o`20outputfile V`5D`20`5Bfile`20name`5D`5Cn"); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20exit(-1); X`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`7D`20else`20`7B X#ifdef`20MSDOS X`20`20`20`20`20`20`20`20`20`20`20`20if`20(encode) X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20fp`20=`20fopen(argv`5Bi`5D,`20 V"rb"); X`20`20`20`20`20`20`20`20`20`20`20`20else X`20`20`20`20`20`20`20`20`20`20`20`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20fp`20=`20fopen(argv`5Bi`5D,`20 V"rt"); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20setmode(fileno(fpo),`20O_BINAR VY); X`20`20`20`20`20`20`20`20`20`20`20`20`7D`20/*`20else`20*/ X#else X`20`20`20`20`20`20`20`20`20`20`20`20fp`20=`20fopen(argv`5Bi`5D,`20"r"); X#endif`20/*`20MSDOS`20*/ X`20`20`20`20`20`20`20`20`20`20`20`20if`20(!fp)`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20perror(argv`5Bi`5D); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20exit(-1); X`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`7D X#ifdef`20MSDOS X`20`20`20`20if`20(fp`20==`20stdin)`20setmode(fileno(fp),`20O_BINARY); X#endif`20/*`20MSDOS`20*/ X`20`20`20`20if`20(which`20==`20BASE64)`20`7B X`20`20`20`20`20`20`20`20if`20(encode)`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20to64(fp,`20fpo,`20portablenewlines); X`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20from64(fp,fpo,`20(char`20**)`20NULL,`20(in Vt`20*)`200,`20portablenewlines); X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20if`20(encode)`20toqp(fp,`20fpo);`20else`20fromqp(fp, V`20fpo,`20NULL,`200); X`20`20`20`20`7D X`20`20`20`20return(0); X`7D X $ call unpack MMENCODE.C;1 861275605 "" 6 1 4 $! $ create 'f' X/* XCopyright`20(c)`201991`20Bell`20Communications`20Research,`20Inc.`20(Bellcore) V X XPermission`20to`20use,`20copy,`20modify,`20and`20distribute`20this`20material V`20 Xfor`20any`20purpose`20and`20without`20fee`20is`20hereby`20granted,`20provided V`20 Xthat`20the`20above`20copyright`20notice`20and`20this`20permission`20notice`20 V Xappear`20in`20all`20copies,`20and`20that`20the`20name`20of`20Bellcore`20not`20 Vbe`20 Xused`20in`20advertising`20or`20publicity`20pertaining`20to`20this`20 Xmaterial`20without`20the`20specific,`20prior`20written`20permission`20 Xof`20an`20authorized`20representative`20of`20Bellcore.`20`20BELLCORE`20 XMAKES`20NO`20REPRESENTATIONS`20ABOUT`20THE`20ACCURACY`20OR`20SUITABILITY`20 XOF`20THIS`20MATERIAL`20FOR`20ANY`20PURPOSE.`20`20IT`20IS`20PROVIDED`20"AS`20IS V",`20 XWITHOUT`20ANY`20EXPRESS`20OR`20IMPLIED`20WARRANTIES. X*/ X#include`20 X#include`20 X#include`20 X Xextern`20char`20*index(); Xstatic`20char`20basis_64`5B`5D`20= X`20`20`20"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"; X Xstatic`20char`20index_64`5B128`5D`20=`20`7B X`20`20`20`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1, X`20`20`20`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1, X`20`20`20`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,62,`20-1,-1,-1,63, X`20`20`20`2052,53,54,55,`2056,57,58,59,`2060,61,-1,-1,`20-1,-1,-1,-1, X`20`20`20`20-1,`200,`201,`202,`20`203,`204,`205,`206,`20`207,`208,`209,10,`201 V1,12,13,14, X`20`20`20`2015,16,17,18,`2019,20,21,22,`2023,24,25,-1,`20-1,-1,-1,-1, X`20`20`20`20-1,26,27,28,`2029,30,31,32,`2033,34,35,36,`2037,38,39,40, X`20`20`20`2041,42,43,44,`2045,46,47,48,`2049,50,51,-1,`20-1,-1,-1,-1 X`7D; X X#define`20char64(c)`20`20(((c)`20<`200`20`7C`7C`20(c)`20>`20127)`20?`20-1`20: V`20index_64`5B(c)`5D) X X/* Xchar64(c) Xchar`20c; X`7B X`20`20`20`20char`20*s`20=`20(char`20*)`20index(basis_64,`20c); X`20`20`20`20if`20(s)`20return(s-basis_64); X`20`20`20`20return(-1); X`7D X*/ X X/*`20the`20following`20gets`20a`20character,`20but`20fakes`20it`20properly`20i Vnto`20two`20chars`20if`20there's`20a`20newline`20character`20*/ Xstatic`20int`20InNewline=0; X Xint`20nextcharin(infile,`20PortableNewlines) XFILE`20*infile; Xint`20PortableNewlines; X`7B X`20`20`20`20int`20c; X X#ifndef`20NEWLINE_CHAR X`20`20`20`20return(getc(infile)); X#else X`20`20`20`20if`20(!PortableNewlines)`20return(getc(infile)); X`20`20`20`20if`20(InNewline)`20`7B X`20`20`20`20`20`20`20`20InNewline`20=`200; X`20`20`20`20`20`20`20`20return(10);`20/*`20LF`20*/ X`20`20`20`20`7D X`20`20`20`20c`20=`20getc(infile); X`20`20`20`20if`20(c`20==`20NEWLINE_CHAR)`20`7B X`20`20`20`20`20`20`20`20InNewline`20=`201; X`20`20`20`20`20`20`20`20return(13);`20/*`20CR`20*/ X`20`20`20`20`7D X`20`20`20`20return(c); X#endif X`7D X Xto64(infile,`20outfile,`20PortableNewlines)`20 XFILE`20*infile,`20*outfile; Xint`20PortableNewlines; X`7B X`20`20`20`20int`20c1,`20c2,`20c3,`20ct=0; X`20`20`20`20InNewline`20=`200;`20/*`20always`20reset`20it`20*/ X`20`20`20`20while`20((c1`20=`20nextcharin(infile,`20PortableNewlines))`20!=`20 VEOF)`20`7B X`20`20`20`20`20`20`20`20c2`20=`20nextcharin(infile,`20PortableNewlines); X`20`20`20`20`20`20`20`20if`20(c2`20==`20EOF)`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20output64chunk(c1,`200,`200,`202,`20outfile V); X`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20c3`20=`20nextcharin(infile,`20PortableNewl Vines); X`20`20`20`20`20`20`20`20`20`20`20`20if`20(c3`20==`20EOF)`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20output64chunk(c1,`20c2,`200, V`201,`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20output64chunk(c1,`20c2,`20c3, V`200,`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20ct`20+=`204; X`20`20`20`20`20`20`20`20if`20(ct`20>`2071)`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20putc('`5Cn',`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20ct`20=`200; X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`7D X`20`20`20`20if`20(ct)`20putc('`5Cn',`20outfile); X`20`20`20`20fflush(outfile); X`7D X Xoutput64chunk(c1,`20c2,`20c3,`20pads,`20outfile) XFILE`20*outfile; X`7B X`20`20`20`20putc(basis_64`5Bc1>>2`5D,`20outfile); X`20`20`20`20putc(basis_64`5B((c1`20`26`200x3)<<`204)`20`7C`20((c2`20`26`200xF0 V)`20>>`204)`5D,`20outfile); X`20`20`20`20if`20(pads`20==`202)`20`7B X`20`20`20`20`20`20`20`20putc('=',`20outfile); X`20`20`20`20`20`20`20`20putc('=',`20outfile); X`20`20`20`20`7D`20else`20if`20(pads)`20`7B X`20`20`20`20`20`20`20`20putc(basis_64`5B((c2`20`26`200xF)`20<<`202)`20`7C`20(( Vc3`20`26`200xC0)`20>>6)`5D,`20outfile); X`20`20`20`20`20`20`20`20putc('=',`20outfile); X`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20putc(basis_64`5B((c2`20`26`200xF)`20<<`202)`20`7C`20(( Vc3`20`26`200xC0)`20>>6)`5D,`20outfile); X`20`20`20`20`20`20`20`20putc(basis_64`5Bc3`20`26`200x3F`5D,`20outfile); X`20`20`20`20`7D X`7D X XPendingBoundary(s,`20Boundaries,`20BoundaryCt) Xchar`20*s; Xchar`20**Boundaries; Xint`20*BoundaryCt; X`7B X`20`20`20`20int`20i,`20len; X X`20`20`20`20if`20(s`5B0`5D`20!=`20'-'`20`7C`7C`20s`5B1`5D`20!=`20'-')`20return V(0); X X X`20`20`20`20for`20(i=0;`20i`20<`20*BoundaryCt;`20++i)`20`7B X`09len`20=`20strlen(Boundaries`5Bi`5D); X`20`20`20`20`20`20`20`20if`20(!strncmp(s,`20Boundaries`5Bi`5D,`20len))`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20if`20(s`5Blen`5D`20==`20'-'`20`26`26`20s V`5Blen+1`5D`20==`20'-')`20*BoundaryCt`20=`20i; X`20`20`20`20`20`20`20`20`20`20`20`20return(1); X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`7D X`20`20`20`20return(0); X`7D X X/*`20If`20we're`20in`20portable`20newline`20mode,`20we`20have`20to`20convert V`20CRLF`20to`20the`20 X`20`20`20`20local`20newline`20convention`20on`20output`20*/ X Xstatic`20int`20CRpending`20=`200; X X#ifdef`20NEWLINE_CHAR Xalmostputc(c,`20outfile,`20PortableNewlines) Xint`20c; XFILE`20*outfile; Xint`20PortableNewlines; X`7B X`20`20`20`20if`20(CRpending)`20`7B X`20`20`20`20`20`20`20`20if`20(c`20==`2010)`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20putc(NEWLINE_CHAR,`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20CRpending`20=`200; X`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20putc(13,`20outfile); X`09`20`20`20`20if`20(c`20!=`2013)`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`09putc(c,`20outfile); X`09`09CRpending`20=`200; X`09`20`20`20`20`7D X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20if`20(PortableNewlines`20`26`26`20c`20==`2013)`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20CRpending`20=`201; X`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20putc(c,`20outfile); X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`7D X`7D X#else Xalmostputc(c,`20outfile,`20PortableNewlines) Xint`20c; XFILE`20*outfile; Xint`20PortableNewlines; X`7B X`20`20`20`20putc(c,`20outfile); X`7D X#endif X Xfrom64(infile,`20outfile,`20boundaries,`20boundaryct,`20PortableNewlines)`20 XFILE`20*infile,`20*outfile; Xchar`20**boundaries; Xint`20*boundaryct; Xint`20PortableNewlines; X`7B X`20`20`20`20int`20c1,`20c2,`20c3,`20c4; X`20`20`20`20int`20newline`20=`201,`20DataDone`20=`200; X X`20`20`20`20/*`20always`20reinitialize`20*/ X`20`20`20`20CRpending`20=`200; X`20`20`20`20while`20((c1`20=`20getc(infile))`20!=`20EOF)`20`7B X`20`20`20`20`20`20`20`20if`20(isspace(c1))`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20if`20(c1`20==`20'`5Cn')`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20newline`20=`201; X`20`20`20`20`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20newline`20=`200; X`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`20`20`20`20continue; X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20if`20(newline`20`26`26`20boundaries`20`26`26`20c1`20== V`20'-')`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20char`20Buf`5B200`5D; X`20`20`20`20`20`20`20`20`20`20`20`20/*`20a`20dash`20is`20NOT`20base`2064,`20so V`20all`20bets`20are`20off`20if`20NOT`20a`20boundary`20*/ X`20`20`20`20`20`20`20`20`20`20`20`20ungetc(c1,`20infile); X`20`20`20`20`20`20`20`20`20`20`20`20fgets(Buf,`20sizeof(Buf),`20infile); X`20`20`20`20`20`20`20`20`20`20`20`20if`20(boundaries X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`26`26`20(Buf`5B0`5D`20== V`20'-') X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`26`26`20(Buf`5B1`5D`20== V`20'-') X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`26`26`20PendingBoundary(Bu Vf,`20boundaries,`20boundaryct))`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20return; X`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`20`20`20`20fprintf(stderr,`20"Ignoring`20unrecognized V`20boundary`20line:`20%s`5Cn",`20Buf); X`20`20`20`20`20`20`20`20`20`20`20`20continue; X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20if`20(DataDone)`20continue; X`20`20`20`20`20`20`20`20newline`20=`200; X`20`20`20`20`20`20`20`20do`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20c2`20=`20getc(infile); X`20`20`20`20`20`20`20`20`7D`20while`20(c2`20!=`20EOF`20`26`26`20isspace(c2)); V X`20`20`20`20`20`20`20`20do`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20c3`20=`20getc(infile); X`20`20`20`20`20`20`20`20`7D`20while`20(c3`20!=`20EOF`20`26`26`20isspace(c3)); V X`20`20`20`20`20`20`20`20do`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20c4`20=`20getc(infile); X`20`20`20`20`20`20`20`20`7D`20while`20(c4`20!=`20EOF`20`26`26`20isspace(c4)); V X`20`20`20`20`20`20`20`20if`20(c2`20==`20EOF`20`7C`7C`20c3`20==`20EOF`20`7C`7C V`20c4`20==`20EOF)`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20fprintf(stderr,`20"Warning:`20base64`20dec Voder`20saw`20premature`20EOF!`5Cn"); X`20`20`20`20`20`20`20`20`20`20`20`20return; X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20if`20(c1`20==`20'='`20`7C`7C`20c2`20==`20'=')`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20DataDone=1; X`20`20`20`20`20`20`20`20`20`20`20`20continue; X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20c1`20=`20char64(c1); X`20`20`20`20`20`20`20`20c2`20=`20char64(c2); X`20`20`20`20`20`20`20`20almostputc(((c1<<2)`20`7C`20((c2`260x30)>>4)),`20outfi Vle,`20PortableNewlines); X`20`20`20`20`20`20`20`20if`20(c3`20==`20'=')`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20DataDone`20=`201; X`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20c3`20=`20char64(c3); X`20`20`20`20`20`20`20`20`20`20`20`20almostputc((((c2`260XF)`20<<`204)`20`7C`20 V((c3`260x3C)`20>>`202)),`20outfile,`20PortableNewlines); X`20`20`20`20`20`20`20`20`20`20`20`20if`20(c4`20==`20'=')`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20DataDone`20=`201; X`20`20`20`20`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20c4`20=`20char64(c4); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20almostputc((((c3`260x03)`20<<6 V)`20`7C`20c4),`20outfile,`20PortableNewlines); X`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`7D X`20`20`20`20if`20(CRpending)`20putc(13,`20outfile);`20/*`20Don't`20drop`20a`20 Vlone`20trailing`20char`2013`20*/ X`7D X Xstatic`20char`20basis_hex`5B`5D`20=`20"0123456789ABCDEF"; Xstatic`20char`20index_hex`5B128`5D`20=`20`7B X`20`20`20`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1, X`20`20`20`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1, X`20`20`20`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1, X`20`20`20`20`200,`201,`202,`203,`20`204,`205,`206,`207,`20`208,`209,-1,-1,`20- V1,-1,-1,-1, X`20`20`20`20-1,10,11,12,`2013,14,15,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1, X`20`20`20`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1, X`20`20`20`20-1,10,11,12,`2013,14,15,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1, X`20`20`20`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1,`20-1,-1,-1,-1 X`7D; X X/*`20The`20following`20version`20generated`20complaints`20on`20Solaris.`20*/ X/*`20#define`20hexchar(c)`20`20(((c)`20<`200`20`7C`7C`20(c)`20>`20127)`20?`20- V1`20:`20index_hex`5B(c)`5D)`20`20*/ X/*`20`20Since`20we're`20no`20longer`20ever`20calling`20it`20with`20anything`20 Vsigned,`20this`20should`20work:`20*/ X#define`20hexchar(c)`20`20(((c)`20>`20127)`20?`20-1`20:`20index_hex`5B(c)`5D) V X X/* Xhexchar(c) Xchar`20c; X`7B X`20`20`20`20char`20*s; X`20`20`20`20if`20(islower(c))`20c`20=`20toupper(c); X`20`20`20`20s`20=`20(char`20*)`20index(basis_hex,`20c); X`20`20`20`20if`20(s)`20return(s-basis_hex); X`20`20`20`20return(-1); X`7D X*/ X Xtoqp(infile,`20outfile)`20 XFILE`20*infile,`20*outfile; X`7B X`20`20`20`20int`20c,`20ct=0,`20prevc=255; X`20`20`20`20while`20((c`20=`20getc(infile))`20!=`20EOF)`20`7B X`20`20`20`20`20`20`20`20if`20((c`20<`2032`20`26`26`20(c`20!=`20'`5Cn'`20`26`26 V`20c`20!=`20'`5Ct')) X`20`20`20`20`20`20`20`20`20`20`20`20`20`7C`7C`20(c`20==`20'=') X`20`20`20`20`20`20`20`20`20`20`20`20`20`7C`7C`20(c`20>=`20127) X`20`20`20`20`20`20`20`20`20`20`20`20`20/*`20Following`20line`20is`20to`20avoid V`20single`20periods`20alone`20on`20lines, X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20which`20messes`20up`20some`20dumb V`20smtp`20implementations,`20sigh...`20*/ X`20`20`20`20`20`20`20`20`20`20`20`20`20`7C`7C`20(ct`20==`200`20`26`26`20c`20== V`20'.'))`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20putc('=',`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20putc(basis_hex`5Bc>>4`5D,`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20putc(basis_hex`5Bc`260xF`5D,`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20ct`20+=`203; X`20`20`20`20`20`20`20`20`20`20`20`20prevc`20=`20'A';`20/*`20close`20enough`20* V/ X`20`20`20`20`20`20`20`20`7D`20else`20if`20(c`20==`20'`5Cn')`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20if`20(prevc`20==`20'`20'`20`7C`7C`20prevc V`20==`20'`5Ct')`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20putc('=',`20outfile);`20/*`20s Voft`20`26`20hard`20lines`20*/ X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20putc(c,`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`20`20`20`20putc(c,`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20ct`20=`200; X`20`20`20`20`20`20`20`20`20`20`20`20prevc`20=`20c; X`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20if`20(c`20==`20'F'`20`26`26`20prevc`20== V`20'`5Cn')`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20/*`20HORRIBLE`20but`20clever V`20hack`20suggested`20by`20MTR`20for`20sendmail-avoidance`20*/ X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20c`20=`20getc(infile); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20if`20(c`20==`20'r')`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20c`20=`20getc(infil Ve); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20if`20(c`20==`20'o' V)`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20c`20= V`20getc(infile); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20if`20( Vc`20==`20'm')`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20c`20=`20getc(infile); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20if`20(c`20==`20'`20')`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20/*`20This`20is`20the`20case`20we`20are`20looking`20for`20*/ V X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20fputs("=46rom",`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20ct`20+=`206; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20fputs("From",`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`20`20`20`20ct`20+=`204; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20`7D X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`7D`20 Velse`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20fputs("Fro",`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20 V`20`20ct`20+=`203; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20fputs( V"Fr",`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20ct`20+ V=`202; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20putc('F',`20outfil Ve); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20++ct; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20ungetc(c,`20infile); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20prevc`20=`20'x';`20/*`20close V`20enough`20--`20printable`20*/ X`20`20`20`20`20`20`20`20`20`20`20`20`7D`20else`20`7B`20/*`20END`20horrible`20h Vack`20*/ X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20putc(c,`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20++ct; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20prevc`20=`20c; X`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20if`20(ct`20>`2072)`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20putc('=',`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20putc('`5Cn',`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20ct`20=`200; X`20`20`20`20`20`20`20`20`20`20`20`20prevc`20=`20'`5Cn'; X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`7D X`20`20`20`20if`20(ct)`20`7B X`20`20`20`20`20`20`20`20putc('=',`20outfile); X`20`20`20`20`20`20`20`20putc('`5Cn',`20outfile); X`20`20`20`20`7D X`7D X Xfromqp(infile,`20outfile,`20boundaries,`20boundaryct)`20 XFILE`20*infile,`20*outfile; Xchar`20**boundaries; Xint`20*boundaryct; X`7B X`20`20`20`20unsigned`20int`20c1,`20c2; X`20`20`20`20int`20sawnewline`20=`201,`20neednewline`20=`200; X`20`20`20`20/*`20The`20neednewline`20hack`20is`20necessary`20because`20the`20n Vewline`20leading`20into`20 X`20`20`20`20`20`20a`20multipart`20boundary`20is`20part`20of`20the`20boundary, V`20not`20the`20data`20*/ X X`20`20`20`20while`20((c1`20=`20getc(infile))`20!=`20EOF)`20`7B X`20`20`20`20`20`20`20`20if`20(sawnewline`20`26`26`20boundaries`20`26`26`20(c1 V`20==`20'-'))`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20char`20Buf`5B200`5D; X`20`20`20`20`20`20`20`20`20`20`20`20unsigned`20char`20*s; X X`20`20`20`20`20`20`20`20`20`20`20`20ungetc(c1,`20infile); X`20`20`20`20`20`20`20`20`20`20`20`20fgets(Buf,`20sizeof(Buf),`20infile); X`20`20`20`20`20`20`20`20`20`20`20`20if`20(boundaries X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`26`26`20(Buf`5B0`5D`20== V`20'-') X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`26`26`20(Buf`5B1`5D`20== V`20'-') X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`26`26`20PendingBoundary(Bu Vf,`20boundaries,`20boundaryct))`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20return; X`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`20`20`20`20/*`20Not`20a`20boundary,`20now`20we`20must V`20treat`20THIS`20line`20as`20q-p,`20sigh`20*/ X`20`20`20`20`20`20`20`20`20`20`20`20if`20(neednewline)`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20putc('`5Cn',`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20neednewline`20=`200; X`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`20`20`20`20for`20(s=(unsigned`20char`20*)`20Buf;`20*s V;`20++s)`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20if`20(*s`20==`20'=')`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20if`20(!*++s)`20bre Vak; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20if`20(*s`20==`20' V`5Cn')`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20/*`20i Vgnore`20it`20*/ X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20sawnew Vline`20=`201; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20c1`20= V`20hexchar(*s); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20if`20( V!*++s)`20break; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20c2`20= V`20hexchar(*s); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20putc(c V1<<4`20`7C`20c2,`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`7D`20else`20`7B X#ifdef`20MSDOS X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20if`20(*s`20==`20' V`5Cn') X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20putc(' V`5Cr',`20outfile);`09/*`20insert`20CR`20for`20binary-mode`20write`20*/ X#endif X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20putc(*s,`20outfile V); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20if`20(neednewline)`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20putc('`5Cn',`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20neednewline`20=`200; X`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`20`20`20`20if`20(c1`20==`20'=')`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20sawnewline`20=`200; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20c1`20=`20getc(infile); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20if`20(c1`20==`20'`5Cn')`20`7B V X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20/*`20ignore`20it V`20*/ X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20sawnewline`20=`201 V; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20c2`20=`20getc(infi Vle); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20c1`20=`20hexchar(c V1); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20c2`20=`20hexchar(c V2); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20putc(c1<<4`20`7C V`20c2,`20outfile); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20if`20(c2`20==`20' V`5Cn')`20sawnewline`20=`201; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20if`20(c1`20==`20'`5Cn')`20`7B V X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20sawnewline`20=`201 V; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20neednewline`20=`20 V1; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`7D`20else`20`7B X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20sawnewline`20=`200 V; X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20putc(c1,`20outfile V); X`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`20`20`20`20`7D X`20`20`20`20`20`20`20`20`7D X`20`20`20`20`7D X`20`20`20`20if`20(neednewline)`20`7B X`20`20`20`20`20`20`20`20putc('`5Cn',`20outfile); X`20`20`20`20`20`20`20`20neednewline`20=`200; X`20`20`20`20`7D`20`20`20`20 X`7D $ call unpack CODES.C;1 268628869 "" 25 2 4 $! $ create 'f' X/* XCopyright`20(c)`201991`20Bell`20Communications`20Research,`20Inc.`20(Bellcore) V X XPermission`20to`20use,`20copy,`20modify,`20and`20distribute`20this`20material V`20 Xfor`20any`20purpose`20and`20without`20fee`20is`20hereby`20granted,`20provided V`20 Xthat`20the`20above`20copyright`20notice`20and`20this`20permission`20notice`20 V Xappear`20in`20all`20copies,`20and`20that`20the`20name`20of`20Bellcore`20not`20 Vbe`20 Xused`20in`20advertising`20or`20publicity`20pertaining`20to`20this`20 Xmaterial`20without`20the`20specific,`20prior`20written`20permission`20 Xof`20an`20authorized`20representative`20of`20Bellcore.`20`20BELLCORE`20 XMAKES`20NO`20REPRESENTATIONS`20ABOUT`20THE`20ACCURACY`20OR`20SUITABILITY`20 XOF`20THIS`20MATERIAL`20FOR`20ANY`20PURPOSE.`20`20IT`20IS`20PROVIDED`20"AS`20IS V",`20 XWITHOUT`20ANY`20EXPRESS`20OR`20IMPLIED`20WARRANTIES. X*/ X X/*`20This`20is`20the`20top-level`20configuration`20file`20for`20the`20metamail V`20distribution.`20*/ X/*`20If`20your`20compiler`20does`20not`20automatically`20do`20so,`20you`20may V`20wish`20to`20 X`20`20`20`20`20`20add`20a`20#define`20here`20that`20defines`20your`20system`20 Vtype,`20e.g. X`20`20`20`20`20`20#define`20LINUX X`20`20`20`20`20`20#define`20SYSV`20 X`20`20`20`20`20`20#define`20MSDOS X`20`20`20`20`20`20#define`20AMIGA X*/ X X#ifdef`20AIX X#define`20SYSV X#endif X#ifdef`20_AIX X#define`20SYSV X#endif X X#ifdef`20__svr4__ X#ifndef`20SYSV X/*`20Stupid`20Solaris`202.0`20machines`20define`20__svr4__`20but`20not`20SYSV V`20*/ X#define`20SYSV X#endif X#endif X X#ifdef`20LINUX X#define`20SYSV`20/*`20Linux`20is`20SysV`20*/ X#endif X X#ifdef`20SVR3 X#ifndef`20SYSV X/*`20Stupid`20SGI`20machines`20define`20SVR3`20but`20not`20SYSV`20*/ X#define`20SYSV X#endif X#endif X X#ifdef`20__MSDOS__`09/*`20Defined`20if`20using`20Borland`20C`20compiler?`20*/ V X#ifndef`20BORLAND X#define`20BORLAND`09`09/*`20Make`20sure`20BORLAND`20gets`20defined`20*/ X#endif X#ifndef`20MSDOS X#define`20MSDOS`20`20`20/*`20A`20common`20symbol`20we`20can`20use`20for`20all V`20DOS`20compilers`20*/ X#endif X#endif X X#ifdef`20_MSC_VER`09`09/*`20Using`20Microsoft`20C`20compiler`20*/ X#ifndef`20MICROSOFT X#define`20MICROSOFT`09/*`20Make`20sure`20MICROSOFT`20gets`20defined`20*/ X#endif X#ifndef`20MSDOS X#define`20MSDOS`20`20`20/*`20A`20common`20symbol`20we`20can`20use`20for`20all V`20DOS`20compilers`20*/ X#endif X#endif X X/*`20NOTE:`20`20The`20RESET_PROGRAM`20resets`20the`20terminal`20to`20a`20"norm Val"`20state`20 X`20`20`20If`20you`20comment`20out`20the`20definition,`20all`20will`20be`20well V`20except`20that`20metamail's X`20`20`20-R`20switch`20won't`20work,`20and`20metamail-called`20programs`20migh Vt`20be`20more`20likely X`20`20`20to`20screw`20up`20your`20terminal`20state`20*/ X X#ifdef`20SYSV X#define`20RESET_PROGRAM`20"tput`20clear" X#else X#ifdef`20__BSD_4_4__ X#define`20RESET_PROGRAM`20"/usr/bin/reset" X#else X#define`20RESET_PROGRAM`20"/usr/ucb/reset" X#endif X#endif X X#ifdef`20__hpux X/*`20Basically`20SYSV`20*/ X#define`20SYSV X#define`20NO_RLIMITS`201 X/*`20I've`20gotten`20conflicting`20reports`20about`20the`20best`20way`20to`20r Veset`20the`20terminal`20 X`20`20state`20under`20hpux.`20`20I'm`20now`20using`20"/usr/bin/reset"`20as`20t Vhe`20default,`20but`20there`20 X`20`20have`20been`20two`20other`20suggestions`20as`20well.`20`20Your`20mileage V`20may`20vary!`20--`20NSB`20*/ X#undef`20RESET_PROGRAM X#define`20RESET_PROGRAM`20"/usr/bin/reset" X/*`20#define`20RESET_PROGRAM`20"tput`20clear"`20*/ X/*`20#define`20RESET_PROGRAM`20"/bin/reset"`20*/ X/*`20#define`20RESET_PROGRAM`20"/usr/ucb/reset"`20*/ X#endif X X#ifdef`20NeXT X#undef`20RESET_PROGRAM X#define`20RESET_PROGRAM`20"/usr/ucb/reset" X#endif X X#ifdef`20SYSV X#define`20killpg(a,`20b)`20kill(-(a),`20(b)) X#define`20bcopy(a,`20b,`20c)`20memcpy(b,`20a,`20c) X#define`20bzero(a,`20b)`20memset(a,`200,`20b) X#define`20bcmp`20memcmp X#define`20index`20strchr X#define`20rindex`20strrchr X#define`20initstate`20srand X#define`20random`20rand X#define`20NO_RLIMITS`201 X#define`20sigtype`20void X#endif X X/*`20Solaris,`20at`20least,`20has`20better`20versions`20of`20some`20functions V`20*/ X#ifdef`20__svr4__ X#define`20bcopy(a,`20b,`20c)`20memmove(b,`20a,`20c) X#define`20initstate`20srand48 X#define`20random`20lrand48 X#endif X X/*`20This`20constant`20should`20define`20the`20ASCII`20code`20for`20newlines V`20on`20systems`20where`20 X`20`20`20the`20newline`20convention`20is`20other`20than`20CRLF.`20`20On`20UNIX V,`20it`20is`20`5EJ,`20ASCII`2010.`20 X`20`20`20`20Here`20we`20define`20it`20as`20'`5Cn'`20which`20should`20be`20righ Vt`20on`20MOST`20systems...`20*/ X#define`20NEWLINE_CHAR`20'`5Cn' X X#ifdef`20MSDOS X#undef`20NEWLINE_CHAR`20/*`20DOS`20uses`20CRLF`20*/ X#undef`20RESET_PROGRAM X#include`20 X#define`20index`20`20strchr X#define`20rindex`20strrchr X#define`20popen`20`20fopen X#define`20pclose`20fclose X#define`20NO_RLIMITS`201 X#endif X X#ifdef`20AMIGA X#undef`20RESET_PROGRAM X#define`20index`20`20strchr X#define`20rindex`20strrchr X#define`20NO_RLIMITS`201 X#define`20DEFAULT_SPLIT_SIZE`2095000 X#endif X X/*`20The`20following`20defines`20the`20default`20size`20at`20which`20long X`20`20`20`20messages`20will`20be`20split`20into`20multiple`20messages`20of`20t Vype X`20`20`20`20"message/partial"`20by`20the`20mailto`20and`20splitmail`20commands V, X`20`20`20`20at`20least.`20*/ X#ifndef`20DEFAULT_SPLIT_SIZE X#define`20DEFAULT_SPLIT_SIZE`20250000 X#endif X X#ifndef`20sigtype X#ifdef`20NeXT X#define`20sigtype`20void X#else X#define`20sigtype`20int X#endif X#endif X X#ifdef`20MSDOS X#define`20PATH_SEPARATOR`20';' X#ifndef`20STDPATH X#define`20STDPATH`20".`5C`5Cmailcap;`5C`5Cmailcap" X#endif X#else X#ifdef`20AMIGA X#define`20PATH_SEPARATOR`20'`20' X#ifndef`20STDPATH X#define`20STDPATH`20"uulib:mailcap" X#endif X#else X#define`20PATH_SEPARATOR`20':' X#ifndef`20STDPATH X#define`20STDPATH`20"/.mailcap:/usr/local/etc/mailcap:/usr/etc/mailcap:/etc/ma Vilcap:/etc/mail/mailcap:/usr/public/lib/mailcap" X#endif X#endif X#endif X X/*`20The`20following`20can`20be`20set`20to`20a`20directory`20or`20colon-separa Vted`20list`20of`20 X`20`20directories`20that`20will`20be`20prepended`20to`20the`20user's`20search V`20path`20before`20 X`20`20executing`20any`20mailcap-derived`20commands.`20 X X`20`20It`20should`20be`20set`20to`20NULL`20if`20there`20are`20no`20directories V`20to`20prepend.`20`20 X*/ X X#define`20AUXPATH`20NULL $ call unpack CONFIG.H;1 1278233841 "" 10 3 4 $! $ create 'f' X$MMENCODE:=$USR_SCRATCH:`5BSIVIA`5DMMENCODE X$! X$!`20READ_MIME.COM X$! X$!`20Run`20either`20by`20prompts`20or`20by`20@READ_MINE`20inputfile`20outputfi Vle`201or2 X$!`20(1or2`20means`201=BASE64,`202=QUOTE-PRINTABLE`20encoding)`20 X$! X$WRITE`20SYS$OUTPUT`20"This`20routine`20converts`20a`20MIME-encoded`20message V`20into X$WRITE`20SYS$OUTPUT`20"something`20readable.`20`20Two`20formats`20are`20suppor Vted`20--" X$WRITE`20SYS$OUTPUT`20"BASE64`20and`20QUOTE-PRINTABLE.`20`20Determine`20which V`20is`20used" X$WRITE`20SYS$OUTPUT`20"by`20reading`20the`20header`20line`20entitled: X$WRITE`20SYS$OUTPUT`20"Content-Transfer-Encoding" X$WRITE`20SYS$OUTPUT`20"" X$IF`20("''P1'"`20.EQS.`20"")`20THEN`20READ/PROMPT="Input`20file?`20"`20SYS$COM VMAND`20P1 X$IF`20("''P1'"`20.EQS.`20"")`20THEN`20EXIT X$IF`20("''P2'"`20.EQS.`20"")`20THEN`20READ/PROMPT="Output`20file?`20"`20SYS$CO VMMAND`20P2 X$IF`20("''P2'"`20.EQS.`20"")`20THEN`20EXIT X$! X$SEARCH`20'P1'`20"Content-Transfer-Encoding" X$! X$IF`20("''P3'"`20.EQS.`20"1"`20.OR.`20"''P3'"`20.EQS.`20"2")`20THEN`20GOTO`20D VO_IT X$! X$WRITE`20SYS$OUTPUT`20"Is`20this`20BASE64`20(1)`20or`20QUOTE-PRINTABLE`20(2)" V X$READ/PROMPT="Enter`201`20or`202`20(D=2)`20"`20SYS$COMMAND`20X X$IF`20("''X'"`20.EQS.`20"")`20THEN`20X=2 X$IF`20("''X'"`20.NES.`20"1"`20.AND.`20"''X'"`20.NES.`20"2")`20THEN`20EXIT X$! X$DO_IT: X$IF`20("''X'"`20.EQS.`20"1") X`09$THEN X`09`09$ASSIGN/USER`20NL:`20SYS$ERROR X`09`09$ASSIGN/USER`20'P2'`20SYS$OUTPUT X`09`09$MMENCODE`20-u`20-b`20'P1' X`09$ELSE X`09`09$ASSIGN/USER`20NL:`20SYS$ERROR X`09`09$ASSIGN/USER`20'P2'`20SYS$OUTPUT X`09`09$MMENCODE`20-u`20-q`20'P1' X$ENDIF X$! X$WRITE`20SYS$OUTPUT`20"Done.`20`20Original`20file`20''P1';`20Converted`20file V`20''P2'" X$EXIT $ call unpack READ_MIME.COM;1 1174430164 "" 3 4 4 $ v=f$verify(v) $ exit ================================================================================ Archive-Date: Wed, 09 Mar 1994 13:41:47 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: lederman@intransit_tsc.vntsc.dot.gov (lederman) Subject: Re: BASE64 Decoder? Message-ID: <1994Mar9.142325.44@bosv01> Date: 9 Mar 94 14:23:23 EST Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU I also needed to decode some MIME files, and expect to do so more in the future. With some help from Dan Wing I was able to figure out a way. It isn't very elegant, but it works. First I obtained the MX 4.0 Beta kit. Then I extracted DECODE.OLB from one of the save sets (I think C). Then by reading the KITINSTAL.COM, I came up (after a couple of tries) with this command file which will link MX_DECODE.EXE even if you're still running on 3.3 as I am: $ LINK /map /NOUSERLIBRARY /exe = MX_DECODE.EXE sys$input /opt DECODE.OLB/INCLUDE=MX_DECODE/LIB DECODE.OLB/LIB MX_EXE:MX_SHR.EXE/SHARE $ EXIT You should define a foreign command like MX_DECODE :== $sys$login:MX_DECODE.EXE or wherever you put the image, or you can RUN it and be prompted for the missing input and output files. The trick is that you have to go into the BASE64 text file and change the header so MX_DECODE will recognize it. I suppose an editor command procedure could be developed for this, but I did mine manually. The following worked for me when decoding some JPEG files: the output is variable-length Stream-LF, but it could be anything. You can stick (probably) any valid FDL file into the header. I've also tried fixed-length 512 byte files and they work. MIME-Version: 1.0 Content-Transfer-Encoding: BASE64 Content-Type: APPLICATION/VMS-RMS; VMS-FDL="SYSTEM; SOURCE VAX/VMS;;FILE; ALLOCATION 100; BEST_TRY_CONTIGUOUS no; CONTIGUOUS no; EXTENSION 0; GLOBAL_BUFFER_COUNT 0; FILE_MONITORING no; ORGANIZATION sequential; READ_CHECK no; SUPERSEDE no; WRITE_CHECK no; PROTECTION (system:RWD, owner:RWD, group:, world:);; RECORD; BLOCK_SPAN yes; CARRIAGE_CONTROL none; FORMAT stream_lf; SIZE 0;" As I said, not very elegant (with the hand editing), but it has worked for me. -- B. Z. Lederman. My personal opinions. ================================================================================ Archive-Date: Wed, 09 Mar 1994 17:45:57 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: Problems with the queue Date: 9 Mar 1994 23:19:09 GMT Message-ID: <2lllhd$713@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <1994Mar9.110651.891@hhcs.gov.au>, Carl Makin writes: =I'm having some problems with the MX queue. I have around 2800 files =total in the queue.n directories. The queue purge and queue show =commands take a *very* long time to return. = =Is this normal? Having 2800 files in the directories? No. Having the queue commands be slow if you've got that many files (that's about 700 queue entries)? Yes. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Wed, 09 Mar 1994 21:44:20 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 09 Mar 1994 19:40:41 PST From: "David Scott Cunningham, TRIUMF, 604 222-1047" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B30C.A75EDAE0.5805@erich.triumf.ca> Subject: log and accounting files Hello, In the next release could it be made so that the log and accounting files are opened the same way that vms log files are, such that they are being written to by one process, but can still be read by others? Dave ================================================================================ Archive-Date: Thu, 10 Mar 1994 07:59:52 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Thu, 10 Mar 1994 15:07:53 -0100 To: From: Robertini@sns.it (Marco Robertini) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: SITE_DELIVER example Some week ago we deinstalled our IBM mainframe named IPISNSIB. I had the RSCS table modified to have all things directed to IPISNSIB diverted to our VAX which has MX and JNET. But e-mail arrived to MAILER@IPISNSIB and having added Path IPISNSIB --> local, to MAILER@VAXSNS.SNS.IT my vax. MAILER@VAXSNS.SNS.IT had a forward set to ROBERTINI (me :-), so that I was receiving all e-mails of IBM's user, and manually delivered :-(. I have fixed in this way: MAILER@VAXSNS.SNS.IT now has forward set to QWERTY@QWERTY; I have added path QWERTY --> SITE, and I have written the following file-commands. The trick is that all this type of mail have a line RCPT TO: inside, wich brings the original destination. Obviously I have all original IBM'username duplicated like account or like forward address onto my vax. Hope this useful for someone! Many thanks to Miklos Pa'sztor for his site_deliver template and the idea. Sorry for italian comment... $! $! Marzo 1994 $! Author: Marco Robertini su un'idea di Pa'sztor Miklos $! $ show sym p1 ! p1 = route ==> QWERTY $ show sym p2 ! p2 = msg file spec $ show sym p3 ! p3 = destinazione ==> To: $ show sym p4 ! p4 = indirizzo di partenza ==> From: $ reply/bell/use=robertini "Site deliver in azione..." $ set ver $ route = f$edit("''p1'", "UPCASE") $ Message_File = f$search(p2) !pathname completo del file $ if route .EQS. "QWERTY" then goto cerca $ exit $! $!cerca nel messaggio la stringa RCPT TO: $ cerca: $ almeno_uno = "FALSO" !per ora non ne ha trovati $ open/read txtFile 'Message_File' $ open/write destinazione dest_address.tmp !scrive qui tutti quelli che trova $! $ cercaRCPT_TO: $ read/err=Fine_Ricerca txtFile linea $ gosub purge_quotes !elimina tutti i doppi apici $! $ UPlinea = f$edit("''linea'", "UPCASE, COMPRESS") !tutto maiuscolo $ sho sym UPlinea $ ind = F$LOCATE("RCPT TO:",UPlinea) $ IF ind .EQ. F$LENGTH( UPlinea ) THEN GOTO cercaRCPT_TO !non c'era $! $ trovata: $ almeno_uno = "TRUE" $ dest_add = F$EXTR(0,ind,UPlinea) + F$EXTR(ind + 8, F$LEN(UPlinea), UPlinea) $ sh sym dest_add $ write destinazione dest_add $ GOTO cercaRCPT_TO !continua la ricerca di altri RCPT TO $! $ Fine_Ricerca: $ close txtFile $ close destinazione $ IF almeno_uno .EQS. "TRUE" THEN GOTO delivera $ mail/sub="messaggio senza RCPT stringa" 'Message_file' "robertini" $ exit 1 $! $! $! MX_SITE_IN accoda ad MX il messaggio con i parametri modificati $! $ delivera: $ mx_enter = "$MX_EXE:MX_SITE_IN" $ mx_enter 'Message_file' dest_address.tmp 'p4' $ exit 1 $! $ purge_quotes: $ purge_next_quote: $ m = F$LOCATE("""", linea) $ IF m .EQ. F$LEN(linea) THEN $ RETURN $ linea = F$EXTR(0,m,linea) + F$EXTRACT(m+1, F$LENGTH(linea), linea) $ GOTO purge_next_quote $ return !finto $ ++++++++++++++++++++++++++++++++++++++++++++++++++++ + Marco Robertini +39 50 509268 + + Fax +39 50 563513 + + Lan manager - Scuola Normale Superiore di Pisa + ++++++++++++++++++++++++++++++++++++++++++++++++++++ ================================================================================ Archive-Date: Thu, 10 Mar 1994 13:56:27 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: Problems with the queue Message-ID: <1994Mar10.102628.892@hhcs.gov.au> From: Carl Makin Reply-To: MX-List@WKUVX1.WKU.EDU Date: 10 Mar 94 10:26:27 +1000 To: MX-List@WKUVX1.WKU.EDU In article <1994Mar9.110651.891@hhcs.gov.au> Carl Makin, makinc@hhcs.gov.au writes: > I'm having some problems with the MX queue. I have around 2800 files > total in the queue.n directories. The queue purge and queue show > commands take a *very* long time to return. Well it looks like I posted a little to quickly. :-( I let a mcp queue purge complete . It took around 3 hours and it removed all but a few of the offending files. Things are quick again. I though the queue purge was supposed to happen automatically? Carl. -- Carl Makin (VK1KCM) "Speaking for myself only!" makinc@hhcs.gov.au (Internet) / vk1kcm@vk1kcm.act.aus.oc (Packet Radio) 'The best book on programming for the layman is "Alice in Wonderland"; but that's because it's the best book on anything for the layman.' ================================================================================ Archive-Date: Fri, 11 Mar 1994 01:58:44 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Fri, 11 Mar 1994 17:55:03 +1000 From: Powell HEUER Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: powell@syd.dwt.csiro.au Message-ID: <0097B490.3ADA89C0.49@syd.dwt.CSIRO.AU> Subject: Queue problems I am running MX V.3.3 and have just started seeing some message files in the queue directory rather than the sub-directories. They are therefore not getting purged. Other messages are still being placed correctly in the sub-directories and being purged. Directory MX_ROOT:[QUEUE] 0.DIR;1 1 10-FEB-1994 15:33:50.16 1.DIR;1 1 10-FEB-1994 15:33:52.09 12.HDR_INFO;1 1 11-MAR-1994 14:04:19.74 12.MSG_TEXT;1 11 11-MAR-1994 14:04:19.89 12.SRC_INFO;1 2 11-MAR-1994 14:04:19.52 2.DIR;1 1 10-FEB-1994 15:33:54.02 21.HDR_INFO;1 1 11-MAR-1994 14:43:46.18 21.MSG_TEXT;1 3 11-MAR-1994 14:43:46.34 21.SRC_INFO;1 1 11-MAR-1994 14:43:46.04 3.DIR;1 1 10-FEB-1994 15:33:55.97 4.DIR;1 1 10-FEB-1994 15:33:57.98 46.HDR_INFO;1 1 11-MAR-1994 16:53:37.20 46.MSG_TEXT;1 2 11-MAR-1994 16:53:37.42 46.SRC_INFO;1 1 11-MAR-1994 16:53:36.99 5.DIR;1 1 10-FEB-1994 15:33:59.88 6.DIR;1 1 10-FEB-1994 15:34:01.91 7.DIR;1 1 10-FEB-1994 15:34:03.80 8.DIR;1 1 10-FEB-1994 15:34:05.72 9.DIR;1 1 10-FEB-1994 15:34:07.74 SYSTEM_QUEUE.FDL;1 2 15-OCT-1990 21:59:50.15 SYSTEM_QUEUE.FLQ_CTL;2 45 11-MAR-1994 12:59:56.71 I have turned on FLQ debugging and can see no errors being reported. The contents of the last part of the most recent log file is: 11-MAR-1994 17:24:46.23 %FLQ_CLEANUP, time to check for cleanups 11-MAR-1994 17:24:49.02 %FLQ_CLEANUP: Checking lock, resnam=FLQ_LOCK_SYD_RQC 11-MAR-1994 17:24:49.06 %FLQ_CLEANUP: Someone else is doing the cleanups. Bye. 11-MAR-1994 17:26:46.44 %FLQ_CLEANUP, time to check for cleanups 11-MAR-1994 17:26:49.50 %FLQ_CLEANUP: Checking lock, resnam=FLQ_LOCK_SYD_RQC 11-MAR-1994 17:26:49.54 %FLQ_CLEANUP: Someone else is doing the cleanups. Bye. 11-MAR-1994 17:28:46.64 %FLQ_CLEANUP, time to check for cleanups 11-MAR-1994 17:28:46.69 %FLQ_CLEANUP, time to make a purge pass 11-MAR-1994 17:28:46.69 %FLQ_CLEANUP, PURGE: purging entry 47 11-MAR-1994 17:28:47.09 %FLQ_CLEANUP, PURGE: purging entry 48 11-MAR-1994 17:28:47.26 %FLQ_CLEANUP, PURGE: final FLQ_SEARCH status = 0001827A 11-MAR-1994 17:28:47.26 %FLQ_CLEANUP, EXPIRE: final FLQ_SEARCH status = 000182B2 11-MAR-1994 17:28:49.97 %FLQ_CLEANUP: Checking lock, resnam=FLQ_LOCK_SYD_RQC 11-MAR-1994 17:28:50.17 %FLQ_CLEANUP: Someone else is doing the cleanups. Bye. 11-MAR-1994 17:30:47.57 %FLQ_CLEANUP, time to check for cleanups 11-MAR-1994 17:30:50.70 %FLQ_CLEANUP: Checking lock, resnam=FLQ_LOCK_SYD_RQC 11-MAR-1994 17:30:50.78 %FLQ_CLEANUP: Someone else is doing the cleanups. Bye. This seems to show that messages after the ones with the files in the wrong place are getting purged as expected. I have recently upgraded from MX V3.2 to V3.3. I had some problems with this. Initially MX would accept messages but never process them. I finally found this seemed to be due to a corrupt queue file from V3.2. The old version of MX was still working but the files associated with old messages were not getting purged and MCP QUEUE SHO/ALL never showed anything in the queue. Once I created a new queue file I was able to start V3.3. This was a week ago. The file became corrupt again (under V3.3) earlier today. I recreated it (using the FDL from the distribution). MX seemed to run OK for a few hours before these problems. The queue file is OK at present (no errors from ANALY/RMS/CHECK). Can anyone suggest what I should check? ================================================================================ Archive-Date: Sat, 12 Mar 1994 01:47:20 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Sat, 12 Mar 1994 10:29:34 -0305 From: SAEED KHADEMI Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wkuvx1.wku.edu Message-ID: <0097B51B.298A8F40.28292@IREARN.BITNET> Subject: New version Hello All, Could someone tell me where can I find MX V4? Is this the latest version? Many thanks in advance. Regards, Saeed. +-----------------------------------------------------------+ | Saeed Khademi | E-mail : SAEED@IREARN.BITNET | | Computer Department | Phone : +9821 243860 | | Institute for studies in | P.O.Box: 19395-1795 | | theoretical Physics and | Fax : +9821 8014003 | | Mathematics ( IPM ) | Telex : +9821 214758 | | Iran/Tehran | | +-----------------------------------------------------------+ ================================================================================ Archive-Date: Sun, 13 Mar 1994 03:38:33 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: clee@td2cad.intel.com (Mantas _DO_ Fly) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: new to fileserv (setting it up) Date: 11 Mar 1994 02:42:36 GMT Message-ID: <2lolqs$kjk@chnews.intel.com> To: MX-List@WKUVX1.WKU.EDU Hi, I just turned on Fileserv with MX 3.3 and appear to hit a problem. Tried the docs and didn't find an answer there - so I hope somebody can help me out. Fileserve works fine if I send a request to it with an Ip address like FILESERV@mymachine. Problem is that some of my users will want (need to) to use DECnet. But mymachine::FILESERV just results in a "no such user" error from VMSmail. Can the Fileserv in MX be made to work with DECnet mail addresses? thx C. Lee Cecil Lee, Intel Corp., CLee@MADOKA.INTEL.COM UUCP : {pur-ee,qantel,amdcad,oliveb,decwrl,hplabs}!intelca!mipos3!madoka!clee Not An Evil Tempter Being Disclaimer: Just _My_ Opinions ================================================================================ Archive-Date: Sun, 13 Mar 1994 05:43:09 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Sun, 13 Mar 1994 12:35:39 EST From: Ralph Kloess Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-LIST%WKUVX1.WKU.EDU@VISION.RS.CH Message-ID: <0097B5F5.F0D1B800.25153@EUROPA.RS.CH> Subject: Re.: new to fileserv (setting it up) > > Fileserve works fine if I send a request to it with an Ip >address like FILESERV@mymachine. Problem is that some of my users will >want (need to) to use DECnet. > > But mymachine::FILESERV just results in a "no such user" error >from VMSmail. > > Can the Fileserv in MX be made to work with DECnet mail >addresses? > > thx > C. Lee Yes, it can. Either install MX on both machine and DECnet-SMTP, or send from the remote node to the MX-node with DECNET and on the MX-node with MX. To do the that the address would be: MXNODE::MX%"fileserv@whatever.who.cares" Regards, Ralph Kloess +--------------------------------------+--------------------------------------+ I Ralph Kloess I I I I I +--------------------------------------+--------------------------------------+ ================================================================================ Archive-Date: Sun, 13 Mar 1994 11:09:36 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: new to fileserv (setting it up) Date: 13 Mar 1994 16:46:25 GMT Message-ID: <2lvg11$qpt@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <2lolqs$kjk@chnews.intel.com>, clee@td2cad.intel.com (Mantas _DO_ Fly) writes: = I just turned on Fileserv with MX 3.3 and appear to hit a =problem. Tried the docs and didn't find an answer there - so I hope =somebody can help me out. = = Fileserve works fine if I send a request to it with an Ip =address like FILESERV@mymachine. Problem is that some of my users will =want (need to) to use DECnet. = = But mymachine::FILESERV just results in a "no such user" error =from VMSmail. = = Can the Fileserv in MX be made to work with DECnet mail =addresses? From an account with SYSNAM priv: $ MAIL MAIL> SET FORWARD/USER=FILESERV MX%FILESERV -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Sun, 13 Mar 1994 21:44:38 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: clee@td2cad.intel.com (Mantas _DO_ Fly) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: setting up fileserv - thx for the replies Date: 13 Mar 1994 20:24:55 GMT Message-ID: <2lvsqn$dkm@chnews.intel.com> To: MX-List@WKUVX1.WKU.EDU Just wanted to thank everybody for the replies to my FILESERV question . I used the SET FORWARD/user=FILESERV mx%FILESERV and it works like a charm. Thx again/ Ceci l Cecil Lee, Intel Corp., CLee@MADOKA.INTEL.COM UUCP : {pur-ee,qantel,amdcad,oliveb,decwrl,hplabs}!intelca!mipos3!madoka!clee Not An Evil Tempter Being Disclaimer: Just _My_ Opinions ================================================================================ Archive-Date: Mon, 14 Mar 1994 05:36:42 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 14 Mar 1994 12:33:22 +0100 From: Juan Altmayer Pizzorno Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B6BE.C98AE643.6@vms.gmd.de> Subject: RE: New version >Hello All, > Could someone tell me where can I find MX V4? Is this the latest version? > Many thanks in advance. MX 4.0 is still in beta-testing. It will probably be soon available from the usual MX sources (ftp.spc.edu, etc.) .. Juan ================================================================================ Archive-Date: Mon, 14 Mar 1994 08:12:27 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: New version Message-ID: <1994Mar14.064522.1282@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 14 Mar 94 06:45:22 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097B51B.298A8F40.28292@IREARN.BITNET>, SAEED KHADEMI writes: >Hello All, > Could someone tell me where can I find MX V4? Is this the latest version? > Many thanks in advance. It is currently in beta test. Contact Hunter Goatley, goathunter@wkuvx1.wku.edu, to get on the beta test mailing list and for the location of the save-sets. -dan -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Mon, 14 Mar 1994 08:47:26 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 14 Mar 1994 09:37:54 EST From: "Brian Tillman" Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wku.edu Message-ID: <0097B6A6.465DFC60.19068@swdev.si.com> Subject: MX and the VMS security update Digital has just issued a security patch for VMS V5.4-3 through V6.0. The cover letter with that patch says that aopplications using the DECwindows transport routines, the MAIL utility routines, and the PTD$ routines are affected. Certainly MX uses the MAIL utility routines, correct? Should MX be re-installed after the security patch is applied? -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Mon, 14 Mar 1994 10:15:22 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 14 Mar 1994 10:12:00 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: SKINNER@GOAT.DREA.DND.CA Message-ID: <0097B6AB.09E58091.15@ALPHA.WKU.EDU> Subject: RE: Can anybody here tell me the status of BLISS for ALPHAs? "Bruce S." writes: > >Hello, > > Am I correct in assuming that MX033 for the AXP was built on a VAX >using a BLISS Cross Compiler? > Yes, that version was build using the cross compiler. The next version will be built with a native BLISS compiler on AXP. > If I am, perhaps someone can tell me what they've heard from DEC >about the availability of this cross-compiler and what the future >holds for said cross-compiler. The local DEC office tells me that >this cross compiler was part of the Application Migration Toolkit, >that it is only available to Application Migration Centers, that it >won't run on VMS 6.0 and never will! > There's no reason that I know of that it won't run on V6.0, but they were designed to run only with VMS V5.4---the cross-compiler RTLs, etc., were VMS V5.4 versions. A number of people have told me that they can no longer order the migration toolkit. I have part numbers for it, if anyone needs it. > I know that DEC has a BLISS-64 compiler for AXP, but I have been told >that it is not available as a product. I have had a BLISS-32 license >since 1985 and I'm not getting good vibes about continued support for >BLISS on the AXP's. > Correct. Digital apparently is going to let BLISS die out. They say, "BLISS isn't used much." Well, of course it's not---Digital priced the compiler so high in the beginning that nobody could justify it. It was several times the cost of all the other compilers. So now, because they don't see a large BLISS customer base, they don't want to support it on AXP. It does exist, though the only way I know of to get it is through the Digital Partner Network (formerly ISVnet). > Can anyone verify or deny any of this? What does the future hold >for MX on AXPs? > I've been told by Digital ISV people that I should be able to use BLISS indefinitely through the ISV program, but there are no guarantees. MX *will* always be supported on AXP, one way or another. > Can someone point me to a copy of the mms rules for building MX on AXP >(WKU$ROOT:[DATA]CROSS_ALPHA.MMS)? > That's something I threw together. What I currently use, using the native AXP BLISS, is below. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) --------------------------------------------------------------------------- ! MMS_DEFAULT_RULES.MMS ! ! Default build rules for use with MMS. (for AXP systems) ! ! Modification history: ! ! 23-DEC-1992 V1.0 Madison Initial coding. ! ! ! This symbol can be used to distinguish this MMS from DEC's DEC/MMS product ! using .IFDEF directives. ! __MATTS_MMS__ = __MATTS_MMS__ __ALPHA__ = 1 EXE = .ALPHA_EXE OLB = .ALPHA_OLB OBJ = .ALPHA_OBJ OPT = .ALPHA_OPT L32 = .L32E .SUFFIXES : ! clear the suffix list first .SUFFIXES : $(EXE) $(OLB) $(OBJ) .TLB .HLB .MLB $(L32) .C .BAS .B32 .BLI .FOR - .COB .COR .DBL .RPG .SCN .PLI .PEN .PAS .MAC .MAR .M64 .MSG .CLD - .R32 .REQ .TXT .H .MEM .HLP .RNH .RNO LINK = LINK LINKFLAGS = /EXEC=$(MMS$TARGET) LIBR = LIBRARY LIBRFLAGS = /REPLACE $(OBJ)$(OLB) : IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE $(MMS$TARGET) $(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE) @ IF "$(MMK_DELETE_SOURCE)" THEN DELETE/NOLOG $(MMS$SOURCE);* .TXT.TLB : IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/TEXT $(MMS$TARGET) $(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE)/MODULE=$(MMS$TARGET_MODULE) @ IF "$(MMK_DELETE_SOURCE)" THEN DELETE/NOLOG $(MMS$SOURCE);* .HLP.HLB : IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/HELP $(MMS$TARGET) $(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE) @ IF "$(MMK_DELETE_SOURCE)" THEN DELETE/NOLOG $(MMS$SOURCE);* .MAC.MLB : IF F$SEARCH("$(MMS$TARGET)") .EQS. "" THEN $(LIBR)/CREATE/MACRO $(MMS$TARGET) $(LIBR)$(LIBRFLAGS) $(MMS$TARGET) $(MMS$SOURCE) @ IF "$(MMK_DELETE_SOURCE)" THEN DELETE/NOLOG $(MMS$SOURCE);* BASIC = BASIC BASFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) .BAS$(OBJ) : $(BASIC)$(BASFLAGS) $(MMS$SOURCE) BLISS = BLISS BFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) .BLI$(OBJ) : $(BLISS)$(BFLAGS) $(MMS$SOURCE) .B32$(OBJ) : $(BLISS)$(BFLAGS) $(MMS$SOURCE) CC = CC CFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) .C$(OBJ) : $(CC)$(CFLAGS) $(MMS$SOURCE) COBOL = COBOL COBFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) .COB$(OBJ) : $(COBOL)$(COBFLAGS) $(MMS$SOURCE) CORAL = CORAL CORFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) .COR$(OBJ) : $(CORAL)$(CORFLAGS) $(MMS$SOURCE) DIBOL = DIBOL DBLFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) .DBL$(OBJ) : $(DIBOL)$(DBLFLAGS) $(MMS$SOURCE) SETCMD = SET COMMAND SETCMDFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) .CLD$(OBJ) : $(SETCMD)$(SETCMDFLAGS) $(MMS$SOURCE) FORT = FORTRAN FFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) .FOR$(OBJ) : $(FORT)$(FFLAGS) $(MMS$SOURCE) MACRO = MACRO/MIGRATION MFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) .MAR$(OBJ) : $(MACRO)$(MFLAGS) $(MMS$SOURCE) TASM = MACRO TASMFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) .M64$(OBJ) : $(TASM)$(TASMFLAGS) $(MMS$SOURCE) MESSAGE = MESSAGE MSGFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) .MSG$(OBJ) : $(MESSAGE)$(MSGFLAGS) $(MMS$SOURCE) PASCAL = PASCAL PFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) PENVFLAGS = /ENVIRONMENT=$(MMS$TARGET)/NOLIST .PAS$(OBJ) : $(PASCAL)$(PFLAGS) $(MMS$SOURCE) .PAS.PEN : $(PASCAL)$(PENVFLAGS) $(MMS$SOURCE) PLI = PLI PLIFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) .PLI$(OBJ) : $(PLI)$(PLIFLAGS) $(MMS$SOURCE) BLIBFLAGS = /NOLIST .REQ$(L32) : $(BLISS)/LIBR=$(MMS$TARGET)$(BLIBFLAGS) $(MMS$SOURCE) .R32$(L32) : $(BLISS)/LIBR=$(MMS$TARGET)$(BLIBFLAGS) $(MMS$SOURCE) RPG = RPG RPGFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) .RPG$(OBJ) : $(RPG)$(RPGFLAGS) $(MMS$SOURCE) RUNOFF = RUNOFF RFLAGS = /OUTPUT=$(MMS$TARGET) .RNH.HLP : $(RUNOFF)$(RFLAGS) $(MMS$SOURCE) .RNO.MEM : $(RUNOFF)$(RFLAGS) $(MMS$SOURCE) SCAN = SCAN SCANFLAGS = /NOLIST/OBJECT=$(MMS$TARGET) .SCN$(OBJ) : $(SCAN)$(SCANFLAGS) $(MMS$SOURCE) ================================================================================ Archive-Date: Mon, 14 Mar 1994 10:58:29 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 14 Mar 1994 10:52:24 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B6B0.AEC81C4F.46@ALPHA.WKU.EDU> Subject: RE: MX and the VMS security update "Brian Tillman" writes: > >Digital has just issued a security patch for VMS V5.4-3 through V6.0. The cover >letter with that patch says that aopplications using the DECwindows transport >routines, the MAIL utility routines, and the PTD$ routines are affected. >Certainly MX uses the MAIL utility routines, correct? Should MX be re-installed >after the security patch is applied? I wouldn't think so, but I haven't installed (or received) the patch. It probably just replaces the MAIL RTLs---MX will just automatically use the new ones. Note that Digital's security update for AXP introduced another new memory leak in the callable mail stuff.... Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Mon, 14 Mar 1994 11:03:39 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: MX and the VMS security update Message-ID: <1994Mar14.084706.1285@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 14 Mar 94 08:47:05 MDT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097B6A6.465DFC60.19068@swdev.si.com>, "Brian Tillman" writes: >Digital has just issued a security patch for VMS V5.4-3 through V6.0. The cover >letter with that patch says that aopplications using the DECwindows transport >routines, the MAIL utility routines, and the PTD$ routines are affected. >Certainly MX uses the MAIL utility routines, correct? Should MX be re-installed >after the security patch is applied? MX doesn't change any DEC-supplied executables, MX only adds new executables, so, no, you don't need to reinstall MX after installing the security patch. However, the security patch *does* replace SYS$SHARE:MAILSHR.EXE; this is the image modified by the "mail patch" (I'm referring to the patch which fixes mail so you can use user@host instead of requiring you to use MX%"user@host"). So if you've installed the MAILSHR patch, you'll probably lose the patch's functionality (and the VMS-version-specific offsets will probably be different, so it won't be possible to reinstall it until someone has the time to determine the new offsets introduced by Digital's "secure" version of MAILSHR.EXE). -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Mon, 14 Mar 1994 11:29:42 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 14 Mar 1994 11:25:48 CST From: "James F. Burnett" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B6B5.593FD380.16395@PANAM1.PANAM.EDU> Subject: RE: Queue problems >To: MX-List@WKUVX1.WKU.EDU >Subject: Queue problems > >I am running MX V.3.3 and have just started seeing some message files in the >queue directory rather than the sub-directories. They are therefore not getting >purged. Other messages are still being placed correctly in the sub-directories >and being purged. > >Directory MX_ROOT:[QUEUE] > >0.DIR;1 1 10-FEB-1994 15:33:50.16 >1.DIR;1 1 10-FEB-1994 15:33:52.09 >12.HDR_INFO;1 1 11-MAR-1994 14:04:19.74 >12.MSG_TEXT;1 11 11-MAR-1994 14:04:19.89 >12.SRC_INFO;1 2 11-MAR-1994 14:04:19.52 >2.DIR;1 1 10-FEB-1994 15:33:54.02 >21.HDR_INFO;1 1 11-MAR-1994 14:43:46.18 >21.MSG_TEXT;1 3 11-MAR-1994 14:43:46.34 >21.SRC_INFO;1 1 11-MAR-1994 14:43:46.04 >3.DIR;1 1 10-FEB-1994 15:33:55.97 >4.DIR;1 1 10-FEB-1994 15:33:57.98 >46.HDR_INFO;1 1 11-MAR-1994 16:53:37.20 >46.MSG_TEXT;1 2 11-MAR-1994 16:53:37.42 >46.SRC_INFO;1 1 11-MAR-1994 16:53:36.99 >5.DIR;1 1 10-FEB-1994 15:33:59.88 >6.DIR;1 1 10-FEB-1994 15:34:01.91 >7.DIR;1 1 10-FEB-1994 15:34:03.80 >8.DIR;1 1 10-FEB-1994 15:34:05.72 >9.DIR;1 1 10-FEB-1994 15:34:07.74 >SYSTEM_QUEUE.FDL;1 2 15-OCT-1990 21:59:50.15 >SYSTEM_QUEUE.FLQ_CTL;2 > 45 11-MAR-1994 12:59:56.71 ************************************************************************ Hmmmm. I've never seen this before nor do I have an explanation. You might want to check the protections and ownerships of 1.dir, 2.dir, and 6.dir. Chances are it had something to do with the corrupt queue file. [...] stuff deleted > >I have recently upgraded from MX V3.2 to V3.3. I had some problems with this. >Initially MX would accept messages but never process them. I finally found this >seemed to be due to a corrupt queue file from V3.2. The old version of MX was >still working but the files associated with old messages were not getting purged >and MCP QUEUE SHO/ALL never showed anything in the queue. > >Once I created a new queue file I was able to start V3.3. This was a week ago. >The file became corrupt again (under V3.3) earlier today. I recreated it (using >the FDL from the distribution). MX seemed to run OK for a few hours before >these problems. The queue file is OK at present (no errors from >ANALY/RMS/CHECK). **************************************************************************** How many nodes are you running the MX processes on ? Is it a clustered environment where a lot of file sharing is occuring ? What version of VMS are you running ? I was having problems with corrupt queue files after upgrading to MX 3.3, until I moved all of the processes to one node in our 3 node cluster(running VMS 6.0). It's been over a week now since I've seen the corruption(knock on wood). Of course, if you do that, you may need to reconfigure some other things also. > >Can anyone suggest what I should check? -- james ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + James F. Burnett INTERNET: BURNETT@PANAM.EDU + + Software Systems Specialist II BITNET : BURNETT@PANAM.BITNET + + University of Texas-Pan American THENET : PANAM::BURNETT + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ================================================================================ Archive-Date: Mon, 14 Mar 1994 15:17:10 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: kismet@trantor.cc.umb.edu (Ted Corning) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Queue file size Date: 14 Mar 1994 21:03:32 GMT Message-ID: <2m2jf4$968@anchor.cc.umb.edu> To: MX-List@WKUVX1.WKU.EDU Hi, My MX queue file seems to be growing larger and larger. In the past few weeks, it has grown from 11,000 blocks to over 29,000 blocks. Should I be doing something to curb this (i.e., MCP QUE RECLAIM, etc)? Does the size of the queue file indicate a problem? The MX processes are taking up a LOT of my CPU today. Doing a MCP QUEUE SHOW, I just killed it after waiting about 4 hours for it to finish. Also, I posted a message a couple of weeks ago about the SMTP Server process dying. We had a problem with our newsfeed, but I recall Hunter asking if I had the message that killed it. I do have the Server log file of it. Thanks for any pointers. Ted -- Ted Corning UMass/Boston Computing Services kismet@trantor.cc.umb. ================================================================================ Archive-Date: Mon, 14 Mar 1994 15:42:52 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: rbp@brown.edu (bob pasker) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Re: MX and the VMS security update Date: Mon, 14 Mar 1994 16:21:43 -0500 Message-ID: To: MX-List@WKUVX1.WKU.EDU is the security update for callable mail or the foreign protocol interface users? -- -- bob pasker -- brown u., dept. of history -- rbp@brown.edu -- ================================================================================ Archive-Date: Mon, 14 Mar 1994 16:06:33 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: kiddd@wr-hits.af.mil (David Kidd) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: DNS & DNR using MX Date: 14 Mar 1994 21:35:26 GMT Message-ID: <2m2lau$cbh@wrdis02.robins.af.mil> To: MX-List@WKUVX1.WKU.EDU Can someone tell me how MX uses CMU/IP DNR to resolve SMTP mail addresses? Thanks, David Kidd kiddd@wr-hits.af.mil ================================================================================ Archive-Date: Mon, 14 Mar 1994 16:29:33 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: MX and the VMS security update Message-ID: <1994Mar14.150056.1292@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 14 Mar 94 15:00:56 MST Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article , rbp@brown.edu (bob pasker) writes: >is the security update for callable mail or the foreign protocol interface >users? "The security update" is a large patch, available from Digital, which they started shipping this month (March). It applies to all "current" versions of VMS (that Digital supports, that is), from VMS V5.4-3 through V6.0, and replaces approximately 48 DEC-supplied images. The release notes for the patch, available via DSNlink in the OPENVMS database as article "[OpenVMS] Release Notes for OpenVMS VAX Security MUP 3", is 1400 lines long. Note, the patch is *not* available through DSNlink -- we have CONDIST and received the patch late last week on CD-ROM. With regards to mail, the patch replaces the following images: MAIL.EXE MAILSHR.EXE MAILSHRP.EXE and if DECnet/OSI is installed: MAIL_SERVER.EXE is also replaced. There are several Mail bug fixes which are corrected by the "security" patch; I don't know Digital's reasoning for packaging things in this fashion -- if there was an underlying security bug and fixing the security hole would have re-exposed the bug(s) which were previously fixed by ECOs, or if Digital is including a bunch of ECOs to try to hide where the security holes really were.... ... And I *still* haven't seen a CERT announcement; in fact, I don't recall having seen anything on comp.os.vms regarding this patch, which sortof surprises me, too. As callable mail is inside of MAILSHR.EXE and MAILSHRP.EXE, and the foreign mail interface (also called the alternate mail protocol interface) -- the thing used with MX%, for example -- the security patch could change the behavior of either callable mail or foreign mail. However, as several Digital-supplied products (such as DSNlink, PSI, and others) use foreign mail, I doubt its (undocumented) interface would change much.... ... Hope I answered your question. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Mon, 14 Mar 1994 16:31:49 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: DNS & DNR using MX Message-ID: <1994Mar14.150603.1293@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 14 Mar 94 15:06:02 MST Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <2m2lau$cbh@wrdis02.robins.af.mil>, kiddd@wr-hits.af.mil (David Kidd) writes: >Can someone tell me how MX uses CMU/IP DNR to resolve SMTP mail addresses? Basically, MX will look for the highest priority MX record and send mail to that; if this isn't possible, it will look for an A record and send mail to that. If that isn't possible, MX will bounce the message to the sender. The number of times MX tries to do domain-name resolution is controlled by SET SMTP/DNS_RETRIES. Note this is different from SET SMTP/MAXIMUM_RETRIES. What do you want to know? -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Mon, 14 Mar 1994 19:31:11 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: kiddd@margie.robins.af.mil (David Kidd) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Forwarding VMS mail into MX Date: 15 Mar 1994 00:53:02 GMT Message-ID: <2m30te$ovt@wrdis02.robins.af.mil> To: MX-List@WKUVX1.WKU.EDU Does anyone know the command to forward VMS mail into MX. I am try to forward my VMS mail into MX using: mail> set forward ??mx%????? How can this be done? Thanks, David Kiddd kiddd@margie.robins.af.mil. (137.244.225.221) ================================================================================ Archive-Date: Mon, 14 Mar 1994 20:06:28 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 14 Mar 1994 18:02:28 PST From: Virtual Bill Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B6EC.C339EF00.4512@gtewd> Subject: RE: Forwarding VMS mail into MX Dave, inside VMS mail issue the following command: MAIL>SET FORWARD "MX%""name@internet_address""" ================================================================================ Archive-Date: Mon, 14 Mar 1994 20:25:45 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 14 Mar 1994 18:22:59 PST From: Mike Johnson (415) 594-3530 Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: mcjohnson@wizard.farinon.harris.com Message-ID: <0097B6EF.A0F10CA0.8616@wizard.farinon.harris.com> Subject: RE: Forwarding VMS mail into MX >Does anyone know the command to forward VMS mail into MX. I am try >to forward my VMS mail into MX using: >mail> set forward ??mx%????? >How can this be done? David, If you have not already gotten the information, the basic form of the command is: SET FORWARD MX%"""
""" The triple set of quotes will be parsed out to one when the command is excepted by the VMS Mail Utility. Good luck. Mike ------------------------------------------------------------------------------- Michael Johnson Harris Corp./Farinon Div. 1691 Bayport Ave., San Carlos, CA 94070-5307 (Voice) 415 594-3530 (FAX) 415 594-3777 (Internet) mcjohnson@wizard.farinon.harris.com ------------------------------------------------------------------------------ ================================================================================ Archive-Date: Mon, 14 Mar 1994 20:28:28 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 14 Mar 1994 20:22:15 CST From: hunterl@uwwvax.uww.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B700.4A756680.24346@uwwvax.uww.edu> Subject: RE: Forwarding VMS mail into MX => Does anyone know the command to forward VMS mail into MX. I am try => to forward my VMS mail into MX using: Try mx%""" """ Lyle Hunter Computer Center University Wisconsin-Whitewater hunterl@uwwvax.uww.edu ================================================================================ Archive-Date: Mon, 14 Mar 1994 20:34:44 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 14 Mar 1994 20:29:52 -0600 (CST) From: "Prof. David Miller" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <940314202952.2dc28@vax1.bemidji.msus.edu> Subject: RE: Forwarding VMS mail into MX David Kiddd kiddd@margie.robins.af.mil. (137.244.225.221) writes > Does anyone know the command to forward VMS mail into MX. I am try > to forward my VMS mail into MX using: > > mail> set forward ??mx%????? MAIL> SET FORWARD "MX%""name@host""" (its as easy as 1, 2, 3 - get it :) /-------------------\ Dave. || /\ * || || / \ /\ || DMILLER@VAX1.Bemidji.MSUS.EDU || / \ / \ || or || / \ \ || DMILLER%BSU.DECNET@MSUS1.BITNET || /________\____\ || || || || || Bemidji (Minn.) State University \------|| -------/ ================================================================================ Archive-Date: Mon, 14 Mar 1994 20:39:36 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 15 Mar 1994 12:34:23 +1000 From: Powell HEUER Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: powell@syd.dwt.csiro.au Message-ID: <0097B788.18803640.271@syd.dwt.CSIRO.AU> Subject: RE: Queue problems >>I am running MX V.3.3 and have just started seeing some message files in the >>queue directory rather than the sub-directories. They are therefore not >>getting purged. Other messages are still being placed correctly in the >>sub-directories and being purged. >... > > Hmmmm. I've never seen this before nor do I have an explanation. > You might want to check the protections and ownerships of > 1.dir, 2.dir, and 6.dir. Chances are it had something to do with > the corrupt queue file. All files and directories are owned by [SYSTEM] and the protection on all the directories is (RWE,RWE,RE,) >[...] stuff deleted > How many nodes are you running the MX processes on ? Is it a clustered > environment where a lot of file sharing is occuring ? What version > of VMS are you running ? I was having problems with corrupt queue files > after upgrading to MX 3.3, until I moved all of the processes to one > node in our 3 node cluster(running VMS 6.0). It's > been over a week now since I've seen the corruption(knock on wood). > Of course, if you do that, you may need to reconfigure some other > things also. We have a 9 node cluster - VAX4000-300 boot node, uVAX3400, and a mix of workstations - VS3500, VS3100s. All boot from the 4000, some have local page/swap disks and a few are diskless. The 4000 and 3400 each run a copy of ROUTER, LOCAL, and SMTP, and a single SMTP Server on the 4000. This was how we ran MX V3.2. The only difference was that we used SMTP from UCX to receive incoming mail. Outgoing SMTP was sent by MX. This was done because V3.2 couldn't handle the binary attachments generated by Pathworks Mail. Since going to MX V3.3 I've been able to shutdown UCX SMTP and use MX entirely. It does look like the problems have been at least partially due to some problems with the disk where MX is installed - a wide variety of errors shown by ANALYS/DISK that then seem to fix themselves. These have gone away and I haven't seen any problems with MX for the past day. Thanks for the comments and suggestions. --------------------------------------------------------------------- Powell Heuer E-Mail: P.Heuer@syd.dwt.csiro.au CSIRO Division of Wool Technology Phone : +61 2 809 9444 PO Box 7 Fax : +61 2 809 9476 Ryde NSW 2112 AUSTRALIA ================================================================================ Archive-Date: Mon, 14 Mar 1994 20:45:10 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 15 Mar 1994 12:41:20 +1000 From: Powell HEUER Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: powell@syd.dwt.csiro.au Message-ID: <0097B789.10DC88C0.275@syd.dwt.CSIRO.AU> Subject: RE: Forwarding VMS mail into MX David Kiddd wrote: >Does anyone know the command to forward VMS mail into MX. I am try >to forward my VMS mail into MX using: > >mail> set forward ??mx%????? > >How can this be done? I'm sure lots of other will respond:) but here's mine. The only hard part is to get the quotes right. 1. Take the address you would use eg MX%"person@node.somewhere" 2. Double any quotes MX%""person@node.somewhere"" 3. Put quotes around the result "MX%""person@node.somewhere""" 4. Use this for the SET FORWARD command MAIL> SET FORWARD "MX%""person@node.somewhere""" 5. Test it to check. Regards --------------------------------------------------------------------- Powell Heuer E-Mail: P.Heuer@syd.dwt.csiro.au CSIRO Division of Wool Technology Phone : +61 2 809 9444 PO Box 7 Fax : +61 2 809 9476 Ryde NSW 2112 AUSTRALIA ================================================================================ Archive-Date: Tue, 15 Mar 1994 03:34:34 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 15 Mar 1994 10:30:14 +0100 From: "Rok Vidmar, RCU Lj." Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B776.C0A84A54.29377@uni-lj.si> Subject: RE: Forwarding VMS mail into MX > Does anyone know the command to forward VMS mail into MX. I am try > to forward my VMS mail into MX using: > > mail> set forward ??mx%????? > > How can this be done? mail> set forward "mx%""kiddd@margie.robins.af.mil""" Regards, Rok Rok Vidmar inet: rok.vidmar@uni-lj.si UCC, University of Ljubljana x.400: S=vidmar;G=rok;O=uni-lj;P=ac;A=mail;C=si Kardeljeva pl. 17 phone: +386 61 1686439 <-- Changed! 61000 Ljubljana fax: +386 61 1686358 <-- Changed! Slovenia ================================================================================ Archive-Date: Tue, 15 Mar 1994 10:49:44 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 15 Mar 1994 10:45:45 CST From: hunterl@uwwvax.uww.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wkuvx1.wku.edu Message-ID: <0097B778.EB42EF60.27629@uwwvax.uww.edu> Subject: mx_startup_info.dat I modified mx_startup_info.dat as described in the tuning guide to have multiple instances of router, etc. A new file appeared, mx_startup_info.node. Am I supposed to make the same changes to it? I can find no references to this file in the documentation. Lyle Hunter Computer Center University Wisconsin-Whitewater hunterl@uwwvax.uww.edu ================================================================================ Archive-Date: Tue, 15 Mar 1994 14:21:19 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: mx_startup_info.dat Message-ID: <1994Mar15.125910.1300@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 15 Mar 94 12:59:10 MST Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097B778.EB42EF60.27629@uwwvax.uww.edu>, hunterl@uwwvax.uww.edu writes: >I modified mx_startup_info.dat as described in the tuning guide to >have multiple instances of router, etc. A new file appeared, >mx_startup_info.node. Am I supposed to make the same changes to it? >I can find no references to this file in the documentation. Where did it appear? I've been running with this configuration: MX_ROOT:[000000]MX_STARTUP_INFO.DAT;59 001NETLIB:* 002ROUTER:BUCKIE=2 003LOCAL:*=1 004SITE:BUCKIE=1 004SMTP:BUCKIE=8 004SMTP_SERVER:BUCKIE 005MLF:UH01 for almost 6 months, and don't have a file that looks like what you're showing above. I'm running VMS V5.5-2 with MX V3.3. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Wed, 16 Mar 1994 12:22:17 CST Sender: List-Mgr@WKUVX1.WKU.EDU MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Mar 1994 13:18:12 -0500 To: MX-List@RPIECSVX.BITNET From: sysmgr@psuhmed.rcf.hmc.psu.edu Reply-To: MX-List@WKUVX1.WKU.EDU Subject: IUPOP3 problem I'm posting this problem to this list since I know there are IUPOP3 users listening. We are using IUPOP3, UCX V2.0, MX and VMS 5.4 on a VAX 6310. Our problem lies in the inability to transfer large (appx.>20 kbytes) messages. Most clients use Macintoshes with Eudora. Most of the time, but not always, during the transfer of these files the connection between the server and the client breaks and the transfer fails. The most common message is: "network write error: broken pipe". Any suggestions or insights will be appreciated. Thanks in advance. -Dave Custer ================================================================================ Archive-Date: Wed, 16 Mar 1994 15:26:30 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 16 Mar 1994 15:26:01 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B869.3CDC573F.5@ALPHA.WKU.EDU> Subject: Re: Possible SMTP protocol bug dwing@uh01.Colorado.EDU (Dan Wing) writes: > >In article <1994Mar1.133339.25785@infopiz>, mark@infocomm.com (Mark Pizzolato 510-837-5600) writes: >> Transcript: >> Rcvd: 220 pjl53wo.i-p.attmail.com SMTP Service ready >> Sent: HELO vs4000.infocomm.com >> Rcvd: 208 WARNING: Invalid calling IP address for vs4000.infocomm.com [192.101.151.1] >> ======================================================================== >> >>Appendix E of RFC821 seems to indicate that MX should take this response >>as a "successful completion". >> >>Am I reading this correctly? > >FWIW, I think you're right. > So do I. MX V4.0 will handle "generic" success and failure codes (2xx and 5xx). Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Wed, 16 Mar 1994 15:29:38 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 16 Mar 1994 15:29:02 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B869.A8B0B11D.8@ALPHA.WKU.EDU> Subject: Re: Any Workaround for Looping UUCP Agent? dwing@uh01.Colorado.EDU (Dan Wing) writes: > >In article <0097B22B.69A57CE0.16472@tanuki.twics.com>, Tim Burress writes: >>We've begun running into this problem where the UUCP agents get stuck in an >>infinite and very resource-hungry loop, and the only way we can unstick things >>is to shut down MX, stop the UUCP interface process with STOP, delete the first >>UUCP job on the MCP queue, and then restart. >> >>This is starting to happen several times a day, so I'm wondering if anyone has >>come up with a workaround. I remember hearing that the culprit was some kind >>of unexpected data in the headers, but is there a more detailed explanation? >>I'd gladly dig into UUCP to find/fix it, but surely someone has had a go at it >>already. > >You might want to ask the UUCP folks, or is this an MX problem? > No, this is a UUCP problem (UUCP_MAILSHR). I actually found and fixed this once, then found that the UUCP guys had already fixed it. They told me that a new version of DECUS UUCP was imminent, so I threw out my modifications. Of course, that was more than a year ago.... The bug has to do with UUCP_MAILSHR losing track of where it is in a file when records with a certain character at a certain offset are encountered. This is usually caused when someone tries to mail a binary file, but it can happen with plain text files too. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Wed, 16 Mar 1994 15:34:06 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 16 Mar 1994 15:32:50 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B86A.30B3A868.2@ALPHA.WKU.EDU> Subject: RE: Other file format changes? "Ray Harwood -- Data Basix: (602)721-1988" writes: > >Can anyone give me a "heads-up" on other file format changes (as far ahead as >MX 4.0)? I've been scoping out writing an MLF tool to give a LOCAL list owner >an interactive method of adding, deleting, and modifying subscriber information >to a list. I don't want to invest time in figuring out the intricacies of the >current file formats if they'll be changed in the next release. > The format of mailing list files has not changed in MX V4.0. A simple command procedure called MLF_MAINT, written by Dan Wing, will be included in the CONTRIB directory. MLF_MAINT is simple, but very effective---it creates the mail message that has to be sent, so there's no reliance on the format of the mailing list file. You can find MLF_MAINT.ZIP on ftp.spc.edu in [.MX.CONTRIB] now.... Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Wed, 16 Mar 1994 15:35:38 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 16 Mar 1994 15:35:10 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B86A.842BC886.12@ALPHA.WKU.EDU> Subject: Re: MX record problem olin@cheme.cornell.edu (Steve Thompson) writes: > >I'm not sure if this is obvious or not, but perhaps I should mention >it anyway. It appeared during my dealings with the problem I mention >above that if the nameserver list that Multinet uses is changed, >the MX SMTP process appears to require stopping and restarting in >order to pick up the changes; it didn't seem to notice automatically. >Did I just dream this? > No, you are correct. If you change the MULTINET_NAMESERVERS logical, MX SMTP must be stopped and restarted. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Wed, 16 Mar 1994 15:37:35 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 16 Mar 1994 15:37:04 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B86A.C7FA6F8B.16@ALPHA.WKU.EDU> Subject: RE: automatic digesting software "MIKE MCINTYRE, MSM@MCINC.COM" writes: > >I am looking for some software to automatically create digests. I am >subscribed to MX-List-Digest and I really like that format. > >Is this software available and what language(s) is it implemented in? > This may have been answered already; I don't remember. In any case, the software I use to do MX-List-Digest can be found in the CONTRIB directory as MX-DIGEST.ZIP. You can also get the latest version via anonymous ftp from ftp.spc.edu in [.MX.CONTRIB]MX-DIGEST.ZIP. >What else is out there for digest software? > Beats me. I found this stuff, written in C, and modified/enhanced/finished it to work with MX. As far as I know, this is the only software that works with MX. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Wed, 16 Mar 1994 15:38:44 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 16 Mar 1994 15:38:01 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B86A.E9B1F400.20@ALPHA.WKU.EDU> Subject: RE: New version SAEED KHADEMI writes: > >Hello All, > Could someone tell me where can I find MX V4? Is this the latest version? > Many thanks in advance. MX V4.0 is still in beta-testing. I hope to release it real soon.... An announcement will be posted here, there, and everywhere when it's ready for general release. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Wed, 16 Mar 1994 17:52:30 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 16 Mar 1994 15:44:19 PST From: robert@dis.ucsf.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-LIST@WKUVX1.WKU.EDU Message-ID: <0097B86B.CB3EA1C0.7094@dis.ucsf.edu> Subject: limit on size of incoming files? I've been having trouble retrieving a file from a gopher server through mail. The file gets truncated on the way in. Now that I know how big the file is I'll just download it. BUT, why am I having this problem? The owner of the server confirms that the file itself isn't truncated and that he's able to retrieve the whole thing through the mail. Does anyone know if MX or Multinet could be imposing a size limit on incoming files? FYI, the file was truncated at 49,838 bytes. Robert Weiner Manager, Development Information Systems robert@dis.ucsf.edu University of California, San Francisco ================================================================================ Archive-Date: Wed, 16 Mar 1994 23:36:34 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Thu, 17 Mar 1994 14:33:17 JST From: Tim Burress Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097B92B.091655A0.4864@tanuki.twics.com> Subject: Re: Any Workaround for Looping UUCP Agent? >No, this is a UUCP problem (UUCP_MAILSHR). I actually found and fixed >this once, then found that the UUCP guys had already fixed it. They >told me that a new version of DECUS UUCP was imminent, so I threw out >my modifications. > >Of course, that was more than a year ago.... > >The bug has to do with UUCP_MAILSHR losing track of where it is in a >file when records with a certain character at a certain offset are >encountered. This is usually caused when someone tries to mail a >binary file, but it can happen with plain text files too. Thanks! Has anyone else had/fixed this one? I suspect that we are seeing it more often because we're in a mixed Japanese/English environment and the binary codes for Japanese characters often appear in headers. ================================================================================ Archive-Date: Thu, 17 Mar 1994 02:44:33 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: wayne@tachyon.com (Wayne Sewell) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: RE: New version Message-ID: <1994Mar16.224524.1257@tachyon.com> Date: 16 Mar 94 22:45:24 CST To: MX-List@WKUVX1.WKU.EDU In article <0097B86A.E9B1F400.20@ALPHA.WKU.EDU>, "Hunter Goatley, WKU" writes: > SAEED KHADEMI writes: >> >>Hello All, >> Could someone tell me where can I find MX V4? Is this the latest version? >> Many thanks in advance. > > MX V4.0 is still in beta-testing. I hope to release it real soon.... > An announcement will be posted here, there, and everywhere when it's > ready for general release. > When it is released, it might be a good idea to set up temporary mirror file servers like you have done in the past. Four zillion people downloading a hundred-and-thirty-something-part file (that was the size of 3.3; 4.0 might be even bigger) simultaneously puts quite a load on ole WKUVX1. Of course, you're directly on the internet now, so the mirrors may not be necessary. Wayne -- ============================================================================== Wayne Sewell |INET: wayne@tachyon.com Tachyon Software Consulting |UUCP: uupsi!uupsi6!tachyon!wayne P. O. Box 550937, Dallas TX 75355-0937 |Voice: (214)-553-9760, Fax: -553-0077 ============================================================================= Moe, Curly, Larry (in Hitler parody):"Hail, hail, Hailstone! Wahoo!" ================================================================================ Archive-Date: Thu, 17 Mar 1994 10:41:14 CST Sender: List-Mgr@WKUVX1.WKU.EDU Subject: Re: limit on size of incoming files? Message-ID: <1994Mar17.092243.1315@buckie.hsc.colorado.edu> From: dwing@uh01.Colorado.EDU (Dan Wing) Date: 17 Mar 94 09:22:42 MST Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097B86B.CB3EA1C0.7094@dis.ucsf.edu>, robert@dis.ucsf.edu writes: >I've been having trouble retrieving a file from a gopher server >through mail. The file gets truncated on the way in. Now that >I know how big the file is I'll just download it. BUT, why am I >having this problem? The owner of the server confirms that the >file itself isn't truncated and that he's able to retrieve the >whole thing through the mail. Does anyone know if MX or Multinet >could be imposing a size limit on incoming files? FYI, the file was >truncated at 49,838 bytes. 97 blocks? I've mailed much, much bigger files through MX than that with no problem at all. I'm running MX V3.4-beta and MultiNet V3.2C; I've mailed large files using MX V3.3 as well, again, with no problems. Enable debugging for the SMTP Server and Local agents, and send the file to your system, and you might give a clue to the problem. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing@eisner.decus.org ================================================================================ Archive-Date: Thu, 17 Mar 1994 20:40:53 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: BMSLIB@mitvma.mit.edu (Dr. W. Curtiss Priest) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Q: contrast/compare MX for VMS and LISTSERV on BITNET Date: Thu, 17 Mar 94 21:19:02 EST Message-ID: <16F7C12BC6S85.BMSLIB@mitvma.mit.edu> To: MX-List@WKUVX1.WKU.EDU As my email address gives away (VM A) -- I mainly live in the VM/CMS world A colleague at a local university wants to set up an internet listserve that will handle any internet email. Is MX able to do that? One message I got in comp.os.vms suggested MX was restricted to local traffic. Any short summary would be appreciated. _______________________________________________________________________________ | Dr. W. Curtiss Priest | | Center for Information, Technology, & Society | | *********************** | | 466 Pleasant Street * Improving Humanity *| | Melrose, MA 02173-4522 * Through Technology * | | Voice: 617-662-4044 *********************** | | Fax: 617-662-6882 | _____________________________________________________________________________| ================================================================================ Archive-Date: Thu, 17 Mar 1994 22:06:35 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Thu, 17 Mar 1994 21:02:33 -0700 From: "Ray Harwood -- Data Basix: (602)721-1988" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: rharwood@Data.Basix.COM Message-ID: <0097B961.6A7F4140.20423@Data.Basix.COM> Subject: RE: Q: contrast/compare MX for VMS and LISTSERV on BITNET BMSLIB@mitvma.mit.edu (Dr. W. Curtiss Priest) wrote: > As my email address gives away (VM A) -- I mainly live in the VM/CMS world > A colleague at a local university wants to set up an internet listserve > that will handle any internet email. > Is MX able to do that? One message I got in comp.os.vms suggested MX > was restricted to local traffic. > Any short summary would be appreciated. ^^^^^^^^^^^^^ Yes. ;)} But depends what you mean by "handle any internet email." Handling EMail is distinct from running a listserv, though they are necessarily related. MX can do anything you need along those lines. Ray ----- Ray Harwood | Data Basix | DEC Pro Networking Editor Voice: (602)721-1988 | PO Box 18324 | "Internet Resource Guide" FAX: (602)721-7240 | Tucson, AZ 85731 | Adjunct Faculty, East Campus, RHarwood@Data.Basix.COM | Info@Data.Basix.COM | Pima Community College ================================================================================ Archive-Date: Fri, 18 Mar 1994 02:50:39 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Fri, 18 Mar 1994 10:01:03 -0100 To: From: Robertini@sns.it (Marco Robertini) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Re: IUPOP3 problem > I'm posting this problem to this list since I know there are IUPOP3 users >listening. We are using IUPOP3, UCX V2.0, MX and VMS 5.4 on a VAX 6310. Our >problem lies in the inability to transfer large (appx.>20 kbytes) messages. > >Most clients use Macintoshes with Eudora. Most of the time, but not always, >during the transfer of these files the connection between the server and >the client breaks and the transfer fails. The most common message is: >"network >write error: broken pipe". Any suggestions or insights will be appreciated. >Thanks in advance. >-Dave Custer > I don't remember that problem in my site, but I made the following changes in IUPOP3 process (we have iupop3 1.8): -----START_IUPOP3.COM----- . . . /ast_limit=200 - /io_buffered=200 - /io_direct=200 - -----IUPOP3.COM----- . . . $ set process/priority=5 . . Ciao ++++++++++++++++++++++++++++++++++++++++++++++++++++ + Marco Robertini +39 50 509268 + + Fax +39 50 563513 + + Lan manager - Scuola Normale Superiore di Pisa + ++++++++++++++++++++++++++++++++++++++++++++++++++++ ================================================================================ Archive-Date: Fri, 18 Mar 1994 12:46:20 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: Q: contrast/compare MX for VMS and LISTSERV on BITNET Date: 18 Mar 1994 18:37:09 GMT Message-ID: <2mcscl$4dp@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <16F7C12BC6S85.BMSLIB@mitvma.mit.edu>, BMSLIB@mitvma.mit.edu (Dr. W. Curtiss Priest) writes: =As my email address gives away (VM A) -- I mainly live in the VM/CMS world =A colleague at a local university wants to set up an internet listserve =that will handle any internet email. =Is MX able to do that? One message I got in comp.os.vms suggested MX =was restricted to local traffic. I'm sorry if my message gave that impression. MX is NOT restricted to local traffic. If someone can send mail with a valid return address to the LISTSERV on a system running MX, LISTSERV can handle it. However, the BITnet listserves are set up as a set of cooperating peers, in an effort to minimize the bandwidth they use. MX doesn't do that. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Sat, 19 Mar 1994 03:32:44 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Sat, 19 Mar 1994 03:29:35 CST From: Kenny Kon Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wkuvx1.wku.edu Message-ID: <0097BA60.A6AB9B00.918@bible.acu.edu> Subject: Return Path Sorry if this question has been asked before. The return path for all responses to the MXServ requests corresponds to the first name on the System user list. Is this normal? Is there a way to change it to Postmaster instead? Thanks. Kenny ----- Kenny Kon, Assistant Systems Manager College of Biblical Studies, Abilene Christian University E-Mail: kenny.kon@BIBLE.ACU.EDU, Postmaster@BIBLE.ACU.EDU ================================================================================ Archive-Date: Sat, 19 Mar 1994 15:43:54 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: Return Path Date: 19 Mar 1994 21:31:50 GMT Message-ID: <2mfr06$79a@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097BA60.A6AB9B00.918@bible.acu.edu>, Kenny Kon writes: =Sorry if this question has been asked before. The return path for all =responses to the MXServ requests corresponds to the first name on the =System user list. Is this normal? Yes. =Is there a way to change it to Postmaster instead? Thanks. Well, you could make Postmaster the first name on the System user list. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Mon, 21 Mar 1994 03:33:56 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 21 Mar 1994 10:31:22 +0100 From: Jacques.Leyrat@unicaen.fr Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@smtp.unicaen.fr CC: Jacques.Leyrat@unicaen.fr Message-ID: <0097BC2D.E7558200.2025@caen1.unicaen.fr> Subject: MX% @ Patch for VMS Mail Sorry for a question that is not relevant of the "standard" distribution of MX. I installed the Patch that lets the users leave off the MX% for adresses as I found it in the contrib directory of the MX033 kit, under Open-VMS V5.5-2, using UCX V2.0. It functions finely, except that the header, as you will probably see in this message, contains an uncorrect To: The original right part of the address is replaced by the content of the logical MX_SITE_NOT_AUTHORIZED_DOMAIN ( I use also the nickname conversion ), in my case cri.unicaen.fr, as you will see lower in the list of my logical names MX_. Is there any solution to this problem ? Thank you for help me. (LNM$PROCESS_TABLE) "MX_AUTO_SIGNATURE" = "TRUE" "MX_SIGNATURE" = "SYS$LOGIN:SIGNATURE.TXT" (LNM$JOB_81D019F0) (LNM$GROUP_000010) (LNM$SYSTEM_TABLE) "MX_ALIAS_HELPLIB" = "MX_DIR:MX_ALIAS_HELPLIB" "MX_DEVICE" = "$1$DUA0:" "MX_DIR" = "MX_DEVICE:[MX]" "MX_DOC" = "MX_ROOT:[DOC]" "MX_EXAMPLES_DIR" = "MX_ROOT:[EXAMPLES]" "MX_EXE" = "MX_ROOT:[EXE]" "MX_FLQ_DIR" = "SYS$SYSDEVICE:[MX.QUEUE]" "MX_FLQ_NODE_NAME" = "CAEN1" "MX_FLQ_RECLAIM_WAIT" = "0 02:00:00" "MX_FLQ_SHR" = "MX_EXE:MX_FLQ_SHR" "MX_LOCAL_DIR" = "MX_ROOT:[LOCAL]" "MX_MAILSHR" = "MX_EXE:MX_MAILSHR" "MX_MAILSHRP" = "MX_EXE:MX_MAILSHRP" "MX_MCP_HELPLIB" = "MX_DIR:MX_MCP_HELPLIB" "MX_MLF_DIR" = "MX_ROOT:[MLF]" "MX_MLIST_DIR" = "MX_ROOT:[MLF.MAILING_LISTS]" "MX_MSG" = "MX_EXE:MX_MSG" "MX_NODE_NAME" = "caen1.unicaen.fr" "MX_ROOT" = "MX_DEVICE:[MX.]" "MX_ROUTER_DIR" = "MX_ROOT:[ROUTER]" "MX_SHR" = "MX_EXE:MX_SHR" "MX_SITE_ALIASES" = "MX_DIR:ALIASES.TXT" "MX_SITE_AUTHORIZED_DOMAIN" = "unicaen.fr" "MX_SITE_DOM_EXPANSION" = "MX_EXE:DOMAIN_EXPANSION" "MX_SITE_NAME_CONVERSION" = "MX_EXE:NAME_CONVERSION" "MX_SITE_NOT_AUTHORIZED_DOMAIN" = "cri.unicaen.fr" "MX_SMTP_DIR" = "MX_ROOT:[SMTP]" "MX_TIMEZONE" = "+0100" "MX_VMSMAIL_FROM_FORMAT" = "" "MX_VMSMAIL_LOCALHOST" = "@cri.unicaen.fr" *********************************************************************** Jacques LEYRAT ! Tel: (33-)31-45-55-08 Centre de Ressources Informatiques (C.R.I.U.C) ! Universite de Caen ! Fax: (33-)31-44-58-54 14032 Caen Cedex ! e-mail: Jacques.Leyrat@unicaen.fr ! *********************************************************************** ================================================================================ Archive-Date: Mon, 21 Mar 1994 05:48:59 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 21 Mar 1994 05:48:31 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097BC06.64038216.28@ALPHA.WKU.EDU> Subject: RE: MX% @ Patch for VMS Mail Jacques.Leyrat@unicaen.fr writes: > >Sorry for a question that is not relevant of the "standard" distribution of MX. >I installed the Patch that lets the users leave off the MX% for adresses >as I found it in the contrib directory of the MX033 kit, under Open-VMS V5.5-2, >using UCX V2.0. >It functions finely, except that the header, as you will probably see in this >message, contains an uncorrect To: >The original right part of the address is replaced by the content >of the logical MX_SITE_NOT_AUTHORIZED_DOMAIN ( I use also the nickname >conversion ), in my case cri.unicaen.fr, as you will see lower in the list of >my logical names MX_. >Is there any solution to this problem ? >Thank you for help me. > This is apparently a known problem with the patch on some systems. I'm not sure what causes it, but I've seen it happen a time or two. Never consistently enough to try to debug it, though. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Mon, 21 Mar 1994 07:58:06 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 21 Mar 1994 14:55:16 +0100 From: Jacques.Leyrat@unicaen.fr Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097BC52.C4ECC320.2049@caen1.unicaen.fr> Subject: RE: MX% @ Patch for VMS Mail > This is apparently a known problem with the patch on some systems. > I'm not sure what causes it, but I've seen it happen a time or two. > Never consistently enough to try to debug it, though. > In my case it occurs systematically. For example, in the message received by the MX-List, the To: field specifies mx-list@smtp.unicaen.fr (I said uncorrectly in my message that the MX_SITE_NOT_AUTHORIZED logical was set to cri.unicaen.fr . It was in fact smtp.unicaen.fr, because I modified it for a test. I now reset it to cri...) Jacques. -------------------------------- Here is the header of the first message I sent > > Return-Path: > Received: from wkuvx1.wku.edu by caen1.unicaen.fr (MX V3.3 VAX) with SMTP; Mon, > 21 Mar 1994 11:57:00 +0100 > X-ListName: Message Exchange Discussion List > Warnings-To: <> > Errors-To: List-Mgr@WKUVX1.WKU.EDU > Sender: List-Mgr@WKUVX1.WKU.EDU > Date: Mon, 21 Mar 1994 10:31:22 +0100 > From: Jacques.Leyrat@unicaen.fr > Reply-To: MX-List@WKUVX1.WKU.EDU > To: mx-list@smtp.unicaen.fr > CC: Jacques.Leyrat@unicaen.fr > Message-ID: <0097BC2D.E7558200.2025@caen1.unicaen.fr> > Subject: MX% @ Patch for VMS Mail *********************************************************************** Jacques LEYRAT ! Tel: (33-)31-45-55-08 Centre de Ressources Informatiques (C.R.I.U.C) ! Universite de Caen ! Fax: (33-)31-44-58-54 14032 Caen Cedex ! e-mail: Jacques.Leyrat@unicaen.fr ! *********************************************************************** ================================================================================ Archive-Date: Mon, 21 Mar 1994 09:39:06 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: kismet@trantor.cc.umb.edu (Ted Corning) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Queue File Questions Date: 21 Mar 1994 15:15:27 GMT Message-ID: <2mkdmf$qqp@anchor.cc.umb.edu> To: MX-List@WKUVX1.WKU.EDU Hi, I've posted here a few times in the past couple of weeks, but I have been in the middle of switching newsfeeds, and had a problem with my VMSNET.* entries, so I never saw any responses to my posts. I retrieved all the archived MX-LIST messages from 1993 and 1994 so far. They have been very helpful. I have extracted the MX_SHRINK procedure and have it running automatically in the wee hours of the morning. It's a great procedure. Today's question is, how can MCP QUEUE SHOW take so long, when the queue file is only around 550 blocks? Are the MX processes keeping records locked? Does MCP wait for them? Is this normal? I'm running MX 3.3, on a VMS V6.0 cluster of VAXes. The MX processes are running on two nodes of the cluster: 2 Routers, 3 Locals, 3 SMTP, 1 DNSMTP, 1 SMTP_SERVER, and 1 MLF. My newsfeed appears to be working normally, so I'll see any discussions from now on. Sorry for the confusion and all the posts. Ted -- Ted Corning UMass/Boston Computing Services kismet@trantor.cc.umb.edu ================================================================================ Archive-Date: Mon, 21 Mar 1994 14:56:52 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 21 Mar 1994 14:53:29 EST From: kenm@adhe.arknet.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wkuvx1.wku.edu Message-ID: <0097BC52.853210A0.18840@adhe.arknet.edu> Subject: MAIL ALTERNATIVES ?? Arkansas Department of Higher Education I N T E R O F F I C E M E M O R A N D U M Date: 03-21-1994 02:42pm GMT From: KEN MCCOY KENM Dept: Information Services Tel No: 501-324-9300 FAX 501-324-9308 TO: Remote Addressee ( _mx-list@wkuvx1.wku.edu ) Subject: MAIL ALTERNATIVES ?? Hello ALL, I'm not sure if this is the correct place for this question, but ... I'm currently running ALL-IN-1 (3.0) and MX to provide my users with e-mail access to the internet (VAX 4000 mod 200 running Message Router and MX). My users want to move away from ALL-IN-1 to a PC word processing and mail solution :) My PC's are on PathWorks 4.1 MY QUESTION: Is anyone using a PC mail product that they would recommend for this setup. What has to be running on the VAX side and PC side for this product to run. Also, how well would this product integrate with something like Word perfect for Win. or Word for Win. Any comments are appreciated, Thanks Again Ken McCoy ================================================================================ Archive-Date: Tue, 22 Mar 1994 01:08:50 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 22 Mar 1994 08:04:40 EST From: "Mario Meyer, Phys.-Techn. Bundesanstalt" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@wkuvx1.wku.edu CC: mmeyer@chbrb.berlin.ptb.de Message-ID: <0097BCE2.93AB0AC0.5193@chbrb.berlin.ptb.de> Subject: RE: MAIL ALTERNATIVES ?? > I'm currently running ALL-IN-1 (3.0) and MX to provide my > users with e-mail access to the internet (VAX 4000 mod 200 > running Message Router and MX). > My users want to move away from ALL-IN-1 to a PC word > processing and mail solution :) My PC's are on PathWorks 4.1 > MY QUESTION: Is anyone using a PC mail product that they > would recommend for this setup. What has to be running on > the VAX side and PC side for this product to run. Also, how > well would this product integrate with something like > Word perfect for Win. or Word for Win. Hello Ken, we have ALL-IN-1 and A1MAIL (DEC) running in a LAVC. A1MAIL works well and You can access MX via MRGATE. PC users run TEAMLINKS Software from DEC that provides Mail Interfaces built into Windows Applications (WORD !) and gives access to A1MAIL as a message store. Access to existing ALL-IN-1 folders is also provided. That will be convenient for users changing from ALL-IN-1 to A1MAIL. The A1Mail user interface on the VAX is very similar to VMSmail. Regards Mario Meyer ================================================================================ Archive-Date: Tue, 22 Mar 1994 01:46:50 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 22 Mar 94 09:40 JST From: "Najman Kahana. Ext:7313" Reply-To: MX-List@WKUVX1.WKU.EDU Subject: 'FROM:' format To: MX-List@WKUVX1.WKU.EDU Message-ID: <4310147303FF200292@HADASSAH.BITNET> Hi. I am switching from PMDF to MX. In PMDF the FROM header which is sent out is: FROM: IN%"user@aa.aa." " my signature. free text" IN MX this seems to be reversed FROM:" my signature. free text" Do I have any control over this order ? If so, how. Thanks, and a happy Pesach Najman Najman@hadassah.bitnet ================================================================================ Archive-Date: Tue, 22 Mar 1994 06:11:03 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 22 Mar 1994 06:10:50 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097BCD2.AC8E81F3.35@ALPHA.WKU.EDU> Subject: RE: 'FROM:' format "Najman Kahana. Ext:7313" writes: > >Hi. > I am switching from PMDF to MX. Good deal! ;-) > In PMDF the FROM header which is sent out is: > FROM: IN%"user@aa.aa." " my signature. free text" Actually, that's what the From: line in VMS Mail looks like. > IN MX this seems to be reversed > FROM:" my signature. free text" > No.... > Do I have any control over this order ? If so, how. > You're confused somewhere. MX and PMDF both generate lines like: From: "Your personal name" in the RFC822 headers. On *incoming* messages, PMDF creates a VMS Mail From: line that looks like: From: IN%"user@node" "Your personal name" while MX produces: From: MX%"user@node" Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Tue, 22 Mar 1994 10:29:23 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: courtney@birdville.k12.tx.us (Roger Courtney - Systems, Programming & Operations) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Connect rejected! Date: 22 Mar 94 08:37:11 -0600 Message-ID: <1994Mar22.083711.1@ringo> To: MX-List@WKUVX1.WKU.EDU Can anyone tell my what the following error means? Sorry if this is a lame question. I can ping the host just fine. >Entry: 7996, Origin: [Local] > Status: IN-PROGRESS, size: 1113 bytes > Created: 22-MAR-1994 08:18:10.78, expires 21-APR-1994 08:18:10.78 > Last modified 22-MAR-1994 08:19:01.05 > SMTP entry #7997, status: READY, size: 1113 bytes, waiting for retry until 22-MAR-1994 08:24:01.82 > Created: 22-MAR-1994 08:19:00.43, expires 21-APR-1994 08:18:10.78 > Last modified 22-MAR-1994 08:19:01.82 > Recipient #1: , Route=sparc0.sparcc.ohio.gov > Error count=1 > Last error: %SYSTEM-F-REJECT, connect to network object rejected -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Roger Courtney Birdville Independent School District - Supervisor of Systems, 3126 Carson St Programming and operations Fort Worth, TX 76117 Voice: (817) 831-5892 E-Mail: courtney@birdville.k12.tx.us Fax: (817) 831-5896 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ================================================================================ Archive-Date: Tue, 22 Mar 1994 10:41:32 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 22 Mar 1994 10:40:42 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: COURTNEY@BIRDVILLE.K12.TX.US Message-ID: <0097BCF8.5F74C3CA.12@ALPHA.WKU.EDU> Subject: RE: Connect rejected! courtney@birdville.k12.tx.us (Roger Courtney - Systems, Programming & writes: > >Can anyone tell my what the following error means? Sorry if this is a lame >question. I can ping the host just fine. > >>Entry: 7996, Origin: [Local] [...] >> Recipient #1: , Route=sparc0.sparcc.ohio.gov >> Error count=1 >> Last error: %SYSTEM-F-REJECT, connect to network object rejected > It means that system (sparc0...) isn't running an SMTP server, or else it's rejecting connections. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Tue, 22 Mar 1994 11:56:58 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Tue, 22 Mar 1994 18:49:01 EST From: Ralph Kloess Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-LIST%WKUVX1.WKU.EDU@VISION.RS.CH Message-ID: <0097BD3C.97330620.26525@EUROPA.RS.CH> Subject: LOCAL agent loops on PSI-Mail Hello out there in MX-land, I have a problem with the LOCAL-delivery agent. It loops, if I try to do the following Rewrite rule: <{u}@{h}.psi.rest.of.domain> I know the way I wrote it down here is not correct, but the correct version is in the config file. What the LOCAL now does is, it opens the connection and sends the message again and again and again..... until you do a $STOP/ID=mumble on it. It ignores the $MX_EXE:MCP SHUTDOWN LOCAL . Anybody out there experiencing the same problem? If so is there a fix for it? Oh I forgot to mention I run VMS 5.5-2 and MX 3.3 Regards, Ralph Kloess +--------------------------------------+--------------------------------------+ I Ralph Kloess I I I I I +--------------------------------------+--------------------------------------+ ================================================================================ Archive-Date: Tue, 22 Mar 1994 18:24:20 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: Connect rejected! Date: 23 Mar 1994 00:13:52 GMT Message-ID: <2mo1k0$ipb@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <1994Mar22.083711.1@ringo>, courtney@birdville.k12.tx.us (Roger Courtney - Systems, Programming & Operations) writes: =Can anyone tell my what the following error means? Sorry if this is a lame =question. I can ping the host just fine. = =>Entry: 7996, Origin: [Local] => Status: IN-PROGRESS, size: 1113 bytes => Created: 22-MAR-1994 08:18:10.78, expires 21-APR-1994 08:18:10.78 => Last modified 22-MAR-1994 08:19:01.05 => SMTP entry #7997, status: READY, size: 1113 bytes, waiting for retry until 22-MAR-1994 08:24:01.82 => Created: 22-MAR-1994 08:19:00.43, expires 21-APR-1994 08:18:10.78 => Last modified 22-MAR-1994 08:19:01.82 => Recipient #1: , Route=sparc0.sparcc.ohio.gov => Error count=1 => Last error: %SYSTEM-F-REJECT, connect to network object rejected It means that sparc0.sparcc.ohio.gov is not accepting incoming SMTP connections. The fact you can ping the system in no way implies that it's willing to accept incoming mail. The machine in question is not. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Tue, 22 Mar 1994 21:28:20 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: cooper@utsph.sph.uth.tmc.edu Subject: More help needed on reviving dying MX_LOCAL process Date: 23 Mar 1994 02:45:24 GMT Message-ID: <2moag4$hui@oac4.hsc.uth.tmc.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU I posted a message previously about the MX_LOCAL process dying on the ALPHA and some of you replied you had a simular problem related to a "leak in the MAIL_SERVER process after upgrading to AXP 1.5-1h1 or applying a manditory patch. However, I haven't done either of these and am not really sure that this is my problem. The Debug information doesn't provide any information as to what causes the process to die. I have been having this problem since version 3.3 (the first time I installed it on our new alpha) I have installed the beta releases (not the latest) ...I'm currently at 4.0-1 release and continue to have problem. I had such a backlog of mail waiting to be delivered today that I was able to capture the process contents a couple of times just as it died. However, I'm not quite sure sure if the information really provides any clue as to what is causing the problem. I would appreciate if any of you would who have a better knowledge of tuning processes to examine the information I have captured and see if you can detect what might be causing my problem and possible (hopefully) a fix. The system is an AXP7610 running openvms 1.5 (july distribution) What follows below is the "show proc/cont/id=xxx" screen The first screen is after watching the process for about 10-15 minutes. The second screen is the contents right after death. (which is usually after about 30 minutes of running....we have quite a bit of mail coming in and I have to run a batch job every hour to restart this process if it is dead) Each time the process dies it leaves a *.tmp file in the [.local] directory, but I can't find anything common in the files and when I re-start the MX_local process, the job using works fine. The one thing that is consistant when the process dies is th virtual page count hits somewhere around 1736 usually 1736 but in my second example below it died at 1720. 99% of the time I am getting the "access violation" in the accounting file as in the second case as displayed in the 2nd case below. However, the first example has an "exceed quota" error that may provide a clue as to what is happening. I havn't seen this particular message in the accounting file before and before I start making changes to the process quotas, I would like some of your opinions as to what you think needs to be change if anything at all I appears that the cause is related to a lack of resources for the process but I'm not really sure as to what resource needs modifying. Thanks to all of you who have previously or will currently take the time in you busy schedules to try to help. If I receive or find a fix, I will be sure to notify this group Again, thanks for you help Charles Cooper cooper@utsph.sph.uth.tmc.edu C------------------------------------------------------------------------------- c MX_LOCAL PROCESS SHORTLY BEFORE DEATH C------------------------------------------------------------------------------- Process MX Local 14:02:13 State HIB Working set 173 Cur/base priority 9/4 Virtual pages 1717 Current PC 800004A8 CPU time 0 00:00:02.43 Current PSL 0000001B Direct I/O 2972 Current user SP 7FF3F7D0 Buffered I/O 759 PID 22E0068A Page faults 1444 UIC [SYSTEM] Event flags E0000001 B0000000 UTSPH$DKA200:[NONDEC.MX.][ALPHA_EXE]MX_LOCAL.EXE;1 C------------------------------------------------------------------------------- C MX LOCAL PROCESS RIGHT AFTER DEATH C------------------------------------------------------------------------------- Process MX Local 14:08:25 State COM Working set 63 Cur/base priority 4/4 Virtual pages 1736 Current PC 80088CCC CPU time 0 00:00:02.49 Current PSL 00000000 Direct I/O 3010 Current user SP 7FF3E2C0 Buffered I/O 798 PID 22E0068A Page faults 1480 UIC [SYSTEM] Event flags E0000001 B0000000 UTSPH$DKA200:[NONDEC.MX.][ALPHA_EXE]MX_LOCAL.EXE;1 AXP> C------------------------------------------------------------------------------- C CONTENTS OF THE ACCOUNTING RECORD ON THE DEAD PROCESS C------------------------------------------------------------------------------- TACHED Process Termination ---------------------------- Username: COOPER UIC: [SYSTEM] Account: Finish time: 21-MAR-1994 14:08:25.88 Process ID: 22E0068A Start time: 21-MAR-1994 13:28:48.60 Owner ID: Elapsed time: 0 00:39:37.27 Terminal name: Processor time: 0 00:00:02.50 Remote node addr: Priority: 4 Remote node name: Privilege <31-00>: FFFFFFFF Remote ID: Privilege <63-32>: FFFFFFFF Queue entry: Final status code: 1000001C Queue name: Job name: Final status text: %SYSTEM-F-EXQUOTA, process quota exceeded Page faults: 1480 Direct IO: 3010 Page fault reads: 68 Buffered IO: 803 Peak working set: 6160 Volumes mounted: 0 Peak page file: 27760 Images executed: 1 Press RETURN for Next Record > C------------------------------------------------------------------------------- C OPENVMS 6.0 MANUAL STATES THE FOLLOWING FOR TH ABOVE ERROR (ALONG WITH C QUITE A LOG OF OTHER INFORMATION THAT I'M NOT SURE IS C RELATED C------------------------------------------------------------------------------- Explanation: An image could not continue executing or a command could not execute because the process exceeded one of it's resource quotas or limits User Action: Use the DCL command SHOW PROCESS/QUOTAs to determine the current quotas and to determine which quota is exceeded. C------------------------------------------------------------------------------- c result of show/quotas for active process C------------------------------------------------------------------------------- AXP>show proc/quot/id=22e006ca 21-MAR-1994 15:15:53.26 User: COOPER Process ID: 22E006CA Node: UTSPH Process name: "MX Local" Process Quotas: Account name: CPU limit: Infinite Direct I/O limit: 50 Buffered I/O byte count quota: 19040 Buffered I/O limit: 50 Timer queue entry quota: 49 Open file quota: 33 Paging file quota: 5616 Subprocess quota: 32 Default page fault cluster: 128 AST quota: 99 Enqueue quota: 285 Shared file limit: 0 Max detached processes: 0 Max active jobs: 0 AXP> C------------------------------------------------------------------------------- C WHAT IS CURRENTLY IN THE MX_STARTUP.COM FILE FOR STARTING THE C PROCESS C------------------------------------------------------------------------------- $ START = "RUN/AST_LIMIT=100/BUFFER=20000/ENQUE=300/MAXIMUM=1024"+- "/FILE_LIM=40/IO_BUF=50/IO_DIR=50/JOB_TABLE=0/EXTENT=3000"+- "/PAGE_FILE=15000/QUEUE=50/TIME_LIMIT=0/DETACH/PRIV=ALL/PRIO=4" $! C------------------------------------------------------------------------------- c Another copy of process right before failure C------------------------------------------------------------------------------- Process MX Local 16:09:33 State HIB Working set 152 Cur/base priority 9/4 Virtual pages 1615 Current PC 800004A8 CPU time 0 00:00:02.05 Current PSL 0000001B Direct I/O 2735 Current user SP 7FF3F7D0 Buffered I/O 719 PID 22E006CA Page faults 2552 UIC [SYSTEM] Event flags E0000001 B0000000 UTSPH$DKA200:[NONDEC.MX.][ALPHA_EXE]MX_LOCAL.EXE;1 C------------------------------------------------------------------------------- c right after death C------------------------------------------------------------------------------- Process MX Local 16:13:28 State LEF Working set 148 Cur/base priority 6/4 Virtual pages 1720 Current PC 80000784 CPU time 0 00:00:02.49 Current PSL 0000001B Direct I/O 3272 Current user SP 7FF3EDB0 Buffered I/O 868 PID 22E006CA Page faults 2902 UIC [SYSTEM] Event flags A0000000 B0000000 UTSPH$DKA200:[NONDEC.MX.][ALPHA_EXE]MX_LOCAL.EXE;1 AXP> C------------------------------------------------------------------------------- C CONTENTS OF THE ACCOUNTING FILE AFTER SECOND MX_LOCAL DEATH C------------------------------------------------------------------------------- DETACHED Process Termination ---------------------------- Username: COOPER UIC: [SYSTEM] Account: Finish time: 21-MAR-1994 16:13:29.49 Process ID: 22E006CA Start time: 21-MAR-1994 14:10:54.81 Owner ID: Elapsed time: 0 02:02:34.67 Terminal name: Processor time: 0 00:00:02.51 Remote node addr: Priority: 4 Remote node name: Privilege <31-00>: FFFFFFFF Remote ID: Privilege <63-32>: FFFFFFFF Queue entry: Final status code: 0000000C Queue name: Job name: Final status text: %SYSTEM-F-ACCVIO, access violation, reason mask=!XB, virtual Page faults: 2921 Direct IO: 3284 Page fault reads: 70 Buffered IO: 898 Peak working set: 4880 Volumes mounted: 0 Peak page file: 27760 Images executed: 1 Press RETURN for Next Record > ================================================================================ Archive-Date: Wed, 23 Mar 1994 00:39:55 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 23 Mar 94 08:36 JST From: "Najman Kahana. Ext:7313" Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Re: 'FROM:' format To: MX-List@WKUVX1.WKU.EDU Message-ID: <424FBEC4D2FF2002FB@HADASSAH.BITNET> >Subj: RE: 'FROM:' format > > >in the RFC822 headers. On *incoming* messages, PMDF creates a VMS >Mail From: line that looks like: > > From: IN%"user@node" "Your personal name" > >while MX produces: > > From: MX%"user@node" > > Hi Thanks. The error was mine. Happy Pesach, if applicable. Najman ================================================================================ Archive-Date: Wed, 23 Mar 1994 06:10:34 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Wed, 23 Mar 1994 06:10:24 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097BD9B.C773E1B0.21@ALPHA.WKU.EDU> Subject: RE: More help needed on reviving dying MX_LOCAL process cooper@utsph.sph.uth.tmc.edu writes: > >I posted a message previously about the MX_LOCAL process dying on the ALPHA >and some of you replied you had a simular problem related to a "leak in >the MAIL_SERVER process after upgrading to AXP 1.5-1h1 or applying a >manditory patch. However, I haven't done either of these and am not >really sure that this is my problem. The Debug information doesn't [...] >The one thing that is consistant when the process dies is th virtual page >count hits somewhere around 1736 usually 1736 but in my second example >below it died at 1720. > > >99% of the time I am getting the "access violation" in the accounting >file as in the second case as displayed in the 2nd case below. >However, the first example has an "exceed quota" error that >may provide a clue as to what is happening. I would guess that your pagefile quota isn't large enough---maybe. It wouldn't surprise me that exceeding a quota would result in an access violation instead of "exceed quota". >I havn't seen this particular message in the accounting file before >and before I start making changes to the process quotas, I would like some >of your opinions as to what you think needs to be change if anything at all > I'm guessing pagefile quota, but it's just a guess. >AXP>show proc/quot/id=22e006ca > >21-MAR-1994 15:15:53.26 User: COOPER Process ID: 22E006CA > Node: UTSPH Process name: "MX Local" > >Process Quotas: > Account name: > CPU limit: Infinite Direct I/O limit: 50 > Buffered I/O byte count quota: 19040 Buffered I/O limit: 50 > Timer queue entry quota: 49 Open file quota: 33 > Paging file quota: 5616 Subprocess quota: 32 > Default page fault cluster: 128 AST quota: 99 > Enqueue quota: 285 Shared file limit: 0 > Max detached processes: 0 Max active jobs: 0 >AXP> > Mine looks like: >23-MAR-1994 06:08:22.78 User: SYSTEM Process ID: 204001BE > Node: ALPHA Process name: "MX Local" > >Process Quotas: > Account name: SYSTEM > CPU limit: Infinite Direct I/O limit: 100 > Buffered I/O byte count quota: 99040 Buffered I/O limit: 100 > Timer queue entry quota: 49 Open file quota: 93 > Paging file quota: 58912 Subprocess quota: 32 > Default page fault cluster: 128 AST quota: 99 > Enqueue quota: 289 Shared file limit: 0 > Max detached processes: 0 Max active jobs: 0 > The Pgflquo as defined in SYSUAF for SYSTEM is 50000; this appears to be overriding the value specified on the RUN command in MX_START.COM, as my MX_START.COM is the same as yours. You might try it and see if it helps.... Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Wed, 23 Mar 1994 18:10:21 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: dunnett@mala.bc.ca (Malcolm Dunnett) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Invalid calling IP address error Message-ID: <1994Mar23.153632.3795@malasp> Date: 23 Mar 94 15:36:32 -0700 To: MX-List@WKUVX1.WKU.EDU One of our users got the attached error message on some mail sent with MX. From my reading it appears that two things might be wrong here. The first one is the HELO message only has "malasp" rather than the full domain name "malasp.mala.bc.ca", the second is that the remote host sends message 208, which it calls a "warning" and MX chokes on it. I don't know which end is at fault here. Where does the "malasp" come from, have I got a logical set up wrong perhaps? Regarding the "208", is this a legitimate warning which MX should deal with or is the other end sending a bogus code? The user claims this address used to work. Note the user portion of the destination address has been changed to protect the innocent ( or guilty ) party :-) ========================================================================= Return-Path: <> Date: Wed, 23 Mar 1994 14:11:46 PST From: SMTP delivery agent Subject: SMTP delivery error Note: this message was generated automatically. A problem occurred during SMTP delivery of your message. Error occurred sending to the following user(s): (via ATTMAIL.COM): %MX_SMTP-F-UNKNOWN_REPLY_C, reply code !UL not known Transcript: Rcvd: 220 pjl53wo.i-p.attmail.com SMTP Service ready Sent: HELO malasp Rcvd: 208 WARNING: Invalid calling IP address for malasp.WAS.MISSING.DOMAIN.SUFFIX [134.87.26.1] ======================================================================== ================================================================================ Archive-Date: Thu, 24 Mar 1994 06:37:06 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: goatley@eisner.decus.org (Hunter Goatley) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: WKU out of commission until 3/26 (?) Message-ID: <1994Mar24.064003.2707@eisner> Date: 24 Mar 94 06:40:03 -0500 To: MX-List@WKUVX1.WKU.EDU What a week.... The air conditioners in our VAX machine room have been out for two weeks. I've been able to keep things running most of the time using a lot of fans, but the temperature has risen enough this week that I'm going to be forced to power off until the air conditioners are replaced. That's *supposed* to happen Saturday. To complicate matters even more, we've been experiencing lost packets on our T1 link to the Internet. That was supposed to have been fixed last night, but wasn't---hopefully that'll be fixed soon. In the meantime, the FILESERV at WKUVX1.WKU.EDU, as well as mail to WKU, will be out of commission. 8-( Gee, I sure do miss those ice storms now.... ;-) Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.WKU.EDU and goatley@EISNER.DECUS.ORG ================================================================================ Archive-Date: Thu, 24 Mar 1994 08:13:11 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: kismet@trantor.cc.umb.edu (Ted Corning) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Queue File Questions Date: 24 Mar 1994 13:42:33 GMT Message-ID: <2ms5c9$9fq@anchor.cc.umb.edu> To: MX-List@WKUVX1.WKU.EDU Hi, I've posted here a few times in the past couple of weeks, but I have been in the middle of switching newsfeeds, and had a problem with my VMSNET.* entry in the newsfeed file, so I never saw any responses to my posts, and I don't know if they even got out. I've retrieved all the archived MX-LIST messages from 1993 and 1994 so far. They have been very helpful and have answered a lot of my questions. Also, I have extracted the MX_SHRINK procedure and have it running automatically in the wee hours of the morning. It's a great procedure. Today's question is, how can MCP QUEUE SHOW take so long, even when the queue file is only around 550 blocks? Are the MX processes keeping records locked? Does MCP wait for them? Is this normal? And does the speed of the MCP QUEUE SHOW command reflect the speed at which the other MX processes are working with the file as well? I'm running MX 3.3, on a VMS V6.0 cluster of VAXes. The MX processes are running on two nodes of the cluster: 2 Routers, 3 Locals, 3 SMTP, 1 DNSMTP, 1 SMTP_SERVER, and 1 MLF on both of them. My newsfeed appears to be working normally, so I'll see any discussions from now on. Sorry for the confusion and all the posts. And thanks for any help. Ted -- Ted Corning UMass/Boston Computing Services kismet@trantor.cc.umb.edu ================================================================================ Archive-Date: Thu, 24 Mar 1994 14:58:19 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Thu, 24 Mar 1994 14:56:25 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097BEAE.6D6649C9.4@ALPHA.WKU.EDU> Subject: RE: Invalid calling IP address error dunnett@mala.bc.ca (Malcolm Dunnett) writes: > > One of our users got the attached error message on some mail sent with >MX. From my reading it appears that two things might be wrong here. The >first one is the HELO message only has "malasp" rather than the full >domain name "malasp.mala.bc.ca", Are you using UCX? Sounds like the old MX-needs-the-FQDN-first-in-UCX problem, as described in the MX release notes. BTW, the next version of MX includes a new NETLIB that removes the need to list the FQDN name first. >the second is that the remote host sends >message 208, which it calls a "warning" and MX chokes on it. > The next version of MX, due RSN, will accept these generic success values. > I don't know which end is at fault here. Where does the "malasp" come >from, have I got a logical set up wrong perhaps? Regarding the "208", is Check your host list in UCX to be sure the FQDN is listed first. >this a legitimate warning which MX should deal with or is the other end >sending a bogus code? > It's valid, but MX V3.3 checks for specific responses and 208 isn't one of them. As I said, MX V4.0 will accept this. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Thu, 24 Mar 1994 15:01:21 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Thu, 24 Mar 1994 15:00:42 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097BEAF.069368AC.12@ALPHA.WKU.EDU> Subject: RE: Queue File Questions kismet@trantor.cc.umb.edu (Ted Corning) writes: > > Today's question is, how can MCP QUEUE SHOW take so long, even when the > queue file is only around 550 blocks? Are the MX processes keeping > records locked? Does MCP wait for them? Is this normal? > As records are added and deleted, the index area goes to hell in a handbasket pretty quickly. It is indeed possible for QUEUE SHOW to take forever even with a small file---it all depends on how fragmented the index area is. Note that this fragmentation is internal to the file, not what you normally think of as a fragmented file. You might try changing the definition of MX_FLQ_RECLAIM_WAIT to something like 30 minutes instead of two hours. The MX processes don't keep the records locked and MCP doesn't wait on them. > And does the speed of the MCP QUEUE SHOW command reflect the speed at > which the other MX processes are working with the file as well? > Yes. Note that this problem will be eliminated in MX V4.0, as an indexed file is no longer used for the MX message queue. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Thu, 24 Mar 1994 15:02:18 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Thu, 24 Mar 1994 15:01:49 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097BEAF.2EAEABCB.18@ALPHA.WKU.EDU> Subject: RE: WKU out of commission until 3/26 (?) goatley@eisner.decus.org (Hunter Goatley) writes: > >The air conditioners in our VAX machine room have been out for two weeks. [...] >To complicate matters even more, we've been experiencing lost packets on >our T1 link to the Internet. That was supposed to have been fixed last >night, but wasn't---hopefully that'll be fixed soon. > >In the meantime, the FILESERV at WKUVX1.WKU.EDU, as well as mail to WKU, >will be out of commission. 8-( > FYI, the Internet connection has been fixed, and I still have WKUVX1 running (but not our other VAXen). Things are cooling off outside, so we should be OK until Saturday when the AC units are replaced. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Fri, 25 Mar 1994 10:01:52 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Fri, 25 Mar 1994 09:58:57 CST From: LIu daniAN Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wkuvx1.wku.edu Message-ID: <0097BF4E.09D33520.1694@BEAVER.HS.Bemidji.MSUS.edu> SUBS MX-LIST DANIAN LIU ================================================================================ Archive-Date: Fri, 25 Mar 1994 19:22:30 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Sat, 26 Mar 1994 01:15:59 GMT From: "Jamie Jones, HICOM Operations" Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wkuvx1.wku.edu Message-ID: <0097BFCE.25812D60.2@hicom.lut.ac.uk> Subject: RE: LOCAL agent loops on PSI-Mail In your message, received 22nd March 1994 23:14:45 you said: => Subject: LOCAL agent loops on PSI-Mail => Message-ID: <0097BD3C.97330620.26525@EUROPA.RS.CH> => => Hello out there in MX-land, => => I have a problem with the LOCAL-delivery agent. It loops, if I try => to do the following => => Rewrite rule: <{u}@{h}.psi.rest.of.domain> => => I know the way I wrote it down here is not correct, but the correct version => is in the config file. => Try changing the righthandside to <""psi%{h}::{u}""@localhost> Jamie ================================================================================ Archive-Date: Sat, 26 Mar 1994 18:42:17 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: goatley@eisner.decus.org (Hunter Goatley) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: WKU is back on-line Message-ID: <1994Mar26.182133.2732@eisner> Date: 26 Mar 94 18:21:33 -0500 To: MX-List@WKUVX1.WKU.EDU Well, our air conditioners have been replaced and our Internet connection was repaired on Thursday, so WKUVX1.WKU.EDU is back on-line. Actually, once the Internet T1 problem was fixed, I managed to keep WKUVX1 up without getting too hot. Anwyay, just a note to let you know that we're back in business. 8-) Hunter ------ Hunter Goatley, goathunter@WKUVX1.WKU.EDU ================================================================================ Archive-Date: Mon, 28 Mar 1994 12:34:13 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 28 Mar 1994 13:30:32 EST From: None The Wiser Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097C1C7.17CD730E.6162@stsci.edu> Subject: help with mailing list Hello Everyone, I'm a bit confused by something that's happening one our mailing lists. I went into MCP and MODIFIED a list to change the owner from the previous system manager to myself. In MCP, if I do a SHOW ALL it shows me as the owner of the list. However, if I try to send mail to MXSERVER and REVIEW the mailing list I get no response. I had the previous system manager check it and the REVIEW via mail showed him as the current owner. So that's two different responses from MX. He suggested I try to save and restart the server. In MCP I issued a SAVE and RESET/CLUSTER command. Still I get no response from the MXSERVER. Does anyone know what I'm doing wrong. I've been going through the manuals and still cannot figure this out. Any help would be greatly appreciated. Thanks, Patrick taylor@stsci.edu ================================================================================ Archive-Date: Mon, 28 Mar 1994 15:28:53 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 28 Mar 1994 17:06:32 ADT From: Greg Bishop Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wkuvx1.wku.edu Message-ID: <0097C1E5.44598CA0.13236@ac.nsac.ns.ca> Subject: Newsrdr problem The non-privileged users on our Academic VAX are getting the following error message when they try to run Newsrdr. The users who are using Newsrdr from other Vaxen via DECnet don't have this problem. $ Newsrdr %NEWS-I-CONNECTING, connecting to NNTP server ac.nsac.ns.ca %NEWS-F-NOCONNECT, could not connect to NNTP server ac.nsac.ns.ca -SYSTEM-W-ENDOFFILE, end of file I have no problem using it from a privileged account. Can anybody suggest a solution. Sorry if this is not the correct group to post to. Greg Greg Bishop Internet: GBISHOP@AC.NSAC.NS.CA System Manager Voice: (902) 893-6693 Nova Scotia Agricultural College Fax: (902) 895-4547 Truro, Nova Scotia CANADA B2N 5E3 ================================================================================ Archive-Date: Mon, 28 Mar 1994 15:45:14 CST Sender: List-Mgr@WKUVX1.WKU.EDU Date: Mon, 28 Mar 1994 13:40:50 PST From: robert@dis.ucsf.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097C1C8.87EBB320.9111@dis.ucsf.edu> Subject: RE: help with mailing list Try the MCP command RESET MLF Robert Weiner Manager, Development Information Systems robert@dis.ucsf.edu University of California, San Francisco > From: MX%"MX-List@WKUVX1.WKU.EDU" 28-MAR-1994 11:45:58.24 > Subj: help with mailing list > Hello Everyone, > > I'm a bit confused by something that's happening one our mailing lists. > I went into MCP and MODIFIED a list to change the owner from the previous > system manager to myself. In MCP, if I do a SHOW ALL it shows me as the > owner of the list. However, if I try to send mail to MXSERVER and REVIEW > the mailing list I get no response. I had the previous system manager check > it and the REVIEW via mail showed him as the current owner. So that's two > different responses from MX. He suggested I try to save and restart the server. > In MCP I issued a SAVE and RESET/CLUSTER command. Still I get no response > from the MXSERVER. > > Does anyone know what I'm doing wrong. I've been going through the manuals > and still cannot figure this out. Any help would be greatly appreciated. > > Thanks, > > Patrick > taylor@stsci.edu ================================================================================ Archive-Date: Mon, 28 Mar 1994 18:01:48 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: wing@tgv.com (Dan Wing) Subject: Re: Newsrdr problem Date: 28 Mar 1994 23:49:53 GMT Message-ID: <2n7qf1$gu@news.arc.nasa.gov> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097C1E5.44598CA0.13236@ac.nsac.ns.ca>, Greg Bishop writes: #>The non-privileged users on our Academic VAX are getting the following error #>message when they try to run Newsrdr. The users who are using Newsrdr from #>other Vaxen via DECnet don't have this problem. #> #> $ Newsrdr #> %NEWS-I-CONNECTING, connecting to NNTP server ac.nsac.ns.ca #> %NEWS-F-NOCONNECT, could not connect to NNTP server ac.nsac.ns.ca #> -SYSTEM-W-ENDOFFILE, end of file #> #>I have no problem using it from a privileged account. Might be a nameserver problem of some sort; check your nameserver configuration. #>Sorry if this is not the correct group to post to. I think INFO-MADGOAT@WKUVX1.WKU.EDU exists for discussions of MadGoat software (MX gets its own mailing list/newsgroup, though!) -Dan Wing, wing@tgv.com ================================================================================ Archive-Date: Mon, 28 Mar 1994 20:43:34 CST Sender: List-Mgr@WKUVX1.WKU.EDU From: kismet@trantor.cc.umb.edu (Ted Corning) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Re: Queue File Questions Date: 29 Mar 1994 01:32:42 GMT Message-ID: <2n80fq$p92@anchor.cc.umb.edu> To: MX-List@WKUVX1.WKU.EDU Hunter Goatley, WKU (goathunter@ALPHA.WKU.EDU) wrote: : kismet@trantor.cc.umb.edu (Ted Corning) writes: : > : > Today's question is, how can MCP QUEUE SHOW take so long, even when the : > queue file is only around 550 blocks? Are the MX processes keeping : > records locked? Does MCP wait for them? Is this normal? : > : As records are added and deleted, the index area goes to hell in a : handbasket pretty quickly. It is indeed possible for QUEUE SHOW to : take forever even with a small file---it all depends on how fragmented : the index area is. Note that this fragmentation is internal to the : file, not what you normally think of as a fragmented file. : You might try changing the definition of MX_FLQ_RECLAIM_WAIT to : something like 30 minutes instead of two hours. : The MX processes don't keep the records locked and MCP doesn't wait on : them. : > And does the speed of the MCP QUEUE SHOW command reflect the speed at : > which the other MX processes are working with the file as well? : > : Yes. : Note that this problem will be eliminated in MX V4.0, as an indexed : file is no longer used for the MX message queue. : Hunter : ------ : Hunter Goatley, VMS Systems Programmer, Western Kentucky University : goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) Hi, I changed the MX_FLQ_RECLAIM_WAIT to 30 minutes, but it seems to have just made things worse. Does having multiple Router processes confuse things? Also, unrelated, I just removed EXQUOTA from the Local delivery process. Will this cause any problems? I have users who are thousands of blocks over their quotas because of mailing lists. Ted -- Ted Corning UMass/Boston Computing Services kismet@trantor.cc.umb.edu ================================================================================ Archive-Date: Tue, 29 Mar 1994 07:14:35 CST Sender: owner-MX-List@WKUVX1.WKU.EDU Date: Tue, 29 Mar 1994 07:14:18 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097C25B.B3064F55.9@ALPHA.WKU.EDU> Subject: Re: Queue File Questions kismet@trantor.cc.umb.edu (Ted Corning) writes: > > I changed the MX_FLQ_RECLAIM_WAIT to 30 minutes, but it seems to have just > made things worse. Does having multiple Router processes confuse things? > Most likely it didn't make any difference---it sounds like the Router isn't ever getting a chance to reclaim (which requires exclusive access to the file). If you have users who stay in VMS Mail sending MX mail most of the day, then the reclaim never happens. You might also consider using MX_SHRINK, too. > Also, unrelated, I just removed EXQUOTA from the Local delivery process. > Will this cause any problems? I have users who are thousands of blocks over > their quotas because of mailing lists. > I don't think it will cause any problems, as long as there are no quotas on the MX disk (MX_FLQ_DIR:). Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Tue, 29 Mar 1994 09:10:10 CST Sender: owner-MX-List@WKUVX1.WKU.EDU From: kismet@trantor.cc.umb.edu (Ted Corning) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Re: Queue File Questions Date: 29 Mar 1994 14:17:32 GMT Message-ID: <2n9d9s$gpi@anchor.cc.umb.edu> To: MX-List@WKUVX1.WKU.EDU Hunter Goatley, WKU (goathunter@ALPHA.WKU.EDU) wrote: > Most likely it didn't make any difference---it sounds like the Router > isn't ever getting a chance to reclaim (which requires exclusive > access to the file). If you have users who stay in VMS Mail sending > MX mail most of the day, then the reclaim never happens. You might > also consider using MX_SHRINK, too. > I am using MX_SHRINK. It gets kicked off at 3:10AM, and has been doing a good job on the queue file. But I looked at it today, and it is still doing the MCP QUEUE PURGE, which started at 3:50AM, and it's now 9:15! This is the first time it's ever acted like this. Shouldn't the PURGE go faster on a newly optimized file? Thanks for all your help. >: Hunter >: ------ >: Hunter Goatley, VMS Systems Programmer, Western Kentucky University >: goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) -- Ted Corning UMass/Boston Computing Services kismet@trantor.cc.umb.edu ================================================================================ Archive-Date: Tue, 29 Mar 1994 09:25:14 CST Sender: owner-MX-List@WKUVX1.WKU.EDU Date: Tue, 29 Mar 1994 09:24:21 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097C26D.DDB69EDC.3@ALPHA.WKU.EDU> Subject: Re: Queue File Questions kismet@trantor.cc.umb.edu (Ted Corning) writes: > >I am using MX_SHRINK. It gets kicked off at 3:10AM, and has been doing >a good job on the queue file. But I looked at it today, and it is still >doing the MCP QUEUE PURGE, which started at 3:50AM, and it's now 9:15! >This is the first time it's ever acted like this. Shouldn't the PURGE go >faster on a newly optimized file? > That's the plan, yes, but it depends on how many entries there are and how badly the newly optimized file was "uglified" since it was optimized. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Tue, 29 Mar 1994 10:16:45 CST Sender: owner-MX-List@WKUVX1.WKU.EDU Date: Tue, 29 Mar 1994 17:11:32 EST From: Paul Havinden Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-list@WKUVX1.WKU.EDU Message-ID: <0097C2AF.217FD480.13592@arc.ug.eds.com> Subject: Help with mail hub/rewrites I am setting up MX on one of our central VMS systems. This is connected by DECNET (and TCP/IP) to several other sites. I would like to be able to use the node with MX as a central mail hub, so that incoming mail could be addressed as follows:- user@host.sub.domain where the Mail Exchange record for this machine will point at sub.domain which is the machine running MX software. So MX would need forward this mail to node HOST via decnet. I think this can be done by setting up a rewrite rule? What about mail from node HOST. They would need to address out going mail as SUB::MX%"username@anysub.anydomain". How would I get the out going return/from address rewritten to user@host.sub.domain? I think what I am asking is how to make our other DECNET sites appear as subdomains for email. We currently use a VMS server running PMDF (not under our control) which did this for us. In fact thats what any mail to me will go via. ie My current email address is paulh@arc.ug.eds.com where in fact node ARC is DECNET connected to the ug.eds.com mail host. I any understands what I have just ask and can suggest how I might do this I would be very grateful. Many Thanks Paul Havinden Graphic Data System Cambridge, UK ================================================================================ Archive-Date: Tue, 29 Mar 1994 11:52:41 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Subject: RE: More help needed on reviving dying MX_LOCAL process Message-ID: <2n9k4s$39d@kasey.umkc.edu> From: mckeever@CSTP.UMKC.EDU (Brian McKeever) Date: 29 Mar 1994 16:14:20 GMT Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097BD9B.C773E1B0.21@ALPHA.WKU.EDU>, "Hunter Goatley, WKU" writes: >cooper@utsph.sph.uth.tmc.edu writes: >> >>I posted a message previously about the MX_LOCAL process dying on the ALPHA [...] >Mine looks like: > >>23-MAR-1994 06:08:22.78 User: SYSTEM Process ID: 204001BE >> Node: ALPHA Process name: "MX Local" >> >>Process Quotas: >> Account name: SYSTEM >> CPU limit: Infinite Direct I/O limit: 100 >> Buffered I/O byte count quota: 99040 Buffered I/O limit: 100 >> Timer queue entry quota: 49 Open file quota: 93 >> Paging file quota: 58912 Subprocess quota: 32 >> Default page fault cluster: 128 AST quota: 99 >> Enqueue quota: 289 Shared file limit: 0 >> Max detached processes: 0 Max active jobs: 0 >> > >The Pgflquo as defined in SYSUAF for SYSTEM is 50000; this appears to >be overriding the value specified on the RUN command in MX_START.COM, >as my MX_START.COM is the same as yours. > >You might try it and see if it helps.... Well, mine looks like this: Process Quotas: Account name: SS001S CPU limit: Infinite Direct I/O limit: 100 Buffered I/O byte count quota: 99040 Buffered I/O limit: 100 Timer queue entry quota: 49 Open file quota: 93 Paging file quota: 51760 Subprocess quota: 32 Default page fault cluster: 128 AST quota: 99 Enqueue quota: 286 Shared file limit: 0 Max detached processes: 0 Max active jobs: 0 Almost identical to yours Hunter and my Local agent is dying about once a day with "%SYSTEM-F-EXQUOTA, process quota exceeded". Any other ideas? I've installed the AXP security patch. Should I RESET the Local agent every so often to stave off the memory leek? I guess I could scan system processes for "MX Local" every so often and restart it if it dies. Could it be a Direct I/O limit? Buffered I/O limit? Unlike the previous poster, I cannot recreate the problem. It just happens. There seems to be no pattern to when it happens or from what host. It just dies, leaving a .TMP file in MX_LOCAL_DIR. It does not even reliably announce to OPCOM that it is exiting. MX V3.3, VMS V1.5 Thanks, -=Brian ================================================================================ Archive-Date: Tue, 29 Mar 1994 12:15:37 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Tue, 29 Mar 1994 12:13:21 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097C285.799D4433.3@ALPHA.WKU.EDU> Subject: RE: More help needed on reviving dying MX_LOCAL process mckeever@CSTP.UMKC.EDU (Brian McKeever) writes: > >Almost identical to yours Hunter and my Local agent is dying about once >a day with "%SYSTEM-F-EXQUOTA, process quota exceeded". > >Any other ideas? I've installed the AXP security patch. Should I >RESET the Local agent every so often to stave off the memory leek? I >guess I could scan system processes for "MX Local" every so often and >restart it if it dies. Could it be a Direct I/O limit? Buffered I/O >limit? > If you *have* installed the AXP security MUP02, then that's the problem. You need to retrieve the original MAILSHR.EXE file from V1.5. I don't know yet if this is a problem in T2.0 (T6.1). The MAILSHR.EXE in MUP02 contains an apparently huge memory leak. RESET won't do anything to stop it---writing something to look for MX Local and restart it is a workaround. Unfortunately, the problem (as far as I can tell) is in callable mail, not MX Local, so there's not really anything I can do about it. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Tue, 29 Mar 1994 14:19:01 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Tue, 29 Mar 1994 13:10:20 EST From: "Stanley J. McCaslin" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-LIST@WKUVX1.WKU.EDU Message-ID: <0097C28D.6FC12C56.24414@psccs1.peru.edu> Subject: VMS mail headers I expect this is a VMS problem, but if anyone out there knows a workaround, I would appreciate hearing it. When VMS mail comes through MX, its From: address is the Reply-To: address off the net, rather than the From: address. Normally this is no problem, but I have some users on mailing lists who would like to see who the post is from, i.e. the From: address from the list, rather then the Reply-To: list, which is usually the list address, when they do a Dir from Mail. Is there any way to get VMS mail to use the From, rather than the Reply-To, from the header when it delivers the mail? Stanley J. McCaslin Inet: mccaslin@psccs1.peru.edu Assistant Professor, Computer Science Phone:402/872-2208 Peru State College, Peru, NE 68421 Home: 402/872-7595 ================================================================================ Archive-Date: Tue, 29 Mar 1994 14:25:08 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Tue, 29 Mar 1994 14:21:18 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-LIST@WKUVX1.WKU.EDU Message-ID: <0097C297.5A064720.17@ALPHA.WKU.EDU> Subject: About MX V4.0.... MX V4.0 is almost ready for release. A full announcement including a brief list of enhancements will be posted when it is ready. In the meantime, I wanted to give you ample warning about an upgrade limitation. As has been discussed here already, MX V4.0 does away with the ISAM message queue file and instead uses a direct-access sequential file. The speed improvements are astounding. Unfortunately, the type of data stored in the new file differs enough from that of the old that it is not really possible to convert the old queue to the new queue format. This means that you *will* have to create a new queue file during the MX installation. You *will* need to clear out your existing queue before doing the installation---otherwise, any messages in the queue at that time will be lost. (The installation will warn you about this, so it's not like the installation just immediately wipes out the existing queue---you have to tell it that it's OK to do so.) I tried several times to come up with good conversion programs and finally gave it up. This is bound to cause some problems for some sites, so I wanted to let you know ahead of time so that you can plan for it. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Tue, 29 Mar 1994 14:31:44 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Tue, 29 Mar 1994 14:30:00 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097C298.90C586CB.23@ALPHA.WKU.EDU> Subject: RE: VMS mail headers "Stanley J. McCaslin" writes: > >I expect this is a VMS problem, but if anyone out there knows a workaround, >I would appreciate hearing it. >When VMS mail comes through MX, its From: address is the Reply-To: address off >the net, rather than the From: address. Normally this is no problem, but I >have some users on mailing lists who would like to see who the post is from, >i.e. the From: address from the list, rather then the Reply-To: list, which is >usually the list address, when they do a Dir from Mail. Is there any way to >get VMS mail to use the From, rather than the Reply-To, from the header when it >delivers the mail? > No, that's MX using the Reply-To:, as it's supposed to do according to RFC822. There is no way (short of modifying the code) to make MX not use the Reply-To:, if it's there and valid. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Tue, 29 Mar 1994 17:39:21 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Wed, 30 Mar 1994 08:34:50 JST From: Tim Burress Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097C330.1DB8B5C0.1008@tanuki.twics.com> Subject: RE: VMS mail headers >>When VMS mail comes through MX, its From: address is the Reply-To: address off >>the net, rather than the From: address. Normally this is no problem, but I >>have some users on mailing lists who would like to see who the post is from, >>i.e. the From: address from the list, rather then the Reply-To: list, which is >>usually the list address, when they do a Dir from Mail. Is there any way to >>get VMS mail to use the From, rather than the Reply-To, from the header when it >>delivers the mail? >> >No, that's MX using the Reply-To:, as it's supposed to do according to >RFC822. There is no way (short of modifying the code) to make MX not >use the Reply-To:, if it's there and valid. On the other hand, is there a way to coerce the MLF program into putting the list name, rather than the sender's name, in the Reply-To: field? We often get the opposite problem, with replies meant for the list going to the person who posted a note, because, as you say, the software is looking at the Reply- To: field. Also, while I'm at it, is there a way in MX (or Multinet, if anyone knows) to "hide" the machine from which a user has written a message behind the general domain name? We have about a dozen machines of various types all hooked up with TCP/IP, so their "From:" and "Reply-To:" lines normally end up being something like somebody@xxxxx.twics.com. I've kludged the "From:" line using an MX option for the "From:" line format, but can't seem to get at the "Reply- To:" line. This is creating weird problems for people on mailing lists, as well as general confusion among novice netters. We'd like to have all outgoing mail addresses look like "somebody@twics.com". Thanks! Tim ================================================================================ Archive-Date: Tue, 29 Mar 1994 18:26:28 CST Sender: owner-mx-list@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: Help with mail hub/rewrites Date: 30 Mar 1994 00:02:40 GMT Message-ID: <2nafj0$qcl@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097C2AF.217FD480.13592@arc.ug.eds.com>, Paul Havinden writes: =I am setting up MX on one of our central VMS systems. This is connected by =DECNET (and TCP/IP) to several other sites. I would like to be able to use the =node with MX as a central mail hub, so that incoming mail could be addressed as =follows:- = =user@host.sub.domain where the Mail Exchange record for this machine will =point at sub.domain which is the machine running MX software. So MX would need =forward this mail to node HOST via decnet. I think this can be done by setting =up a rewrite rule? =What about mail from node HOST. They would need to address out going mail as =SUB::MX%"username@anysub.anydomain". How would I get the out going return/from =address rewritten to user@host.sub.domain? = =I think what I am asking is how to make our other DECNET sites appear as =subdomains for email. We currently use a VMS server running PMDF (not under our =control) which did this for us. In fact thats what any mail to me will go via. =ie My current email address is paulh@arc.ug.eds.com where in fact node ARC is =DECNET connected to the ug.eds.com mail host. = =I any understands what I have just ask and can suggest how I might do this I =would be very grateful. Probably the easiest way to deal with this would to be to run MX on all the nodes, with the hub running the SMTP, DSMTP, LOCAL, and SMTP Server processes, and the other machines running just the DSMTP and LOCAL processes. Then, in the hubs MX database, you could define paths of the form: DEFINE PATH smtp_host_name DECnet_SMTP/ROUTE=decnet_node_name -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Tue, 29 Mar 1994 18:59:34 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Tue, 29 Mar 1994 19:56:47 EST From: kamrul@ycvax.york.cuny.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wkuvx1.wku.edu Message-ID: <0097C2C6.37D491A0.3033@ycvax.york.cuny.edu> Subject: Help suppress/modify mail header Hi there: We are using MX 3.3 and VMS 5.5 . The Return-Path, Errors-To and Sender fields in the header of any mail posted through a list contain the owner's address. Is there any way to modify and/or suppress these three fields? If it is expained in any manual, please tell me where to look for. Thanks very much. Kamrul Ahsan York College, CUNY New York. ================================================================================ Archive-Date: Tue, 29 Mar 1994 19:08:44 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Tue, 29 Mar 1994 19:06:15 EST From: Chris Olive Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: tim@twics.com, olive@sgi.siemens.com Message-ID: <0097C2BF.282A1E20.1280@sgi.siemens.com> Subject: RE: VMS mail headers In article <0097C330.1DB8B5C0.1008@tanuki.twics.com>, Tim Burress writes: >with TCP/IP, so their "From:" and "Reply-To:" lines normally end up being >something like somebody@xxxxx.twics.com. I've kludged the "From:" line using >an MX option for the "From:" line format, but can't seem to get at the "Reply- >To:" line. I'm curious about this... To what particular kludge are you referring? Chris _______________________________________________________________________________ ___ ___ ___ _ _ ___ _ _ ___ /___ | |__ |\ /| |__ |\ | /___ Chris Olive, VMS Systems Consultant ___/ _|_ |___ | Y | |___ | \| ___/ Internet: olive@sgi.siemens.com Medical Systems, Inc. Voice: 708.304.7793 2501 N. Barrington Road. FAX: 708.304.7704 Hoffman Estates, IL 60195 CompuServe: 73740,1636 _______________________________________________________________________________ ================================================================================ Archive-Date: Tue, 29 Mar 1994 19:34:49 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Wed, 30 Mar 1994 10:30:39 JST From: Tim Burress Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-LIST@WKUVX1.WKU.EDU Message-ID: <0097C340.4B3E33C0.2115@tanuki.twics.com> Subject: RE: VMS mail headers >>with TCP/IP, so their "From:" and "Reply-To:" lines normally end up being >>something like somebody@xxxxx.twics.com. I've kludged the "From:" line using >>an MX option for the "From:" line format, but can't seem to get at the "Reply- >>To:" line. > > I'm curious about this... To what particular kludge are you referring? There's a logical name, MX_VMSMAIL_FROM_FORMAT that you can use to set the form of the "From:" line, so I've defined it like this: "MX_VMSMAIL_FROM_FORMAT" = "" which forces all outgoing "From:" lines into the username@twics.com format that people want. But the outgoing "Reply-To:" line still uses the fully qualified domain names, resulting in confusion. Ideally, I'd like to be able to have a "network alias" or something like that which would apply to locally originated mail. Tim ================================================================================ Archive-Date: Tue, 29 Mar 1994 23:32:46 CST Sender: owner-mx-list@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: RE: VMS mail headers Date: 30 Mar 1994 05:08:49 GMT Message-ID: <2nb1h1$6ro@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097C330.1DB8B5C0.1008@tanuki.twics.com>, Tim Burress writes: =On the other hand, is there a way to coerce the MLF program into putting the =list name, rather than the sender's name, in the Reply-To: field? We often =get the opposite problem, with replies meant for the list going to the person =who posted a note, because, as you say, the software is looking at the Reply- =To: field. $ MCR MX_EXE:MCP HELP DEFINE LIST /REPLY_TO DEFINE LIST /REPLY_TO /REPLY_TO=(kwd[,...]) Specifies how the mailing list processor should handle Reply-To headers. Available reply-to types are SENDER and LIST, which may be combined. The default is SENDER, which prevents the mailing list processor from modifying the headers. If LIST is specified, a Reply-To header is added to list messages to re-direct replies to the mailing list, eliminating any existing Reply-To header in the original message. If LIST and SENDER are both specified, a Reply-To header containing both the mailing list address and the original Reply-To address is added to list messages (using the From address if no Reply-To header existed in the original message). -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Wed, 30 Mar 1994 04:05:36 CST Sender: owner-mx-list@WKUVX1.WKU.EDU From: "Pasztor Miklos" Reply-To: MX-List@WKUVX1.WKU.EDU To: Tim Burress , MX-List@WKUVX1.WKU.EDU Date: Tue, 29 Mar 1994 23:59:03 CET Subject: RE: VMS mail headers Message-ID: <2ABB7E2B61@aszi.sztaki.hu> > > which forces all outgoing "From:" lines into the username@twics.com format tha t > people want. But the outgoing "Reply-To:" line still uses the fully qualified > domain names, resulting in confusion. > > Ideally, I'd like to be able to have a "network alias" or something like that > which would apply to locally originated mail. > Tim, You can use DEF MX_REPLY_TO "anybody@any.domain.here". If you put something like: $user = F$EDIT( F$GETJPI("","USERNAME"),"COLLAPSE") $def MX_REPLY_TO "''user'@twics.com" in your sylogin.com, you get what you want. Regards, Miklos ==================================================================== Pa'sztor Miklo's | E-mail: pasztor@hugbox.bitnet MTA SZTAKI/ASZI Budapest Victor H. u. 18-22 | Phone: (36)-(1)-149-75-32 Institute for Computation and Automation, Hungarian Academy of Sciences ==================================================================== ================================================================================ Archive-Date: Wed, 30 Mar 1994 05:01:30 CST Sender: owner-mx-list@WKUVX1.WKU.EDU From: "Pasztor Miklos" Reply-To: MX-List@WKUVX1.WKU.EDU To: "Hunter Goatley, WKU" , MX-List@WKUVX1.WKU.EDU Date: Wed, 30 Mar 1994 00:31:21 CET Subject: Re: About MX V4.0.... Message-ID: <2B452B059A@aszi.sztaki.hu> [...] > This means that you *will* have to > create a new queue file during the MX installation. You *will* need > to clear out your existing queue before doing the > installation---otherwise, any messages in the queue at that time will > be lost. (The installation will warn you about this, so it's not like > the installation just immediately wipes out the existing queue---you > have to tell it that it's OK to do so.) > > I tried several times to come up with good conversion programs and > finally gave it up. This is bound to cause some problems for some > sites, so I wanted to let you know ahead of time so that you can plan > for it. A collegue of mine has written a small program that refeeds the MX queue. It does do following: Creates a message file with the RFC822 headers from the .hdr_info file, and the .msg_text file, and creates a .to file from the TO and CC lines of the .hdr_info file. The recipients addresses are stored in this .to file in the format as MX_SITE_IN requires. The program can be used along with a command procedure to do MX_SITE_IN and refeed all the messages in mx_root:[queue...] in the MX queue. The solution is certainly not perfect since: - the from attribute of the message is not preserved, (note that this could be fixed) - the message you processed could have been in FINISHED, or CANCELED state, - actually the TO: and CC: lines are *not* the intended recipients, these should be the contents of the "RCPT TO" RFC821 line instead, - etc, but I think that it is useful since at least it can save same messages from being lost. If anybody wishes I can send the code. Regards, Miklos ==================================================================== Pa'sztor Miklo's | E-mail: pasztor@hugbox.bitnet MTA SZTAKI/ASZI Budapest Victor H. u. 18-22 | Phone: (36)-(1)-149-75-32 Institute for Computation and Automation, Hungarian Academy of Sciences ==================================================================== ================================================================================ Archive-Date: Wed, 30 Mar 1994 07:37:20 CST Sender: owner-mx-list@WKUVX1.WKU.EDU From: system@orion.cmc.uab.edu (Tim Buckner) Subject: Mail headers Message-ID: <30MAR199407000089@orion.cmc.uab.edu> Reply-To: MX-List@WKUVX1.WKU.EDU Date: Wed, 30 Mar 1994 13:00:00 GMT To: MX-List@WKUVX1.WKU.EDU While the topic is on mail headers, has anyone seen the following header line? Warnings-To: <> I get this in Usenet posts sent through a MX->News gateway. I have tried sending mail to the MX->News gateway from multiple machines and still get the warning header so I assume that it gets added by the gateway. I do not get the line when I post normally. Nor do I get this header from any mail sent from this machine. Any suggestions on how this line should be eliminated? Alternatively, how should it be completed? Of course, knowing the source of the line could help a lot. Where does it come from? Environment: MX 3.3, MX_POST, VMS 5.4-2, Multinet 3.2D, VNEWS 1.41 -- Tim Buckner - system@orion.cmc.uab.edu - buckner@topaz.decus.org -- Univ. Alabama at Birmingham Center for Macromolecular Crystallography 261 BHSB, Birmingham, AL 35294-0005 USA phone/fax:(205)934-1973/-0480 Disclaimer:IMHO, this isn't the HO of my employer and maybe not my HO. ================================================================================ Archive-Date: Wed, 30 Mar 1994 08:23:26 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Wed, 30 Mar 1994 08:23:11 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097C32E.7CC4913A.3@ALPHA.WKU.EDU> Subject: RE: Mail headers system@orion.cmc.uab.edu (Tim Buckner) writes: > >While the topic is on mail headers, has anyone seen the following >header line? > > Warnings-To: <> > Yes, that's intentionally added by MX for all list traffic. >Any suggestions >on how this line should be eliminated? Alternatively, how should it >be completed? Of course, knowing the source of the line could help a >lot. Where does it come from? > The purpose is to (try to) stop mailers like PMDF and others from sending warning messages to the list owner. If you've ever run a list without it, you'll find that you get inundated with messages from some mailers that say "Your message has been undeliverable for X days, will continue retrying for Y days." When it's list traffic, you *don't* want to get millions of these if you can help it. This line helps it. The "<>" essentially says, "Do not send any warnings." Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Wed, 30 Mar 1994 08:46:18 CST Sender: owner-mx-list@WKUVX1.WKU.EDU MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Mar 1994 08:47:11 -0600 To: MX-List@WKUVX1.WKU.EDU From: gilliam@alpha.hendrix.edu (Dan Gilliam) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Re: MX-LIST Digest V94 #60 > If you *have* installed the AXP security MUP02, then that's the > problem. You need to retrieve the original MAILSHR.EXE file from > V1.5. I don't know yet if this is a problem in T2.0 (T6.1). The > MAILSHR.EXE in MUP02 contains an apparently huge memory leak. Do similar problems exist with MUP03 for VAX? Since we installed it over VMS 5.5-2, we've had a lot of problems with our SMTP service. We have 20 or so people using Eudora for the Mac, which sends and receives e-mail via POP3 and SMTP servers on our VAX. When you attempt to send mail, Eudora can't connect to the SMTP server, unless the MX processes have just been stopped and restarted. Doing a "telnet localhost 25" from the VAX to connect directly to the SMTP server works occasionally, but at times is very slow. At other times, the telnet returns a "connect to network object refused". Has anyone seen this behavior? Dan Gilliam Asst. Director, Computer Services Hendrix College ================================================================================ Archive-Date: Wed, 30 Mar 1994 10:07:53 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Wed, 30 Mar 1994 11:02:13 EST From: "Jonathan E. Hardis" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: hardis@garnet.nist.gov Message-ID: <0097C344.B42F4BE0.7767@garnet.nist.gov> Subject: RE: VMS mail headers > Also..., is there a way in MX (or Multinet, if anyone knows) to "hide" the > machine from which a user has written a message behind the general domain > name? We have about a dozen machines of various types all hooked up with > TCP/IP, so their "From:" and "Reply-To:" lines normally end up being > something like somebody@xxxxx.twics.com. I've kludged the "From:" line > using an MX option for the "From:" line format, but can't seem to get at > the "Reply- To:" line. This is creating weird problems for people on > mailing lists, as well as general confusion among novice netters. We'd > like to have all outgoing mail addresses look like "somebody@twics.com". Since no one else has mentioned it, what about changing the logicals MX_VMSMAIL_LOCALHOST and/or MX_NODE_NAME in MX_LOGICALS.DAT? - Jonathan ================================================================================ Archive-Date: Wed, 30 Mar 1994 11:31:42 CST Sender: owner-mx-list@WKUVX1.WKU.EDU From: kismet@trantor.cc.umb.edu (Ted Corning) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: LOCAL Daemon crashing Date: 30 Mar 1994 17:04:03 GMT Message-ID: <2ncbe3$3ba@anchor.cc.umb.edu> To: MX-List@WKUVX1.WKU.EDU Hi, I am running into a problem this morning with my LOCAL daemons crashing. This has just started. The ONLY thing that has changed is that I have removed EXQUOTA from the Local processes. We are running MX V3.3, VAX/VMS V6.0, VAX 8800. The disk for the MX spool area has Diskquotas disabled. Here is some more information: MX_LOCAL_GEMINI.LOG: 30-MAR-1994 11:13:32.21: MX Local#2 (pid 00A245A7) starting 30-MAR-1994 11:50:16.79: MX Local#2 (pid 00A245A7) exiting, status = 10018294 MX_LOCAL_LOG.LOG: 30-MAR-1994 11:50:16.03 Processing queue entry number 16884 MCP QUE SHOW 16884/FULL: Entry: 16883, Origin unknown Status: IN-PROGRESS, size: 717 bytes Created: 30-MAR-1994 04:44:36.18, expires 29-APR-1994 04:44:36.18 Last modified 30-MAR-1994 11:18:35.82 LOCAL entry #16884, status: IN-PROGRESS, size: 717 bytes Created: 30-MAR-1994 04:44:38.03, expires 29-APR-1994 04:44:36.18 Last modified 30-MAR-1994 11:50:15.71 [no LOCAL_INFO file for this entry] $ dir mx_root:[queue.4..]*688*.* %DIRECT-W-NOFILES, no files found I am wondering if this could be caused by messages that are going to multiple users, and only one has a quota problem. Would the queue file be deleted but the entry stay in the queue file for later processing? Thanks in advance for any help. Ted -- Ted Corning UMass/Boston Computing Services kismet@trantor.cc.umb.edu ================================================================================ Archive-Date: Wed, 30 Mar 1994 11:53:20 CST Sender: owner-mx-list@WKUVX1.WKU.EDU From: system@orion.cmc.uab.edu (Tim Buckner) Subject: RE: Mail headers Message-ID: <30MAR199411224639@orion.cmc.uab.edu> Reply-To: MX-List@WKUVX1.WKU.EDU Date: Wed, 30 Mar 1994 17:22:00 GMT To: MX-List@WKUVX1.WKU.EDU >In article <0097C32E.7CC4913A.3@ALPHA.WKU.EDU>, >"Hunter Goatley, WKU" writes... >>system@orion.cmc.uab.edu (Tim Buckner) writes: >> >>While the topic is on mail headers, has anyone seen the following >>header line? >> >> Warnings-To: <> >> >Yes, that's intentionally added by MX for all list traffic. > >>Any suggestions >>on how this line should be eliminated? Alternatively, how should it >>be completed? Of course, knowing the source of the line could help a >>lot. Where does it come from? >> >The purpose is to (try to) stop mailers like PMDF and others from >sending warning messages to the list owner. If you've ever run a >list without it, you'll find that you get inundated with messages from >some mailers that say "Your message has been undeliverable for X days, >will continue retrying for Y days." When it's list traffic, you >*don't* want to get millions of these if you can help it. This line >helps it. The "<>" essentially says, "Do not send any warnings." Thanks for the follow up and the explanation... Now here's the rub: My system is a news reader and it posts through a machine that is out of my influence. The controllers of the news server have requested that the line either be removed or contain a valid contain a mailing address. What do you suggest? -- Tim Buckner - system@orion.cmc.uab.edu - buckner@topaz.decus.org -- Univ. Alabama at Birmingham Center for Macromolecular Crystallography 261 BHSB, Birmingham, AL 35294-0005 USA phone/fax:(205)934-1973/-0480 Disclaimer:IMHO, this isn't the HO of my employer and maybe not my HO. ================================================================================ Archive-Date: Wed, 30 Mar 1994 14:47:59 CST Sender: owner-mx-list@WKUVX1.WKU.EDU From: wing@tgv.com (Dan Wing) Subject: RE: Mail headers Date: 30 Mar 1994 18:42:52 GMT Message-ID: <2nch7c$r7f@news.arc.nasa.gov> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <30MAR199411224639@orion.cmc.uab.edu>, system@orion.cmc.uab.edu (Tim Buckner) writes: #>>>While the topic is on mail headers, has anyone seen the following #>>>header line? #>>> #>>> Warnings-To: <> [...] #>My system is a news reader and it posts through a machine that is out #>of my influence. The controllers of the news server have requested #>that the line either be removed or contain a valid contain a mailing #>address. What do you suggest? You could write a Site agent which strips the header. The Site agent could all be in DCL and use TPU to strip the first Warnings-To: <> line. -Dan Wing, wing@tgv.com ================================================================================ Archive-Date: Wed, 30 Mar 1994 16:20:12 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Wed, 30 Mar 1994 15:15:16 -0700 From: "Ray Harwood -- Data Basix: (602)721-1988" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: rharwood@Data.Basix.COM Message-ID: <0097C368.0E3CF4C0.27182@Data.Basix.COM> Subject: RE: Mail headers > #>My system is a news reader and it posts through a machine that is out > #>of my influence. The controllers of the news server have requested > #>that the line either be removed or contain a valid contain a mailing > #>address. What do you suggest? > > You could write a Site agent which strips the header. The Site agent could > all be in DCL and use TPU to strip the first Warnings-To: <> line. Excuse me, but now I'M confused. Are you actually POSTING to news using mail which flows through MX? You're not using a newsreader of some sort? MX doesn't control the headers created by any news reader that I'm aware of. ANU-News and VNews only go through MX when using the REPLY function, and that circumvents normal posting and simply sends an EMail that SHOULND'T be of any interest to your News Server folks. All other times, they use the NNTP protocol and pass their own headers. I'll stand by quietly and see if the mud clears... Ray ----- Ray Harwood | Data Basix | DEC Pro Networking Editor Voice: (602)721-1988 | PO Box 18324 | "Internet Resource Guide" FAX: (602)721-7240 | Tucson, AZ 85731 | Adjunct Faculty, East Campus, RHarwood@Data.Basix.COM | Info@Data.Basix.COM | Pima Community College ================================================================================ Archive-Date: Wed, 30 Mar 1994 16:40:44 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Wed, 30 Mar 1994 17:35:00 EST From: "Jonathan E. Hardis" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU CC: system@orion.cmc.uab.edu, hardis@garnet.nist.gov Message-ID: <0097C37B.93732660.7791@garnet.nist.gov> Subject: RE: Mail headers > My system is a news reader and it posts through a machine that is out > of my influence. The controllers of the news server have requested > that the line either be removed or contain a valid contain a mailing > address. What do you suggest? On one hand, I don't understand what the problem is. This discussion concerns the MX MLF, and not a news reader that posts to news groups. On the other hand, I may have the answer if the question is: One entry on my mailing list has special requirements. How can I change the headers for mail going to that one destination? For such circumstances, use the SITE processor. We have the PMDF mail->fax gateway running on a host on site, and I have to diddle with the "Reply To:" headers for it. (If I don't, an acknowledge- ment of the fax is returned to the entire mailing list.) On the mailing list, I manually entered some addresses as "user@fax", and I made a configuration entry: DEFINE PATH "fax" SITE SITE_DELIVER.COM looks like: $! Site Delivery Agent to modify FAX headers for PMDF $! $ SET NOON $! $! Modify contents of msg-file (P2) to change "Reply-To:" to <> $! $ DEFINE/USER_MODE SYS$OUTPUT NL: $ SEARCH 'P2' "X-ListName:" $ IF ($SEVERITY .EQ. 3) THEN GOTO NOT_FROM_MAILING_LIST $ DEFINE/USER_MODE SYS$OUTPUT NL: $ EDIT/EDT/COMMAND=MX_ROOT:[SITE]CHANGE_P2_LIST.DAT 'P2' $ GOTO FINISH_P2 $ NOT_FROM_MAILING_LIST: $ DEFINE/USER_MODE SYS$OUTPUT NL: $ SEARCH 'P2' "Reply-To:" $ IF ($SEVERITY .EQ. 3) THEN GOTO NO_REPLY_TO $ DEFINE/USER_MODE SYS$OUTPUT NL: $ EDIT/EDT/COMMAND=MX_ROOT:[SITE]CHANGE_P2_NOLIST.DAT 'P2' $ GOTO FINISH_P2 $ NO_REPLY_TO: $ DEFINE/USER_MODE SYS$OUTPUT NL: $ EDIT/EDT/COMMAND=MX_ROOT:[SITE]CHANGE_P2_NOREPLY.DAT 'P2' $ FINISH_P2: $ NEW_P2 = F$PARSE(";2",P2) $! $! Modify contents of dest-file (P3) to change from @FAX to the real host $! $ DEFINE/USER_MODE SYS$OUTPUT NL: $ EDIT/EDT/COMMAND=MX_ROOT:[SITE]CHANGE_P3.DAT 'P3' $ NEW_P3 = F$PARSE(";2",P3) $! $! Send processed file on its way $! $ MX_ENTER := $MX_EXE:MX_SITE_IN $ MX_ENTER 'NEW_P2' 'NEW_P3' "" $ DELETE 'NEW_P2' $ DELETE 'NEW_P3' $ EXIT 1 MX_ROOT:[SITE]CHANGE_P2_LIST.DAT: REPLACE "Reply-To: ";Reply-To: <> INSERT END; FIND 1 COPY "X-ListName:" to END EXIT MX_ROOT:[SITE]CHANGE_P2_NOLIST.DAT: FIND "Reply-To: " DELETE . INSERT .;Reply-To: <> EXIT MX_ROOT:[SITE]CHANGE_P2_NOREPLY.DAT: EXIT MX_ROOT:[SITE]CHANGE_P3.DAT: SUBSTITUTE/@FAX>/@ACTUAL_HOST.NIST.GOV>/ WHOLE /NOTYPE EXIT Yes, there are obvious bugs in it, but I have little sympathy for people who want EMail printed on their fax machines. It's a quick hack. - Jonathan ================================================================================ Archive-Date: Wed, 30 Mar 1994 18:39:45 CST Sender: owner-mx-list@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: RE: Mail headers Date: 30 Mar 1994 23:53:03 GMT Message-ID: <2nd3cv$539@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <30MAR199411224639@orion.cmc.uab.edu>, system@orion.cmc.uab.edu (Tim Buckner) writes: =Thanks for the follow up and the explanation... Now here's the rub: = =My system is a news reader and it posts through a machine that is out =of my influence. The controllers of the news server have requested =that the line either be removed or contain a valid contain a mailing =address. What do you suggest? Point them to RFC821, which is the authority on such matters, and which indicates that <> IS a valid path? -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Wed, 30 Mar 1994 18:41:45 CST Sender: owner-mx-list@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: RE: Mail headers Date: 31 Mar 1994 00:00:14 GMT Message-ID: <2nd3qe$539@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097C368.0E3CF4C0.27182@Data.Basix.COM>, "Ray Harwood -- Data Basix: (602)721-1988" writes: => #>My system is a news reader and it posts through a machine that is out => #>of my influence. The controllers of the news server have requested => #>that the line either be removed or contain a valid contain a mailing => #>address. What do you suggest? => => You could write a Site agent which strips the header. The Site agent could => all be in DCL and use TPU to strip the first Warnings-To: <> line. = =Excuse me, but now I'M confused. Are you actually POSTING to news using mail =which flows through MX? You're not using a newsreader of some sort? Perhaps he's using a news/mail gateway? -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Wed, 30 Mar 1994 18:42:26 CST Sender: owner-mx-list@WKUVX1.WKU.EDU From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) Subject: Re: LOCAL Daemon crashing Date: 30 Mar 1994 23:58:39 GMT Message-ID: <2nd3nf$539@gap.cco.caltech.edu> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <2ncbe3$3ba@anchor.cc.umb.edu>, kismet@trantor.cc.umb.edu (Ted Corning) writes: =Hi, = = I am running into a problem this morning with my LOCAL daemons crashing. = This has just started. The ONLY thing that has changed is that I have = removed EXQUOTA from the Local processes. Well, then it sounds like you're probably running out of disk quota, now doesn't it? = We are running MX V3.3, VAX/VMS V6.0, VAX 8800. The disk for the MX spool = area has Diskquotas disabled. Here is some more information: = = MX_LOCAL_GEMINI.LOG: = =30-MAR-1994 11:13:32.21: MX Local#2 (pid 00A245A7) starting =30-MAR-1994 11:50:16.79: MX Local#2 (pid 00A245A7) exiting, status = 10018294 Status %X10018294 is: %RMS-F-FNF, file not found = MX_LOCAL_LOG.LOG: = =30-MAR-1994 11:50:16.03 Processing queue entry number 16884 = = MCP QUE SHOW 16884/FULL: = =Entry: 16883, Origin unknown = Status: IN-PROGRESS, size: 717 bytes = Created: 30-MAR-1994 04:44:36.18, expires 29-APR-1994 04:44:36.18 = Last modified 30-MAR-1994 11:18:35.82 = LOCAL entry #16884, status: IN-PROGRESS, size: 717 bytes = Created: 30-MAR-1994 04:44:38.03, expires 29-APR-1994 04:44:36.18 = Last modified 30-MAR-1994 11:50:15.71 = [no LOCAL_INFO file for this entry] Sounds like maybe the LOCAL process was unable to create the LOCAL_INFO file? = $ dir mx_root:[queue.4..]*688*.* = %DIRECT-W-NOFILES, no files found Sounds even more like the LOCAL process couldn't create a file. = I am wondering if this could be caused by messages that are going to = multiple users, and only one has a quota problem. Would the queue file = be deleted but the entry stay in the queue file for later processing? "Deleted?" How about "Never created." You left out one important piece of information: The disk quota listing for the account under which the LOCAL process is running, on the disk that holds the queue directory. Chances are you'll find that that account is over disk quota. Either give it back EXQUOTA, or increase the disk quota on the disk holding the queue directories. The above is just a guess, but you really ought to check the quotas on the disk in question. -------------------------------------------------------------------------------- Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL Disclaimer: Hey, I understand VAXen and VMS. That's what I get paid for. My understanding of astronomy is purely at the amateur level (or below). So unless what I'm saying is directly related to VAX/VMS, don't hold me or my organization responsible for it. If it IS related to VAX/VMS, you can try to hold me responsible for it, but my organization had nothing to do with it. ================================================================================ Archive-Date: Wed, 30 Mar 1994 19:52:28 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Wed, 30 Mar 1994 13:01:23 PST From: robert@dis.ucsf.edu Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-LIST@WKUVX1.WKU.EDU Message-ID: <0097C355.5A0AC200.9517@dis.ucsf.edu> Subject: FROM headers on listserv messages I subscribe to several listserv mailing lists. Usually the incoming mail has the list address in the FROM: header. But sometimes the FROM: address is the sender's address. I've written to the manager of one of these lists about this and he thinks the problem is on my end. Here's a sample header. Usually the From: address would be fundlist@jhuvm so that when I reply the response goes to the entire list. Does anyone know if this is something I can correct? Robert Weiner Manager, Development Information Systems robert@dis.ucsf.edu University of California, San Francisco > From: MX%"PKASSOVER@cc.colorado.edu" 25-MAR-1994 10:54:41.45 > To: ROBERT > CC: > Subj: Development Services staffing > > Return-Path: <@UCCVMA.UCOP.EDU:owner-fundlist@JHUVM.HCF.JHU.EDU> > Received: from uccvma.ucop.edu by DIS.UCSF.EDU (MX V3.3 VAX) with SMTP; Fri, 25 > Mar 1994 10:54:37 PST > Received: from UCCVMA.UCOP.EDU by uccvma.ucop.edu (IBM VM SMTP V2R2) with BSMTP > id 4839; Fri, 25 Mar 94 10:54:32 PST > Received: from UCCVMA.UCOP.EDU (NJE origin LISTSERV@UCCVMA) by UCCVMA.UCOP.EDU > (LMail V1.1d/1.7f) with BSMTP id 2962; Fri, 25 Mar 1994 10:54:32 -0800 > Date: Fri, 25 Mar 1994 11:24:27 -0700 > Reply-To: PKASSOVER@cc.colorado.edu > Sender: "List for the discussion of university fund raising issues." > > From: pkassover@CC.COLORADO.EDU > Subject: Development Services staffing > X-To: fundlist%jhuvm.bitnet@cc.colorado.edu > To: Multiple recipients of list FUNDLIST > ================================================================================ Archive-Date: Thu, 31 Mar 1994 06:53:47 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Thu, 31 Mar 1994 06:53:36 EST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097C3EB.23715141.8@ALPHA.WKU.EDU> Subject: RE: FROM headers on listserv messages robert@dis.ucsf.edu writes: > >I subscribe to several listserv mailing lists. Usually the incoming >mail has the list address in the FROM: header. But sometimes the >FROM: address is the sender's address. I've written to the manager of >one of these lists about this and he thinks the problem is on my end. > He's wrong. >Here's a sample header. Usually the From: address would be fundlist@jhuvm >so that when I reply the response goes to the entire list. > >Does anyone know if this is something I can correct? > No. This happens on the DECTEI-L list a lot too. >> From: MX%"PKASSOVER@cc.colorado.edu" 25-MAR-1994 10:54:41.45 [...] >> Reply-To: PKASSOVER@cc.colorado.edu >> Sender: "List for the discussion of university fund raising issues." >> >> From: pkassover@CC.COLORADO.EDU >> Subject: Development Services staffing >> X-To: fundlist%jhuvm.bitnet@cc.colorado.edu >> To: Multiple recipients of list FUNDLIST >> As you can see, both the Reply-To: and From: lines have PKASSOVER's address. MX is just doing what it was told to do. For whatever reason, the sending system isn't setting the Reply-To: correctly for some messages. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Thu, 31 Mar 1994 07:24:57 CST Sender: owner-mx-list@WKUVX1.WKU.EDU From: system@orion.cmc.uab.edu (Tim Buckner) Subject: RE: Mail headers Message-ID: <31MAR199406492651@orion.cmc.uab.edu> Reply-To: MX-List@WKUVX1.WKU.EDU Date: Thu, 31 Mar 1994 12:49:00 GMT To: MX-List@WKUVX1.WKU.EDU In article <0097C368.0E3CF4C0.27182@Data.Basix.COM>, "Ray Harwood -- Data Basix: (602)721-1988" writes... >> #>My system is a news reader and it posts through a machine that is out >> #>of my influence. The controllers of the news server have requested >> #>that the line either be removed or contain a valid contain a mailing >> #>address. What do you suggest? >> >> You could write a Site agent which strips the header. The Site agent could >> all be in DCL and use TPU to strip the first Warnings-To: <> line. > >Excuse me, but now I'M confused. Are you actually POSTING to news using mail >which flows through MX? You're not using a newsreader of some sort? My apologies if my problem statement was unclear. Basically, I am using MX 3.3, MX_POST, MULTINET 3.2D, VMS 5.4-2, and VNEWS 1.41 in an attempt to set up a bi-directional news<->mail gateway. The mail->news direction has a header, Warnings-To: <>, that disturbs the people who control the machine that serves me news. I was trying to find out where the header was added, why was the header there, how the header could be deleted, whether or not the header should be deleted, and whether or not the header contains a valid address. Hunter supplied the info of where it comes from and why it is there. Dan and Jonathan suggested that I use site-agent to strip the header. Carl pointed out that RFC821 allows <> as a valid path. Thanks to each of you for your help, -- Tim Buckner - system@orion.cmc.uab.edu - buckner@topaz.decus.org -- Univ. Alabama at Birmingham Center for Macromolecular Crystallography 261 BHSB, Birmingham, AL 35294-0005 USA phone/fax:(205)934-1973/-0480 Disclaimer:IMHO, this isn't the HO of my employer and maybe not my HO. ================================================================================ Archive-Date: Thu, 31 Mar 1994 10:53:31 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Thu, 31 Mar 1994 10:43:19 EST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: bed_gdg@SHSU.edu CC: mx-list@wkuvx1.wku.edu Message-ID: <0097C40B.3AC01FC4.30@ALPHA.WKU.EDU> Subject: RE: A "Really Needed" enhancement "George D. Greenwade" writes: > >I know that MX 4.0 is either ready of nearly ready, but here is one >suggestion that I would LOVE to add to any fix list -- if someone can figure >out a patch to achieve this I would LOVE to see it ASAP. > >In defining lists, under MX 3.3 at least, you can use /strip_headers to >remove or not remove Received: fields. This is nice, but...... One item I >would LOVE to be able to strip is the da*n: >> X-pmrqc: 1 >created by Pegasus Mail requesting receipt notification (I am pretty sure [...] >If this were a strip'pable header, I think things would be a lot nicer. > This is already in MX V4.0. I did this several months ago, in fact. 8-) (MCP MODIFY LIST/STRIP=OTHER) MX V4.0 should be ready tomorrow, barring disaster today. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Thu, 31 Mar 1994 10:54:23 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Thu, 31 Mar 1994 10:21:13 CST From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.WKU.EDU To: mx-list@wkuvx1.wku.edu, goathunter@alpha.wku.edu Message-ID: <0097C408.24C85400.15523@SHSU.edu> Subject: A "Really Needed" enhancement I know that MX 4.0 is either ready of nearly ready, but here is one suggestion that I would LOVE to add to any fix list -- if someone can figure out a patch to achieve this I would LOVE to see it ASAP. In defining lists, under MX 3.3 at least, you can use /strip_headers to remove or not remove Received: fields. This is nice, but...... One item I would LOVE to be able to strip is the da*n: > X-pmrqc: 1 created by Pegasus Mail requesting receipt notification (I am pretty sure this is the trigger it includes and acts upon when receipt notification is requested by the sender). In the wondrous minds of the people who designed Pegasus Mail, the notification is sent to whatever is in the Reply-To: field (which is not consistent with RFC822 by my reading of it, but somewhat beside the point) instead of any field MX includes for automated notification purposes (consistent with RFC822, but beyond the marvelously simplistic proprietary minds of the PMail people). When running a list where the Reply-To: points to the list (such as MX-List), you can be inundated with all kinds of information about who read what when; as a list owner, you can then be inundated by mail from others wanting to know why you let this junk get to them. In short, a pain in the butt, a waste of bandwidth, and a shame thhat someone actually spent money to buy something along the lines of this miscreant mailer software used on quite a few LANs. As list owner, I would be willing to accept the notifications (which I would have to, if PMail did its job properly); however, I hate to have this trivial bull propagated to everyone on a list. If this were a strip'pable header, I think things would be a lot nicer. Regards, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Internet: bed_gdg@SHSU.edu Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 Sam Houston State University FAX: (409) 294-3612 Huntsville, TX 77341-2118 USA %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ================================================================================ Archive-Date: Thu, 31 Mar 1994 15:26:27 CST Sender: owner-mx-list@WKUVX1.WKU.EDU From: sharpe@tol-ed.com (Rick Sharpe) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Problem with MX 3.3 Message-ID: <1994Mar31.095132.4772@tol-ed.com> Date: 31 Mar 94 09:51:32 EST To: MX-List@WKUVX1.WKU.EDU I'm having a problem with MX V3.3 that I can't figure out. All the files in the [MX.QUEUE.*] directories are staying around forever (or at least until I delete them manually). I've been through the documentation several times and can't see why this should happen, looking at the queue shows no messages in the queue but all these files from days ago are still around. Does anyone have an idea what could be going on here? Or at least where I should look next? Rick sharpe@tol-ed.com ================================================================================ Archive-Date: Thu, 31 Mar 1994 16:55:48 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Thu, 31 Mar 1994 16:55:07 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097C43F.2B7D0A2F.11@ALPHA.WKU.EDU> Subject: RE: Help suppress/modify mail header kamrul@ycvax.york.cuny.edu writes: > >Hi there: > >We are using MX 3.3 and VMS 5.5 . The Return-Path, Errors-To and Sender >fields in the header of any mail posted through a list contain the owner's >address. Is there any way to modify and/or suppress these three fields? >If it is expained in any manual, please tell me where to look for. > Return-Path and Sender have to be there, as per RFC822. Errors-To is a non-RFC822 header used by a lot of mailers, so MX supplies it. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Thu, 31 Mar 1994 16:58:23 CST Sender: owner-mx-list@WKUVX1.WKU.EDU Date: Thu, 31 Mar 1994 16:57:21 CST From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU Message-ID: <0097C43F.7B8E811F.13@ALPHA.WKU.EDU> Subject: Re: MX-LIST Digest V94 #60 gilliam@alpha.hendrix.edu (Dan Gilliam) writes: > >Do similar problems exist with MUP03 for VAX? Since we installed it over >VMS 5.5-2, we've had a lot of problems with our SMTP service. > >We have 20 or so people using Eudora for the Mac, which sends and receives >e-mail via POP3 and SMTP servers on our VAX. When you attempt to send mail, >Eudora can't connect to the SMTP server, unless the MX processes have just >been stopped and restarted. > >Doing a "telnet localhost 25" from the VAX to connect directly to the SMTP >server works occasionally, but at times is very slow. At other times, the >telnet returns a "connect to network object refused". > >Has anyone seen this behavior? > No, but it sounds like it *could* be a TCP/IP issue, not an MX issue. What TCP/IP software are you using? Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@ALPHA.WKU.EDU (or goathunter@WKUVX1.BITNET) ================================================================================ Archive-Date: Thu, 31 Mar 1994 17:15:56 CST Sender: owner-mx-list@WKUVX1.WKU.EDU From: eric@segate.sunet.se (Eric Thomas) Subject: RE: FROM headers on listserv messages Date: 1 Apr 94 01:04:02 WET Message-ID: <1994Apr1.010402.1@segate.sunet.se> Reply-To: MX-List@WKUVX1.WKU.EDU To: MX-List@WKUVX1.WKU.EDU In article <0097C3EB.23715141.8@ALPHA.WKU.EDU>, "Hunter Goatley, WKU" writes: > As you can see, both the Reply-To: and From: lines have PKASSOVER's > address. MX is just doing what it was told to do. For whatever > reason, the sending system isn't setting the Reply-To: correctly for > some messages. Some people just like having a 'Reply-To:' pointing to one of their other accounts, usually because their official address is delivered through a slow campus mail server. It can be very annoying but there is no way for LISTSERV to know why the user decided to set a particular 'Reply-To:' address. Eric ================================================================================ Archive-Date: Thu, 31 Mar 1994 23:52:40 CST Sender: owner-mx-list@WKUVX1.WKU.EDU MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Mar 1994 23:54:34 -0600 To: MX-List@WKUVX1.WKU.EDU From: gilliam@alpha.hendrix.edu (Dan Gilliam) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: Eudora problem (seemingly resolved) Re our problems with Eudora and SMTP service in general - Hunter, we're using UCX 2.0D and MX 3.0 (yes, I know we're several upgrades behind :-)). But the problem seems to have gotten a lot better. I had set the DISMAIL flag on a user's account, and the person in question gets a lot of incoming mailing list traffic. It looks like we were just overloaded with bouncing messages and automated responses. I re-enabled mail for the user, then followed the "Tuning MX" instructions to increase # of STMP server threads to 8 and add a second outgoing SMTP process, and everything seems to be working. Dan ------------ Dan Gilliam Asst. Director, Computer Services Hendrix College (501) 450-1340 ================================================================================ Archive-Date: Thu, 31 Mar 1994 23:55:08 CST Sender: owner-mx-list@WKUVX1.WKU.EDU MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Mar 1994 23:56:51 -0600 To: MX-List@WKUVX1.WKU.EDU From: gilliam@alpha.hendrix.edu (Dan Gilliam) Reply-To: MX-List@WKUVX1.WKU.EDU Subject: How long should e-mail take to arrive? Can anyone give me a ballpark figure for how long delivery of an e-mail message to another site ought to take, on average? If a user tells me "It took an hour for my message to get to so-and-so", should I care? I realize this may be a difficult question to answer precisely. Dan ------------ Dan Gilliam Asst. Director, Computer Services Hendrix College (501) 450-1340