chuq@sun.uucp (Chuq Von Rospach) (07/03/86)
I just noticed that ihnp4 has eaten a batch of mail being sent to it
from Sun because it can't create temp files. If you've sent mail through
"..!sun!ihnp4" over the last while (24 hours<?> as of 5PM July 2) you should
expect that it was eaten and lost. I would expect that ihnp4 is also doing
this to other sites -- this usually means that /usr/spool overflowed. ihnp4
should be considered broken and unreliable (again) until they fix it
(again). If you sent mail through ihnp4, consider resending through an
alternate path if possible or plan on resending it again later.
chuq
--
:From the lofty realms of Castle Plaid: Chuq Von Rospach
chuq%plaid@sun.COM FidoNet: 125/84 CompuServe: 73317,635
{decwrl,decvax,hplabs,ihnp4,pyramid,seismo,ucbvax}!sun!plaid!chuq
Dessert is probably the most important stage of the meal, since it will be
the last thing your guests remember before they pass out all over the table.
-- The Anarchist Cookbookeric@chronon.UUCP (Eric Black) (07/03/86)
In article <4746@sun.uucp> chuq@sun.uucp (Chuq Von Rospach) writes: >I just noticed that ihnp4 has eaten a batch of mail being sent to it >from Sun because it can't create temp files. > [...] >If you sent mail through ihnp4, consider resending through an >alternate path if possible or plan on resending it again later. The neat thing about this kind of thing is that as more of us get "smart" mail routers installed (I've just now got ours using mod.map data, and inter-net gateways and domains are still clumsy and usually unsuccessful), the probability increases that originators of mail have no idea that it was directed to/through a node that did a no-no on the floor, and don't know that they should re-send it. Perhaps sites which perform any out-of-direct-view UUCP path manipulation should log enough information that an SA can cause an informatory message to be sent to the originator with date/time, message ID, original destination, and the altered path, with a warning that it may or may not have gone through, and that there may or may not be any other notification of non-delivery. The heuristics for this are, I'm sure, not pretty... Is it a good idea to try to do this? As we all know, you can't count on UUCP mail getting through (or not being read along the way :-) -- Eric Black "Garbage In, Gospel Out" UUCP: {sun,pyramid,hplabs,amdcad}!chronon!eric