HDTenEightyP/NetNews huggingface dataset:
From: ckd@eff.org (Christopher Davis)
Subject: Re: X-Windows mailer
Organization: Electronic Frontier Foundation Tech Central
Date: Fri, 8 Jan 1993 22:50:12 GMT

JRW> == Jan Roger Wilkens <jawil@hpx13.aid.no>

 JRW> What is the best mailer for X-Windows systems?

A Mac, InterCon's PlanetX (or Cayman's XGator), and Eudora. :)

Really, though, it depends on the system and the user.  I just use the
Emacs-based package VM inside epoch (a heavily X-ified version of emacs).
--
Christopher K. Davis      | ``Usenet seems to run much like the Kif (or,
<ckd@eff.org>   EFF #14   |   for the TV generation, Klingon) high command.
System Administrator, EFF |   Whoever takes action and can be heard wins.''
+1 617 864 0665  [CKD1]   |   --Peter da Silva <peter@ferranti.com>
Newsgroups: comp.mail.misc
From: andy@homebase.vistachrome.com (Andy Finkenstadt)
Subject: Re: email to General Electric Information Network
Reply-To: andy@homebase.vistachrome.com
Organization: Vista-Chrome Incorporated
Date: Tue, 12 Jan 1993 04:58:49 GMT

karish@pangea.Stanford.EDU (Chuck Karish) writes:
>GEnie now has a facility for exchanging mail with
>Internet hosts.  Your friend has to subscribe to
>a special service on GEnie.  They charge something
>like $9.40 a month for a mailbox for incoming mail,
>and $0.40 per outgoing message.

Close - that is indeed the old pricing.  The new pricing (Effective
november 1, 1992) is $2 one time registration on the Internet gateway 
and 30 cents per message per 5,000 characters.

>For more details on how to do this, call your friend
>on the phone and suggest that he download the relevant
>information from the Internet roundtable.
>--
>    Chuck Karish          karish@mindcraft.com
>    (415) 323-9000 x117   karish@pangea.stanford.edu

The Internet RoundTable doesn't exist.  However two good places:
the unix roundtable and the genie users' roundtable.  Unix (the 
place that I manage) has two categories dedicated to internet-type
issues and genie users has one topic mostly about pricing and
general info.

-Andy

You can also call 800-638-9636 and talk with GEnie client (customer)
service for more information.

-- 
Andrew Finkenstadt, Vista-Chrome, Inc., Homes & Land Publishing Corporation
GEnie Unix RoundTable Manager, andy@vistachrome.com, andy@genie.geis.com.

"[The author] neither accidentally nor intentionally omits or includes 
anything that could support a preconceived thesis." - C&EN 21-DEC-92 p.72
Newsgroups: comp.mail.misc
From: matt@wardsgi.med.yale.edu (Matt Healy)
Subject: Return and read receipts
Followup-To: comp.mail.misc
Organization: Yale University--Genetics
Date: Tue, 5 Jan 1993 00:48:52 GMT

All this splitting of hairs completely misses what I consider
the most important point: even if we had a closed-loop
feedback from the recipient's eyeballs (showing me the exact
retina image of their CRT with my text), I still do not have
any proof my message was indeed received and acted upon!

I am *serious* here.  For every time any channel of
communication (snail mail, email, voice mail, Fedex,
or whatever) has failed in the technical sense without
giving its equivalent of a bounce, I have experienced
many more cases where a *human* misunderstanding took
place!

The *only* way, regardless of the technical scheme used,
that I can have anything resembling assurance that my
message *really* got through is if the *human* at the
other end replies to me.

Many of the computer companies with which I deal have
voicemail systems.  The machines themselves work just
fine, but the people there sometimes take forever to
reply.  No amount of technology is going to solve
this problem!

Of course I *always* reply promptly to any communication
even when my desktop is 6 inches deep in paper!  (And if
you believe that last sentence I have a great deal in
Florida real estate for you :-) )

