stuart@bms-at.UUCP (Stuart D. Gathman) (04/07/88)
**** Background ****
Quite often, I get failed mail sent back to me. It seems to me that
failed mail is a valuable source of information.
First, I maintain a file of exceptions, one per line. I currently extract
these manually from failed mail. Each failed mail indicates a dead link.
Certain hosts with nasty rerouting habits are also listed. I list uunet as
'dead' because I don't pay for it and I'm sure my net neighbors aren't
anxious to pay for me.
These exceptions are fed to pathalias on the command line with the
'-d' option and shell magic. (If the exception file gets large,
I will modify pathalias to take a '-f' parameter. Isn't having source
wonderful!) This system corrects for the propagation delay in distributing
the maps.
**** Ideas and Questions ****
Is there a way to correct smail without rerunning pathalias? Perhaps
a paths exception file? The exception file would be cleared the next
time pathalias is run. Currently, I just wait until the next pathalias
run to retry manually.
When should exception entries be removed? When a new map entry is
received listing a connection? When the #W line changes on the map
entry(ies) listing the connection? Can this be done automatically in any
way?
What about positive feedback? Is it worthwhile to extract paths from
all news and mail to find unpublished connections to add to the database?
This would have to be automatic. There is too much volume for manual
scanning.
Can smail simply recognize failed mail? It could then copy it to a spool
directory. At the next pathalias run, this mail could be analyzed
(manually or automagically) to extract dead links and merge them with
the exception file. At completion of pathalias, the failed mail could
be retried. Mail where failure was not caused by a specific dead link
would not be retried, but returned to the sender.
Please reply by E-mail as well as or instead of posting. Our machine
has a fixed 30 Meg spool news file system and drops news on heavy flow days.
--
Stuart D. Gathman <stuart@bms-at.uucp>
<..!{vrdxhq|daitc}!bms-at!stuart>lyndon@ncc.UUCP (Lyndon Nerenberg) (04/08/88)
In article <650@bms-at.UUCP> stuart@bms-at.UUCP (Stuart D. Gathman) writes: > I list uunet as >'dead' because I don't pay for it and I'm sure my net neighbors aren't >anxious to pay for me. I don't think this is correct. I have a connection with uunet specifically because uunet is well connected and (usually) gets my mail here faster than the other paths (via alberta or utzoo). Uunet lists us as <ncc>(DEMAND) because I prefer my mail via uunet (all other things being equal), but I don't want to forward UUCP mail that comes in via uunet (we do forward internet mail from uunet). We list our uunet connection as uunet(HOURLY), which says we *are* willing to forward other peoples mail via uunet (HOURLY is a compromise value to keep us from relaying mail for half of Canada and the northwestern US). By listing uunet as DEAD, you are ignoring the explicit recomendations of the system administrators who list mail connections in the maps. If a site doesn't want to relay mail through a site, they don't (or shouldn't) publish that link in the maps. (Case in point: we talk UUCP mail to over 30 sites, however only eight or so are listed in our map entry). "Hidden" sites can be maintained locally through the use of a "local" file that you feed to pathalias along with [ud]*. -- lyndon {alberta,uunet}!ncc!lyndon lyndon%ncc@uunet.uu.net
stuart@bms-at.UUCP (Stuart D. Gathman) (04/08/88)
After rereading the new manual, I see that pathalias already takes
a file of dead hosts and links. The format is:
dead { host
hosta!hostb
...
}
--
Stuart D. Gathman <stuart@bms-at.uucp>
<..!{vrdxhq|daitc}!bms-at!stuart>