HDTenEightyP/NetNews huggingface dataset:
From: Erik Naggum <enag@ifi.uio.no>
Organization: Department of Informatics, University of Oslo, Norway
Date: 09 Sep 1992 16:43:27 +0200
Subject: Re: I need to add an "Originally-From:" header to my mailing list posts.

Steven D. Majewski <sdm7g@aemsun.med.Virginia.EDU> writes:
|
|   Another possible format is:
|
|   From: originator@some.where
|   Sender: sfraves-request@other.place
|   Reply-To: sfraves@other.place

Please don't.  This causes a large number of misaddressed messages, and
makes naive users unnecessarily involved in headers, since they can't
reply to the author without replying to the whole list.

This problem is compounded if the messages is crossposted to several
lists.

We should have learned from BITNET listservers by now, although they
seem to be very hard dying.

Best regards,
</Erik>
--
Erik Naggum             |  ISO  8879 SGML     |      +47 295 0313
                        |  ISO 10744 HyTime   |
<erik@naggum.no>        |  ISO 10646 UCS      |      Memento, terrigena.
<enag@ifi.uio.no>       |  ISO  9899 C        |      Memento, vita brevis.
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Newsgroups: comp.mail.headers
Subject: Re: Reply-To: rewrite
Date: 6 Sep 92 14:28:55 GMT
Article-I.D.: rhyolite.pgrgjug
Organization: Silicon Graphics, Inc.  Mountain View, CA

In article <11-PCNews-124beta@pos.pub.uu.oz.au>, Mark.Purcell@pos.pub.uu.oz.au (Mark Purcell) writes:
> jwt@duke.cs.duke.edu (Jeffrey W. Tannehill @ Duke University Computer Science Dept.; Durham, N.C.) once wrote....
> >
> >	When receiving mail via a uucp connection our mail software modifies 
> >the "Reply-To:" header on the message.  For example, the header 
> >
> >	Reply-To: testuser@testhost.testdomain.test
> >
> >may be modified to be:
> >
> >	Reply-To: hornet!duke!testhost.testdomain.test!testuser
> 
> I find it a real pain in the ass the way some uucp sites will take a FQDN 
> and modify
> it into a mess of UUCP addressing, which may or may not make sense at the
> other end.  Usually they don't make any sense.  So <replying> to mail
> does not work, amongst other problems.
> 
> It's bad enough when sites munge the From: line but there is a saving
> grace which is the Reply-To: header which most will not munge.  But if that
> starts getting changed then there is really no hope for mail getting back.
> 
> I am of the opinion that if an address if a FQDN that it shouldn't be UUCP
> munged as a FQDN should make sense from anywhere :-).


Well, it would be nice if FQDN's worked everywhere.  Unfortunately,
the root servers don't respond very quickly over UUCP links.


A UUCP gateway necessarily must translate from whatever is happening on
the Internet to whatever is right in the connected UUCP world.

That necessarily means rewriting all addresses appropriately.  In some
UUCP worlds, only !-paths work.  In other UUCP worlds, machine
understand FQDN's.  Reasonable Internet-UUCP gateways re-write FQDN's
or not depending on whether the other end understands FQDN's.  Years
ago, I found it necessary to to assume the other end does not do FQDN's
unless told otherwise.  More recently, it has been effective to assume
FQDN's are understood unless bounces are seen.

Sendmail, for example, does not distinguish between Reply-To: and
From:  It sends them through the same re-write rules, and has since
version 5.39, 85/01/05, according to version.c.


Vernon Schryver,  vjs@sgi.com
Newsgroups: comp.mail.headers
Subject: Re: Reply-To: rewrite
From: denny@alisa.com (Bob Denny)
Date: Sun, 6 Sep 1992 20:16:10 GMT
Organization: Alisa Systems, Inc.

In <11-PCNews-124beta@pos.pub.uu.oz.au> 
   Mark.Purcell@pos.pub.uu.oz.au (Mark Purcell) writes:

> [...]
> 
> I am of the opinion that if an address if a FQDN that it shouldn't be UUCP
> munged as a FQDN should make sense from anywhere :-).
> 
> Any thoughts?