Matt Healy
"I pretend to be a network administrator; the lab
 net pretends to work!"

matt@wardsgi.med.yale.edu
Newsgroups: comp.mail.misc,news.newusers.questions
From: drdowns@bach.udel.edu (David R. Downs)
Subject: University of San Jose (CR) on the Internet???
Followup-To: sender
Organization: University of Delaware
Date: Wed, 6 Jan 1993 02:36:48 GMT

As a consultant for the University, I got the following question:

  Is the University of San Jose in Costa Rica on the Internet?  If not, does it
have an email link to the Internet?

All I could find via Gopher and NetFind was:

    huracan.cr (consejo superior universitario centroamericano - csuca,)

Could someone give me the answer to the above question(s)?  If possible
include the mail path.

Thanks for you time.

David

-- 
E-mail: drdowns@brahms.udel.edu   | U  | 20 Conover East | H  | David R. Downs
          downs@cis.udel.edu      | of | Newark DE 19711 | om | RD 2 Box 173 B
       downs@freezer.cns.udel.edu |  D | (302) 837-1969  |  e | Milton DE 19968
Computer & Information Science ** My opinions don't reflect those of the U of D
Xref: sparky comp.mail.headers:423 comp.mail.uucp:2509
From: barrett@daisy.ee.und.ac.za (Alan P Barrett)
Newsgroups: comp.mail.headers,comp.mail.uucp
Subject: Re: Interpretation of RFC-822
Followup-To: comp.mail.headers
Date: 4 Jan 1993 09:59:52 +0200
Organization: Dept. Elec. Eng., Univ. Natal, Durban, S. Africa
NNTP-Posting-Host: daisy.ee.und.ac.za
Keywords: whitespace, structured headers, destination

[redirecting to comp.mail.headers  --apb]

In article <yLmTwB4w165w@valinor.mythical.com> in comp.mail.uucp,
stu@valinor.mythical.com (Stu Labovitz) writes:
> Now that we've covered what I believe are the relevant sections of the
> RFC, here's the question:  Does RFC #822 provide limits (either minimum or
> maximum) upon the number of SPACE characters that separate the "To:" from
> the mailbox on the destination line?  Must there be at least one SPACE,
> and is there any reasonable interpretation to prevent the existance of
> more than one SPACE?

There are no limits in RFC822.  RFC821 specifies a maximum line length
of 1000 chars (a sender may not transmit longer lines, but a receiver
is encouraged to accept longer lines).

RFC822 section 3.1.4 says that the free insertion of linear-white-space
is permitted between lexical tokens.  A cursory reading of this section
may suggest that it applies only to structured field bodies, but I
believe that the same rule applies to space between the field-name
and the colon, and to space between the colon and the first token in
the field-body.  I believe that this position is supported by clues
in section 1.1 ("The formal definition is divided into four levels ...
the second level describes basic lexical analysers that feed tokens to
higher-level parsers"), section 3.1.2 ("Field names, unstructured field
bodies and structured field bodies are eached scanned by their own,
independent \"lexical\" analyzers"), sections A.3.1 and A.3.2 (examples
in which there is no space between the field-name and the colon, and a
variable amount of space after the colon), and section A.3.3 (an example
in which there is space between the field-name and the colon).

In other words, if we consider the  definition of a field,

    field          =       field-name ":" [ field-body ] CRLF

we see that the field-name, the colon, and the first token of the
field-body are three separate tokens, which may be separated by any
amount of linear-white-space, including no space at all.

--apb
Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa
RFC822: barrett@ee.und.ac.za                    Bang: m2xenix!undeed!barrett
Newsgroups: comp.mail.headers
From: rickert@mp.cs.niu.edu (Neil Rickert)
Subject: Re: discrepancies between RFC821 and RFC822 (as amended by RFC1123) regarding Received headers
Organization: Northern Illinois University
Date: Mon, 11 Jan 1993 17:50:33 GMT

