Xref: utzoo comp.mail.uucp:2996 news.sysadmin:2262
Path: utzoo!utgpu!watmath!iuvax!mailrus!ames!think!rlk
From: rlk@think.com (Robert Krawitz)
Newsgroups: comp.mail.uucp,news.sysadmin
Subject: Re: mail headers
Message-ID: <39121@think.UUCP>
Date: 13 Apr 89 02:15:36 GMT
References: <5463@ozdaltx.UUCP> <11470@s.ms.uky.edu> <627@dtscp1.UUCP>
Sender: news@think.UUCP
Reply-To: rlk@think.com (Robert Krawitz)
Followup-To: comp.mail.uucp
Organization: Thinking Machines Corp., Cambridge MA
Lines: 58
In-reply-to: scott@dtscp1.UUCP (Scott Barman)

In article <627@dtscp1.UUCP>, scott@dtscp1 (Scott Barman) writes:
]Why?  Someone please explain to me what purpose do they serve besides making
]it more difficult to get to the real mail at the end.  I am more interested
]in the message not what software, version number, or even system the note
]passed through to get here.

That's the point -- use a mailer that strips those headers for you.  I
use rmail, and I have it configured to show me only a handful of
normally interesting headers.  But when I get a strange bounce
message, or a UUCP message from nowhere (which is less contradictory
than it seems :-) ), I'm glad that all but the very most brain-damaged
sites stick in received: headers.  It's the only tool I have to debug
remote mail problems that doesn't require working mail to a
cooperative postmaster.

]Are all these header lines needed because we have so many brain-dead
]machines running brain-damaged software?  I would figure by now most of
]the net-bugs have been ironed out and mail does pass pretty reliably
]to make these things unnecessary.  Being only a five-year net veteran
]I have not had too many problems with mail.

Being a six-year veteran and a moderator of a major mailing list
(info-nets) that goes all over the network universe, I will agree with
you -- up to a point.  The agreement is that over the past year, I've
had a failure rate of maybe 2%, with major failures happening maybe
.1% of the time.  The disagreement is that I've received 38,259
messages since last May 2, so that corresponds to about 50 really big
failures, or an average of one per week.  One of those failures was a
real whopper (a fast, tight loop on info-nets that blasted a
significant portion of Known Netspace until I came in and cleaned it
up).  Knowing the routing of all this stuff is useful -- it's just
that I don't see it if I don't want to.

Most internet sites deliver mail reliably.  99.9% delivery isn't bad,
but the total mail traffic is high enough so that the last .1% is
significant, and machine speeds are high enough in many cases so that
serious mail lossage can hurt (at the time, our external mailer was
running on a MicroVAX II with 5 Mbytes of memory on a somewhat flaky
arpanet connection -- a very underpowered machine, but still quite
capable of hammering on the net.  With 13 Mbytes of memory, which we
have now, we can really hit a gateway hard, in my experience).

The real problem, though, is that there are plenty of networks that
aren't part of the internet and don't follow any particular guidelines
(many UUCP sites, Bitnet in general, etc.).  All sorts of weird things
happen to mail on these networks, and they can be very confusing.
Even if I don't understand an error message or a delay, I can infer a
lot about what happened by knowing the path a message took.

]Yes, I agree that this sounds a bit naive; but why do we have to put up
]with transmitting this extra data all over the net when it seems to have
]out lived its usefulness?

The point is that it hasn't outlived its usefulness.
-- 
ames >>>>>>>>>  |	Robert Krawitz <rlk@think.com>	245 First St.
bloom-beacon >  |think!rlk	(postmaster)		Cambridge, MA  02142
harvard >>>>>>  .	Thinking Machines Corp.		(617)876-1111