Archive-Date: Fri, 6 Jul 2001 08:11:06 -0700 Message-ID: <026801c1062d$2fe1b2a0$c68387c0@ulm.edu> From: "eppinette" Reply-To: MX-List@MadGoat.com To: Subject: mail buffer problem Date: Fri, 6 Jul 2001 10:06:08 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0265_01C10603.46EA18E0" This is a multi-part message in MIME format. ------=_NextPart_000_0265_01C10603.46EA18E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Over the past year or so I have occasionally seen a problem with =3D received email messages to mailboxes on my OVMS system. However, =3D recently the problem seems to have escalated. The first clue to the problem is that the POP3 browser gets an error =3D message fromt the POP3 server that an error has occurred and at this =3D point no new messages can be received. After looking at the POP3 log = =3D file for that user, I get further information as to a particular message = =3D was in error and it shows the POP3 service errors out. The particular email, if viewed from the VMS mail utility, will be =3D truncated with the following error message as the last line: =3D %MAIL-E-RECTOBIG, 6429 byte record too large for MAIL buffer After deleting this message, everything is fine and POP3 activity can = =3D proceed. Any ideas as to if this would be a VMS problem or an MX problem... I am running: MX version id is: MX V5.1-X on Process Software MultiNet V4.1 Rev A-X, AlphaServer 2100 4/200, =3D OpenVMS AXP V7.2-1 Many thanks, Chance Eppinette eppinette@ulm.edu Technology Support Manager ULM Computing Center 318-342-5021 fax: 318-342-5018 ------=_NextPart_000_0265_01C10603.46EA18E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,

Over the past year or so = I have=20 occasionally seen a problem with =3D
received email messages to = mailboxes on my=20 OVMS system.  However, =3D
recently the problem seems to have=20 escalated.
The first clue to the problem is that the POP3 browser = gets an=20 error =3D
message fromt the POP3 server that an error has occurred = and at this=20 =3D
point no new messages can be received.  After looking at the = POP3 log=20 =3D
file for that user, I get further information as to a particular = message=20 =3D
was in error and it shows the POP3 service errors out.

The = particular email, if viewed from the VMS mail utility, will be = =3D
truncated=20 with the following error message as the last line:  = =3D
%MAIL-E-RECTOBIG,=20 6429 byte record too large for MAIL buffer

After deleting this = message,=20 everything is fine and POP3 activity can =3D
proceed.

Any = ideas as to if=20 this would be a VMS problem or an MX problem...

I am = running:
MX=20 version id is: MX V5.1-X
on  Process Software MultiNet V4.1 Rev = A-X,=20 AlphaServer 2100 4/200, =3D
OpenVMS AXP V7.2-1