In article <1993Jan10.162048.22777@blilly.uucp> bruce@blilly.uucp (Bruce Lilly) writes:
>I have found a few discrepancies between RFC821 and RFC822 regarding the
>contents of the Received header.
>
>1)	RFC821 section 4.1.1 requires the "from" and "by" clauses, while
>	RFC822 4.1 lists them as optional.

I don't believe this is a discrepancy.  RFC821 is only discussing the
new "Received:" header it adds, and is not referring to any pre-existing
header.

>2)	RFC821 prohibits unquoted special characters (including '<', '>',
>	and '@') in the optional "id" clause, while RFC822 requires that the
>	format of the msg-id used in that clause, if present, is
>		"<" local-part "@" domain ">".

The "id" clause is not the same as the msg-id.  That is, the msg-id, or
more fully, the "Message-ID:" header is a unique identifier of the
message.  The "id" clause in the "Received:" header could be just a
transaction ID with purely local meaning.  It might, for example, be an
identifier which can be used to locate log records retained on this
host.

>                                                              If the "by"
>clause is always provided, mail loops can be more quickly and more reliably
>detected by processing the information in the headers, but it is not
>acceptable for the machine to place any interpretation on comments.

If you really want to process the contents of "Received:" headers for
finding mail loops, what you need is the requirement that such headers
not be modified.  Then if there is a previous header from your own host,
there is a loop.  The exact syntax of headers generated by hosts other
than yours would seem to be of no importance.  I presume that your
sofware can be designed to recognize the "Received:" headers it has
generated.

Newsgroups: comp.mail.headers
From: john@chance.gts.org (John R MacMillan)
Subject: Re: Return and read receipts (was Re: Return-Receipt-To & forwarding...)
Organization: $HOME
Date: Sun, 3 Jan 1993 22:04:59 GMT

|>|Lack of a bounce message tells me nothing useful:
|>|	the message might have been delivered successfully to the
|>|		intended destination
|>
|>By far the most likely of the possibilities.
|
|On what mathematical analysis or statistical evidence do you base that assertion?

None, of course.  I base it on quite a lot of personal experience.
Email has been getting better every year, ever since I've been using
it; more of my mail gets through, and I get bounces almost all the
time it doesn't.  Your mileage may vary, but I doubt it varies by much.

|I never claimed that that other information, mentioned in a sidebar, was
|useful as an indication of receipt.  Why are you trying to put words into my
|mouth?

I certainly did not intend to, and if you think I was, I apologize.  I
assumed that since you brought up that information in a discussion
about the value of receipts as delivery indicators, you felt it was
somehow relevant.  Again my apologies if you knew it was irrelevant.

|Sounds more like you were trying to twist the previous poster's wording
|around to suit your own preconceived notions.

I already discussed this with Steve, but that was not my intent.  The
intent was to point out the preconceived notions people have about
these receipts, that is, that they represent proof.  I think we all
agree that this is not the case, but plenty of naive users do not know
this.  Strong words, such as proof, encourage this belief.

|As long as you're going to be pedantic, ``failure to receive a bounce'' is no
|indication (of successful delivery) at all.

Sure it is.  If mail is as unreliable as you seem to think, it's not a
very good indication, but if it's as reliable as I think it is, it's
not a bad indication.

We can continue to bicker about this indefinitely, but I'm afraid it
won't get either of us anywhere; this argument has been going on for
as long as I've used email, and I'm getting rather tired of it.  Make
you a deal, you can continue to use Return-Receipt-To, and I'll
continue to drop all mail with non-standard headers. :-)

Seriously, I've said all I can say on the topic.  Good night, Gracie.
Newsgroups: comp.mail.headers
From: o.CRepin-leblond@ic.ac.UK (Olivier M.J. Crepin-Leblond, Olivier M.J. 
      Crepin-Leblond)
