Archive-Date: Sun, 01 Sep 1996 00:05:10 CST Sender: owner-mx-list@WKU.EDU Date: Sun, 01 Sep 1996 00:04:52 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: mx-list@WKU.EDU Message-ID: <009A7B21.A9D165C4.191@WKU.EDU> Subject: MX-LIST Administrivia: Monthly Post Posting statistics for list MX-LIST during August 1996 Total number of posts: 39 Total number of posters: 22 Total number of subscribers: 296 Last modified: 28-SEP-1995 13:33 (Updated digest info) Welcome to MX-List@LISTS.WKU.EDU, an electronic mailing list established for the discussion of the Message Exchange mail software. This is a routine posting you will see from time to time on MX-List. MX-List postings are also available in a daily digest format. To subscribe to the digest, send the following command in the body of a mail message to MXserver@LISTS.WKU.EDU: SUBSCRIBE MX-List-Digest "Your real name here" The MX-List archives are maintained at ARCHIVES@LISTS.WKU.EDU. To get a copy of any month's postings, send an e-mail message with the body SEND MX-List.yyyy-mm to ARCHIVES@LISTS.WKU.EDU, where "yyyy" is the year and "mm" is the numeric representation of the month. For example, the message SENDME MX-List.1992-04 will send the archives for April 1992. MX itself is available via anonymous ftp from ftp.spc.edu in [.MX.MX041]. You can also get it via e-mail by sending the commands SEND MX and SEND FILESERV_TOOLS on separate lines in the body of a mail message to FILESERV@LISTS.WKU.EDU. To remove yourself from the mailing list, send the following command to MXserver@LISTS.WKU.EDU: SIGNOFF MX-List MXserver supports a few other commands for your convenience. The following commands can be handled automatically by the list processor: SIGNOFF MX-List - to remove yourself from the list REVIEW MX-List - to get a list of subscribers QUERY MX-List - to get the status of your entry on the list SET MX-List DIGEST - to switch to digest mode SET MX-List NODIGEST - to switch to non-digest mode SET MX-List NOMAIL - to remain on the list but not receive mail SET MX-List MAIL - to resume receiving mail from the list SET MX-List CONCEAL - to not report your address in a REVIEW SET MX-List NOCONCEAL - to report your address in a REVIEW SET MX-List REPRO - to receive posts you make to MX-List SET MX-List NOREPRO - to not receive posts you make to MX-List LIST - to get a list of mailing lists served by WKUVX1 HELP - to receive a help file By default, subscriptions are set to MAIL, REPRO, NOCONCEAL. If you have any questions, comments, or suggestions about MX-List, please contact the list owner at the address below. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Hunter Goatley, Sr. OpenVMS Systems Programmer goathunter@LOKI.COM The LOKI Group, Inc. P.O. Box 9609 Bowling Green, KY 42102-9609 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- ================================================================================ Archive-Date: Mon, 02 Sep 1996 04:22:17 CST Sender: owner-mx-list@WKU.EDU From: goathunter@MadGoat.com (Hunter Goatley) Subject: Re: SMTP Envelope UserID Date: 1 Sep 96 22:29:22 CST Message-ID: <1996Sep1.222922@alpha.wku.edu> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <643_9608312236@neverlnd.org.uk>, Peter Burnett writes: > I have a small list server utilising the MX package on a 3100 here. > > Most subscribers have had zero problems in subscribing and managing thier > subscriptions to the couple of lists I run except for one. > [...] > From experiments I have tried here, any email to the MXServer or FileServer > where the userid part of the SMTP envelope is "uucp", MX just ignores the > message. Is this the correct and expected action for MX. It's expected, but not correct. The *real* problem is that the envelope shouldn't say "uucp". In trying to block bounce messages from lists, I got a bit overzealous and caught these as well. It'll be fixed in the next release. It should work to put an access entry for that host and subscribe the user by hand. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Tue, 03 Sep 1996 08:24:18 CST Sender: owner-mx-list@WKU.EDU From: goathunter@MadGoat.com (Hunter Goatley) Subject: Re: Mailing list or file server error Date: 3 Sep 96 08:04:44 CST Message-ID: <1996Sep3.080444@alpha.wku.edu> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <658_9609022317@neverlnd.org.uk>, Peter Burnett writes: > Has the newsgroup VMSNET.MAIL.MX <> Mailing List gateway gone into one-way mode > or is there a situation that I am not aware about. I posted a message into the > group and I got this back. > Yes, several months ago (between 6 and 12), I set the list so that only subscribers can post. This was done to eliminate all the junk mail coming from the news side (all those magazine subscription spams, etc.). I posted messages to that effect here, but I guess I should do that periodically. If you read vmsnet.mail.mx and want to post to the list too, you must subscribe to the list. You don't have to receive the mail, though; just send these commands to : SUBSCRIBE MX-List "Your real name here" SET MX-List NOMAIL Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Tue, 03 Sep 1996 13:50:44 CST Sender: owner-mx-list@WKU.EDU From: dwing@tgv.com ("Dan Wing") Subject: Re: Mailing list or file server error Date: 3 Sep 1996 17:35:52 GMT Message-ID: <50hq9o$bgs@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <658_9609022317@neverlnd.org.uk>, Peter Burnett writes: > Has the newsgroup VMSNET.MAIL.MX <> Mailing List gateway gone into one-way mode > or is there a situation that I am not aware about. I posted a message into the > group and I got this back. > > ================================== > Note: this message was generated automatically. > > The following error(s) occurred during local delivery of your message. > > Error in delivery to mailing list MX-List: > access denied; send subscription requests to MX-List-Request@WKU.EDU [...] Due to the many USENET spams, Hunter set the MX-List mailing list to only allow posts by subscribers. If you post via USENET, and you want your post seen by MX-List mailing list subscribers, you need to subscribe to MX-List (via mx-list-request@wkuvx1.wku.edu) and set your subscription to NoMail. -Dan Wing dwing@tgv.com / dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Tue, 03 Sep 1996 19:37:17 CST Sender: owner-mx-list@WKU.EDU Message-ID: <322C6CBA.2E29672F@tmc.naecker.com> Date: Tue, 03 Sep 1996 17:36:58 +0000 From: Brad Hughes Reply-To: MX-List@MadGoat.com MIME-Version: 1.0 To: mx-list@madgoat.com Subject: $ MCP SET LOCAL/HEADER=TOP:NOALL Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit continuing a thread from last February.. If you've set LOCAL/HEADER=TOP:NOALL then Netscape mail (version 2.02b1 from the DEC website) will get very upset and confused. Messages will half appear, then disappear entirely, and other strange behavior. Setting headers back on seemed to make it happier. ================================================================================ Archive-Date: Wed, 04 Sep 1996 09:16:11 CST Sender: owner-mx-list@WKU.EDU Date: Wed, 04 Sep 1996 16:15:06 EDT From: "Mario Meyer, Phys.-Techn. Bundesanstalt" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: mmeyer@ChbRB.Berlin.PTB.De Message-ID: <009A7E04.B36A9A84.5@ChbRB.Berlin.PTB.De> Subject: DECnet_SMTP transfer problems Hello, I observe very slow data transfer between two MX-MTAs via DECnet_SMTP. For large Files there is no transfer possible, since links are disconnected after some time. File transfer via FAL between these systems is much faster. I can't find any network problems nor ressource problems on the servers. This is the configuration: ,-------. ,-------. | |--RouterA- -ser.line (9.6kb/s TCP/IP)- -RouterC--| | Internet--| net 1 | | net 2 | | |--RouterB- -ser.line (64kb/s DECnet4)- -RouterD--| | `---+---' `---+---' | | MX-Server1 MX-Server2 (MX V4.1 VAX,DECnetIV) (MX V3.3 VAX,DECnet/OSI) I route SMTP traffic between the two nets via DECnet_SMTP. I can observe data transfer via NCL on MX-Server2 looking at the NSP Port that belongs to a connection. For normal (big) file copy operation (Session Control Application FAL) there were RoundTrip Delay Estimate of about 1.3 s. DECSMTP showed an RoundTrip Delay Estimate rising from 3 to 60 s and aborted the logical link then (sts2=000020E4). BTW other Services like X.11 (X$X0) or CTERM (42) had RoundTrip Delay Estimate of 70 ms (they use short packets). All NSP Ports have Network Priority 0 (in and out). NSP ports used by DECSMTP show extraordinary high "Retransmitted PDUs" count. Thus I assume that the DECnet_SMTP-server-process at the Phase4-Server responds very slowly. This process runs with base priority 4 and is most of the time in HIB state. The Phase4-NCP-object DECSMTP is entered as recommended: Number = 254 File id = MX_EXE:DNSMTP_SERVER.EXE User id = DNSMTP_SRV Password = ... Proxy access = none I can't see any reason, why DECSMTP is so much slower than other services. My workaround is to route the mails via TCP/IP-SMTP meanwhile, and this is much faster though there is less bandwith for TCP/IP. Can someone explain this behavior and help me to fix the problem ? I append a DECnet_SMTP(client) debug log for illustration: 8<------------------------------------------------------------------------------ 4-SEP-1996 12:59:01.83 Processing queue entry number 24413 on node ATLAS 4-SEP-1996 12:59:02.04 Recipient: , route=merlin 4-SEP-1996 12:59:02.04 SMTP_SEND: connecting to merlin::"DECSMTP=" 4-SEP-1996 12:59:17.46 SMTP_SEND: Connected 4-SEP-1996 12:59:17.57 SMTP_SEND: Rcvd: 220 MERLIN MX V4.1 VAX SMTP server re ady at Wed, 04 Sep 1996 12:58:34 EDT 4-SEP-1996 12:59:17.69 SMTP_SEND: Sent: HELO ATLAS 4-SEP-1996 12:59:25.16 SMTP_SEND: Rcvd: 250 Hello, ATLAS 4-SEP-1996 12:59:25.16 SMTP_SEND: Sent: MAIL FROM: 4-SEP-1996 12:59:30.29 SMTP_SEND: Rcvd: 250 MAIL command accepted. 4-SEP-1996 12:59:30.30 SMTP_SEND: Sent: RCPT TO: 4-SEP-1996 12:59:30.35 SMTP_SEND: Rcvd: 250 Recipient okay (at least in form) 4-SEP-1996 12:59:30.37 SMTP_SEND: Sent: DATA 4-SEP-1996 12:59:30.71 SMTP_SEND: Rcvd: 354 Start mail input; end with . 4-SEP-1996 12:59:30.71 SMTP_SEND: Sent: Received: by FhgRB.Berlin.PTB.De (MX V3.3 VAX) id 24412; Wed, 04 Sep 1996 4-SEP-1996 12:59:30.72 SMTP_SEND: Sent: 12:03:28 MET_DST 4-SEP-1996 12:59:30.72 SMTP_SEND: Sent: Sender: mmeyer@FhgRB.Berlin.PTB.De 4-SEP-1996 12:59:30.72 SMTP_SEND: Sent: Date: Wed, 04 Sep 1996 12:03:22 MET_D ST 4-SEP-1996 12:59:30.72 SMTP_SEND: Sent: From: mmeyer@FhgRB 4-SEP-1996 12:59:30.73 SMTP_SEND: Sent: To: mmeyer@chbtest 4-SEP-1996 12:59:30.73 SMTP_SEND: Sent: Message-ID: <009A7DE1.88722AAC.24412@ FhgRB.Berlin.PTB.De> 4-SEP-1996 12:59:30.73 SMTP_SEND: Sent: Subject: X25TRAFF.OUT;2 4-SEP-1996 12:59:30.73 SMTP_SEND: Sent: 4-SEP-1996 12:59:30.73 SMTP_SEND: Sent: Messung Nr. 0 4-SEP-1996 12:59:30.74 SMTP_SEND: Sent: 4-SEP-1996 12:59:30.74 SMTP_SEND: Sent: Node .IB.CHAC X25 Protocol DTE WIN-DT E 4-SEP-1996 12:59:30.74 SMTP_SEND: Sent: at 1996-05-22-11:01:08.216+02:00Iinf 4-SEP-1996 12:59:30.74 SMTP_SEND: Sent: 4-SEP-1996 12:59:30.74 SMTP_SEND: Sent: Counters 4-SEP-1996 12:59:30.74 SMTP_SEND: Sent: 4-SEP-1996 12:59:30.75 SMTP_SEND: Sent: Data Octets Received = 231018847 4-SEP-1996 12:59:30.75 SMTP_SEND: Sent: Data Octets Sent = 51933163 4-SEP-1996 12:59:30.75 SMTP_SEND: Sent: 4-SEP-1996 12:59:30.75 SMTP_SEND: Sent: Messung Nr. 1 4-SEP-1996 12:59:30.75 SMTP_SEND: Sent: 4-SEP-1996 13:02:53.24 SMTP_SEND: Sent: Node .IB.CHAC X25 Protocol DTE WIN-DT E 4-SEP-1996 13:02:53.24 SMTP_SEND: Sent: at 1996-05-22-11:01:18.046+02:00Iinf 4-SEP-1996 13:02:53.24 SMTP_SEND: Sent: 4-SEP-1996 13:02:53.24 SMTP_SEND: Sent: Counters 4-SEP-1996 13:02:53.25 SMTP_SEND: Sent: 4-SEP-1996 13:02:53.25 SMTP_SEND: Sent: Data Octets Received = 231021212 4-SEP-1996 13:02:53.25 SMTP_SEND: Sent: Data Octets Sent = 51933547 4-SEP-1996 13:02:53.25 SMTP_SEND: Sent: 4-SEP-1996 13:02:53.25 SMTP_SEND: Sent: Messung Nr. 2 4-SEP-1996 13:02:53.25 SMTP_SEND: Sent: 4-SEP-1996 13:02:53.25 SMTP_SEND: Sent: Node .IB.CHAC X25 Protocol DTE WIN-DT E 4-SEP-1996 13:02:53.25 SMTP_SEND: Sent: at 1996-05-22-11:01:28.066+02:00Iinf 4-SEP-1996 13:02:53.26 SMTP_SEND: Sent: 4-SEP-1996 13:02:53.26 SMTP_SEND: Sent: Counters 4-SEP-1996 13:02:53.26 SMTP_SEND: Sent: 4-SEP-1996 13:02:53.26 SMTP_SEND: Sent: Data Octets Received = 231027308 4-SEP-1996 13:02:53.26 SMTP_SEND: Sent: Data Octets Sent = 51934319 4-SEP-1996 13:02:53.26 SMTP_SEND: Sent: 4-SEP-1996 13:02:53.27 SMTP_SEND: Sent: Messung Nr. 3 4-SEP-1996 13:09:30.82 SMTP_SEND: Sent: 4-SEP-1996 13:09:30.90 SMTP send failed, sts=0C27804A, sts2=000020E4 4-SEP-1996 13:09:30.90 Recipient status=0C27804A for 4-SEP-1996 13:09:31.53 1 rcpts need retry, next try 4-SEP-1996 13:21:55.53 4-SEP-1996 13:09:31.56 *** End of processing pass *** >8------------------------------------------------------------------------------ The end is always the same where the code sts2=000020E4 stands for %SYSTEM-F-LINKABORT, network partner aborted logical link The log of the server process doesn't show more. it ends with 8<------------------------------------------------------------------------------ ... STM[1]: Receive "" STM[1]: Error: status=20E4 >8------------------------------------------------------------------------------ Thanks in advance Mario Meyer --,------------------------------------------------------.------------------ | Mario Meyer Physikalisch-Technische Bundesanstalt | . , | ............. Institut Berlin Referat IB.TI | _QQ__ | : wide area : Abbestr. 2-12, D - 10587 Berlin | __( U, )__ | : networker : tel. (+49 30) 3481 472, fax. ... 490 | /// `---' \\\ | SMTP: MMeyer@Berlin.PTB.De, BITNET: MMeyer@PTBIB | /||\ /||\ --| X.400: S=Meyer; OU=IB-TI; O=PTB; P=PTB; A=d400; C=DE |------------------ `------------------------------------------------------' ================================================================================ Archive-Date: Fri, 06 Sep 1996 11:50:18 CST Sender: owner-mx-list@WKU.EDU Date: Fri, 06 Sep 1996 17:50:53 BST From: John Powers Reply-To: MX-List@MadGoat.com To: goathunter@LOKI.COM CC: MX-LIST@WKUVX1.WKU.EDU, john.powers@blackwell.co.uk Message-ID: <009A7FA4.698DB620.50@blackwell.co.uk> Subject: RE: Router goes phut,, Sorry about the appalling delay on answering this. Just as it arrived, I disappeared off on vacation, then we had a major failure of our network links, then just a major failure of my brain or something.. On 11-JUL-1996 21:38:14.58 (yes, that long ago) MX%"goathunter@LOKI.COM" wrote > >john.powers@blackwell.co.uk writes: >> >>Many thanks for the vital clues. Got the bug in the rewriter sorted >>now. > >Good! Sorry it took so long to reply to your post. > >>Last month somebody was subscribed to a mailing list with a very >>long address, and the address rewriter got flummoxed by exceptionally >>long mail addresses. Now fixed - people can subscribe to whatever they >>want. >> >Was this the ADDRESS_REWRITER.C that's shipped with MX? If the bug >was in that, I'd appreciate it if you would send me the fix. > The correct answer is "I don't know". It came from from someone in Bristol via our GoldMail supplier. If you are still interested, I can try to find out for you. We no longer have it here, as following another thread in this list, we scrapped it and replaced it with the superior ADDRESS_REWRITER.B32. This is much better for us, as we have the Bliss compiler (cos its free!), and we never had a C compiler (you have to pay for it!), so we kept having to ask our Bristol friends to compile it. John. ----------------------------------------------------------------------------- John Powers - Blackwell's, Oxford - - "fee issuing thirty mails" (anag.) john.powers@blackwell.co.uk (Internet) Blackwells Booksellers - Visit our PSI%234284400179::TJGP (PSImail) home page: http://www.blackwell.co.uk/ ----------------------------------------------------------------------------- ================================================================================ Archive-Date: Mon, 16 Sep 1996 11:05:46 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 16 Sep 1996 11:05:16 CST From: hunterl@uwwvax.uww.edu Reply-To: MX-List@MadGoat.com To: mx-list@wkuvx1.wku.edu Message-ID: <009A8747.675E5E3B.3@uwwvax.uww.edu> Subject: string too long string is too long (greater than 65535) is the error after smtp server dies. What can I do do prevent the problem? Lyle Hunter T & IR University Wisconsin-Whitewater hunterl@uwwvax.uww.edu ================================================================================ Archive-Date: Mon, 16 Sep 1996 11:07:46 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 16 Sep 1996 11:07:29 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8747.B6FE32B3.7@ALPHA.WKU.EDU> Subject: RE: string too long hunterl@uwwvax.uww.edu writes: > >string is too long (greater than 65535) is the error after smtp server >dies. What can I do do prevent the problem? > As I think I replied here last week, nothing yet, but that'll be fixed in the next release of MX, for which I hope to have a timeframe in the next few weeks. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Mon, 16 Sep 1996 13:24:48 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 16 Sep 1996 14:24:23 EST From: Jim Bender Reply-To: MX-List@MadGoat.com To: mx-list@madgoat.com Message-ID: <009A8763.38BF6450.37@bdsnet.com> Subject: lines longer than 255 chars Hi... Was a consensus ever reached in the problem with VMS mail truncating lines after 255 chars? Could a configurable option be added to allow forced line breaks to be inserted at a user-definable point to overcome this? Would solve a *VERY* annoying problem. Educating people about hitting return at the end of a line isn't working. Thanks! Jim Bender jbender@bdsnet.com MX4.2, VMS5.5, problem is with incoming SMTP messages. ================================================================================ Archive-Date: Mon, 16 Sep 1996 13:35:59 CST Sender: owner-mx-list@WKU.EDU From: dunnett@mala.bc.ca (Malcolm Dunnett) Reply-To: MX-List@MadGoat.com Subject: RE: string too long Date: 16 Sep 96 11:24:31 -0700 Message-ID: <1996Sep16.112431@malvm1.mala.bc.ca> To: MX-List@WKUVX1.WKU.EDU [sorry about the duplication, my last attempt got bounced from mx-list because I wasn't subscribed] In article <009A8747.B6FE32B3.7@ALPHA.WKU.EDU>, Hunter Goatley writes: > hunterl@uwwvax.uww.edu writes: >> >>string is too long (greater than 65535) is the error after smtp server >>dies. What can I do do prevent the problem? >> > As I think I replied here last week, nothing yet, but that'll be fixed > in the next release of MX, for which I hope to have a timeframe in the > next few weeks. > I'm getting these this morning also. I suspect some jerk is sending a spam with a malformed message in it. I'll look forward to the next release. I guess in the interim all one can do is turn on debugging to find out the source of the spam then block all access from that host. -- ============================================================================= Malcolm Dunnett Malaspina University-College Email: dunnett@mala.bc.ca Computer Services Nanaimo, B.C. CANADA V9R 5S5 Tel: (604)755-8738 ================================================================================ Archive-Date: Mon, 16 Sep 1996 13:47:00 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 16 Sep 1996 13:46:26 CST From: hunterl@uwwvax.uww.edu Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A875D.EB744EC7.91@uwwvax.uww.edu> Subject: RE: string too long => >>string is too long (greater than 65535) is the error after smtp server => >>dies. What can I do do prevent the problem? => >> => > As I think I replied here last week, nothing yet, but that'll be fixed => > in the next release of MX, for which I hope to have a timeframe in the => > next few weeks. => > => => I'm getting these this morning also. I suspect some jerk is sending => a spam with a malformed message in it. => => I'll look forward to the next release. I guess in the interim all => one can do is turn on debugging to find out the source of the spam then => block all access from that host. If any one discovers the source, please share it. I am been unsuccessful in tracking it down since this morning. Lyle Hunter T & IR University Wisconsin-Whitewater hunterl@uwwvax.uww.edu ================================================================================ Archive-Date: Mon, 16 Sep 1996 14:07:38 CST Sender: owner-mx-list@WKU.EDU From: dwing@tgv.com ("Dan Wing") Subject: Re: string too long Date: 16 Sep 1996 18:31:40 GMT Message-ID: <51k6ec$s4m@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <009A8747.675E5E3B.3@uwwvax.uww.edu>, hunterl@uwwvax.uww.edu writes: > string is too long (greater than 65535) is the error after smtp server > dies. What can I do do prevent the problem? Nothing other than convince users sending you data to limit their string length. Also, RFC821 indicates: text line The maximum total length of a text line including the is 1000 characters (but not counting the leading dot duplicated for transparency). -Dan Wing dwing@tgv.com / dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Mon, 16 Sep 1996 14:55:22 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 16 Sep 1996 14:55:12 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8767.868A440D.4@ALPHA.WKU.EDU> Subject: RE: lines longer than 255 chars Jim Bender writes: > >Was a consensus ever reached in the problem with VMS mail truncating lines >after 255 chars? > >Could a configurable option be added to allow forced line breaks to be >inserted at a user-definable point to overcome this? > >Would solve a *VERY* annoying problem. Educating people about hitting >return at the end of a line isn't working. > You could force them into an editor to solve the problem. The problem here, if I'm remembering correctly from when I looked into this a couple of years ago, is that VMS Mail drops the text, so it never makes it to MX. VMS Mail would have to be fixed to really solve this problem (outgoing VMS mail). Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Mon, 16 Sep 1996 15:55:55 CST Sender: owner-mx-list@WKU.EDU From: dunnett@mala.bc.ca (Malcolm Dunnett) Reply-To: MX-List@MadGoat.com Subject: Re: string too long Date: 16 Sep 96 13:39:29 -0700 Message-ID: <1996Sep16.133929@malvm1.mala.bc.ca> To: MX-List@WKUVX1.WKU.EDU In article <51k6ec$s4m@cronkite.cisco.com>, dwing@tgv.com ("Dan Wing") writes: > > Nothing other than convince users sending you data to limit their > string length. Also, RFC821 indicates: > > text line > > The maximum total length of a text line including the > is 1000 characters (but not counting the leading > dot duplicated for transparency). > I think the problem is not with a particular line, but that some header element is > 65535 bytes after all the continuation lines are appended on. My report of this problem earlier today turned out to be caused by this, as the attached trace shows: STM[6]: Send "220 malvm1.mala.bc.ca MX V4.2 AXP SMTP server ready at Mon, 16 Sep 1996 12:24:47 PST" STM[6]: Receive "HELO Cyber2.cybernet-usa.net" STM[6]: Send "250 Hello, Cyber2.cybernet-usa.net" STM[6]: Receive "MAIL FROM:" STM[6]: Send "250 MAIL command accepted." STM[6]: Receive "RCPT TO:" STM[6]: Send "250 Recipient okay (at least in form)" STM[6]: Receive "DATA" STM[6]: Send "354 Start mail input; end with ." STM[6]: Receive "Received: from cyberhq1.cybernet-usa.net ([206.72.143.33])" STM[6]: Receive " by Cyber2.cybernet-usa.net (post.office MTA v2.0 0813 ID# 0-0U10)" STM[6]: Receive " with SMTP id AAA116; Sun, 15 Sep 1996 13:13:52 -0400" STM[6]: Receive "Comments: Authenticated sender is " STM[6]: Receive "From: admail@cyber2.cybernet-usa.net (admail)" STM[6]: Receive "To: null@reiworld.com" STM[6]: Receive "Date: Mon, 16 Sep 1996 01:16:52 +0000" STM[6]: Receive "MIME-Version: 1.0" STM[6]: Receive "Content-type: text/plain; charset=US-ASCII" STM[6]: Receive "Content-transfer-encoding: 7BIT" STM[6]: Receive "Subject: INFORMATION YOU REQUESTED" STM[6]: Receive "BCC: 102200.3071@compuserve.com," STM[6]: Receive " 102215.1311@compuserve.com," STM[6]: Receive " 102222.2360@compuserve.com," STM[6]: Receive " 102232.1007@compuserve.com," STM[6]: Receive " 102250.2572@compuserve.com," STM[6]: Receive " 102256.2043@compuserve.com," STM[6]: Receive " 102266.234@compuserve.com," STM[6]: Receive " 102316.3113@compuserve.com," STM[6]: Receive " 102334.2017@compuserve.com," STM[6]: Receive " 102342.2535@compuserve.com," STM[6]: Receive " 102351.1713@compuserve.com," STM[6]: Receive " 102363.135@compuserve.com," (this then goes on for thousands of lines, leading to a server crash). I had earlier suggested setting the host to reject mail from the offending address, but of course this won't work with MX/Multinet because MX doesn't go through Multinet's server process. My solution was to block all traffic from the offender at our router. Perhaps a "reject hosts" database would be a useful addition to the MX wish list ( if it isn't already there ). -- ============================================================================= Malcolm Dunnett Malaspina University-College Email: dunnett@mala.bc.ca Computer Services Nanaimo, B.C. CANADA V9R 5S5 Tel: (604)755-8738 ================================================================================ Archive-Date: Mon, 16 Sep 1996 16:05:30 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 16 Sep 1996 16:05:20 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8771.531C31DA.6@ALPHA.WKU.EDU> Subject: Re: string too long dunnett@mala.bc.ca (Malcolm Dunnett) writes: > > I think the problem is not with a particular line, but that some >header element is > 65535 bytes after all the continuation lines are >appended on. My report of this problem earlier today turned out to be >caused by this, as the attached trace shows: > Exactly---the RFC822 To: header is too long. I don't have RFC822 handy, so I don't remember what it says about long lines. > Perhaps a "reject hosts" database would be a useful addition >to the MX wish list ( if it isn't already there ). > Yes, that's on the wish list.... Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Mon, 16 Sep 1996 16:09:01 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 16 Sep 1996 17:08:40 EST From: Jim Bender Reply-To: MX-List@MadGoat.com To: mx-list@madgoat.com Message-ID: <009A877A.2C09F240.7@bdsnet.com> Subject: re: lines longer than 255 chars On Mon, 16 Sep 1996, Hunter Goatley wrote: > Jim Bender writes: > > > >Was a consensus ever reached in the problem with VMS mail truncating lines > >after 255 chars? > > > >Could a configurable option be added to allow forced line breaks to be > >inserted at a user-definable point to overcome this? > > > >Would solve a *VERY* annoying problem. Educating people about hitting > >return at the end of a line isn't working. > > > You could force them into an editor to solve the problem. > > The problem here, if I'm remembering correctly from when I looked into > this a couple of years ago, is that VMS Mail drops the text, so it > never makes it to MX. VMS Mail would have to be fixed to really solve > this problem (outgoing VMS mail). > Oops... what I meant to say was that this is for incoming SMTP mail. i.e, the message is intact until MX hands it off to VMS Mail, which promptly drops everything after 255 chars. A way to have MX insert line breaks before giving the message to VMS mail would solve this. Thanks for the response... Jim Bender jbender@bdsnet.com ================================================================================ Archive-Date: Mon, 16 Sep 1996 16:20:54 CST Sender: owner-mx-list@WKU.EDU From: dwing@tgv.com ("Dan Wing") Subject: Re: string too long Date: 16 Sep 1996 21:14:09 GMT Message-ID: <51kfv1$a9h@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <1996Sep16.133929@malvm1.mala.bc.ca>, dunnett@mala.bc.ca (Malcolm Dunnett) writes: > I think the problem is not with a particular line, but that some > header element is > 65535 bytes after all the continuation lines are > appended on. My report of this problem earlier today turned out to be > caused by this, as the attached trace shows: > > STM[6]: Send "220 malvm1.mala.bc.ca MX V4.2 AXP SMTP server ready at Mon, 16 Sep 1996 12:24:47 PST" > STM[6]: Receive "HELO Cyber2.cybernet-usa.net" > STM[6]: Send "250 Hello, Cyber2.cybernet-usa.net" > STM[6]: Receive "MAIL FROM:" > STM[6]: Send "250 MAIL command accepted." > STM[6]: Receive "RCPT TO:" > STM[6]: Send "250 Recipient okay (at least in form)" > STM[6]: Receive "DATA" > STM[6]: Send "354 Start mail input; end with ." > STM[6]: Receive "Received: from cyberhq1.cybernet-usa.net ([206.72.143.33])" > STM[6]: Receive " by Cyber2.cybernet-usa.net (post.office MTA v2.0 0813 ID# 0-0U10)" > STM[6]: Receive " with SMTP id AAA116; Sun, 15 Sep 1996 13:13:52 -0400" > STM[6]: Receive "Comments: Authenticated sender is " > STM[6]: Receive "From: admail@cyber2.cybernet-usa.net (admail)" > STM[6]: Receive "To: null@reiworld.com" > STM[6]: Receive "Date: Mon, 16 Sep 1996 01:16:52 +0000" > STM[6]: Receive "MIME-Version: 1.0" > STM[6]: Receive "Content-type: text/plain; charset=US-ASCII" > STM[6]: Receive "Content-transfer-encoding: 7BIT" > STM[6]: Receive "Subject: INFORMATION YOU REQUESTED" > STM[6]: Receive "BCC: 102200.3071@compuserve.com," > STM[6]: Receive " 102215.1311@compuserve.com," > STM[6]: Receive " 102222.2360@compuserve.com," > STM[6]: Receive " 102232.1007@compuserve.com," > STM[6]: Receive " 102250.2572@compuserve.com," > STM[6]: Receive " 102256.2043@compuserve.com," > STM[6]: Receive " 102266.234@compuserve.com," > STM[6]: Receive " 102316.3113@compuserve.com," > STM[6]: Receive " 102334.2017@compuserve.com," > STM[6]: Receive " 102342.2535@compuserve.com," > STM[6]: Receive " 102351.1713@compuserve.com," > STM[6]: Receive " 102363.135@compuserve.com," > > (this then goes on for thousands of lines, leading to > a server crash). Ah, I see. > I had earlier suggested setting the host to reject mail from the > offending address, but of course this won't work with MX/Multinet > because MX doesn't go through Multinet's server process. My solution > was to block all traffic from the offender at our router. Some sites don't have control over their router, so a black-hole route can be used on your MultiNet box, too: $ MULTINET SET/ROUTE/ADD=(DESTINATION=ip,GATE=blah) Where "ip" is the IP address of the source mailer(s) you don't want to accept mail from, and "blah" is some local IP address which is _not_ a router. This will cause your mail connections to receive some SYNs and not be able to respond to them (so some TCP connections will remain embryonic), but that's better than having your SMTP server crash. > Perhaps a "reject hosts" database would be a useful addition > to the MX wish list ( if it isn't already there ). I know Hunter has it on his long list. :-) It'd be relatively easy to implement one simply based on the MAIL FROM: line that is received. More complex algorithms could be thought of, but rejecting certain MAIL FROM: would be a start. -Dan Wing dwing@tgv.com / dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Mon, 16 Sep 1996 16:41:39 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 16 Sep 1996 16:41:22 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8776.5B51D986.4@ALPHA.WKU.EDU> Subject: RE: re: lines longer than 255 chars Jim Bender writes: > >i.e, the message is intact until MX hands it off to VMS Mail, which >promptly drops everything after 255 chars. > >A way to have MX insert line breaks before giving the message to VMS mail >would solve this. > Yes, that's on the wish list as well. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Mon, 16 Sep 1996 21:53:34 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 16 Sep 1996 22:53:04 EST From: "Dennis P. Costello, CNF Systems Manager" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: costello@cnf.cornell.edu Message-ID: <009A87AA.48DBDE80.1325@cnf.cornell.edu> Subject: RE: lines longer than 255 chars >Was a consensus ever reached in the problem with VMS mail truncating lines >after 255 chars? A possible solution might involve the several following pieces: - replace Mail's Send command with SEND/EDIT Define a Symbol in SYS$MANAGER:SYLOGIN.COM $ mail :== mail /edit - Ensure that word-wrapping at a reasonable column (e.g., 78) takes place Ensure that everyone has an EDTINI file that includes the lines set mode change set wrap 78 and a TPU initialization or section file or whatever that includes set right 78 set wrap These last can be assured (well enough for those resistant to education, as they are the ones less likely to set logicals and so on) by creating a system logical EDTINI that points to a shared file, and similarly for TPU. We haven't done this system-wide, but one of my users has set himself up this way, so he has that much less to think about every time... and it works for him. Good luck, -d ***************************************************************************** CCCCCCCCC NNNNN NNN FFFFFFFFF Dennis Costello, CCP CCC NNNNNN NNN FFF Computer Systems Manager CCC NNN NN NNN FFFFFFFFF Cornell Nanofabrication Facility CCC NNN NNNN FFF Knight Laboratory Cornell University CCCCCCCCC NNN NN FFF Ithaca, New York 14853-5403 Voice (607)-255-2329 ext 112 FAX (607)-255-8601 On the Web at http://www.cnf.cornell.edu/ email: costello@cnf.cornell.edu ***************************************************************************** ================================================================================ Archive-Date: Tue, 17 Sep 1996 03:48:00 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 17 Sep 1996 10:48:23 GMT1 From: tobiasz@delta.sggw.waw.pl Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A880E.360B57AE.27@delta.sggw.waw.pl> Subject: Re: string too long Hi ! >> Perhaps a "reject hosts" database would be a useful addition >>to the MX wish list ( if it isn't already there ). >> >Yes, that's on the wish list.... when talking about wishes ... I would like to restrict my SMTP server to accept relaying mails from MUAs (like Netscape, Eudora etc) only from my domain/specific hosts/nets. Don't know how it conforms to RFCs. Another wish - I would like to restict max mail size user may send via MX or size of mail MX smtp server accepts. I know it is one of ESMTP features. Best regards Jacek Tobiasz ================================================================================ Archive-Date: Tue, 17 Sep 1996 11:05:10 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 17 Sep 1996 11:04:27 CST From: hunterl@uwwvax.uww.edu Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8810.74A0FCAB.26@uwwvax.uww.edu> Subject: Re: string too long => => $ MULTINET SET/ROUTE/ADD=(DESTINATION=ip,GATE=blah) => => Where "ip" is the IP address of the source mailer(s) you don't want to => accept mail from, and "blah" is some local IP address which is _not_ => a router. This will cause your mail connections to receive some SYNs => and not be able to respond to them (so some TCP connections will => remain embryonic), but that's better than having your SMTP server => crash. This solution has not worked for me., the message continues to return hourly. Is there something missing from the above? Lyle Hunter T & IR University Wisconsin-Whitewater hunterl@uwwvax.uww.edu ================================================================================ Archive-Date: Tue, 17 Sep 1996 12:07:01 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 17 Sep 1996 12:56:41 EDT From: "G. Del Merritt" Reply-To: MX-List@MadGoat.com To: MX-List@madgoat.com Message-ID: <009A8820.225FF4E9.40@intranet.com> Subject: Re: lines longer than 255 chars In-reply-to: "Hunter Goatley "'s message of 17-SEP-1996 09:46:32.28 >Jim Bender writes: >> >>Was a consensus ever reached in the problem with VMS mail truncating lines >>after 255 chars? >> : >The problem here, if I'm remembering correctly from when I looked into >this a couple of years ago, is that VMS Mail drops the text, so it >never makes it to MX. VMS Mail would have to be fixed to really solve >this problem (outgoing VMS mail). What is the possiblity of sending messages with "lines" longer than 1000 "characters" as /FOREIGN when they are to be processed by VMS Mail? The VMS receiver would just have to EXTRACT the message. Actually, I think bouncing such messages, clearly not conforming to the RFC, would be acceptable behavior, too. -- Del Merritt, ** del@IntraNet.com IntraNet, Inc., One Gateway Center #700, Newton, MA 02158 Voice: 617-527-7020; FAX: 617-527-1761 Just say no to Clipper. You may not add me to a commercial mailing list or send me commercial advertising without my consent. ================================================================================ Archive-Date: Tue, 17 Sep 1996 13:25:44 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 17 Sep 1996 13:25:52 -0500 (CDT) From: Cory Erickson Reply-To: MX-List@MadGoat.com To: MX-List@LISTS.WKU.EDU Subject: V4.2 problems with outgoing SMTP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am using an old VAX 4000/200 that I just upgraded the OS from A5.5-2 to 6.2, the Multinet to 3.5 and went up from MX V3.3 to V4.2. I am having a strange problem with outgoing SMTP mail. I can subscribe and make requests to the listserver with no problems (I get the requested info back), but if I send a message to a list, all DECNet users get it, but none of our SMTP Unix machines get it. When I look at the queue it shows: 56 INPROG 1886 SMTP SMTP 58 READY 1886 (waiting until 17-SEP-1996 13:36:19.51) 59 INPROG 1581 SMTP SMTP 60 READY 1581 (waiting until 17-SEP-1996 13:36:22.93) 61 INPROG 627 SMTP SMTP 62 READY 627 (waiting until 17-SEP-1996 13:36:31.04) It waits for the 30 minute retry period, tries again then bombs. Any suggestions? I am using MX for mail on the machine and that works fine as well. Thanks! Cory ericksco@mhd1.moorhead.msus.edu ================================================================================ Archive-Date: Tue, 17 Sep 1996 14:14:14 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 17 Sep 1996 14:13:59 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: ERICKSCO@MHD1.MOORHEAD.MSUS.EDU Message-ID: <009A882A.EF4F393F.4@ALPHA.WKU.EDU> Subject: RE: V4.2 problems with outgoing SMTP Cory Erickson writes: > >I am using an old VAX 4000/200 that I just upgraded the OS from A5.5-2 to >6.2, the Multinet to 3.5 and went up from MX V3.3 to V4.2. I am having a >strange problem with outgoing SMTP mail. I can subscribe and make requests >to the listserver with no problems (I get the requested info back), but if >I send a message to a list, all DECNet users get it, but none of our SMTP >Unix machines get it. When I look at the queue it shows: > > 56 INPROG 1886 SMTP > SMTP 58 READY 1886 > (waiting until 17-SEP-1996 The first thing to check is MCP SHOW QUEUE/FULL xxx so you can see what the actual error was that caused the retry. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Tue, 17 Sep 1996 15:12:05 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 17 Sep 1996 15:12:10 -0500 (CDT) From: Cory Erickson Reply-To: MX-List@MadGoat.com To: MX-List@LISTS.WKU.EDU Subject: Re: Outgoing SMTP problems V4.2.... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am a little confused by the following info sent to my postmaster which is at site mhd1.moorhead.msus.edu. MX is sending to everyone via SMTP now, and it is received by my host machine OK, but can't find the mailbox for the users I am sending to on Mhd1 (error 3?). I am REALLY confused how MX can't post a message to Mhd1, but knows enough to send an error message about it to the postmaster which resides at mhd1: From daemon Tue Sep 17 14:55:41 1996 Received: from mhd.moorhead.msus.edu by mhd1.moorhead.msus.edu; (5.65v3.2/1.1.8.2/09Oct95-1257PM) id AA23992; Tue, 17 Sep 1996 14:55:40 -0500 Message-Id: <9609171955.AA23992@mhd1.moorhead.msus.edu> Date: Tue, 17 Sep 1996 14:49:38 CST From: SMTP delivery agent To: Subject: SMTP delivery error X-Report-Type: Nondelivery; boundary="> Error description:" Status: RO X-Status: 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: owner-turbo@moorhead.msus.edu Error-Code: 2 Error-Text: %MX_SMTP-F-TRANSACTION_FAI, transaction failed -(Via MHD.MOORHEAD.MSUS.EDU) -Transcript: -Rcvd: 220 mhd.moorhead.msus.edu MX V4.2 VAX SMTP server ready at Tue, 17 Sep 1996 14:49:35 CST -Sent: HELO mhd.moorhead.msus.edu -Rcvd: 250 Hello, mhd.moorhead.msus.edu -Sent: MAIL FROM: -Rcvd: 250 MAIL command accepted. -Sent: RCPT TO: -Rcvd: 250 Recipient okay (at least in form) -Sent: DATA -Rcvd: 354 Start mail input; end with . -Rcvd: 554 Received too many times by this host. -Sent: QUIT -Rcvd: 221 mhd.moorhead.msus.edu Service closing transmission channel Error-End: 1 error detected ------------------------------ Rejected message ------------------------------ Received: from mhd.moorhead.msus.edu by mhd.moorhead.msus.edu (MX V4.2 VAX) with SMTP; Tue, 17 Sep 1996 14:49:33 CST Received: from mhd.moorhead.msus.edu by mhd.moorhead.msus.edu (MX V4.2 VAX) with SMTP; Tue, 17 Sep 1996 14:49:29 CST Received: from mhd.moorhead.msus.edu by mhd.moorhead.msus.edu (MX V4.2 VAX) with SMTP; Tue, 17 Sep 1996 14:49:25 CST Received: from mhd.moorhead.msus.edu by mhd.moorhead.msus.edu (MX V4.2 VAX) with SMTP; Tue, 17 Sep 1996 14:49:22 CST Date: Tue, 17 Sep 1996 14:49:15 CST From: SMTP delivery agent To: Subject: SMTP delivery error X-Report-Type: Nondelivery; boundary="> Error description:" Note: this message was generated automatically. An error was detected while processing the enclosed message. A list of the affected recipients follows. This list is in a special format that allows software like LISTSERV to automatically take action on incorrect addresses; you can safely ignore the numeric codes. --> Error description: Error-For: syssup@MHD1.MOORHEAD.MSUS.EDU Error-Code: 3 Error-Text: %MX_SMTP-F-MBX_UNAVAILABLE, action not taken: mailbox unavailable -(Via MHD1.MOORHEAD.MSUS.EDU) Error-For: fuchs@MHD1.MOORHEAD.MSUS.EDU Error-Code: 3 Error-Text: %MX_SMTP-F-MBX_UNAVAILABLE, action not taken: mailbox unavailable -(Via MHD1.MOORHEAD.MSUS.EDU) Error-For: ericksco@MHD1.MOORHEAD.MSUS.EDU Error-Code: 3 Error-Text: %MX_SMTP-F-MBX_UNAVAILABLE, action not taken: mailbox unavailable -(Via MHD1.MOORHEAD.MSUS.EDU) -Transcript: -Rcvd: 220 mhd1.moorhead.msus.edu Sendmail 5.65v3.2 (1.1.8.2/09Oct95-1257PM) Tue, 17 Sep 1996 14:55:13 -0500 -Sent: HELO mhd.moorhead.msus.edu -Rcvd: 250 mhd1.moorhead.msus.edu Hello mhd.moorhead.msus.edu, pleased to meet you -Sent: MAIL FROM: -Rcvd: 250 ... Sender ok -Sent: RCPT TO: -Rcvd: 250 ... Recipient ok -Sent: RCPT TO: -Rcvd: 250 ... Recipient ok -Sent: RCPT TO: -Rcvd: 250 ... Recipient ok -Sent: DATA -Rcvd: 354 Enter mail, end with "." on a line by itself -Rcvd: 550 owner-turbo@moorhead.msus.edu... User unknown -Sent: QUIT -Rcvd: 221 mhd1.moorhead.msus.edu closing connection Error-End: 1 error detected ------------------------------ Rejected message ------------------------------ X-ListName: TURBO@moorhead.msus.edu Warnings-To: <> Errors-To: owner-turbo@moorhead.msus.edu Sender: owner-turbo@moorhead.msus.edu Received: from mhd8.moorhead.msus.edu by mhd.moorhead.msus.edu (MX V4.2 VAX) with SMTP; Tue, 17 Sep 1996 14:49:08 CST Date: Tue, 17 Sep 1996 14:54:55 -0500 (CDT) From: CORY ERICKSON Reply-To: CORY ERICKSON To: turbo@mhd.moorhead.msus.edu Message-ID: <960917145455.1091@mhd8.moorhead.msus.edu> Subject: test from mhd8 test from mhd8 Thanks! Cory ericksco@mhd1.moorhead.msus.edu ================================================================================ Archive-Date: Wed, 18 Sep 1996 09:23:57 CST Sender: owner-mx-list@WKU.EDU Date: Wed, 18 Sep 1996 10:22:59 EDT From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: ericksco@mhd1.moorhead.msus.edu, hardis@garnet.nist.gov Message-ID: <009A88D3.D43103A0.4@garnet.nist.gov> Subject: Re: Outgoing SMTP problems V4.2.... > -Rcvd: 554 Received too many times by this host. This means that the same message has been received too many times by this host. Either it is being forwarded back and forth between two computers, or this one computer does not recognize the message as requiring local delivery, and it keeps sending it to itself. > Error-For: fuchs@MHD1.MOORHEAD.MSUS.EDU > Error-Text: %MX_SMTP-F-MBX_UNAVAILABLE, action not taken: mailbox unavailable This means that there is no userid "fuchs" at the computer MHD1.MOORHEAD.MSUS.EDU . Since Moorhead is running Sendmail, I will guess that its OS is Unix. On Unix systems, user names are case sensitive. - Jonathan ================================================================================ Archive-Date: Wed, 18 Sep 1996 12:58:01 CST Sender: owner-mx-list@WKU.EDU From: dwing@tgv.com ("Dan Wing") Subject: RE: string too long Date: 18 Sep 1996 17:37:14 GMT Message-ID: <51pc0a$7b0@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <009A875D.EB744EC7.91@uwwvax.uww.edu>, hunterl@uwwvax.uww.edu writes: > If any one discovers the source, please share it. I am been > unsuccessful in tracking it down since this morning. If you're running MultiNet, you can use something like this to help track it down. Put the following into a batch job and stop the batch job when you notice the MX SMTP process dies: $ SET PROCESS/PRIVILEGE=SYSPRV $ MULTINET TCPDUMP/WRITE_BINARY=filename/SNAP=1514 HOST myhost AND DST PORT 25 Where "myhost" is the IP address of your VMS box. Then, when you've had the MX SMTP process die, you can analyze the TCPDUMP via: $ MULTINET TCPDUMP/READ_BINARY=filename/SNAP=1514/HEX/AFTER=time Where "time" is a few minutes before the MX SMTP process died (you can get the time it died from VMS accounting). Hope that helps, -Dan Wing dwing@tgv.com / dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Wed, 18 Sep 1996 20:43:56 CST Sender: owner-mx-list@WKU.EDU Date: Thu, 19 Sep 1996 11:49:19 EDT From: Daiajo Tibdixious MACS <"svs::svist070"@svs6pub.svh.unsw.EDU.AU> Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A89A9.0E7A1080.7@svs6pub.svh.unsw.EDU.AU> Subject: Re: Outgoing SMTP problems V4.2.... Wed, 18 Sep 1996 10:22:59 "Jonathan E. Hardis" >> -Rcvd: 554 Received too many times by this host. >This means that the same message has been received too many times by this >host. Either it is being forwarded back and forth between two computers, >or this one computer does not recognize the message as requiring local >delivery, and it keeps sending it to itself. I get this a lot here. I've tracked it down to when an outbound error occurs, it tries to bounce the message back to the sender. If the return address has something wrong with it (which is common with Eurdora), the message goes around and around, alternating betwen VMSmail and MXmail due to forwarding. ================================================================================ Archive-Date: Thu, 19 Sep 1996 03:37:36 CST Sender: owner-mx-list@WKU.EDU Message-ID: <1.5.4.16.19960919083527.5aa7bfae@agate.actfs.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Sep 1996 09:35:27 +0100 To: MX-List@MadGoat.com From: John Rourke Reply-To: MX-List@MadGoat.com Subject: Re: Outgoing SMTP problems V4.2.... At 11:49 19/09/96 EDT, you wrote: >Wed, 18 Sep 1996 10:22:59 "Jonathan E. Hardis" >>> -Rcvd: 554 Received too many times by this host. >>This means that the same message has been received too many times by this >>host. Either it is being forwarded back and forth between two computers, >>or this one computer does not recognize the message as requiring local >>delivery, and it keeps sending it to itself. > >I get this a lot here. I've tracked it down to when an outbound error occurs, >it tries to bounce the message back to the sender. If the return address has >something wrong with it (which is common with Eurdora), the message goes around >and around, alternating betwen VMSmail and MXmail due to forwarding. >--------------------------------------------------------------------------- ----- >Received: from gateway.actfs.co.uk ([97.25.10.11]) by agate.actfs.co.uk (MX > V4.1 AXP) with SMTP; Thu, 19 Sep 1996 03:11:53 BST >Received: from WKUVX1.WKU.EDU by gateway.actfs.co.uk (MX V4.1 VAX) with SMTP; > Thu, 19 Sep 1996 03:11:45 BST > > ================================================================================ Archive-Date: Thu, 19 Sep 1996 13:10:21 CST Sender: owner-mx-list@WKU.EDU From: dwing@tgv.com ("Dan Wing") Subject: Re: string too long Date: 19 Sep 1996 17:59:22 GMT Message-ID: <51s1lq$909@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <009A8810.74A0FCAB.26@uwwvax.uww.edu>, hunterl@uwwvax.uww.edu writes: > => > => $ MULTINET SET/ROUTE/ADD=(DESTINATION=ip,GATE=blah) > => > => Where "ip" is the IP address of the source mailer(s) you don't want to > => accept mail from, and "blah" is some local IP address which is _not_ > => a router. This will cause your mail connections to receive some SYNs > => and not be able to respond to them (so some TCP connections will > => remain embryonic), but that's better than having your SMTP server > => crash. > This solution has not worked for me., the message continues to return > hourly. Is there something missing from the above? Check your routing tables to make sure that host "blah" (that you specified) didn't update your routing tables for you via an ICMP redirect. If it did, pick a different host "blah" that won't send you an ICMP redirect (a PC is a good bet -- most PC stacks don't know how to do that) or simply pick an unused IP address on your local network. If you have a black-hole route (which prevents TCP connection from being established with the remote host) there is _no way_ your MX SMTP Server process can be crashed, as your application (MX SMTP Server) is never handed the connection (nor the data). You can also try blocking the entire network the connections are coming from -- they may have a few different outgoing mailers and you're getting a connection from a different on than you're blocking. -Dan Wing dwing@tgv.com / dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Thu, 19 Sep 1996 17:04:08 CST Sender: owner-mx-list@WKU.EDU Date: Thu, 19 Sep 1996 17:04:16 -0500 (CDT) From: Cory Erickson Reply-To: MX-List@MadGoat.com To: MX-List@LISTS.WKU.EDU CC: "Bryan G. Kotta" Subject: more problems with V4.2 talking SMTP to Digital Unix... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hello, I posted earlier about my VAX 4000/200 running VMS 6.2 and V4.2 MX having problems talking SMTP. Well with the help of the list I have narrowed down the search a little. MX is working fine sending to a VAX 4000/90 VMS 6.0, an Ultrix DEC 5000/240, and a NeXT Step Pentium, but just not to our main user machine, a '95 model 2100 DEC Alpha 5/250 running Digital Unix. The debug run on SMTP brings up the following: 19-SEP-1996 16:26:39.07 Recipient: , route=MHD1.MOORHEAD.MSUS.EDU 19-SEP-1996 16:26:39.07 SMTP_SEND: looking up host name MHD1.MOORHEAD.MSUS.EDU 19-SEP-1996 16:26:39.10 SMTP_SEND: DNS_MXLOOK status is 00000001 19-SEP-1996 16:26:39.14 SMTP_SEND: Attempting to start session with MHD1.MOORHEAD.MSUS.EDU [199.17.81.1] 19-SEP-1996 16:26:39.15 SMTP_SEND: Connected 19-SEP-1996 16:26:39.39 SMTP_SEND: Rcvd: 220 mhd1.moorhead.msus.edu Sendmail 5.65v3.2 (1.1.8.2/09Oct95-1257PM) Thu, 19 19-SEP-1996 16:26:39.52 SMTP_SEND: Sent: HELO mhd.moorhead.msus.edu 19-SEP-1996 16:26:39.53 SMTP_SEND: Rcvd: 250 mhd1.moorhead.msus.edu Hello mhd.moorhead.msus.edu, pleased to meet you 19-SEP-1996 16:26:39.53 SMTP_SEND: Sent: MAIL FROM: 19-SEP-1996 16:26:39.71 SMTP_SEND: Rcvd: 250 ... Sender ok 19-SEP-1996 16:26:39.76 SMTP_SEND: Sent: RCPT TO: 19-SEP-1996 16:26:39.77 SMTP_SEND: Rcvd: 250 ... Recipient ok 19-SEP-1996 16:26:39.80 SMTP_SEND: Sent: DATA 19-SEP-1996 16:26:39.86 SMTP_SEND: Rcvd: 354 Enter mail, end with "." on a line by itself ..... ..... 19-SEP-1996 16:26:39.99 SMTP_SEND: Sent: . 19-SEP-1996 16:26:39.99 SMTP_SEND: will wait 00:12:00.00 for reply. 19-SEP-1996 16:26:40.49 SMTP_SEND: Rcvd: 550 owner-turbo@moorhead.msus.edu... User unknown ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ??? 19-SEP-1996 16:26:40.49 SMTP_SEND: Sent: QUIT 19-SEP-1996 16:26:40.50 SMTP_SEND: Rcvd: 221 mhd1.moorhead.msus.edu closing connection 19-SEP-1996 16:26:40.61 SMTP send failed, sts=0C268094, sts2=0C268094 19-SEP-1996 16:26:40.61 Recipient status=0C268094 for It seems like mhd1 (AlphaServer) is trying to check to see if owner-turbo@moorhead.msus.edu exists before it sends mail to users on that box? Is this a Digital Unix problem or an MX problem? Thanks! Cory ericksco@mhd1.moorhead.msus.edu ================================================================================ Archive-Date: Thu, 19 Sep 1996 22:11:01 CST Sender: owner-mx-list@WKU.EDU Date: Thu, 19 Sep 1996 22:10:43 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: ERICKSCO@MHD1.MOORHEAD.MSUS.EDU, KOTTA@MHD1.MOORHEAD.MSUS.EDU Message-ID: <009A89FF.DD0ED6FF.17@ALPHA.WKU.EDU> Subject: RE: more problems with V4.2 talking SMTP to Digital Unix... Cory Erickson writes: > >I posted earlier about my VAX 4000/200 running VMS 6.2 and V4.2 MX having >problems talking SMTP. Well with the help of the list I have narrowed >down the search a little. MX is working fine sending to a VAX 4000/90 VMS >6.0, an Ultrix DEC 5000/240, and a NeXT Step Pentium, but just not to our >main user machine, a '95 model 2100 DEC Alpha 5/250 running Digital Unix. >The debug run on SMTP brings up the following: > [...] >19-SEP-1996 16:26:39.53 SMTP_SEND: Sent: MAIL >FROM: [...] >19-SEP-1996 16:26:40.49 SMTP_SEND: Rcvd: 550 >owner-turbo@moorhead.msus.edu... User unknown >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ??? I have no idea why it would be taking the MAIL FROM: address and trying to verify it. >It seems like mhd1 (AlphaServer) is trying to check to see if >owner-turbo@moorhead.msus.edu exists before it sends mail to users on that >box? Is this a Digital Unix problem or an MX problem? > Sounds to me like a sendmail config problem on the Digital UNIX box. It's certainly not MX's problem. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Fri, 20 Sep 1996 05:41:39 CST Sender: owner-mx-list@WKU.EDU Date: Fri, 20 Sep 96 12:41:04 T1W From: Alain Messin Reply-To: MX-List@MadGoat.com Subject: que stat entries keep increasing To: mx-list@wkuvx1.wku.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Vax 3100-30, running YMS 5.5-2 and MX V4.0-1. QUE SH display 0 entries but all messages are not deleted and stay in directories QUE STAT display 356/5002 Highest entry used 360 and go on increasing until queue is full I must do queue/compress from time to time. I happened to see a similar problem on this list about one year ago but I did'nt catch the answer. Alain Messin ---------------------------------------------------------------- Observatoire de la Cote d'Azur/ Alain Messin Avenue Copernic 06130 GRASSE FRANCE Telephone: 33(0) 4 93 40 53 61 Fax:33(0) 4 93 40 53 33 E-mail: Date: 20/09/1996 Time: 09:14:22 -------------------------------------------- ================================================================================ Archive-Date: Fri, 20 Sep 1996 09:39:43 CST Sender: owner-mx-list@WKU.EDU Date: Fri, 20 Sep 1996 10:36:42 EST5EDT4,M4.1.0,M10.5.0 From: Scott McNeilly Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8A68.13A8C320.98@fred.bridgew.edu> Subject: RE: que stat entries keep increasing >From: Alain Messin > >On Vax 3100-30, running YMS 5.5-2 and MX V4.0-1. > >QUE SH display 0 entries >but all messages are not deleted and stay in directories >QUE STAT display 356/5002 Highest entry used 360 >and go on increasing until queue is full > >I must do queue/compress from time to time. > >I happened to see a similar problem on this list about one year >ago but I did'nt catch the answer. > You might want to try automatic purging of finished entries. It works for us. Use the following command: $ DEFINE/SYSTEM/EXEC MX_FLQ_AUTOPURGE_FIN TRUE See section 6.4 in the MX Management Guide for more details. -------------------------------------------------------------------- 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: Fri, 20 Sep 1996 11:49:31 CST Sender: owner-mx-list@WKU.EDU Date: Fri, 20 Sep 1996 12:49:03 EST From: "Henry A. Frystak - System Manager" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: syshaf@tesla.njit.edu Message-ID: <009A8A7A.90B3C308.55@tesla.njit.edu> Subject: RE: que stat entries keep increasing >Subj: que stat entries keep increasing > >On Vax 3100-30, running YMS 5.5-2 and MX V4.0-1. >QUE SH display 0 entries >but all messages are not deleted and stay in directories >QUE STAT display 356/5002 Highest entry used 360 >and go on increasing until queue is full >I must do queue/compress from time to time. >I happened to see a similar problem on this list about one year >ago but I did'nt catch the answer. > >Alain Messin Since I believe I am the originator of the "similar problem" referred to above, I will try to relate what I found out and what I ended up doing. This is on VMS 5.5-2 using Multinet 3.4B and MX 4.1 . My site had been "off the air" for a period of time, and I knew that when I opened the mail "flood gates" I would be inundated with large quantities of queued up messages (we are an educational site and have many subscribers of listserves as well as large amounts of research e-mails going all over the world). I had wanted to purge finished queue entries sooner than normal but not immediately, such as setting the logical name MX_FLQ_AUTOPURGE_FIN to TRUE would do, so that I could do some manual monitoring of the mail flowing in. There is another logical name MX_FLQ_PURGE_WAIT which can be set for the amount of time a finished queue entry should remain in the queue; according to the MX Management Guide Table 6-1 the default wait time is 15 min. (unless a manual MCP QUEUE PURGE command is done). Since I wanted about a 5 min. delay, I promptly set the logical to "5" and issued the MCP RESET ROUTER,FLQ command. That's when my problems started. As you said, queue entries stay around when finished until a manual MCP QUEUE PURGE command is issued, or the logical MX_FLQ_AUTOPURGE_FIN is set to TRUE. Since this was late at night and I had just spent approx. 24 hours rebuilding the disk (it had had a crash and had to be swapped out and rebuilt from backups), I set the AUTOPURGE logical, verified that it would at least keep me working, and went home for much needed sleep. It was not until a few days later that when reading section 6.3 of the MX Management Guide that I saw the time format for the MX_FLQ_PURGE_WAIT logical. Apparently, with the incorrect format, crazy things like no purging of finished entries occurred (Hunter, perhaps you could provide more insight about this). Even after removing the MX_FLQ_PURGE_WAIT logical (and the MX_FLQ_AUTOPURGE_FIN logical) and doing the MCP RESET ROUTER,FLQ command, I still had wierd problems (such as mail which refused to go offsite via smtp, and other misc. queue abnormalities). The only solution to the problem which I found, was to shutdown MX completely, remove all non-standard MX logicals (like the MX_FLQ_PURGE_WAIT, MX_FLQ_AUTOPURGE_FIN, and any other debugging logicals), build a new queue file with MCP, and then restart MX. After a little manual cleanup of leftover files in the MX_FLQ_DIR directory tree, all again appears sane. Hunter, as a wish list suggestion, how about an added command(s) to the MCP program, to display routine things like queue check wait interval, queue purge wait interval, wakeups intervals, and possibly showing any overridden params and how they were overridden (config. option or logical def.). Also possibly showing any debugging options which have been activated by logical defs. Henry Frystak New Jersey Institute of Technology System Administrator Academic Computing Department VAX/VMS USENET Newsmanager University Heights TESLA::SYSHAF Newark, New Jersey 07102 syshaf@tesla.njit.edu ================================================================================ Archive-Date: Fri, 20 Sep 1996 12:07:23 CST Sender: owner-mx-list@WKU.EDU Date: Fri, 20 Sep 1996 12:07:16 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8A74.BA9A6CD1.1@ALPHA.WKU.EDU> Subject: RE: que stat entries keep increasing "Henry A. Frystak - System Manager" writes: > >My site had been "off the air" for a period of time, and I knew that when I >opened the mail "flood gates" I would be inundated with large quantities of >queued up messages (we are an educational site and have many subscribers of Situations like this do seem to overwhelm MX's ability to keep up, though I'm not 100% sure why that is yet. >Apparently, with the incorrect format, crazy things like no purging of finished >entries occurred (Hunter, perhaps you could provide more insight about this). Yep, I think now I may have found the real problem. The FLQ Cleanup code checks for the existence of the logicals, but doesn't check for errors on the $BINTIM calls to convert them to system internal time format. If those logical name values aren't valid time strings, it looks like that would definitely cause some problems. I'll fix that for the next release. Good call! >Hunter, as a wish list suggestion, how about an added command(s) to the MCP >program, to display routine things like queue check wait interval, queue purge >wait interval, wakeups intervals, and possibly showing any overridden params >and how they were overridden (config. option or logical def.). Also possibly >showing any debugging options which have been activated by logical defs. > I'll add that to the ever-growing wish list. Anybody know of some philanthropist or philanthropic company who'll pay me money to spend my time on MX and other freeware? ;-) Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Fri, 20 Sep 1996 12:24:14 CST Sender: owner-mx-list@WKU.EDU From: "Robert H. McClanahan" To: MX-List@MadGoat.com Date: Fri, 20 Sep 1996 12:22:53 -0500 Subject: RE: que stat entries keep increasing Reply-To: MX-List@MadGoat.com On 20 Sep 96 at 10:36, Scott McNeilly wrote: > >From: Alain Messin > > > >QUE SH display 0 entries > >but all messages are not deleted and stay in directories > >QUE STAT display 356/5002 Highest entry used 360 > >and go on increasing until queue is full > > > >I must do queue/compress from time to time. > > > You might want to try automatic purging of finished entries. It works for > us. Use the following command: > $ DEFINE/SYSTEM/EXEC MX_FLQ_AUTOPURGE_FIN TRUE > > See section 6.4 in the MX Management Guide for more details. I, too, ahve the same problem as the original poster. I hate to enable auto purging of entries, because I am often amazed at how much easier is is to troubleshoot mail problems having the finished entries hang around for 15 minutes or so after completion. Is there no other way to make the queue files go away? RHM +--+ Robert H. McClanahan, Mgr, Tech Info Systems, rmcclanahan@tis.aecc.com <[]>< Arkansas Electric Coop Corp, PO Box 194208, Little Rock, AR 72219-4208 USA "If I find in myself a desire which no experience in this world can satisy, the most probable explanation is that I was made for another world." C.S. Lewis ================================================================================ Archive-Date: Fri, 20 Sep 1996 14:03:08 CST Sender: owner-mx-list@WKU.EDU Date: Fri, 20 Sep 1996 15:02:43 EDT From: netmgr@bigvax.alfred.edu Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: netmgr@bigvax.alfred.edu Message-ID: <009A8A8D.3D007194.210@bigvax.alfred.edu> Subject: RE: que stat entries keep increasing Hunter Goatley writes: >"Henry A. Frystak - System Manager" writes: >> >>My site had been "off the air" for a period of time, and I knew that when I >>opened the mail "flood gates" I would be inundated with large quantities of >>queued up messages (we are an educational site and have many subscribers of > >Situations like this do seem to overwhelm MX's ability to keep up, >though I'm not 100% sure why that is yet. I've seen this too. When my queue gets up to about 5000 entries, even a directory command on a single file in one of the the queue sub-directories may take several seconds while it waits for a lock. Faster hardware might help. I'm running a cluster of mostly VAX 6410s and RA90 disks. I believe it is because VMS is brain dead about the way it removes directory entries when deleting files. If it empties out a block, it rewrites the rest of the directory to close up the space. But it does so one block at a time, waiting for each write to finish before starting the next. (The reasons why it does that sound good on paper, but it causes more trouble than it prevents.) This takes a very long time when directories get huge. Having 10 sub-directores helps keep them small enough, but I think 100 (or a user configurable number) would help more. Other things that would help are shorter extensions on the *.*_info files. Or instead of deleting them when done, truncate them to 0 blocks and rename them to *.empty, then when creating an entry recycle the *.empty file if it exists. Naturally this would be messy, especially for the router entries which have multiple files. My workaround when the problem comes up is to create a new queue directory and queue, and redefine the logical MX_FLQ_DIR and restart the processes on all nodes in the cluster except one. The node with the old queue gets a router and some local and some outgoing smtp processes, but no smtp_server, and interactive logins are discouraged so nobody will be adding more messages to that queue. After several days it will catch up. Then switch the last node to the new queue, and delete the old queue. Jim Walker VAX System & Network manager, Alfred University Computer Center, Alfred, NY 14802-1298 USA +1-607-871-2222, Using VMS V6.1 Unsolicited junk mail is not welcome. ================================================================================ Archive-Date: Fri, 20 Sep 1996 14:09:49 CST Sender: owner-mx-list@WKU.EDU Date: Fri, 20 Sep 1996 14:09:33 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8A85.D016BB6C.21@ALPHA.WKU.EDU> Subject: RE: que stat entries keep increasing netmgr@bigvax.alfred.edu writes: > >I've seen this too. When my queue gets up to about 5000 >entries, even a directory command on a single file in one of >the the queue sub-directories may take several seconds while >it waits for a lock. Faster hardware might help. I'm running >a cluster of mostly VAX 6410s and RA90 disks. > Yes, I meant to mention that---faster disks would certainly help MX along..... >This takes a very >long time when directories get huge. Having 10 >sub-directores helps keep them small enough, but I think 100 >(or a user configurable number) would help more. > This feature may be in the next release. It was implemented a while back, but I think it was hardcoded at 100 and I've never gotten around to making it configuratble. >Other things that would help are shorter extensions on the >*.*_info files. Or instead of deleting them when done, >truncate them to 0 blocks and rename them to *.empty, then >when creating an entry recycle the *.empty file if it >exists. Naturally this would be messy, especially for the >router entries which have multiple files. > Yep. >My workaround when the problem comes up is to create a new >queue directory and queue, and redefine the logical >MX_FLQ_DIR and restart the processes on all nodes in the >cluster except one. The node with the old queue gets a >router and some local and some outgoing smtp processes, but >no smtp_server, and interactive logins are discouraged so >nobody will be adding more messages to that queue. After >several days it will catch up. Then switch the last node >to the new queue, and delete the old queue. > Thanks for posting that; that, too, is an option. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Fri, 20 Sep 1996 18:57:55 CST Sender: owner-mx-list@WKU.EDU Subject: Re: que stat entries keep increasing Message-ID: From: levitte@lp.se (Richard Levitte - VMS Whacker) Reply-To: MX-List@MadGoat.com Date: 21 Sep 1996 01:53:48 GMT To: MX-List@WKUVX1.WKU.EDU In article <009A8A74.BA9A6CD1.1@ALPHA.WKU.EDU> Hunter Goatley writes: Anybody know of some philanthropist or philanthropic company who'll pay me money to spend my time on MX and other freeware? ;-) If you find out, give me a pointer. Hell, I'd love to be able to hack on the GNU on VMS project and the Free-VMS project full time and getting payed for it :-). -- R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN Tel: +46-8-26 52 47, (via nation.se) +46-8-728 20 33; 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: Sat, 21 Sep 1996 13:09:54 CST Sender: owner-mx-list@WKU.EDU From: dwing@tgv.com ("Dan Wing") Subject: Re: more problems with V4.2 talking SMTP to Digital Unix... Date: 21 Sep 1996 17:54:15 GMT Message-ID: <521a47$62a@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article , Cory Erickson writes: > 19-SEP-1996 16:26:39.99 SMTP_SEND: Sent: . > 19-SEP-1996 16:26:39.99 SMTP_SEND: will wait 00:12:00.00 for reply. > 19-SEP-1996 16:26:40.49 SMTP_SEND: Rcvd: 550 > owner-turbo@moorhead.msus.edu... User unknown > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ??? > 19-SEP-1996 16:26:40.49 SMTP_SEND: Sent: QUIT > 19-SEP-1996 16:26:40.50 SMTP_SEND: Rcvd: 221 mhd1.moorhead.msus.edu > closing connection > 19-SEP-1996 16:26:40.61 SMTP send failed, sts=0C268094, sts2=0C268094 > 19-SEP-1996 16:26:40.61 Recipient status=0C268094 for > > > It seems like mhd1 (AlphaServer) is trying to check to see if > owner-turbo@moorhead.msus.edu exists before it sends mail to users on that > box? Is this a Digital Unix problem or an MX problem? It is a Digital Unix problem. Try sending to user root@alphaserver and see if that works. -Dan Wing dwing@tgv.com / dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Mon, 23 Sep 1996 11:03:19 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 23 Sep 96 17:32:55 T1W From: Alain Messin Reply-To: MX-List@MadGoat.com Subject: Re: que stat entries keep increasing To: mx-list@wkuvx1.wku.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII many thanks to the list! I had to shutdown MX, mcp> que create,(queue compress is not sufficient) purge old files, and then restart MX.And now everything is ok (or seems to be!). -------------------------------------------- Alain Messin : Observatoire de la Cote d'Azur Avenue Copernic 06130 Grasse FRANCE Telephone: 33(0) 4 93 40 53 61 Fax:33(0) 4 93 40 53 33 E-mail: Date: 23/09/1996 Time: 17:46:00 -------------------------------------------- ================================================================================ Archive-Date: Mon, 23 Sep 1996 11:13:47 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 23 Sep 1996 11:13:33 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8CC8.B8F0EAEE.5@ALPHA.WKU.EDU> Subject: Re: que stat entries keep increasing Alain Messin writes: > >many thanks to the list! > >I had to shutdown MX, mcp> que create,(queue compress is not >sufficient) purge old files, and then restart MX.And now >everything is ok (or seems to be!). > FWIW, I have found an actual bug in the FLQ_PURGE routine that *could* be responsible for these problems. It's basically a memory leak that could cause the routine to stop purging entries (and deleting files). This, too, will be fixed in the next release of MX. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Mon, 23 Sep 1996 11:34:16 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 23 Sep 1996 18:10:58 +0100 Message-ID: <96092318105818@ecn01.ec-nantes.fr> From: Claude.Erbacher@ec-nantes.fr (C. ERBACHER - Centrale Nantes - Tel : 40 37 16 26) Reply-To: MX-List@MadGoat.com To: MX-List@wku.edu Subject: possibility to switch messages when a host is down ? Hello, All the messages incomming and outgoing my domain are managed on a mailhost with MX sofware, and all is good running (thank for thes authors of this software). Now, in my domain, there is a host who is down, and MX is keeping the messages for the users of this host. Is there a matter to switch this messages, by giving a new username on a new host when the messages are already in the mcp queue ? A other question : is there a possibility to customize the postmaster error message, or to add a specific message at the end of the postmaster error message, without to write it in the code and recompile the package ? Thank, for help, Claude ERBACHER ================================================================================ Archive-Date: Mon, 23 Sep 1996 11:37:39 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 23 Sep 1996 11:37:29 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8CCC.1080A341.12@ALPHA.WKU.EDU> Subject: RE: possibility to switch messages when a host is down ? Claude.Erbacher@ec-nantes.fr (C. ERBACHER - Centrale Nantes - Tel : writes: > > All the messages incomming and outgoing my domain are managed on a >mailhost with MX sofware, and all is good running (thank for thes authors >of this software). > > Now, in my domain, there is a host who is down, and MX is keeping >the messages for the users of this host. Is there a matter to switch this >messages, by giving a new username on a new host when the messages are >already in the mcp queue ? > No, there's no way in MCP to do that. You could use PATHs to redirect mail for a certain host to another host, but it would have to know what to do with the message (for example, you define a PATH for host A to be delivered to B, then MCP RESET the original Router entries to have things sent to the node B). > A other question : is there a possibility to customize the postmaster >error message, or to add a specific message at the end of the postmaster >error message, without to write it in the code and recompile the package ? > No, that's not site-customizable without recompiling, though I agree that it would be nice for it to be changeable.... Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Mon, 23 Sep 1996 14:27:26 CST Sender: owner-mx-list@WKU.EDU From: "David Murray" To: mx-list@madgoat.com Date: Mon, 23 Sep 1996 15:26:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Mail Headers Reply-To: MX-List@MadGoat.com I've been a perpetual lurker for a while, but haven't posted anything in recent memory, so if I haven't said it before, thanks to Hunter and friends for the most excellent product. I have been having a problem reading MIME attachements downloaded by IUPOP3 to Pegasus. It seems that my problem was an extra blank line in the message, and Pegasus thought that was where the headers ended. I modified IUPOP3 to strip this blank line out, but I was wondering if there was a more elegant fix (since I just broke local messages). The problem (as I see it) is that VMS mail inserts a blank line to separate the VMS header from the body of the message. Unfortunately, it does not recognize that there are SMTP headers following it. According to RFC822, the first null line denotes the end of the headers, so Pegasus is interpreting it correctly. Am I correct in assuming the VMS mail is the culprit? Is there a DEC patch for this problem? Thanks for any input. David N. Murray | PDS Sr. Software Engineer | 670 Sentry Parkway 610/828-4294 | Blue Bell, PA 19422 dmurray@pdssoftware.com | ================================================================================ Archive-Date: Mon, 23 Sep 1996 15:13:44 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 23 Sep 1996 15:13:25 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8CEA.3B3596B4.25@ALPHA.WKU.EDU> Subject: RE: Mail Headers "David Murray" writes: > >The problem (as I see it) is that VMS mail inserts a blank line to >separate the VMS header from the body of the message. Unfortunately, >it does not recognize that there are SMTP headers following it. >According to RFC822, the first null line denotes the end of the >headers, so Pegasus is interpreting it correctly. > >Am I correct in assuming the VMS mail is the culprit? Is there a DEC >patch for this problem? > When you compile IUPOP3, you must select the option to remove VMS Mail headers.... Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Tue, 24 Sep 1996 01:49:44 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 24 Sep 1996 08:36:34 +0100 Message-ID: <96092408363415@ecn01.ec-nantes.fr> From: Claude.Erbacher@ec-nantes.fr (C. ERBACHER - Centrale Nantes - Tel : 40 37 16 26) Reply-To: MX-List@MadGoat.com To: MX-List@madgoat.com Subject: Re: possibility to switch messages when a host is down ? |> |> Now, in my domain, there is a host who is down, and MX is keeping |>the messages for the users of this host. Is there a matter to switch this |>messages, by giving a new username on a new host when the messages are |>already in the mcp queue ? |> |No, there's no way in MCP to do that. You could use PATHs to redirect |mail for a certain host to another host, but it would have to know |what to do with the message (for example, you define a PATH for host A |to be delivered to B, then MCP RESET the original Router entries to |have things sent to the node B). And is there a matter to make the messages for the users of the host who is down in state 'holding' in the MX queue ? So MCP does not retry every 30 minutes, and when the host will be OK, the messages will be released for processing by making them in state 'no holding' ? Claude ERBACHER ================================================================================ Archive-Date: Tue, 24 Sep 1996 06:03:16 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 24 Sep 1996 06:03:09 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8D66.8675E4B3.1@ALPHA.WKU.EDU> Subject: Re: possibility to switch messages when a host is down ? Claude.Erbacher@ec-nantes.fr (C. ERBACHER - Centrale Nantes - Tel : writes: > > And is there a matter to make the messages for the users of the host >who is down in state 'holding' in the MX queue ? So MCP does not retry every >30 minutes, and when the host will be OK, the messages will be released for >processing by making them in state 'no holding' ? > No, but that too is on the ever-growing wish list.... Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Tue, 24 Sep 1996 07:46:42 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 24 Sep 1996 14:35:03 GMT Message-ID: <96092414350325@ecn02.ec-nantes.fr> From: Claude.Erbacher@ec-nantes.fr (C. ERBACHER - Centrale Nantes - Tel : 40 37 16 26) Reply-To: MX-List@MadGoat.com To: MX-List@madgoat.com Subject: other wish for the ever-growing wish list Please could you say me if the support of Extented SMTP protocol (ESMTP) and MIME would be possible in a future release of MX ? If yes, in how many time ? Best regards, Claude ERBACHER ================================================================================ Archive-Date: Tue, 24 Sep 1996 08:01:39 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 24 Sep 1996 09:00:53 EDT From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: dmurray@pdssoftware.com, goathunter@MadGoat.com, hardis@garnet.nist.gov Message-ID: <009A8D7F.5ADC6FC0.7@garnet.nist.gov> Subject: RE: Mail Headers >> I have been having a problem reading MIME attachements downloaded by >> IUPOP3 to Pegasus. It seems that my problem was an extra blank line >> in the message, and Pegasus thought that was where the headers ended. >> I modified IUPOP3 to strip this blank line out, but I was wondering >> if there was a more elegant fix (since I just broke local messages). > When you compile IUPOP3, you must select the option to remove > VMS Mail headers.... [and that, specifically refering to IGNORE_MAIL11_HEADERS] The first time a user complained about this to me on my system was last Friday. The problem is that I'm running CMU/TEK TCP/IP, and that puts me back to the specially modified version 1.7 of IUPOP3. The IGNORE_MAIL11_HEADERS flag wasn't introduced until version 1.8. Presuming that I might have the time to tackle this, where might I find the documentation on programming to NETLIB? My fantasy is that the transformation from 1.7 to 1.7-CMU was simple enough that the same might be applied to 1.8. If that's true, then making it universal with NETLIB has additional value. - Jonathan ================================================================================ Archive-Date: Tue, 24 Sep 1996 08:04:04 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 24 Sep 1996 09:03:21 EDT From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: hardis@garnet.nist.gov Message-ID: <009A8D7F.B2B04320.4@garnet.nist.gov> Subject: Re: possibility to switch messages when a host is down ? >> And is there a matter to make the messages for the users of the host >> who is down in state 'holding' in the MX queue ? So MCP does not retry every >> 30 minutes, and when the host will be OK, the messages will be released for >> processing by making them in state 'no holding' ? > No, but that too is on the ever-growing wish list.... $ MCP QUEUE READY wouldn't do this? - Jonathan ================================================================================ Archive-Date: Tue, 24 Sep 1996 08:11:59 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 24 Sep 1996 08:11:51 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8D78.813BD8A1.2@ALPHA.WKU.EDU> Subject: Re: possibility to switch messages when a host is down ? "Jonathan E. Hardis" writes: > >>> And is there a matter to make the messages for the users of the host >>> who is down in state 'holding' in the MX queue ? So MCP does not retry every >>> 30 minutes, and when the host will be OK, the messages will be released for >>> processing by making them in state 'no holding' ? > >> No, but that too is on the ever-growing wish list.... > >$ MCP QUEUE READY wouldn't do this? > It'll retry the delivery, but I interpreted the question as, "Is there a way to mark those entries as "HOLD" until such time as the remote system is available." QUEUE READY will cause the retry at that time, but it won't let you mark an entry as held. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Tue, 24 Sep 1996 09:18:05 CST Sender: owner-mx-list@WKU.EDU From: "Robert H. McClanahan" To: MX-List@MadGoat.com Date: Tue, 24 Sep 1996 09:16:48 -0500 Subject: RE: Mail Headers Reply-To: MX-List@MadGoat.com On 24 Sep 96 at 9:00, Jonathan E. Hardis wrote: > Presuming that I might have the time to tackle this, where might I find the > documentation on programming to NETLIB? My fantasy is that the > transformation from 1.7 to 1.7-CMU was simple enough that the same might be > applied to 1.8. If that's true, then making it universal with NETLIB has > additional value. > > - Jonathan I would second that. RHM +--+ Robert H. McClanahan, Mgr, Tech Info Systems, rmcclanahan@tis.aecc.com <[]>< Arkansas Electric Coop Corp, PO Box 194208, Little Rock, AR 72219-4208 USA "If I find in myself a desire which no experience in this world can satisy, the most probable explanation is that I was made for another world." C.S. Lewis ================================================================================ Archive-Date: Tue, 24 Sep 1996 09:25:24 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 24 Sep 1996 16:18:11 GMT Message-ID: <96092416181119@ecn02.ec-nantes.fr> From: Claude.Erbacher@ec-nantes.fr (C. ERBACHER - Centrale Nantes - Tel : 40 37 16 26) Reply-To: MX-List@MadGoat.com To: MX-List@madgoat.com Subject: Re: possibility to switch messages when a host is down ? |>>> And is there a matter to make the messages for the users of the host |>>> who is down in state 'holding' in the MX queue ? So MCP does not retry every |>>> 30 minutes, and when the host will be OK, the messages will be released for |>>> processing by making them in state 'no holding' ? |> |>> No, but that too is on the ever-growing wish list.... |> |>$ MCP QUEUE READY wouldn't do this? |> |It'll retry the delivery, but I interpreted the question as, "Is there |a way to mark those entries as "HOLD" until such time as the remote |system is available." QUEUE READY will cause the retry at that time, |but it won't let you mark an entry as held. You are right and have good unterstand what I wanted to say : Is there a way to mark those entries as "HOLD" until such time as the remote system is available." For a solution, I will wait a next release of MX software. Thanks Claude ERBACHER ================================================================================ Archive-Date: Tue, 24 Sep 1996 09:27:38 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 24 Sep 1996 09:27:31 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8D83.12EF78B1.17@ALPHA.WKU.EDU> Subject: RE: other wish for the ever-growing wish list Claude.Erbacher@ec-nantes.fr (C. ERBACHER - Centrale Nantes - Tel : writes: > > Please could you say me if the support of Extented SMTP protocol >(ESMTP) and MIME would be possible in a future release of MX ? If yes, in >how many time ? > I've answered these before, but since I haven't had time to do an FAQ yet, I'll post it again. - ESMTP This is on the wish list, though, frankly, it's a pretty low priority right now because there don't seem to be many mail systems that support it. Or, at least, I haven't seen them, if there are a bunch out there. Still, I agree that it would be nice to support, so it is on the list.... - MIME MX itself will never support MIME itself, because it's not supposed to. MIME is *supposed* to be handled by the *user agent* (the user's interface to mail) and *NOT* the transport agent (MX). Unfortunately, VMS Mail does not include MIME support, and MX doesn't provide its own user agent, so there's not really any way MX could support MIME. (MX *does* support MIME in that it leaves message bodies alone, so a MIME-aware user agent can certainly process MIME messages that arrive via MX.) Now, it is true that the MX Local agent includes very limited MIME support (it decodes quoted printable and base64-encoded files from other VMS systems), but that was done simply because they were fairly easy to implement for VMS Mail users. But real MIME support depends on the user agent, so there's not much more MX Local could support either. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Tue, 24 Sep 1996 09:38:40 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 24 Sep 1996 10:19:43 EDT From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8D8A.5DF23A40.2@swdev.si.com> Subject: RE: Mail Headers Jonathan E. Hardis (hardis@garnet.nist.gov) writes: >Presuming that I might have the time to tackle this, where might I find the >documentation on programming to NETLIB? My fantasy is that the >transformation from 1.7 to 1.7-CMU was simple enough that the same might be >applied to 1.8. If that's true, then making it universal with NETLIB has >additional value. The NETLIB Zip file contains full docs. May I suggest you consider using SOCKETSHR (which, in turn, uses NETLIB)? SOCKETSHR implements BSD-style sockets ina TCP/IP independent fashion. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman_brian@si.com Smiths Industries, Inc. | tillman@swdev.si.com 4141 Eastern Ave., MS239 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Tue, 24 Sep 1996 11:23:07 CST Sender: owner-mx-list@WKU.EDU From: "David Murray" To: mx-list@madgoat.com, goathunter@MadGoat.COM Date: Tue, 24 Sep 1996 12:21:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: RE: Mail Headers Reply-To: MX-List@MadGoat.com > When you compile IUPOP3, you must select the option to remove > VMS Mail headers.... > I found the compile option for patching the 'From' line, but I can see no logic to omit the VMS headers, either through a compile or run-time switch. When retrieving a message, IUPOP3_VMS.C uses the callable mail interface to retrieve the header, and always sends it to the client. The SMTP headers appear to be part of the body of the message. David N. Murray | PDS Sr. Software Engineer | 670 Sentry Parkway 610/828-4294 | Blue Bell, PA 19422 dmurray@pdssoftware.com | ================================================================================ Archive-Date: Tue, 24 Sep 1996 11:40:43 CST Sender: owner-mx-list@WKU.EDU From: "David Murray" To: mx-list@madgoat.com, hardis@garnet.nist.gov Date: Tue, 24 Sep 1996 12:39:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: RE: Mail Headers Reply-To: MX-List@MadGoat.com > > When you compile IUPOP3, you must select the option to remove > > VMS Mail headers.... > > [and that, specifically refering to IGNORE_MAIL11_HEADERS] > > The first time a user complained about this to me on my system was last > Friday. The problem is that I'm running CMU/TEK TCP/IP, and that puts me > back to the specially modified version 1.7 of IUPOP3. The > IGNORE_MAIL11_HEADERS flag wasn't introduced until version 1.8. I too am running 1.7-CMU of IUPOP3. No wonder I couldn't find it... > > Presuming that I might have the time to tackle this, where might I find the > documentation on programming to NETLIB? My fantasy is that the > transformation from 1.7 to 1.7-CMU was simple enough that the same might be > applied to 1.8. If that's true, then making it universal with NETLIB has > additional value. > The docs are in saveset D of ftp://ftp.wku.edu/madgoat/NETLIB020.ZIP. The readme says they will be installed into NETLIB_DIR. I'd be interested in helping you bring 1.8 to CMU and/or NETLIB'ing it. Dave ================================================================================ Archive-Date: Tue, 24 Sep 1996 14:07:12 CST Sender: owner-mx-list@WKU.EDU Date: Tue, 24 Sep 1996 14:01:51 CST From: metze@vmetze.mrl.uiuc.edu Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU CC: metze@vmetze.mrl.uiuc.edu Message-ID: <009A8DA9.660EF230.20@vmetze.mrl.uiuc.edu> Subject: "Version number in qf(2)..." I have received mail back from MAILER-DAEMON on a campus machine with subject: Returned mail: Version number in qf(2) greater than max (1) Has anyone seen this? ================================================================================ Archive-Date: Tue, 24 Sep 1996 23:23:05 CST Sender: owner-mx-list@WKU.EDU Date: Wed, 25 Sep 1996 00:22:50 EST From: Jim Bender Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8E00.263EE172.246@bdsnet.com> Subject: Re: string too long In article <009A8810.74A0FCAB.26@uwwvax.uww.edu>, hunterl@uwwvax.uww.edu writes: >> => >> => $ MULTINET SET/ROUTE/ADD=(DESTINATION=ip,GATE=blah) >> => >> => Where "ip" is the IP address of the source mailer(s) you don't want to >> => accept mail from, and "blah" is some local IP address which is _not_ >> => a router. This will cause your mail connections to receive some SYNs >> => and not be able to respond to them (so some TCP connections will >> => remain embryonic), but that's better than having your SMTP server >> => crash. >> This solution has not worked for me., the message continues to return >> hourly. Is there something missing from the above? > >Check your routing tables to make sure that host "blah" (that you >specified) didn't update your routing tables for you via an ICMP >redirect. If it did, pick a different host "blah" that won't send you >an ICMP redirect (a PC is a good bet -- most PC stacks don't know how >to do that) or simply pick an unused IP address on your local network. > >If you have a black-hole route (which prevents TCP connection from >being established with the remote host) there is _no way_ your MX SMTP >Server process can be crashed, as your application (MX SMTP Server) is >never handed the connection (nor the data). > >You can also try blocking the entire network the connections are >coming from -- they may have a few different outgoing mailers and >you're getting a connection from a different on than you're blocking. If redirects are a problem, try turning off MTU discovery with MU SET/KERNEL TCP_DO_MTU_DISCOVERY 0 This stopped hundreds of little routes from appearing in the routing table. But the problem remains, and seems to be getting worse... Has anyone been successful in contacting the postmaster(s) at any of these sites? This is hitting us hard now and our users are about to revolt.. :-( So far, we are using Dan's suggested method to block THREE sites!! And they keep coming!! AARRRRRGH!!!!! So far, we have one at missouri.edu, stanford.edu, and the original cyberwhateveritwas.com It *IS* working, as the server is crashing less and less, and we can see the repeated attempts as incrementing counters in MU SH/ROUTE This is really starting to become ridiculous, though... Question: Why is this error fatal to the server? Couldn't it be trapped and the message rejected? Or was this simply something not planned for? Could the MX processes be made "persistent" sort of like how IUPOP3 operates? i.e., from a dcl file, and if the executable ever exits the dcl code pops off a message to the system manager with the exit status and loops back around and restarts the process... This helps a *lot* with programs that are prone to dying for various reasons. Would it be difficult to adapt this to MX? Thanks, Jim Bender jbender@bdsnet.com ================================================================================ Archive-Date: Tue, 24 Sep 1996 23:37:03 CST Sender: owner-mx-list@WKU.EDU From: dwing@tgv.com ("Dan Wing") Subject: Re: string too long Date: 25 Sep 1996 04:34:42 GMT Message-ID: <52acp2$5fv@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <009A8E00.263EE172.246@bdsnet.com>, Jim Bender writes: > If redirects are a problem, try turning off MTU discovery with > MU SET/KERNEL TCP_DO_MTU_DISCOVERY 0 > This stopped hundreds of little routes from appearing in the routing > table. > > But the problem remains, and seems to be getting worse... > > Has anyone been successful in contacting the postmaster(s) at any of > these sites? This is hitting us hard now and our users are about to > revolt.. :-( > > So far, we are using Dan's suggested method to block THREE sites!! And > they keep coming!! AARRRRRGH!!!!! > > So far, we have one at missouri.edu, stanford.edu, and the original > cyberwhateveritwas.com > > It *IS* working, as the server is crashing less and less, and we > can see the repeated attempts as incrementing counters in MU SH/ROUTE > > This is really starting to become ridiculous, though... > > Question: Why is this error fatal to the server? Couldn't it be > trapped and the message rejected? Or was this simply something not > planned for? It was something that wasn't expected in MX -- we're going over the bounds of a buffer. A solution to the spamming sources would be rejecting mail with certain MAIL FROMs -- that would be easier than creating lots of black-hole routes (which cause the same effect as the TCP SYN floods, by the way -- creating TCP connection table entries, tying up the kernel trying to respond, etc. -- but as long as the number of incoming SYNs stays low enough it won't cause the denial of service caused by the TCP SYN floods. See a recent post of mine to Info-MultiNet on how to keep MultiNet more bullet-proof in a TCP SYN attack). > Could the MX processes be made "persistent" sort of like how IUPOP3 > operates? i.e., from a dcl file, and if the executable ever exits > the dcl code pops off a message to the system manager with the exit > status and loops back around and restarts the process... This helps > a *lot* with programs that are prone to dying for various reasons. > > Would it be difficult to adapt this to MX? You could have a detached process which looked for a missing SMTP Server process (it always has the same name) and if it finds it is missing will fire off a TCPDUMP (so you can capture the site that causes it to die the next time) and fires up a new SMTP server process. -Dan Wing dwing@tgv.com / dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Wed, 25 Sep 1996 06:18:54 CST Sender: owner-mx-list@WKU.EDU Date: Wed, 25 Sep 1996 06:18:47 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A8E31.E0358794.20@ALPHA.WKU.EDU> Subject: Re: string too long dwing@tgv.com ("Dan Wing") writes: > >> Question: Why is this error fatal to the server? Couldn't it be >> trapped and the message rejected? Or was this simply something not >> planned for? > >It was something that wasn't expected in MX -- we're going over the >bounds of a buffer. > Yep---the server never expected to have to deal with a string bigger than 64K bytes, so it dies when that happens. The next version of MX expects this (in the SMTP Server, anyway). >You could have a detached process which looked for a missing SMTP >Server process (it always has the same name) and if it finds it is >missing will fire off a TCPDUMP (so you can capture the site that >causes it to die the next time) and fires up a new SMTP server >process. > Until I can the next version released, this is one way. In fact, there's a .COM file already out there that'll restart the server for you. Pick up MX_WATCHDOG.COM from ftp.wku.edu in [.MX.CONTRIB]. Or you could change the MX_START.COM to launch the server by running SYS$SYSTEM:LOGINOUT and supplying a .COM file as the input that looks like this: $ set noon $ loop: $ run mx_exe:smtp_server.exe $ goto loop Or you could not have MX_STARTUP.COM start the server (by taking it out of MX_STARTUP_INFO.DAT) and starting it yourself using the LOGINOUT method. Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Wed, 25 Sep 1996 16:39:41 CST Sender: owner-mx-list@WKU.EDU Date: Wed, 25 Sep 1996 16:38:56 CST From: "James T. Horn" Reply-To: MX-List@MadGoat.com To: mx-list@wkuvx1.wku.edu Message-ID: <009A8E88.8275C38D.3448@SHSU.edu> Subject: Command RSET Is the SMTP command RSET implemented in MX Version 4.1 AXP? One of our instructor's is using that command in his class and after issuing that command, it outputs "Server has reset to initial state". But when he trys to then do a "HELO address", it gets the error message "Bad sequence of commands." Any help will be appreciated. ----------------------------------------------------------------------- James T. Horn /-\ Coordinator, VMS Systems / | \ Sam Houston State University / /|\ \ Internet : horn@Shsu.edu / / ^ \ \ http://oliver.shsu.edu/~horn/horn.html / / /,\ \ \ Something to think about: \ \ \`/ / / Indecision may or may not be my problem. --------- - Jimmy Buffett, "Don't Chu-Know", Barometer Soup | | | | | ----------------------------------------------------------------------- ================================================================================ Archive-Date: Wed, 25 Sep 1996 16:52:44 CST Sender: owner-mx-list@WKU.EDU Date: Wed, 25 Sep 1996 16:51:16 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: HORN@SHSU.EDU Message-ID: <009A8E8A.3B05900D.20@ALPHA.WKU.EDU> Subject: RE: Command RSET "James T. Horn" writes: > >Is the SMTP command RSET implemented in MX Version 4.1 AXP? > Yes, it's implemented (always has been, as far as I can tell). >One of our instructor's is using that command in his class and after >issuing that command, it outputs "Server has reset to initial state". >But when he trys to then do a "HELO address", it gets the error >message "Bad sequence of commands." > RFC821 isn't clear on this point; MX doesn't allow another HELO after a RSET, though any other command is valid, as is proper. The RFC examples using RSET show a MAIL FROM: following the RSET. I believe this is correct behavior, given this from the RFC: RESET (RSET) This command specifies that the current mail transaction is to be aborted. Any stored sender, recipients, and mail data must be discarded, and all buffers and state tables cleared. The receiver must send an OK reply. RSET does indeed discard any info received, but the connection isn't closed, so no new HELO is expected (or allowed). Other SMTPs may allow that, but I don't think it's required by the RFC (or if it is, it's unclear to me). Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Thu, 26 Sep 1996 11:16:08 CST Sender: owner-mx-list@WKU.EDU From: dwing@tgv.com ("Dan Wing") Subject: Re: Mail Headers Date: 25 Sep 1996 23:55:47 GMT Message-ID: <52cgq3$t36@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <35322180@MVB.SAIC.COM>, "David Murray" writes: > I've been a perpetual lurker for a while, but haven't posted anything > in recent memory, so if I haven't said it before, thanks to Hunter > and friends for the most excellent product. > > I have been having a problem reading MIME attachements downloaded by > IUPOP3 to Pegasus. It seems that my problem was an extra blank line > in the message, and Pegasus thought that was where the headers ended. > I modified IUPOP3 to strip this blank line out, but I was wondering > if there was a more elegant fix (since I just broke local messages). > > The problem (as I see it) is that VMS mail inserts a blank line to > separate the VMS header from the body of the message. Unfortunately, > it does not recognize that there are SMTP headers following it. > According to RFC822, the first null line denotes the end of the > headers, so Pegasus is interpreting it correctly. > > Am I correct in assuming the VMS mail is the culprit? Is there a DEC > patch for this problem? Configure IUPOP to not send the VMSmail headers. And you can setup everyone that uses POP with: MAIL> SET FORWARD MX%"""_user@host""" to force the MX headers to be present. That's what I do here. -Dan Wing dwing@tgv.com / dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Fri, 27 Sep 1996 10:49:00 CST Sender: owner-mx-list@WKU.EDU From: dwing@tgv.com ("Dan Wing") Subject: Re: Attachments not being recognised Date: 27 Sep 1996 15:29:09 GMT Message-ID: <52grs5$4db@cronkite.cisco.com> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <1996Sep27.171356.632@fcnz.co.nz>, wykesn@fcnz.co.nz (Nick Wykes - Info Services) writes: > Anyone played with UCX 4.1's POP server yet? Works great except Pegasus > (and other clients for that matter) doesn't recognise attachments. > > I believe it's got to be something to do with headers. Anyone got any > thoughts on this? > > We're using MX 4.1 & VMS 6.1. What do the headers look like? TELNET to your POP3 port manually and examine what comes across: $ TELNET HOST /PORT=110 USER user PASS password RETR 1 QUIT -Dan Wing dwing@tgv.com / dwing@cisco.com cisco Systems, Inc. ================================================================================ Archive-Date: Sat, 28 Sep 1996 11:07:28 CST Sender: owner-mx-list@WKU.EDU Subject: Re: Alpha SMTP_SERVER process dying with SYSTEM-F-DUPLNAM Message-ID: From: levitte@lp.se (Richard Levitte - VMS Whacker) Reply-To: MX-List@MadGoat.com Date: 28 Sep 1996 16:04:57 GMT To: MX-List@WKUVX1.WKU.EDU In article "Fred R. Ziegler" writes: Hi! Scenario: ALPHA OpenVMS V6.2. MX version 4.1 On occasion, my SMTP_SERVER process dies and/or is killed. When I try starting again, in the foreground to make debugging easier, I get: As I recall, there was some bug in version 4.1 which had this effect. Upgrade to 4.2. If I remember incorrectly, please tell me. -- R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN Tel: +46-8-26 52 47, (via nation.se) +46-8-728 20 33; 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: Sat, 28 Sep 1996 11:24:11 CST Sender: owner-mx-list@WKU.EDU Subject: Re: other wish for the ever-growing wish list Message-ID: From: levitte@lp.se (Richard Levitte - VMS Whacker) Reply-To: MX-List@MadGoat.com Date: 28 Sep 1996 16:20:33 GMT To: MX-List@WKUVX1.WKU.EDU In article <009A8D83.12EF78B1.17@ALPHA.WKU.EDU> Hunter Goatley writes: - ESMTP This is on the wish list, though, frankly, it's a pretty low priority right now because there don't seem to be many mail systems that support it. Or, at least, I haven't seen them, Ahem, Hunter, you're in the US, so you don't see it very often. Here in Sweden, ESMTP servers increase in numbers by the day (OK, by the week :-)). QP is just too much of a hassle. Actually it's a kludge to cover up a badly defined RFC (my opinion). Right now, I'm breaking RFC822 by sending messages through SMTP with 8-bit characters in the clear. I guess it's the same in many non-english countries, as almost all of them have a bunch of non-US-ASCII characters to deal with. - MIME supposed to. MIME is *supposed* to be handled by the *user agent* (the user's interface to mail) and *NOT* the transport agent (MX). That's almost true. There are wild discussions going on about this. Say you send a message in swedish, containing one or more of the characters å (aring), ä (auml) or ö (ouml). The author of this message has no idea whatsoever if his message will be sent to a server that is ESMTP-aware or not, and therefore has no idea if he should make sure his message gets QP-coded or not. Many people think that QP should therefore be handled by the transport agent. Some go further and say that all content coding should be handled by the transport agent. In a way, it *does* make sence. -- R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN Tel: +46-8-26 52 47, (via nation.se) +46-8-728 20 33; 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: Sat, 28 Sep 1996 11:40:45 CST Sender: owner-mx-list@WKU.EDU Subject: Re: possibility to switch messages when a host is down ? Message-ID: From: levitte@lp.se (Richard Levitte - VMS Whacker) Reply-To: MX-List@MadGoat.com Date: 28 Sep 1996 16:25:04 GMT To: MX-List@WKUVX1.WKU.EDU In article <96092408363415@ecn01.ec-nantes.fr> Claude.Erbacher@ec-nantes.fr (C. ERBACHER - Centrale Nantes - Tel : 40 37 16 26) writes: And is there a matter to make the messages for the users of the host who is down in state 'holding' in the MX queue ? So MCP does not retry every 30 minutes, and when the host will be OK, the messages will be released for processing by making them in state 'no holding' ? Isn't that some kind of contradiction? If your SMTP server (not MCP :-)) doesn't try to send the message every now and then, how will it know that the SMTP service on the receiving host is up or not? A "ping" won't do you much good... -- R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN Tel: +46-8-26 52 47, (via nation.se) +46-8-728 20 33; 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: Sat, 28 Sep 1996 20:23:16 CST Sender: owner-mx-list@WKU.EDU Date: Sat, 28 Sep 1996 21:24:41 EST From: Kevin Convery FSU GFDI 644-2454 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A910B.ECAE53E3.21@gfdi.fsu.edu> Subject: Re: Alpha SMTP_SERVER process dying with SYSTEM-F-DUPLNAM I've had that happen too. I finally tracked it down to a user sending an e-mail into us that had 1132+ lines of CC: . Sort of a lazy mailing list. Each time the message was resent to us by the offending system it killed smtp_server. I solved it with a .com file that auto restarted whenever it it detected a smtp_server had crashed. Then when the offending system stopped resending the e-mail the problem never resurfaced. Just 1 possibility... Kevin FSU GFDI System Manager (904)644-2454 convery@gfdi.fsu.edu ================================================================================ Archive-Date: Sun, 29 Sep 1996 07:25:03 CST Sender: owner-mx-list@WKU.EDU Date: Sun, 29 Sep 1996 07:24:55 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A915F.C68159FA.11@ALPHA.WKU.EDU> Subject: Re: Alpha SMTP_SERVER process dying with SYSTEM-F-DUPLNAM levitte@lp.se (Richard Levitte - VMS Whacker) writes: > > Hi! Scenario: ALPHA OpenVMS V6.2. MX version 4.1 > > On occasion, my SMTP_SERVER process dies and/or is killed. > When I try starting again, in the foreground to make debugging easier, I get: > >As I recall, there was some bug in version 4.1 which had this effect. >Upgrade to 4.2. > >If I remember incorrectly, please tell me. > Even in V4.2, the SMTP Server will die if messages come in with To: or CC: lines that contain thousands of addresses and are more than 64K bytes long. This will be fixed in the next version. As far as the duplicate name stuff, that means that some process out there is already listening on the SMTP port (25). Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Sun, 29 Sep 1996 07:29:57 CST Sender: owner-mx-list@WKU.EDU Date: Sun, 29 Sep 1996 07:29:47 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A9160.749689E8.13@ALPHA.WKU.EDU> Subject: Re: other wish for the ever-growing wish list levitte@lp.se (Richard Levitte - VMS Whacker) writes: > >Ahem, Hunter, you're in the US, so you don't see it very often. Here in >Sweden, ESMTP servers increase in numbers by the day (OK, by the week :-)). >QP is just too much of a hassle. Actually it's a kludge to cover up a >badly defined RFC (my opinion). > Agreed. I should have qualified that by providing my research methods. A few months ago, I hand-Telnetted to port 25 of more than a dozen sites around the world that rejected mail because it had 8-bit characters sent in the clear. None of them supported ESMTP (I guess they were expecting QP). That probably has changed now. >Right now, I'm breaking RFC822 by sending messages through SMTP with 8-bit >characters in the clear. > As is every other MX site. ;-) > supposed to. MIME is *supposed* to be handled by the *user > agent* (the user's interface to mail) and *NOT* the transport > agent (MX). > >That's almost true. There are wild discussions going on about this. >Say you send a message in swedish, containing one or more of the >characters å (aring), ä (auml) or ö (ouml). The author of this message >has no idea whatsoever if his message will be sent to a server that is >ESMTP-aware or not, and therefore has no idea if he should make sure his >message gets QP-coded or not. Many people think that QP should therefore >be handled by the transport agent. Some go further and say that all >content coding should be handled by the transport agent. In a way, it >*does* make sence. > Yes, I agree with that example. PMDF automatically QPs (by default) any outgoing message with an 8-bit character (or at least, it did the last time I looked at PMDF). That's the main reason I added QP decoding to MX Local! Content coding is a little different; that *could* be better handled by the transport because it can look at where it originated and where it's going. But decoding is a lot different; you have no idea where things will end up. (Does that even make sense?) Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Sun, 29 Sep 1996 10:30:02 CST Sender: owner-mx-list@WKU.EDU Subject: Re: other wish for the ever-growing wish list Message-ID: From: levitte@lp.se (Richard Levitte - VMS Whacker) Reply-To: MX-List@MadGoat.com Date: 29 Sep 1996 15:24:33 GMT To: MX-List@WKUVX1.WKU.EDU In article <009A9160.749689E8.13@ALPHA.WKU.EDU> Hunter Goatley writes: Agreed. I should have qualified that by providing my research methods. A few months ago, I hand-Telnetted to port 25 of more than a dozen sites around the world that rejected mail because it had 8-bit characters sent in the clear. None of them supported ESMTP (I guess they were expecting QP). That probably has changed now. Those sites are behaving correctly according to RFC822. If they don't support ESMTP, they don't have to support 8-bit chars. Some of them are following RFC822 to the letter and misfeature, and thus reject messages with "invalid characters". ESMTP servers should never reject such messages, as far as I understand. enklav.stacken.kth.se is an ESMTP server that I don't mind if you try on (as long as you don't crash it :-). I'm one of the managers at stacken.kth.se, BTW). Content coding is a little different; that *could* be better handled by the transport because it can look at where it originated and where it's going. But decoding is a lot different; you have no idea where things will end up. (Does that even make sense?) It did make sense to me. And I didn't even use ESP :-). -- R Levitte, Levitte Programming; Spannvägen 38, I; S-161 43 Bromma; SWEDEN Tel: +46-8-26 52 47, (via nation.se) +46-8-728 20 33; 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: Sun, 29 Sep 1996 10:46:12 CST Sender: owner-mx-list@WKU.EDU Date: Sun, 29 Sep 1996 11:42:10 EDT From: Brian Reed Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.COM Message-ID: <009A9183.B6841C1C.1@cbict3.cb.lucent.com> Subject: Re: Alpha SMTP_SERVER process dying with SYSTEM-F-DUPLNAM >> On occasion, my SMTP_SERVER process dies and/or is killed. > >As far as the duplicate name stuff, that means that some process out >there is already listening on the SMTP port (25). I just ran into this, and the message didn't click in as soon as it should have. Any chance to update the message and add "SMTP server already running" or something similar. That would make it quite obvious what the problem is, especially when you're brain's not in high gear. Just a thought. Brian D. Reed Columbus Works bdreed1@lucent.com 614-860-6218 ================================================================================ Archive-Date: Mon, 30 Sep 1996 08:09:51 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 30 Sep 1996 08:58:04 EDT From: "Brian Tillman, x8425" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A9235.F4693AA0.13@swdev.si.com> Subject: Re: possibility to switch messages when a host is down ? Richard Levitte (levitte@lp.se) wrote: >Isn't that some kind of contradiction? If your SMTP server (not MCP :-)) >doesn't try to send the message every now and then, how will it know that >the SMTP service on the receiving host is up or not? A "ping" won't do >you much good... OK, suppose I am the system administrator of a mail hub and I know I'm going to shut it down for a while. I could very well wish to have MX hold all the messages intended for that hub until I bring it back up. Since I'm controlling the down time, I know when it will be back up, too. No PING necessary. -----------------------------+-------------------------------- Brian Tillman | Internet: tillman_brian@si.com Smiths Industries, Inc. | tillman@swdev.si.com 4141 Eastern Ave., MS239 | Hey, I said this stuff myself. Grand Rapids, MI 49518-8727 | My company has no part in it. -----------------------------+-------------------------------- ================================================================================ Archive-Date: Mon, 30 Sep 1996 08:37:22 CST Sender: owner-mx-list@WKU.EDU From: "David Murray" To: MX-List@MadGoat.com Date: Mon, 30 Sep 1996 09:37:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT Subject: Re: Attachments not being recognised Reply-To: MX-List@MadGoat.com > In article <1996Sep27.171356.632@fcnz.co.nz>, wykesn@fcnz.co.nz (Nick Wykes - Info Services) writes: > > Anyone played with UCX 4.1's POP server yet? Works great except Pegasus > > (and other clients for that matter) doesn't recognise attachments. > > > > I believe it's got to be something to do with headers. Anyone got any > > thoughts on this? > > > > We're using MX 4.1 & VMS 6.1. > > What do the headers look like? TELNET to your POP3 port manually and > examine what comes across: > > $ TELNET HOST /PORT=110 > USER user > PASS password > RETR 1 > QUIT > Since I just spent an ungodly amount of time on this, I'm going to add in my two cents: Specifically, if there is a blank line in your headers, Pegasus stops interpreting the headers at the blank line. I was/still am/kind of fixed the same problem with IUPOP3 and Pegasus. Dave David N. Murray | PDS Sr. Software Engineer | 670 Sentry Parkway 610/828-4294 | Blue Bell, PA 19422 dmurray@pdssoftware.com | ================================================================================ Archive-Date: Mon, 30 Sep 1996 08:37:33 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 30 Sep 1996 08:37:16 CST From: Hunter Goatley Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A9233.0C640BD8.20@ALPHA.WKU.EDU> Subject: Re: other wish for the ever-growing wish list levitte@lp.se (Richard Levitte - VMS Whacker) writes: > > characters sent in the clear. None of them supported ESMTP (I guess > they were expecting QP). That probably has changed now. > >Those sites are behaving correctly according to RFC822. If they don't >support ESMTP, they don't have to support 8-bit chars. Yes, that's true, but it still forces you to use QP or your message doesn't get through. That's equally irritating, IMO, regardless of RFC-compliance. ;-) Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Mon, 30 Sep 1996 10:20:03 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 30 Sep 1996 11:16:41 EST5EDT4,M4.1.0,M10.5.0 From: Scott McNeilly Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009A9249.51E570A0.44@fred.bridgew.edu> Subject: Re: Attachments not being recognised > In article <1996Sep27.171356.632@fcnz.co.nz>, wykesn@fcnz.co.nz (Nick Wykes - Info Services) writes: > > Anyone played with UCX 4.1's POP server yet? Works great except Pegasus > > (and other clients for that matter) doesn't recognise attachments. > > > > I believe it's got to be something to do with headers. Anyone got any > > thoughts on this? > > > > We're using MX 4.1 & VMS 6.1. > Did you define the logical UCX$POP_IGNORE_MAIL11_HEADERS? There are a few other logicals which also affect headers. They are described in section 2 of the release notes. I haven't played with UCX 4.1's POP server yet, because I can't get it to run. Whenever I try, my POP client tells me that the connection was refused, and SYSTEM gets the following mail message: From: EAGLE::UCX$POP To: SYSTEM CC: Subj: EAGLE - %SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged image The UCX POP server has experienced a runtime error. The reason for the error should appear on the subject line of this message. Please investigate this problem as quickly as possible. Thank you. But when I run INSTALL and LIST SYS$SYSTEM:UCX$POP_SERVER.EXE, it shows me that it is installed with privileges SYSPRV and BYPASS. Any ideas on this problem? I have this problem with UCX 4.1 and both VAX VMS 5.5-2 and 6.0, and MX 4.2. -------------------------------------------------------------------- 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, 30 Sep 1996 16:13:49 CST Sender: owner-mx-list@WKU.EDU From: goathunter@MadGoat.com (Hunter Goatley) Subject: Re: [help] bliss compiling FLQ_PRIVATE_DEFS.R32 modue of MX4.2 souce kit Date: 30 Sep 96 15:43:34 CST Message-ID: <1996Sep30.154334@alpha.wku.edu> Reply-To: MX-List@MadGoat.com To: MX-List@WKUVX1.WKU.EDU In article <1996Sep24.102044.19488@riksun.riken.go.jp>, ichihara@rikaxp.riken.go.jp (Takashi Ichihara) writes: > > Also in the [.netlib] directory, I cannot find NETLIB_SHRXFR.ALPHA_OPT > file in the same distribution file (MX4.2 source). Where can I find this ? > Thanks again. > That's missing from the NETLIB sources. It's not necessary to recompile NETLIB to recompile MX. > ------------------------------------------------------------------ > at [.FLQ] directory > > AXP6.2> mmk > DEFINE SYS$LIBRARY ALPHA$LIBRARY,SYS$SYSROOT:[SYSLIB] > BLISS/LIBR=[MX.COMMON]FIELDS.L32/NOLIST [MX.COMMON]FIELDS.R32 > BLISS/LIBR=FLQ_PRIVATE_DEFS.L32/NOLIST FLQ_PRIVATE_DEFS.R32 > > $ASSUME (((FLQ_K_BMAPBLKS*512)*8), EQLU, FLQ_K_MAXENT); > ....^ > %BLS32-W-TEXT, Undeclared name: $ASSUME You need to create your BLISS STARLET (and LIB, though it's not needed by MX) libraries: $ set def sys$common:[syslib] $ bliss/library=starlet.l32e starlet.req $ bliss/library=lib.l32e starlet.req+lib.req Hunter ------ Hunter Goatley, Process Software Corporation (TCPware) http://www.wku.edu/www/madgoat/hunter.html ================================================================================ Archive-Date: Mon, 30 Sep 1996 19:39:40 CST Sender: owner-mx-list@WKU.EDU Message-ID: <199610010034.UAA08835@redstone.interpath.net> From: "Rich Hill" To: MX-List@Madgoat.com Date: Mon, 30 Sep 1996 20:35:28 -0400 Subject: MLF & lower case domain names Reply-To: MX-List@MadGoat.com Content-Type: text I received the following request from one my list owners. What response should I give him? | Some domains reject my mailings because the listserv automatically capitalizes | the shills domain, e.g. | | "xxxx xxxx" (NOCASE) | | I notice that it says (NOCASE). Is there a way to change it to lower case? I understand about the 'case' issue for the username portion of the address. The list in question is defined as /NOCASE. What can be done about the domain name portion? TIA Rich Hill -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rich Hill S I M Rich.Hill@sim.org Systems Engineer b y EasyLink: 62923838 SIM USA, Inc. P r a y e r Phone: 1-704-587-1462 Charlotte, NC since 1893 FAX: 1-704-587-1518 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- [SC] Smiley captioned for the humor impaired. ================================================================================ Archive-Date: Mon, 30 Sep 1996 21:15:43 CST Sender: owner-mx-list@WKU.EDU Date: Mon, 30 Sep 1996 22:14:31 EDT From: "Jonathan E. Hardis" Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: rich.hill@sim.org, hardis@garnet.nist.gov Message-ID: <009A92A5.37B7E9E0.4@garnet.nist.gov> Subject: RE: MLF & lower case domain names > I received the following request from one my list owners. What response > should I give him? > > | Some domains reject my mailings because the listserv automatically > | capitalizes the shills domain, e.g. > | > | "xxxx xxxx" (NOCASE) > | > | I notice that it says (NOCASE). Is there a way to change it to lower case? Tell him that his mail recipient's software is buggy -- the RFCs specify that domain names must be case insensitive. - Jonathan