🚀 go-pugleaf

From article <17601@glacier.STANFORD.EDU>, by jbn@glacier.STANFORD.EDU (John B. Nagle):
> 
>      The X mail system (is this part of X windows?) seems to indulge in
> heavy self-promotion.  Is all the following, taken from incoming mail,
> necessary?  It has little value to the recipient.
> 
> 	X-To:         DYNSYS-L%UNCVM1.bitnet@jade.berkeley.edu

Gentle flame. Read the standard, X-<field> is the RFC822 extension
mechanism. it allows mail systems to add fields into the message header
for end-to-end (well, I suppose other people/things could use it) purposes.

-value is in the eye of the beholder. your mail system (and mine) may balk
a little on these fields, but it should not barf. It is in the standard to 
ignore them. 

Elm clearly offers some enhanced functionality.

	apologies to mail-gurus if this is wrong/to late.

	-george
-- 
        George Michaelson, CSIRO Division of Information Technology

ACSnet: G.Michaelson@ditmela.oz                      Phone: +61 3 347 8644
Postal: CSIRO, 55 Barry St, Carlton, Vic 3053 Oz       Fax: +61 3 347 8987

In article <17601@glacier.STANFORD.EDU> jbn@glacier.STANFORD.EDU (John B. Nagle) writes:
>
>     The X mail system (is this part of X windows?) seems to indulge in
>heavy self-promotion.  Is all the following, taken from incoming mail,
>necessary?  It has little value to the recipient.
>

Things in a mail header that have an "X-" flag are mailer independant.  This
means that anything that starts with "X-" was put in by some mailer somewhere,
either as a comment or to pass commands specifically interpretted by that
mailer, and they are ignored by all other mailers.  I believe that this is
the only way to add lines to the header that is supported as part of the
standard, all lines that don't begin with "X-" have to do with real information
that is documented in RFC822.  It's a little hard to tell what everything below
is doing without looking at the complete header of the message, but most 
of the things are comments.  



>	X-To:         DYNSYS-L%UNCVM1.bitnet@jade.berkeley.edu

I'm not sure where this came from, maybe some strange IBM system on BITNET.

>	X-Mailer: Elm [version 1.5b]
>	X-Mailer: Elm [version 1.5d]

Says that the mail went through the Elm mailer (twice), mainly comments.

>	X-Origin: The Portal System (TM)

Free advertisments for the Portal System.

>	X-Possible-Reply-Path: Ed_Eric_Mitchell@cup.portal.com
>	X-Possible-Reply-Path: mslater@cup.portal.com
>	X-Possible-Reply-Path: sun!portal!cup.portal.com!Ed_Eric_Mitchell
>	X-Possible-Reply-Path: sun!portal!cup.portal.com!mslater

All semi useful stuff from portal listing possible return paths.  I believe
this is actually put in by Elm, but it is not used any mailers I know of, it
has to be interpreted by a human.  There are basically two return paths listed,
one via a domain-ised internet and one via uucp.  I believe that the two 
different versions of the address are just aliases for the same person.  If
the entire world used the domain based systems then this would certainly
be unnecessary, and even with things the way they are it shouldn't be required
if all sites in the intervening path builds the return address correctly.

>	X-St-Vmsmail-To: MIPL3::ST%"jbn@glacier.stanford.edu",RGD059      
>	X-St-Vmsmail-To: ST%"jbn@glacier.STANFORD.EDU",RGD059      
>	X-St-Vmsmail-To: ST%"jbn@glacier.stanford.edu"

These three lines come from the Software Tools Mailer (yeah!!!) running under
VMS, with mail sent from VMSmail (yuch) into the Software Tools system.  

>	X-Vms-To: IN%"jbn@glacier.STANFORD.EDU"

This alse comes from VMS, someone sent the mail from VMSmail into a TCP/IP
based mailer.  I believe this one looks like Excelans's.

  --darren

-------------------------------------------------------------------------------
Darren Griffiths                                          DAGG@LBL.GOV
Lawrence Berkeley Labs
Information and Computing Sciences Division                

You're joking, right?  This has little to do with X windows.
It looks like ELM turds.  Remember the X- construct from RFC822.

The point is not "What does it mean?" but rather "What the hell good
is it?"  I think most of the "X-" headers ever used are useless and
were probably inserted for someone's own fun or for, as jbn suggests,
self-promotion.  The "X-Mailer" headers are the ones the really get
my dander up, but even worse than these are the one or two dweebs out
there who insert "Precedence: special-delivery" into every message
they send!  They know who they are ...
________________________________________________________
Matt Crawford	     		matt@oddjob.uchicago.edu

In article <601@helios.ee.lbl.gov> dagg@lbl.gov (Darren Griffiths) writes:
>Things in a mail header that have an "X-" flag are mailer independant.  

     Shouldn't this be "mailer dependent"?

Incidentally, some new examples of advertising have arrived.

	X-Mailer: MMDF/Ream version 4.12 (The Choice for a New Generation)
	X-Subliminal-Message: Send me all your money

My point is that this may be getting out of hand.  But it will probably
get worse for a while, and then some sites will start trimming headers
during forwarding.


					John Nagle

>      The X mail system (is this part of X windows?) seems to indulge in
> heavy self-promotion.  Is all the following, taken from incoming mail,
> necessary?  It has little value to the recipient.