Subject: Release of FAQ top-level-domains
Organization: Imperial College, London, UK.
Date: Wed, 6 Jan 1993 15:47:05 GMT

The FAQ list of top-level domains, has recently been distributed 
around Usenet and is available in news.answers. 

Modified extract of the document:

      Every now-and-then there are enquiries on the net regarding
email to a distant country. The question is often of the type
"has that country got email access ?". The following table is a
guide of top-level country names, showing the countries which have
access to internet or general email services. The top-level country
codes have been derived from the International Standards Organisation
international standard ISO 3166, except for United Kingdom which should
be called Great Britain (GB) instead of UK. The field GB is used mainly
in the X.400 addressing of United Kingdom sites.

    Once released, this document, entitled top-level-domains ,  is 
archived in a number of archive sites around the world. Amongst
them:


pit-manager.mit.edu (18.172.1.27) directory: /usenet/news.answers
ftp.uu.net          (137.31.1.9) directory: /usenet/news.answers
lth.se            (130.235.16.3) directory: /archive2/netnews/news.answers
unix.hensa.ac.uk   (129.12.21.7) directory: /pub/uunet/usenet/news.answers
grasp1.univ-lyon1.fr (134.214.100.25) directory: /pub/faq

also via listserv request: listserv@grasp1.univ-lyon1.fr
with the command: get faq top-level-domains

The up-to-date, pre-release document is also available using an
experimental simple mail-server that I have setup from my account.
Send email to: <ocl@ic.ac.uk> with a subject: archive-server-request
and the command: get top-level-domains   in the body of your message.
Please use only lowercase letters.
This server will recognise *most* addresses.


-- 
Olivier M.J. Crepin-Leblond, Digital Comms. Section, Elec. Eng. Department
 Imperial College of Science, Technology and Medicine, London SW7 2BT, UK
       Internet/Bitnet: <foobar@ic.ac.uk> - Janet: <foobar@uk.ac.ic>
From: kehres@ima.com (Tim Kehres)
Newsgroups: comp.mail.headers
Subject: Re: Return-Receipt-To & forwarding...
Date: 6 Jan 93 00:29:54 GMT
Organization: International Messaging Associates, Menlo Park, California

In article <9212311441.AA06064@TIS.COM> avolio@TIS.COM writes:
| 
| Among other things needed is a clearer definition or, more exactly, a
| model to follow.  Clearly, this is not the model of Certified Mail in
| the U.S. Postal System.  Certified Mail gets a return receipt sent to
| the sender if the delivery agent delivered the mail.  Also, it gets
| signed and stamped in an official, trusted manner.  

I'm not sure that an exact mapping of the way the U.S. Postal system does
things is necessarily a good thing.  As you say, the postal system return
receipt is not what I was describing.  I think that a reasonable analogy
would be the the postal return receipt would correspond to a MTA delivery
report.  A user agent return receipt in the USPS world would be more like
the postman coming into your home or business, watching you open you mail,
and then writing a report back to the sender indicating it had been opened.

| 1. Certified Mail -- the compliant MTA certifies delivery to the
| mailbox.  There may be an option to have this be digitally signed by
| the system to have a valid and acceptable time stamp (like a Post
| Office rubber date stamp).

This is an interesting option - but one that I don't believe would be
necessary for most applications.  Perhaps if we were to come up with a
mechanism that would work with and without digital signitures?

| 2. Read Receipt Requested.  The compliant UA should indicate "A Read
| Receipt was requested.  Shall I send one?"  For non-smart UA's, The
| header line should indicate to the reader that they are being asked to
| confirm their reading it.

It should also be acceptable if the remote UA were to do nothing with
the request.  The key here is that it is a "request".

Best Regards,

Tim Kehres
From: uucpmap@rutgers.rutgers.edu (UUCP Mapping Project)
Newsgroups: comp.mail.maps
Subject: UUCP map for u.grc.0
Date: 8 Jan 93 11:23:24 GMT
Expires: 22 Feb 93 11:23:21 GMT
Supersedes: <Dec.8.07.55.00.1992.3541@rutgers.rutgers.edu>

