>The attached error report has been occurring for weeks on the list that I am >co-list owner of. We cannot figure out who the subscriber is that is causing >the errors. It is not the [log in to unmask] address that is listed in the >report - that address is not subscribed & there are no addresses subscribed >under a globecomm.net domain (maybe the postings are getting forwarded to this >hotmail account via the actual subscriber). It seems like someone subscribed >using iname, but with a personalized email domain. We've never had one of >these that we could not figure out, and we get many of these same errors every >day. Any ideas would be appreciated. > >Thanks, >Janis Thomas Ah, good old iname.com. They're subscribed from an iname account, which unfortunately can mean that they're subscribed from any of hundreds of domains. (See http://www.iname.com/ to see a partial list.) Also unfortunately, they don't leave any clues in the header as to just what that email address might be. In this situation I'd send mail to [log in to unmask] explaining the situation, including a sample bounce, and asking if they can find out what email address they have that forwards to [log in to unmask] Good luck! -Jacob Haller >---------------------- Forwarded by Janis Thomas/Pti on 09/17/99 08:03 AM >--------------------------- > > >"L-Soft list server at LISTSERV.AMERICAN.EDU (1.8d)" ><[log in to unmask]> on 09/17/99 02:58:59 AM > >To: [log in to unmask], Janis Thomas/Pti, [log in to unmask] >cc: >Subject: DB2-L: error report from GLOBECOMM.NET > > > > >The enclosed message, found in the DB2-L mailbox and shown under the spool ID >9907701 in the system log, has been identified as a possible delivery error >notice for the following reason: "Message/Delivery-Status" body part found in >the message body. > >------------------------ Message in error (162 lines) >------------------------- >Received: from listserv (listserv.american.edu [147.9.238.200]) by >listserv.american.edu (8.9.3/8.7) with ESMTP id DAA4812410 for ><[log in to unmask]>; Fri, 17 Sep 1999 03:58:58 -0400 >Received: from rmx04.globecomm.net (rmx04.iname.net [206.253.130.33]) by > listserv.american.edu (8.9.3/8.7) with ESMTP id DAA4812908 for > <[log in to unmask]>; Fri, 17 Sep 1999 03:58:55 -0400 >Received: from localhost by rmx04.globecomm.net (8.9.1/8.8.0) with internal >id > DAA03895 >Date: Fri, 17 Sep 1999 03:58:13 -0400 (EDT) >From: Mail Delivery Subsystem <[log in to unmask]> >Message-Id: <[log in to unmask]> >To: <[log in to unmask]> >MIME-Version: 1.0 >Content-Type: multipart/report; report-type=delivery-status; > boundary="DAA03895.937555093/rmx04.globecomm.net" >Subject: Returned mail: Service unavailable >Auto-Submitted: auto-generated (failure) >X-Report-Type: Nondelivery; boundary="> Error description:" > > >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. > >--> Error description: >Error-For: Requested mail action aborted: exceeded storage allocation >Error-Code: 0 >Error-Text: Service unavailable > >Error-End: One error reported. > > >This is a MIME-encapsulated message > >--DAA03895.937555093/rmx04.globecomm.net > >The original message was received at Fri, 17 Sep 1999 03:58:13 -0400 (EDT) >from lmtp05.iname.net [206.253.130.42] > >** >This is an automatic message to inform you that your email was not >forwarded through iName's server. > >The iName email address that you tried to send mail to may not be active. >Reasons for the failed delivery attempt could include: > >1. The iName customer has selected a new personalized iName email address > rendering their old iName email address inactive. > >2. The iName customer may have signed up for one of iName's free offers > and then not validated their forwarding address. > >3 The address may simply be typed incorrectly. Please check that you > typed the email address correctly. > >iName provides email users with a permanent, personalized and secure email >address that is independent of how one accesses the Internet. iName acts >as a global forwarding service. All email sent to a permanent iName address >is automatically forwarded to a user specified destination email address. >Please visit iName's Online Support Area at >http://www.iname.com/info/intro/index.html for further information. >** > > ----- The following addresses had permanent fatal errors ----- ><[log in to unmask]> > > ----- Transcript of session follows ----- >... while talking to mail9.hotmail.com.: >>>> RCPT To:<[log in to unmask]> ><<< 552 Requested mail action aborted: exceeded storage allocation >554 <[log in to unmask]>... Service unavailable > >--DAA03895.937555093/rmx04.globecomm.net >Content-Type: message/delivery-status > >Reporting-MTA: dns; rmx04.globecomm.net >Received-From-MTA: DNS; lmtp05.iname.net >Arrival-Date: Fri, 17 Sep 1999 03:58:13 -0400 (EDT) > >Final-Recipient: RFC822; [log in to unmask] >Action: failed >Status: 5.5.0 >Remote-MTA: DNS; mail9.hotmail.com >Diagnostic-Code: SMTP; 552 Requested mail action aborted: exceeded storage >allocation >Last-Attempt-Date: Fri, 17 Sep 1999 03:58:13 -0400 (EDT) > >--DAA03895.937555093/rmx04.globecomm.net >Content-Type: message/rfc822 > >Received: from smv14.iname.net by rmx04.globecomm.net (8.9.1/8.8.0) with SMTP >id DAA03890 ; Fri, 17 Sep 1999 03:58:13 -0400 (EDT) >Received: from listserv.american.edu (listserv.american.edu [147.9.238.200]) > by smv14.iname.net (8.9.3/8.9.1SMV2) with ESMTP id CAA24587; > Fri, 17 Sep 1999 02:18:33 -0400 (EDT) >Received: from listserv (listserv.american.edu [147.9.238.200]) by >listserv.american.edu (8.9.3/8.7) with ESMTP id CAA3859576; Fri, 17 Sep 1999 >02:17:48 -0400 >Received: from LISTSERV.AMERICAN.EDU by LISTSERV.AMERICAN.EDU (LISTSERV-TCP/IP > release 1.8d) with spool id 9902345 for [log in to unmask]; > Fri, 17 Sep 1999 02:16:47 -0400 >Received: from csimo02.mx.cs.com (csimo02.mx.cs.com [205.188.156.53]) by > listserv.american.edu (8.9.3/8.7) with ESMTP id CAA3857210 for > <[log in to unmask]>; Fri, 17 Sep 1999 02:16:45 -0400 >Received: from [log in to unmask] by csimo02.mx.cs.com (mail_out_v22.4.) id > eJNKa03044 (4571) for <[log in to unmask]>; Fri, 17 Sep >1999 > 02:13:50 -0400 (EDT) >MIME-Version: 1.0 >Content-Type: text/plain; charset="us-ascii" >Content-Transfer-Encoding: 7bit >X-Mailer: CompuServe 2000 32-bit sub 65 >Message-ID: <[log in to unmask]> >Newsgroups: bit.listserv.db2-l >Date: Fri, 17 Sep 1999 02:13:50 EDT >Reply-To: DB2 Data Base Discussion List <[log in to unmask]> >Sender: DB2 Data Base Discussion List <[log in to unmask]> >From: Rick Davis <[log in to unmask]> >Subject: Re: Leafdist - how to fix ? >To: [log in to unmask] > >Alan, > There's several things you can try. >1. Ensure ample primary space. Secondary extents in either the table or index >can be quite a problem if major access is sequential or skip-sequential. >2. Consider 'seeding' new tables with dummy rows if its possible and ample >freepages. >3. For rapidly growing indexes, LEAFDIST will continue to be a problem until >the percentage of added entries represents a smaller percentage of the total. >4. For a brand new table, large LEAFDIST isn't necessarily bad until its >quite large due to the many page-splits. >5. See DB2/OS390 V5 Admin. Guide, bookmanager ref. 5.9.5.3.1. >HTH, Rick > >In a message dated 1999-09-16 9:09:44 PM Central Daylight Time, >[log in to unmask] writes: > >> I have a number of indexes where the Leafdist has grown significantly since >> they >> were reorg'd only 1 month ago. >> Cardinality seems to have increased around 6-10K each week in most cases. >(i. >> e >> evenly across the weeks). >> >> I'm seeking some tips on how to stop the leafdist rising in the following >> situations: >> 1. Leafdist jumps dramatically once but card increases (non-clustering IX ) >> 2. Leafdist continues to rise dramatically each week (non-clustering IX >and >> PK) >> 3. Leafdist jumps dramatically once, then starts to reduce each week by >> small >> amounts (non-clstr IX and PK) >> >> I have had a look at SYSCOLDIST and the non-key cols have low frequency >xxE- >> 05. >> I have some ideas what to do but would like some confirmation or successful >> solutions that have worked for others. (In his book Mullins makes some >> suggestions based on the coldist - still pondering how to apply this to my >> problem set) >> >> Thanks in advance >> Allan Caldwell > >--DAA03895.937555093/rmx04.globecomm.net-- -- Jacob Haller, Technical Support L-Soft international, Inc http://www.lsoft.com/