Archive-Date: Thu, 01 Oct 1992 00:11:10 CDT Sender: goathunter@WKUVX1.BITNET Date: Thu, 01 Oct 1992 00:05:02 CDT From: "Hunter Goatley, WKU" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <009616A5.9A7B86C0.5541@WKUVX1.BITNET> Subject: MX-LIST Administrivia: Monthly Post Last modified: 2-JUL-1992 00:40 01:26 (Created) Welcome to MX-List@WKUVX1.BITNET, an electronic mailing list established for the discussion of the Message Exchange mail software. This is a routine posting you will see from time to time on MX-List. The MX-List archives are maintained at ARCHIVES@WKUVX1.BITNET. To get a copy of any month's postings, send an e-mail message with the body SEND MX-List.yyyy-mm to ARCHIVES@WKUVX1.BITNET, where "yyyy" is the year and "mm" is the numeric representation of the month. For example, the message SENDME MX-List.1992-04 will send the archives for April 1992. To remove yourself from the mailing list, send the following command to LISTSERV@WKUVX1.BITNET: SIGNOFF MX-List LISTSERV supports a few other commands for your convenience. The following commands can be handled automatically by the list processor: SIGNOFF MX-List - to remove yourself from the list REVIEW MX-List - to get a list of subscribers QUERY MX-List - to get the status of your entry on the list SET MX-List NOMAIL - to remain on the list but not receive mail SET MX-List MAIL - to resume receiving mail from the list SET MX-List CONCEAL - to not report your address in a REVIEW SET MX-List NOCONCEAL - to report your address in a REVIEW SET MX-List REPRO - to receive posts you make to MX-List SET MX-List NOREPRO - to not receive posts you make to MX-List LIST - to get a list of mailing lists served by WKUVX1 HELP - to receive a help file By default, subscriptions are set to MAIL, REPRO, NOCONCEAL. If you have any questions, comments, or suggestions about MX-List, please contact the list owner at the address below. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Hunter Goatley, VAX Systems Programmer goathunter@WKUVX1.BITNET Western Kentucky University Academic Computing, STH 226 (502) 745-5251 Bowling Green, KY 42101 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ================================================================================ Archive-Date: Thu, 01 Oct 1992 10:58:54 CDT Date: Thu, 01 Oct 1992 08:59:01 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <009616F0.3364BB00.10096@swdev.si.com> Subject: Re: MX headers and mail logical names. Matt Madison (madison@tgv.com) writes: >VMS Mail does). If you defined EWG as > > $ DEFINE EWG "Jon","Jim","Kent","Paul" > >you should get the correct results. Looks like VMS Mail automatically >deals with the comma-separated list, whereas MX_MAILSHR does not. Looks >like MX_MAILSHR needs some additional code to handle this. Thanks for the suggestion, Matt. However, it didn't work. Apparently Mail can't handle search lists, either. This appears to be a basic mail problem, too, not am MX problem. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 01 Oct 1992 12:18:27 CDT Date: Thu, 01 Oct 1992 12:52:52 EDT From: murphy@hal.hahnemann.edu Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00961710.DE9942A0.14406@hal.hahnemann.edu> Subject: Re: MX headers and mail logical names. In a previous article, wrote: >Matt Madison (madison@tgv.com) writes: > >>VMS Mail does). If you defined EWG as >> >> $ DEFINE EWG "Jon","Jim","Kent","Paul" >> >>you should get the correct results. Looks like VMS Mail automatically >>deals with the comma-separated list, whereas MX_MAILSHR does not. Looks >>like MX_MAILSHR needs some additional code to handle this. > >Thanks for the suggestion, Matt. However, it didn't work. Apparently Mail >can't handle search lists, either. This appears to be a basic mail problem, >too, not am MX problem. > An alternate solution would be to create a distribution list file EWG.DIS containing: Jon Jim Kent Paul and defining EWG as: $DEFINE EWG "@EWG.DIS" Since messages to these individuals are routed through MX, it should produce a message on the recipients' end(s) with a complete address for each of the addressees. Regards, John ----------------------------------------------------------------------------- |John Murphy (JM66) |Internet: murphy@hal.hahnemann.edu / / / /|Library System Manager |VMS Mail: HAL::MURPHY /---/ / / |Hahnemann University |Beeper #: 1864 / / /___/ |245 N. 15th St., MS 449 |Voice: (215) 762-1042 |Phila., PA 19102-1192 |Fax: (215) 762-8180 ----------------------------------------------------------------------------- "It's a small world, but I wouldn't want to have to paint it" - Steve Wright ================================================================================ Archive-Date: Thu, 01 Oct 1992 15:01:05 CDT Date: Thu, 01 Oct 1992 13:59:39 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: murphy@hal.hahnemann.edu Message-ID: <0096171A.33307280.10363@swdev.si.com> Subject: Re: MX headers and mail logical names. John Murphy (murphy@hal.hahnemann.edu) writes: >An alternate solution would be to create a distribution list file EWG.DIS Yes, I know, and that's probably what I'll do. I was just trying to avoid another file on disk if I could. Thanks. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 01 Oct 1992 22:16:30 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: file server wish list item. Message-ID: <1992Oct1.175511.4610@dmc.com> Date: 1 Oct 92 17:55:11 EDT To: MX-List@WKUVX1.BITNET For the wish list. I wish the file server would accept a "path" statement so people who send out bogus addresses can provide a really replyable address. -- Dick Munroe Internet: munroe@dmc.com Doyle Munroe Consultants, Inc. UUCP: ...uunet!thehulk!munroe 267 Cox St. Office: (508) 568-1618 Hudson, Ma. FAX: (508) 562-1133 GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection. ================================================================================ Archive-Date: Fri, 02 Oct 1992 02:08:27 CDT Date: Fri, 2 Oct 92 02:53:34 -0400 Message-ID: <9210020653.AA07419@genrad.com> From: Reply-To: MX-List@WKUVX1.BITNET X-MX-Warning: Warning -- Invalid "To" header. To: "mx-list%wkuvx1.bitnet@ukcc.uky.edu" Subject: Re: Protocol errors between Vaxcluster? Shutting down and restarting UCX and MX on both clusters didn't clear this problem. Has anyone got any suggestions what's wrong, please? Every time I try a test message it works, but this list entry simply isn't being delivered. And the status entries don't seem to mean anything. 2-OCT-1992 07:52:43.41 Processing queue entry number 3666 on node CD4000 2-OCT-1992 07:52:43.65 Recipient: , route=CDCLU2 [...lines deleted...] 2-OCT-1992 07:52:43.66 Recipient: , route=CDCLU2 2-OCT-1992 07:52:43.66 SMTP_SEND: looking up host name CDCLU2 2-OCT-1992 07:52:43.80 SMTP_SEND: Attempting to start session with CDCLU2 [128.1.0.42] 2-OCT-1992 07:52:43.81 SMTP_SEND: Connected 2-OCT-1992 07:52:43.93 SMTP_SEND: Rcvd: 2-OCT-1992 07:52:44.07 SMTP send failed, sts=0C27804A, sts2=0C278042 2-OCT-1992 07:52:44.07 Recipient status=0C27804A for [...lines deleted...] 2-OCT-1992 07:52:44.07 Recipient status=0C27804A for 2-OCT-1992 07:52:44.62 16 rcpts need retry, next try 2-OCT-1992 08:22:44.62 2-OCT-1992 07:52:44.72 *** End of processing pass *** I think ther blank "Rcvd" line may be trying to tell me something; but every time I try "telnet cdclu2 25" from one one our Unix boxes, I get the identification banner, so the SMTP server seems to be working. Also is there some way to reset the timeout on a message? It's tedious to have to wait 20 minutes or so for the next retry after trying something to clear the problem. -------------------------------------------------------------------------------- Name : Derek Dongray, Systems Manager, GenRad Ltd. Phone : 061 486 1511 ext 166 InterNet : Dongray@GenRad.com UKnet : Derek.Dongray@GenRad.co.uk PSS : 234261600119::Dongray CompuServe : 70374,2745 Address : Monmouth House, Monmouth Road, Cheadle Hulme, Cheshire, SK8 7AY, UK. ================================================================================ Archive-Date: Fri, 02 Oct 1992 02:13:23 CDT Date: Fri, 2 Oct 92 03:06:58 -0400 Message-ID: <9210020706.AA08190@genrad.com> From: Reply-To: MX-List@WKUVX1.BITNET X-MX-Warning: Warning -- Invalid "To" header. To: "mx-list%wkuvx1.bitnet@ukcc.uky.edu" Subject: Re: Protocol errors between Vaxcluster? Skip the query about a retry command. I've realized that whaty I wanted was the QUEUE READY command specifying the (sub-)entry number of the specific transfer. (I'd previously tried using the 'main' entry number, which simply resent the message to all the poeple who'd already received it!). -------------------------------------------------------------------------------- Name : Derek Dongray, Systems Manager, GenRad Ltd. Phone : 061 486 1511 ext 166 InterNet : Dongray@GenRad.com UKnet : Derek.Dongray@GenRad.co.uk PSS : 234261600119::Dongray CompuServe : 70374,2745 Address : Monmouth House, Monmouth Road, Cheadle Hulme, Cheshire, SK8 7AY, UK. ================================================================================ Archive-Date: Fri, 02 Oct 1992 02:25:44 CDT Date: Fri, 2 Oct 92 03:10:23 -0400 Message-ID: <9210020710.AA08226@genrad.com> From: Reply-To: MX-List@WKUVX1.BITNET X-MX-Warning: Warning -- Invalid "To" header. To: "mx-list%wkuvx1.bitnet@ukcc.uky.edu" Subject: Re: Protocol errors between Vaxcluster? My problem must be something to do with timing; e.g. SMTP sever being swapped out and not waking up fast enough for the sender? I tried "telnet cdclu2 25" from an Ultrix machine and got ... dongray brandy>telnet cdclu2 25 Trying 128.1.0.42... Connected to cdclu2. Escape character is '^]'. Connection closed by foreign host. dongray brandy>^[ telnet cdclu2 25 Trying 128.1.0.42... Connected to cdclu2. Escape character is '^]'. 220 cd4201 MX V3.1C SMTP server ready at Fri, 02 Oct 1992 08:01:59 BST quit 221 cd4201 Service closing transmission channel. Connection closed by foreign host. I then ran MCP and issued a QUEUE READY command for the message which has been retrying for nearly two days... and it's now delivered it! Has anyone else seen this sort of problem? 2-OCT-1992 08:07:45.78 Processing queue entry number 3666 on node CD4000 2-OCT-1992 08:07:46.04 Recipient: , route=CDCLU2 [...lines deleted...] 2-OCT-1992 08:07:46.05 Recipient: , route=CDCLU2 2-OCT-1992 08:07:46.05 SMTP_SEND: looking up host name CDCLU2 2-OCT-1992 08:07:46.18 SMTP_SEND: Attempting to start session with CDCLU2 [128.1.0.42] 2-OCT-1992 08:07:46.20 SMTP_SEND: Connected 2-OCT-1992 08:07:47.04 SMTP_SEND: Rcvd: 220 cdmv22 MX V3.1C SMTP server ready at Fri, 02 Oct 1992 08:07:47 BST 2-OCT-1992 08:07:47.08 SMTP_SEND: Sent: HELO CD4000 2-OCT-1992 08:07:47.58 SMTP_SEND: Rcvd: 250 Hello, CD4000 2-OCT-1992 08:07:47.59 SMTP_SEND: Sent: MAIL FROM: 2-OCT-1992 08:07:47.84 SMTP_SEND: Rcvd: 250 MAIL command accepted. 2-OCT-1992 08:07:47.84 SMTP_SEND: Sent: RCPT TO: 2-OCT-1992 08:07:47.87 SMTP_SEND: Rcvd: 250 Recipient okay (at least in form) [...lines deleted...] 2-OCT-1992 08:07:48.36 SMTP_SEND: Sent: RCPT TO: 2-OCT-1992 08:07:48.39 SMTP_SEND: Rcvd: 250 Recipient okay (at least in form) 2-OCT-1992 08:07:48.48 SMTP_SEND: Sent: DATA 2-OCT-1992 08:07:49.38 SMTP_SEND: Rcvd: 354 Start mail input; end with . 2-OCT-1992 08:07:49.38 SMTP_SEND: Sent: Errors-To: system@cdclu1 2-OCT-1992 08:07:49.38 SMTP_SEND: Sent: X-ListName: Company Distribution List 2-OCT-1992 08:07:49.38 SMTP_SEND: Sent: Received: by cdclu1 (MX V3.1C) id 3662; Wed, 30 Sep 1992 10:00:23 BST 2-OCT-1992 08:07:49.38 SMTP_SEND: Sent: Date: Wed, 30 Sep 1992 10:00:16 BST [...lines deleted...] 2-OCT-1992 08:07:49.42 SMTP_SEND: Sent: . 2-OCT-1992 08:07:49.42 SMTP_SEND: will wait 00:18:00.00 for reply. 2-OCT-1992 08:07:51.22 SMTP_SEND: Rcvd: 250 Message received and queued. 2-OCT-1992 08:07:51.22 SMTP_SEND: Sent: QUIT 2-OCT-1992 08:07:51.25 SMTP_SEND: Rcvd: 221 cdmv22 Service closing transmission channel 2-OCT-1992 08:07:51.35 Recipient status=00000001 for [...lines deleted...] 2-OCT-1992 08:07:51.36 Recipient status=00000001 for 2-OCT-1992 08:07:51.46 Entry now completely processed, no retries needed. 2-OCT-1992 08:07:51.62 *** End of processing pass *** Of course, the log shows that it used a different node to receive the message from the one I 'woke up'. So my 'swapped-out' idea looks like a non-starter! I'd still like clues as to why this happens, as it isn't the first time and doubtless won't be the last! -------------------------------------------------------------------------------- Name : Derek Dongray, Systems Manager, GenRad Ltd. Phone : 061 486 1511 ext 166 InterNet : Dongray@GenRad.com UKnet : Derek.Dongray@GenRad.co.uk PSS : 234261600119::Dongray CompuServe : 70374,2745 Address : Monmouth House, Monmouth Road, Cheadle Hulme, Cheshire, SK8 7AY, UK. ================================================================================ Archive-Date: Fri, 02 Oct 1992 06:46:42 CDT Sender: goathunter@WKUVX1.BITNET Date: Fri, 02 Oct 1992 06:46:28 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <009617A6.D986D2A0.20641@WKUVX1.BITNET> Subject: RE: file server wish list item. writes: > >For the wish list. I wish the file server would accept a "path" statement so >people who send out bogus addresses can provide a really replyable address. >-- Since I run a very popular FILESERV, I know the feeling immensely. If we could get people to use it.... It's on the wish list now. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Fri, 02 Oct 1992 15:40:41 CDT Sender: mckeetr@cvse.cortex.prospect.com Date: Fri, 02 Oct 1992 12:16:42 EDT From: "Tim McKee, 803-366-2620" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: mckeetr@cvse.cortex.prospect.com Message-ID: <009617D4.FB8B14A0.126@cvse.cortex.prospect.com> Subject: ADDRESSING QUESTION Assuming I have the following configuration: node INTNET (the INTERNET link with domain name cortex.prospect.com) path "hq.cortex.prospect.com" DECNET_SMTP/route=CVMAIL ... some other path routings.... path * SMTP node CVMAIL (a node on the local network that is known internally by the name hq.cortex.prospect.com) path "hq.cortex.prospect.com" LOCAL ... some other path routings.... path * DECNET_SMTP/route=INTNET Everything works fine internally, but how does an outside user send mail to a user such as "user@hq.cortex.prospect.com" when the hq.cortex.prospect.com domain is unknown outside of the company network? Do I need some rewrite rules somewhere to accomplish this? signed: a neophyte ============================================== Timothy R. McKee Senior Consultant Cortex Corporation - SouthEast Field Office Phone: (803) 366-2620 FAX: (803) 366-5417 ================================================================================ Archive-Date: Fri, 02 Oct 1992 18:48:52 CDT From: sleight@venus.ycc.yale.edu Reply-To: MX-List@WKUVX1.BITNET Subject: Reply to an MX Message Message-ID: <1992Oct2.140315.1@venus.ycc.yale.edu> Sender: (USENET News System) Date: 2 Oct 92 14:03:15 EDT To: MX-List@WKUVX1.BITNET I recently installed MX 3.1C on some of our VAXStations, using UCX as the transport. A few of my users have complained that people from some sites trying to reply to their messages, sent out from here via MX, can't. What seems to happen is say a user has an address, user@node.university.edu, the reply-to that gets generated at other sites in some cases is just the address user@node. Is there something worng with my MX setup, or is this a problem at the remote sites this occurs at? Our machine that had UCX 2.0 SMTP did not generate these problems. We have removed UCX 2.0 SMTP, due to the numerous problems and bugs in it that were crashing our machines. -Jeff Sleight sleight@venus.ycc.yale.edu ================================================================================ Archive-Date: Fri, 02 Oct 1992 22:32:10 CDT From: daveh@vax.oxford.ac.uk Reply-To: MX-List@WKUVX1.BITNET Subject: Unexpected error message Message-ID: <1992Oct2.091518.9170@vax.oxford.ac.uk> Date: 2 Oct 92 08:15:18 GMT To: MX-List@WKUVX1.BITNET One of our users has been trying to send a mail message to vac+@cs.cmu.edu. We've got the mail patch installed so that you don't have to put the MX% in front of the address. The following error is produced: mail> send to: vac+@cs.cmu.edu no such user VAC error opening FS27:[DAVEH]CS.CMU as input - file not found no such user EDU Using MX%"vac+@cs.cmu.edu" seems to work, however. Can anybody explain the error messages? Dave -- David Hastings | "Imposition of order=escalation of chaos" VAX Systems Programmer | Oxford University Computing Services| "Just when you think you've won the daveh@vax.oxford.ac.uk | rat race, along come faster rats" ================================================================================ Archive-Date: Sat, 03 Oct 1992 18:25:29 CDT From: Subject: Re: Unexpected error message Date: 3 Oct 1992 22:43:23 GMT Message-ID: <1al7mbINNk87@gap.caltech.edu> References: <1992Oct2.091518.9170@vax.oxford.ac.uk> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <1992Oct2.091518.9170@vax.oxford.ac.uk>, daveh@vax.oxford.ac.uk writes: >One of our users has been trying to send a mail message to vac+@cs.cmu.edu. >We've got the mail patch installed so that you don't have to put the MX% in >front of the address. The following error is produced: > >mail> send >to: vac+@cs.cmu.edu > >no such user VAC >error opening FS27:[DAVEH]CS.CMU as input - file not found >no such user EDU > > >Using MX%"vac+@cs.cmu.edu" seems to work, however. Can anybody explain the >error messages? Yes. The CLI is parsing "+" as being equivalent to "," (try using a "+" in most DCL commands). So it's seeing the address as: vac,@cs.cmu.edu So it tries the first user, and you get the message: no such user VAC Now, the @ means it's supposed to look in a file. I'd've expected it to claim that "edu" is an invalid version number, but instead, it apparently treats cs.cmu. as the filespec, with the trailing dot treated as a ";". Trying an @file.ext.whatever confirms that this is normal behavior for MAIL. I assume that your default directory at the time you issued the command was FS27:[DAVE], so MAIL used FS27:[DAVE].DIS as the default filespec. After failing to open that file, you get the message: error opening FS27:[DAVEH]CS.CMU as input - file not found Now it's still got one last user, "edu" to deal with, which generates the message: no such user EDU -------------------------------------------------------------------------------- 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, 04 Oct 1992 07:32:12 CDT Date: Sun, 4 Oct 1992 12:12 +0300 From: SYSENG@BHUOB00.BITNET Reply-To: MX-List@WKUVX1.BITNET Subject: MX MAILER INFORMATIONS. To: MX-LIST@RPIECSVX.BITNET To MX MAILER Users, This is Nader Nasry, the VAX system engineer at University of Bahrain, our node ID is BHUOB00 in GULFNET connected to BITNET. We have VAX 8550 using VMS ver 5.4 and JNET ver 3.5. We are connected to Dahran to Ryadh to GWUVM etc. JNET does't accept Direct InterNet Domains then : 1. What is your way to contact InterNet Using MX MAILER ? 2. How can i get these Software ? Is It available in the Network ? explain your solution, thanks. *===============================***=====================================* * Best Regards, !*! * * UOB System Engineer !*! Tel.# : (973) 449204 * * Nader Nasry !*! Fax : (973) 441995 * * U.O.B. Computer Centre !*! E-Mail : SYSENG@BHUOB00 * * P.O.Box 32038, Sakheer !*! * * Bahrain !*! * *===============================***=====================================* ================================================================================ Archive-Date: Sun, 04 Oct 1992 22:26:10 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: Yet another mailing list wish list item. Message-ID: <1992Oct4.205824.4622@dmc.com> Date: 4 Oct 92 20:58:24 EDT To: MX-List@WKUVX1.BITNET I run a number of access controlled file servers. Right now, the only way I can get clients onto the access list is to enumerate all of them, e.g.: a@foo.bar b@foo.bar ... It would be way cool if it was possible to have an entry in a mailing list that was an "authorization" entry and took wild cards, e.g.: *@foo.bar Any client sending from foo.bar there would probably be other useful combinations, but this is the one I would have most user for. Such entries would not enter into the normal mail distribution associated with mailing lists. Dick MUnroe -- Dick Munroe Internet: munroe@dmc.com Doyle Munroe Consultants, Inc. UUCP: ...uunet!thehulk!munroe 267 Cox St. Office: (508) 568-1618 Hudson, Ma. FAX: (508) 562-1133 GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection. ================================================================================ Archive-Date: Mon, 05 Oct 1992 00:06:37 CDT Date: Mon, 05 Oct 1992 01:02:53 EDT From: "Jonathan E. Hardis" Reply-To: MX-List@WKUVX1.BITNET Subject: RE: Reply to an MX Message To: MX-List@WKUVX1.BITNET CC: sleight@venus.ycc.yale.edu, hardis@vax844.phy.nist.gov Message-ID: <009619D2.59432E80.5135@vax844.phy.nist.gov> > I recently installed MX 3.1C on some of our VAXStations, using UCX as the > transport. ... What [happens] is, say, a user has an address > user@node.university.edu, the reply-to that gets generated at other sites > in some cases is just the address user@node. Is there something wrong with > my MX setup, or is this a problem at the remote sites this occurs at? The problem is at your end, with UCX (rather than MX). This is a FAQ: | I believe you've bumped into a known problem with UCX. The |documentation suggests that the hosts file be set up with alias first and |then the FQDN. You need to set up the hosts file so that the FQDN is |first, followed by any aliases. | |************************************************************************* |* * |* Here, there be dragons! * |* dragon@nscvax.princeton.edu * |* * |* Richard B. Gilbert * |************************************************************************* ================================================================================ Archive-Date: Mon, 05 Oct 1992 01:45:42 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: inhomogeneous cluster? Date: 5 Oct 1992 01:26:38 GMT Message-ID: <1ao5keINNr45@gap.caltech.edu> Keywords: mx,cluster,inhomogeneous To: MX-List@WKUVX1.BITNET I am just installing MX on a vaxcluster, one of whose nodes violates the condition for a homogeneous MX-cluster in that it has its own UAF. Has anyone done this, and if so could you advise me what files need to be specific to that node? The manual seems pretty clear on homogeneous clusters, but this is not my situation. Stanley J. McCaslin mccaslin@alumni.caltech.edu or mccaslin@pscvax.peru.edu (when I get it working) ================================================================================ Archive-Date: Mon, 05 Oct 1992 07:46:39 CDT Date: Mon, 5 Oct 92 13:21+0100 To: Message Exchange Discussion List CC: mccaslin@cco.caltech.EDU, "Stanley J. McCaslin" Subject: RE: inhomogeneous cluster? From: Rok Vidmar Reply-To: MX-List@WKUVX1.BITNET Message-ID: <100*rok.vidmar@uni-lj.SI> > I am just installing MX on a vaxcluster, one of whose nodes > violates the condition for a homogeneous MX-cluster in that > it has its own UAF. Has anyone done this, and if so could you > advise me what files need to be specific to that node? The > manual seems pretty clear on homogeneous clusters, but this > is not my situation. I did it this way: - node has its own UAF *and* VMSMAIL_PROFILE.DATA, - node's DECnet executor has Alias incomming disabeled, - node's MX routes nonlocal mail to cluster using DECnet SMTP, - cluster MX routes mail for node using DECnet SMTP. DECnet SMTP, btw, is all node's MX can speak. Regards, Rok Vidmar x.400: S=vidmar;G=rok;O=uni-lj;P=ac;A=mail;C=si UCC, University of Ljubljana inet: rok.vidmar@uni-lj.si Kardeljeva pl. 17 phone: +38 61 183579 61000 Ljubljana fax: +38 61 183534 Slovenia ================================================================================ Archive-Date: Mon, 05 Oct 1992 11:52:22 CDT From: Subject: Re: inhomogeneous cluster? Message-ID: <1992Oct5.162609.11088@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <1ao5keINNr45@gap.caltech.edu> Date: Mon, 5 Oct 1992 16:26:09 GMT To: MX-List@WKUVX1.BITNET In article <1ao5keINNr45@gap.caltech.edu>, mccaslin@cco.caltech.edu (Stanley John McCaslin) writes: >I am just installing MX on a vaxcluster, one of whose nodes >violates the condition for a homogeneous MX-cluster in that >it has its own UAF. Has anyone done this, and if so could you >advise me what files need to be specific to that node? The >manual seems pretty clear on homogeneous clusters, but this >is not my situation. The reason it's not clear in the heterogeneous case is because there are many differing levels of heterogeneity. If you have a different UAF, but you keep the usernames and UIC's the same as in your main sub-cluster, and you still share the same VMSMAIL_PROFILE.DATA file, and you share the same disk space, you can probably treat the cluster as homogeneous -- just don't run any of the MX processing agents (or at least not the Router and Local delivery agents) on the heterogeneous node. The easiest thing to do in the completely heterogeneous case (separate UAF, separate VMSMAIL_PROFILE.DATA, different user base entirely) is to install MX separately on the heterogeneous node, give it an "MX Cluster Name" that is different from the main sub-cluster, and make sure it also has a different "MX Network Host Name" from the main sub-cluster. What you do for an in-between case will depend on how heterogeneous your cluster is. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Mon, 05 Oct 1992 21:36:02 CDT From: daveh@vax.oxford.ac.uk Reply-To: MX-List@WKUVX1.BITNET Subject: Entries with size 0 in MX queue Message-ID: <1992Oct5.150035.9219@vax.oxford.ac.uk> Date: 5 Oct 92 14:00:35 GMT To: MX-List@WKUVX1.BITNET Does anybody know why we keep getting entries like the following in our MX message queue? They seem to go away eventually, but I would like to know what they are. Entry: 18523, Origin: [code=0] Status: IN-PROGRESS, size: 0 bytes Created: 1-OCT-1992 22:41:59.85, expires 31-OCT-1992 22:41:59.85 Last modified 1-OCT-1992 22:41:59.85 Recipient #1: Entry: 25486, Origin unknown Status: IN-PROGRESS, size: 0 bytes Created: 5-OCT-1992 09:22:42.36, expires 4-NOV-1992 09:22:42.36 Last modified 5-OCT-1992 09:22:42.36 Thanks, Dave -- David Hastings | "Imposition of order=escalation of chaos" VAX Systems Programmer | Oxford University Computing Services| "Just when you think you've won the daveh@vax.oxford.ac.uk | rat race, along come faster rats" ================================================================================ Archive-Date: Mon, 05 Oct 1992 21:49:42 CDT Sender: goathunter@WKUVX1.BITNET Date: Mon, 05 Oct 1992 21:47:13 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: daveh@vax.oxford.ac.uk Message-ID: <00961A80.2DCDDA80.21303@WKUVX1.BITNET> Subject: RE: Entries with size 0 in MX queue daveh@vax.oxford.ac.uk writes: > >Does anybody know why we keep getting entries like the following in our MX >message queue? They seem to go away eventually, but I would like to know what >they are. > >Entry: 18523, Origin: [code=0] > Status: IN-PROGRESS, size: 0 bytes > Created: 1-OCT-1992 22:41:59.85, expires 31-OCT-1992 22:41:59.85 > Last modified 1-OCT-1992 22:41:59.85 > Recipient #1: > [...] These are left whenever a user aborts a message. For example, if a user enters an MX "To:" address, but then QUITs out of the editor or types ^C to cancel the message, the 0-byte entry is left in the MX queue. The entries were made as soon as the "To:" address was processed. MX is not called again after the user cancels the message, hence the left-over queue entry. They go away when the expiration date is reached or when you issue an MCP QUEUE CANCEL command. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Tue, 06 Oct 1992 06:36:54 CDT Date: Tue, 06 Oct 1992 07:32:56 EDT From: John Hasstedt Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00961AD2.009F69A0.6679@nuclear.physics.sunysb.edu> Subject: Multinet 3.1 I recently received Multinet V3.1. Has anyone installed it with V3.1C of MX? The release notes say user-written dispatchers may need to be modified. Does MX use a user-written dispatcher? The socket library is compatible with previous releases. ========================================================================== John Hasstedt BITNET: MANAGER@SUNYSBNP Physics Department Internet: John.Hasstedt@sunysb.edu State University of New York HEPNET: SBNUC::MANAGER or 44145::MANAGER Stony Brook, NY 11794-3800 Phone: 516-632-8154 FAX: 516-632-8573 ================================================================================ Archive-Date: Tue, 06 Oct 1992 12:08:11 CDT Sender: p_rand@luke.spu.edu Date: Tue, 06 Oct 1992 10:06:48 EDT From: "Phil Rand, Computer Services, 281-2428" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00961AE7.7FC54280.4503@luke.spu.edu> Subject: Patch, what patch? daveh@vax.oxford.ac.uk writes in <1992Oct2.091518.9170@vax.oxford.ac.uk>: > We've got the mail patch installed so that you don't have to put the MX% in > front of the address. What patch is this? Where can I find it, and what are the pros and cons of installing it? Any comments would be appreciated. --Phil ----------------------------------------------------------------------- Phil Rand, Computer & Information Systems, Seattle Pacific University 3307 3rd Ave W, Seattle, WA 98119 p_rand@spu.edu (206) 281-2428 ----------------------------------------------------------------------- ================================================================================ Archive-Date: Tue, 06 Oct 1992 13:56:42 CDT Date: 06 Oct 1992 12:45:28 -0600 (MDT) From: Dan Wing Reply-To: MX-List@WKUVX1.BITNET Subject: Re: Patch, what patch? To: MX-List@WKUVX1.BITNET CC: p_rand@spu.edu Message-ID: <01GPMNBKWLQA00008Z@VAXF.COLORADO.EDU> Phil Rand, , from the "rain capital of the world" (otherwise known as The Evergreen State), writes: >daveh@vax.oxford.ac.uk writes in > <1992Oct2.091518.9170@vax.oxford.ac.uk>: > >> We've got the mail patch installed so that you don't have to put the MX% in >> front of the address. > >What patch is this? Where can I find it, and what are the pros and cons >of installing it? Any comments would be appreciated. MX_ROOT:[CONTRIB]VMSMAIL_PATCH.TXT -Dan Wing, DWING@UH01.Colorado.EDU or WING_D@UCOLMCC.BITNET (DGW11) Systems Programmer, University Hospital, Denver (A former resident of WA State. Sorry, couldn't resist! ) ================================================================================ Archive-Date: Tue, 06 Oct 1992 14:20:25 CDT From: Subject: RE: Entries with size 0 in MX queue Message-ID: <1992Oct6.173406.8239@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <00961A80.2DCDDA80.21303@WKUVX1.BITNET> Date: Tue, 6 Oct 1992 17:34:06 GMT To: MX-List@WKUVX1.BITNET In article <00961A80.2DCDDA80.21303@WKUVX1.BITNET>, Hunter Goatley writes: >>Does anybody know why we keep getting entries like the following in our MX >>message queue? They seem to go away eventually, but I would like to know what >>they are. >> >>Entry: 18523, Origin: [code=0] >> Status: IN-PROGRESS, size: 0 bytes >> Created: 1-OCT-1992 22:41:59.85, expires 31-OCT-1992 22:41:59.85 >> Last modified 1-OCT-1992 22:41:59.85 >> Recipient #1: >> >[...] >These are left whenever a user aborts a message. For example, if a >user enters an MX "To:" address, but then QUITs out of the editor or >types ^C to cancel the message, the 0-byte entry is left in the MX >queue. The entries were made as soon as the "To:" address was >processed. MX is not called again after the user cancels the message, >hence the left-over queue entry. They go away when the expiration >date is reached or when you issue an MCP QUEUE CANCEL command. Under normal circumstances, cancelling a message in VMS Mail should result in a zero-length queue entry with status = CANCELLED. A zero-length entry with status = IN-PROGRESS probably means that message entry was interrupted in a somewhat more violent nature (like the process was deleted or the system crashed). -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Tue, 06 Oct 1992 14:38:08 CDT Date: Tue, 6 Oct 92 11:35:49 -0700 Message-ID: <9210061835.AA21777@whistler.sfu.ca> Sender: randy@sfu.ca To: MX-List@WKUVX1.BITNET From: Randy_Raine@sfu.ca Reply-To: MX-List@WKUVX1.BITNET Subject: Re: Patch, what patch? >daveh@vax.oxford.ac.uk writes in > <1992Oct2.091518.9170@vax.oxford.ac.uk>: > >> We've got the mail patch installed so that you don't have to put the MX% in >> front of the address. > >What patch is this? Where can I find it, and what are the pros and cons >of installing it? Any comments would be appreciated. > >--Phil > We have found it very useful in our environment. Our world here is all Unix except for the Administration systems which run on VMS (you have to be sure that some things work when you want them to -:). Using the patch eliminates the confusion users might have had with addresses. We have used it over a year now with no problems. We just had a VMS 5.5-1 upgrade, and I applied the patch to the new MAILSHR image. It still works just fine. I can send you a copy of the patch (if you have not already received several dozen). --- Randy Raine | Voice: (604) 291-4447 Computing Services | Fax: (604) 291-4242 Simon Fraser University | Internet: randy@sfu.ca Burnaby, B.C. V5A 1S6 | Bitnet: randy@SFUVAX.Bitnet ================================================================================ Archive-Date: Tue, 06 Oct 1992 15:22:40 CDT Sender: westerm@aclcb.purdue.edu Date: Tue, 06 Oct 1992 14:59:24 EDT From: Rick Westerman Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00961B10.5FD4B2C0.18672@bchm1.aclcb.purdue.edu> Subject: RE: Patch, what patch? !---------------------- MAILSHR_PATCH_FOR_AT_02.COM ----------------- MAILSHR.EXE ! ! Modifed Nov, 1990, RPW to replace IN%" with MX%" and to make the form ! user@system translate into mx%"user@system" instead of system::user ! ! This patch will be of interest to any VAX/VMS system (more especially if it ! is running PMDF) since it lets TO: or CC: addresses such as ! user%machine@site.co.org to be accepted without the IN% prefix and without ! surrounding double quotes. Yes, let's admit it, it lets VMS mail accept Un*x ! type addresses. In addition to its original goal, the format of this ! modification is also original by the fact of the straight macro code that ! can easily be modified/expanded or altered (ie IN% could become M_INTERNET:: ! in the case of most Schlumberger VMS nodes) ! If the address is "similar" (see algorithm below) to user%machine@site.co.org ! it is simply rewritten as IN%"user%machine@site.co.org" and passed along. ! At the same time, user@machine will be accepted and rewritten as machine::user ! If the IN% prefix is not the one in use on your VAX/VMS system, but XYZ% is, ! then all you have to do is $ DEFINE/SYSTEM/EXECUTIVE - ! MAIL$PROTOCOL_IN - ! XYZ_ROOT:[EXE]XYZ_MAILSHR ! or wherever the XYZ overlay for MAIL ! ! might be located and installed from ! ! See additional impact remarks below. ! ! This patch applies to SYS$LIBRARY:MAILSHR.EXE (usually SYS$COMMON:[SYSLIB]) ! from VMS 5.0 to Field Test version of 5.4 as of June 1990 ! ! We recommend: ! ! $ SET DEFAULT SYS$COMMON:[SYSLIB] ! $ INSTALL:= $INSTALL/COMMAND ! $ PATCH @ this_file.COM ! $ INSTALL REPLACE SYS$COMMON:[SYSLIB]MAILSHR.EXE ! ! Claude Barbe - Schlumberger-Doll Research - Ridgefield, CT - USA ! (Internet) barbe@sdr.slb.com (a happy hacker of MAIL and PMDF for over 3yr) ! ! 3-Jul-1990 ! ! No warranty implied. This can be freely copied and altered. Use it at ! your own risks. It is probably pure chance if it ever worked on a ! particular system. ! ! Additional remarks on the impact of this patch ! ! 1) With this patch in place we hope to make addressing unique in the VMS world ! whether a message is sent via DECnet or via a foreign protocol (such as ! the successful/affordable PMDF) without forcing any one to use prefixes ! and/or quotes. Quotes are to be avoided by all means since MAIL and DEC's ! MRGATE interface have no mechanisms to imbed quoted addresses between ! quotes (ie MRGATE and PMDF cannot carry the same message!) ! 2) There are risks of confusion for new users who will learn that the Un*x ! addressing format works on a patched VMS system and who will never bother ! to know the DEC way to send mail with double colons between node and ! username until they use a non patched VMS system ! 3) The patch will certainly break when DECnet node names will contain dots ! but this is in DECnet phase V and we still have to see a field test ! for this product. By that time a better patch will be developped or ! whatever foreign protocol is used (PMDF by default) will just handle ! these deliveries that could have gone also more simply across DECnet ! 4) The patch is far from being fully RFC822 compliant and there are risks ! that some users will be confused by the lack of completeness. This ! in some case will be due to the approach taken in this patch where, ! instead of redoing the address parsing that DEC is doing in MAIL, we ! simply hacked a string filter on a "DEC approved string" which has already ! been pruned of commas and exclamation points. Users familiar with "bang" ! addresses will still have to say IN%"node!node!user@relay.somewhere" ! 5) After a few extra weeks of testing on a larger scale, this patch will be ! submitted to DEC as an SPR for improvement. Hopefully, then DEC will ! support the de facto standard (or at least the most commonly used part ! of it). In the mean time let's try to let our users access Internet ! addresses in the most natural way. At last! ! ! Validity of this patch ! ! It has only been tested on VMS 5.3-1 but is expected to work on VMS 5.0 to 5.4 ! (well, 5.4 is not out yet, so at least up to T5.4-4). This part of the code ! is the same for all these versions of VMS 5, only the addresses changed after ! 5.0. For VMS 4.6/4.7, unfortunately the code was different and it was not ! found worth the effort to retrofit this patch for a version of VMS that was ! replaced 23 months ago. ! ! For VMS 5.0 only, uncomment the following 6 lines and comment another 6 lines ! below. ! ! If you patch, VMS 5.0, it is different from the following VMS versions ! MAIL$$ADD_ADDR is located at 000049C2 and ! ADD_ADDR is located at 000048EF ! then uncomment the following 6 lines and comment out 6 similar lines below !DEF !MAIL$$ADD_ADDR !000049C2 !ADD_ADDR !000048EF !EXI ! ! If you patch any versions from VMS 5.1 to T5.4-4 including 5.1 and 5.2, all ! appear to have identical MAIL$$ADD_ADDR always located at 000049D2 and ! calling ADD_ADDR always located at 000048FF ! For VMS 5.0 comment out the following 6 lines and uncomment 6 lines above ! DEF MAIL$$ADD_ADDR 000049D2 ADD_ADDR 000048FF EXI ! Now make sure that we have a patch area ! ALI/B PATAREA ! And now enter instruction mode ! SE M I EXI ! Start implementing the ALTER_TO subroutine ! It was first developped and tested as a MACRO-32 program ! and changed into the body of this patch.com file by ! a MACRO_TO_PATCH.COM procedure developped for that purpose DEP /PAT PATAREA !; ALTER_TO is called with the same 2 arguments used by !; MAIL$$SEND_ADD_ADDR in calling MAIL$$ADD_ADDR and will call !; ADD_ADDR itself with or without a rewrite. There is no rewrite !; if SYS$FAO fails. The original address is never modified and !; will still appear unmodified in the "published" TO: field. !; !; At this point when MAIL$$ADD_ADDR calls ALTER_TO, 4(AP) points !; to a string descriptor which MAIL has already parsed to be one !; of a single recipient (we don't have to look for commas or for !; an @ sign preceding a distribution list). Because of the !; location of this patch, floating/unquoted "!"s seem unlikely. !; !; The principle of this patch is to allow plain RFC addresses !; to be acceptable by mail. We never anticipated to fully deal !; with the full RFC822 format but simply to lrt forms such as !; user@site.org or user%machine@site.company.org with all atoms !; being alphanumerics and the whole address void of double quotes !; !; At the same time STRAIGHTFORWARD phase IV DECnet mail addresses !; are also allowed in an RFC822 like format: USERNAME@NODENAME !; is being transformed into NODENAME::USERNAME. Note well that !; the code will NOT transform any address with an "@" into !; a more complex DECnet mail address such as AAA::BBB::USER. !; !; The parsing is an adhoc scanning of the string looking for !; no more than one "@", checking the absence of " and for the !; A and B parts of A@B distinguish between A-Z,0-9,a-z,$,%,.,- !; and other characters (in case MAIL's parser would any slip thru) !; !; More exactly the algorithm is: !; !; input string might look like A@B with A and B containing no " !; if " or not A@B, pass the string to ADD_ADDR unchanged ! Case 1 !; else if A or B has any character not in A-Z,0-9,a-z,$,%,.,- !; pass IN%"A@B" ! Case 2 !; else !; if B has no dots (pure DECnet) pass B::A ! Case 3 !; else pass IN%"A@B" ! Case 2 !; 'alter_to: .word 7C ' ! ; entry mask save R2-R6 ' movq @B^4(ap),r0' ' movzwl r0,r0' ' clrl r2' 'cdblp1: cmpb #^x22,(r1)' ' beql cdbcs1' ' cmpb #^x40,(r1)+' ' beql cdbl1x' ' incl r2 ' ! ; length of A in A@B ' sobgtr r0,cdblp1' 'cdbcs1: movab @B^4(ap),r2' ' jmp cdbcom ' ! ; no changes - case 1 'cdbl1x: decl r0 ' ! ; count "@" ' bleq cdbcs1 ' ! ; branch if at end ' tstl r2' ' beql cdbcs1 ' ! ; branch if @B with no A ' clrl r3 ' ! ; now parse after "@" 'cdblp2: cmpb #^x22,(r1)' ' beql cdbcs1' ' cmpb #^x40,(r1)+' ' beql cdbcs1' ' incl r3 ' ! ; length of B in A@B ' sobgtr r0,cdblp2' !; passed test 1 - we have A@B - Now check A ' movq @B^4(ap),r0' !; allocate room on stack for 2 descriptors (for A and B) ' pushl r1' ' pushl r2' ' movl sp,r5 ' ! ; r5 points to desc(A) ' movl r2,r0' ' beql cdbcs1' ' jsb cdbck1' ' tstl r0' ' bneq cdbcs2' ' incl r1' ' pushl r1' ' pushl r3' ' movl sp,r6 ' ! ; r6 points to desc(B) ' movl r3,r0' ' beql cdbcs1' ' jsb cdbck1' ' tstl r0' ' beql cdbps2' ! ; build IN%"A@B" for case 2 !; use the stack this way for all $FAO !; outlen initial sp <- r3 <-r2 !; ptr to outbuf initial sp-264 <- r2 minus 8 !; ...... <- r2 to beg of ptr !; outbuf initial sp-4 <- r3 minus 4 !; ...... initial sp-256 <- sp 'cdbcs2: pushl #22534121 ' ! ; ctrstr #^A/!AS"/ ' pushl #2225584D ' ! ; ctrstr #^A/MX%"/ ' pushl sp ' ! ; make desc to ctrstr ' pushl #8 ' ! ; make desc to ctrstr ' movl sp,r4 ' ! ; address of desc to ctrstr ' subl #4,sp ' ! ; adjusted stack ' movl sp,r3 ' ! ; save stack for outlen ' movl sp,r2 ' ! ; end of desc to outbuf ' subl #108,sp ' ! ; end of outbuf ' movl sp,-(r2) ' ! ; make outbuf ' movzwl #100,-(r2) ' ! ; make outbuf ' pushl B^4(AP) ' ! ; #4 P1 pass what we got ' pushl r2 ' ! ; #3 outbuf ' pushl r3 ' ! ; #2 outlen ' pushl r4 ' ! ; #1 ctrstr ' calls #4,@#7FFEDF50 ' ! ; calls #04,g^sys$fao ' blbs r0,N102$' ' jmp cdberr' 'N102$: movw (r3),(r2) ' ! ; complete ptr to final text ' jmp cdbcom' 'cdbps2: movq @B^4(ap),r0' ' addl r2,r1' ' incl r1' ' movl r3,r0' ' jsb cdbck2' ' tstl r0' ' beql cdbcs2 ' ! ; RPW mod: always jump ' bneq cdbcs2 ' ! ; old statement here ! ! ; build B::A for case 3 'cdbcs3: pushl #5341213A ' ! ; ctrstr #^A/:!AS/ ' pushl #3A534121 ' ! ; ctrstr #^A/!AS:/ ' pushl sp ' ! ; make desc to ctrstr ' pushl #8 ' ! ; make desc to ctrstr ' movl sp,r4 ' ! ; address of desc to ctrstr ' subl #4,sp ' ! ; adjusted stack ' movl sp,r3 ' ! ; save stack for outlen ' movl sp,r2 ' ! ; end of desc to outbuf ' subl #108,sp ' ! ; end of outbuf ' movl sp,-(r2) ' ! ; make outbuf ' movzwl #100,-(r2) ' ! ; make outbuf ' pushl r5 ' ! ; #5 Second sub string A ' pushl r6 ' ! ; #4 first sub string B ' pushl r2 ' ! ; #3 outbuf ' pushl r3 ' ! ; #2 outlen ' pushl r4 ' ! ; #1 ctrstr ' calls #5,@#7FFEDF50 ' ! ; calls #05,g^sys$fao ' blbs r0,N103$' ' jmp cdberr' 'N103$: movw (r3),(r2) ' ! ; complete ptr to final text ' jmp cdbcom' !; check if all alpha numerical + .-_$% returns non zero 'cdbck1: cmpb #^x41,(r1)' ' bgtr cdbck11' ' cmpb #^x5A,(r1)' ' bgeq cdbck19' 'cdbck11: cmpb #^x61,(r1)' ' bgtr cdbck12' ' cmpb #^x7A,(r1)' ' bgeq cdbck19' 'cdbck12: cmpb #^x30,(r1)' ' bgtr cdbck13' ' cmpb #^x39,(r1)' ' bgeq cdbck19' 'cdbck13: cmpb #^x24,(r1)' ' beql cdbck19' ' cmpb #^x25,(r1)' ' beql cdbck19' ' cmpb #^x2D,(r1)' ' beql cdbck19' ' cmpb #^x2E,(r1)' ' beql cdbck19' ' cmpb #^x5F,(r1)' ' rsb' 'cdbck19: incl r1' ' sobgtr r0,cdbck1' ' rsb' !; check if we have at least one dot (then r0 > 0) 'cdbck2: cmpb #^x2E,(r1)' ' bneq cdbck29' ' rsb' 'cdbck29: incl r1' ' sobgtr r0,cdbck2' ' rsb' !; 'cdberr: movab @B^4(ap),r2 ' !; If SYS$FAO fails, use original addr 'cdbcom: MOVQ #^X00000001,-(SP)' ' movl B^8(ap),-(sp)' ' pushl r2' ' CALLS #04,L^ADD_ADDR' ' ret ' !; this is the only RET for ALTER_TO EXI ! Above was the new code ! Below is the patch in the existing code that ! will make use of the ALTER_TO new code RE MAIL$$ADD_ADDR 'MOVQ #^X00000001,-(SP)' 'MOVQ B^04(AP),-(SP)' 'CALLS #04,W^ADD_ADDR' 'RET' EXIT 'MOVQ B^04(AP),-(SP)' 'CALLS #02,ALTER_TO' 'RET' EXIT ! And now update if we reached this point without a single error U !---------------------- end of patch ---------------------- ================================================================================ Archive-Date: Tue, 06 Oct 1992 18:11:46 CDT Date: Tue, 06 Oct 1992 21:49:50 EDT From: "J.C. Higgins, Sys Mgr CsVax1, UCC , Eire" Reply-To: MX-List@WKUVX1.BITNET Subject: RE: Entries with size 0 in MX queue To: MX-LIST@WKUVX1.BITNET Message-ID: <00961B49.B5EBF220.21763@CSVAX1.UCC.IE> In a previous article, madison@tgv.com wrote: >Date: Tue, 6 Oct 1992 17:34:06 GMT >From: madison@tgv.com >Subject: RE: Entries with size 0 in MX queue >Reply-To: MX-List@WKUVX1.BITNET > >In article <00961A80.2DCDDA80.21303@WKUVX1.BITNET>, Hunter Goatley > writes: >>>Does anybody know why we keep getting entries like the following in our MX >>>message queue? They seem to go away eventually, but I would like to know what >>>they are. >>> >>>Entry: 18523, Origin: [code=0] >>> Status: IN-PROGRESS, size: 0 bytes >>> Created: 1-OCT-1992 22:41:59.85, expires 31-OCT-1992 22:41:59.85 >>> Last modified 1-OCT-1992 22:41:59.85 >>> Recipient #1: >>> >>[...] >>These are left whenever a user aborts a message. For example, if a > >Under normal circumstances, cancelling a message in VMS Mail should result > Would they not also be there whilst the process is actually preparing a mail message.. Ie: Don't go killing them as soon as you see them... >-Matt >-- >Matthew Madison | madison@tgv.com | +1 408 427 4366 >TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA >ÿ Chris. + J.C. Higgins, Sys Admin + If you love something, set it free. If it doesn't + CHRIS@csvax1.ucc.ie + come back to you, hunt it down and KILL it. If + SCCS6002@iruccvax.ucc.ie + that doesn't work, then GIVE UP peacefully. ================================================================================ Archive-Date: Tue, 06 Oct 1992 18:11:59 CDT Date: Tue, 06 Oct 1992 14:09:18 PDT From: "John F. Sandhoff" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: p_rand@spu.edu, syssand@CCVAX.CCS.CSUS.EDU Message-ID: <00961B09.5FCB1A00.19550@CCVAX.CCS.CSUS.EDU> Subject: RE: Patch, what patch? >> We've got the mail patch installed so that you don't have to put the MX% >> in front of the address. > What patch is this? From the comments: ! This patch will be of interest to any VAX/VMS system (more especially if it ! is running PMDF) since it lets TO: or CC: addresses such as ! user%machine@site.co.org to be accepted without the IN% prefix and without ! surrounding double quotes. Yes, let's admit it, it lets VMS mail accept Un*x ! type addresses. It was originally written by Claude Barbe. Rick Westerman updated it: > This posting contains a patch to MAIL that elimiates the need to put a > MX%" in front of a mail address. E.g, instead of 'MX%"user@site"', a person > using mail can simply use 'user@site' for the mail address. This patch is > not originally mine; I merely updated it for the MX mailer. The downside is that addresses are UPCASED. This isn't supposed to cause problems but sometimes it does (What if your U*ix machine has three logons: JOHN, John and john? Yes, this is valid, though very, very unwise :-) ). But problems are very rare I understand - in general, it works. NOTE: I myself haven't installed it, though I've come very close on several occasions. The patch is available via Anon-FTP to ftp.spc.edu, directory [.MX.CONTRIB], file VMSMAIL_PATCH.TXT John F. Sandhoff, University Network Support California State University, Sacramento - USA sandhoff@csus.edu ================================================================================ Archive-Date: Wed, 07 Oct 1992 06:37:40 CDT Sender: mbieniec@PLUNLO51.BITNET Date: Wed, 07 Oct 1992 12:27:04 EDT From: mbieniec@PLUNLO51.BITNET Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00961BC4.423F8F00.2673@plunlo51.bitnet> Subject: bitnet node & decnet network My problem is: One vax with Jnet and MX (this one is bitnet node) and several vaxes in DecNet (some connected to Ethernet cable others by leased telepnone lines). I assume that each user of any computer has his own mail address on his own local computer. What is the proper way of using mail in such configuration? 1. What parts of MX should be installed on the bitnet node and what parts on th others? 2. How to configure MX for both types of nodes ( path,rewrite rules, and mx_logicals.dat file ) 3. To use or not to use SMTP-over-DecNet ? 4. Jnet may be also installed on each computer in DecNet. Should I do it or not? Unfortunatelly, I can't find the answers for these questions in MX documentation or maybe I didn't understand it. Pls, anybody help me if you can. Marian Bieniecki Solid State Physics Dpt, Univ of Lodz, Lodz, Pomorska 149/153, Poland tel. (4842)784176, (4842)782953 fax. (4842)790030 E-mail: mbieniec@plunlo51.bitnet ================================================================================ Archive-Date: Wed, 07 Oct 1992 07:31:54 CDT Sender: goathunter@WKUVX1.BITNET Date: Wed, 07 Oct 1992 07:31:36 EDT From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00961B9A.FB741240.21979@WKUVX1.BITNET> Subject: RE: bitnet node & decnet network mbieniec@PLUNLO51.BITNET writes: > >My problem is: >One vax with Jnet and MX (this one is bitnet node) and several vaxes >in DecNet (some connected to Ethernet cable others by leased telepnone >lines). I assume that each user of any computer has his own >mail address on his own local computer. >What is the proper way of using mail in such configuration? I've got the same setup. >1. What parts of MX should be installed on the bitnet node and what >parts on th others? The BITNET node should run MX_JNET, MX_ROUTER, MX_LOCAL, and MX_DNSTMP. >2. How to configure MX for both types of nodes ( path,rewrite >rules, and mx_logicals.dat file ) Just run MX_CONFIG.COM on both types of nodes. That'll do most of the work for you. On the Jnet side, I have the following rewrite rule and path for my VAXstation: Rewrite "<{user}@HUNTER>" => "<{user}@HUNTER.DNET>" Rewrite "<{user}@HUNTER.DNET>" => "<{user}@HUNTER.DNET>" Domain-to-path mappings: Domain="WKUVX1", Path=Local Domain="WKUVX1.BITNET", Path=Local Domain="HUNTER.DNET", Path=DECnet_SMTP, Route="HUNTER" Domain="*.BITNET", Path=Jnet Domain="*.*", Path=Jnet, Route="UKCC" Domain="*", Path=Jnet Note that UKCC.BITNET is my Internet gateway---I don't use INTERBIT for anything. On my VAXstation, the entire CONFIG.MCP file looks like this: >! MX_DEVICE:[MX]CONFIG.MCP;1 >! Created: 11-JUL-1992 19:42:02.66 by MXCONFIG >! >DEFINE PATH "HUNTER.DNET" LOCAL >DEFINE PATH "WKUVX1.BITNET" DECNET_SMTP/ROUTE=WKUVX1 >DEFINE PATH * DECNET_SMTP/ROUTE=WKUVX1 >! >! If sending to myself via MX, don't send it to WKUVX1 >! >DEFINE REWRITE_RULE "" "" >! >! Done with routing information. >! >DEFINE ALIAS "Postmaster" "goathunter@HUNTER.DNET" >DEFINE ALIAS "POSTMAST" "goathunter@HUNTER.DNET" ! for BITNET compatibility >! >SET LOCAL/ACCOUNTING >SET DECNET_SMTP/ACCOUNTING >SET LOCAL/HEADERS=(TOP=(NORESENT_TO,NORESENT_DATE,NORESENT_FROM,NOMESSAGE_ID)) I chose the .DNET just to signal that it was DECnet. There are, of course, many other options. >3. To use or not to use SMTP-over-DecNet ? I did. It's nice. It works well, and it gives you automatic retries in case a node goes down for some reason. >4. Jnet may be also installed on each computer in DecNet. > Should I do it or not? I don't see any point in it, unless you want the users to have things like SEND and SEND/FILE. Of course, then each node would have to be connected to BITNET or clustered anyway. Right? Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Wed, 07 Oct 1992 17:02:22 CDT Date: Wed, 07 Oct 1992 13:39:00 MDT From: Reply-To: MX-List@WKUVX1.BITNET To: MX-LIST@WKUVX1.BITNET CC: jpsmith@CEDAR.atmel.com Message-ID: <00961bce.4ea75340.46@CEDAR> Subject: MX with TGV V3.1? I am pretty new to the MX-List, so I am sure you have had this question before, but, does anyone use MX as TGV's Multinet V3.1 SMTP server? I assumed that all you would have to do is modify the PROGRAM for the SMTP service to use MX_EXE:SMTP_SERVER.EXE instead of MULTINET:SMTP_SERVER.EXE. Since this seems to be incomplete, what else must be done? --Jody Smith ================================================================================ Archive-Date: Wed, 07 Oct 1992 17:23:16 CDT Sender: moniker@OEHL.brooks.af.mil Date: Wed, 07 Oct 1992 13:45:14 EDT From: moniker@OEHL.brooks.af.mil Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00961BCF.2DDF7D80.28939@oehl.brooks.af.mil> Subject: RE: Patch, what patch? ================================================================================ Archive-Date: Thu, 08 Oct 1992 09:53:10 CDT Date: Thu, 08 Oct 1992 15:18:07 CET From: Hans-Joachim Koch Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: sys_hjk@lifra.lif.de Message-ID: <00961CA5.52447C80.9645@lifra.lif.de> Subject: SMTP accounting question Hello all, I have a small problem with the MX smtp accounting. Accounting lines look like this: 8-OCT-1992 10:39 XMIT: PROTO=SMTP, SOURCE="", HOST="SUNNY.LIF.DE", BYTES_SENT=1510 Node LIFRA is our VMS system running VMS5.4-2, Multinet 3.1 and MX 3.1c. Node SUNNY is a Sparc-1 station running in our ethernet and connected to the EUnet via ISDN. The last path config line says "domain *, path=smtp, route=sunny.lif.de". My question is: is it possible to get the REAL address into the smtp accounting instead of the router address. In the above example I would like to see: 8-OCT-1992 10:39 XMIT: PROTO=SMTP, SOURCE="", HOST="user@anywhere.world", BYTES_SENT=1510 Any hints? Thanks. Hans. -- Hans-Joachim Koch, Computer department of Lahmeyer International Lyoner Strasse 22, POB 71 06 51, D-6000 Frankfurt (Main) 71, Germany Phone: +49 69 6677-642, Fax: +49 69 6677-571, Tx: 413478 li d Email: koch@lifra.lif.de, dk9om@dk9om.ampr.org [44.130.25.45] ================================================================================ Archive-Date: Thu, 08 Oct 1992 12:50:55 CDT Date: Thu, 8 Oct 1992 14:31 BSC (-0300 C) From: Joseph Max Cohenca Reply-To: MX-List@WKUVX1.BITNET Subject: Re: MX with TGV V3.1? To: MX-List@WKUVX1.BITNET Message-ID: <9ED88C922000237A@brfapesp.bitnet> References: ANSP network HEPnet SPAN Bitnet Internet gateway =>I am pretty new to the MX-List, so I am sure you have had this question before , =>but, does anyone use MX as TGV's Multinet V3.1 SMTP server? I assumed that all =>you would have to do is modify the PROGRAM for the SMTP service to use =>MX_EXE:SMTP_SERVER.EXE instead of MULTINET:SMTP_SERVER.EXE. Since this seems t o =>be incomplete, what else must be done? => =>--Jody Smith We do use MX with Multinet V3.0 . What we do is just to disable the Multinet SMTP server . And MX SMTP_SERVER works perfectly. This should work ass well for Multinet V3.1. +-----------------------------------------------------------------------------+ ! Joseph Max Cohenca ! Hepnet: uspif::mcohenca ! ! Centro de Computacao ! Hecnet: 47602::mcohenca ! ! Instituto de Fisica da ! Renpac: psi%11182594::uspif::mcohenca ! ! Universidade de Sao Paulo ! Internet: mcohenca@uspif.if.usp.br ! ! Caixa Postal 20516 ! Bitnet: mcohenca%uspif.hepnet@brfapesp.bitnet! ! 01498- Sao Paulo ! Fone: (011) 815-5599 ext 2110 ! ! BRASIL ! FAX : (011) 814-0503 ! +-----------------------------------------------------------------------------+ ================================================================================ Archive-Date: Fri, 09 Oct 1992 11:13:49 CDT Date: 09 Oct 1992 17:02:00 +0100 From: "Alberto Meregalli (SIC)" Reply-To: MX-List@WKUVX1.BITNET Subject: Is MX over UCX lazy? To: MX-List@WKUVX1.BITNET Message-ID: <00961D7CFF7B0180.20201DBB@cesi.it> Hello all! I have installed MX 3.1C on my VAXcluster (8530+6410 with VMS 5.5-1 and UCX 1.3A) When I try to send mail from a Sparc/OS station to the cluster alias or to any cluster node I have random results: sometime the message arrives immediately, sometime it is deferred saying 'connection refused by ...' and sometime it is bounced shortly with 'Host unknown' (but /etc/hosts has the right entries both for the cluster alias and the nodes!) Any idea? (I have bad ones of mine about UCX, but I'm not sure I can throw on it all the blame) Thanks in advance! ------------------------------------------------------------------ Alberto Meregalli, SIC tel. +39 2 2125 249 Centro Elettrotecnico Sperimentale Italiano fax +39 2 2125 520 Via Rubattino, 54 - I 21034 Milano Internet: meregalli@cesi.it UUCP: ...i2unix!cesi!meregalli ================================================================================ Archive-Date: Fri, 09 Oct 1992 12:35:00 CDT From: Subject: Re: Is MX over UCX lazy? Message-ID: <1992Oct9.163616.3050@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <00961D7CFF7B0180.20201DBB@cesi.it> Date: Fri, 9 Oct 1992 16:36:16 GMT To: MX-List@WKUVX1.BITNET In article <00961D7CFF7B0180.20201DBB@cesi.it>, "Alberto Meregalli (SIC)" writes: >When I try to send mail from a Sparc/OS station to the cluster alias >or to any cluster node I have random results: sometime the message >arrives immediately, sometime it is deferred saying 'connection >refused by ...' and sometime it is bounced shortly with 'Host unknown' >(but /etc/hosts has the right entries both for the cluster alias and >the nodes!) > >Any idea? (I have bad ones of mine about UCX, but I'm not sure I can >throw on it all the blame) First, I wouldn't recommend trying to send mail to the cluster alias address. In fact, the cluster alias address may be screwing other things up as well. I never got it to work for me when I was running V1.3 (back at my last job). That might explain the connection refused errors. The bounces with "host unknown" don't sound like problems with the VAXes at all, but perhaps a configuration problem on your Sun. Including a copy of one of these bounce messages might help in trying to track down the problem. -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Fri, 09 Oct 1992 23:28:26 CDT Date: Fri, 09 Oct 1992 20:01:24 PDT From: RON WELKER Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: welker@gtewd.mtv.gsc.gte.com Message-ID: <00961D96.0F1DA7A0.11920@GTEWD> Subject: Re: Is MX over UCX lazy? > writes: >>When I try to send mail from a Sparc/OS station to the cluster alias >>or to any cluster node I have random results: sometime the message >>arrives immediately, sometime it is deferred saying 'connection >>refused by ...' and sometime it is bounced shortly with 'Host unknown' >>(but /etc/hosts has the right entries both for the cluster alias and >>the nodes!) >> >>Any idea? (I have bad ones of mine about UCX, but I'm not sure I can >>throw on it all the blame) Mathew Madison writes: >First, I wouldn't recommend trying to send mail to the cluster alias address. >In fact, the cluster alias address may be screwing other things up as well. >I never got it to work for me when I was running V1.3 (back at my last job). >That might explain the connection refused errors. >The bounces with "host unknown" don't sound like problems with the VAXes >at all, but perhaps a configuration problem on your Sun. Including a >copy of one of these bounce messages might help in trying to track down >the problem. That's strange. I haven't had a bit of a problem. I've been running 3.1-C, with both UCX V1.3a (and it's myriad patches) and now 2.0. Someone did mention earlier tho that in UCX, you need to use the FQDN (fully qualified domain name), not just the host name, for the cluster. In my case, the cluster is known as GTEWD, so in UCX I set it up with the command SET HOST GTEWD.MTV.GSC.GTE.COM/ALIAS=GTEWD... In MCP, it's set up exactly the same way as all six real hosts are. When mail comes in, it's received varisously by C.MTV.GSC.GTE.COM, D.MTV.GSC.GTE.COM ... H.MTV.GSC.GTE.COM (real creative host names right? ;-) ). When mail is sent out from any of the machines, it always goes out as GTEWD.MTV.GSC.GTE.COM; this message is being sent from G.MTV.GSC.GTE.COM and should be received with the cluster alias. || ||Ron Welker (415) 966-2900 || ||Internet: US Mail: ||welker@gtewd.mtv.gsc.gte.com 100 Ferguson Dr. M/S 5G09 ||welker@ns2.mtv.gsc.gte.com Mt. View, CA 94039 ================================================================================ Archive-Date: Fri, 09 Oct 1992 23:32:16 CDT Date: Fri, 09 Oct 1992 14:46:55 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: meregalli@cesi.it CC: mx-list@WKUVX1.BITNET Message-ID: <00961D6A.211BB040.17878@swdev.si.com> Subject: RE: Is MX over UCX lazy? Alberto Meregalli (meregalli@cesi.it) writes: >When I try to send mail from a Sparc/OS station to the cluster alias >or to any cluster node I have random results: sometime the message >arrives immediately, sometime it is deferred saying 'connection >refused by ...' and sometime it is bounced shortly with 'Host unknown' >(but /etc/hosts has the right entries both for the cluster alias and >the nodes!) I am using the exact configuration of software Alberto mentions (UCX V1.3A and MX3.1C). There's nothing pokey about inbound or outbound mail. MX transfers the mail within second (or tens of seconds) of it appearing in the queue. Perhaps you should describe more of your environment (type of VAX, MX configuration, etc.) in order to facilitate a better analysis of your problem. -----------------------------+-------------------------------- 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: Sun, 11 Oct 1992 21:20:13 CDT Date: Sun, 11 Oct 92 21:06:16 CDT From: Reply-To: MX-List@WKUVX1.BITNET Message-ID: <9210120206.AA01415@helios.augustana.edu.augustana.edu> To: mx-list@WKUVX1.BITNET Subject: Help!! (New Install of MX) k Greetings, all. I must appologize for the length of this message, but I did want it to be complete enough to solve our problem. The problem: I have a bunch of messages in the queue, and none of them are being distributed. I tried shutting down all the MX agents, but I get errors when trying to do this. Here is a transcript (edited down a bit) of a recent session.... Thank you for your assistance... ++ Andy Barcus ++ ++ Network Manager ++ ++ Augustana College (Illinios) ++ ++++++++++++++++++++++++++++++++++ $ Vax: mcp MCP> queue show Entry Status Size Source Agent Entry Status Size ----- ------ ------ ------ ------- ----- ------ ------ 67 READY 4 MAIL CCAB 68 READY 5 SMTP 69 READY 5 SMTP 76 READY 3 MAIL CCAB 77 READY 42 MAIL CCAB 78 READY 5 MAIL CCAB 79 READY 13 SMTP 80 READY 3 MAIL CCAB 81 READY 4 SMTP 82 READY 415 LOCAL <> MCP> shutdown %MCP-W-SHUTRESF, command SHUTDOWN failed -SYSTEM-F-IVBUFLEN, invalid buffer length %MCP-W-SHUTRESF, command SHUTDOWN failed -SYSTEM-F-IVBUFLEN, invalid buffer length %MCP-W-SHUTRESF, command SHUTDOWN failed -SYSTEM-F-IVBUFLEN, invalid buffer length %MCP-W-SHUTRESF, command SHUTDOWN failed -SYSTEM-F-IVBUFLEN, invalid buffer length %MCP-W-SHUTRESF, command SHUTDOWN failed -SYSTEM-F-IVBUFLEN, invalid buffer length %MCP-W-SHUTRESF, command SHUTDOWN failed -SYSTEM-F-IVBUFLEN, invalid buffer length %MCP-W-SHUTRESF, command SHUTDOWN failed -SYSTEM-F-IVBUFLEN, invalid buffer length %MCP-W-SHUTRESF, command SHUTDOWN failed -SYSTEM-F-IVBUFLEN, invalid buffer length %MCP-W-SHUTRESF, command SHUTDOWN failed -SYSTEM-F-IVBUFLEN, invalid buffer length %MCP-W-SHUTRESF, command SHUTDOWN failed -SYSTEM-F-IVBUFLEN, invalid buffer length MCP> show all Configuration file: MX_DEVICE:[MX]MX_CONFIG.MXCFG;1 MX version id is: MX V3.1C Domain-to-path mappings: Domain="vax.augustana.edu", Path=Local Domain="vax", Path=Local Domain="[143.226.192.1]", Path=Local Domain="*.UUCP", Path=SMTP, Route="uunet.uu.net" Domain="*.BITNET", Path=SMTP, Route="cunyvm.cuny.edu" Domain="vax.dnet.augustana.edu", Path=Local Domain="vax.dnet", Path=Local Domain="vax4.augustana.edu", Path=DECnet_SMTP, Route="VAX4" Domain="mvax.augustana.edu", Path=DECnet_SMTP, Route="MVAX" Domain="*", Path=SMTP Aliases: LocalName="Postmaster", Address="ccab@vax.augustana.edu" LocalName="POSTMAST", Address="ccab@vax.augustana.edu" SMTP agent settings: Retry interval: 0 00:30:00.00 Maximum number of retries: 96 Number of DNS failure retries: 12 Accounting: disabled Default router: (none) LOCAL agent settings: DECnet delivery retry interval: 0 00:30:00.00 Maximum number of retries: 96 Accounting disabled. Top headers: FROM,SENDER,TO,RESENT_TO,CC,RESENT_CC,BCC,RESENT_BCC,MESSAGE_ID, RESENT_MESSAGE_ID,IN_REPLY_TO,REFERENCES,KEYWORDS,SUBJECT, ENCRYPTED,DATE,REPLY_TO,RECEIVED,RESENT_REPLY_TO,RESENT_FROM, RESENT_SENDER,RESENT_DATE,RETURN_PATH,OTHER Bottom headers: (none) ROUTER agent settings: Automatic percent-hack handling: enabled JNET agent settings: Automatic percent-hack handling: enabled BSMTP replies: disabled Accounting: disabled Lenient about gatewaying mail: no No mailer username set. DECnet_SMTP agent settings: Retry interval: 0 00:30:00.00 Maximum number of retries: 96 Accounting disabled. SITE agent settings: Retry interval: 0 00:30:00.00 Maximum number of retries: 96 X25_SMTP agent settings: Retry interval: 0 00:30:00.00 Maximum number of retries: 96 Accounting disabled. MCP> exit $ Vax: cd [mx] $ Vax: show logical mx* (LNM$PROCESS_TABLE) (LNM$JOB_80636260) (LNM$GROUP_000002) (LNM$SYSTEM_TABLE) "MX_DEVICE" = "DUA0:" "MX_DIR" = "MX_DEVICE:[MX]" "MX_DNSMTP_DIR" = "MX_ROOT:[DNSMTP]" "MX_DOC" = "MX_ROOT:[DOC]" "MX_EXAMPLES_DIR" = "MX_ROOT:[EXAMPLES]" "MX_EXE" = "MX_ROOT:[EXE]" "MX_JNET_DIR" = "MX_ROOT:[JNET]" "MX_LOCAL_DIR" = "MX_ROOT:[LOCAL]" "MX_MAILSHR" = "MX_EXE:MX_MAILSHR" "MX_MAILSHRP" = "MX_EXE:MX_MAILSHRP" "MX_MLF_DIR" = "MX_ROOT:[MLF]" "MX_MLIST_DIR" = "MX_ROOT:[MLF.MAILING_LISTS]" = "MX_ROOT:[LOCAL.MLIST]" "MX_MSG" = "MX_EXE:MX_MSG" "MX_NODE_NAME" = "VAX" "MX_ROOT" = "MX_DEVICE:[MX.]" "MX_ROUTER_DIR" = "MX_ROOT:[ROUTER]" "MX_SHR" = "MX_EXE:MX_SHR" "MX_SITE_DIR" = "MX_ROOT:[SITE]" "MX_SITE_DOM_EXPANSION" = "MX_EXE:DOMAIN_EXPANSION" "MX_SMTP_DIR" = "MX_ROOT:[SMTP]" "MX_UUCP_DIR" = "MX_ROOT:[UUCP]" "MX_VMSMAIL_LOCALHOST" = "@augustana.edu" (DECW$LOGICAL_NAMES) $ Vax: show system VAX/VMS V5.3 on node VAX 11-OCT-1992 20:51:40.25 Uptime 46 22:41:43 Pid Process Name State Pri I/O CPU Page flts Ph.Mem 0000050B MX Router HIB 5 35988 0 00:09:42.50 442 675 00000312 MX Local HIB 5 10955 0 00:02:49.98 633 728 00000313 MX DNSMTP HIB 5 14110 0 00:03:49.96 360 454 00000314 MX SMTP HIB 5 10915 0 00:02:47.84 348 680 00000515 SMTP Server HIB 5 239 0 00:00:04.14 395 529 0000052F CCAB CUR 4 515 0 00:00:13.68 1630 245 00000466 INET_ACP HIB 8 529 0 00:00:09.25 251 261 00000467 UCX$FTPD LEF 9 79 0 00:00:01.98 272 423 00000468 NFS$SERVER LEF 8 60 0 00:00:02.79 1248 1439 (Others edited out) $ Vax: type mx_logicals.dat FLQ_NODE_NAME\/SYSTEM/EXEC\VAX MX_NODE_NAME\/SYSTEM/EXEC\vax.augustana.edu MX_VMSMAIL_LOCALHOST\/SYSTEM/EXEC\@AUGUSTANA FLQ_DIR\/SYSTEM/EXEC\SYS$SYSDEVICE:[MX.QUEUE] MX_ROUTER_DIR\/SYSTEM/EXEC\MX_ROOT:[ROUTER] MX_LOCAL_DIR\/SYSTEM/EXEC\MX_ROOT:[LOCAL] MCP_HELPLIB\/SYSTEM\MX_DIR:MCP_HELPLIB $ Vax: type mx_startup_info.dat 001NETLIB:* 002ROUTER:* 003LOCAL:* 004DNSMTP:* 004SMTP:* 004SMTP_SERVER:* $ Vax: ucx UCX> show version V1.3 UCX> exit ================================================================================ Archive-Date: Mon, 12 Oct 1992 04:40:04 CDT Subject: Re: Help!! (New Install of MX) Message-ID: <1bb823INNfq2@gap.caltech.edu> From: Date: 12 Oct 1992 07:04:35 GMT Reply-To: MX-List@WKUVX1.BITNET References: <9210120206.AA01415@helios.augustana.edu.augustana.edu> To: MX-List@WKUVX1.BITNET In article <9210120206.AA01415@helios.augustana.edu.augustana.edu>, writes: >The problem: I have a bunch of messages in the queue, and none of them are >being distributed. I tried shutting down all the MX agents, but I get errors >when trying to do this. Look, turkey, the basic problem is: Mail isn't getting delivered, right? Then the first step is to define the DEBUG logicals and look at the traces. Try that, and if the results don't make sense, post them. In other words: RTFM. -------------------------------------------------------------------------------- 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, 12 Oct 1992 14:07:17 CDT Sender: ccab@AUGUSTANA Date: Mon, 12 Oct 1992 13:15:26 CDT From: ccab@vax.augustana.edu Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00961FB8.D825D540.97@vax.augustana.edu> Subject: How can I change my Reply-To field If you will notice my original Reply-to field is wrong. The last time I tried to change it, I really messed things up. I need it to read vax.augustana.edu. Thanks for your time... ++ Andy Barcus ++ ================================================================================ Archive-Date: Mon, 12 Oct 1992 14:14:21 CDT Sender: p_rand@luke.spu.edu Date: Mon, 12 Oct 1992 11:41:26 PDT From: "Phil Rand, Computer Services, 281-2428" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00961FAB.B68A8B40.5930@luke.spu.edu> Subject: RE: Patch, what patch? Just a belated thank you to all who responded so quickly to my question about the patch that allows you to leave off the mx%" " around mail addresses. The consensus seems to be: 1) I should look at the distribution materials more carefully: It's in the user-contributed part of the standard MX distribution. 2) The patch works nicely, though it does reveal some bugs in certain Unix mail systems by upcasing the addresses. Thanks, everybody! --Phil ----------------------------------------------------------------------- Phil Rand, Computer & Information Systems, Seattle Pacific University 3307 3rd Ave W, Seattle, WA 98119 p_rand@spu.edu (206) 281-2428 ----------------------------------------------------------------------- ================================================================================ Archive-Date: Mon, 12 Oct 1992 15:45:59 CDT Date: Mon, 12 Oct 1992 18:22:58 +0100 From: system@mpib-tuebingen.mpg.dbp.de Reply-To: MX-List@WKUVX1.BITNET Message-ID: <12*/S=system/O=mpib-tuebingen/PRMD=mpg/ADMD=dbp/C=de/@MHS> To: mx-list@RPIECSVX.BITNET Subject: subscribe SUBSCRIBE ================================================================================ Archive-Date: Mon, 12 Oct 1992 15:49:09 CDT Date: Mon, 12 Oct 1992 18:56:58 +0100 From: boerner Reply-To: MX-List@WKUVX1.BITNET Message-ID: <12*/S=system/O=mpib-tuebingen/PRMD=mpg/ADMD=dbp/C=de/@MHS> To: mx-list@RPIECSVX.BITNET Subject: mx - vms -cmutek Hallo, i can't find mx V3.1b on server vms.ecs.rpi.edu ? We have VACXstation 4000 VMS 5.5-1 (cluster) CMUTEK 6.6 . Is there are Problems to take MX3.1 with this configurations ??? with regards rudi boerner mpi f. biologie tuebingen ================================================================================ Archive-Date: Mon, 12 Oct 1992 15:55:47 CDT Date: Mon, 12 Oct 1992 15:47:19 CDT From: Mike Frohme Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00961FCE.102CE4A0.1285@bilbo.memst.edu> Subject: RE: How can I change my Reply-To field Andy, > > If you will notice my original Reply-to field is wrong. The last time I tried > to change it, I really messed things up. I need it to read vax.augustana.edu. > We had the same problem here. It seems to happen with UCX (at least to me, it did), and the way names are put into the local hosts database. Even though the documentation says to put the alias as the *first* entry, the proper way to do it is to use the "Fully Qualified Domain Name" (FQDN) as the first entry . You'll probably get quite a few responses on this one - it will eventually make the FAQ list. See below for example. Good luck. Mike Frohme -------------------------------------------------------------------------------- $ ucx sh host/local bilbo LOCAL database Host address Host name 141.225.56.13 bilbo.memst.edu, BILBO, bilbo, BILBO.MEMST.EDU -------------------------------------------------------------------------------- Michael K. Frohme Internet: frohme@bilbo.memst.edu Center for Earthquake Research & Information Bitnet: frohmemk@memstvx1 Memphis State University PhoneNet: 901/678-2007 "... I suppose we *could* network a few tricorders together..."- Geordi ================================================================================ Archive-Date: Mon, 12 Oct 1992 16:42:20 CDT Date: Mon, 12 Oct 1992 14:30:25 PDT From: "John F. Sandhoff" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: syssand@CCVAX.CCS.CSUS.EDU Message-ID: <00961FC3.519E21C0.26141@CCVAX.CCS.CSUS.EDU> Subject: Re: Help!! (New Install of MX) >> The problem: I have a bunch of messages in the queue, and none of them >> are being distributed... > Look, turkey... I realize that seeing the same genre of 'help me' messages becomes rather tiring, but we need to remember that there's lots of novices that suddenly find themselves faced with a terrifying problem: their mail is STUCK and they are suddenly DESPERATE to find a quick fix. I hope that we can all find the patience to keep from flame-festing here... Meanwhile, who wants to volunteer to write the 'ARRGH! My mail is STUCK and I need help NOW!' troubleshooting manual that lists what to do, what to look at, and what it all means :-) John F. Sandhoff, University Network Support California State University, Sacramento - USA sandhoff@csus.edu ================================================================================ Archive-Date: Mon, 12 Oct 1992 17:09:47 CDT Date: Mon, 12 Oct 1992 14:56:05 PDT From: "John F. Sandhoff" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: system@mpib-tuebingen.mpg.dbp.de, syssand@CCVAX.CCS.CSUS.EDU Message-ID: <00961FC6.E7DB6820.26194@CCVAX.CCS.CSUS.EDU> Subject: RE: mx - vms -cmutek > i can't find mx V3.1b on server vms.ecs.rpi.edu ? Since Matt Madison abandoned MX in favor of sun, surf, and a real salary :-) the package is now under the care of Hunter Goatley and has taken up residence at ftp.spc.edu. John F. Sandhoff, University Network Support California State University, Sacramento - USA sandhoff@csus.edu ================================================================================ Archive-Date: Tue, 13 Oct 1992 03:58:27 CDT Sender: gazicki@lodz1.decnet.pl Date: Tue, 13 Oct 1992 08:51:19 CET From: "PAWEL GAZICKI - CENTRUM KOMPUTEROWE POLITECHNIKI LODZKIEJ T.(0-42)312835, 362208 UL.STEFANOWSKIEGO 18/22 90-924 LODZ POLAND" Reply-To: MX-List@WKUVX1.BITNET To: MX-LIST@WKUVX1.BITNET Message-ID: <0096205D.1CBB9060.1055@lodz1.decnet.pl> Subject: How Change RETURN-PATH field I would like to ask, how can I change the RETURN-PATH field in my MX3.1C. Pawel Gazicki , Computer Center , Technical University of Lodz ul. Stefanowskiego 18/22 POLAND ================================================================================ Archive-Date: Tue, 13 Oct 1992 04:00:11 CDT Subject: Re: Help!! (New Install of MX) Message-ID: <1bd47nINNcn6@gap.caltech.edu> From: Date: 13 Oct 1992 00:11:35 GMT Reply-To: MX-List@WKUVX1.BITNET References: <00961FC3.519E21C0.26141@CCVAX.CCS.CSUS.EDU> To: MX-List@WKUVX1.BITNET In article <00961FC3.519E21C0.26141@CCVAX.CCS.CSUS.EDU>, "John F. Sandhoff" writes: > >>> The problem: I have a bunch of messages in the queue, and none of them >>> are being distributed... > >> Look, turkey... > >I realize that seeing the same genre of 'help me' messages becomes rather >tiring, but we need to remember that there's lots of novices that suddenly >find themselves faced with a terrifying problem: their mail is STUCK and >they are suddenly DESPERATE to find a quick fix. Perhaps I overreacted, but the "genre" of `help me' messages in this case is someone who pretty obviously hasn't read the appropriate part of the documentation. Now, in some instances, this would be excusable, but: 1) The standard excuse given when didn't RTFM is that they don't HAVE TFM. Since the MX distribution includes the manuals in both PostScript and plain ASCII formats, this excuse is clearly invalid. 2) In some cases, the particular piece of documentation might be rather obscure (like trying to figure out where to look to find out how to reset the new mail count), but in this case TFM happens to have a chapter called "Troubleshooting MX," which tells you how to get a trace of what the agent is doing. It would seem rather obvious that such information might have some bearing on solving the problem. Now, this just happens to be that time of year when you can expect most of the computer-related newsgroups to be chock full of posts from people who weren't willing to learn enough about the system they're "managing" to even suspect what information they ought to provide in their questions. Something like 20% of the questions I've seen in such groups for the past month have been from people who expect an instant answer to a question of the form "This is broken. How do I fix it?" After patiently explaining the same basic fact (we can't possibly tell you how to fix something if you refuse to tell us what the system tells you) do literally dozens of people recently, my temper's gotten pretty short. >Meanwhile, who wants to volunteer to write the 'ARRGH! My mail is STUCK and >I need help NOW!' troubleshooting manual that lists what to do, what to look >at, and what it all means :-) Matt Madison already provided a manual that tells you how to get the information necessary to diagnose and fix most MX problems. What makes you think that someone who won't read THAT manual would bother to read the one you propose? -------------------------------------------------------------------------------- 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, 13 Oct 1992 10:24:26 CDT Date: Tue, 13 Oct 1992 10:52:34 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <0096206E.0D5D2D20.20363@swdev.si.com> Subject: Temporary files In my MX_LOCAL_DIR are come files whose names are of the form LCL_BBE89AA0_009618BC_2780009C.TMP. They seem to contain old messages that I received over ten days ago. What is the purpose of these files and why might MX have left them around? -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Tue, 13 Oct 1992 10:25:21 CDT From: Reply-To: MX-List@WKUVX1.BITNET Subject: Re: Help!! (New Install of MX) References: <1bd47nINNcn6@gap.caltech.edu> Message-ID: <8585008@MVB.SAIC.COM> Date: Tue, 13 Oct 1992 14:55:19 GMT To: MX-List@WKUVX1.BITNET Carl J Lydick (carl@SOL1.GPS.CALTECH.EDU) wrote: : >Meanwhile, who wants to volunteer to write the 'ARRGH! My mail is STUCK and : >I need help NOW!' troubleshooting manual that lists what to do, what to look : >at, and what it all means :-) : : Matt Madison already provided a manual that tells you how to get the : information necessary to diagnose and fix most MX problems. What makes you : think that someone who won't read THAT manual would bother to read the one you : propose? I put some time into just such a manual and I believe it is contained in the contrib area of the savesets. I tried to cover most of the basics that I ran across and I am sure I left out some pieces but it might be a good starting point. Earle ake@dayton.saic.com ================================================================================ Archive-Date: Tue, 13 Oct 1992 10:26:48 CDT Date: Tue, 13 Oct 1992 10:18:54 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00962069.598D8460.20330@swdev.si.com> Subject: Personal names and RFC-822 addressing Currently, MX (v3.1C) places the VMS personal name in the From: header by enclosing the name in quotes and following that with the Internet-style address enclosed in "angle brackets." I read the RFC and, although I don't understand all I read, it seemed that a more appropriate handling of the personal name would have been to enclose it in parentheses, since the RFC explicitly says that parentheses-enclosed text is treated as comments, but doesn't seem (at least in my mind) to say exactly what to do with quoted text. Could someone suggest a patch to MX to implement this behavior change? We have a mailer here that is supposedly RFC-compliant that isn't handling the personal name properly and I want to see if parentheses would make a difference. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Tue, 13 Oct 1992 12:06:22 CDT Date: 13 Oct 1992 17:49:17 +0100 From: "Alberto Meregalli (SIC)" Reply-To: MX-List@WKUVX1.BITNET Subject: Re: Is MX over UCX lazy? To: MX-List@WKUVX1.BITNET Message-ID: <009620A8441C5360.20401486@cesi.it> Matt Madison writes: >>When I try to send mail from a Sparc/OS station to the cluster alias >>or to any cluster node I have random results: sometime the message >>arrives immediately, sometime it is deferred saying 'connection >>refused by ...' and sometime it is bounced shortly with 'Host unknown' >>(but /etc/hosts has the right entries both for the cluster alias and >>the nodes!) >> > >First, I wouldn't recommend trying to send mail to the cluster alias address. >In fact, the cluster alias address may be screwing other things up as well. >I never got it to work for me when I was running V1.3 (back at my last job). >That might explain the connection refused errors. As I specified, the 'connection' was 'refused' both while sending to the cluster alias and to the cluster nodes! But about that, MAYBE, I have found out something: my MX_STARTUP_INFO.DAT file looked so 001NETLIB:* 002ROUTER:V8530 003LOCAL:V8530 004SMTP:V8530 004SMTP_SERVER:V8530 004UUCP:V8530 It seems to me that this is correct according to 1.2.1 in page 1-2 of the 'Message Exchange Instllation Guide' that states that 'the processing agents [...]can be run on any or all nodes of the cluster [...] and will automatically cooperate in providing their respective services' But I only had all work as I changed the file to 001NETLIB:* 002ROUTER:* 003LOCAL:* 004SMTP:* 004SMTP_SERVER:* 004UUCP:V8530 Now I have still the 'unknown host' problem, but at least not the 'connection refused' one. Is the statement in the Guide incorrect? have I misunderstood it? is the trick somewhere else? >The bounces with "host unknown" don't sound like problems with the VAXes >at all, but perhaps a configuration problem on your Sun. Including a >copy of one of these bounce messages might help in trying to track down >the problem. This is the message I get >From meregall Tue Oct 13 16:45:41 1992 >Return-Path: >Received: by sic5020.cesi.it. (4.1/SMI-4.1) > id AB00286; Tue, 13 Oct 92 16:45:39 GMT >Date: Tue, 13 Oct 92 16:45:39 GMT >From: Mailer-Daemon (Mail Delivery Subsystem) >Subject: Returned mail: Host unknown >Message-Id: <9210131645.AB00286@sic5020.cesi.it.> >To: meregall >Status: R > > ----- Transcript of session follows ----- >421 Host mailhost not found for mailer ether. >550 meregalli@decvax.cesi.it... Host unknown > > ----- Unsent message follows ----- >Return-Path: >Received: by sic5020.cesi.it. (4.1/SMI-4.1) > id AA00284; Tue, 13 Oct 92 16:45:39 GMT >Date: Tue, 13 Oct 92 16:45:39 GMT >From: meregall (Alberto Meregalli) >Message-Id: <9210131645.AA00284@sic5020.cesi.it.> >To: meregalli@decvax.cesi.it >Subject: meregalli@decvax.cesi.it > >testo This is part of the /etc/hosts file on the UNIX station >128.1.0.3 decvax.cesi.it decvax DECVAX # VAXcluster alias >128.1.0.20 sic5020.cesi.it sic5020 SIC5020 # SPARC/OS station >128.1.0.4 vax6000.cesi.it vax6000 VAX6000 # 1st node of cluster >128.1.0.5 vax8530.cesi.it vax8530 VAX8530 # 2nd ... (Please note that I _had_ to give different UCX names to my VAX's than are their SCSNODE names: I saw that names like ANNNN (i.e. one letter followed by many digits) annoy UCX! I hope that's not important!) (I would also thank Brian Tillman and Ron Welker for comforting my distress with UCX ;-). ------------------------------------------------------------------ Alberto Meregalli, SIC tel. +39 2 2125 249 Centro Elettrotecnico Sperimentale Italiano fax +39 2 2125 520 Via Rubattino, 54 - I 21034 Milano Internet: meregalli@cesi.it UUCP: ...i2unix!cesi!meregalli ================================================================================ Archive-Date: Tue, 13 Oct 1992 13:18:08 CDT Date: Tue, 13 Oct 1992 14:10:00 EDT From: ANIL KHULLAR Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00962089.A2833654.27944@cunyvms1.gc.cuny.edu> Subject: Re: Is MX over UCX lazy? HI, Is'nt 128.1.0.0 reserved for BBN Test ? I hope the machines being specified are not connected to the internet. MX will query nameservers and since 128.1.0.0 is not under your admin control it may give a host unknown error. Just a thought anil ================================================================================ Archive-Date: Tue, 13 Oct 1992 13:45:27 CDT Subject: Re: Temporary files Message-ID: <1992Oct13.155921.5607@news.arc.nasa.gov> From: Date: Tue, 13 Oct 1992 15:59:21 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: usenet@news.arc.nasa.gov References: <0096206E.0D5D2D20.20363@swdev.si.com> To: MX-List@WKUVX1.BITNET In article <0096206E.0D5D2D20.20363@swdev.si.com>, "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: >In my MX_LOCAL_DIR are come files whose names are of the form >LCL_BBE89AA0_009618BC_2780009C.TMP. They seem to contain old messages that I >received over ten days ago. They are temporary files that are constructed when delivering messages into VMS Mail. They should get deleted automatically after they've been used. They might get left around if the MX_LOCAL agent (or the system it was running on) died before it could delete those files. If that's not the case, then there might be a problem in MX_LOCAL... anything unusual about the messages? -Matt= -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Tue, 13 Oct 1992 13:45:36 CDT Subject: Re: Temporary files Message-ID: <1berdvINN60g@gap.caltech.edu> From: Date: 13 Oct 1992 15:53:35 GMT Reply-To: MX-List@WKUVX1.BITNET References: <0096206E.0D5D2D20.20363@swdev.si.com> To: MX-List@WKUVX1.BITNET In article <0096206E.0D5D2D20.20363@swdev.si.com>, "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: >In my MX_LOCAL_DIR are come files whose names are of the form >LCL_BBE89AA0_009618BC_2780009C.TMP. They seem to contain old messages that I >received over ten days ago. In particular, the mail arrived at 3-OCT-1992 15:51:30.22. >What is the purpose of these files and why might MX have left them around? They are, I think, temporary files created by the LOCAL delivery agent to be passed to callable mail. Have you looked at the contents of MX_LOCAL_yournode.LOG to see if the LOCAL delivery agent reported any problems (it's not likely, I know)? -------------------------------------------------------------------------------- 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, 13 Oct 1992 13:45:49 CDT Subject: Re: Personal names and RFC-822 addressing Message-ID: <1992Oct13.173241.1@sejnet.sunet.se> From: Date: Tue, 13 Oct 1992 17:32:41 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: news@sunic.sunet.se References: <00962069.598D8460.20330@swdev.si.com> To: MX-List@WKUVX1.BITNET In article <00962069.598D8460.20330@swdev.si.com>, "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: > Currently, MX (v3.1C) places the VMS personal name in the From: header by > enclosing the name in quotes and following that with the Internet-style address > enclosed in "angle brackets." I read the RFC and, although I don't understand > all I read, it seemed that a more appropriate handling of the personal name > would have been to enclose it in parentheses, A particular syntax was provided in RFC822 for the explicit purpose of carrying the user's name: From: Joe Doe The name must be quoted if it contains certain characters, and may always be quoted even if it contains only letters and blanks. The syntax you mention is also valid, since comments can be present anywhere and must be ignored (which actually is a royal pain, especially as they can be nested - you will find that most software accepts them where they are usually present, but not everywhere they are allowed to appear). > We have > a mailer here that is supposedly RFC-compliant that isn't handling the > personal name properly and I want to see if parentheses would make a > difference. There is a known bug in certain unix-based mail software which prevents proper parsing when parentheses are quoted, as in: From: "(Joe Doe hides between his parentheses)" which is ugly and not something I would generate on purpose, but still valid. If the program in question won't handle a plain name, it certainly needs fixing as MANY mail programs (I am inclined to say MOST mail programs) generate addresses with the angle brackets. Eric ================================================================================ Archive-Date: Tue, 13 Oct 1992 14:01:10 CDT Date: Tue, 13 Oct 1992 14:02:26 EDT From: "Edward J. Groth" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: groth@PUPGG.PRINCETON.EDU Message-ID: <00962088.9398BCA0.3405@PUPGG.PRINCETON.EDU> Subject: Re: Help!! (New Install of MX) > Carl J Lydick (carl@SOL1.GPS.CALTECH.EDU) wrote: > > : >Meanwhile, who wants to volunteer to write the 'ARRGH! My mail is STUCK and > : >I need help NOW!' troubleshooting manual that lists what to do, what to look > : >at, and what it all means :-) > : > : Matt Madison already provided a manual that tells you how to get the > : information necessary to diagnose and fix most MX problems. What makes you > : think that someone who won't read THAT manual would bother to read the one you > : propose? > > I put some time into just such a manual and I believe it is contained > in the contrib area of the savesets. I tried to cover most of the basics that > I ran across and I am sure I left out some pieces but it might be a good > starting > point. > > > Earle > ake@dayton.saic.com Earl - you missed the point! Recall the urban legend about a beginning computer science class: Student: "Help, it says `Type your name and press return,' what do I do???" Instructor: "Type your name and press return." Student: "Oh!" - Ed /----------------------------------------------------------------------\ | Edward J. Groth | Phone: 609-258-4361 | | Physics Dept., Jadwin Hall | Fax: 609-258-1124 | | Princeton University | SPAN/HEPNET: PUPGG::GROTH=44117::GROTH | | Princeton, NJ 08544 | Internet: groth@pupgg.princeton.edu | \----------------------------------------------------------------------/ ================================================================================ Archive-Date: Tue, 13 Oct 1992 15:49:36 CDT Date: Tue, 13 Oct 1992 15:54:47 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00962098.45AA39A0.20701@swdev.si.com> Subject: Re: Temporary files Matthew Madison (madison@tgv.com) writes: >They are temporary files that are constructed when delivering messages into >VMS Mail. They should get deleted automatically after they've been used. I figured that they are normally deleted. >anything unusual about the messages? Not that I can see. I deleted them and won't bother with them any more, since the occurrance of them is rare. Thanks. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Tue, 13 Oct 1992 16:55:39 CDT Date: Tue, 13 Oct 1992 16:43:05 CDT From: Larry Horn Reply-To: MX-List@WKUVX1.BITNET To: tillman@swdev.si.com CC: MX-List@WKUVX1.BITNET Message-ID: <0096209F.04558200.11769@okra.millsaps.edu> Subject: Re: Temporary files Brian Tillman (tillman@swdev.si.com) writes: #Matthew Madison (madison@tgv.com) writes: # #>They are temporary files that are constructed when delivering messages into #>VMS Mail. They should get deleted automatically after they've been used. # #I figured that they are normally deleted. I have "$ MCR MX_EXE:MCP SHUTDOWN" in "SYS$MANAGER:SYSHUTDWN.COM" -- if you're not doing this, it might explain some of the temporary files being left around due to shutdown. Larry Horn / Millsaps College / Jackson, MS / hornlo@okra.millsaps.edu ================================================================================ Archive-Date: Tue, 13 Oct 1992 17:58:56 CDT Subject: Problems with UUCP and MX Message-ID: <1bdjbmINNq28@golem.wcc.govt.nz> From: Reply-To: MX-List@WKUVX1.BITNET Date: 13 Oct 1992 17:29:42 +1300 To: MX-List@WKUVX1.BITNET The following is an extract from the uucp_log:uuxqt.log file. Has anyone seen this problem before ? ... p:uxqt =< h:- [10/13-14:54:05-2020411e] Processing (DUA12:[UUCP.SPOOL.TOSH]X.TOSH19576;1) u:- p:uxqt << h:tosh [10/13-14:54:06-2020411e] Executing (rmail brockie@med.wcc.govt.nz < UUCP_DISK:[UUCP.SPOOL.tosh]D.TOSH19576 > NL:) u:- Begin X file DUA12:[UUCP.SPOOL.TOSH]X.TOSH19576;1 at 13-OCT-1992 14:54:06.46 $ RMAIL DUA12:[UUCP.SPOOL.TOSH]D.TOSH19576; "brockie@med.wcc.govt.nz" %RMS-F-FLK, file currently locked by another user %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel PC abs PC MX_RMAIL MX_RMAIL 127 00000033 00001C47 $ FAILED_RMAIL: Attempt to send mail to failed with status %X1001828C %RENAME-I-RENAMED, DUA12:[UUCP.SPOOL.TOSH]X.TOSH19576;1 renamed to DUA12:[UUCP.SPOOL.TOSH]REMAIL_X.TOSH19576;1 ... Roger -- brockie@golem.wcc.govt.nz ================================================================================ Archive-Date: Tue, 13 Oct 1992 21:52:21 CDT Subject: Re: Is MX over UCX lazy? Message-ID: <1bfaqqINNqej@gap.caltech.edu> From: Date: 13 Oct 1992 20:16:26 GMT Reply-To: MX-List@WKUVX1.BITNET References: <009620A8441C5360.20401486@cesi.it> To: MX-List@WKUVX1.BITNET In article <009620A8441C5360.20401486@cesi.it>, "Alberto Meregalli (SIC)" writes: >As I specified, the 'connection' was 'refused' both while sending to >the cluster alias and to the cluster nodes! >But about that, MAYBE, I have found out something: my >MX_STARTUP_INFO.DAT file looked so > >001NETLIB:* >002ROUTER:V8530 >003LOCAL:V8530 >004SMTP:V8530 >004SMTP_SERVER:V8530 >004UUCP:V8530 > >It seems to me that this is correct according to 1.2.1 in page 1-2 of >the 'Message Exchange Instllation Guide' that states that > > 'the processing agents [...]can be run on any or all > nodes of the cluster [...] and will automatically cooperate > in providing their respective services' SMTP_SERVER (the agent that was giving you trouble). isn't really a "processing agent" for the purposes of that paragraph. I admit, the documentation's not too clear about this, but if you think about it, SMTP_SERVER *MUST* be running on any node that's to accept incoming mail. Consider: If you don't run SMTP_SERVER on a particular node, then there's nothing listening on port 25. Hence, when another machine attempts to connect to port 25, your TCP/IP software will refuse the connection. This happens *BEFORE* *ANY* MX software gets involved. >But I only had all work as I changed the file to > >001NETLIB:* >002ROUTER:* >003LOCAL:* >004SMTP:* >004SMTP_SERVER:* >004UUCP:V8530 To fix the problem you reported, you merely had to change it to: 001NETLIB:* 002ROUTER:V8530 003LOCAL:V8530 004SMTP:V8530 004SMTP_SERVER:* 004UUCP:V8530 Once the SMTP_SERVER processes the message and puts it in the QUEUE, the ROUTER on any other node can handle it, and pass it along to the appropriate delivery agent on any node. >Now I have still the 'unknown host' problem, but at least not the >'connection refused' one. > >Is the statement in the Guide incorrect? have I misunderstood it? >is the trick somewhere else? It's vague, and you misunderstood it, as explained above. >>The bounces with "host unknown" don't sound like problems with the VAXes >>at all, but perhaps a configuration problem on your Sun. Including a >>copy of one of these bounce messages might help in trying to track down >>the problem. > >This is the message I get > >>From meregall Tue Oct 13 16:45:41 1992 >>Return-Path: >>Received: by sic5020.cesi.it. (4.1/SMI-4.1) >> id AB00286; Tue, 13 Oct 92 16:45:39 GMT >>Date: Tue, 13 Oct 92 16:45:39 GMT >>From: Mailer-Daemon (Mail Delivery Subsystem) >>Subject: Returned mail: Host unknown >>Message-Id: <9210131645.AB00286@sic5020.cesi.it.> >>To: meregall >>Status: R OK. It's not MX that's bouncing the mail, it's the mailer on the unix machine. >> ----- Transcript of session follows ----- >>421 Host mailhost not found for mailer ether. >>550 meregalli@decvax.cesi.it... Host unknown It can't find the host decvax.cesi.it. It would appear that the unix host is using nameservers rather than its local hosts database (if decvax is really reachable from the unix machine), or that the mailer on that system is misconfigured. Judging from other things in the bounced header, I'd guess that the unix machines mailer is very badly misconfigured. -------------------------------------------------------------------------------- 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, 14 Oct 1992 00:05:23 CDT Date: Tue, 13 Oct 1992 20:57:40 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <009620C2.955F6680.20828@swdev.si.com> Subject: More on Personal names and RFC-822 addressing I had said in an earlier message: >Currently, MX (v3.1C) places the VMS personal name in the From: header by >enclosing the name in quotes and following that with the Internet-style address >enclosed in "angle brackets." and Carl Lydick pointed out, in private mail: >No, it doesn't. It doesn't put the personal name in quotes. He then suggested: >Perhaps you've expliticly included quotes in your personal name? and in another message: >Why not simply telnet to port 25 on the machine with the mailer you want to >test? I thought this was a very good idea, so I followed his advice and this is what I've found: VMS Mail (or perhaps MX_MAILSHR) is supplying the quoted text, but only when the personal name contains a special character. We discovered this situation because an SMTP message gatewayed to Microsoft Mail (Macintosh) would have the reply address be the sender's personal name. Now, my personal name usually appears in the From: header enclosed in quotes, so I thought the gateway coouldn't handle quoted text in the From: header, hence my original posting. Also, the people on the MSMAIL side of things said that the messages were never replyable, but I demonstrated that on occasion the message was replyable. Using TELNET, I found that if the personal name is not enclosed or is enclosed in parentheses, MSMAIL used the personal name for the reply address (obviously a gateway problem), but if the personal name was enclosed in quotes, like mine usually is, MSMAIL used the internet addressing for the reply, which was correct. I'd like to thank Carl for his hint. Now, I'm guessing that it's MX_MAILSHR (or MX_MAILSHRP) adding the quotes to the From: header when there are special characters and leaving them off when there aren't. (I sent VMS Mail both ways - using a personal name with special characters and using one without. Quotes were automatically added in the first case and not in the second.) Could someone with MX source verify this? If this is the case, is there a way to get MX to always add the quotes? If it's really VMS Mail that's deciding when to add quotes, I'll take any hints on how to change its behavior instead. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Wed, 14 Oct 1992 04:11:30 CDT Date: Wed, 14 Oct 1992 09:41:41 MEZ From: Peter Kobe Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <0096212D.50B236A0.27938@PIB1.physik.uni-bonn.de> Subject: RE: Personal names and RFC-822 addressing Brian Tillman writes > I read the RFC and, although I don't understand >all I read, it seemed that a more appropriate handling of the personal name >would have been to enclose it in parentheses, since the RFC explicitly says >that >parentheses-enclosed text is treated as comments, >Could someone suggest a patch to MX to implement this behavior change? We have >a mailer here that is supposedly RFC-compliant that isn't handling the personal >name properly and I want to see if parentheses would make a difference. To do that, you get into conflict with VMS quote handling in DCL. (at least I didn't find a way to solve it) When some years ago I adapted G.Newmans MAILER for our ANJE installation, I circumvented this by letting the users use a single quote <'> intead of <"> and then have the mailer replacing it with the correct <">. I think this is a very poor solution and not generally applicable. Peter ===================================================================== Peter Kobe Internet: system@pib1.physik.uni-bonn.de Physikalisches Institut HEPNET: 13562::SYSTEM Universitaet Bonn Tel: (49) 228 73 3222 D 53 Bonn ================================================================================ Archive-Date: Wed, 14 Oct 1992 18:25:41 CDT Subject: Re: More on Personal names and RFC-822 addressing Message-ID: <1992Oct14.161616.21185@news.arc.nasa.gov> From: Date: Wed, 14 Oct 1992 16:16:16 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: usenet@news.arc.nasa.gov References: <009620C2.955F6680.20828@swdev.si.com> To: MX-List@WKUVX1.BITNET In article <009620C2.955F6680.20828@swdev.si.com>, "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: >Now, I'm guessing that it's MX_MAILSHR (or MX_MAILSHRP) adding the quotes to the >From: header when there are special characters and leaving them off when there >aren't. (I sent VMS Mail both ways - using a personal name with special >characters and using one without. Quotes were automatically added in the first >case and not in the second.) Could someone with MX source verify this? If this >is the case, is there a way to get MX to always add the quotes? MX_MAILSHR adds the quotes when required, as do all bits of MX that actually create messages. The syntax for the leading phrase is (extracted in brief from RFC822): phrase = 1*word ; Sequence of words word = atom / quoted-string atom = 1* specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word. So if your personal name contains any of the special characters listed above, it will get quoted; otherwise, quoting is unnecessary. The people who wrote the mail gateway you're using should fix it so it handles addresses correctly. Actually reading RFC822 might help; you could suggest that to them. :-) -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Wed, 14 Oct 1992 23:03:45 CDT Subject: Problem with incoming X25_SMTP messages Message-ID: <1992Oct15.143046.1@matai.vuw.ac.nz> From: Date: Thu, 15 Oct 1992 01:30:46 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: (News Admin) To: MX-List@WKUVX1.BITNET Hi, We have a problem receiving mail via X25. Some incoming messages fail with the status code %0XF4 (SYSTEM-F-ILLIOFUNC, illegal I/O function code). The messages that mail fails on have records lengths greater than 80 characters, the specific messages we've tested have 132, and 140 character record lengths. Does any one have any idea what the problem might be. -- Andrew Greer, VAX/VMS Systems Programmer -------------------------------------------------------------------------- Computing Services Centre | Domain: Andrew.Greer@vuw.ac.nz Victoria University | Phone: +64 4 495-5048 P.O. Box 600 | Fax: +64 4 471-5386 Wellington, New Zealand | STM[1]: Send "220 TOTARA MX V3.1C SMTP server ready at Thu, 15 Oct 1992 13:41:55 +1300 " STM[1]: Receive "HELO SSS.CO.NZ" STM[1]: Send "250 Hello, SSS.CO.NZ " STM[1]: Receive "MAIL FROM:" STATE=MAIL STM[1]: Send "250 MAIL command accepted." STM[1]: Receive "RCPT TO:" STM[1]: Send "250 Recipient okay (at least in form)" STM[1]: Receive "DATA" STM[1]: Send "354 Start mail input; end with ." STM[1]: Receive "Received: from SSS.CO.NZ by SSS.CO.NZ (PMDF #2910 ) id" STM[1]: Receive " <01GPUY2DFSO08ZDVTW@SSS.CO.NZ>; Mon, 12 Oct 1992 11:16:52 +1300" STM[1]: Receive "Date: Mon, 12 Oct 1992 11:16:52 +1300" STM[1]: Receive "From: Simeon Copsey - Scientific Software and Systems Ltd " STM[1]: Receive "Subject: 132 col test" STM[1]: Receive "To: simeon%sss.co.nz@VUW.AC.NZ" STM[1]: Receive "Message-id: <01GPUY2DFSO28ZDVTW@SSS.CO.NZ>" STM[1]: Receive "X-Envelope-to: simeon%sss.co.nz@VUW.AC.NZ" STM[1]: Receive "X-VMS-To: IN%"simeon%sss.co.nz@vuw.ac.nz"" STM[1]: Receive "X-VMS-Cc: SIMEON" STM[1]: Receive "MIME-version: 1.0" STM[1]: Receive "Content-type: TEXT/PLAIN" STM[1]: Receive "Content-transfer-encoding: 7BIT" STM[1]: Receive "" STM[1]: Receive "From: SSSMV4::SIMEON "Simeon Copsey - Scientific Software and Systems Ltd" 12-OCT-1992 11:11:48.04" STM[1]: Receive "To: IN%"simeon%sss.com.nz@vuw.ac.nz"" STM[1]: Receive "CC: SIMEON" STM[1]: Receive "Subj: 132 col test" STM[1]: Receive "" STM[1]: Receive "A" STM[1]: Receive " 1 2 3 4 5 6 7 8 9 0 1 2 3" STM[1]: Receive "123456789012345678901234567890123456789012345678901234567890123456789012345678 901234567890123456789012345678901234567890123456789012" STM[1]: Receive "B" STM[1]: Receive " 1 2 3 4 5 6 7 8 9 0 1 2 3" STM[1]: Receive "123456789012345678901234567890123456789012345678901234567890123456789012345678 901234567890123456789012345678901234567890123456789012" STM[1]: Receive "C" STM[1]: Receive " 1 2 3 4 5 6 7 8 9 0 1 2 3" STM[1]: Receive "123456789012345678901234567890123456789012345678901234567890123456789012345678 901234567890123456789012345678901234567890123456789012" STM[1]: Receive "D" STM[1]: Receive " 1 2 3 4 5 6 7 8 9 0 1 2 3" STM[1]: Receive "123456789012345678901234567890123456789012345678901234567890123456789012345678 901234567890123456789012345678901234567890123456789012" STM[1]: Receive "E" STM[1]: Receive " 1 2 3 4 5 6 7 8 9 0 1 2 3" STM[1]: Receive "123456789012345678901234567890123456789012345678901234567890123456789012345678 901234567890123456789012345678901234567890123456789012" STM[1]: Receive "F" STM[1]: Error: status=00F4 ================================================================================ Archive-Date: Thu, 15 Oct 1992 14:04:22 CDT Date: Thu, 15 Oct 1992 09:18:46 EDT From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: madison@tgv.com CC: mx-list@WKUVX1.BITNET Message-ID: <009621F3.47DF8980.22107@swdev.si.com> Subject: Re: More on Personal names and RFC-822 addressing Matthew Madison (madison@tgv.com) writes: >The people who wrote the mail gateway you're using should fix it so it handles >addresses correctly. Actually reading RFC822 might help; you could suggest >that to them. Thank you, Matt, for the confirmation that MX is adding the quotes. And, while I cetainly agree wholeheartedly with the above quoted statement, it doesn't help, because it doesn't solve an immediate problem. Moreover, while text not containing special characters certainly isn't required to be quoted, quoting it is also legitimate. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Thu, 15 Oct 1992 23:49:48 CDT Subject: Re: Return Address for MX Message-ID: <1992SEP30.164524.03@pegasus.ch> From: Reply-To: MX-List@WKUVX1.BITNET Date: 30 Sep 92 16:45:24 +0100 References: <009615A0.64C3C2A0.2296@DRWHO.IAC.HONEYWELL.COM> To: MX-List@WKUVX1.BITNET In message <009615A0.64C3C2A0.2296@DRWHO.IAC.HONEYWELL.COM>, kish@DRWHO.IAC.HONEYWELL.COM writes: >> Im shure this is in the DOC set but I cant seem to locate it. How is > the return address determined? Is it from the first PATH=LOCAL > or is from the transport. My problem is that we are being > reorganized and I need to change the primairy name for our host > but I would like to leave the onld name in the name space. I > have got that all working but I cant figure how to change our from > address to our current actual address. > > Karl It's in MX_DIR:MX_LOGICALS.DAT FLQ_NODE_NAME,MX_NODE_NAME, and MX_VMSMAIL_LOCALHOST Change these lines to the new names and restart MX. And voila, the new names are in affect. +-------------------+-----------------------------------+------------------+ I Ralph Kloess I E-Mail I Disclaimer: I I I Internet: Imkesun@pegasus.ch I The usual Stuff I I I PSI-Mail: -228-475212574::imkesun I I +-------------------+-----------------------------------+------------------+ ================================================================================ Archive-Date: Fri, 16 Oct 1992 07:26:07 CDT Subject: Re: Problems with UUCP and MX Message-ID: <1992Oct16.022724.759@cmkrnl.com> From: jeh@cmkrnl.com Reply-To: MX-List@WKUVX1.BITNET Date: 16 Oct 92 02:27:24 PDT References: <1bdjbmINNq28@golem.wcc.govt.nz> <1992Oct14.084936.309@cutler> To: MX-List@WKUVX1.BITNET In article <1992Oct14.084936.309@cutler>, john@cutler.com (John E. Babbitt Jr.) writes: > In article <1bdjbmINNq28@golem.wcc.govt.nz>, brockie@golem.wcc.govt.nz (Roger Brockie) writes: >> >> The following is an extract from the uucp_log:uuxqt.log file. >> Has anyone seen this problem before ? >> [...] >> $ RMAIL DUA12:[UUCP.SPOOL.TOSH]D.TOSH19576; "brockie@med.wcc.govt.nz" >> %RMS-F-FLK, file currently locked by another user >> %TRACE-F-TRACEBACK, symbolic stack dump follows >> module name routine name line rel PC abs PC >> MX_RMAIL MX_RMAIL 127 00000033 00001C47 >> $ FAILED_RMAIL: >> Attempt to send mail to failed with status %X1001828C >> %RENAME-I-RENAMED, DUA12:[UUCP.SPOOL.TOSH]X.TOSH19576;1 renamed to DUA12:[UUCP.SPOOL.TOSH]REMAIL_X.TOSH19576;1 > > If only I could've seen the first few lines of the uucp log just prior to > the above, I may have had an answer for you. > > I've seen where some uucp software attempts to send the X file first, then > the D file after. Of course, the X get processed immediately (or it used > to in pre-2.0) and one of the two things happen: 1) doesn't find the D.* > file; 2) Finds the D. file as it's being renamed from a temporary name > (and it's still locked by the renaming process). The odds of 2) happening > is very small, I must admit. > > The uucp software that sends the X first then D is called "Coherent". I've never seen this nor heard a report on it before. Mr. Babbitt's conjecture sounds like the right one. if the remote system sends the files in the correct order (D-file first) there is no way this can happen. uucico does not send back the "file received ok, what now?" message (CY message; see the protocol document) until after the rename is DONE. Until the remote sees this message it won't start to send the next file. So it looks very much as though the X-file arrived first. There is no change in 2.0 re. X-file processing -- once the X-file arrives, it gets processed. However, note what happened to the X-file -- it got renamed to REMAIL_X.whatever. It will be picked up again within an hour or so by the mail delivery retry mechanism (part of uuclean.com). By that time (!) the D file should be present. --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA uucp 'g' protocol guru and release coordinator, VMSnet (DECUS uucp) W.G., and Chair, VMS Programming and Internals Working Group, U.S. DECUS VAX Systems SIG Internet: jeh@cmkrnl.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com Uucp: ...{crash,eisner,uunet}!cmkrnl!jeh ================================================================================ Archive-Date: Mon, 19 Oct 1992 00:41:23 CDT Subject: Re: Problems with UUCP and MX Message-ID: From: Reply-To: MX-List@WKUVX1.BITNET Date: Mon, 19 Oct 1992 05:16:50 GMT Sender: (News Admin) References: <1992Oct14.084936.309@cutler> To: MX-List@WKUVX1.BITNET john@cutler.com (John E. Babbitt Jr.) writes: > > p:uxqt =< h:- [10/13-14:54:05-2020411e] Processing (DUA12:[UUCP.SPOOL.TOSH]X.TOSH19576;1) u:- > > p:uxqt << h:tosh [10/13-14:54:06-2020411e] Executing (rmail brockie@med.wcc.govt.nz < UUCP_DISK:[UUCP.SPOOL.tosh]D.TOSH19576 > NL:) u:- > > Begin X file DUA12:[UUCP.SPOOL.TOSH]X.TOSH19576;1 at 13-OCT-1992 14:54:06.46 > > $ RMAIL DUA12:[UUCP.SPOOL.TOSH]D.TOSH19576; "brockie@med.wcc.govt.nz" > > %RMS-F-FLK, file currently locked by another user > > %TRACE-F-TRACEBACK, symbolic stack dump follows > > module name routine name line rel PC abs PC > > MX_RMAIL MX_RMAIL 127 00000033 00001C47 > The uucp software that sends the X first then D is called "Coherent". > Perhaps they've fixed it by now, but it was a problem for Coherent user a > year ago. Suffice to say this user no longer runs that software. I have Coherent on a machine at home. Coh 3.1 did indeed send X files before D files, but the 3.2 and the new 4.0 releases have fixed that. Last time I saw it, "tosh" was a DOS machine running waffle, which I _thought_ did things the right way, but it may have been broken. It does look like it's receiving the X file before the D file. -- Don Stokes, ZL2TNM (DS555) don@zl2tnm.gen.nz (home) Network Manager, Computing Services Centre don@vuw.ac.nz (work) Victoria University of Wellington, New Zealand. +64-4-495-5052 ================================================================================ Archive-Date: Mon, 19 Oct 1992 10:13:30 CDT Date: 19 Oct 1992 16:03:47 +0100 From: "Alberto Meregalli (SIC)" Reply-To: MX-List@WKUVX1.BITNET Subject: MX versus DECUS UUCP rewrite rules To: vmsnet@drycas.club.cc.cmu.edu, MX-List@WKUVX1.BITNET Message-ID: <009625508640BF40.20200739@cesi.it> Hi! I have installed DECUS UUCP 2.0 and MX 3.1C. I see that both have their own rewrite rules, and I am told that, by defining a logical name, I can force MX to use DECUS UUCP rewrite rules file. But there's something that escapes me: - when exactly do rewrite rules work? - does MX use UUCP rewrite rules (if it's forced to) only for messages incoming/outgoing through UUCP or for any kind of messages? - which fields do MX 'native' rewrite rules modify? - do UUCP rewrite rules change only TO and FROM fields (that's what I have understood!) - could I have both UUCP and MX rewrite rules at work? would it be useful or only confusing? My goal is to have my VAXcluster act as a mail server with an external UUCP connection and some DECnet and TCP/IP nodes on the Ethernet. Nodes on the LAN should only know local names; users on them should exchange mail with the world through their own mail utility. Thanks in advance for any light! (I post on both MX-list and Vmsnet list) ------------------------------------------------------------------ Alberto Meregalli, SIC tel. +39 2 2125 249 Centro Elettrotecnico Sperimentale Italiano fax +39 2 2125 520 Via Rubattino, 54 - I 21034 Milano Internet: meregalli@cesi.it UUCP: ...i2unix!cesi!meregalli ================================================================================ Archive-Date: Mon, 19 Oct 1992 17:09:42 CDT Date: Tue, 13 Oct 1992 12:04:10 CDT From: "George D. Greenwade" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: madison@tgv.com Message-ID: <00962078.0DB309C0.18140@SHSU.edu> Subject: Problems purging queue We have a few problems with MX (3.1B) which I hope someone can help with. As soon as this gets straightened out, we will be moving to 3.1C since we now have MultiNet for another machine and need to change a few of the installation parameters. First, we have more than a few files which simply will not go away. FLQ PURGE, MCP QUEUE PURGE, the internal purging which is supposed to be done by the processor, etc., just don't work. The files in question are in FIN or CAN state in every class of processor (and a few of them have been that way for about a week!). If anyone can offer a suggestion, please do so as a few of these get re-processed somehow, causing (in some cases) re-posts to lists, re-requests to FILESERV, and simple (supposedly) one-time posts to be routine to users. Second, something I hope gets high on the to-do list (*please*, Hunter) is re-defining FLQ_DIR to point to a searchpath. Our QUEUE.DIR stands at 1,800+ blocks and SYSTEM_QUEUE.FLQ_CTL won't compress below 8,000+ blocks! Simple access to files is a mess due to reads required to access a directory (and, I assume, a file) of this size and seriously hurts performance. Has anyone tried to put a searchpath in the logical FLQ_DIR? Our idea was to run a routine batch job (say, every five minutes) to place files in their appropriate directory (make 0.DIR, 1.DIR,...,9.DIR subdirectories in QUEUE.DIR and place files in the numeric subdirectories based on the last digit of the filename). While it won't necessarily help SYSTEM_QUEUE.FLQ_CTL, it should help in reducing FLQ_DIR to a manageable set of searchpath sets. Might this work as a hack? Tied to this, Matt put in a feature to process the smallest files in a queue first. Is there any way to turn this off? Rather than have to go back and evaluate everything, might it be possible to go back to the old way and simply process files sequentially? I may be wrong on this, but it seems as if quite a few less reads on the QUEUE.DIR directory. Finally, Matt also made a *real* enhancement in not copying files served by servers to QUEUE.DIR some time back. From something recently, I assume that this is accomplished by something along the lines of SET FILE. What happened was that a directory was updated, with the old files deleted and superseded by new files of the same name. When the MLF processor got around to sending those files, it couldn't find them and gave FILESERV-Mgr a bunch of mail to this effect. Might it be possible to take the most current version of a file for MLF use? I realize that this has become a wish list of sorts. The REAL question I have to deal with is how to get rid of the files completed which need to be gotten rid of. Regards and thanks in advance, George %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% George D. Greenwade, Ph.D. Bitnet: BED_GDG@SHSU Department of Economics and Business Analysis THEnet: SHSU::BED_GDG College of Business Administration Voice: (409) 294-1266 P. O. Box 2118 FAX: (409) 294-3612 Sam Houston State University Internet: bed_gdg@SHSU.edu Huntsville, TX 77341 bed_gdg%SHSU.decnet@relay.the.net %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% ================================================================================ Archive-Date: Mon, 19 Oct 1992 17:24:29 CDT Subject: MAILPATCH broken under VMS v5.5-2 Message-ID: <1992Oct19.184059.28726@news.Hawaii.Edu> From: Reply-To: MX-List@WKUVX1.BITNET Date: Mon, 19 Oct 1992 18:40:59 GMT Sender: (Henry Stilmack) To: MX-List@WKUVX1.BITNET The patch provided by Claude Barbe which allows RFC-822 - style addresses under VMS Mail WILL FAIL if you try to patch the new MAILSHR.EXE installed by the VMS v5.5-2 upgrade. To fix the patch file, add the following: ! For VMS 5.0 only, uncomment the following 6 lines and comment another 6 lines ! below. ! ! If you patch, VMS 5.0, it is different from the following VMS versions ! MAIL$$ADD_ADDR is located at 000049C2 and ! ADD_ADDR is located at 000048EF ! then uncomment the following 6 lines and comment out 6 similar lines below !DEF !MAIL$$ADD_ADDR !000049C2 !ADD_ADDR !000048EF !EXI ! ! If you patch any versions from VMS 5.1 to T5.4-4 including 5.1 and 5.2, all ! appear to have identical MAIL$$ADD_ADDR always located at 000049D2 and ! calling ADD_ADDR always located at 000048FF ! For VMS 5.0 comment out the following 6 lines and uncomment 6 lines above ! !DEF !MAIL$$ADD_ADDR !000049D2 !ADD_ADDR !000048FF !EXI ! !****** ADD THESE NEXT LINES ****** ! For V5.5-2, it looks like MAIL$$ADD_ADDR is at 000049DA, so modify the patch ! and comment out the above: ! DEF MAIL$$ADD_ADDR 000049DA ADD_ADDR 00004907 EXI ! (This at least works for VMS v5.5-2HW which DEC claims is the same as the soon-to-be-released v5.5-2) Cheers, -- ______________________________________________________________________________ Henry Stilmack ) Computing Systems Manager ) "Haven't you heard, UK/Netherlands/Canada Joint Astronomy Centre ) it's a battle of words - 660 N. A'ohoku Place, Hilo, HI 96720 ) and most of them are lies..." hps@jach.Hawaii.Edu 808-969-6546 ) ------------------------------------------------------------------------------ ================================================================================ Archive-Date: Fri, 23 Oct 1992 05:56:32 CDT Date: Thu, 22 Oct 1992 15:56:50 CET From: Hans-Joachim Koch Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: sys_hjk@lifra.lif.de Message-ID: <009627AB.0C985880.10051@lifra.lif.de> Subject: SMTP accounting question Hello, I did not see me question in the News until now - just wondering if there is a great backlog or if I made something wrong... > From: JANUS::SYS_HJK "Hans-Joachim Koch" 8-OCT-1992 15:18:09.51 > To: MX%"mx-list@wkuvx1.bitnet" > CC: SYS_HJK > Subj: SMTP accounting question > > Hello all, > > I have a small problem with the MX smtp accounting. > > Accounting lines look like this: > > 8-OCT-1992 10:39 XMIT: PROTO=SMTP, SOURCE="", > HOST="SUNNY.LIF.DE", BYTES_SENT=1510 > > Node LIFRA is our VMS system running VMS5.4-2, Multinet 3.1 and MX 3.1c. > Node SUNNY is a Sparc-1 station running in our ethernet and connected to > the EUnet via ISDN. > > The last path config line says "domain *, path=smtp, route=sunny.lif.de". > > My question is: is it possible to get the REAL address into the smtp > accounting instead of the router address. In the above example I would > like to see: > > 8-OCT-1992 10:39 XMIT: PROTO=SMTP, SOURCE="", > HOST="user@anywhere.world", BYTES_SENT=1510 > > Any hints? > Thanks. Hans. -- Hans-Joachim Koch, Computer department of Lahmeyer International Lyoner Strasse 22, POB 71 06 51, D-6000 Frankfurt (Main) 71, Germany Phone: +49 69 6677-642, Fax: +49 69 6677-571, Tx: 413478 li d Email: koch@lifra.lif.de, dk9om@dk9om.ampr.org [44.130.25.45] ================================================================================ Archive-Date: Sat, 24 Oct 1992 00:05:16 CDT From: daveh@vax.oxford.ac.uk Reply-To: MX-List@WKUVX1.BITNET Subject: MX performance questions Message-ID: <1992Oct22.104651.9701@vax.oxford.ac.uk> Date: 22 Oct 92 09:46:51 GMT To: MX-List@WKUVX1.BITNET Hi, A couple of questions about MX: 1. Why is the queue file so large (currently ours is over 9500 blocks)? What is in it? 2. According to the user guide space in the queue file is reclaimed one a day by default. Is there any advantage in reducing the time interval between reclaims? 3. The mailqueue program seems to take several minutes to run. Is this normal? We are running VMS 5.5-1 and MX 3.1C Thanks in advance for any help, Dave -- David Hastings | "Imposition of order=escalation of chaos" VAX Systems Programmer | Oxford University Computing Services| "Just when you think you've won the daveh@vax.oxford.ac.uk | rat race, along come faster rats" ================================================================================ Archive-Date: Sat, 24 Oct 1992 00:05:29 CDT Subject: Re: MX performance questions Message-ID: <1992Oct23.171651.26650@news.arc.nasa.gov> From: Date: Fri, 23 Oct 1992 17:16:51 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: usenet@news.arc.nasa.gov References: <1992Oct22.104651.9701@vax.oxford.ac.uk> To: MX-List@WKUVX1.BITNET In article <1992Oct22.104651.9701@vax.oxford.ac.uk>, daveh@vax.oxford.ac.uk writes: >A couple of questions about MX: > >1. Why is the queue file so large (currently ours is over 9500 blocks)? What is > in it? It is an RMS indexed file that contains information about each queue entry. >2. According to the user guide space in the queue file is reclaimed one a day by > default. Is there any advantage in reducing the time interval between > reclaims? Yes. See #3. Having the queue reclaims occur more frequently generally speeds up queue access. >3. The mailqueue program seems to take several minutes to run. Is this normal? No. I suggest you shut down all MX processes and manually perform a reclaim pass on the queue file: MCP> SHUTDOWN MCP> QUEUE RECLAIM I think you can add a /LOG qualifier to the QUEUE RECLAIM command to find out how much space was reclaimed. This should speed up the queue search programs considerably. Alternatively, you may wish to use CONVERT to create a new version of the file, which will wind up being a lot smaller (although it will grow again with use). Command procedures to do this automatically have been posted here before; maybe someone will post theirs again. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Mon, 26 Oct 1992 02:50:07 CST Date: 26 Oct 1992 09:25:12 +0100 From: "Alberto Meregalli (SIC)" Reply-To: MX-List@WKUVX1.BITNET Subject: MX versus DECUS UUCP rewrite rules To: vmsnet@drycas.club.cc.cmu.edu, MX-List@WKUVX1.BITNET Message-ID: <00962A9900116020.20201D5C@cesi.it> Hi! I re-post this, as I've got no answer since a week and I have some clue that E-mail has not been working too well here these days. I'm sorry if any replies were lost! I have installed DECUS UUCP 2.0 and MX 3.1C. I see that both have their own rewrite rules, and I am told that, by defining a logical name, I can force MX to use DECUS UUCP rewrite rules file. But there's something that escapes me: - when exactly do rewrite rules work? - does MX use UUCP rewrite rules (if it's forced to) only for messages incoming or outgoing through UUCP or for any kind of messages? - which fields do MX 'native' rewrite rules modify? - do UUCP rewrite rules change only TO and FROM fields (that's what I have understood!)? - could I have both UUCP and MX rewrite rules at work? would it be useful or only confusing? My goal is to have my VAXcluster act as a mail server with an external UUCP connection and some DECnet and TCP/IP nodes on the Ethernet. Nodes on the LAN should only know local names; users on them should exchange mail with the world through their own mail utility. Thanks in advance for any light! (I post on both MX-list and Vmsnet list) ------------------------------------------------------------------ Alberto Meregalli, SIC tel. +39 2 2125 249 Centro Elettrotecnico Sperimentale Italiano fax +39 2 2125 520 Via Rubattino, 54 - I 21034 Milano Internet: meregalli@cesi.it UUCP: ...i2unix!cesi!meregalli ================================================================================ Archive-Date: Mon, 26 Oct 1992 05:35:23 CST Date: 26 Oct 1992 12:23:17 +0100 From: "Alberto Meregalli (SIC)" Reply-To: MX-List@WKUVX1.BITNET Subject: rewrite rules To: vmsnet@drycas.club.cc.cmu.edu, MX-List@WKUVX1.BITNET Message-ID: <00962AB1E10E7F00.20201D5C@cesi.it> Hi! I have MX 3.1C working with DECUS UUCP 2.0. I see some strange 'From' addresses: this is from a mx_rmail_log.log file >26-OCT-1992 11:33:54.69 RMAIL: Input file opened, now looking for From_ line(s). >26-OCT-1992 11:33:54.73 RMAIL: Read: From san-ben!renato Mon Oct 26 ^^^^^^^^^^^^^^ 11:14:47 1992 remote from i2unix ^^^^^^ >26-OCT-1992 11:33:54.73 RMAIL: This is a From_ line, host=i2unix, user=san-ben!renato >26-OCT-1992 11:33:54.74 UUCP_TO_MX: UUCP rewrite transformed i2unix!san-ben!renato to i2unix!san-ben!renato ^^^^^^^^^^^^^^^^^^^^^ >26-OCT-1992 11:33:54.76 RMAIL: Sender string now reads <@i2unix.UUCP:renato@san-ben.UUCP> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ??? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >26-OCT-1992 11:33:54.76 RMAIL: Read: Received: from dist.dist.unige.it by relay.iunet.it with SMTP >26-OCT-1992 11:33:54.76 RMAIL: No more From_ lines. This is from another similar log >26-OCT-1992 11:32:09.97 RMAIL: Now ensuring addresses are 822-compliant... >26-OCT-1992 11:32:10.03 UUCP_TO_MX: UUCP rewrite transformed i2unix!decvax!"mvax1::meregalli" to i2unix!decvax!"mvax1::meregalli" ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >26-OCT-1992 11:32:10.04 RMAIL: i2unix!decvax!"mvax1::meregalli" => "mvax1::meregalli"%decvax.UUCP%i2unix.UUCP@cesi.it ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ??? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >26-OCT-1992 11:32:10.08 UUCP_TO_MX: UUCP rewrite transformed cesi!"mvax1::meregalli" to cesi!"mvax1::meregalli" ^^^^^^^^^^^^^^^^^^^^^^^ >26-OCT-1992 11:32:10.09 RMAIL: cesi!"mvax1::meregalli" => "mvax1::meregalli"%cesi.UUCP@cesi.it ^^^^^^^^^^ ??? ^^^^^^^^^^ >26-OCT-1992 11:32:10.12 UUCP_TO_MX: UUCP rewrite transformed i2unix!decvax.cesi.it!"mvax1::meregalli" to i2unix!decvax.cesi.it!"mvax1::meregalli" >26-OCT-1992 11:32:10.15 RMAIL: i2unix!decvax.cesi.it!"mvax1::meregalli" => "mvax1::meregalli"@decvax.cesi.it >26-OCT-1992 11:32:10.20 UUCP_TO_MX: UUCP rewrite transformed i2unix!sic5020.cesi.it!meregall to meregall@sic5020 >26-OCT-1992 11:32:10.21 RMAIL: i2unix!sic5020.cesi.it!meregall => meregall%sic5020@cesi.it I include also my only MX rewrite rule: >Address-rewriting rules: > Rewrite "<{user}@mvax1.cesi.it>" => "<""mvax1::{user}""@decvax>" And my MAIL_REWRITE.RULES DECUS UUCP file (I think there is much junk in it but I'm still trying to understand) -------------------------------------------------------------- # # cesi.it domain gateway rules. # # cesi.it will "alias" to the VAXCluster # [INBOUND-TO] *@cesi.it \001 *%cesi.it \001 cesi.it!* \001 cesi!* \001 [OUTBOUND-FROM] # -- No outbound rules required # # decvax.cesi.it is the fully qualified domain name for the VAXCluster # [INBOUND-TO] *@decvax.cesi.it \001 *%decvax.cesi.it \001 decvax.cesi.it!* \001 [OUTBOUND-FROM] decvax::* \001@decvax.cesi.it # # # non vogliamo che nessuno esca con i nomi dei singoli vax # [INBOUND-TO] *@decvax.cesi.it \001 *%decvax.cesi.it \001 decvax.cesi.it!* \001 [OUTBOUND-FROM] v6000::* \001@decvax.cesi.it v8530::* \001@decvax.cesi.it # # # i nodi DECnet ... # [INBOUND-TO] *@mvax1.cesi.it mvax1::\001 mvax1.cesi.it!* mvax1::\001 [OUTBOUND-FROM] mvax1::* \001@mvax1.cesi.it #[OUTBOUND-TO] #*@mvax1.cesi.it mvax1::\001 # # # i nodi internet della rete devono essere raggiungibili col loro nome # [INBOUND-TO] *@sic5020.cesi.it \001@sic5020 *!sic5020.cesi.it!* \002@sic5020 sic5020.cesi.it!* \001@sic5020 [OUTBOUND-FROM] *@sic5020 \001@sic5020.cesi.it *@sic5020. \001@sic5020.cesi.it *!sic5020!* \002@sic5020.cesi.it *!sic5020.!* \002@sic5020.cesi.it sic5020!* \001@sic5020.cesi.it sic5020.!* \001@sic5020.cesi.it #[OUTBOUND-TO] ##*@sic5020.cesi.it \001@sic5020 #[INBOUND-FROM] ##*@sic5020.cesi.it \001@sic5020 # # # end of cesi.it domain gateway rules -------------------------------------------------------------- I thank in advance for any help. (I post on both MX-list and Vmsnet list) ------------------------------------------------------------------ Alberto Meregalli, SIC tel. +39 2 2125 249 Centro Elettrotecnico Sperimentale Italiano fax +39 2 2125 520 Via Rubattino, 54 - I 21034 Milano Internet: meregalli@cesi.it UUCP: ...i2unix!cesi!meregalli ================================================================================ Archive-Date: Mon, 26 Oct 1992 16:37:07 CST Subject: Re: MX versus DECUS UUCP rewrite rules Message-ID: <1992Oct26.182207.20989@news.arc.nasa.gov> From: Date: Mon, 26 Oct 1992 18:22:07 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: usenet@news.arc.nasa.gov References: <00962A9900116020.20201D5C@cesi.it> To: MX-List@WKUVX1.BITNET In article <00962A9900116020.20201D5C@cesi.it>, "Alberto Meregalli (SIC)" writes: >I see that both have their own rewrite rules, and I am told that, by >defining a logical name, I can force MX to use DECUS UUCP rewrite >rules file. Correct. >But there's something that escapes me: > >- when exactly do rewrite rules work? UUCP rewrite rules are called on by MX in the MX_RMAIL program. Only the INBOUND-FROM and INBOUND-TO rules are used by MX. >- does MX use UUCP rewrite rules (if it's forced to) only for messages > incoming or outgoing through UUCP or for any kind of messages? Just for UUCP messages. >- which fields do MX 'native' rewrite rules modify? Only the "envelope" TO-fields. Those rewrite rules are applied to all messages passing through MX. >- do UUCP rewrite rules change only TO and FROM fields (that's what I > have understood!)? MX_RMAIL will apply the UUCP rewrite rules to all headers that contain addresses, as well as the envelope addresses. >- could I have both UUCP and MX rewrite rules at work? would it be > useful or only confusing? Yes. I think people who currently use both UUCP and MX will find that using the UUCP rewrite rules to preprocess addresses into RFC822 (user@host) form will probably get cleaner-looking addresses. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Tue, 27 Oct 1992 07:22:46 CST From: roseberry@taney.uscghq.uscg.mil Reply-To: MX-List@WKUVX1.BITNET Subject: Does MX truncate Long Lines ? Message-ID: <1992Oct27.064515.86@taney.uscghq.uscg.mil> Date: 27 Oct 92 06:45:15 EST To: MX-List@WKUVX1.BITNET We have a very odd UNISYS B-series computer that we are trying to get to communicate with our VAX. One of the "features" of the UNISYS native mail system that gets transformed into SMTP is very long lines of text in the message with no s. It looks like the RFC says that lines can be up to 1000 bytes long. When I got the following mail it was truncated on the line that starts with "Perot:". Is MX V3.1C truncating the lines of text and what can I do to prevent that from happening ? Here's my log file. STM[4]: Send "220 TANEY.USCGHQ.USCG.MIL MX V3.1C SMTP server ready at Mon, 26 Oct 1992 13:21:46 EST" [Stuff Deleted] STM[4]: Receive "" STM[4]: Receive "Actually, what the presidental Candidates meant to say was:" STM[4]: Receive "" STM[4]: Receive "Bush: "Read my lips. The sky is blue. It will never be any other color. Never, never, never, never, never."" STM[4]: Receive "" STM[4]: Receive "Clinton: "I support the sky being blue. In fact, when I go out there and talk to the sky, I feel the pain the sky feels being blue. In fact the sky has never been bluer in the past 50 years since the great depression." STM[4]: Receive "" STM[4]: Receive "Perot: "Is it my turn? Okay. The sky is blue and it's going to stay that way until we all come together and roll up our sleeves and make it some other color. You see, I'm not changing the color of the sky for me, I'm going to do it for STM[4]: Receive "" STM[4]: Receive "." STM[4]: Send "250 Message received and queued." STM[4]: Receive "QUIT" STM[4]: Send "221 TANEY.USCGHQ.USCG.MIL Service closing transmission channel" STM[4]: Receive "QUIT" Thanks for your time. - Bert Roseberry US Coast Guard roseberry@taney.uscghq.uscg.mil ================================================================================ Archive-Date: Tue, 27 Oct 1992 11:24:02 CST Date: Tue, 27 Oct 1992 17:49:10 MEZ From: Peter Kobe Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00962BA8.91F43840.2305@PIB1.physik.uni-bonn.de> Subject: distribution lists Sending messages to a distribution list can be a problem, if you use the examples given in the VMS MAIL UTILITY MANUAL page 6 and 7. I.e if one uses comments in the the lines. Here is an example The list: MX%"system@pib1.physik.uni-bonn.de" !use the MX-MAILER system !the direct message kobe !use a forwarding address, I don't expect this message psi%45050211211::system !have psi MX%"system@pib3.physik.uni-bonn.de" !another node in the cluster send mail with mail/subj=listproblems test.dis "@test.dis" What you get is: 2 MX-Messages, 1 PSI-Message and 1 direkt MAIL Message The TO:-Lines in the MX-messages are corrupted and very long(>80), so won't go through all gateways. The nice thing is, MX doesn't mind the corrupted To-field. I just gives a warning. Here are the received headers 1) Date: 27-OCT-1992 17:31:58.11 From: MX%"system@PIB1.physik.uni-bonn.de" Subj: LISTPROBLEME To: SYSTEM CC: Return-Path: Received: by PIB1.physik.uni-bonn.de (MX V3.1B) id 2296; Tue, 27 Oct 1992 17:31:47 MEZ Date: Tue, 27 Oct 1992 17:31:47 MEZ From: Peter Kobe X-MX-Warning: Warning -- Invalid "To" header. To: X%"system@pib3.physik.uni-bonn.de" !another node in the cluste, si%45050211211::system !have ps, obe !use a forwarding addres, ystem !the direct messag, X%"system@pib1.physik.uni-bonn.de" !use the MX-MAILE Message-ID: <00962BA6.244BA0A0.2296@PIB1.physik.uni-bonn.de> Subject: LISTPROBLEME 2) Date: 27-OCT-1992 17:32:05.27 From: MX%"system@PIB1.physik.uni-bonn.de" Subj: LISTPROBLEME To: SYSTEM CC: Return-Path: Received: by PIB1.physik.uni-bonn.de (MX V3.1B) id 2296; Tue, 27 Oct 1992 17:31:47 MEZ Date: Tue, 27 Oct 1992 17:31:47 MEZ From: Peter Kobe X-MX-Warning: Warning -- Invalid "To" header. To: X%"system@pib3.physik.uni-bonn.de" !another node in the cluste, si%45050211211::system !have ps, obe !use a forwarding addres, ystem !the direct messag, X%"system@pib1.physik.uni-bonn.de" !use the MX-MAILE Message-ID: <00962BA6.244BA0A0.2296@PIB1.physik.uni-bonn.de> Subject: LISTPROBLEME ===================================================================== Peter Kobe Internet: system@pib1.physik.uni-bonn.de Physikalisches Institut HEPNET: 13562::SYSTEM Universitaet Bonn Tel: (49) 228 73 3222 D 53 Bonn FAX: (49) 228 73 7869 Nussallee 12 ================================================================================ Archive-Date: Tue, 27 Oct 1992 11:29:56 CST Sender: goathunter@WKUVX1.BITNET Date: Tue, 27 Oct 1992 11:29:27 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET CC: fsupdate@WKUVX1.BITNET Message-ID: <00962B73.85C65740.29466@WKUVX1.BITNET> Subject: New MX utility: MX-DIGEST A few weeks ago, I took over the Info-Zip list. The people on that list were accustomed to having a digest and threw baby-fits when I said I wasn't going to do digests. Well, I relented, thinking that maybe other people could use them to. I just finished adding MX-DIGEST to FILESERV@WKUVX1.BITNET. MX-DIGEST contains two programs to allow Message Exchange (MX) to produce digests for MX mailing lists (like MX-List and FSUPDATE). The program that does most of the work was written by David A. Currey for UN*X. I modified it to work under VMS with MX and also wrote the other MX stuff. To get MX-DIGEST via e-mail, send the following commands in the body of a mail message to FILESERV@WKUVX1.BITNET: SEND MX-DIGEST SEND FILESERV_TOOLS To get it via anonymous ftp from ftp.spc.edu, you'll need: [.MACRO32]UNZIP.EXE [.MACRO32.SAVESETS]MX-DIGEST.ZIP Note: the MX and UUCP file server (MXSERVER) has been removed here. MX031 and UUCP020 are now available from FILESERV. Any mail directed to MXSERVER will automatically be forwarded to FILESERV. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Tue, 27 Oct 1992 11:51:53 CST Date: Tue, 27 Oct 1992 11:09:04 EST From: "Brian Tillman, Smiths Industries, VAX Support, x8425" Reply-To: MX-List@WKUVX1.BITNET To: mx-list@WKUVX1.BITNET Message-ID: <00962B70.ACEC57A0.1074@swdev.si.com> Subject: Re: MX versus DECUS UUCP rewrite rules In response to Alberto Meregalli about the interaction between MX and UUCP rewrite rules, Matt Madison says: >>- does MX use UUCP rewrite rules (if it's forced to) only for messages >> incoming or outgoing through UUCP or for any kind of messages? > >Just for UUCP messages. Does this mean that I must be running UUCP on the node where the MX router is and be using the MX UUCP channel? I ask this because Matt also says: >MX_RMAIL will apply the UUCP rewrite rules to all headers that contain >addresses, as well as the envelope addresses. and >Yes. I think people who currently use both UUCP and MX will find that >using the UUCP rewrite rules to preprocess addresses into RFC822 (user@host) >form will probably get cleaner-looking addresses. Is MX_RMAIL supplied with UUCP? Could it be used for incoming SMTP messages from a Sun system running UUCP (our internet connection is through UUNET/UUCP)? -----------------------------+-------------------------------- Brian Tillman | Internet: tillman@swdev.si.com Smiths Industries, Inc. | tillman_brian@si.com 4141 Eastern Ave., MS129 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Tue, 27 Oct 1992 19:11:32 CST Subject: Re: MX versus DECUS UUCP rewrite rules Message-ID: <1992Oct28.000352.5840@news.arc.nasa.gov> From: Date: Wed, 28 Oct 1992 00:03:52 GMT Reply-To: MX-List@WKUVX1.BITNET Sender: usenet@news.arc.nasa.gov References: <00962B70.ACEC57A0.1074@swdev.si.com> To: MX-List@WKUVX1.BITNET In article <00962B70.ACEC57A0.1074@swdev.si.com>, "Brian Tillman, Smiths Industries, VAX Support, x8425" writes: >Does this mean that I must be running UUCP on the node where the MX router is >and be using the MX UUCP channel? I ask this because Matt also says: > >>MX_RMAIL will apply the UUCP rewrite rules to all headers that contain >>addresses, as well as the envelope addresses. MX_RMAIL is part of MX. It's the program that UUCP invokes to get a message into MX. You don't have to run the MX Router on the same node as you run UUCP. And UUCP rewrite rules cannot be applied to anything but messages coming in from UUCP. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Wed, 28 Oct 1992 17:53:26 CST Sender: p_rand@luke.spu.edu Date: Wed, 28 Oct 1992 11:36:17 PST From: "Phil Rand, SPU CIS, (206) 281-2428" Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Message-ID: <00962C3D.A4D2BD20.10884@luke.spu.edu> Subject: UUCP gateway through UUNET On p. 3-2 of the _Message_Exchange_Management_Guide_ V3.1, is an example of commands to create a typical path list, including: MCP> DEFINE PATH *.UUCP SMTP/ROUTE=uunet.uu.net We've had this path defined for a while, and I know that at least one of our users has made use of it successfully. I've just found out, though, that UUNET really expects sites to pay for this UUCP gateway service. I have subscription information from UUNET on the way to me in postal mail, but they've already told me the cost is $55/month for sites already on the internet, like us. That seems kind of steep for our low volume of anticipated UUCP traffic. I understand the service includes a USENET news feed, which I don't expect to need because we'll be getting our feed from another source. What do other internet sites do about low-volume UUCP traffic? Is UUNET a better deal than I think it is? Are there free gateways? I'd rather not set up our own UUCP hub, since it sounds like a lot of work for little benefit. I'd appreciate any suggestions. ----------------------------------------------------------------------- Phil Rand p_rand@luke.spu.edu (206) 281-2428 Computer and Information Systems Seattle Pacific University 3307 3rd Ave W Seattle, WA 98119 ----------------------------------------------------------------------- ================================================================================ Archive-Date: Thu, 29 Oct 1992 08:30:33 CST Date: 29 Oct 1992 08:58:27 -0400 (EDT) From: "G. Del Merritt" Reply-To: MX-List@WKUVX1.BITNET Subject: Re: UUCP gateway through UUNET To: MX-List@WKUVX1.BITNET, p_rand@luke.spu.edu Message-ID: <00962CF0C271A7C0.24C007C9@giant.IntraNet.com> >Date: 28 Oct 1992 11:36:17 -0800 (PST) >From: "Phil Rand, SPU CIS, (206) 281-2428" >I've just found out, though, that UUNET really expects sites to pay for this >UUCP gateway service. I have subscription information from UUNET on the way UUNET is offering a commercial service to "usenet" hosts. Part of that service happens to be providing a MAIL gateway to the Internet. It is my third-hand understanding that, while they can legitimately require a fee for "direct" connection to their modem pool (or one of the modem pool hubs), they cannot really require folk who don't connect directly to pay anything; this is part of their being a good Internet neighbor. I heard once that it's because of this "good neighbor" aspect that they can derive commercial gain soley from the fact that they provide access to the Internet. Their service (and PSI's, and others I don't know/remember) is valuable for a number of reasons (it's a source archive site, provides SLIP access to the "real" Internet, etc). But if you "just" want to exchange mail, you never need exchange $'s for bytes with UUNET if you have access to any other gateway. Logistically, this would prove untenable for their paying customers, since a) the paying folk could send mail to me, but b) I couldn't respond! Our record alone won't cut it. -- White House Chief of Staff Sam Skinner to his staff, on the importance of negative campaigning in the 1992 election. Del Merritt del@IntraNet.com ccavax!giant!del IntraNet, Inc., 255 Washington Street, Newton, MA 02158 Voice: 617-527-7020; FAX: 617-527-6779 ================================================================================ Archive-Date: Thu, 29 Oct 1992 16:44:22 CST Subject: MX 3.1 Message-ID: <4388@winnie.fit.edu> From: Reply-To: MX-List@WKUVX1.BITNET Date: 29 Oct 92 19:45:57 GMT Sender: usenet@winnie.fit.edu To: MX-List@WKUVX1.BITNET Hello fellow netters, Was preparing to install this new toy and was wondering if: (1) it will run on VMS 5.5-1? (2) it is compatible with UCX 2.0? (3) it uses a queue, like UCX's version of SMTP? Thanks in advance. -- .-.| | | | | /------------------\ Karin Nicholson | |-..-.|/.-.|-..-.|*|/ < karin@zach.fit.edu > VAX Sys Mgr @ Florida Tech `-'| |`-'|\`-'| |`-'|||\ \------------------/ Florida Space Coast LUG Chair ================================================================================ Archive-Date: Thu, 29 Oct 1992 16:52:37 CST Sender: goathunter@WKUVX1.BITNET Date: Thu, 29 Oct 1992 16:51:35 CST From: Hunter Goatley Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET CC: karin@zach.fit.edu Message-ID: <00962D32.DAFB10A0.30003@WKUVX1.BITNET> Subject: RE: MX 3.1 writes: > >Hello fellow netters, > >Was preparing to install this new toy and was wondering if: > The latest version of MX is V3.1C. If you picked it up from ftp.spc.edu, that's what you have. > (1) it will run on VMS 5.5-1? > Yes. > (2) it is compatible with UCX 2.0? > Yes. > (3) it uses a queue, like UCX's version of SMTP? > It provides its owning queuing for file processing. It does not use any batch queues for any reason. I've never looked at the UCX SMTP stuff, so I can't really compare them. Hunter ------ Hunter Goatley, VMS Systems Programmer, Western Kentucky University goathunter@WKUVX1.BITNET, 502-745-5251 ================================================================================ Archive-Date: Fri, 30 Oct 1992 12:06:42 CST Subject: Problems with MX% referenced through a logical Message-ID: <1992Oct30.164715.278@logica.co.uk> From: Date: 30 Oct 92 16:47:14 GMT Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET We are currently in the process of setting up a mail gateway between our company wide All-in-1 mail network and MX with CMU-Tek TCP/IP for SMTP connections to internet nodes. We have come across the MRGATE logical defined for DEC's All-in-1 to VMSmail gatewaying function. This logical is defined /SYS/EXEC to be "MR%" and appears to deliver mail of the form MRGATE::"funny foreign address" to MR% which is then further re-defined using MAIL$PROTOCOL_MR to point at MRFROMVMS.EXE as the foreign protocol handler. Since the VIRTUAL_GATEWAY_NODE::"address" format seemed more intuitive for our users and could make addressing easier from All-in-1 through the gateway, we tried defining a logical MXGATE /SYS/EXEC "MX%". We would eventually like to define something like INTERNET as a system logical on each of our VMS boxes which would simply be "MXGATE" on nodes with MX running and perhaps MX_NODE::MXGATE for VMS nodes without MX running. Sending mail from VMSmail on pluto to MXGATE::"gerry@pluto.logica.co.uk" (a loopback test through MX) currently produces RFC822 headers that look like: From: Gerry Magennis To: "mxgate::\"gerry@pluto.logica.co.uk\""@pluto.logica.co.uk which does get through but has this funny return address on it. Is there some mechanism I can use to have MX understand that it is being sent mail using this form of logical indirection and have it produce "correct" format return addresses? I've been following the threads on having MX correctly handle IN%, SMTP%, etc and would like to know whether this ability to "emulate" other mail deliver interfaces extends to handling my sort of logical addresses. I'm aware of the address re-writing rules but these are only for the TO: envelope address (I think). I also know about the NAME_CONVERSION.C routines but can't (yet) program very well in C and would like to find some "hidden" MX functionality to handle this. Thanks in advance, Gerry ------------------------------------------------------------------------------- Gerard Magennis | Logica Industry Ltd, London UK | Internet: gerry@logica.co.uk ================================================================================ Archive-Date: Fri, 30 Oct 1992 13:41:54 CST From: Reply-To: MX-List@WKUVX1.BITNET Subject: Integrating UUBATCH into DECUS UUCP. Message-ID: <1992Oct30.105542.4661@dmc.com> Date: 30 Oct 92 10:55:42 EST To: MX-List@WKUVX1.BITNET I'm thinking of integrating UUBATCH into DECUS UUCP and I can think of three ways to do it, each of which has advantages and disadvantages. [For those that don't know about UUBATCH, it's a way to batch the UUCP files so they go out in a single file instead of a BUNCH of files. The net result is a higher bandwidth on your UUCP links.] 1. Do it pretty much the way UUBATCH is done on U*X. This is essentially a batch process that comes along every so once in a while, scans UUCP_SPOOL: for work to do, and batches the files. This is probably what I'll do FIRST in any event, just to get the port of the UUBATCH stuff done and to test out linkages to my neighbors. The biggest problem with this solution is that it doesn't scale too well. As the number of systems goes up, the amount of work UUBATCH has to do just to figure out what to do goes up a lot too. Big installations doing a lot of UUCP work couldn't use this as a long term solution. 2. Integrate it into MX. I'm actually rather attracted to this solution as you could think of the whole thing as a kind of new path to a site. I haven't looked too closely at the router and delivery agents to see what this would actually entail, so I'm soliciting comments from the MX experts. If there was no other way, DECUS UUCP would require MX to provide batching, so this isn't a great solution. In all likelyhood, the U*x style UUBATCH solution would have to be provided as well. On the other hand, it WOULD scale rather nicely (or at least as well as MX would), so large UUCP sites would be able to use it. 3. Integrate it into UUCP_mailshr Which, I suppose, is the BEST solution, the only thing is I really think that it would be a royal pain to actually put in here as it would require, at the very least, some sort of ad hoc data base describing the down stream capablities of each site in the SYSTEMS. file. So, the question before the MX and UUCP guru's is: a. Is this worth doing? b. If so, is it already being done, in which case, do you need any help. c. If it is not already being done, what are, from your perspective, the pros and cons of the three approaches? d. Did I miss any other possible way to do the integration? I'm eagerly awaiting your comments. -- Dick Munroe Internet: munroe@dmc.com Doyle Munroe Consultants, Inc. UUCP: ...uunet!thehulk!munroe 267 Cox St. Office: (508) 568-1618 Hudson, Ma. FAX: (508) 562-1133 GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection. ================================================================================ Archive-Date: Fri, 30 Oct 1992 18:53:21 CST Subject: NAME_CONVERSION.* Message-ID: <1992Oct31.001219.20448@rz.uni-karlsruhe.de> From: Reply-To: MX-List@WKUVX1.BITNET Date: Sat, 31 Oct 1992 00:12:19 GMT Sender: (USENET News System) To: MX-List@WKUVX1.BITNET Hello alltogether... I saw that NAME_CONVERSION rewrites DECnet addresses to more readable SMTP addresses HOST::USER --> USER%HOST.dnet Is it possible to add in a later version the same functionality for P.S.I. addresses ? Or even better for mixtures of P.S.I., DECnet and MRGATE ? I solved it quick and dirty for the moment but i am interested in a more useable implementation... Thanks, Bernd Onasch Bernd Onasch, Informatik Rechnerabteilung [IRA], University of Karlsruhe [FRG] E-MAIL: or or or (Rest of signature deleted by an anti-signature virus) ================================================================================ Archive-Date: Fri, 30 Oct 1992 21:30:15 CST Subject: Re: Integrating UUBATCH into DECUS UUCP. Message-ID: <1992Oct30.171826.17878@infocomm.com> From: mark@infocomm.com Reply-To: MX-List@WKUVX1.BITNET Date: 30 Oct 92 17:18:26 PDT References: <1992Oct30.105542.4661@dmc.com> To: MX-List@WKUVX1.BITNET In article <1992Oct30.105542.4661@dmc.com>, munroe@dmc.com (Dick Munroe) writes: > I'm thinking of integrating UUBATCH into DECUS UUCP and I can think of > three ways to do it, each of which has advantages and disadvantages. > [For those that don't know about UUBATCH, it's a way to batch the UUCP > files so they go out in a single file instead of a BUNCH of files. The > net result is a higher bandwidth on your UUCP links.] ONLY for sites that end up sending LOTS of small mail messages, AND who really don't connect "real" often (i.e. on demand). > 1. Do it pretty much the way UUBATCH is done on U*X. > > This is essentially a batch process that comes along every so once in a > while, scans UUCP_SPOOL: for work to do, and batches the files. > > This is probably what I'll do FIRST in any event, just to get the port > of the UUBATCH stuff done and to test out linkages to my neighbors. > > The biggest problem with this solution is that it doesn't scale too > well. As the number of systems goes up, the amount of work UUBATCH has > to do just to figure out what to do goes up a lot too. Big > installations doing a lot of UUCP work couldn't use this as a long term > solution. This is totally dependent on what you define as "big" it is certainly reasonable if "big" is all you are dealing with is smaller than 50 sites. I suggest that there are many other issues that would start to rear their heads as your number of "active" connected sites grows to a "large" number. Please describe some details about your scaling concerns. > 2. Integrate it into MX. > > I'm actually rather attracted to this solution as you could think of the > whole thing as a kind of new path to a site. I haven't looked too > closely at the router and delivery agents to see what this would > actually entail, so I'm soliciting comments from the MX experts. > > If there was no other way, DECUS UUCP would require MX to provide > batching, so this isn't a great solution. In all likelyhood, the U*x > style UUBATCH solution would have to be provided as well. > > On the other hand, it WOULD scale rather nicely (or at least as well as > MX would), so large UUCP sites would be able to use it. > > 3. Integrate it into UUCP_mailshr > > Which, I suppose, is the BEST solution, the only thing is I really think > that it would be a royal pain to actually put in here as it would > require, at the very least, some sort of ad hoc data base describing the > down stream capablities of each site in the SYSTEMS. file. > > So, the question before the MX and UUCP guru's is: > > a. Is this worth doing? Yes, but most likely for sites that are: a) very busy already or b) across real expensive phone lines that must be operated most efficiently. DM:> b. If so, is it already being done, in which case, do you need any help. I've got it 99% done, and in the process I discovered there were several substantial bugs in the current implementation. I tried to contact the authors and the mail mail did not bounce and it also never was answered. This is what I sent to the authors: > I've worked through the necessary integration issues to get UUBATCH working > with DECUS uucp which runs on VAX/VMS systems. > > During this effort I found the following two issues to REQUIRE changing: > > 1) The batching of rmail jobs emitted the "X." file before the "D." > file into the batch file. This implies that the "X." file will > end up arriving at the ultimate destination's spool directory > (during unbatching) BEFORE the associated "D." file. This is NOT > the order that these things would take place during the normal > course of uucp transfers and can cause serious problems if uuxqt > happens to find (and start to process) the "X." file before the > "D." file is unbatched. This is simply fixed by changing > "batch_job" to emit the "D." file to the output batch before the > "X." file. This change is necessary for any implementation to > actually have predictable results all of the time. > > 2) The debatch processing ends up debatching directly into the > target "D." or "X." files by their explicit destination names. > More predictable behaviour will result if these are written to files > with temporary names and then renamed to the target name. This will > avoid a uuxqt finding a "X." file that has not been completely > written. > > Is there a newer version of this package? > > Are many sites actually using this package? I suspect that very few Unix sites actually are using the package, and it seems that since UUNET didn't adopt it, it's general popularity has really not grown very far. It also takes special programming on a per system basis since what is distributed is quite unlikely to work for any uucp except that which the original authors used it on. DM:> c. If it is not already being done, what are, from your perspective, DM:> the pros and cons of the three approaches? One big issue that really will drive the design decision regarding batching is proper synchronization with the existing outbound work list. The standard UUBATCH method involves aquiring the same locks that UUCICO uses to attain exclusive "remove" access to the outbound work queue. Such "exclusive" access may be unattainable for large periods of time, which for the standard methodology is no big deal since it merely skips that system and looks for another with work to consider batching. The possibility of "large periods" of unattained access essentially says that you shouldn't do it in the mailer user agent since you simply might not be able to get access to the outbound work queue for that system. If you then end up having to store the message somewhere else, and then finding it later for batching, you might as well have simply let the original method deal with the whole issue. Also, if it is done within the user agent, the possibly slow rebatching processing (which could savely be done in a low priority batch job), will potentially hang the user up for far longer than they might expect. The user's behaviour will then become non deterministic, and hence he might start to do more damage if he goes and tries to abort the processing in the middle. Also, putting it into the mailer context will end up with more hard to debug code than is currently there. DM:> d. Did I miss any other possible way to do the integration? I dunno. ============================== Given that it is likely to NOT currently be very popular, and since we are concerned about efficiencies, I suggest that we should design a new approach to the actual batch structure that best addressed the list of concerns that we can all come up with. Some of these include: 1) Avoiding decompressing and recompressing to grow batches. 2) hooks needed to support canceling of sub-batches to support "undeliverable/bounced" mail after some expiration period. 3) Batching of other than rmail jobs also. If we work out a good solution, we will then have to make it more popular so we can actually use it when not talking to other similarly equipped DECUS uucp sites. We will/should then integrate it into Taylor UUCP and help to spread the popularity. -- Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca PHONE: (415)369-9366 UUCP: decwrl!infopiz!mark or uunet!lupine!infopiz!mark DOMAIN: mark@infocomm.com ================================================================================ Archive-Date: Sat, 31 Oct 1992 13:32:53 CST From: Subject: mx smtp accounting question Message-ID: <2344@sunny.lif.de> Date: 30 Oct 92 21:26:31 GMT Sender: news@lif.de Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET Ok, I will give it a last try... :-( First question send to mx-list on 8.oct. - nothing Second try on 23.oct. - hey! the question appeared in vmsnet.mail.mx. But - until now: no reaction mailed or posted... Is it a real problem? Does nobody have/see this problem? Or ist my question too stupid? Anyway - a last try: Hello all, I have a small problem with the MX smtp accounting. Accounting lines look like this: 8-OCT-1992 10:39 XMIT: PROTO=SMTP, SOURCE="", HOST="SUNNY.LIF.DE", BYTES_SENT=1510 Node LIFRA is our VMS system running VMS5.4-2, Multinet 3.1 and MX 3.1c. Node SUNNY is a Sparc-1 station running in our ethernet and connected to the EUnet via ISDN. The last path config line says "domain *, path=smtp, route=sunny.lif.de". My question is: is it possible to get the REAL address into the smtp accounting instead of the router address. In the above example I would like to see: 8-OCT-1992 10:39 XMIT: PROTO=SMTP, SOURCE="", HOST="user@anywhere.world", BYTES_SENT=1510 Any hints? Thanks. Hans. -- Hans-Joachim Koch, Computer department of Lahmeyer International Lyoner Strasse 22, POB 71 06 51, D-6000 Frankfurt (Main) 71, Germany Phone: +49 69 6677-642, Fax: +49 69 6677-571, Tx: 413478 li d Email: koch@lifra.lif.de, dk9om@dk9om.ampr.org [44.130.25.45] ================================================================================ Archive-Date: Sat, 31 Oct 1992 14:10:09 CST From: Subject: Re: mx smtp accounting question Message-ID: <1992Oct31.194016.1777@news.arc.nasa.gov> Sender: usenet@news.arc.nasa.gov Reply-To: MX-List@WKUVX1.BITNET References: <2344@sunny.lif.de> Date: Sat, 31 Oct 1992 19:40:16 GMT To: MX-List@WKUVX1.BITNET In article <2344@sunny.lif.de>, sys_hjk@LIFRA.LIF.DE (Hans-Joachim Koch) writes: >But - until now: no reaction mailed or posted... >Is it a real problem? Does nobody have/see this problem? Or ist my >question too stupid? Anyway - a last try: It's not stupid, it's just that the answer is, basically, "no". > Accounting lines look like this: > > 8-OCT-1992 10:39 XMIT: PROTO=SMTP, SOURCE="", > HOST="SUNNY.LIF.DE", BYTES_SENT=1510 > > Node LIFRA is our VMS system running VMS5.4-2, Multinet 3.1 and MX 3.1c. > Node SUNNY is a Sparc-1 station running in our ethernet and connected to > the EUnet via ISDN. > > The last path config line says "domain *, path=smtp, route=sunny.lif.de". > > My question is: is it possible to get the REAL address into the smtp > accounting instead of the router address. In the above example I would > like to see: > > 8-OCT-1992 10:39 XMIT: PROTO=SMTP, SOURCE="", > HOST="user@anywhere.world", BYTES_SENT=1510 The reason the accounting information conatins the name of the host that the message was sent to, rather than its eventual destination, is that the information is supposed to be used to account for actual network usage. It wouldn't hurt, I suppose, to extend the accounting records to include the eventual destination as well, but the code would have to be changed to do that. -Matt -- Matthew Madison | madison@tgv.com | +1 408 427 4366 TGV, Inc. | 603 Mission Street | Santa Cruz, CA 95060 USA ================================================================================ Archive-Date: Sat, 31 Oct 1992 19:44:12 CST From: Subject: Re: mx smtp accounting question Date: 31 Oct 1992 20:01:31 GMT Message-ID: <1cuomrINNa0c@gap.caltech.edu> References: <2344@sunny.lif.de> Reply-To: MX-List@WKUVX1.BITNET To: MX-List@WKUVX1.BITNET In article <2344@sunny.lif.de>, sys_hjk@LIFRA.LIF.DE (Hans-Joachim Koch) writes: >But - until now: no reaction mailed or posted... >Is it a real problem? Does nobody have/see this problem? Or ist my >question too stupid? Anyway - a last try: > Probably the latter; I'll try to explain. > > I have a small problem with the MX smtp accounting. > > Accounting lines look like this: > > 8-OCT-1992 10:39 XMIT: PROTO=SMTP, SOURCE="", > HOST="SUNNY.LIF.DE", BYTES_SENT=1510 > > Node LIFRA is our VMS system running VMS5.4-2, Multinet 3.1 and MX 3.1c. > Node SUNNY is a Sparc-1 station running in our ethernet and connected to > the EUnet via ISDN. > > The last path config line says "domain *, path=smtp, route=sunny.lif.de". > > My question is: is it possible to get the REAL address into the smtp > accounting instead of the router address. I don't think so. And it really doesn't make sense anyway. From the point of view of your system, the only resources used were in sending the message from LIFRA to SUNNY. Lifra has abolutely no idea of what SUNNY does with it after that. So how can you possibly do any reasonable accounting on LIFRA other than to indicate that the message was sent to SUNNY. If you want further accounting, that should be up to the manager of SUNNY. That's assuming that you want the information for accounting purposes (that's why they're called ACCOUNTING files). In the United States, anyway, that's about all the information it's legal to keep about the message on a day-to-day basis: If you try to keep track of who sends mail to whom, that's an invasion of privacy. If you think a user is somehow abusing the system, then you can always enable SMTP logging and check through those files for the information you want. -------------------------------------------------------------------------------- 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.