:	This is a shell archive.
:	Remove everything above this line and
:	run the following text with /bin/sh to create:
:	u.grc.0
: This archive created: Fri Jan  8 06:23:18 1993
echo shar: extracting u.grc.0
cat << 'SHAR_EOF' > u.grc.0
# Copyright (c) 1991, 1992 EurOpen. All rights reserved.
# Information may be used for non-commercial purposes.
#
# u.grc.0;  changes to: uucpmap@ariadne.uucp
# file one of two : u.grc.[01]
# Last change:	Sun Oct 18 20:41:00 EET 1992
#
 
#N	ariadne, pythia, greece.eu.net
#S	SUN-3/280S; UNIX SUN-OS 4.0.3
#O	Foundation of Res & Tech Hellas, Computer Science Institute
#C	Stelios Sartzetakis
#E	netman@ariadne.uucp
#T	+30 81 221171, 229368, x229342, x229343
#P	Daidalou 36, P.O. Box 1385, Heraklion, Crete, Greece 71110
#L	25 09 E / 35 20 N
#R 	pythia.uucp == ariadne.uucp == ARIADNE.BITNET; Greek EUnet backbone site
#R	connected via GREARN; Help : postmaster@csi.forth.gr;
#R
#U	inria, goya, mcsun, sunic, ukc, unido
#U	theseas
#W	stelios@ariadne.uucp, Sun Oct 18 20:41:00 EET 1992
#
ariadne	.gr
ariadne	.forth.gr
ariadne	.csi.forth.gr
ariadne	= forth.gr
ariadne	= csi.forth.gr
ariadne	= pythia.csi.forth.gr
pythia = pythia.csi.forth.gr

### National links
ariadne	aello(WEEKLY), algo(DAILY), alicia(DAILY),
	ctc(DAILY), daphne(WEEKLY), danbo(DEMAND), epstech(DAILY),
	evelyn(DAILY), intra(DAILY),
	sirius(DAILY), statik(DAILY), theseas(DAILY/3),
	trust(DEAD), vergina(DEAD), xanthi(DAILY)

### Connections through IP/X.25
ariadne	isosun(LOCAL), elsyp(LOCAL)

# End of file u.grc.0
SHAR_EOF
:	End of shell archive
exit 0
From: uucpmap@rutgers.rutgers.edu (UUCP Mapping Project)
Newsgroups: comp.mail.maps
Subject: UUCP map for u.dom.1
Date: 8 Jan 93 11:20:46 GMT
Expires: 22 Feb 93 11:20:45 GMT
Supersedes: <Dec.8.07.52.17.1992.2906@rutgers.rutgers.edu>

:	This is a shell archive.
:	Remove everything above this line and
:	run the following text with /bin/sh to create:
:	u.dom.1
: This archive created: Fri Jan  8 06:20:41 1993
echo shar: extracting u.dom.1
cat << 'SHAR_EOF' > u.dom.1
# u.dom.1 - pleasant@rutgers.edu - Sun Mar 11 22:36:56 EST 1990

#N	microc	
#S	386 IBM Clone
#O	Microcomputos, S.A.
#C	Luis Caamano
#E	microc!lpc
#T	+1 809 530 8506
#P	P.O.Box 1065, Santo Domingo, Dominican Republic
#L	18 30 N / 69 57 W city
#R	
#W	jane@uunet.UU.NET (Jane Roop); Thu Feb  1 15:55:12 EST 1990
#U
#
microc	uunet(DEMAND)