Yes, I agree! As far as I am concerned, it has been LONG ENOUGH for bang
path addressing (and it's SMTP cousin, @-path addressing) to be exorcised
from end-user exposure. That stuff is low-level source routing, and is the
property of the mail transport. RFC976 specifies it for uucp, and RFC821
specifies it for SMTP. Messing with the RFC822 headers of a message should
be verboten.

Unfortunately, enough people haven't caught up to the modern way on UUCP,
so it's "safe" to pre-route a return path and/or a from. All this does is
prolong the agony. 

"If you can't route UUCP (no pathalias/maps), send your messages to a
system that can (smart-host)" -- Bob Denny, September 1992.

  :-)  :-)  :-)

_______________________________________________________________________________
Robert B. Denny                                           voice: (818) 792-9474
Alisa Systems, Inc.                                         fax: (818) 792-4068
Pasadena, CA                         (denny@alisa.com, ..uunet!alisa.com!denny)
From: Mark.Purcell@pos.pub.uu.oz.au (Mark Purcell)
Newsgroups: comp.mail.headers
Subject: Re: Reply-To: rewrite
Date: 4 Sep 92 15:10:4 GMT
Organization: Me?  Organized?

jwt@duke.cs.duke.edu (Jeffrey W. Tannehill @ Duke University Computer Science Dept.; Durham, N.C.) once wrote....
>
>	When receiving mail via a uucp connection our mail software modifies 
>the "Reply-To:" header on the message.  For example, the header 
>
>	Reply-To: testuser@testhost.testdomain.test
>
>may be modified to be:
>
>	Reply-To: hornet!duke!testhost.testdomain.test!testuser
>

I find it a real pain in the ass the way some uucp sites will take a FQDN 
and modify
it into a mess of UUCP addressing, which may or may not make sense at the
other end.  Usually they don't make any sense.  So <replying> to mail
does not work, amongst other problems.

It's bad enough when sites munge the From: line but there is a saving
grace which is the Reply-To: header which most will not munge.  But if that
starts getting changed then there is really no hope for mail getting back.

I am of the opinion that if an address if a FQDN that it shouldn't be UUCP
munged as a FQDN should make sense from anywhere :-).

Any thoughts?

Mark

----
Mark Purcell, 62/25 Market Street, SYDNEY NSW 2000.  (02) 283 5598
	Mark.Purcell@pos.pub.uu.oz.au, msp@kralizec.zeta.org.au

Newsgroups: comp.mail.headers
From: SEB1525@MVS.draper.com (Steve Bacher)
Subject: Re: Public domain RFC822 header parsing code?
Organization: Draper Laboratory
Date: Sat, 12 Sep 1992 22:41:00 GMT

In article <1992Sep11.165855.12826@twg.com>,
"David Herron" <david@twg.com> writes:

