Xref: utzoo comp.mail.headers:684 news.software.b:7471
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!blars!blarson
From: blarson@blars
Newsgroups: comp.mail.headers,news.software.b
Subject: Re: Header stripper
Message-ID: <188@blars>
Date: 15 Apr 91 00:52:10 GMT
References: <10712@rls.UUCP> <1621@aupair.cs.athabascau.ca> <10715@rls.UUCP>
Sender: news@usc
Reply-To: blarson@usc.edu
Followup-To: comp.mail.headers
Lines: 47
Nntp-Posting-Host: dianne.usc.edu
Originator: blarson@dianne.usc.edu

In article <10715@rls.UUCP> randy@rls.UUCP (Randall L. Smith) writes:
>In article <1621@aupair.cs.athabascau.ca>, lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes:
>> randy@rls.UUCP (Randall L. Smith) writes:
>>> *    Easily achieved because the first line of a mail or news
>>> *    header must begin with "Path:" and the last line of the
>>> *    header must be a blank line.
>> 
>> This is incorrect. There is no "Path:" header defined for RFC822 mail,
>> and if one is present, there's no guarantee that it will be the first
>> header. The "Path:" header must be present in news articles, but again
>> there is no guarantee that it will be the first header, although all
>> existing news transports that I'm aware of will place it there.

C news usually (but not always) puts the Xref: header first if there is
one.  The Path: header usually follows.  (There is no RFC specifying
header order, and C news will put the headers in a different order if
a buffer fills before all headers have been read.)

>Quite right.  See my follow up posting with corrections.  I didn't read
>the RFC's for this information.  I simply looked at the actual headers of
>news and mail.  

And guessed the rest of the world followed what you saw on one system.

>Mail consistantly has "From " on the first line 

When using uucp style mail boxes, common (but not the only thing) on
unix systems and rare elsewhere.

>and news has "Path:" on the first line, both in the first 5 characters.

I think this is the case with B news.

>  My guess
>is the RFC's somewhere define this. 

Nope.


-- 
blarson@usc.edu
		C news and rn for os9/68k!
-- 
Bob Larson (blars)	blarson@usc.edu			usc!blarson
	Hiding differences does not make them go away.
	Accepting differences makes them unimportant.