#  End of u.dom.1
SHAR_EOF
:	End of shell archive
exit 0
From: uucpmap@rutgers.rutgers.edu (UUCP Mapping Project)
Newsgroups: comp.mail.maps
Subject: UUCP map for u.nic.1
Date: 8 Jan 93 11:24:37 GMT
Expires: 22 Feb 93 11:24:36 GMT
Supersedes: <Dec.8.07.58.39.1992.4468@rutgers.rutgers.edu>

:	This is a shell archive.
:	Remove everything above this line and
:	run the following text with /bin/sh to create:
:	u.nic.1
: This archive created: Fri Jan  8 06:24:35 1993
echo shar: extracting u.nic.1
cat << 'SHAR_EOF' > u.nic.1
# u.nic.1 - pleasant@rutgers.edu - Sun Apr 21 22:54:52 EST 1989

#N	uninic
#S
#O	Universidad Nacional de Ingenieria, Escuela de Ingenieria en Computacion
#C	Cornelius Hopmann
#E	uninic!cornelio
#T
#P	AP: 5595, Managua, Nicaragua
#L	12 10 N / 88 20 W city
#R
#W	rick@uunet.UU.NET (Rick Adams); Fri Mar 24 15:12:33 EST 1989
#U	uunet
#
uninic	uunet(DEMAND)
SHAR_EOF
:	End of shell archive
exit 0
From: uucpmap@rutgers.rutgers.edu (UUCP Mapping Project)
Newsgroups: comp.mail.maps
Subject: UUCP map for u.arg.se.1
Date: 8 Jan 93 11:12:04 GMT
Expires: 22 Feb 93 11:12:03 GMT
Supersedes: <Dec.8.07.48.45.1992.2088@rutgers.rutgers.edu>

:	This is a shell archive.
:	Remove everything above this line and
:	run the following text with /bin/sh to create:
:	u.arg.se.1
: This archive created: Fri Jan  8 06:11:58 1993
echo shar: extracting u.arg.se.1
cat << 'SHAR_EOF' > u.arg.se.1
# u.arg.se.1

# UUCP Maps for Sgo. del Estero - Thu Dec 27 13:34:10 GMT-3:00 1990

#N	cytsant
#S	IBM-XT comp.; MS-DOS 3.3
#O	Inst. Invest. Astronomica y Cs. Exactas
#C	Carlos Garcia Eberle
#E	cytsant!postmaster
#T	+54 85 22 2017, +54 85 21 5102
#P	Parana 509, (4200) Santiago del Estero, ARGENTINA
#L	34 34 S / 58 03 W city
#U
#W	cytsant!postmaster ( Carlos Garcia Eberle ); Wed Oct 24 10:18:04 ARG 1990
cytsant = cytsant.edu.ar
cytsant	dcfcen(DEAD)

#N	provg
#S	Compatible IBM AT 286; MS-DOS 3.3
#O	Inst. de Inv. Astronomicas y Ccias. Exactas - Sgo. del Estero
#C	Carlos A. Garcia Eberle
#E	provg!postmaster
#T	+54 85 21 5102 ; +54 85 22 2017
#P	Av. Rivadavia 351, (4200) - Sgo. del Estero - ARGENTINA
#L	
#R	
#U	
#W	secyt!ceci (Cecilia M. Sarmiento); Thu Jun 20 17:51:26 ARG 1991
provg = provg.gov.ar
provg secyt(DAILY)
SHAR_EOF
:	End of shell archive
exit 0
From: uucpmap@rutgers.rutgers.edu (UUCP Mapping Project)
Newsgroups: comp.mail.maps
Subject: UUCP map for u.eur.fra.1
Date: 8 Jan 93 11:21:33 GMT
Expires: 22 Feb 93 11:21:32 GMT
Supersedes: <Dec.8.07.52.40.1992.2978@rutgers.rutgers.edu>

