THis is from our sysop= The bottom line is that it is NOT a UMASS error that
is causing delays. Please check with Compuserve.
[Quote from one of your subscribers]
> >This may be unnecessary, since everything is back to normal, but I just
> >went thru what compuserve calls my "filing cabinet," an easy way to file
> >mail, and it makes the delay quite clear, because the list gives the
> >digest date as titled, and the date rec'd by compuserve. I'm not sure
> >whether that latter date is the date compuserve gets it, or the date I
> >log it on, but since I check for lactnet 3 to 5 times a day, and on
> >Wednesday the 14th, must have checked 8 times at least (not used to "no
> >mail"!), it essentially amts to the same thing.
It was interesting to see that list ... still, "the date CompuServe gets
it" is a third variable from what she's showing, based on the info I have a
bit lower in this message. What we really need, here, is a delayed message
with *all* its RFC822 headers, or at least all the "Received:" lines
intact. That would show exactly where the delay is occurring.
However, at this point, it's probably not worthwhile to follow much more up
with *me*, because I've found out enough to see that the delay is not on
our end, and also not in CompuServe's *receipt* of the message ... it must
therefore be somewhere in CompuServe's internal mail handling system. This
is easy to imagine -- they're BIG, and probably mail goes through several
internal hops before getting to the subscriber. In this case, one of the
hops took a day or so.
FYI, the here are our delivery records for 6/14 digests sent to CompuServe.
I'll also write a short "translated" table below the full records:
---------------------------------------------------------------------------
Jun 14 11:52:36 library sendmail[29169]: LAA29168:
to=<[log in to unmask]>,<[log in to unmask]>,<76723.3336@COMPUSE
RVE.COM>,<[log in to unmask]>,<[log in to unmask]>,<73741.2117
@COMPUSERVE.COM>,<[log in to unmask]>,<75472.
[log in to unmask]>, delay=00:03:26, mailer=smtp,
relay=mailgate.compuserve.com. [198.4.7.4], stat=Sent (LAA27669 Message
accepted for delivery)
Jun 14 15:02:54 library sendmail[30125]: PAA30124:
to=<[log in to unmask]>,<[log in to unmask]>,<76723.3336@COMPUSE
RVE.COM>,<[log in to unmask]>,<[log in to unmask]>,<73741.2117
@COMPUSERVE.COM>,<[log in to unmask]>,<75472.
[log in to unmask]>, delay=00:01:46, mailer=smtp,
relay=mailgate.compuserve.com. [198.4.7.1], stat=Sent (PAA08664 Message
accepted for delivery)
Jun 14 21:05:06 library sendmail[32050]: VAA32049:
to=<[log in to unmask]>,<[log in to unmask]>,<76723.3336@COMPUSE
RVE.COM>,<[log in to unmask]>,<[log in to unmask]>,<73741.2117
@COMPUSERVE.COM>,<[log in to unmask]>,<75472.
[log in to unmask]>, delay=00:00:29, mailer=smtp,
relay=mailgate.compuserve.com. [198.4.7.1], stat=Sent (VAA14947 Message
accepted for delivery)
---------------------------------------------------------------------------
Our queue ID Del time Del delay CIS system accepting CIS queue ID
LAA29168 11:52:36 3:26 mailgate 198.4.7.4 LAA27669
PAA30124 15:02:54 1:46 mailgate 198.4.7.1 PAA08664
VAA32049 21:05:06 0:29 mailgate 198.4.7.1 VAA14947
As you can see, delivery time from us to CIS is pretty good -- those times
are in minutes and seconds! This is only for the "special issue" digests,
by the way -- they were a tiny bit easier for me to get info on, and I
figured this was enough info.
If you or one of the CIS subscribers wants to follow this up with CIS, the
CIS queue ID's above will be useful to their sysops ...
Norm
--
Be braver. You cannot cross a chasm in two small jumps.
*********************************************************************
Kathleen B. Bruce RN, BSN, IBCLC (email = [log in to unmask])
"Personally I am always ready to learn, although I do not always
like being taught." Winston Churchill
**********************************************************************
|