Many=20 thanks,
Chance Eppinette
eppinette@ulm.edu
Technology = Support=20 Manager
ULM Computing Center
318-342-5021
fax:=20 318-342-5018
------=_NextPart_000_0265_01C10603.46EA18E0-- ================================================================================ Archive-Date: Fri, 6 Jul 2001 08:59:13 -0700 Sender: maulis@ludens.elte.hu Date: Fri, 06 Jul 2001 17:57:40 +0200 From: Adam Maulis Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com Message-ID: <009FE9CD.9CB7455F.3102@ludens.elte.hu> Subject: RE: mail buffer problem > The first clue to the problem is that the POP3 browser gets an error =3D > message fromt the POP3 server that an error has occurred and at this =3D > point no new messages can be received. After looking at the POP3 log = [...] > %MAIL-E-RECTOBIG, 6429 byte record too large for MAIL buffer in the IUpop3 server, there is an comment in the source: (IUpop3 version 2.0-4 in the IUPOP3_GENERAL.H ) In order to retrieve lines longer than 256 bytes from the callable mail subsystem, we use an undocumented item code (MAIL$_MESSAGE_BUFFER) that returns a pointer to the in-memory text. This text has a particular block structure and the following definitions simplify the handling of that structure. [...] This information was supplied by Hunter Goatley. :-) > MX version id is: MX V5.1-X > on Process Software MultiNet V4.1 Rev A-X, AlphaServer 2100 4/200, =3D I have no idea with MultiNet, ask vmsnet.networks.tcp-ip.multinet newsgroup. Regards, Adam Maulis ================================================================================ Archive-Date: Mon, 9 Jul 2001 05:20:35 -0700 From: Andy Harper Sender: andy.harper@kcl.ac.uk Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com CC: MX-List@MadGoat.com Subject: Re: RE: mail buffer problem In-Reply-To: <009FE9CD.9CB7455F.3102@ludens.elte.hu> Message-ID: Date: Mon, 9 Jul 2001 13:24:35 +0100 (GDT) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII On Fri, 06 Jul 2001 17:57:40 +0200 Adam Maulis wrote: > > > The first clue to the problem is that the POP3 browser gets an error =3D > > message fromt the POP3 server that an error has occurred and at this =3D > > point no new messages can be received. After looking at the POP3 log = > > [...] > > > %MAIL-E-RECTOBIG, 6429 byte record too large for MAIL buffer > > in the IUpop3 server, there is an comment in the source: > (IUpop3 version 2.0-4 in the IUPOP3_GENERAL.H ) > > > In order to retrieve lines longer than 256 bytes from the callable mail > subsystem, we use an undocumented item code (MAIL$_MESSAGE_BUFFER) that > returns a pointer to the in-memory text. This text has a particular block > structure and the following definitions simplify the handling of that > structure. You might want to look further at the IUPOP3 setup, since it has the ability to read the long lines using precisely this undocumented method (I know this because I wrote the code for it). I think you can set it up via a build option or a logical. My memory's a bit vague due to not having looked at it for several years - sorry. Regards, ---------------------- Andy Harper B.Sc., M.B.C.S, C.Eng Systems and Mail Manager Kings College London ================================================================================ Archive-Date: Mon, 9 Jul 2001 05:37:41 -0700 Subject: Re: RE: mail buffer problem From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3b49a2ae$1@news.kapsch.co.at> Date: 9 Jul 2001 14:25:18 +0200 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com In article , Andy Harper writes: >On Fri, 06 Jul 2001 17:57:40 +0200 Adam Maulis >wrote: >> > The first clue to the problem is that the POP3 browser gets an error =3D >> > message fromt the POP3 server that an error has occurred and at this =3D >> > point no new messages can be received. After looking at the POP3 log = >> >> [...] >> >> > %MAIL-E-RECTOBIG, 6429 byte record too large for MAIL buffer >> >> in the IUpop3 server, there is an comment in the source: >> (IUpop3 version 2.0-4 in the IUPOP3_GENERAL.H ) >> >> >> In order to retrieve lines longer than 256 bytes from the callable mail >> subsystem, we use an undocumented item code (MAIL$_MESSAGE_BUFFER) that >> returns a pointer to the in-memory text. This text has a particular block >> structure and the following definitions simplify the handling of that >> structure. > > You might want to look further at the IUPOP3 setup, since it has the > ability to read the long lines using precisely this undocumented > method (I know this because I wrote the code for it). > I think you can set it up via a build option or a logical. My > memory's a bit vague due to not having looked at it for several years > - sorry. $ DEFINE/SYSTEM/EXEC IUPOP3_ENABLE_LONG_LINES TRUE -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Tue, 10 Jul 2001 06:45:29 -0700 Message-ID: <1da901c10946$39f4cdb0$76041c7e@si.com> From: "Brian Tillman" Reply-To: MX-List@MadGoat.com To: References: Subject: Re: RE: mail buffer problem Date: Tue, 10 Jul 2001 09:42:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >I think you can set it up via a build option or a logical. Yes. Define the system logical IUPOP3_ENABLE_LONG_LINES to have the value TRUE. Brian Tillman Internet: tillman_brian at si.com Smiths Aerospace tillman at swdev.si.com 3290 Patterson Ave. SE, MS Addresses modified to prevent Grand Rapids, MI 49512-1991 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ********************************************************************** This e-mail and any files transmitted with it are confidential and may be legally privileged or otherwise exempt from disclosure under applicable law. This e-mail and its files are intended solely for the individual or entity to whom they are addressed and their content is the property of Smiths Aerospace. If you are not the intended recipient, please do not read, copy, use or disclose this communication. If you have received this e-mail in error please notify the e-mail administrator at postmaster@si.com and then delete this e-mail, its files and any copies. This footnote also confirms that this e-mail message has been scanned for the presence of known computer viruses. *********************************************************************** ================================================================================ Archive-Date: Tue, 10 Jul 2001 06:50:38 -0700 Message-ID: <1db701c10946$f4fbfc00$76041c7e@si.com> From: "Brian Tillman" Reply-To: MX-List@MadGoat.com To: References: <3b49a2ae$1@news.kapsch.co.at> Subject: Re: RE: mail buffer problem Date: Tue, 10 Jul 2001 09:48:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >$ DEFINE/SYSTEM/EXEC IUPOP3_ENABLE_LONG_LINES TRUE The /EXEC is unnecessary. Brian Tillman Internet: tillman_brian at si.com Smiths Aerospace tillman at swdev.si.com 3290 Patterson Ave. SE, MS Addresses modified to prevent Grand Rapids, MI 49512-1991 SPAM. Replace "at" with "@" This opinion doesn't represent that of my company ********************************************************************** This e-mail and any files transmitted with it are confidential and may be legally privileged or otherwise exempt from disclosure under applicable law. This e-mail and its files are intended solely for the individual or entity to whom they are addressed and their content is the property of Smiths Aerospace. If you are not the intended recipient, please do not read, copy, use or disclose this communication. If you have received this e-mail in error please notify the e-mail administrator at postmaster@si.com and then delete this e-mail, its files and any copies. This footnote also confirms that this e-mail message has been scanned for the presence of known computer viruses. *********************************************************************** ================================================================================ Archive-Date: Wed, 25 Jul 2001 01:15:41 -0700 Subject: Short question/suggestion From: eplan@kapsch.net (Peter LANGSTOEGER) Message-ID: <3b5e8007$1@news.kapsch.co.at> Date: 25 Jul 2001 10:15:03 +0200 Reply-To: MX-List@MadGoat.com To: MX-List@MadGoat.com 1) How to bind two different SMTP servers on different IP addresses on a multihomed host ? MX_SMTP_TCPIP_PORT isn't sufficient then, is it ? 2) The MX Server DEBUG file should IMHO be better split up in one file per thread. It is VERY hard to do a fast/good debug session with >=24 threads mixed up in only one file. -- Peter "EPLAN" LANGSTOEGER Tel. +43 1 81111-2651 Network and OpenVMS system manager Fax. +43 1 81111-888 <<< KAPSCH AG Wagenseilgasse 1 E-mail eplan@kapsch.net A-1121 VIENNA AUSTRIA "I'm not a pessimist, I'm a realist" ================================================================================ Archive-Date: Tue, 31 Jul 2001 12:43:04 -0700 Message-ID: <007d01c119f9$1a4ba240$070610ac@sysmanhome> From: "Ruslan R. Laishev" Reply-To: MX-List@MadGoat.com To: Subject: MX 5.1A - block relay for user%domain@zz.top.net Date: Tue, 31 Jul 2001 23:43:40 +0400 Hi All! How to disable a relaying for so kind of addresses in MX 5.1-A? Regards. Mobile:+7 (901) 9713222, AIM nickname:"VMS hardworker" http://www.DLS.net - Non-stop VMS-powered ISP in ChicagoLand! http://www.RadiusVMS.com - RADIUS server for OpenVMS project ================================================================================ Archive-Date: Tue, 31 Jul 2001 14:18:11 -0700 Message-ID: <5.1.0.14.0.20010801001959.00b64778@juhani.decus.fi> Date: Wed, 01 Aug 2001 00:20:01 +0300 To: MX-List@MadGoat.com, From: Esa Laitinen Reply-To: MX-List@MadGoat.com Subject: Re: MX 5.1A - block relay for user%domain@zz.top.net MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 22:43 31.7.2001, Ruslan R. Laishev wrote: > How to disable a relaying for so kind of addresses in MX 5.1-A? set router/nopercent esa ================================================================================ Archive-Date: Tue, 31 Jul 2001 14:18:15 -0700 Message-ID: <5.1.0.14.0.20010801001959.00b64778@juhani.decus.fi> Date: Wed, 01 Aug 2001 00:20:01 +0300 To: MX-List@MadGoat.com, From: Esa Laitinen Reply-To: MX-List@MadGoat.com Subject: Re: MX 5.1A - block relay for user%domain@zz.top.net MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed At 22:43 31.7.2001, Ruslan R. Laishev wrote: > How to disable a relaying for so kind of addresses in MX 5.1-A? set router/nopercent esa