:	This is a shell archive.
:	Remove everything above this line and
:	run the following text with /bin/sh to create:
:	u.eur.fra.1
: This archive created: Fri Jan  8 06:21:30 1993
echo shar: extracting u.eur.fra.1
cat << 'SHAR_EOF' > u.eur.fra.1
# u.eur.fra.1 - uucpmap@frmug.fr.mugnet.org - Mon Oct 19 18:17:57 EDT 1992
# 
#  This file is now obsolete.  All new information is contained within file
#  u.fra.100.
#
#
SHAR_EOF
:	End of shell archive
exit 0
From: uucpmap@rutgers.rutgers.edu (UUCP Mapping Project)
Newsgroups: comp.mail.maps
Subject: UUCP map for u.nor.100
Date: 8 Jan 93 11:25:01 GMT
Expires: 22 Feb 93 11:25:01 GMT
Supersedes: <Dec.8.07.59.24.1992.4619@rutgers.rutgers.edu>

:	This is a shell archive.
:	Remove everything above this line and
:	run the following text with /bin/sh to create:
:	u.nor.100
: This archive created: Fri Jan  8 06:24:59 1993
echo shar: extracting u.nor.100
cat << 'SHAR_EOF' > u.nor.100
#   u.nor.100; last changed 910927 hph
#
#       Copyright 1991 by UNINETT. All rights reserved.
#       Permission is granted for non-commercial use.
#
#   changes to uucpmap@nac.no
#
#   file two of two
#
# #W lines show 2 dates: date of introduction and date of last change.
#

#N  ugle.unit.no
#S  SparcStation-1+/SunOS4.1
#O  University of Trondheim
#C  Havard Eidnes
#E  usenet@ugle.unit.no
#T  +47 7 594468
#P  Sintef Runit, N-7034 Trondheim, Norway
#L  63 25 N / 10 24 E city
#R  Presently main NNTP in-node for news to Norway
#U  sunic, seunet, nuug, news.kth.se, ifi, barsoom.nhh.no,
#U  alf.uib.no, mack.uit.no, humpty 
#W  Havard.Eidnes@runit.sintef.no 261191 Havard.Eidnes@runit.sintef.no 261191
SHAR_EOF
:	End of shell archive
exit 0
From: uucpmap@rutgers.rutgers.edu (UUCP Mapping Project)
Newsgroups: comp.mail.maps
Subject: UUCP map for u.usa.ma.5
Date: 8 Jan 93 11:29:46 GMT
Expires: 22 Feb 93 11:29:45 GMT
Supersedes: <Dec.8.08.03.48.1992.5591@rutgers.rutgers.edu>

:	This is a shell archive.
:	Remove everything above this line and
:	run the following text with /bin/sh to create:
:	u.usa.ma.5
: This archive created: Fri Jan  8 06:29:40 1993
echo shar: extracting u.usa.ma.5
cat << 'SHAR_EOF' > u.usa.ma.5
file {u.usa.ma.5}
#	start of u.usa.ma.5: Sat Sep 26 12:47:56 EDT 1992
#	maintained by nemap@harvard.edu
#	Please send all updates/new-entries
#	to: uucpmap@rutgers.{uucp,edu}
#
#	this file has been merged back into u.usa.ma.[1-4]

#	end of u.usa.ma.5: Sat Sep 26 12:48:02 EDT 1992
SHAR_EOF
:	End of shell archive
exit 0
From: uucpmap@rutgers.rutgers.edu (UUCP Mapping Project)
Newsgroups: comp.mail.maps
Subject: UUCP map for u.che.10
Date: 8 Jan 93 11:19:31 GMT
Expires: 22 Feb 93 11:19:30 GMT
Supersedes: <Dec.8.07.50.27.1992.2497@rutgers.rutgers.edu>

:	This is a shell archive.
:	Remove everything above this line and
:	run the following text with /bin/sh to create:
:	u.che.10
: This archive created: Fri Jan  8 06:19:27 1993
echo shar: extracting u.che.10
cat << 'SHAR_EOF' > u.che.10
# u.che.10 renamed to u.che.100
SHAR_EOF
:	End of shell archive
exit 0