Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!pacific.mps.ohio-state.edu!linac!midway!clout!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.misc
Subject: Re: BITFTP grief! (UUNET email-ftp?)
Message-ID: <1991May22.174325.6230@chinet.chi.il.us>
Date: 22 May 91 17:43:25 GMT
References: <81678@bu.edu> <4068@island.COM> <1991May22.081251.1026@uunet.uu.net>
Distribution: na
Organization: Chinet - Chicago Public Access UNIX
Lines: 26

In article <1991May22.081251.1026@uunet.uu.net> asp@uunet.uu.net (Andrew Partan) writes:

>If someone can write some software that can distinguish between
>	customer!customer-node!user
>and
>	customer!non-customer-node!user
>for all customers w/o us having to keep a database of interior customer
>nodes, then we will consider running it.

>Until that point, we would rather use one of our operators to do the
>ftping of files.
>	--asp@uunet.uu.net (Andrew Partan)

If you tell us how your operators can distinguish this without a database,
perhaps someone will suggest how to do it in software.

I'd settle for a requirement that the return address either be only
one hop away in uucp format or in domain format where uunet is the
forwarder for the domain.  The operator request could still be used
in situations where this check fails.

How do you feel about requests like checking the directory of the
test versions of kermit on watsun.cc.columbia.edu on a weekly basis?

Les Mikesell
  les@chinet.chi.il.us