The "X-" stuff has nothing to do with a "X mail system"; RFC822
specifies that non-standard headers should begin with an "X-" to avoid
conflict with any future defined headers.  The following are from a
variety of mail systems:

> 	X-To:         DYNSYS-L%UNCVM1.bitnet@jade.berkeley.edu
From a bitnet gateway at berkeley (UREP)
> 	X-Mailer: Elm [version 1.5b]
> 	X-Mailer: Elm [version 1.5d]
From two different versions of Elm.
> 	X-Origin: The Portal System (TM)
> 	X-Possible-Reply-Path: Ed_Eric_Mitchell@cup.portal.com
> 	X-Possible-Reply-Path: sun!portal!cup.portal.com!Ed_Eric_Mitchell
From "portal", trying to let the recipient know possibile reply
addresses, since addresses passing through uucp land are likely to
become unrecognizable.
> 	X-St-Vmsmail-To: MIPL3::ST%"jbn@glacier.stanford.edu",RGD059      
> 	X-St-Vmsmail-To: ST%"jbn@glacier.STANFORD.EDU",RGD059      
> 	X-St-Vmsmail-To: ST%"jbn@glacier.stanford.edu"
One VMS mail system showing what addresses the VMS user sent mail to,
before they were converted to "normal" addresses.
> 	X-Vms-To: IN%"jbn@glacier.STANFORD.EDU"
The same, from another VMS mail system.
-- 
John Owens		john@jetson.UPMA.MD.US
SMART HOUSE L.P.	uunet!jetson!john		(old uucp)
+1 301 249 6000		john%jetson.uucp@uunet.uu.net	(old internet)

In comp.mail.headers, matt@oddjob.UChicago.EDU writes:
>The point is not "What does it mean?" but rather "What the hell good
>is it?"  I think most of the "X-" headers ever used are useless 

The most useful X- header I've seen is X-Content-Type, an unofficial 
way of doing the Content-Type: header that Marvin Sirbu has proposed 
as an extension to 822 for mail systems capable of accepting and 
displaying different message types (text, PostScript, Andrew message 
format, Diamond encoded multimedia format, etc.)

On the other hand, X-Zippy-Quote-of-the-Day is at least amusing once 
in a while, and X-Return-Path can be a useful hint to a USER saddled
with a brain-dead mailer, whereas X-Mailer is just annoying.

In article <17601@glacier.STANFORD.EDU> jbn@glacier.STANFORD.EDU (John B. Nagle) writes:
>
>     The X mail system (is this part of X windows?) seems to indulge in
>heavy self-promotion.  Is all the following, taken from incoming mail,
>necessary?  It has little value to the recipient.
>
>
The X-whatever headers are not from any single system. There is an RFC-822 
convention that allows [programs|sites|people|etc] to add their own headers
by proceeding them with 'X-'.  This assures that RFC-822 compliant mailers
won't confuse these with 'officially' defined headers.  These headers may
or may not have any value to the recipient (or sender for that matter). :-)


*****************************************************************************
Internet:	stewarta@sco.COM	
UUCP:		{uunet,ucbvax!ucscc,decvax!miscosoft}!sco!stewarta

In article <17601@glacier.STANFORD.EDU> jbn@glacier.STANFORD.EDU (John B. Nagle) writes:
 >
 >     The X mail system (is this part of X windows?) seems to indulge in
 >heavy self-promotion.  Is all the following, taken from incoming mail,
 >necessary?  It has little value to the recipient.
 >
 >	X-To:         DYNSYS-L%UNCVM1.bitnet@jade.berkeley.edu
	...
 >	X-Vms-To: IN%"jbn@glacier.STANFORD.EDU"
 >
 >						John Nagle

Read RFC 822.

Header fields beginning with "X-" are gauranteed to not
conflict with the standard or future versions of the standard.
(They are standard, non-standard fields ;-)
-- 
If you can't convince |   David Messer - (dave@Lynx.MN.Org)
them, confuse them.   |   Lynx Data Systems
   -- Harry S Truman  | 
                      |   amdahl   --!bungia!viper!dave
                      |   hpda    /

Copyright 1988 David Messer -- All Rights Reserved
This work may be freely copied.  Any restrictions on
redistribution of this work are prohibited.

>      The X mail system (is this part of X windows?) seems to indulge in
> heavy self-promotion.  Is all the following, taken from incoming mail,
> necessary?  It has little value to the recipient.
> 
> 	X-To:
> 	X-Mailer:
> 	X-Origin:
> 	X-Possible-Reply-Path:
> 	X-St-Vmsmail-To:
> 	X-Vms-To:

There is no such thing as the "X mail system."  There are mailers that run
under the X Window System (xmh, for instance) but they have nothing to do
with these headers.  The "X-" prefix is specified by the mail standards
(RFC822, I think) for any header which is not official.  In other words, 
if your mailer wants to put a header on a message that isn't a supported
header, it should preceed the name by "X-."  You may still choose to argue
that the headers are useless, but I would disagree in at least some cases
(X-Mailer, for instance).  However, any mail user interface worth its salt
will hide these headers unless you ask to see them, so it really is a moot
point.


John Diamant
Software Development Environments
Hewlett-Packard Co.		ARPA Internet: diamant@hpfclp.sde.hp.com
Fort Collins, CO		UUCP:  {hplabs,hpfcla}!hpfclp!diamant