LSTOWN-L Archives

LISTSERV List Owners' Forum

LSTOWN-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Jacob Haller <[log in to unmask]>
Fri, 17 Sep 1999 10:03:39 -0400
text/plain (226 lines)
>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/

ATOM RSS1 RSS2