Archive-Date: Tue, 1 Jul 1997 00:02:01 -0500 Sender: Date: Tue, 1 Jul 1997 00:01:45 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B693A.6D9D48C4.78@wku.edu> Subject: MX-LIST Administrivia: Monthly Post Posting statistics for list MX-LIST during June 1997 Total number of posts: 35 Total number of posters: 18 Total number of subscribers: 0 Last modified: 28-SEP-1995 13:33 (Updated digest info) Welcome to MX-List@LISTS.WKU.EDU, an electronic mailing list established for the discussion of the Message Exchange mail software. This is a routine posting you will see from time to time on MX-List. MX-List postings are also available in a daily digest format. To subscribe to the digest, send the following command in the body of a mail message to MXserver@LISTS.WKU.EDU: SUBSCRIBE MX-List-Digest "Your real name here" The MX-List archives are maintained at ARCHIVES@LISTS.WKU.EDU. To get a copy of any month's postings, send an e-mail message with the body SEND MX-List.yyyy-mm to ARCHIVES@LISTS.WKU.EDU, where "yyyy" is the year and "mm" is the numeric representation of the month. For example, the message SENDME MX-List.1992-04 will send the archives for April 1992. MX itself is available via anonymous ftp from ftp.spc.edu in [.MX.MX041]. You can also get it via e-mail by sending the commands SEND MX and SEND FILESERV_TOOLS on separate lines in the body of a mail message to FILESERV@LISTS.WKU.EDU. To remove yourself from the mailing list, send the following command to MXserver@LISTS.WKU.EDU: SIGNOFF MX-List MXserver supports a few other commands for your convenience. The following commands can be handled automatically by the list processor: SIGNOFF MX-List - to remove yourself from the list REVIEW MX-List - to get a list of subscribers QUERY MX-List - to get the status of your entry on the list SET MX-List DIGEST - to switch to digest mode SET MX-List NODIGEST - to switch to non-digest mode SET MX-List NOMAIL - to remain on the list but not receive mail SET MX-List MAIL - to resume receiving mail from the list SET MX-List CONCEAL - to not report your address in a REVIEW SET MX-List NOCONCEAL - to report your address in a REVIEW SET MX-List REPRO - to receive posts you make to MX-List SET MX-List NOREPRO - to not receive posts you make to MX-List LIST - to get a list of mailing lists served by WKU HELP - to receive a help file By default, subscriptions are set to MAIL, REPRO, NOCONCEAL. If you have any questions, comments, or suggestions about MX-List, please contact the list owner at the address below. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Hunter Goatley, Sr. OpenVMS Systems Programmer goathunter@MadGoat.com Process Software P.O. Box 51745 Bowling Green, KY 42102-6745 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ================================================================================ Archive-Date: Tue, 1 Jul 1997 04:56:20 -0500 Sender: Date: Tue, 01 Jul 1997 04:45:00 EDT From: mertus@speech.cog.brown.edu Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B6961.FF5D4B00.10@speech.cog.brown.edu> Subject: MX_LOCAL dying I'm running MX 4.1 on VMS 5.5, and I have a problem. The MX_LOCAL process keeps dying with a file "not found message in the log." Alas, it doesn't tell me what file is not found. So my question is, can one set a debug mode that will give me information on what file is not found. Even better, does anyone have any idea what file is not being found. After years of working perfecterly, this occured after a power failure crashed the system, so my guess is some file wants to deliver a piece of mail that already has been delivered. Thanks for any information -John_Mertus@Brown.EDU PS: I prefer not to upgrade VMS or MX as we are replacing the system soon. ================================================================================ Archive-Date: Wed, 2 Jul 1997 10:24:43 -0500 Sender: Date: Wed, 02 Jul 1997 11:20:52 EST From: Scott McNeilly Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B6A62.772E1640.48@fred.bridgew.edu> Subject: RE: MX_LOCAL dying >From: mertus@speech.cog.brown.edu > > I'm running MX 4.1 on VMS 5.5, and I have a problem. The MX_LOCAL >process keeps dying with a file "not found message in the log." Alas, it >doesn't tell me what file is not found. > > So my question is, can one set a debug mode that will give me information >on what file is not found. Even better, does anyone have any idea what You can create a debug file by defining the logical name: $ DEFINE/SYSTEM/EXEC MX_LOCAL_DEBUG "ON" The log file will be placed in [MX.LOCAL]MX_LOCAL_LOG.LOG This should help you locate the offending entry which you can then QUEUE CANCEL. You may then want to DEASSIGN the above logical. -------------------------------------------------------------------- Scott Mc Neilly email: smcneilly@bridgew.edu Assistant Director Phone: 508-697-1236 Information Services FAX: 508-697-1774 Bridgewater State College Bridgewater, MA 02325 --------------------------------------------------------------------- ================================================================================ Archive-Date: Wed, 2 Jul 1997 12:34:46 -0500 Sender: Date: Wed, 02 Jul 1997 13:35:25 EDT From: mertus@speech.cog.brown.edu Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B6A75.42F322E0.7@speech.cog.brown.edu> Subject: RE: MX_LOCAL dying Thank you, it worked! MX is now back up. -jam ================================================================================ Archive-Date: Wed, 2 Jul 1997 15:43:26 -0500 Sender: Date: Wed, 02 Jul 1997 14:43:17 MDT -0600 From: "Michael L. Hitch" Reply-To: MX-List@MadGoat.com To: mx-list@madgoat.com Message-ID: <009B6A7E.BDB2D429.53@msu.oscs.montana.edu> Subject: RE: Quirk with /RETURN_ADDRESS in lists when mail contains Reply-To: Hunter Goatley writes: > Richard Levitte - GNU on VMS hacker writes: > > > >When you define a list with a /RETURN_PATH (so the list members get > >the message from another address than the list's real name), you > >expect to get messages from the address specified there. The mailing > >list processor simply creates a Reply-To: header containing the correct > >information. There is, however, a quirk to this, and that's when the > >original message already contains a Reply-To: header... > > > Yep, I discovered that myself a couple of weeks ago. > > >Unfortunatelly, I'm not much of a BLISS man. If anyone can come up with > >a patch that will correct this (maybe Hunter himself?), I'd be more than > >happy to try it out. > > > I have a fix for it, but it's not quite ready for prime-time. I'll > try do that this week. Has this problem ever been fixed? It's been almost a year since this message. We just noticed this inconsistency while getting ready to move our mailing list server to another system. Michael --- Michael L. Hitch mhitch@msu.oscs.montana.edu Computer Consultant, Information Technology Center Montana State University, Bozeman, MT USA ================================================================================ Archive-Date: Wed, 2 Jul 1997 15:55:13 -0500 Sender: Date: Wed, 2 Jul 1997 15:55:06 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B6A88.C67904A6.37@ALPHA.WKU.EDU> Subject: RE: Quirk with /RETURN_ADDRESS in lists when mail contains Reply-To: "Michael L. Hitch" writes: > >> >list processor simply creates a Reply-To: header containing the correct >> >information. There is, however, a quirk to this, and that's when the >> >original message already contains a Reply-To: header... >> > > > Has this problem ever been fixed? It's been almost a year since this >message. We just noticed this inconsistency while getting ready to move >our mailing list server to another system. > This is fixed in MX V5.0, which is still not-quite-ready-for-prime-time. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Thu, 3 Jul 1997 18:13:14 -0500 Sender: Subject: Re: POP3? Message-ID: From: levitte@lp.se (Richard Levitte - VMS Whacker) Reply-To: MX-List@MadGoat.com Date: 03 Jul 1997 22:28:49 GMT MIME-Version: 1.0 Content-Type: Text/Plain; Charset=ISO-8859-1 Content-Transfer-Encoding: 8bit To: MX-List@WKUVX1.WKU.EDU In article Ian.Miller@softel.xxx (Ian Miller) writes: No POP3 server in MX. Make sure you have defined the right magic logicals for UCX POP3. I once tried UCX POP3, and failed. Can you tell me exactly what is needed to get it to work with MX? I had the impression it needed to have UCX SMTP running to work... -- R Levitte, Levitte Programming; Spannv. 38, I; S-161 43 Bromma; SWEDEN Tel: +46-8-26 52 47; Cel: +46-10-222 64 05; No fax right now PGP key fingerprint = A6 96 C0 34 3A 96 AA 6C B0 D5 9A DF D2 E9 9C 65 Check http://www.lp.se/~levitte for my public key. bastard@bofh.se ================================================================================ Archive-Date: Thu, 3 Jul 1997 20:22:55 -0500 Sender: Date: Thu, 03 Jul 1997 19:22:43 MDT -0600 From: "Michael L. Hitch" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B6B6E.F16A910D.4@msu.oscs.montana.edu> Subject: RE: Quirk with /RETURN_ADDRESS in lists when mail contains Reply-To: Hunter Goatley writes: > >> >list processor simply creates a Reply-To: header containing the correct > >> >information. There is, however, a quirk to this, and that's when the > >> >original message already contains a Reply-To: header... > >> > > > > > Has this problem ever been fixed? It's been almost a year since this > >message. We just noticed this inconsistency while getting ready to move > >our mailing list server to another system. > > > This is fixed in MX V5.0, which is still > not-quite-ready-for-prime-time. That's OK - it's now fixed on my systems :-) Michael --- Michael L. Hitch mhitch@msu.oscs.montana.edu Computer Consultant, Information Technology Center Montana State University, Bozeman, MT USA ================================================================================ Archive-Date: Mon, 7 Jul 1997 10:16:53 -0500 Sender: Date: Mon, 07 Jul 1997 11:15:26 EST From: Scott McNeilly Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B6E4F.88876CC0.56@fred.bridgew.edu> Subject: Re: POP3? >I once tried UCX POP3, and failed. Can you tell me exactly what is needed >to get it to work with MX? I had the impression it needed to have UCX SMTP running to work... > >-- >R Levitte, Levitte Programming; Spannv. 38, I; S-161 43 Bromma; SWEDEN > Tel: +46-8-26 52 47; Cel: +46-10-222 64 05; No fax right now UCX POP will run without UCX SMTP, but DEC does not support it that way. To get UCX POP to work with MX, you need to disable UCX SMTP (using UCX$CONFIG.COM) in UCX> SET CONFIGURATION SMTP /OPTION=TOP_HEADERS in your SYSTARTUP_VMS.COM, run INSTALL to install the following SYS$SHARE:UCX$SMTP_MAILSHR.EXE /SHARE/OPEN SYS$SHARE:UCX$SMTP_PARSESHR.EXE /SHARE/OPEN (These are for a VAX; the Alpha is different. On the Alpha it is UCX$SMTP_PARSESHR_TV.EXE) enable POP in UCX$CONFIG.COM you will probably want to define the following in SYSTARTUP $ DEFINE/SYSTEM UCX$POP_IGNORE_MAIL11_HEADERS "TRUE" $ DEFINE/SYSTEM UCX$POP_PURGE_RECLAIM "TRUE" I hope I didn't forget anything. By the way, I'm running UCX v 4.1. -------------------------------------------------------------------- Scott Mc Neilly email: smcneilly@bridgew.edu Assistant Director Phone: 508-697-1236 Information Services FAX: 508-697-1774 Bridgewater State College Bridgewater, MA 02325 --------------------------------------------------------------------- ================================================================================ Archive-Date: Mon, 7 Jul 1997 10:58:38 -0500 Sender: Message-ID: <3.0.1.32.19970707170103.00764dd0@agate.actfs.co.uk> Date: Mon, 07 Jul 1997 17:01:03 +0100 To: MX-List@MadGoat.com From: John Rourke Reply-To: MX-List@MadGoat.com Subject: Re: POP3? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" [snip] > in your SYSTARTUP_VMS.COM, run INSTALL to install the following > SYS$SHARE:UCX$SMTP_MAILSHR.EXE /SHARE/OPEN > SYS$SHARE:UCX$SMTP_PARSESHR.EXE /SHARE/OPEN > (These are for a VAX; the Alpha is different. On the Alpha > it is UCX$SMTP_PARSESHR_TV.EXE) A simpler way would be @sys$startup:ucx$service_setup smtp John Rourke ================================================================================ Archive-Date: Tue, 8 Jul 1997 14:05:54 -0500 Sender: Message-ID: <9707082008.AA01858@leviathan.ag.ohio-state.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 08 Jul 1997 15:04:38 -0400 To: MX-List@MadGoat.com From: "Harrington B. Laufman" Reply-To: MX-List@MadGoat.com Subject: SMTP refusing connections Hello, We have MX 4.1, Multinet 3.2, VMX 5.4-3 on a VAX 4000-300. SMTP is refusing connections. Telenet to port 25 is refused. Router, Local,FLQ, MLF are idle. Four SMTPS are idle, Four Waiting on messages. Four messages seemed to be persisting in the queue. I have canceled two so far. A reboot fixes the problem for a few minutes, say 20 minutes. I need guidance on troubleshooting and fixing, please. Thanks, Harry ================================================================================ Archive-Date: Tue, 8 Jul 1997 14:19:12 -0500 Sender: Date: Tue, 8 Jul 1997 14:19:04 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: HLAUFMAN@MAGNUS.ACS.OHIO-STATE.EDU Message-ID: <009B6F32.5A79254E.1@ALPHA.WKU.EDU> Subject: RE: SMTP refusing connections "Harrington B. Laufman" writes: > >Hello, > >We have MX 4.1, Multinet 3.2, VMX 5.4-3 on a VAX 4000-300. > >SMTP is refusing connections. Telenet to port 25 is refused. > >Router, Local,FLQ, MLF are idle. Four SMTPS are idle, Four Waiting >on messages. > You're missing the SMTP Server, which is why telnet to port 25 is refused. >A reboot fixes the problem for a few minutes, say 20 minutes. > >I need guidance on troubleshooting and fixing, please. > My guess is that you've got a spam message coming in that's exercising a bug in the SMTP server that can't handle To: or CC: lines longer than 64K characters. You *should* upgrade to MX V4.2 (it's only been out for a year and a half+), and then pick up the new SMTP_SERVER on ftp.madgoat.com in [.MX.MX042.PATCH]. That image may work with MX V4.1, but I can't guarantee it. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Tue, 8 Jul 1997 14:33:11 -0500 Sender: Date: Tue, 8 Jul 1997 12:32:42 -0700 From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009B6F23.7E5B3CCA.19@sacto.mp.usbr.gov> Subject: RE: SMTP refusing connections > From: MX%"MX-List@MadGoat.com" 8-JUL-1997 12:16:20.50 > Subj: SMTP refusing connections > Hello, > > We have MX 4.1, Multinet 3.2, VMX 5.4-3 on a VAX 4000-300. > > SMTP is refusing connections. Telenet to port 25 is refused. > > Router, Local,FLQ, MLF are idle. Four SMTPS are idle, Four Waiting > on messages. > > Four messages seemed to be persisting in the queue. I have canceled > two so far. > > A reboot fixes the problem for a few minutes, say 20 minutes. > > I need guidance on troubleshooting and fixing, please. > > Thanks, > > Harry > If you do: MCP> STATUS Does the SMTP Server show up? My bet is that the server is crashing. You should just be able to restart MX, without having to reboot the system. What it sounds like is happening is that you are getting nailed with an extra long line from a remote SMTP client. You should upgrade to 4.2, and Hunter has a patched version of the SMTP server that fixed this problem. -HWM ================================================================================ Archive-Date: Wed, 9 Jul 1997 08:17:48 -0500 Sender: Date: Wed, 9 Jul 1997 8:17:25 -0500 From: "Charles R. McKown" Reply-To: MX-List@MadGoat.com To: MX-LIST@MADGOAT.COM CC: MCKOWN@paws.cowley.cc.ks.us Message-ID: <970709081725.20201021@paws.cowley.cc.ks.us> Subject: HELO Problem Greetings. We installed MX version 4.2 on our Alpha 2100. (We are using VMS version 6.2-1H1, Netlib version 2.0J, and Multinet version 4.0 rev A.) After doing so we began having the following error from some (not all) of our personal computers that are using Netscape as their e-mail package: An error occurred sending mail. The mail server responded: Please identify yourself with HELO. Please verify that your email address is correct in your Mail perferences and try again. In looking at the Mail preferences on the computers that were working and those that were not, we could not identify what was causing this problem so we disabled MX and went back to Multinet's SMTP package which eliminated this problem. Any suggestions as to what to try to get MX working without this problem would be greatly appreciated. ------------------------------------------------------------ Charles R. McKown mckown@paws.cowley.cc.ks.us Director of Computer Services Cowley County Community College Phone: (316) 441-5264 125 South Second, P.O. Box 1147 FAX: (316) 441-5350 Arkansas City, Kansas 67005 ------------------------------------------------------------ ================================================================================ Archive-Date: Wed, 9 Jul 1997 08:30:54 -0500 Sender: Date: Wed, 09 Jul 1997 08:29:42 CST From: hunterl@uwwvax.uww.edu Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B6FCA.B63BD06C.25@uwwvax.uww.edu> Subject: RE: HELO Problem => We installed MX version 4.2 on our Alpha 2100. (We are using VMS version => 6.2-1H1, Netlib version 2.0J, and Multinet version 4.0 rev A.) After doing so => we began having the following error from some (not all) of our personal => computers that are using Netscape as their e-mail package: => => => An error occurred sending mail. => The mail server responded: => Please identify yourself with HELO. => Please verify that your email address is correct => in your Mail perferences and try again. => => => In looking at the Mail preferences on the computers that were working and those => that were not, we could not identify what was causing this problem so we => disabled MX and went back to Multinet's SMTP package which eliminated this => problem. Any suggestions as to what to try to get MX working without this => problem would be greatly appreciated. We have the same problem with NETSCAPE and have solved it by using a UNIX box as the SMTP server for NETSCAPE mail rather than the ALPHA. The problem seems to be NETSCAPE's in that they do provide the address for the HELO command, which I assume is part of the standard. UNIX does not seem to care. Lyle Hunter T & IR University Wisconsin-Whitewater 414-472-1967 Fax: 414-472-5733 ================================================================================ Archive-Date: Wed, 9 Jul 1997 10:16:40 -0500 Sender: Date: Wed, 9 Jul 1997 10:16:33 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B6FD9.A3F41FDD.4@ALPHA.WKU.EDU> Subject: RE: HELO Problem hunterl@uwwvax.uww.edu writes: > >=> In looking at the Mail preferences on the computers that were working and those >=> that were not, we could not identify what was causing this problem so we >=> disabled MX and went back to Multinet's SMTP package which eliminated this >=> problem. Any suggestions as to what to try to get MX working without this >=> problem would be greatly appreciated. > >We have the same problem with NETSCAPE and have solved it by using a UNIX >box as the SMTP server for NETSCAPE mail rather than the ALPHA. > >The problem seems to be NETSCAPE's in that they do provide the address >for the HELO command, which I assume is part of the standard. UNIX >does not seem to care. > Actually, the problem is that Netscape is only sending EHLO. It's *supposed* to send EHLO, then, if it gets an error, it's supposed to send HELO. However, they send EHLO (the Extended SMTP greeting) and stop when they get the error. At least, this is what I saw happen at WKU a few months ago with Netscape. The SMTP_SERVER image on ftp.madgoat.com in [.MX.MX042.PATCH] allows the use of both HELO and EHLO. It was placed there in January. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Wed, 9 Jul 1997 12:25:09 -0500 Sender: From: "Nic CLEWS" Reply-To: MX-List@MadGoat.com To: MX_List@MadGoat.com Message-ID: <802564CF.005F983A.00@aejacob.jacobs.co.uk> Date: Wed, 9 Jul 1997 18:28:55 +0100 Subject: VMS Personal name in FROM: header MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII We have VMS 6.2, MX 4.2 and the new versions of SMTP_SERVER and MX_LOCAL I Have all headers switched on. The MX_LOCAL works well with other external email systems and places the data in the FROM field into the personal name. However mail recieved from a VMS host does not carry data from the FROM field. When checking the headers, a mail that works (putting personal names in) has: From: "Nic CLEWS" - this originated on a Notes Domino server. Note the quotes around the name. One that does not work, i.e. generated on the Vax has this format of header: From: Nic Clews Note that the quotes are missing from the name portions; also the domain is not completed (It should be clewsn@midge.jacobs.co.uk). The domain rewrite rules are *@midge *@midge.jacobs.co.uk. We use GOLDMAIL V3, but this does not allow any quotes in a personal name. I have tried using SET PER in MAIL, using combinations of quotes, the only valid combinations are one pair and a double pair. However neither of these make the quote appear in the FROM header. We used to use the Multinet SMTP server and I recall it did exactly the same, is this a fault with the VMS mail system, or within MX,? Could MX be coded to append the quotes to the FROM header? Regards Nic Clews ================================================================================ Archive-Date: Wed, 9 Jul 1997 13:08:45 -0500 Sender: Date: Wed, 9 Jul 1997 11:08:37 -0700 From: Dan Wing Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <970709110837.2332d187@Cisco.COM> Subject: RE: VMS Personal name in FROM: header >We have VMS 6.2, MX 4.2 and the new versions of SMTP_SERVER and MX_LOCAL I >Have all headers switched on. > >The MX_LOCAL works well with other external email systems and places the >data in the FROM field into the personal name. However mail recieved from a >VMS host does not carry data from the FROM field. > >When checking the headers, a mail that works (putting personal names in) >has: > >From: "Nic CLEWS" >- this originated on a Notes Domino server. Note the quotes around the >name. > >One that does not work, i.e. generated on the Vax has this format of >header: >From: Nic Clews Both are correct, especially per the new DRUMS Internet Drafts. >Note that the quotes are missing from the name portions; also the domain is >not completed (It should be clewsn@midge.jacobs.co.uk). The domain rewrite >rules are *@midge *@midge.jacobs.co.uk. That is broken - you've got your VMS mailer misconfigured. >We use GOLDMAIL V3, but this does not allow any quotes in a personal name. The quotes are necessary per RFC822, and using quotes in your VMSmail or GoldMail personal name won't cause the desired effect anyway. >I have tried using SET PER in MAIL, using combinations of quotes, the only >valid combinations are one pair and a double pair. However neither of >these make the quote appear in the FROM header. We used to use the Multinet >SMTP server and I recall it did exactly the same, is this a fault with the >VMS mail system, or within MX,? Could MX be coded to append the quotes to >the FROM header? -Dan Wing ================================================================================ Archive-Date: Wed, 9 Jul 1997 13:49:43 -0500 Sender: Date: Wed, 9 Jul 1997 14:49:46 -0400 From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B6FFF.CEAC65A0.5@swdev.si.com> Subject: RE: VMS Personal name in FROM: header Nic Clews (Nic_CLEWS@jacobs.co.uk) writes: >Could MX be coded to append the quotes to the FROM header? MX will add quotes to the personal name if it contains a character that is not allowed outside of quotes. For MX V4.0 and for V4.1, I had created patches for MX_SHR (which is where the work gets done) which would always add the quotes no matter what was in the personal name. With V4.2 and beyond, we no longer have the software that objected to certain characters in the personal name (even though they were perfectly legal), so I did not develop a patch. The patch was simply. I simply turned a conditional branch BLBC B^10(SP),xxxx into a NOP. The statements prior to the conditional branch tested for the inproper characters. If none were found, the BLBC skip the code that would add the quotes. By replacing it with NOP, the code was always executed. For V4.1, the patch looked like this: $ type mx_shr_041_patch.com $ PATCH mx_exe:MX_SHR.EXE REPLACE/INSTR 369F 'BLBC B^10(SP),3702' EXIT 'NOP' EXIT UPDATE For V4.0, the patch was of exactly the same form, but the addresses were a little different. -- Brian Tillman Internet: tillman_brian at si.com Smiths Industries, Inc. tillman at swdev.si.com 4141 Eastern Ave., MS239 Addresses modified to prevent Grand Rapids, MI 49518-8727 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ================================================================================ Archive-Date: Wed, 9 Jul 1997 15:51:08 -0500 Sender: Message-ID: From: Rick Campbell-HQ Reply-To: MX-List@MadGoat.com To: "'MX-List@MadGoat.com'" Subject: Date: Wed, 9 Jul 1997 13:43:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit SIGNOFF MX-List ================================================================================ Archive-Date: Tue, 15 Jul 1997 12:47:30 -0500 Sender: Date: Tue, 15 Jul 1997 10:47:18 PST From: HelpDesk@PlanAcc.COM Reply-To: MX-List@MadGoat.com To: MX-LIST@MADGOAT.COM Message-ID: <009B7494.EDFE13C4.51@planacc.com> Subject: Spam attack Greetings All, We have been receiving nonstop spam from intrnt@adxntorx.com that is using MX on our system to sent to multiple addresses. Whois does not find this domain. Is there a way to set a reject on receiving from this address or better yet, a way for MX to not forward to the users on other systems. VMS/VAX 6.1 MX 4.2 THANKS, HelpDesk@PlanAcc.COM ================================================================================ Archive-Date: Tue, 15 Jul 1997 12:58:51 -0500 Sender: Date: Tue, 15 Jul 1997 13:58:23 EST From: Jim Bender Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B74AF.9FA4FEF2.89@bdsnet.com> Subject: RE: Spam attack >Greetings All, > > We have been receiving nonstop spam from intrnt@adxntorx.com >that is using MX on our system to sent to multiple addresses. Whois does >not find this domain. Is there a way to set a reject on receiving from this >address or better yet, a way for MX to not forward to the users on other >systems. We are experiencing a similar problem. It is almost as if we are on a "SPAMable server" list of some sort. For the last few days, we've been hit pretty hard by spammers using our MX systems for relaying unauthorized bulk email. The only way we've been able to stop it, is to black-hole route the offenders as it occurs. We DESPERATELY need the functionality of MX 5.0.... The NORELAY function would easily stop this from occuring. We need the other SPAM filters badly as well. >VMS/VAX 6.1 MX 4.2 > >THANKS, >HelpDesk@PlanAcc.COM Regards, Jim Bender jbender@bdsnet.com ================================================================================ Archive-Date: Tue, 15 Jul 1997 12:59:09 -0500 Sender: Date: Tue, 15 Jul 1997 10:59:02 -0700 From: Dan Wing Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <970715105902.2020029d@Cisco.COM> Subject: RE: Spam attack > We have been receiving nonstop spam from intrnt@adxntorx.com >that is using MX on our system to sent to multiple addresses. Whois does >not find this domain. Is there a way to set a reject on receiving from this >address or better yet, a way for MX to not forward to the users on other >systems. > >VMS/VAX 6.1 MX 4.2 MX version 5.0, which is still in beta, has protections against this problem. With current versions of MX, you must determine the source IP address and then do either: a. Block that IP address at your router or b. Create a black-hole route on your VMS box (if running MultiNet, use the command "$ MULTINET SET/ROUTE/ADD=(DESTIONATION:ip,GATE:blah", where "ip" is the source IP address of the spams, and "blah" is an unused IP address on your local network. -Dan Wing ================================================================================ Archive-Date: Tue, 15 Jul 1997 13:05:42 -0500 Sender: Date: Tue, 15 Jul 1997 11:05:33 -0700 From: Dan Wing Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <970715110533.202016a3@Cisco.COM> Subject: RE: Spam attack >We DESPERATELY need the functionality of MX 5.0.... The NORELAY >function would easily stop this from occuring. I can provide anyone with a MultiNet mailer that blocks spam (and relayed mail) immediately. You can continue to use MX (version 4) as your primary mail system on an alternate port and MultiNet's mailer can immediately forward all incoming mail to your already-configured MX mailer. (At least, I believe MX version 4 supports the MX_SMTP_PORT logical.) If anyone would like details, let me know. -Dan Wing ================================================================================ Archive-Date: Tue, 15 Jul 1997 13:21:08 -0500 Sender: Date: Tue, 15 Jul 1997 14:18:21 EST From: Jim Bender Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B74B2.697A3CC2.51@bdsnet.com> Subject: RE: Spam attack >>We DESPERATELY need the functionality of MX 5.0.... The NORELAY >>function would easily stop this from occuring. > >I can provide anyone with a MultiNet mailer that blocks spam (and relayed >mail) immediately. You can continue to use MX (version 4) as your primary >mail system on an alternate port and MultiNet's mailer can immediately >forward all incoming mail to your already-configured MX mailer. (At least, >I believe MX version 4 supports the MX_SMTP_PORT logical.) > >If anyone would like details, let me know. How would this work? >-Dan Wing Thanks, Jim Bender jbender@bdsnet.com ================================================================================ Archive-Date: Tue, 15 Jul 1997 13:29:59 -0500 Sender: From: goathunter@madgoat.com (Hunter Goatley) Subject: Re: UCX v4.1 ECO 6 POP3 Server on Alpha/OpenVMS v6.2 Date: 15 Jul 1997 17:06:47 GMT Message-ID: <5qgan7$uaf$2@news.wku.edu> Reply-To: MX-List@MadGoat.com To: Info-VAX@Mvb.Saic.Com In article <5qe1c4$nbs$1@flood.weeg.uiowa.edu>, dyson@scat.physics.uiowa.edu (Richard L. Dyson) writes: > Can anyone confirm this problem I am having with the recent UCX v4.1 >ECO 6 for Alpha/OpenVMS? > I don't have UCX running anywhere, but.... > I installed ECO 6 Friday night and now I have found that the POP >clients do not see the MIME encoded sections the say way they did before. >The base64 encodings are not decoded, etc. > My guess is that the POP3 server is inserting a blank line before the headers in the messages. Why, I don't know, but that would certainly cause what you're seeing. > The basic POP interface worked in ECO 4, so it must be something >Digital changed that MX uses. No, I think it's something Digital changed in the way they handle the messages from MX. >I tried an experiment by sending a mail >message from Eudora Pro with a simple image/gif attachment. The same >letter twice. Once with just UCX SMTP running on the Alpha and once with >UCX's SMTP and MX layered over it. > Layered over it how? Are you receiving it with UCX's SMTP and then forwarding back through MX%?? If so, then there's your problem. The way the UCX mailer works, mail forwarded to UCX (via SET FORWARD MX%"...") will end up with two sets of RFC822 headers. Basically, the headers are passed to MX as part of the message body, so the blank line gets added and decoding stops.... > When I read the subsequent messages with Eudora Pro, the SMTP one >presented the attachment decoded whereas the MX one just presented the >raw base64 encoding as text. When I examined both messages in VMS MAIL, I found (besides MX vs. SMTP ids and time tags) only one difference. >SMTP had the string "Mime-Version: 1.0" where MX used the string >"MIME-Version: 1.0". Note the case difference for letters MIME... > That shouldn't affect anything, though I'm 99% sure the MIME RFC specifies "MIME-Version:". Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Tue, 15 Jul 1997 13:39:46 -0500 Sender: Date: Tue, 15 Jul 1997 14:38:59 EDT From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: hardis@garnet.nist.gov Message-ID: <009B74B5.4B94D7A0.4@garnet.nist.gov> Subject: RE: Spam attack >>>We DESPERATELY need the functionality of MX 5.0.... The NORELAY >>>function would easily stop this from occuring. >>I can provide anyone with a MultiNet mailer that blocks spam (and relayed >>mail) immediately. You can continue to use MX (version 4) as your primary >>mail system on an alternate port and MultiNet's mailer can immediately >>forward all incoming mail to your already-configured MX mailer. (At least, >>I believe MX version 4 supports the MX_SMTP_PORT logical.) >> >>If anyone would like details, let me know. > How would this work? One can also use the SITE interface to send to NL: all mail that meets certain criteria. Give me a minute to work out the details. In the meanwhile, make sure that the SITE agent is installed on your system. - Jonathan ================================================================================ Archive-Date: Tue, 15 Jul 1997 13:40:13 -0500 Sender: Date: Tue, 15 Jul 1997 11:37:24 -0700 From: Dan Wing Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <970715113724.2020029d@Cisco.COM> Subject: Re: UCX v4.1 ECO 6 POP3 Server on Alpha/OpenVMS v6.2 >> I installed ECO 6 Friday night and now I have found that the POP >>clients do not see the MIME encoded sections the say way they did before. >>The base64 encodings are not decoded, etc. >> >My guess is that the POP3 server is inserting a blank line before the >headers in the messages. Why, I don't know, but that would certainly >cause what you're seeing. > >> The basic POP interface worked in ECO 4, so it must be something >>Digital changed that MX uses. > >No, I think it's something Digital changed in the way they handle the >messages from MX. I suspect Digital is looking for in the VMSmail FROM: line to detect if the message originates from SMTP, and if it doesn't see it assumes it is a DECnet-delivered message and the POP3 server generates RFC822 headers. Try changing MX to use instead of (which is documented in MX_DOC:MX_MGMT_GUIDE.TXT) and see if that makes the POP3 server happier. Of course, let Digital know they broke the POP3 server, too. Or perhaps there's a way to let the POP3 server know that should be treated the same as . >>I tried an experiment by sending a mail >>message from Eudora Pro with a simple image/gif attachment. The same >>letter twice. Once with just UCX SMTP running on the Alpha and once with >>UCX's SMTP and MX layered over it. >> >Layered over it how? Are you receiving it with UCX's SMTP and then >forwarding back through MX%?? If so, then there's your problem. The >way the UCX mailer works, mail forwarded to UCX (via SET FORWARD MX%"...") >will end up with two sets of RFC822 headers. Basically, the headers are >passed to MX as part of the message body, so the blank line gets added >and decoding stops.... > >> When I read the subsequent messages with Eudora Pro, the SMTP one >>presented the attachment decoded whereas the MX one just presented the >>raw base64 encoding as text. When I examined both messages in VMS MAIL, >I found (besides MX vs. SMTP ids and time tags) only one difference. >>SMTP had the string "Mime-Version: 1.0" where MX used the string >>"MIME-Version: 1.0". Note the case difference for letters MIME... >> >That shouldn't affect anything, though I'm 99% sure the MIME RFC specifies >"MIME-Version:". I'm 1% sure, so that makes it 100%. (See RFC2049, section 2, "MIME Conformance" which says: # A mail user agent that is MIME-conformant MUST: # # (1) Always generate a "MIME-Version: 1.0" header field in # any message it creates. ) -Dan Wing ================================================================================ Archive-Date: Tue, 15 Jul 1997 13:43:40 -0500 Sender: Date: Tue, 15 Jul 1997 11:43:07 -0700 From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009B749C.BA215E46.7@sacto.mp.usbr.gov> Subject: RE: Spam attack > From: MX%"MX-List@MadGoat.com" 15-JUL-1997 11:16:18.55 > Subj: RE: Spam attack Dan, > >We DESPERATELY need the functionality of MX 5.0.... The NORELAY > >function would easily stop this from occuring. > > I can provide anyone with a MultiNet mailer that blocks spam (and relayed > mail) immediately. You can continue to use MX (version 4) as your primary > mail system on an alternate port and MultiNet's mailer can immediately > forward all incoming mail to your already-configured MX mailer. (At least, > I believe MX version 4 supports the MX_SMTP_PORT logical.) > 4.1, no. 4.2, yes. > If anyone would like details, let me know. > > -Dan Wing -HWM ================================================================================ Archive-Date: Tue, 15 Jul 1997 13:46:15 -0500 Sender: Date: Tue, 15 Jul 1997 11:46:02 -0700 From: Dan Wing Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <970715114602.2020029d@Cisco.COM> Subject: Re: UCX v4.1 ECO 6 POP3 Server on Alpha/OpenVMS v6.2 >>> When I read the subsequent messages with Eudora Pro, the SMTP one >>>presented the attachment decoded whereas the MX one just presented the >>>raw base64 encoding as text. When I examined both messages in VMS MAIL, >>I found (besides MX vs. SMTP ids and time tags) only one difference. >>>SMTP had the string "Mime-Version: 1.0" where MX used the string >>>"MIME-Version: 1.0". Note the case difference for letters MIME... >>> >>That shouldn't affect anything, though I'm 99% sure the MIME RFC specifies >>"MIME-Version:". > >I'm 1% sure, so that makes it 100%. (See RFC2049, section 2, "MIME >Conformance" which says: > # A mail user agent that is MIME-conformant MUST: > # > # (1) Always generate a "MIME-Version: 1.0" header field in > # any message it creates. >) Sorry, the original message was referring to the case of "Mime" versus "MIME". Both are allowed, as case in headers is ignored (according to the RFC822 and the new DRUMS drafts). -dan ================================================================================ Archive-Date: Tue, 15 Jul 1997 13:55:40 -0500 Sender: Date: Tue, 15 Jul 1997 13:55:34 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B74AF.3AD2612A.75@ALPHA.WKU.EDU> Subject: Re: UCX v4.1 ECO 6 POP3 Server on Alpha/OpenVMS v6.2 Dan Wing writes: > >I suspect Digital is looking for in the VMSmail FROM: line to detect >if the message originates from SMTP, and if it doesn't see it >assumes it is a DECnet-delivered message and the POP3 server generates >RFC822 headers. > Yep! I forgot about that. I'm sure that it does look for that, since the IUPOP did. >Try changing MX to use instead of (which is documented in >MX_DOC:MX_MGMT_GUIDE.TXT) and see if that makes the POP3 server happier. > That should do it. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Tue, 15 Jul 1997 15:26:53 -0500 Sender: Date: Tue, 15 Jul 1997 11:25:54 -0700 From: Dan Wing Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <970715112554.2020029d@Cisco.COM> Subject: RE: Spam attack >>I can provide anyone with a MultiNet mailer that blocks spam (and relayed >>mail) immediately. You can continue to use MX (version 4) as your primary >>mail system on an alternate port and MultiNet's mailer can immediately >>forward all incoming mail to your already-configured MX mailer. (At least, >>I believe MX version 4 supports the MX_SMTP_PORT logical.) >> >>If anyone would like details, let me know. > >How would this work? First, I'm not 100% sure that MX V4.x supports the MX_SMTP_PORT logical -- could you search the MX_EXE:SMTP_SERVER.EXE image for MX_SMTP_PORT? If it is there, then the following will work: Basically, you install a new MultiNet SMTP mailer (on a port other than 25 while you're configuring it). You configure it so that it accepts mail for your domain (and doesn't permit relaying for other domains) and forwards mail for your domain to MX (on port 25). When you're satisified with the configuration of MultiNet's SMTP, you make it "live" by shutting down MX, reconfigure MX to listen on an alternate port, reconfigure MultiNet's SMTP to listen on port 25 and forward "your" mail to the alternate MX port, and you're set. Make sense? -Dan Wing ================================================================================ Archive-Date: Tue, 15 Jul 1997 16:14:48 -0500 Sender: From: dyson@scat.physics.uiowa.edu (Richard L. Dyson) Subject: Re: UCX v4.1 ECO 6 POP3 Server on Alpha/OpenVMS v6.2 Date: 15 Jul 1997 19:23:35 GMT Message-ID: <5qginn$slo$1@flood.weeg.uiowa.edu> Reply-To: MX-List@MadGoat.com To: Hunter Goatley CC: To: MX-List@WKUVX1.WKU.EDU In article <009B74AF.3AD2612A.75@ALPHA.WKU.EDU>, Hunter Goatley writes: > Dan Wing writes: > > > >I suspect Digital is looking for in the VMSmail FROM: line to detect > >if the message originates from SMTP, and if it doesn't see it > >assumes it is a DECnet-delivered message and the POP3 server generates > >RFC822 headers. > > > Yep! I forgot about that. I'm sure that it does look for that, since > the IUPOP did. > > >Try changing MX to use instead of (which is documented in > >MX_DOC:MX_MGMT_GUIDE.TXT) and see if that makes the POP3 server happier. > > > That should do it. We have a Bingo! Damn nice guys!!! I issued $ Define /System /Executive_Mode MX_Protocol_Prefix "SMTP%" $ MCP Reset /Cluster (just in case it needed it) Then sent myself a MIME encoded msg from my PC, "POP"ed it back to the PC and the MIME header was seen and processed by the client. rick -- Richard L. Dyson dyson@iowasp.physics.uiowa.edu _ _ _____ http://www-pi.physics.uiowa.edu/~dyson/ | | | | |_ _| Systems Analyst O: 319/335-1879 | | | | of | | University of Iowa FAX: 319/335-1753 | \_/ | _| |_ Department of Physics & Astronomy H: 319/338-6117 \___/ |_____| Iowa City, IA 52242-1479 ================================================================================ Archive-Date: Tue, 15 Jul 1997 17:41:31 -0500 Sender: From: dwing@cisco.com (Dan Wing) Subject: Re: POP vs. UCX v4.1 ECO 6 on Alpha/OpenVMS Date: 15 Jul 1997 22:27:42 GMT Message-ID: <5qgtgu$7k5$2@news-sj-2.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <5qgkc9$slo$2@flood.weeg.uiowa.edu>, dyson@scat.physics.uiowa.edu (Richard L. Dyson) writes: >In article <009B74AF.3AD2612A.75@ALPHA.WKU.EDU>, Hunter Goatley writes: >> Dan Wing writes: >> > >> >I suspect Digital is looking for in the VMSmail FROM: line to detect >> >if the message originates from SMTP, and if it doesn't see it >> >assumes it is a DECnet-delivered message and the POP3 server generates >> >RFC822 headers. >> > >> Yep! I forgot about that. I'm sure that it does look for that, since >> the IUPOP did. > >But UCX POP did not apparently do this in the past. Is there a config >option to tell UCX POP to go back to accepting MX% as well as SMTP%? Dunno. Ask Digital and let people on this newsgroup know (who are likely to have the same problem when they install the ECO). -Dan Wing ================================================================================ Archive-Date: Tue, 15 Jul 1997 20:01:30 -0500 Sender: Date: Tue, 15 Jul 1997 21:01:16 EDT From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: hardis@garnet.nist.gov Message-ID: <009B74EA.B3640EC0.1@garnet.nist.gov> Subject: RE: Spam attack I don't have time to make sure that this works, but you can try something along this line. (In other words, expect to modify this to make it work right.) In CONFIG.MCP: ! Presuming that there are no previously defined rewrite rules: ! (If there are, then modified versions of them must appear FIRST.) ! (Note that only the first rewrite rule that applies is used.) ! DEFINE REWRITE_RULE <{user}%{host}@FILTERED> <{user}@{host}> ! Accept mail back out of SITE interface DEFINE REWRITE_RULE <{user}@{host}> <{user}%{host}@TOFILTER> ! All new mail goes into SITE interface ! ! DEFINE PATH "TOFILTER" SITE/ROUTE="TOFILTER" In SITEDELIVERY.COM: $ SET NOON $ MX_ENTER := $MX_EXE:MX_SITE_IN $ $! Separate processing for different routes $ $ IF P1 .EQS. "TOFILTER" THEN GOTO TOFILTER_Start $ IF P1 .EQS. "this" THEN GOTO this_Start $ IF P1 .EQS. "that" THEN GOTO that_Start $ EXIT 4 $ $!------------------------------------------------------------------------- $ $ TOFILTER_Start: $ $! Site Delivery Agent to get rid of SPAM $ $ DEFINE/USER_MODE SYS$OUTPUT NL: $ SEARCH 'P2' adxntorx $ IF ($SEVERITY .EQ. 1) THEN EXIT 1 $! (Exiting here means that the mail is forever lost, without a trace.) $! (Alternatively, you could branch somewhere and log it in a file.) $! (Better would be to have a small, custom program here to see whether $! or not the "dirty words" are specifically in address fields.) $! $! Modify contents of dest-file (P3) to change from TOFILTER to FILTERED $! $ DEFINE/USER_MODE SYS$OUTPUT NL: $ EDIT/EDT/COMMAND=MX_ROOT:[SITE]CHANGE_P3_FILTER.DAT 'P3' $ $ NEW_P3 = F$PARSE(";2",P3) $! $! Send processed file on its way $! $ MX_ENTER 'P2' 'NEW_P3' "''P4'" $! $ DELETE 'NEW_P3' $ EXIT 1 MX_ROOT:[SITE]CHANGE_P3_FILTER.DAT contains the following: SUBSTITUTE/TOFILTER>/FILTERED>/ WHOLE /NOTYPE EXIT Remember --- this software is untested, probably incorrect, and offered only for the ideas that it provides for interested parties. - Jonathan ================================================================================ Archive-Date: Wed, 16 Jul 1997 18:50:47 -0500 Sender: From: dyson@scat.physics.uiowa.edu (Richard L. Dyson) Subject: Re: UCX v4.1 ECO 6 POP3 Server on Alpha/OpenVMS v6.2 Date: 16 Jul 1997 23:37:04 GMT Message-ID: <5qjlv0$k7k$1@flood.weeg.uiowa.edu> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <5qginn$slo$1@flood.weeg.uiowa.edu>, dyson@scat.physics.uiowa.edu (Richard L. Dyson) writes: > In article <009B74AF.3AD2612A.75@ALPHA.WKU.EDU>, Hunter Goatley writes: > > Dan Wing writes: > > > > > >I suspect Digital is looking for in the VMSmail FROM: line to detect > > >if the message originates from SMTP, and if it doesn't see it > > >assumes it is a DECnet-delivered message and the POP3 server generates > > >RFC822 headers. > > > > > Yep! I forgot about that. I'm sure that it does look for that, since > > the IUPOP did. > > > > >Try changing MX to use instead of (which is documented in > > >MX_DOC:MX_MGMT_GUIDE.TXT) and see if that makes the POP3 server happier. > > > > > That should do it. > > We have a Bingo! > > Damn nice guys!!! > > I issued > > $ Define /System /Executive_Mode MX_Protocol_Prefix "SMTP%" OK, now my users on cluster satellite nodes can't "reply" to any internet messages. :( At first the errors to a "REPLY" were about unknown logical names or an unknown queue. I think it was really using SMTP instead of MX. It is hard to tell now... I fixed those with "UCX Start Mail" & "UCX Stop Mail". This defined the server queues, but I don't really want to use UCX's SMTP mail. I have rebooted satellite nodes with a clean UCX and MX startup. I start like this: $ @ Sys$Startup:UCX$Startup $ @ Sys$Startup:UCX$Service_SetUp SMTP later I run $ @ Sys$Startup:MX_Startup I can initiate a REPLY now and actually send the message off, but it never arrives at the destination. I can't see it with "MCP Queue Show" or with "Show Queue /All UCX$*". Does anyone have any ideas what I have messed up? What info do you need to help sort this out? Note, on my boot node all seems well (which is the only one I ever use so I missed this problem for over a day...) Regards, rick -- Richard L. Dyson dyson@iowasp.physics.uiowa.edu _ _ _____ http://www-pi.physics.uiowa.edu/~dyson/ | | | | |_ _| Systems Analyst O: 319/335-1879 | | | | of | | University of Iowa FAX: 319/335-1753 | \_/ | _| |_ Department of Physics & Astronomy H: 319/338-6117 \___/ |_____| Iowa City, IA 52242-1479 ================================================================================ Archive-Date: Wed, 16 Jul 1997 20:48:04 -0500 Sender: Date: Wed, 16 Jul 1997 18:47:49 -0700 From: Dan Wing Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <970716184749.2020de1d@Cisco.COM> Subject: Re: UCX v4.1 ECO 6 POP3 Server on Alpha/OpenVMS v6.2 >OK, now my users on cluster satellite nodes can't "reply" to any internet >messages. :( > >At first the errors to a "REPLY" were about unknown logical names or an >unknown queue. I think it was really using SMTP instead of MX. It is >hard to tell now... I fixed those with "UCX Start Mail" & "UCX Stop Mail". >This defined the server queues, but I don't really want to use UCX's SMTP >mail. > >I have rebooted satellite nodes with a clean UCX and MX startup. > >I start like this: > >$ @ Sys$Startup:UCX$Startup >$ @ Sys$Startup:UCX$Service_SetUp SMTP > >later I run > >$ @ Sys$Startup:MX_Startup Not a good idea to startup UCX's mailer and MX's mailer unless you want to run both. Not sure if you can do that, but from my experience with running 4 mailers at the same time on the same cluster, it can be quite frustrating to debug problems. >I can initiate a REPLY now and actually send the message off, but it >never arrives at the destination. I can't see it with "MCP Queue Show" >or with "Show Queue /All UCX$*". > >Does anyone have any ideas what I have messed up? What info do you need >to help sort this out? > >Note, on my boot node all seems well (which is the only one I ever use so >I missed this problem for over a day...) Define the logical name MX_VMSMAIL_SHOW_INFO to TRUE and send mail. If you get a message like: %MX-I-MAIDLVR, message (entry number 1) successfully delivered to MX then MX got the message. If you don't, then something else (such as UCX) got the message. -Dan Wing ================================================================================ Archive-Date: Wed, 16 Jul 1997 21:04:23 -0500 Sender: Message-ID: <01BC9219.B62BE920@pc29.planacc.com> From: Systems Management team Reply-To: MX-List@MadGoat.com To: "'mx-list@madgoat.com'" Subject: Date: Wed, 16 Jul 1997 18:54:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit SIGNOFF ================================================================================ Archive-Date: Thu, 17 Jul 1997 05:28:50 -0500 Sender: Date: Thu, 17 Jul 1997 10:16:42 GMT From: chris@ccagroup.co.uk Reply-To: MX-List@MadGoat.com To: mx-list@wkuvx1.wku.edu CC: chris@ccagroup.co.uk Message-ID: <009B7622.FCA416A5.45@ccagroup.co.uk> Subject: MX Alias Database Is it possible, or is there a mod available, to set up a two tier MX Alias Database (ie personal and systemwide). Something like: $ def mx_alias_database sys$login:mx-alias,sys$manager:mx-alias so that users can keep a personal directory of friends etc, as well as being able to use a companywide directory of business contacts. Obviously MX would then need to be able to read both files to get a match, depending who was being mailed. My environment is Alpha OpenVMS 6.2 (for most users) and VAX VMS 6.1 (for all incoming traffic). Thanks, Chris ______________________________________________________________________ Chris Sharman chris@ccagroup.co.uk Tel: +(44) 1772 662883 Fax: +(44) 1772 662893 CCA Stationery Ltd, Eastway, Fulwood, Preston, Lancs, PR2 9WS, ENGLAND ================================================================================ Archive-Date: Thu, 17 Jul 1997 08:13:58 -0500 Sender: Date: Thu, 17 Jul 1997 15:14:03 MET-1MET DST From: "Michael Lemke, Sternwarte Bamberg, Phone: +49-951-9522216" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: DYSON@IOWASP.PHYSICS.UIOWA.EDU, ai26@sternwarte.uni-erlangen.de Message-ID: <009B764C.866928F2.23@sternwarte.uni-erlangen.de> Subject: Re: UCX v4.1 ECO 6 POP3 Server on Alpha/OpenVMS v6.2 In a message of 16 Jul 1997 23:37:04 GMT Received on Thu, 17 Jul 1997 02:06:54 MET-1MET DST Richard L. Dyson wrote to: Message Exchange Discussion List >> >> I issued >> >> $ Define /System /Executive_Mode MX_Protocol_Prefix "SMTP%" > >OK, now my users on cluster satellite nodes can't "reply" to any internet >messages. :( > $ def/system MAIL$PROTOCOL_SMTP MX_MAILSHR should fix this. -- Michael Lemke Sternwarte Bamberg, University of Erlangen-Nürnberg, Germany (michael@astro.as.utexas.edu or ai26@a400.sternwarte.uni-erlangen.de) ================================================================================ Archive-Date: Thu, 17 Jul 1997 09:19:23 -0500 Sender: Date: Thu, 17 Jul 1997 09:19:18 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B761A.F7AF6754.46@ALPHA.WKU.EDU> Subject: RE: MX Alias Database chris@ccagroup.co.uk writes: > >Is it possible, or is there a mod available, to set up a two tier MX Alias >Database (ie personal and systemwide). > No, but that has been on my personal wish-list for a while too. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Thu, 17 Jul 1997 10:00:45 -0500 Sender: Date: Thu, 17 Jul 1997 09:28:51 EST From: Scott McNeilly Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B761C.4D009F80.35@fred.bridgew.edu> Subject: RE: MX Alias Database >From: chris@ccagroup.co.uk > >Is it possible, or is there a mod available, to set up a two tier MX Alias >Database (ie personal and systemwide). > >Something like: > >$ def mx_alias_database sys$login:mx-alias,sys$manager:mx-alias > >so that users can keep a personal directory of friends etc, as well as being >able to use a companywide directory of business contacts. Obviously MX would >then need to be able to read both files to get a match, depending who was being >mailed. Users can keep a personal directory of friends, etc., without any intervention on the part of MX. They can define "aliases" in their LOGIN.COM files, along these lines: $ DEFINE SUZIE "MX%""suzieq@host.net.domain""" $ DEFINE Bill "MX%""wsmith@xxxx.yyyy.zzzz""" And at the "TO: " prompt in the MAIL utility, type in "SUZIE" or "Bill" or whatever "alias" they care to define. As for companywide, you could use the "DEFINE ALIAS" command in MCP. You could also use the "SET FORWARD /USER" in VMS MAIL. -------------------------------------------------------------------- Scott Mc Neilly email: smcneilly@bridgew.edu Assistant Director Phone: 508-697-1236 Information Services FAX: 508-697-1774 Bridgewater State College Bridgewater, MA 02325 --------------------------------------------------------------------- ================================================================================ Archive-Date: Thu, 17 Jul 1997 10:28:41 -0500 Sender: Date: Thu, 17 Jul 1997 10:28:35 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B7624.A5617E74.14@ALPHA.WKU.EDU> Subject: RE: MX Alias Database Scott McNeilly writes: > >Users can keep a personal directory of friends, etc., without any intervention >on the part of MX. They can define "aliases" in their LOGIN.COM files, along >these lines: > > $ DEFINE SUZIE "MX%""suzieq@host.net.domain""" > $ DEFINE Bill "MX%""wsmith@xxxx.yyyy.zzzz""" >And at the "TO: " prompt in the MAIL utility, type in "SUZIE" or "Bill" or >whatever "alias" they care to define. > Yes, but using MXALIAS is much better, IMO. I have a couple of hundred aliases defined that don't take up memory used for defining logicals, etc. >As for companywide, you could use the "DEFINE ALIAS" command in MCP. You >could also use the "SET FORWARD /USER" in VMS MAIL. > Yes, this is the only way to do this right now.... Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Thu, 17 Jul 1997 10:51:03 -0500 Sender: From: dyson@scat.physics.uiowa.edu (Richard L. Dyson) Subject: Re: UCX v4.1 ECO 6 POP3 Server on Alpha/OpenVMS v6.2 Date: 17 Jul 1997 14:14:48 GMT Message-ID: <5ql9co$kci$1@flood.weeg.uiowa.edu> Reply-To: MX-List@MadGoat.com To: Dan Wing CC: To: MX-List@WKUVX1.WKU.EDU In article <970716184749.2020de1d@Cisco.COM>, Dan Wing writes: > >OK, now my users on cluster satellite nodes can't "reply" to any internet > >messages. :( > > > >At first the errors to a "REPLY" were about unknown logical names or an > >unknown queue. I think it was really using SMTP instead of MX. It is > >hard to tell now... I fixed those with "UCX Start Mail" & "UCX Stop Mail". > >This defined the server queues, but I don't really want to use UCX's SMTP > >mail. > > > >I have rebooted satellite nodes with a clean UCX and MX startup. > > > >I start like this: > > > >$ @ Sys$Startup:UCX$Startup > >$ @ Sys$Startup:UCX$Service_SetUp SMTP > > > >later I run > > > >$ @ Sys$Startup:MX_Startup > > Not a good idea to startup UCX's mailer and MX's mailer unless you want to > run both. Not sure if you can do that, but from my experience with running > 4 mailers at the same time on the same cluster, it can be quite frustrating > to debug problems. I would agree, but for a few months now, I had SMTP enabled so that POP would work from UCX and then MX handled everything else. Well, last night I decided to back out as much as possible, and get back to UCX as a core and let MX handle all e-mail and disable UCX's SMTP & POP. I then picked up the IUPOP3 v1.9b11 kit (which builds easily) and started it. Immediately POP worked and I don't have the MX/SMTP problems. Even though UCX POP is supposed to be based on IUPOP3, I guess it is just too much wed to UCX SMTP. Are there any IUPOP3 users that have an recommendations or "heads-up" notes about this version? So far, the default config is working OK for me to serve Eudora Pro and Netscape Mail on PCs. Regards, rick -- Richard L. Dyson dyson@iowasp.physics.uiowa.edu _ _ _____ http://www-pi.physics.uiowa.edu/~dyson/ | | | | |_ _| Systems Analyst O: 319/335-1879 | | | | of | | University of Iowa FAX: 319/335-1753 | \_/ | _| |_ Department of Physics & Astronomy H: 319/338-6117 \___/ |_____| Iowa City, IA 52242-1479 ================================================================================ Archive-Date: Thu, 17 Jul 1997 11:12:43 -0500 Sender: Date: Thu, 17 Jul 1997 13:12:35 -0300 (ADT) From: Ben Armstrong Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Subject: RE: MX Alias Database Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 17 Jul 1997, Hunter Goatley wrote: > Scott McNeilly writes: > >As for companywide, you could use the "DEFINE ALIAS" command in MCP. You > >could also use the "SET FORWARD /USER" in VMS MAIL. > > > Yes, this is the only way to do this right now.... ... which has the interesting side-effect of making the alias available to the entire world, not just your local user community Ben. -- Ben Armstrong -. Medianet Development Group, BArmstrong@dymaxion.ca `-. Dymaxion Research Limited `- Halifax, Nova Scotia, Canada ================================================================================ Archive-Date: Thu, 17 Jul 1997 11:22:27 -0500 Sender: Date: Thu, 17 Jul 1997 11:22:17 -0500 Message-ID: <2.2.16.19970717112334.1ec74dd0@blue.weeg.uiowa.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: MX-List@MadGoat.com From: Howard Meadows Reply-To: MX-List@MadGoat.com Subject: Re: UCX v4.1 ECO 6 POP3 Server on Alpha/OpenVMS v6.2 At 02:14 PM 7/17/97 GMT, Rick Dyson wrote: > I then picked up the IUPOP3 v1.9b11 kit (which builds easily) and >started it. Immediately POP worked and I don't have the MX/SMTP >problems. > > Even though UCX POP is supposed to be based on IUPOP3, I guess it is >just too much wed to UCX SMTP. > > Are there any IUPOP3 users that have an recommendations or "heads-up" >notes about this version? So far, the default config is working OK for >me to serve Eudora Pro and Netscape Mail on PCs. > >Regards, >rick >-- Rick; I don't know if this is a default with the UIPOP3 server or not (and I'm sure the version I ran for years on the Psych Departments OpenVMS box was *much* earlier than your version) but the one we had would keep a log file of ALL POP transactions. This was good if you needed to debug a problem, but with any kind of traffic, the files would grow quickly! If this is a settable feature, I'd disable it if not needed. A new log file would be opened each time the server was restarted, then you could purge the old version. -Howard *************************************************************************** * Howard Meadows Information Technology Services 200 Lindquist Center * * University Of Iowa Iowa City, Iowa 52242 Phone: 319-335-5519 * * email: howard-meadows@uiowa.edu FAX : 319-384-0701 * *************************************************************************** ================================================================================ Archive-Date: Thu, 17 Jul 1997 12:40:17 -0500 Sender: Date: Thu, 17 Jul 1997 12:40:12 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B7637.080A94F4.11@ALPHA.WKU.EDU> Subject: System-wide MXALIAS database 75% of supporting a system-wide MXALIAS database was already in the code---I just never got around to finishing it. I've now done so, so MX V5.0 will support both personal MXALIAS databases and a system-wide MXALIAS database (or groupwise, or whatever). The user will be able to define a logical to prevent MX from using the system-wide database, if s/he so desires. Note that this is only used by MX_MAILSHR to convert aliases to outgoing addresses. It has no effect on incoming mail. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Fri, 18 Jul 1997 04:58:16 -0500 Sender: Date: Fri, 18 Jul 1997 10:57:25 BST From: Andy Harper Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: A.HARPER@kcl.ac.uk Message-ID: <009B76F1.D6D8BCE4.205@alder.cc.kcl.ac.uk> Subject: Re: UCX v4.1 ECO 6 POP3 Server on Alpha/OpenVMS v6.2 > I don't know if this is a default with the UIPOP3 server or not (and >I'm sure the version I ran for years on the Psych Departments OpenVMS box >was *much* earlier than your version) but the one we had would keep a log >file of ALL POP transactions. This was good if you needed to debug a >problem, but with any kind of traffic, the files would grow quickly! > > If this is a settable feature, I'd disable it if not needed. A new >log file would be opened each time the server was restarted, then you could >purge the old version. The latest version has four levels of log file info, from none thru to everything. It can also auto create a new log file each night. Version 1.9 Beta 11 is available from http://www.tcl.uni-hannover.de/pub/iupop3/index.htmlx PLUS it supports NETLIB as the tcp interface... Regards, Andy Harper Kings College London ================================================================================ Archive-Date: Fri, 18 Jul 1997 13:24:36 -0500 Sender: Date: Fri, 18 Jul 1997 16:12:26 GMT From: chris@ccagroup.co.uk Reply-To: MX-List@MadGoat.com To: MX-List@madgoat.com CC: chris@ccagroup.co.uk Message-ID: <009B771D.D8A39284.4@ccagroup.co.uk> Subject: RE: System-wide MXALIAS database By the way: I have a simple Powerhouse maintenance screen for the MX Alias database, if anyone's interested. Suitable for captive users who don't want a command line interface. ______________________________________________________________________ Chris Sharman chris@ccagroup.co.uk Tel: +(44) 1772 662883 Fax: +(44) 1772 662893 CCA Stationery Ltd, Eastway, Fulwood, Preston, Lancs, PR2 9WS, ENGLAND ================================================================================ Archive-Date: Fri, 18 Jul 1997 13:36:06 -0500 Sender: Date: Fri, 18 Jul 1997 16:09:21 GMT From: chris@ccagroup.co.uk Reply-To: MX-List@MadGoat.com To: MX-List@madgoat.com CC: chris@ccagroup.co.uk Message-ID: <009B771D.6A53AF8A.3@ccagroup.co.uk> Subject: RE: System-wide MXALIAS database >75% of supporting a system-wide MXALIAS database was already in the >code---I just never got around to finishing it. I've now done so, so >MX V5.0 will support both personal MXALIAS databases and a system-wide >MXALIAS database (or groupwise, or whatever). The user will be able >to define a logical to prevent MX from using the system-wide database, >if s/he so desires. Thanks, that's great. When's 5.0 coming out ? What's changed from 4.1 ? ______________________________________________________________________ Chris Sharman chris@ccagroup.co.uk Tel: +(44) 1772 662883 Fax: +(44) 1772 662893 CCA Stationery Ltd, Eastway, Fulwood, Preston, Lancs, PR2 9WS, ENGLAND ================================================================================ Archive-Date: Fri, 18 Jul 1997 18:17:08 -0500 Sender: Date: Fri, 18 Jul 1997 18:17:02 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B772F.4115C739.33@ALPHA.WKU.EDU> Subject: RE: System-wide MXALIAS database chris@ccagroup.co.uk writes: > >When's 5.0 coming out ? Mid-August, we hope. >What's changed from 4.1 ? Everything that was in V4.2 plus new features for V5.0. 8-) Seriously, I don't have a list made up yet, but will do so soon. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Wed, 23 Jul 1997 13:23:34 -0500 Sender: Date: Wed, 23 Jul 1997 14:23:12 EST From: Jim Bender Reply-To: MX-List@MadGoat.com To: mx-list@madgoat.com Message-ID: <009B7AFC.6A2CBDA2.320@bdsnet.com> Subject: Queue entry numbers keep increasing Hi! The entry numbers in our MX queue keep increasing, rather than resetting as they used to do. When this happened in the past, we were able to fix it with the MCP QUEUE SYNC command. However, now this only gets the queue numbers restarting from 0, and they continue to increase from there. Normal behaviour is for the numbers to recycle periodically automatically. Any ideas what can be amiss here? Not sure where to start looking. Thanks! Jim Bender jbender@bdsnet.com ================================================================================ Archive-Date: Thu, 24 Jul 1997 11:41:39 -0500 Sender: Date: Thu, 24 Jul 1997 13:41:29 -0300 (ADT) From: Ben Armstrong Reply-To: MX-List@MadGoat.com To: mx-list@madgoat.com Subject: MX 4.1: Trouble sending message from Netscape 3.0 (?) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I'm not sure if Netscape is the culprit, but in other respects, MX seems to behave just fine. Here is an edited transcript of a rejected message (host and usernames have been changed). Has anyone else had this problem? If so, how do I fix it? Thanks, Ben. -- Ben Armstrong -. Medianet Development Group, BArmstrong@dymaxion.ca `-. Dymaxion Research Limited `- Halifax, Nova Scotia, Canada ------- Forwarded Message Follows ------- Date: Wed, 16 Jul 1997 11:02:28 EDT From: SMTP delivery agent To: Subject: SMTP delivery error Note: this message was generated automatically. An error was detected while processing the enclosed message. A list of the affected recipients follows. This list is in a special format that allows software like LISTSERV to automatically take action on incorrect addresses; you can safely ignore the numeric codes. --> Error description: Error-For: Info@some.org Error-Code: 2 Error-Text: %SYSTEM-F-NOPRIV, insufficient privilege or object protection violation -Retry count exceeded -(Via some.org) Error-End: 1 error detected ------------------------------ Rejected message ------------------------------ Received: from ... Received: from ... Message-ID: ... Date: Mon, 14 Jul 1997 11:02:31 -0400 From: Joe User Reply-To: JoeUser@some.org X-Mailer: Mozilla 3.0 (WinNT; I) MIME-Version: 1.0 To: Info@some.org Subject: Test III Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is a test message sent from the order form page. ================================================================================ Archive-Date: Thu, 24 Jul 1997 11:54:57 -0500 Sender: Date: Thu, 24 Jul 1997 9:54:49 -0700 From: Matt Madison Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <970724095449.20246fa4@Cisco.COM> Subject: RE: Queue entry numbers keep increasing >The entry numbers in our MX queue keep increasing, rather than >resetting as they used to do. > >When this happened in the past, we were able to fix it with >the MCP QUEUE SYNC command. However, now this only gets the >queue numbers restarting from 0, and they continue to increase >from there. Normal behaviour is for the numbers to recycle >periodically automatically. > >Any ideas what can be amiss here? Not sure where to start >looking. Which version of MX? Also, if you do an MCP QUEUE SHOW/ALL, do you see the entries for the entry numbers that aren't being reused? If so, then how often is the queue getting purged? -Matt -- Matthew Madison | | madison@cisco.com Cisco Systems | 101 Cooper St. | Santa Cruz, CA 95060 USA | +1 408 457 5390 ================================================================================ Archive-Date: Thu, 24 Jul 1997 12:38:01 -0500 Sender: Date: Thu, 24 Jul 1997 10:37:54 -0700 From: Dan Wing Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <970724103754.20276774@Cisco.COM> Subject: RE: MX 4.1: Trouble sending message from Netscape 3.0 (?) >I'm not sure if Netscape is the culprit, but in other respects, >MX seems to behave just fine. Here is an edited transcript of >a rejected message (host and usernames have been changed). > >Has anyone else had this problem? If so, how do I fix it? >Error-For: Info@some.org >Error-Code: 2 >Error-Text: %SYSTEM-F-NOPRIV, insufficient privilege or object protection violation > -Retry count exceeded > -(Via some.org) Enable VMS security auditing which should be the fastest way to track this down. -Dan Wing ================================================================================ Archive-Date: Thu, 24 Jul 1997 12:49:17 -0500 Sender: Date: Thu, 24 Jul 1997 13:49:02 EST From: Jim Bender Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B7BC0.CEE964F6.111@bdsnet.com> Subject: RE: Queue entry numbers keep increasing >>The entry numbers in our MX queue keep increasing, rather than >>resetting as they used to do. >> >>When this happened in the past, we were able to fix it with >>the MCP QUEUE SYNC command. However, now this only gets the >>queue numbers restarting from 0, and they continue to increase >>from there. Normal behaviour is for the numbers to recycle >>periodically automatically. >> >>Any ideas what can be amiss here? Not sure where to start >>looking. > >Which version of MX? Also, if you do an MCP QUEUE SHOW/ALL, do you see >the entries for the entry numbers that aren't being reused? If so, then >how often is the queue getting purged? Hi! Sorry, left out that vital piece of info... MX V4.2, VMS 5.5-2 Queue is supposed to be automatically purged every 15 minutes. No, the numbers that were not being reused did not show up in a MCP QUEUE SHOW/ALL, and in fact, several times that command showed only 1 or 2 entries, something that NEVER happens due to the volume of mail we receive. (Mail was still coming in and being delivered, however.) I noticed that there were MANY files in the [MX042.QUEUE...] dirs that were not being purged for some reason. This seems to have been the reason for the unusual queue entry numbering. i.e., the entry numbers associated with these stray files were being skipped. Deleting these files seems to have restored the queue numbering, but we have that uneasy feeling still as we have no idea why all these files got left behind. From what I saw, they were relatively recent files. none older than a few days. Isn't the MCP QUEUE SYNC command supposed to rebuild the queue bitmap based upon the files actually in the queue? At least that is how the HELP entry for SYNC reads. If that is the case, shouldn't it have found these files and put them back into the queue listing? Something else that may not be related: Occasionally we receive messages that do not show in the queue listing (MCP QUEUE SHOW/ALL). That is, I receive a message from someone@yoyodyne.com and do a MCP QUEUE SHOW /ALL, the message is not there, although many older messages (up to the time of the last purge) are there. Just a curious oddity, mostly, since the mail still gets delivered. But it would be cool to know why it does this just the same. >-Matt Thanks, Jim Bender jbender@bdsnet.com ================================================================================ Archive-Date: Thu, 24 Jul 1997 13:32:46 -0500 Sender: Date: Thu, 24 Jul 1997 13:32:40 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B7BBE.857E6D87.1@ALPHA.WKU.EDU> Subject: RE: Queue entry numbers keep increasing Jim Bender writes: > >Isn't the MCP QUEUE SYNC command supposed to rebuild the queue bitmap >based upon the files actually in the queue? At least that is how >the HELP entry for SYNC reads. If that is the case, shouldn't it >have found these files and put them back into the queue listing? > No, that's not what it does. I'll check the help entry and reword it if necessary. All QUEUE SYNC does is run through the queue and ensure that the queue bitmap matches the entries in the queue---it doesn't actually look for external files in the [MX.QUEUE...] tree. >Something else that may not be related: Occasionally we receive >messages that do not show in the queue listing (MCP QUEUE SHOW/ALL). >That is, I receive a message from someone@yoyodyne.com and do a >MCP QUEUE SHOW /ALL, the message is not there, although many older >messages (up to the time of the last purge) are there. Just a >curious oddity, mostly, since the mail still gets delivered. But it >would be cool to know why it does this just the same. > Those are probably because the MAIL FROM: used some other address, while the From: line shows "someone@yoyodyne.com". They don't have to match. As for what caused the problem in the first place, I'm not sure, but it sounds like your queue may have been corrupted somehow. It also sounds like it's operational again now. True? Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Thu, 24 Jul 1997 13:44:43 -0500 Sender: Date: Thu, 24 Jul 1997 14:44:27 EST From: Jim Bender Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B7BC8.8CF0AFB6.200@bdsnet.com> Subject: RE: Queue entry numbers keep increasing >Jim Bender writes: >> >>Isn't the MCP QUEUE SYNC command supposed to rebuild the queue bitmap >>based upon the files actually in the queue? At least that is how >>the HELP entry for SYNC reads. If that is the case, shouldn't it >>have found these files and put them back into the queue listing? >> >No, that's not what it does. I'll check the help entry and reword it >if necessary. All QUEUE SYNC does is run through the queue and ensure >that the queue bitmap matches the entries in the queue---it doesn't >actually look for external files in the [MX.QUEUE...] tree. Yes, I checked it again and it doesn't say anything about files. It says it matches the bitmap against actual queue entries. At first glance somehow we got the idea that this would include a scan of the queue directories. >>Something else that may not be related: Occasionally we receive >>messages that do not show in the queue listing (MCP QUEUE SHOW/ALL). >>That is, I receive a message from someone@yoyodyne.com and do a >>MCP QUEUE SHOW /ALL, the message is not there, although many older >>messages (up to the time of the last purge) are there. Just a >>curious oddity, mostly, since the mail still gets delivered. But it >>would be cool to know why it does this just the same. >> >Those are probably because the MAIL FROM: used some other address, >while the From: line shows "someone@yoyodyne.com". They don't have to >match. I am familiar with that behaviour. I am certain that is not the case in the occurances I am seeing. The message is not in the queue listing at all. >As for what caused the problem in the first place, I'm not sure, but >it sounds like your queue may have been corrupted somehow. It also >sounds like it's operational again now. True? Yes, things seem to be working fine again. >Hunter >------ Thanks! Jim Bender jbender@bdsnet.com ================================================================================ Archive-Date: Thu, 24 Jul 1997 13:47:53 -0500 Sender: Date: Thu, 24 Jul 1997 13:47:47 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B7BC0.A1E931D5.39@ALPHA.WKU.EDU> Subject: RE: Queue entry numbers keep increasing Jim Bender writes: > >Yes, I checked it again and it doesn't say anything about files. It >says it matches the bitmap against actual queue entries. At first >glance somehow we got the idea that this would include a scan >of the queue directories. > I do plan to provide such a tool in V5.0, for use in recreating a corrupted queue. >I am familiar with that behaviour. I am certain that is not the >case in the occurances I am seeing. The message is not in the >queue listing at all. > Strange.... Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Thu, 24 Jul 1997 15:48:38 -0500 Sender: Message-ID: <3.0.2.32.19970724155114.006945ec@ccr.dsi.uanl.mx> Date: Thu, 24 Jul 1997 15:51:14 -0600 To: MX-List@MadGoat.com From: Erick Javier Retta Carrizales Reply-To: MX-List@MadGoat.com Subject: RE: Queue entry numbers keep increasing MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 02:44 PM 24/07/97 EST, you wrote: What do you tink about using the next command QUEUE COMPRESS the help says: Shrinks the message queue file by creating a new file and renumbering all the existing entries in the file. may it solve the problem ???? ================================================================================ Archive-Date: Fri, 25 Jul 1997 10:00:09 -0500 Sender: Date: Fri, 25 Jul 1997 11:59:58 -0300 (ADT) From: Ben Armstrong Reply-To: MX-List@MadGoat.com To: mx-list@madgoat.com Subject: Mail messages with no line wrap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does anyone know of a way for MX or VMS MAIL to automatically wrap mail messages that have no line wraps? Occasionally we receive messages from individuals whose mail clients apparently do not wrap lines. This wouldn't be a big problem for us, provided we could live with manually wrapping these messages, except VMS MAIL apparently truncates lines past some limit (probably around 512 characters). Ben. -- Ben Armstrong -. Medianet Development Group, BArmstrong@dymaxion.ca `-. Dymaxion Research Limited `- Halifax, Nova Scotia, Canada ================================================================================ Archive-Date: Fri, 25 Jul 1997 10:54:12 -0500 Sender: Date: Fri, 25 Jul 1997 12:53:58 -0300 (ADT) From: Ben Armstrong Reply-To: MX-List@MadGoat.com To: "H.A. Kippenhan Jr." CC: mx-list@madgoat.com Subject: Re: Mail messages with no line wrap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 25 Jul 1997, H.A. Kippenhan Jr. wrote: > Hi Ben: > > On Fri, 25 Jul 1997, Ben Armstrong wrote: > > > Does anyone know of a way for MX or VMS MAIL to automatically wrap > > mail messages that have no line wraps? Occasionally we receive > > messages from individuals whose mail clients apparently do not wrap > > lines. This wouldn't be a big problem for us, provided we could live > > with manually wrapping these messages, except VMS MAIL apparently > > truncates lines past some limit (probably around 512 characters). > > > I believe that MX does the proper thing with respect to e-mail > messages with long lines. The user agent (in this case VMS mail) > is what is truncating the lines. I'm sure it does. However, it would be handy to have a way to "cheat" to handle bad mail rather than to expend the time and effort correcting the people we do business with, and possibly being a source of aggravation to them as well. > That said, I also believe there is a limit to line length > specified in one of the RFC's (as I recall it's 255 characters). > So the mail system at the originating end is really at fault. > Probably the best thing to do is to teach the originator of the > e-mail to hit a carriage return every now and again. The problem is that other people apparently receive their mail from these individuals without any trouble, and so long as they do, they will view *us* as being the problem regardless of whether or not there is an RFC to back up our position. > Sorry to not have a better answer. Well, if the answer is no, we can't, then I guess we will just have to live with it, but if there is any possible way to work around the problem, rather than having to tell our clients to change their e-mail habits, we are interested. Thanks for taking the time to answer, Ben -- Ben Armstrong -. Medianet Development Group, BArmstrong@dymaxion.ca `-. Dymaxion Research Limited `- Halifax, Nova Scotia, Canada ================================================================================ Archive-Date: Fri, 25 Jul 1997 11:09:36 -0500 Sender: Date: Fri, 25 Jul 1997 11:08:19 CDT From: metze@vmetze.mrl.uiuc.edu Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: metze@vmetze.mrl.uiuc.edu Message-ID: <009B7C73.857784DE.11@vmetze.mrl.uiuc.edu> Subject: Re: Mail messages with no line wrap > > On Fri, 25 Jul 1997, H.A. Kippenhan Jr. wrote: > > Hi Ben: > > > > On Fri, 25 Jul 1997, Ben Armstrong wrote: > > > > > Does anyone know of a way for MX or VMS MAIL to automatically wrap > > > mail messages that have no line wraps? Occasionally we receive > > > messages from individuals whose mail clients apparently do not wrap > > > lines. This wouldn't be a big problem for us, provided we could live > > > with manually wrapping these messages, except VMS MAIL apparently > > > truncates lines past some limit (probably around 512 characters). > > > > > I believe that MX does the proper thing with respect to e-mail > > messages with long lines. The user agent (in this case VMS mail) > > is what is truncating the lines. > > I'm sure it does. However, it would be handy to have a way to "cheat" > to handle bad mail rather than to expend the time and effort > correcting the people we do business with, and possibly being a source > of aggravation to them as well. I agree. I am more and more frequently receiving mail from PC systems which seem to be able to interchange messages with arbitrary line lengths. It would be ideal if the mail transport agents used by non-PC systems would somehow insert carriage returns at some arbitrary place when lines exceed 255 characters. There is no way to change the world, particularly when the world believes you to be the fault. Ginny > > > That said, I also believe there is a limit to line length > > specified in one of the RFC's (as I recall it's 255 characters). > > So the mail system at the originating end is really at fault. > > Probably the best thing to do is to teach the originator of the > > e-mail to hit a carriage return every now and again. > > The problem is that other people apparently receive their mail from > these individuals without any trouble, and so long as they do, they > will view *us* as being the problem regardless of whether or not there > is an RFC to back up our position. > > > Sorry to not have a better answer. > > Well, if the answer is no, we can't, then I guess we will just have to > live with it, but if there is any possible way to work around the > problem, rather than having to tell our clients to change their e-mail > habits, we are interested. > > Thanks for taking the time to answer, > Ben > -- > Ben Armstrong -. Medianet Development Group, > BArmstrong@dymaxion.ca `-. Dymaxion Research Limited > `- Halifax, Nova Scotia, Canada > > ================================================================================ Archive-Date: Fri, 25 Jul 1997 11:27:42 -0500 Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: MX-List@MadGoat.com From: sgarrett@teleport.com (Stephen Garrett) Reply-To: MX-List@MadGoat.com Subject: Re: Mail messages with no line wrap Date: Fri, 25 Jul 1997 11:27:38 -0500 I have encountered this problem many times. The VMS mailer truncates at 255 chars and many times email msgs are unreadable. The email clients that issue these msgs and their _similar non RFC following_ bretheren are /can be a big pain. (altho I seem to recall that the RFC's allow line lengths of up to 1024 characters, so the VMS mailer may be called non-compliant as well!) The only conclusion I could ever come up with, outside of mods to MX itself, is to run *all* received email thru the site interface, and add in your own "filtering" logic... Steve >On Fri, 25 Jul 1997, H.A. Kippenhan Jr. wrote: >> Hi Ben: >> >> On Fri, 25 Jul 1997, Ben Armstrong wrote: >> >> > Does anyone know of a way for MX or VMS MAIL to automatically wrap >> > mail messages that have no line wraps? Occasionally we receive >> > messages from individuals whose mail clients apparently do not wrap >> > lines. This wouldn't be a big problem for us, provided we could live >> > with manually wrapping these messages, except VMS MAIL apparently >> > truncates lines past some limit (probably around 512 characters). >> > >> I believe that MX does the proper thing with respect to e-mail >> messages with long lines. The user agent (in this case VMS mail) >> is what is truncating the lines. > >I'm sure it does. However, it would be handy to have a way to "cheat" >to handle bad mail rather than to expend the time and effort >correcting the people we do business with, and possibly being a source >of aggravation to them as well. > >> That said, I also believe there is a limit to line length >> specified in one of the RFC's (as I recall it's 255 characters). >> So the mail system at the originating end is really at fault. >> Probably the best thing to do is to teach the originator of the >> e-mail to hit a carriage return every now and again. > >The problem is that other people apparently receive their mail from >these individuals without any trouble, and so long as they do, they >will view *us* as being the problem regardless of whether or not there >is an RFC to back up our position. > >> Sorry to not have a better answer. > >Well, if the answer is no, we can't, then I guess we will just have to >live with it, but if there is any possible way to work around the >problem, rather than having to tell our clients to change their e-mail >habits, we are interested. > >Thanks for taking the time to answer, >Ben >-- > Ben Armstrong -. Medianet Development Group, > BArmstrong@dymaxion.ca `-. Dymaxion Research Limited > `- Halifax, Nova Scotia, Canada > > ================================================================================ Archive-Date: Fri, 25 Jul 1997 11:50:08 -0500 Sender: Date: Fri, 25 Jul 1997 12:49:43 EDT From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: hardis@garnet.nist.gov Message-ID: <009B7C81.B009A840.11@garnet.nist.gov> Subject: Re: Mail messages with no line wrap >> Does anyone know of a way for MX or VMS MAIL to automatically wrap >> mail messages that have no line wraps? Occasionally we receive >> messages from individuals whose mail clients apparently do not wrap >> lines. This wouldn't be a big problem for us, provided we could live >> with manually wrapping these messages, except VMS MAIL apparently >> truncates lines past some limit (probably around 512 characters). Amen to that. (And it's 255 characters, not 512.) >> I believe that MX does the proper thing with respect to e-mail >> messages with long lines. The user agent (in this case VMS mail) >> is what is truncating the lines. Well, it's VMS mail that's truncating the lines. However, nothing says that MX can't automatically apply a MIME "quotable printable" filter to the data stream. >> That said, I also believe there is a limit to line length >> specified in one of the RFC's (as I recall it's 255 characters). >> So the mail system at the originating end is really at fault. >> Probably the best thing to do is to teach the originator of the >> e-mail to hit a carriage return every now and again. Hold on to your seats, boys and girls... but as best as I can tell, no RFC ever addressed the issue of maximum line length. Until word processors with automatic word-wrap came on the scene in the early '80s, it was never an issue! The RFCs specify the maximum line length for _headers_, and the MIME specification limits the line length to be 75 characters (as I remember), but there is no specification on the generalized _body_ of the message. (Here's a good reason to recommend that people turn on MIME encoding for their mail system -- that will break lines up to reasonable size.) Then again, the only RFC that addresses the length of an SMTP message says that all mail systems should handle mail at least 64 KB long. - Jonathan ================================================================================ Archive-Date: Fri, 25 Jul 1997 12:01:02 -0500 Sender: Date: Fri, 25 Jul 1997 13:59:39 -0300 (ADT) From: Ben Armstrong Reply-To: MX-List@MadGoat.com To: "Jonathan E. Hardis" Subject: Re: Mail messages with no line wrap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Date: Fri, 25 Jul 1997 14:00:48 -0300 (ADT) Resent-From: Ben Armstrong Resent-To: mx-list@madgoat.com Resent-Message-ID: On Fri, 25 Jul 1997, Jonathan E. Hardis wrote: > >> Does anyone know of a way for MX or VMS MAIL to automatically wrap > >> mail messages that have no line wraps? Occasionally we receive > >> messages from individuals whose mail clients apparently do not wrap > >> lines. This wouldn't be a big problem for us, provided we could live > >> with manually wrapping these messages, except VMS MAIL apparently > >> truncates lines past some limit (probably around 512 characters). > > Amen to that. (And it's 255 characters, not 512.) Ahh, that would make sense ... constrained by byte-addressing no doubt. Here is a bit of speculation. Perhaps this is fixed in VMS 7.1? Check this out: OVMS 7.1 Programming Release notes 5.14.1.1 MAIL$SEND,MAIL$MESSAGE, and MAIL$MAILFILE Return Status Modifications V7.1 The MAIL utility routines MAIL$SEND, MAIL$MESSAGE and MAIL$MAILFILE have been modified to return a word-sized length for items specified in the output list. Doesn't "word-sized length" sound hopeful? Anyway, that would wrap the messages, it would just ensure that they didn't get totally mangled. Anybody have any experience with long line-length messages on VMS 7.1? > Well, it's VMS mail that's truncating the lines. However, nothing says > that MX can't automatically apply a MIME "quotable printable" filter > to the data stream. How, pray tell, would we do that? Or by "we", do you mean the MX developers. :) I've seen the suggestion that we use a SITE agent, but I wouldn't want everyone to go re-inventing the wheel to solve the same problem. It seems there should be a "standard" solution distributed with MX that future MX users can turn on if they so desire. > >> That said, I also believe there is a limit to line length > >> specified in one of the RFC's (as I recall it's 255 characters). > >> So the mail system at the originating end is really at fault. > >> Probably the best thing to do is to teach the originator of the > >> e-mail to hit a carriage return every now and again. > > Hold on to your seats, boys and girls... but as best as I can tell, > no RFC ever addressed the issue of maximum line length. Until word > processors with automatic word-wrap came on the scene in the early > '80s, it was never an issue! > > The RFCs specify the maximum line length for _headers_, and the MIME > specification limits the line length to be 75 characters (as I remember), > but there is no specification on the generalized _body_ of the message. > (Here's a good reason to recommend that people turn on MIME encoding for > their mail system -- that will break lines up to reasonable size.) Fascinating! > Then again, the only RFC that addresses the length of an SMTP message says > that all mail systems should handle mail at least 64 KB long. ... and even that doesn't put an upper limit on it. Hmm. Well, I guess I would like to hear from the developers of MX what their take is on this issue. Ben. -- Ben Armstrong -. Medianet Development Group, BArmstrong@dymaxion.ca `-. Dymaxion Research Limited `- Halifax, Nova Scotia, Canada ================================================================================ Archive-Date: Fri, 25 Jul 1997 12:02:42 -0500 Sender: Date: Fri, 25 Jul 1997 14:02:36 -0300 (ADT) From: Ben Armstrong Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Subject: Re: Mail messages with no line wrap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 25 Jul 1997, Ben Armstrong wrote: > Doesn't "word-sized length" sound hopeful? Anyway, that would wrap oops ... "wouldn't wrap", i meant > the messages, it would just ensure that they didn't get totally > mangled. -- Ben Armstrong -. Medianet Development Group, BArmstrong@dymaxion.ca `-. Dymaxion Research Limited `- Halifax, Nova Scotia, Canada ================================================================================ Archive-Date: Fri, 25 Jul 1997 12:57:33 -0500 Sender: Date: Fri, 25 Jul 1997 13:57:00 -0400 From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B7C8B.16256700.3@swdev.si.com> Subject: Re: Mail messages with no line wrap >I have encountered this problem many times. The VMS mailer truncates >at 255 chars and many times email msgs are unreadable. The email clients >that issue these msgs and their _similar non RFC following_ bretheren >are /can be a big pain. (altho I seem to recall that the RFC's allow >line lengths of up to 1024 characters, so the VMS mailer may be called >non-compliant as well!) Section 4.5.3 of RFC 821 says: 4.5.3. SIZES There are several objects that have required minimum maximum sizes. That is, every implementation must be able to receive objects of at least these sizes, but must not send objects larger than these sizes. **************************************************** * * * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * * OF THESE OBJECTS SHOULD BE USED. * * * **************************************************** user The maximum total length of a user name is 64 characters. domain The maximum total length of a domain name or number is 64 characters. path The maximum total length of a reverse-path or forward-path is 256 characters (including the punctuation and element separators). command line The maximum total length of a command line including the command word and the is 512 characters. reply line The maximum total length of a reply line including the reply code and the is 512 characters. text line The maximum total length of a text line including the is 1000 characters (but not counting the leading dot duplicated for transparency). recipients buffer The maximum total number of recipients that must be buffered is 100 recipients. This says that RFC-compliant software MUST ACCEPT at least 1000 characters and MUST NEVER SEND more than 1000 characters in any text line. So, VMS Mail is, of course, non-compliant because it stops at 255. However, anyone whose software sends 512 (or 700, or 900) characters in a text line is correct to point the finger at those of us who use VMS Mail. However, since it is MX that is receiving the message (via SMTP_SERVER), prior to handing it to VMS Mail, why can't MX wrap the long lines? A side question: does MX send a 5xx reply code when it received a text line liner than 1000 characters? -- Brian Tillman Internet: tillman_brian at si.com Smiths Industries, Inc. tillman at swdev.si.com 4141 Eastern Ave., MS239 Addresses modified to prevent Grand Rapids, MI 49518-8727 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ================================================================================ Archive-Date: Fri, 25 Jul 1997 14:03:14 -0500 Sender: Date: Fri, 25 Jul 1997 12:03:04 -0700 From: Matt Madison Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <970725120304.2027b803@Cisco.COM> Subject: Re: Mail messages with no line wrap "Jonathan E. Hardis" writes: >Well, it's VMS mail that's truncating the lines. However, nothing says >that MX can't automatically apply a MIME "quotable printable" filter >to the data stream. And MX V5.0 will have that feature. That doesn't mean, of course, that VMS MAIL will be any smarter about how it displays long lines. -Matt -- Matthew Madison | | madison@cisco.com Cisco Systems | 101 Cooper St. | Santa Cruz, CA 95060 USA | +1 408 457 5390 ================================================================================ Archive-Date: Fri, 25 Jul 1997 14:15:21 -0500 Sender: Date: Fri, 25 Jul 1997 16:15:09 -0300 (ADT) From: Ben Armstrong Reply-To: MX-List@MadGoat.com To: Matt Madison CC: mx-list@madgoat.com Subject: Re: Mail messages with no line wrap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 25 Jul 1997, Matt Madison wrote: > "Jonathan E. Hardis" writes: > >Well, it's VMS mail that's truncating the lines. However, nothing says > >that MX can't automatically apply a MIME "quotable printable" filter > >to the data stream. > > And MX V5.0 will have that feature. That doesn't mean, of course, that > VMS MAIL will be any smarter about how it displays long lines. In what way would "quoted printable" help, then? Isn't that the scheme in which long lines are wrapped and an equals sign is placed at the end of the line? What determines the wrap width? I don't mind if we have to do a bit of re-assembly to read these broken messages. I do mind, however, if the messages are rendered totally unreadable by VMS mail. Would that still happen with the "quoted printable" turned on? Ben. -- Ben Armstrong -. Medianet Development Group, BArmstrong@dymaxion.ca `-. Dymaxion Research Limited `- Halifax, Nova Scotia, Canada ================================================================================ Archive-Date: Fri, 25 Jul 1997 14:16:16 -0500 Sender: Date: Fri, 25 Jul 1997 14:14:59 CDT From: metze@vmetze.mrl.uiuc.edu Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: metze@vmetze.mrl.uiuc.edu Message-ID: <009B7C8D.992BAE05.4@vmetze.mrl.uiuc.edu> Subject: Re: Mail messages with no line wrap > > "Jonathan E. Hardis" writes: > >Well, it's VMS mail that's truncating the lines. However, nothing says > >that MX can't automatically apply a MIME "quotable printable" filter > >to the data stream. > > And MX V5.0 will have that feature. That doesn't mean, of course, that > VMS MAIL will be any smarter about how it displays long lines. > Unfortunately it is clear that at least some DEC administrators don't realize that OpenVMS has these problems. I couldn't read some mail because of this... finally got it right when it was forwarded to my home PC :-( Good ole Jesse Lipcon sends mail one can read, though! Ginny Metze > -Matt > > -- > Matthew Madison | | madison@cisco.com > Cisco Systems | 101 Cooper St. | Santa Cruz, CA 95060 USA | +1 408 457 5390 ================================================================================ Archive-Date: Fri, 25 Jul 1997 15:04:10 -0500 Sender: Date: Fri, 25 Jul 1997 13:04:03 -0700 From: Dan Wing Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <970725130403.2027451b@Cisco.COM> Subject: Re: Mail messages with no line wrap >In what way would "quoted printable" help, then? Isn't that the >scheme in which long lines are wrapped and an equals sign is placed >at the end of the line? What determines the wrap width? RFC2045, 76 characters. >I don't mind if we have to do a bit of re-assembly to read these >broken messages. I do mind, however, if the messages are rendered >totally unreadable by VMS mail. Would that still happen with the >"quoted printable" turned on? I use VMSmail exclusively and get quoted printable quite often (as the MultiNet SMTP that I use doesn't have a quoted-printable decoder). It is ugly, but it is definately not "totally unreadable". Compared to the alternative, which is loss of long lines, quoted-printable is the only real solution. Furthermore, real MIME-aware UAs will display the message perfectly, which wouldn't happen if some other scheme were to be used. -d ================================================================================ Archive-Date: Fri, 25 Jul 1997 15:19:20 -0500 Sender: Date: Fri, 25 Jul 1997 17:19:14 -0300 (ADT) From: Ben Armstrong Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Subject: Re: Mail messages with no line wrap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII If I use quoted-printable universally, will all of my e-mail received via MX look ugly? If so, then I don't think this is a viable solution for us. Ben. On Fri, 25 Jul 1997, Dan Wing wrote: > >In what way would "quoted printable" help, then? Isn't that the > >scheme in which long lines are wrapped and an equals sign is placed > >at the end of the line? What determines the wrap width? > > RFC2045, 76 characters. > > >I don't mind if we have to do a bit of re-assembly to read these > >broken messages. I do mind, however, if the messages are rendered > >totally unreadable by VMS mail. Would that still happen with the > >"quoted printable" turned on? > > I use VMSmail exclusively and get quoted printable quite often (as the > MultiNet SMTP that I use doesn't have a quoted-printable decoder). It is > ugly, but it is definately not "totally unreadable". Compared to the > alternative, which is loss of long lines, quoted-printable is the only > real solution. Furthermore, real MIME-aware UAs will display the message > perfectly, which wouldn't happen if some other scheme were to be used. > > -d > -- Ben Armstrong -. Medianet Development Group, BArmstrong@dymaxion.ca `-. Dymaxion Research Limited `- Halifax, Nova Scotia, Canada ================================================================================ Archive-Date: Fri, 25 Jul 1997 15:30:17 -0500 Sender: Date: Fri, 25 Jul 1997 13:30:11 -0700 From: Dan Wing Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <970725133011.2027451b@Cisco.COM> Subject: Re: Mail messages with no line wrap >If I use quoted-printable universally, will all of my e-mail received >via MX look ugly? If so, then I don't think this is a viable >solution for us. Matt only said that MX would encode a message as quoted-printable if any line exceeded 255 characters (or else VMSmail would've truncated the message, with loss). Remember, if MX were to do its own 'wrapping' (to avoid the VMSmail limitation) then the message could not be presented 100% correctly to a MUA (VMSmail or a MIME-aware POP client). By doing a quoted-printable MIME encoding, it will be presented 100% correctly to a MIME-aware mailer, and will be readable, albeit ugly, to VMSmail. Maybe you can make a convincing argument and Matt will make this a switch you can toggle in V5.0. ;-) -d ================================================================================ Archive-Date: Fri, 25 Jul 1997 16:46:08 -0500 Sender: Date: Fri, 25 Jul 1997 17:45:20 EDT From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: BArmstrong@dymaxion.ca, hardis@garnet.nist.gov Message-ID: <009B7CAA.FC032220.15@garnet.nist.gov> Subject: Re: Mail messages with no line wrap > In what way would "quoted printable" help, then? Isn't that the > scheme in which long lines are wrapped and an equals sign is placed > at the end of the line? What determines the wrap width? > > I don't mind if we have to do a bit of re-assembly to read these > broken messages. I do mind, however, if the messages are rendered > totally unreadable by VMS mail. Would that still happen with the > "quoted printable" turned on? If you have a Eudora manual lying about, look at the Appendix, "MIME and Mapping." Yes, "quoted-printable" is a scheme that replaces (a presumed few) scattered oddities in a mail message with reasonable (and temporary) substitutes: 1) If any line is longer than 76 characters, after 75 characters the encoder puts an equal sign at the end of a line-segment, and continues it on the next line. To decode, you can use a text editor to search for "=", and replace it with a null string. 2) If any line ends with a character, the encoder changes it to "=20", so it won't be stripped by those mail systems that do such things. 3) If there is any non-printing ASCII character in the file, it is hexified and preceeded by an equal sign, too. To decode, you can use a text editor to search for "=", and to convert the next two characters from hex to a byte. (This catches the "=20" also, as well as "=3D", the equal sign itself.) So, for most, normal, well-behaved mail bodies, quoted-printable encoding does nothing. For the others, I would either rather run an editor script against them (or use the utility MPack, to decode the MIME format -- not a VAX program) than to lose the message entirely. Eudora, by the way, automatically decodes MIME messages upon receipt (assuming that people get their mail via IUPOP3). - Jonathan ================================================================================ Archive-Date: Fri, 25 Jul 1997 17:04:30 -0500 Sender: Message-ID: <199707252158.AAA21706@masdsa.micronas.com> Date: Sat, 26 Jul 97 01:04:23 EET DST From: "Heikki Kaskelma, Micronas, +358 40 5811205" Reply-To: MX-List@MadGoat.com To: mx-list@madgoat.com CC: kashei@masvxa.dnet Subject: RE: Mail messages with no line wrap When is VMS actually truncating mail lines? I just sent to myself on VAX/VMS 6.1 (no MX) a one-line message, 1024 characters long, and I received it intact, without truncation (and without wrapping). ================================================================================ Archive-Date: Fri, 25 Jul 1997 17:16:37 -0500 Sender: Date: Fri, 25 Jul 1997 17:15:18 CDT From: metze@vmetze.mrl.uiuc.edu Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: metze@vmetze.mrl.uiuc.edu Message-ID: <009B7CA6.C9D6A910.6@vmetze.mrl.uiuc.edu> Subject: RE: Mail messages with no line wrap > > When is VMS actually truncating mail lines? > > I just sent to myself on VAX/VMS 6.1 (no MX) a > one-line message, 1024 characters long, and I > received it intact, without truncation (and without > wrapping). > > How did you do this?????? I get messages which are cut off all of the time. Ginny ================================================================================ Archive-Date: Fri, 25 Jul 1997 18:32:38 -0500 Sender: Message-ID: <199707252305.CAA21799@masdsa.micronas.com> Date: Sat, 26 Jul 97 02:32:31 EET DST From: "Heikki Kaskelma, Micronas, +358 40 5811205" Reply-To: MX-List@MadGoat.com To: mx-list@madgoat.com CC: kashei@masvxa.dnet Subject: RE: Mail messages with no line wrap Maybe I wasn't clear enough. I was all the time within one and same VAX system, and sent a message to myself, using TPU editor, but the same can be done directly from the DCL level if you first create a file with a long line. If I try to route the message via some other VAXen, I get "1024 byte record too large for user's buffer" and no message is sent. If I try to send the same message to smtp%"...", I get "1007396 byte record too large for user's buffer" - a mild exaggeration. So it is not quite clear - not to me at least - where in VAXMail and in what cases the line is really truncated. I can read most incoming one-liners (cannot remember when not) using TPU editor (PF1 KP4 at the mail prompt) and the "fill" command in the editor, so I consider this non-wrapping to be a minor nuisance only and not a problem at all. - Heikki ================================================================================ Archive-Date: Fri, 25 Jul 1997 20:10:14 -0500 Sender: Date: Fri, 25 Jul 1997 19:10:02 MDT From: Mark Tarka Reply-To: MX-List@MadGoat.com To: mx-list@madgoat.com Message-ID: <009B7CB6.D14DE900.3@earth.oscs.montana.edu> Subject: Re: Mail messages with no line wrap Well, sure, long lines are a problem. Anyone who's ever sued another party knows, that the defense goes on and on and on. The disussion has been at the level of the sysadmin and MX development. What about the average Joe-user, with a small account, absolute minimum privs.? I'm fairly certain a TPU script or two would cover mangled-mail (not that I could do it without help), but what about a DCL .com file? The idea would be to run the script (tpu or dcl), detect long lines, and reformat them into a 72 or whatever column product. As it is now, when the text is garbage on my screen, I delete it. Yes, this is all moot, given that MX will adopt sooner or later in response to the problem, but I would like to know if DCL could get into the Mail facility and reformat or otherwise manipulate mail messages. Pointers? Mark ichjsmt@earth.oscs.montana.edu msu-bozeman USA ================================================================================ Archive-Date: Sat, 26 Jul 1997 10:40:30 -0500 Sender: From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: RE: Queue entry numbers keep increasing Date: 25 Jul 97 14:36:54 -0500 Message-ID: <1997Jul25.143654.1@aspen> To: MX-List@WKUVX1.WKU.EDU Here are some vague thoughts. They are based on my very-incomplete understanding of MX (which I realize, more and more, is a piece of art). It generally works very well, but we continue to have strange sporadic troubles. It happened again this morning as I returned from a 3-day vacation. Here are some things we do to try to confine troubles, or at least detect them. Send yourself a mail message, on schedule, from a distant site (not too distant), at 7:30am. For several weeks these used to take 40 seconds; then for several months they would take 2min 40sec. I knew something was wrong immediately when it was an hour late this morn. Every 34 minutes, we execute sys$startup:mx_startup on each node, whether it needs it or not. (You have to remember to disable these, if attempting to shut down MX.) Our troubles at times seem to coincide with network problems within the university. Today the system would not completely respond to SHUTDOWN/CLU; I think it was due to a huge message being attempted (2.5MB). I wonder sometimes how idiot-proof MX is. How about multiple administrators trying to Compress, or interrupting (^Y) bit syncronization and starting it again, etc.? Today part of the solution seemed to require a little .com file like this: i = loop: i = i + 1 mcp que ready 'i if i.gt. then exit goto loop It can be embellished with QUE SHOW's, WAIT 00:00:05, or even decisions based up what SHOW shows. -- Brendan Welch, system analyst, UMass-Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Mon, 28 Jul 1997 08:23:31 -0500 Sender: Date: Mon, 28 Jul 1997 09:22:55 -0400 From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B7EC0.4B2FDC00.29@swdev.si.com> Subject: Re: Mail messages with no line wrap Jonathan E. Hardis (hardis@garnet.nist.gov) writes: >So, for most, normal, well-behaved mail bodies, quoted-printable >encoding does nothing. For the others, I would either rather run >an editor script against them (or use the utility MPack, to decode >the MIME format -- not a VAX program) than to lose the message entirely. MPack is available for VMS. First, pick up the base package from ftp://ftp.uu.net/networking/mail/mpack/mpack-1.5-src.tar.Z. Then, pick up the changes that make it VMS compatible from ftp://seqaxp.bio.caltech.edu/pickup/VMS_MPACK_1_5.TAR. -- Brian Tillman Internet: tillman_brian at si.com Smiths Industries, Inc. tillman at swdev.si.com 4141 Eastern Ave., MS239 Addresses modified to prevent Grand Rapids, MI 49518-8727 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ================================================================================ Archive-Date: Mon, 28 Jul 1997 08:50:22 -0500 Sender: Date: Mon, 28 Jul 1997 08:50:16 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B7EBB.BBD20F47.48@ALPHA.WKU.EDU> Subject: The definitive answer RE: MX and long lines and VMS Mail My, you guys were busy over the weekend! To clear up some confusion, VMS Mail *used* to truncate lines at 255 characters. However, sometime along the line, VMS Mail was modified to allow much longer lines. I didn't notice that, though, and so MX continued to truncate lines at 255 characters before handing them off to VMS Mail. The MX_LOCAL.EXE on ftp.madgoat.com in [.MX.MX042.PATCH] fixed this problem several months ago. It no longer truncates lines, it just hands them off to VMS Mail. (Just one of many reasons you should all be running MX V4.2 with the new images in the [.PATCH] directory!!) Note that VMS Mail has a lot of oddities about displaying messages with long lines. Some versions will, some versions won't. Some will display them, some will only EXTRACT them properly. There are a bunch of variables here, but suffice it to say that, with the MX_LOCAL mentioned above, MX does no message length truncation. RE: quoted-printable, MX has, for years, decoded quoted-printable messages automatically before handing them off to VMS Mail for incoming messages. With MX V5.0, QP will be done on out-going messages too. If you're sending from one MX system to another (or to a PMDF system, I think), your message will get decoded before it's delivered to you. It is true that MX doesn't encode messages that come in but are not targetted for local delivery. MX is a transport and should not really (IMO) be doing those sorts of things to messages that are just passing through. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Mon, 28 Jul 1997 11:40:35 -0500 Sender: Date: Mon, 28 Jul 1997 17:39:39 BST From: Andy Harper Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: A.HARPER@kcl.ac.uk Message-ID: <009B7F05.AFFA745C.220@alder.cc.kcl.ac.uk> Subject: RE: The definitive answer RE: MX and long lines and VMS Mail >To clear up some confusion, VMS Mail *used* to truncate lines at 255 >characters. However, sometime along the line, VMS Mail was modified >to allow much longer lines. I didn't notice that, though, and so MX >continued to truncate lines at 255 characters before handing them off >to VMS Mail. The MX_LOCAL.EXE on ftp.madgoat.com in [.MX.MX042.PATCH] >fixed this problem several months ago. It no longer truncates >lines, it just hands them off to VMS Mail. > >(Just one of many reasons you should all be running MX V4.2 with the >new images in the [.PATCH] directory!!) If it's true that VMS MAIL no longer truncates long liness, how is that (a) the documentation on callable mail still specifies a limit of 256 bytes and (b) if you try to use callable mail (on OpenVMS 6.2 at least) to retrieve a message with a buffer size bigger than 256, the callable mail routine returns an error status (basically telling you that the buffer's bigger than the maximum size). I'ld REALLY like to kbow how to get these long lines so that I can update some local applications appropriately. Regards, Andy Harper Kings College London ================================================================================ Archive-Date: Mon, 28 Jul 1997 13:19:48 -0500 Sender: Date: Mon, 28 Jul 1997 13:19:39 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B7EE1.5DE56098.6@ALPHA.WKU.EDU> Subject: RE: The definitive answer RE: MX and long lines and VMS Mail Andy Harper writes: > > If it's true that VMS MAIL no longer truncates long liness, how is that (a) > the documentation on callable mail still specifies a limit of 256 bytes and I didn't say callable MAIL didn't truncate! 8-) Callable MAIL *does* reject records longer than 255 if you use MAIL$_SEND_RECORD with MAIL$SEND_ADD_BODYPART. Specify a length longer than 255 and it'll signal "Invalid item size." HOWEVER, when you mail a file using MAIL$_SEND_FILENAME, the records are *not* truncated--they are, in fact, copied as is, apparently regardless of whether the message is stored inside MAIL.MAI or in an external MAIL$xxxxxx.MAI file. On reading messages, the length specified is *not* verified, so you *can* read longer records. The callable mail routines use 2*NAM$C_MAXRSS, which is 510, so you get that amount back when you do a READ/EDIT on a message. Try reading a message with a line longer than some 2048 and you'll get the "Record too big" error: 2049 byte record too large for MAIL buffer However, the message is intact in the external MAIL$xxx.MAI file created for it. You just can't get it via callable MAIL (well, that's not really true either). > (b) if you try to use callable mail (on OpenVMS 6.2 at least) to retrieve a > message with a buffer size bigger than 256, the callable mail routine > returns an error status (basically telling you that the buffer's bigger than > the maximum size). > VMS Mail versions do different things with messages with long lines. On VMS V5.5-2, I sent a file containing one 2048 character line using MAIL$_SEND_FILENAME. MAIL wouldn't display the message text, but EXTRACT did extract the whole message---all 2048 characters. Which is still different behavior from what I saw on Alpha V7.0, where it was truncated to 510 characters on the EXTRACT. Apparently someone made that code more consistent in VMS V7.x. > I'ld REALLY like to kbow how to get these long lines so that I can update > some local applications appropriately. > The key is to use the undocumented callable MAIL item code MAIL$_MESSAGE_BUFFER. When MAIL (callable MAIL) reads a message, it reads the entire message into memory as a linked list. If you specify MAIL$_MESSAGE_BUFFER, callable MAIl returns a pointer to the block of memory that contains the entire message text. This block looks like this: +----------------------------------------+ | Address of next text block or 0 | +----------------------------------------+ | Length of this text block | +----------------------------------------+ | Total allocated bytes for this block | +----------------------------------------+ | Each line of message text, preceded | | by a word containing the number of | | bytes in that record. | +----------------------------------------+ This block contains all lines, even those exceeding 2048 characters. By stepping through this text block to get the records, instead of calling MAIL$MESSAGE_GET for each record, you can retrieve all the records, regardless of size. There is one exception: if the first line is longer than 510 or 2048, depending on the version of VMS, there's absolutely no way to have callable MAIL return that record. For Internet mail, this isn't a problem, because the first line is a From: line or Received: or whatever. If a message is sent via regular MAIL and the first line is longer than that callable MAIL max, callable MAIL returns a message to the user telling him that the message contains a record too long to be retrieved. This concludes today's lesson on callable MAIL internals. 8-) Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Mon, 28 Jul 1997 14:36:18 -0500 Sender: Date: Mon, 28 Jul 1997 15:36:02 EDT From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: hardis@garnet.nist.gov Message-ID: <009B7EF4.6B4ED480.17@garnet.nist.gov> Subject: RE: The definitive answer RE: MX and long lines and VMS Mail > To clear up some confusion, VMS Mail *used* to truncate lines at 255 > characters. However, sometime along the line, VMS Mail was modified > to allow much longer lines. Ouch. That doesn't help me much, though, because this microVAX is going to remain at VMS 5.3-1 until the day it dies. (I suspect lot of other people are in a similar situation.) Could 255 character truncation be made a configuration option? > It is true that MX doesn't encode messages that come in but are not > targetted for local delivery. MX is a transport and should not really > (IMO) be doing those sorts of things to messages that are just passing > through. What about messages that come in that *are* targeted for local delivery? This is where the pain is. Thanks for your consideration, Jonathan ================================================================================ Archive-Date: Mon, 28 Jul 1997 14:47:30 -0500 Sender: Date: Mon, 28 Jul 1997 14:47:22 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B7EED.9E81564B.21@ALPHA.WKU.EDU> Subject: RE: The definitive answer RE: MX and long lines and VMS Mail "Jonathan E. Hardis" writes: > >> To clear up some confusion, VMS Mail *used* to truncate lines at 255 >> characters. However, sometime along the line, VMS Mail was modified >> to allow much longer lines. > >Ouch. That doesn't help me much, though, because this microVAX is going to >remain at VMS 5.3-1 until the day it dies. (I suspect lot of other people >are in a similar situation.) > >Could 255 character truncation be made a configuration option? > It's no longer an issue, as far as MX goes. It doesn't do the truncation, but VMS Mail might. I can see how auto-wrapping by MX Local would be desirable, but I haven't thought much about how best to do that. >> It is true that MX doesn't encode messages that come in but are not >> targetted for local delivery. MX is a transport and should not really >> (IMO) be doing those sorts of things to messages that are just passing >> through. > >What about messages that come in that *are* targeted for local delivery? >This is where the pain is. > Plain quoted-printable messages coming in for local delivery *are* automatically decoded by MX, alhtough those were restricted to "text/plain" messages in MX V4.2. MX V5.0 will decode all "text*" messages, though multi-part MIME messages are still not handled. And before anyone else can bring it up again, MIME is something that should be done by the USER AGENT, and since MX uses VMS Mail as its user agent, there's not much we can do about adding additional MIME support to MX. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Mon, 28 Jul 1997 22:00:34 -0500 Sender: Date: Mon, 28 Jul 1997 23:00:22 EDT From: Brian Reed Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B7F32.7D84435E.3@cbict3.cb.lucent.com> Subject: RE: The definitive answer RE: MX and long lines and VMS Mail Hunter said: >It's no longer an issue, as far as MX goes. It doesn't do the >truncation, but VMS Mail might. > >>What about messages that come in that *are* targeted for local delivery? >>This is where the pain is. >> >Plain quoted-printable messages coming in for local delivery *are* >automatically decoded by MX, alhtough those were restricted to >"text/plain" messages in MX V4.2. MX V5.0 will decode all "text*" >messages, though multi-part MIME messages are still not handled. I just got a message, where the lines (in the file) were several hundred characters long. DECWindows mail chopped off the messages while reading them. The header says: X-MX-Comment: QUOTED-PRINTABLE message automatically decoded I'm confused by this. This seems to say that the message got decoded, which I take to mean broken up into small (80 character) lines. But, the message wasn't. So my question is just what does the above message mean, and what triggers it? Thanks, Brian D. Reed Lucent Technologies Columbus Works bdreed1@lucent.com 614-860-6218 ================================================================================ Archive-Date: Tue, 29 Jul 1997 09:03:59 -0500 Sender: Date: Tue, 29 Jul 1997 09:03:52 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B7F86.CCB3B0B0.29@ALPHA.WKU.EDU> Subject: RE: The definitive answer RE: MX and long lines and VMS Mail Brian Reed writes: > >>Plain quoted-printable messages coming in for local delivery *are* >>automatically decoded by MX, alhtough those were restricted to >>"text/plain" messages in MX V4.2. MX V5.0 will decode all "text*" >>messages, though multi-part MIME messages are still not handled. > >I just got a message, where the lines (in the file) were >several hundred characters long. DECWindows mail chopped >off the messages while reading them. The header says: > >X-MX-Comment: QUOTED-PRINTABLE message automatically decoded > >I'm confused by this. This seems to say that the message got >decoded, which I take to mean broken up into small (80 character) >lines. But, the message wasn't. So my question is just what >does the above message mean, and what triggers it? > No, it was decoded from quoted-printable (where 8-bit characters are replaced with sequences like "=9f" and lines are broken up into smaller lines) back to an unencoded state, which means the message may now include 8-bit characters and may have long lines. The decoding returns it to its original state as the user sent it. Your problem is that you're using DECwindows MAIL, which truncates message lines when it displays them. If you were to use normal VMS Mail, you'd see those longer lines. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Tue, 29 Jul 1997 09:35:01 -0500 Sender: Date: Tue, 29 Jul 1997 10:38:00 EDT From: "G. Del Merritt" Reply-To: MX-List@MadGoat.com To: bdreed1@lucent.com CC: MX-List@madgoat.com Message-ID: <009B7F93.F30D68AA.5@intranet.com> Subject: RE: The definitive answer RE: MX and long lines and VMS Mail In-reply-to: "bdreed1@lucent.com"'s message of 28-JUL-1997 23:12:27.54 >I just got a message, where the lines (in the file) were >several hundred characters long. DECWindows mail chopped >off the messages while reading them. The header says: > >X-MX-Comment: QUOTED-PRINTABLE message automatically decoded > >I'm confused by this. This seems to say that the message got >decoded, which I take to mean broken up into small (80 character) >lines. But, the message wasn't. So my question is just what >does the above message mean, and what triggers it? From my experience, if MX (4.1ish forward) decides the message is QP, it will "decode" it into what the sender initially sent, e.g., "lines" that are very "long". This may break VMSMAIL. The decoding doesn't break up the message; to the contrary, it "unbreaks it up". The QP encoding/decoding is homologous to uuencode/uudecode. Hope that helps some. -- Del Merritt del@IntraNet.com IntraNet, Inc., One Gateway Center #700, Newton, MA 02158 Voice: 617-527-7020; FAX: 617-527-1761 filter suggestion: deny agis.net You may not add me to a commercial mailing list or send me commercial advertising without my consent. NERD PRIDE is a registered trademark of the MIT ================================================================================ Archive-Date: Tue, 29 Jul 1997 22:19:34 -0500 Sender: From: goathunter@madgoat.com (Hunter Goatley) Subject: Re: Multiple From addresses and REPLY (VMS 7.x) Date: 29 Jul 1997 22:00:13 GMT Message-ID: <5rlp5d$5hi$1@news.wku.edu> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <5rl1u8$qjg@newton.cc.rl.ac.uk>, "Richard Brodie" writes: >Dejanews and I vaguely remember a discussion some time back about a problem >with multiple From addresses and MX (or more precisely VMS MAIL) when running >7.0 or 7.1. > > >I can see the problem on a test machine: REPLY generates an address that >doesn't parse. >Was there a happy resolution somewhere along the line? > Digital insists this isn't their bug, but it is.... The only happy resolution is to omit the MX% prefix on incoming mail, which you'll be able to do in MX V5.0, as soon as it's released. Hunter ------ Hunter Goatley, Process Software, http://www.process.com/ TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Tue, 29 Jul 1997 22:41:59 -0500 Sender: Date: Tue, 29 Jul 1997 21:41:47 MDT From: Mark Tarka Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B7FF0.ADB1307C.9@earth.oscs.montana.edu> Subject: Re: Multiple From addresses and REPLY (VMS 7.x) Uh...question from a dummy user...what do you think? In article <5rlp5d$5hi$1@news.wku.edu>, goathunter@madgoat.com (Hunter Goatley) writes: [NB Quote symbol is "|" for the current message.] | In article <5rl1u8$qjg@newton.cc.rl.ac.uk>, "Richard Brodie" |writes: |>Dejanews and I vaguely remember a discussion some time back about a problem |>with multiple From addresses and MX (or more precisely VMS MAIL) when running |>7.0 or 7.1. |> |> |>I can see the problem on a test machine: REPLY generates an address that |>doesn't parse. |>Was there a happy resolution somewhere along the line? |> |Digital insists this isn't their bug, but it is.... | |The only happy resolution is to omit the MX% prefix on incoming mail, |which you'll be able to do in MX V5.0, as soon as it's released. Um...is this a situation where the DEC has dumped upon the customer (2nd) and the third (?) party vendor(s)? Mark (A "newbie" user...who jus' wants to know...for sure :-) ================================================================================ Archive-Date: Wed, 30 Jul 1997 06:49:58 -0500 Sender: Date: Wed, 30 Jul 1997 12:48:58 BST From: Andy Harper Reply-To: MX-List@MadGoat.com To: MX-LIST@MADGOAT.COM CC: A.HARPER@kcl.ac.uk Message-ID: <009B806F.69630D04.263@alder.cc.kcl.ac.uk> Subject: long lines; queue corruption Hunter, Thanks for your in-depth look at callable mail internals. I should now have enough to update the local applications. On a different topic entirely - Recently, someone mentioned apparent queue corruption in MX. To add my two cents worth: I notice that it can get 'corrupted' under certain conditions. Those that I've identified are: * If MX is not properly shut down (all processes stopped tidily) before the system goes down, then the queue can become corrupted. For instance, following a crash of a node. * Two users simultaneously using MCP to manipulate the queue * (this one is a guess..) Running MX on a node in the cluster that doesn't have a cluster alias defined. I guess this because I've had trouble with this in ther past and noted that one of the locknames used by MX contained the cluster alias, leading me to think it might not be properly acquiring/releasing locks. * Killing a stuck process with STOP/ID=nnnn Observed symptoms of corrupt queues are: * Entries in queues that stick and need a QUEUE READY to release them. * Gradual increase in the number of entries shown by QUEU STAT which do not show up on a QUEU SHOW/ALL * Files in [MX.QUEUE.x] which do not have a corresponding queue entry. * MX processes that will not respond to SHUTDOWN even though they are IDLE Needs a STOP/ID to get rid of it. * QUEUE SYNC/RESET can cause QUEU STAT and QUEU SHOW to think there are no entries, even though they existed before the QUEUE SYNC and the existing MX processes continue to process entries in the queue that no longer show up !!! Additional entries to the queue can cause QUEU STAT and QUEU SHOW to start seeing entries up to the highest new entry number created. It would appear that MX does not do much consistency checking on the queue (a new command to display inconsitencies would be nice) and is ill-prepared to deal with some unexpected conditions, such as forced removal of an MX process in the middle of manipulating a queue entry. Regards, Andy Harper Kings College London ================================================================================ Archive-Date: Wed, 30 Jul 1997 09:08:19 -0500 Sender: Date: Wed, 30 Jul 1997 10:05:44 -0400 From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B8058.9B7A1BA0.5@swdev.si.com> Subject: Re: Multiple From addresses and REPLY (VMS 7.x) Hunter writes: >The only happy resolution is to omit the MX% prefix on incoming mail, >which you'll be able to do in MX V5.0, as soon as it's released. I don't see anything inthe F5.0 docs that indicates how this should be done. In fact, paragraph 5.1 in the Management Guide still says: "Note that incoming mail from MX will always bear the MX% prefix." -- Brian Tillman Internet: tillman_brian at si.com Smiths Industries, Inc. tillman at swdev.si.com 4141 Eastern Ave., MS239 Addresses modified to prevent Grand Rapids, MI 49518-8727 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ================================================================================ Archive-Date: Wed, 30 Jul 1997 09:14:24 -0500 Sender: Date: Wed, 30 Jul 1997 10:13:34 -0400 From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B8059.B3B6D4A0.11@swdev.si.com> Subject: Re: Multiple From addresses and REPLY (VMS 7.x) Oohh! BIG ECO for VMS Mail on OpenVMS VAX V6.2 just appeared in DSNlink. Here are the problems addressed: o In the event of an error opening or reading SYSUAF.DAT, and a subsequent continuation or unwind request, the protected image's condition handler must place the condition value in the mechanism array. If this does not occur, SIGNAL returns an undefined value, the error does not get passed back to the user mode code, and MAIL attempts to continue. o One of the privileged code condition handlers expects the address of the privileged context block in the enable vector when it is invoked. It then attempts to store the signal arguments at an offset within that context block. However, under certain circumstances, the address of the privileged context is zero when a UAF record locked condition is being handled. The ACCVIO occurs because the offset for the signal arguments within the context block is invalid. o When calling MAIL$MAILFILE_PURGE_WASTE from a detached process, the image was aborting with a LIB$_NOCLI message. o Programs using callable MAIL routines from AST level code will often receive ACCVIOs when RMS errors are signaled. o Strange characters are displayed in DIR command when a user has no mail messages and no folders. o A program using callable mail routine MAIL$USER_GET_INFO will receive an EXEC mode access violation and the process is deleted. A non-fatal SSRVEXCEPTN bugcheck is generated. o A program using callable mail routine MAIL$USER_GET_INFO will receive an EXEC mode access violation and the process is deleted when the MAIL$_USER_NEXT item code is used before MAIL$_USER_FIRST or MAIL$_USER_USERNAME. A non-fatal SSRVEXCEPTN bugcheck is generated. o Two SSRVEXCEPTION crashes in MAILSHRP when running LBN disk I/O or UETP, in the context of the image DTWM. o When using callable mail to send messages, it will eventually run out of virtual memory. There is a memory leak in both MAIL$SEND_BEGIN and MAIL$SEND_END routines. o Defining a Logical for Username in the following manner produces Forward Loop in MAIL. $DEFINE/TRANSLATION_ATTRIB=TERMINAL name node::name eg. $ define/tran=terminal system quebit::system MAIL> send To: system %MAIL-E-FORWLOOP, infinite forwarding detected sending to user netaly o The TO line in a received message can become so skewed that passwords for remote distribution lists may be visible in a received message. o When sending mail to a REMOTE and LOCAL user of the same name, and the send to the REMOTE recipient-name fails, the mail message is NOT sent to the LOCAL recipient-name either. However, other recipient names listed receive the mail. o When a mail message is sent and the TO: field incorporates a set of quotes, and the TO: field/addressee is incorrect, there is no error message returned. o A VAX C application that uses the MAIL$ callable API runs for varied lengths of time, then crashes due to insufficient virtual memory. o When using MAIL$MESSAGE_COPY to copy messages from one mail file to another version of the same file, the messages are not copied to the target file, but rather are copied to the source file. o Depending on DECnet Plus namespace configuration, appearance of MAIL> prompt can be very slow. -- Brian Tillman Internet: tillman_brian at si.com Smiths Industries, Inc. tillman at swdev.si.com 4141 Eastern Ave., MS239 Addresses modified to prevent Grand Rapids, MI 49518-8727 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ================================================================================ Archive-Date: Wed, 30 Jul 1997 09:31:27 -0500 Sender: Date: Wed, 30 Jul 1997 15:30:52 BST From: Andy Harper Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: A.HARPER@kcl.ac.uk Message-ID: <009B8086.078433B7.263@alder.cc.kcl.ac.uk> Subject: RE: The definitive answer RE: MX and long lines and VMS Mail >> I'ld REALLY like to kbow how to get these long lines so that I can update >> some local applications appropriately. >> >The key is to use the undocumented callable MAIL item code >MAIL$_MESSAGE_BUFFER. When MAIL (callable MAIL) reads a message, it >reads the entire message into memory as a linked list. > >If you specify MAIL$_MESSAGE_BUFFER, callable MAIl returns a pointer >to the block of memory that contains the entire message text. This >block looks like this: Hunter, Could you give an example of a mail$message_get call with this item code? When I try it, I end up with zero returned as the buffer pointer! Here's my test routine: char *__get_message_ptr(int *msgcontext, int msgnum) { int status; char *ptr = NULL; item MessageInfoList[] = { { sizeof(msgnum), MAIL$_MESSAGE_ID, &msgnum, 0}, { 0, 0, NULL, NULL}}; item MessageDataList[] = { { sizeof(ptr), MAIL$_MESSAGE_BUFFER, &ptr, 0}, { 0, 0, NULL, NULL}}; printf("Looking for message number %d\n", msgnum); status = mail$message_get(msgcontext, MessageInfoList, MessageDataList); printf("GET Status: %08x\n", status); printf("PTR: %08x\n", ptr); return ptr; } Regards, Andy Harper Kings College London ================================================================================ Archive-Date: Wed, 30 Jul 1997 09:42:38 -0500 Sender: Date: Wed, 30 Jul 1997 07:42:09 -0700 From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009B8044.8CAFB152.15@sacto.mp.usbr.gov> Subject: Re: Multiple From addresses and REPLY (VMS 7.x) > From: MX%"MX-List@MadGoat.com" 30-JUL-1997 07:19:21.08 > Subj: Re: Multiple From addresses and REPLY (VMS 7.x) Brian, > Hunter writes: > > >The only happy resolution is to omit the MX% prefix on incoming mail, > >which you'll be able to do in MX V5.0, as soon as it's released. > > I don't see anything inthe F5.0 docs that indicates how this should be done. In > fact, paragraph 5.1 in the Management Guide still says: "Note that incoming mail > from MX will always bear the MX% prefix." Remember, these ARE the PRELIMINARY docs. Hopefully the finished product will have all of the good poop in it. > -- > Brian Tillman Internet: tillman_brian at si.com > Smiths Industries, Inc. tillman at swdev.si.com > 4141 Eastern Ave., MS239 Addresses modified to prevent > Grand Rapids, MI 49518-8727 SPAM. Replace "at" with "@" > This opinion doesn't represent that of my company BTW, Thank you VERY MUCH for forwarding the 6.2 MAIL ECO article to the list. Most enlightening. -HWM ================================================================================ Archive-Date: Wed, 30 Jul 1997 09:51:57 -0500 Sender: Date: Wed, 30 Jul 1997 09:51:49 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B8056.AA0671BC.83@ALPHA.WKU.EDU> Subject: Re: Multiple From addresses and REPLY (VMS 7.x) "Henry W. Miller" writes: > >> I don't see anything inthe F5.0 docs that indicates how this should be done. In >> fact, paragraph 5.1 in the Management Guide still says: "Note that incoming mail >> from MX will always bear the MX% prefix." > > Remember, these ARE the PRELIMINARY docs. Hopefully the >finished product will have all of the good poop in it. > Actually, they were supposed to be the final docs. We just forgot this. ;-) If you see anything else, please let me know via private e-mail. To omit the MX% prefix on incoming mail, simply define MX_PROTOCOL_PREFIX as a blank: $ define/system/exec mx_protocol_prefix " " Given the way the code works, it couldn't be defined as "", but has to be defined as " ". I'll make sure this makes it into the manual. Thanks. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Wed, 30 Jul 1997 09:55:01 -0500 Sender: Date: Wed, 30 Jul 1997 10:54:14 -0400 From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B805F.61EB2300.41@swdev.si.com> Subject: Re: Multiple From addresses and REPLY (VMS 7.x) > Remember, these ARE the PRELIMINARY docs. Hopefully the >finished product will have all of the good poop in it. Shouldn't we beta testers get "the good poop" first so we can proofread it? -- Brian Tillman Internet: tillman_brian at si.com Smiths Industries, Inc. tillman at swdev.si.com 4141 Eastern Ave., MS239 Addresses modified to prevent Grand Rapids, MI 49518-8727 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ================================================================================ Archive-Date: Wed, 30 Jul 1997 10:01:54 -0500 Sender: Date: Wed, 30 Jul 1997 10:01:32 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B8058.052CCD6F.60@ALPHA.WKU.EDU> Subject: RE: long lines; queue corruption Andy Harper writes: > >Hunter, > >Thanks for your in-depth look at callable mail internals. I should now have >enough to update the local applications. > As per your other message, I'll post an example later today. >On a different topic entirely - Recently, someone mentioned apparent queue >corruption in MX. To add my two cents worth: > >I notice that it can get 'corrupted' under certain conditions. Those that I've >identified are: > * If MX is not properly shut down (all processes stopped tidily) before the > system goes down, then the queue can become corrupted. For instance, > following a crash of a node. > Yes, it's possible. > * Two users simultaneously using MCP to manipulate the queue > That shouldn't cause any real problems, but there are conditions where it could. MCP queue manipulation is something that should be used sparingly, mostly because MCP will let you do things like READY an entry that's already IN-PROGRESS. Usually this won't hurt anything, but.... > * (this one is a guess..) Running MX on a node in the cluster that doesn't > have a cluster alias defined. I guess this because I've had trouble with > this in ther past and noted that one of the locknames used by MX contained > the cluster alias, leading me to think it might not be properly > acquiring/releasing locks. > That would certainly cause big problems for the reason you gave. > * Killing a stuck process with STOP/ID=nnnn > If it's really stuck, this shouldn't hurt anything, though it will leave an entry marked as IN-PROGRESS. >Observed symptoms of corrupt queues are: Note that I wouldn't call all of these "queue corruption". When I think of queue corruption, I think of a queue that has be re-initialized to fix problems (which, unfortunately, Brendan has seen several times). > * Entries in queues that stick and need a QUEUE READY to release them. > MX V5.0 has some new code to prevent that from happening any more (at least, I haven't seen it in months). > * Gradual increase in the number of entries shown by QUEU STAT which do not > show up on a QUEU SHOW/ALL > This I haven't seen, except in cases of real queue corruption. > * Files in [MX.QUEUE.x] which do not have a corresponding queue entry. > Not sure how these get left behind.... > * MX processes that will not respond to SHUTDOWN even though they are IDLE > Needs a STOP/ID to get rid of it. > There were a couple of bugs I fixed for MX V5.0 that should take care of this. > * QUEUE SYNC/RESET can cause QUEU STAT and QUEU SHOW to think there are > no entries, even though they existed before the QUEUE SYNC and the existing > MX processes continue to process entries in the queue that no longer show > up !!! Additional entries to the queue can cause QUEU STAT and QUEU SHOW > to start seeing entries up to the highest new entry number created. > Hmmmm. I haven't seen this, but, again, QUEUE SYNC/RESET should be used sparingly, and ideally with all MX processes shutdown. It does take out a lock while doing the queue, but it'd still be best to shutdown the processes before you do it. >It would appear that MX does not do much consistency checking on the queue (a >new command to display inconsitencies would be nice) It sure would. If you can figure out how to do that, I'd be glad to add it. ;-) Seriously, I've thought about some ways to better handle that kind of stuff, but haven't come up with anything particularly useful yet. >and is ill-prepared to >deal with some unexpected conditions, such as forced removal of an MX process >in the middle of manipulating a queue entry. > That particular case *should* only possibly cause a queue entry to be left marked as IN-PROGRESS. It shouldn't cause other problems, but there is a small window that could cause actual queue corruption. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Wed, 30 Jul 1997 10:28:51 -0500 Sender: Date: Wed, 30 Jul 1997 11:28:21 -0400 From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B8064.25E37420.2@swdev.si.com> Subject: Re: Multiple From addresses and REPLY (VMS 7.x) >To omit the MX% prefix on incoming mail, simply define >MX_PROTOCOL_PREFIX as a blank: > > $ define/system/exec mx_protocol_prefix " " How do I specify this in MX_LOGICALS.DAT? I'm unsure of how to make the value of the logical a blank in this file. -- Brian Tillman Internet: tillman_brian at si.com Smiths Industries, Inc. tillman at swdev.si.com 4141 Eastern Ave., MS239 Addresses modified to prevent Grand Rapids, MI 49518-8727 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ================================================================================ Archive-Date: Wed, 30 Jul 1997 10:34:23 -0500 Sender: Date: Wed, 30 Jul 1997 11:31:19 -0400 From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B8064.90656240.13@swdev.si.com> Subject: RE: long lines; queue corruption >> * Entries in queues that stick and need a QUEUE READY to release them. >> >MX V5.0 has some new code to prevent that from happening any more (at >least, I haven't seen it in months). Well, here I am running F5.0 and I see: Entry# Status Size Source Agent Entry# Status Size ------ ------ ------- ------ ------- ------ ------ ------- 1 INPROG 2368 MAIL SMTP 19 INPROG 2368 This message has been in this state for two full days. -- Brian Tillman Internet: tillman_brian at si.com Smiths Industries, Inc. tillman at swdev.si.com 4141 Eastern Ave., MS239 Addresses modified to prevent Grand Rapids, MI 49518-8727 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ================================================================================ Archive-Date: Wed, 30 Jul 1997 10:40:07 -0500 Sender: Date: Wed, 30 Jul 1997 10:39:56 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B805D.62AF6A79.61@ALPHA.WKU.EDU> Subject: Re: Multiple From addresses and REPLY (VMS 7.x) "Brian Tillman, x8425" writes: > >>To omit the MX% prefix on incoming mail, simply define >>MX_PROTOCOL_PREFIX as a blank: >> >> $ define/system/exec mx_protocol_prefix " " > >How do I specify this in MX_LOGICALS.DAT? I'm unsure of how to make the value >of the logical a blank in this file. You don't. You should never edit MX_LOGICALS.DAT by hand (or at least, you shouldn't add logicals) because it's replaced by new MX installations. As with other products, you should define any additional MX logicals in your system startup procedure. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Wed, 30 Jul 1997 10:42:43 -0500 Sender: Date: Wed, 30 Jul 1997 10:42:29 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B805D.BDE56DEE.100@ALPHA.WKU.EDU> Subject: RE: long lines; queue corruption "Brian Tillman, x8425" writes: > >>> * Entries in queues that stick and need a QUEUE READY to release them. >>> >>MX V5.0 has some new code to prevent that from happening any more (at >>least, I haven't seen it in months). > >Well, here I am running F5.0 and I see: > >Entry# Status Size Source Agent Entry# Status Size >------ ------ ------- ------ ------- ------ ------ ------- > 1 INPROG 2368 MAIL > SMTP 19 INPROG 2368 > >This message has been in this state for two full days. Is there an SMTP agent that says it's working on that entry? My guess is that your SMTP agent died for some reason (don't know why, as I haven't seen that happen in more than a month at WKU with F5.0) and left it INPROG. That entry will remain that way until a reboot occurs. There's special logic in MX FLQ Manager (and MX Router, if you don't run the FLQ Manager) to detect these and READY them again. If there's no process, check your MX_SMTP_node.LOG files and see why that agent bombed. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Wed, 30 Jul 1997 10:44:24 -0500 Sender: Date: Wed, 30 Jul 1997 10:44:00 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B805D.F3F38DF8.113@ALPHA.WKU.EDU> Subject: One solved Robert McClanahan reminded me about this one: > >> > * Files in [MX.QUEUE.x] which do not have a corresponding queue entry. >> > >> Not sure how these get left behind.... > I was wrong. I do know how those are left behind. There was a bug in the FLQ_PURGE routine that I fixed many moons ago for the never-released MX V4.3. You'll get this fix in MX V5.0. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Wed, 30 Jul 1997 10:50:09 -0500 Sender: Date: Wed, 30 Jul 1997 10:49:54 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B805E.C71078E5.122@ALPHA.WKU.EDU> Subject: RE: long lines; queue corruption Hunter Goatley writes: > >Is there an SMTP agent that says it's working on that entry? My guess >is that your SMTP agent died for some reason (don't know why, as I >haven't seen that happen in more than a month at WKU with F5.0) and >left it INPROG. That entry will remain that way until a reboot >occurs. There's special logic in MX FLQ Manager (and MX Router, if >you don't run the FLQ Manager) to detect these and READY them again. > BTW, it makes perfect sense as to how these happen. The entry is marked IN-PROGRESS, the agent tries delivery, and something causes the agent to die. The entry is left IN-PROGRESS because the agent never changes its state before it dies. MX V5.0 includes lots of changes to eliminate access violations in the agents and, until Brian's post, I hadn't heard of any agent dying in MX F5.0. WKU's agents have been running for a month now. Before F5.0, it was not uncommon for a few SMTP agents to accvio every week. Many of these problems were caused by memory leaks, which I've plugged for MX V5.0. Also, Brian, do a DIR of MX_EXE: and make sure your .EXEs all date from the same time. I, too, had an MX SMTP agent crash the other day, but it was because the MX_SMTP.EXE wasn't updated when I did my last MX installation. I apparently forgot to ensure that the SMTP module was updated during the last install. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Wed, 30 Jul 1997 11:10:53 -0500 Sender: Date: Wed, 30 Jul 1997 12:10:29 -0400 From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B806A.08DC5DA0.15@swdev.si.com> Subject: RE: long lines; queue corruption >Is there an SMTP agent that says it's working on that entry? Yes, there is. >That entry will remain that way until a reboot occurs. Um, a reboot? Not just a shutdown/restart of MX? I did just that (i.e., SHUTDOWN/CLUSTER, QUEUE COMPRESS, QUEUE RESYNCH, then a restart) and the job is now: Entry: 1, Origin: [Local] Status: IN-PROGRESS, size: 2368 bytes Created: 28-JUL-1997 07:36:11.71, expires 27-AUG-1997 07:36:11.71 Last modified 30-JUL-1997 11:59:29.54 SMTP entry #6, status: READY, size: 2368 bytes, waiting for retry until 30-JUL -1997 12:13:50.09 Created: 30-JUL-1997 11:59:28.90, expires 27-AUG-1997 07:36:11.71 Last modified 30-JUL-1997 12:03:50.10 Recipient #1: , Route=esseye.si. com Error count=1 Last error: %SYSTEM-F-TIMEOUT, device timeout Yet, I can TELNET to port 25 of the target and, manually, enter all of the commands necessary to send mail. I guess it's time for the DEBUG logical. -- Brian Tillman Internet: tillman_brian at si.com Smiths Industries, Inc. tillman at swdev.si.com 4141 Eastern Ave., MS239 Addresses modified to prevent Grand Rapids, MI 49518-8727 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ================================================================================ Archive-Date: Wed, 30 Jul 1997 11:18:53 -0500 Sender: Date: Wed, 30 Jul 1997 12:14:57 -0400 From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B806A.A893D120.19@swdev.si.com> Subject: RE: long lines; queue corruption >Also, Brian, do a DIR of MX_EXE: and make sure your .EXEs all date >from the same time. The only file not dated 30-JUN-1997 22:22:xx.xx is MX_SITE.COM. -- Brian Tillman Internet: tillman_brian at si.com Smiths Industries, Inc. tillman at swdev.si.com 4141 Eastern Ave., MS239 Addresses modified to prevent Grand Rapids, MI 49518-8727 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ================================================================================ Archive-Date: Wed, 30 Jul 1997 11:28:05 -0500 Sender: Date: Wed, 30 Jul 1997 11:27:57 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B8064.179D8421.49@ALPHA.WKU.EDU> Subject: RE: long lines; queue corruption "Brian Tillman, x8425" writes: > >>Is there an SMTP agent that says it's working on that entry? > >Yes, there is. > So my comment stands: I believe I've fixed the access violations. Why that process is hung and didn't timeout, I don't know. Sounds like a TCP/IP problem of some kind. >>That entry will remain that way until a reboot occurs. > >Um, a reboot? Not just a shutdown/restart of MX? > You're right. I had forgotten exactly how I coded that. Here's the comment on that logic: ! An entry should be READYed or CANCELled if: ! ! o the stored PID no longer matches a process ! o the stored PID does match an existing process, ! but the MODDT was before the last system boot. ! ! The entry is CANCELled if one of the above is true ! and the size is 0. These are usually caused by ! VMS Mail users getting bumped off, etc. So shutting down and restarting MX will usually catch the entries. >I did just that (i.e., SHUTDOWN/CLUSTER, QUEUE COMPRESS, QUEUE RESYNCH, then a >restart) and the job is now: [...] > Last error: %SYSTEM-F-TIMEOUT, device timeout > >Yet, I can TELNET to port 25 of the target and, manually, enter all of the >commands necessary to send mail. I guess it's time for the DEBUG logical. Yep. Again, it sounds like a weird TCP/IP issue that prevented the process from timing out properly. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Wed, 30 Jul 1997 11:40:23 -0500 Sender: From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: RE: long lines; queue corruption Date: 30 Jul 97 12:16:49 -0500 Message-ID: <1997Jul30.121649.1@aspen> To: MX-List@WKUVX1.WKU.EDU In article <009B805E.C71078E5.122@ALPHA.WKU.EDU>, Hunter Goatley writes: > Hunter Goatley writes: > > Also, Brian, do a DIR of MX_EXE: and make sure your .EXEs all date > from the same time. I, too, had an MX SMTP agent crash the other day, > but it was because the MX_SMTP.EXE wasn't updated when I did my last > MX installation. I apparently forgot to ensure that the SMTP module > was updated during the last install. Why is it that even the complications have complications? For example, I just took Hunter's advice, and said $DIR/DAT MX_EXE:*.EXE To my surprise, all the latest versions had the same time, within seconds of each other last January, except that mx_local.exe;2 and smtp_server.exe;2 had times 25 hours EARLIER than their version 1. I knew there must be some simple explanation, which of course would require me to search through log files (or paperwork) if we had any. Fortunately, I had placed a 0read.me in that directory, which says "mx_local.exe;2 and smtp_server.exe;2 are indeed later, patched versions". I do not understand it; I wrote it; I will take the easy way out and believe it. -- Brendan Welch, system analyst, UMass-Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Wed, 30 Jul 1997 11:41:37 -0500 Sender: Message-ID: From: "Worlton, Thomas" Reply-To: MX-List@MadGoat.com To: 'MX-LIST' Subject: FW: Mailing list or file server error Date: Wed, 30 Jul 1997 11:40:55 -0500 MIME-Version: 1.0 Content-Type: text/plain > Hunter: > This is a little late to be bringing up since you are about > ready to introduce a new version, but I would like to see the format > of > mailing list entries be a little more consistent. Some of my mailing > list entries have the personal name in quotations and some don't. > Some > have the address in angle brackets and some don't. Personally, I > prefer > the quotation marks and angle brackets, but I don't think those are > added when a person subscribes via E Mail. Ideally, I would like to > have the personal name as "lastname, firstname" for sorting > convenience. > Another thing that would be useful as a list administrator would be a > "replace" command that would allow replacing an address entry with one > with the name added or modified, or with different qualifiers. I > don''t > know how doable these requests are since I don't know how you store > your > mailing list database. > > Tom Worlton > ================================================================================ Archive-Date: Wed, 30 Jul 1997 11:56:22 -0500 Sender: Date: Wed, 30 Jul 1997 11:56:15 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B8068.0C08649C.1@ALPHA.WKU.EDU> Subject: RE: FW: Mailing list or file server error "Worlton, Thomas" writes: > > Hunter: > This is a little late to be bringing up since you are about > ready to introduce a new version, but I would like to see the format > of > mailing list entries be a little more consistent. Some of my mailing > list entries have the personal name in quotations and some don't. > Some > have the address in angle brackets and some don't. Personally, I > prefer > the quotation marks and angle brackets, but I don't think those are > added when a person subscribes via E Mail. Ideally, I would like to > have the personal name as "lastname, firstname" for sorting > convenience. It all depends on what the person adds for their personal name when they SUBSCRIBE (or what you supply when you ADD them). If they surround their personal name in quotes, the quotes make it to the list. If they don't, the quotes aren't added. The angle brackets around the e-mail address are always there *if* a personal name was supplied. If the subscriber just said "SUBSCRIBE" with no name, the entry will show up without the angle brackets. I could ensure that quotes are always there, and that angle brackets are always present, but the "Lastname, Firstname" bit isn't practical because the subscriber may supply all kinds of extra info in the personal name. > Another thing that would be useful as a list administrator would be a > "replace" command that would allow replacing an address entry with one > with the name added or modified, or with different qualifiers. I > don''t > know how doable these requests are since I don't know how you store > your > mailing list database. > Yes, I agree that REPLACE would be nice. Especially if you have DIGEST subscribers, or NOMAIL or something, which requires you to look up the address before you do the REMOVE/ADD combo. I'll add this to the wish list, but it won't be in MX V5.0. Thanks. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Wed, 30 Jul 1997 12:13:45 -0500 Sender: Date: Wed, 30 Jul 1997 13:13:27 EDT From: Brian Reed Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B8072.D4EDAB9E.5@cbict3.cb.lucent.com> Subject: Re: Multiple From addresses and REPLY (VMS 7.x) >>How do I specify this in MX_LOGICALS.DAT? I'm unsure of how to make the >>value of the logical a blank in this file. > >You don't. You should never edit MX_LOGICALS.DAT by hand (or at >least, you shouldn't add logicals) because it's replaced by new MX >installations. As with other products, you should define any >additional MX logicals in your system startup procedure. Is it possible to add that as a note to that file? I'm probably guilty of editing that file, just because it seemed like the place to put it. A warning at the top would prevent that. Brian D. Reed Lucent Technologies Columbus Works bdreed1@lucent.com 614-860-6218 ================================================================================ Archive-Date: Wed, 30 Jul 1997 15:49:09 -0500 Sender: Date: Wed, 30 Jul 1997 16:48:00 EDT From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: hardis@garnet.nist.gov Message-ID: <009B8090.CDE2F200.19@garnet.nist.gov> Subject: RE: The definitive answer RE: MX and long lines and VMS Mail "Jonathan E. Hardis" continues to beat a dead horse: >>> To clear up some confusion, VMS Mail *used* to truncate lines at 255 >>> characters. However, sometime along the line, VMS Mail was modified >>> to allow much longer lines. >> Ouch. That doesn't help me much, though, because this microVAX is >> going to remain at VMS 5.3-1 until the day it dies. (I suspect lot >> of other people are in a similar situation.) >> >> Could 255 character truncation be made a configuration option? > It's no longer an issue, as far as MX goes. It doesn't do the > truncation, but VMS Mail might. > > I can see how auto-wrapping by MX Local would be desirable, but I > haven't thought much about how best to do that. One need not do a clean word-wrap like word processors do, rather, MX Local could be triggered into a "quoted-printable" ENCODING mode if (1) any line is longer than 76 characters, or (2) any character is not printable ASCII. >>> It is true that MX doesn't encode messages that come in but are not >>> targetted for local delivery. MX is a transport and should not really >>> (IMO) be doing those sorts of things to messages that are just passing >>> through. >> What about messages that come in that *are* targeted for local delivery? >> This is where the pain is. > Plain quoted-printable messages coming in for local delivery *are* > automatically decoded by MX, alhtough those were restricted to > "text/plain" messages in MX V4.2. MX V5.0 will decode all "text*" > messages, though multi-part MIME messages are still not handled. The discussion slipped a cog ... I wasn't talking about decoding messages, I was talking about encoding them. However, you raise a second, interesting point. Imagine the situation where the remote sender encodes a message as "quoted-printable" because of its long lines. (Eudora does that, I believe, when "MIME" is enabled.) Then, stealing defeat from the jaws of victory, MX Local recreates the long lines so that VMS Mail (at least my antique version of it) can truncate them. In this situation, I'd be happy if the MX Local MIME decoding mechanism can be turned off by a configuration switch. In other words, I'd rather have the MIME junk than truncated lines. Thanks for the consideration, Jonathan ================================================================================ Archive-Date: Wed, 30 Jul 1997 15:54:08 -0500 Sender: Date: Wed, 30 Jul 1997 15:53:59 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B8089.41E3C275.3@ALPHA.WKU.EDU> Subject: RE: The definitive answer RE: MX and long lines and VMS Mail "Jonathan E. Hardis" writes: > >"Jonathan E. Hardis" continues to beat a dead >horse: > 8-) >One need not do a clean word-wrap like word processors do, rather, >MX Local could be triggered into a "quoted-printable" ENCODING mode >if (1) any line is longer than 76 characters, or (2) any character >is not printable ASCII. > Ouch. I can see your point, though. >However, you raise a second, interesting point. Imagine the situation >where the remote sender encodes a message as "quoted-printable" because of >its long lines. (Eudora does that, I believe, when "MIME" is enabled.) >Then, stealing defeat from the jaws of victory, MX Local recreates the long >lines so that VMS Mail (at least my antique version of it) can truncate >them. > 8-) >In this situation, I'd be happy if the MX Local MIME decoding mechanism can >be turned off by a configuration switch. In other words, I'd rather have >the MIME junk than truncated lines. > I'll look into making that configurable for MX V5.0..... Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html ================================================================================ Archive-Date: Wed, 30 Jul 1997 15:55:56 -0500 Sender: From: welchb@woods.uml.edu (Brendan Welch, W1LPG) Reply-To: MX-List@MadGoat.com Subject: RE: long lines; queue corruption Date: 30 Jul 97 16:39:33 -0500 Message-ID: <1997Jul30.163933.1@aspen> To: MX-List@WKUVX1.WKU.EDU > Note that I wouldn't call all of these "queue corruption". When I > think of queue corruption, I think of a queue that has be > re-initialized to fix problems (which, unfortunately, Brendan has seen > several times). > And if this is any possible hint, for our situation, after starting a new que, the REFEED in the contributed directory does not work. VMS V7.0, MX V4.2 with patches. -- Brendan Welch, system analyst, UMass-Lowell, W1LPG, welchb@woods.uml.edu ================================================================================ Archive-Date: Thu, 31 Jul 1997 04:13:43 -0500 Sender: Date: Thu, 31 Jul 1997 02:12:55 -0700 From: "Henry W. Miller" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: henrym@sacto.mp.usbr.gov Message-ID: <009B80DF.B896B162.3@sacto.mp.usbr.gov> Subject: Re: Multiple From addresses and REPLY (VMS 7.x) > From: MX%"MX-List@MadGoat.com" 30-JUL-1997 08:12:56.73 > Subj: Re: Multiple From addresses and REPLY (VMS 7.x) Brian, > > Remember, these ARE the PRELIMINARY docs. Hopefully the > >finished product will have all of the good poop in it. > > Shouldn't we beta testers get "the good poop" first so we can proofread it? Sometimes, the "Good poop" falls through the cracks in the floor... > -- > Brian Tillman Internet: tillman_brian at si.com > Smiths Industries, Inc. tillman at swdev.si.com > 4141 Eastern Ave., MS239 Addresses modified to prevent > Grand Rapids, MI 49518-8727 SPAM. Replace "at" with "@" > This opinion doesn't represent that of my company -HWM ================================================================================ Archive-Date: Thu, 31 Jul 1997 05:38:47 -0500 Sender: From: "Nic CLEWS" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <802564E5.0033FCE5.00@aejacob.jacobs.co.uk> Date: Thu, 31 Jul 1997 11:42:55 +0100 Subject: Editing MX_LOGICALS.DAT MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII >> >>You don't. You should never edit MX_LOGICALS.DAT by hand (or at >>least, you shouldn't add logicals) because it's replaced by new MX >>installations. As with other products, you should define any >>additional MX logicals in your system startup procedure.> >Is it possible to add that as a note to that file? I'm probably >guilty of editing that file, just because it seemed like the >place to put it. A warning at the top would prevent that. I Must admit I have _had_ to edit this file manually. Reason is, the installation configures this file when MX is installed. However if you need to change any IP parameters, particularly the node name, then this is not recorded in this file, and the result is incorrect addresses get sent out. If we are NOT to edit this file, then we should have access to some way of re-running the configurator that creates this file when parameters on our system change which affect the contents of this file. Perhaps there is a way of re-running it, but shutting down MX, editing the file, and restarting MX has not given us any problems. Regards Nic Clews [apologies for the line spacing/wrapping, i'm using Lotus notes :( ] -- Bolton UK website http://www.bolton.ac.uk/bolton/ homepage http://www.python.demon.co.uk/ ================================================================================ Archive-Date: Thu, 31 Jul 1997 08:48:46 -0500 Sender: Date: Thu, 31 Jul 1997 08:48:37 -0500 From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009B8117.001ABA31.18@ALPHA.WKU.EDU> Subject: RE: Editing MX_LOGICALS.DAT "Nic CLEWS" writes: > >I Must admit I have _had_ to edit this file manually. Reason is, the >installation configures this file when MX >is installed. However if you need to change any IP parameters, particularly >the node name, then this is not >recorded in this file, and the result is incorrect addresses get sent out. > >If we are NOT to edit this file, then we should have access to some way of >re-running the configurator that >creates this file when parameters on our system change which affect the >contents of this file. Perhaps there > is a way of re-running it, but shutting down MX, editing the file, and >restarting MX has not given us any problems. > This will be easier in MX V5.0. You can surely edit the file by hand to change values. What I was trying to say is that you shouldn't add site-specific logical names to the file because they'll be lost during the next upgrade. Hunter ------ Hunter Goatley, Process Software, http://www.process.com TCPware & MultiNet: The Best TCP/IP for OpenVMS http://www.madgoat.com/hunter.html