>> Can anybody point me to some freely available code, preferably in C,
>> for parsing RFC822 headers - specifically email addresses as would
>> appear in a To: header?  The completer the better.
>
>Yes.
>
>Look in any comp.sources.misc archives and you'll find one written
>in YACC.  (posted by me many many moons ago while I was still a
>junior level E-Mail hacker known to the world as `david@ms.uky.edu').

...

Er - I guess I should have (also) said, "preferably some that DOESN'T
use lex or yacc"?  Y'see, I am hoping to use this in a (gasp!) IBM
mainframe email system, among other things...

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
From: bbehlen@soda.berkeley.edu (Vitamin B (Brian Behlendorf))
Newsgroups: comp.mail.headers
Subject: I need to add an "Originally-From:" header to my mailing list posts.
Date: 7 Sep 1992 20:31:42 GMT
Organization: U.C. Berkeley, CS Undergraduate Association
Distribution: world
NNTP-Posting-Host: soda.berkeley.edu

	Apologies in advance for the newbie question, but the sendmail man
page was not helpful about this.  I run a mailing list out of this machine
called sfraves, with about 215 users.  Right now the "From:" line reads
"sfraves-request", so that only I will have to deal with MAILER DAEMON 
problems and not the original writer of whatever gets posted to the list.
On most machines, the name and address of the original writer does stay in
the header, so people can tell who wrote a particular post.  However, some
mail programs seem to strip away that second "From:" line, so that every 
piece of mail seems to come from "sfraves-request", and the real writer's
name is unknown.  So, I would like to add an "Originator:" or "Originally
From:" line to every post that goes through the sfraves alias, so that
those people with the messed-up mail programs can still see who the original
writer is, with bounced messages still going to sfraves-request.

How would I go about doing this?  It would be much preferable if it were
simply some option to the "|/usr/lib/sendmail -odp -oi -fsfraves-request..."
line in my /usr/lib/aliases.

	Thank you in advance,
		Brian
Newsgroups: comp.mail.headers
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.mail.headers
Subject: How many headers exist?
Date: 8 Sep 92 03:34:50 GMT

Well, there are no articles here in this newsgroup, but it  seems  the
right place to ask, and maybe people will reply via email ...

What  I've been doing is writing my own program that grovels through a
message's headers and tries to generate headers for a reply.  I've got
it  working  pretty  well  in most cases, but there are quite a lot of
interesting and amusing headers that  I've  never  seen  and/or  don't
quite know how to decipher.  So I was wondering whether there might be
any sort of summary of what to expect from email headers.

There are of course some RFCs on this subject, but I  don't  have  any
Internet  access  at  the  moment, and so I don't know how to go about
finding out the latest suggestions there.  Even if I did,  it's  clear
that   many  implementors  consider  such  "standards"  to  be  merely
interesting guidelines, to be casually violated whenever they can come
up  with a Better Idea.  I'm more interested in what I can learn about
reality than about some committee's decrees.

Are there any useful summaries of existing email headers and the rules
(such  as  they  may be) for how they are formatted?  Or should I just
continue collecting headers and making my own guesses as to what  they
might possibly mean?

I've occasionally seen messages from several mailers'  daemons  (e.g.,
the  one  on  the snorkelwacker system) directed to my system's usenet
package, chiding it for the email paths it generates. Think of it: One
piece  of  software  is chewing out another for violating the former's
rules.  But perhaps I can do something  about  it  in  my  own  header
munger, if I can only learn more about what the rules might be.

-- 
All opinions Copyright (c) 1992 by John Chambers. Inquire for licensing at:
1-617-647-1813 ...!{bu.edu,harvard.edu,eddie.mit.edu,ruby.ora.com}!minya!jc 
--
Pensu tutmonde; agu loke.
Newsgroups: comp.mail.headers,comp.mail.uucp
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Reply-To: rewrite
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Mon, 7 Sep 1992 14:59:46 GMT

In article <bu76bk.hhx@wang.com>, fitz@wang.com (Tom Fitzgerald) writes:
> vjs@rhyolite.wpd.sgi.com (Vernon Schryver) writes:
> 
> > A UUCP gateway necessarily must translate from whatever is happening on
> > the Internet to whatever is right in the connected UUCP world.
> > That necessarily means rewriting all addresses appropriately.  In some
> > UUCP worlds, only !-paths work.
> 
> I think the only world where this is still true is AT&T.  Everywhere else,
> probably 99% of the UUCP sites, now understand domain addresses.  And many
> of the sites that do require !-paths, (people running unmodified AT&T
> SysV.2, old Xenixes, etc.) don't honor Reply-To: for return addresses
> anyway, they use the From_ line.
> 
> Even for those few sites that only understand ! paths, you're not doing
> them a favor by rewriting domain addresses into !s unless you're a direct
> neighbor, because after one or two more hops, the original !-path has often
> been mutilated into something that is not only wrong, but can't even be
> hand-translated back into a working !-path.  At least an untouched
> @-address can be rewritten by hand into a !-path on non-domainist sites.

But of course you should not rewrite except based on what your direct
neighbor requires.  That's part of the definition of "gateway".


> > Years
> > ago, I found it necessary to to assume the other end does not do FQDN's
> > unless told otherwise.  More recently, it has been effective to assume
> > FQDN's are understood unless bounces are seen.
> 
> Very much so - and even if bounces are seen, it's worth checking with the
> owner of the affected site and letting him/her know about it first.  It's
> often easier to get someone to install smail 2.5 or something, than deal
> with the continual problems caused by rewriting domain addresses into
> !-paths.

That is one way.  There are other attitudes.  After a few years and
hundred UUCP neighbors, some people get tired of reforming the world,
and just let people do whatever they silliness they want within
limits.  Eventually you just pick a list of minimal requirements (e.g.
name in the maps or registered FQDN, >= 2400 b/s modem unless news
wanted, no more than a few bounces/week) and refuse connections unless
unless those requirements are met.


Vernon Schryver,  vjs@sgi.com
From: friedman@gnu.ai.mit.edu (Noah Friedman)
Newsgroups: comp.mail.headers
Subject: Re: Reply-To: rewrite
Date: 7 Sep 92 09:11:09 GMT
	<pgrgjug@rhyolite.wpd.sgi.com> <bu76bk.hhx@wang.com>
Organization: Free Software Foundation, 675 Mass Ave. Cambridge, MA 02139
In-reply-to: fitz@wang.com's message of 7 Sep 92 07:33:18 GMT


   It occurs to me that, regrettably, a rewrite of the appropriate mail
headers is also necessary when transferring mail between the UK and the
rest of the world, since they have their domains backwards. 

   I wouldn't mind rewrite of the headers so much if the rewrites were any
better than the original FQDN!  Half the time the rewrite is broken. 
Newsgroups: comp.mail.headers
From: "David Herron" <david@twg.com>
Subject: Re: Public domain RFC822 header parsing code?
Sensitivity: Personal
Encoding:  22 TEXT , 4 TEXT 
Conversion: Prohibited
Organization: The Wollongong Group, Inc., Palo Alto, CA
Conversion-With-Loss: Prohibited
Date: Fri, 11 Sep 1992 17:01:18 GMT

> Can anybody point me to some freely available code, preferably in C,
> for parsing RFC822 headers - specifically email addresses as would
> appear in a To: header?  The completer the better.

Yes.

Look in any comp.sources.misc archives and you'll find one written
in YACC.  (posted by me many many moons ago while I was still a
junior level E-Mail hacker known to the world as `david@ms.uky.edu').

That version has BUGS ('twas before I learned that not all the
world was a Vax ;-().

A later version is in the FACES distribution.  (It was a pleasant surprise
pulling that code over and finding that YACC grammer in there...)  That
version has most/all the necessary patching to get it working right.
I don't recall where to get FACES at, but shouting at Archie would
be a good start ;-).

There's also an RFC822 parser in the IMAP distribution available from
ftp.cac.washington.edu.  Dunno how seperable it is, though.


<- David Herron <david@twg.com> (work) <david@davids.mmdf.com> (home)
<-
<- "ISO is really just another politically correct one-world fantasy
<-  of the U.N." -- Gordon McLachlan (LAN Computing, Aug 1992, p. 37)
From: chris@visionware.co.uk (Chris Davies)
Newsgroups: comp.mail.headers
Subject: Re: Reply-To: rewrite
Date: 8 Sep 92 12:31:36 GMT
Organization: VisionWare Ltd., Leeds, UK
X-Newsreader: Tin 1.1 PL4

friedman@gnu.ai.mit.edu (Noah Friedman) writes:
:    It occurs to me that, regrettably, a rewrite of the appropriate mail
: headers is also necessary when transferring mail between the UK and the
: rest of the world, since they have their domains backwards. 

No, No, No!!!!!  Some of the academic network (Janet) uses domains
which happen to be the other way round to the Internet way of doing
things.  The rest of us use Internet domains (or perhaps bang paths if
absolutely necessary).  Life's too short to attempt to do anything with
uk.ac.* addresses except pass them on to our smart host (uknet.ac.uk).
However, we can handle some *.ac.uk addresses (which is the way we see
things).  Likewise for most UK commercial sites.

:    I wouldn't mind rewrite of the headers so much if the rewrites were any
: better than the original FQDN!  Half the time the rewrite is broken. 

Specifically UK academia?  Or in general?

Chris
--
            VISIONWARE LTD, 57 Cardigan Lane, LEEDS LS4 2LE, England
  Tel +44 532 788858 x238.  Fax +44 532 304676.  Email chris@visionware.co.uk
---------- "VisionWare:   The home of DOS/SQL/UNIX/X/VMS integration" ---------
Newsgroups: comp.mail.headers
From: SEB1525@MVS.draper.com (Steve Bacher)
Subject: Public domain RFC822 header parsing code?
Organization: Draper Laboratory
Date: Fri, 11 Sep 1992 12:38:00 GMT

Can anybody point me to some freely available code, preferably in C,
for parsing RFC822 headers - specifically email addresses as would
appear in a To: header?  The completer the better.

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
From: uucpmap@rutgers.rutgers.edu (UUCP Mapping Project)
Newsgroups: comp.mail.maps
Subject: UUCP map for u.usa.sd.1
Date: 8 Sep 92 10:00:04 GMT
Expires: 23 Oct 92 10:00:04 GMT
Supersedes: <Aug.8.07.50.26.1992.4135@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.sd.1
: This archive created: Tue Sep  8 06:00:01 1992
echo shar: extracting u.usa.sd.1
cat << 'SHAR_EOF' > u.usa.sd.1
file {u.usa.sd.1}
# u.usa.sd.1 updated by brodie@fps.mcw.edu Monday Mar 9 10:23:34.19 CDT 1992
# This map is maintained by Kent C. Brodie (Systems Mgr, Medical College of WI)
# Send any updates to uucpmap@rutgers.edu, (rutgers!uucpmap)
# Before sending updates, please consult the README file for the proper format.
# Send email to brodie@fps.mcw.edu for a copy if you need one.
#
# Reason for update: updated dsuvax.  new site:  smurfbbs
#
 
#N	dsuvax
#S	DEC MicroVAX II; Ultrix 4.2
#O	Dakota State University
#C	Guy Helmer
#E	ghelmer@dsuvax.dsu.edu
#T	+1 605 256 5675
#P	820 N Washington, Madison, SD  57042
#L	44 00 24 N / 97 06 48 W
#R	DSU's primary Internet host
#U	wupost smurfbbs
#W	ghelmer@dsuvax.dsu.edu (Guy Helmer); Mon Mar  2 16:24:49 CST 1992
#
dsuvax	wupost(DIRECT), smurfbbs(DAILY)
dsuvax	.dsu.edu
dsuvax	= dsuvax.dsu.edu

#N	loft386
#S	80386 AT-clone; Bell Technologies System V/386 Release 3.2u
#O	Lofty Pursuits
#C	Doug Ingraham
#E	dpi@loft386.UUCP
#T	+1 605 343 8760
#P	2274 Aster Court, Rapid City, SD  57702
#L	44 03 N / 103 15 W
#R	Public Access Unix for Rapid City, SD  USA
#U	bibs, enger386, nhh2sd, leagle, ledgepc
#W	loft386!dpi (Doug Ingraham); Mon Mar  4 20:15:47 MST 1991
#
loft386	uunet(DAILY), uudell(DAILY), ledgepc(WEEKLY), nhh2sd(DAILY),
	enger386(DAILY), bibs(DAILY), leagle(DAILY)

#N      smurfbbs
#S      IBM PC Clone; MS-DOS 5.0-PCBoard + uuPCB
#O      SELECTaWARE
#C      Mike Waldner
#E      smurfbbs!mike.waldner
#T      +1 605 256 9600
#P      418 N Union, Madison, SD  57042-2044
#L      44 00 23 N / 97 06 49 W
#R      SELECTaWARE Bulletin Board System
#U      dsuvax
#W      smurfbbs!mike.waldner (Mike Waldner); Mon Mar  2 16:22:47 CST 1992
#
smurfbbs dsuvax(DAILY)

#N	walldrug
#O	Wall Drug Store
#S	pdp 11/45, v6 modified
#C	Ted Hustead jr.
#E	walldrug!hustead
#T	+1 605 279 2175
#P	Wall Drug Store, Wall SD 57790
#L	44 00 43 N / 102 19 59 W
#U	namei glotz hoptoad kgbvax kremvax
#R	Yep, a million people a year come to see our very own ice water
#R	well, 6 foot jack rabbit, 5 cent coffee, church & 520 seat cafe!
#W	walldrug!postmaster (Ted Hustead jr.); Sat Mar 19 19:02:51 MST 1988
#
#	upstream sites
walldrug	glotz(HOURLY+LOW), namei(HOURLY+HIGH)
#
#	downstream sites
walldrug	kgbvax(HOURLY*4), kremvax(HOURLY*4)
#
#	our alt.drugs feed
walldrug	hoptoad(DAILY)

# u.usa.sd.1 EOF
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.egy.1
Date: 8 Sep 92 09:47:19 GMT
Expires: 23 Oct 92 09:47:19 GMT
Supersedes: <Aug.8.07.46.24.1992.2640@rutgers.rutgers.edu>

:	This is a shell archive.
:	Remove everything above this line and
:	run the following text with /bin/sh to create:
:	u.egy.1
: This archive created: Tue Sep  8 05:47:15 1992
echo shar: extracting u.egy.1
cat << 'SHAR_EOF' > u.egy.1
file {u.egy.1} # of 1; changes to: uucpmap@mcsun.eu.net
# #W lines show 2 dates: date of introduction and date of last change.
# Last change:  Tue Jan 28 10:13:27 MET 1992

#N	estinet
#S      AT&T 3B5, UNIX 2.0
#O	Egyptian National STI Network (ENSTINET)
#C	Maged Reda Boulos
#E	mb@estinet.uucp
#T	+20 2 3557253
#P	ENSTINET/ASRT, 101 Kasr El Ainy Street, Cairo, Egypt
#L	31 03 E / 31 15 N city
#R	Egyptian backbone site
#U	
#W	piet@mcsun.eu.net 900625, piet@mcsun.eu.net 920127
#
# International links
estinet	mcsun(WEEKLY/2)
# National links

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.can.bc.2
Date: 8 Sep 92 09:44:11 GMT
Expires: 23 Oct 92 09:44:10 GMT
Supersedes: <Aug.8.07.45.25.1992.2384@rutgers.rutgers.edu>

:	This is a shell archive.
:	Remove everything above this line and
:	run the following text with /bin/sh to create:
:	u.can.bc.2
: This archive created: Tue Sep  8 05:44:08 1992
echo shar: extracting u.can.bc.2
cat << 'SHAR_EOF' > u.can.bc.2
file {u.can.bc.2}
#	u.can.bc.2 : last updated Sun Mar  8 13:21:45 EST 1992
#
# Empty file.  A reorganization of the u.can.* files resulted in
# the number of u.can.bc files decreasing from 2 to 1.
#
# All map entries that were automatically generated from CA domain
# registration forms are now in u.can.?. - utai!path
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.nld.100
Date: 8 Sep 92 09:54:08 GMT
Expires: 23 Oct 92 09:54:08 GMT
Supersedes: <Aug.8.07.48.54.1992.3526@rutgers.rutgers.edu>

:	This is a shell archive.
:	Remove everything above this line and
:	run the following text with /bin/sh to create:
:	u.nld.100
: This archive created: Tue Sep  8 05:54:05 1992
echo shar: extracting u.nld.100
cat << 'SHAR_EOF' > u.nld.100
file {u.nld.100} # of 0,1,2,3,4,100; changes to: uucpmap@nluug.nl
# Non EUnet nodes residing in the Netherlands
# #W lines show 2 dates: date of introduction and date of last change.
# Last change:  Mon Jul 29 13:48:05 METDST 1991

#N     comsat
#S     Amstrad PPC-640; Waffle v1.64; MS/DOS
#O     Satellite Telecom, Geldrop Holland
#C     Marcel Kat
#E     comsat!marcel
#T     +31 40 853798
#P     Nieuwendijk 17a, 5664 HA, Geldrop, The Netherlands
#L     5 28 E / 51 26 N
#R     Public system for telecom and satellite related questions
#U
#W     martijn@nluug.nl 910729, martijn@nluug.nl 910729
#

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.wv.1
Date: 8 Sep 92 10:00:16 GMT
Expires: 23 Oct 92 10:00:16 GMT
Supersedes: <Aug.8.07.50.32.1992.4179@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.wv.1
: This archive created: Tue Sep  8 06:00:13 1992
echo shar: extracting u.usa.wv.1
cat << 'SHAR_EOF' > u.usa.wv.1
file{u.usa.wv.1}
# u.usa.wv.1 from uucp-map@acsu.buffalo.edu
#  send maps to usa-[dc|de|md|nj|ny|va|wv]@rutgers.edu
# 03:05 gmt 15-Mar-1992
#END u.usa.wv.1
SHAR_EOF
:	End of shell archive
exit 0