🚀 go-pugleaf

I also would like to keep the "Received:" headers.  Mail to us is often
delayed, and it's useful to know where the holdup is.  As a concrete
example, we discovered through analysis of "Received:" headers that most
of our recent delays were caused by queuing at our immediate neighbor,
wjh12.  That is, a message might take an hour to make the five or six
hops to wjh12, and then two days to make the last hop here.  As a result,
we increased our polling frequency and switched from a normal news feed
to a compressed batched feed (wjh12 also feeds us news).  This solved
the mail problem.  But we would not have understood the problem nearly
as well without the "Received:" headers.

Please retain the "Received:" headers.
-- 
Larry Campbell                                The Boston Software Works, Inc.
Internet: campbell@maynard.BSW.COM          120 Fulton Street, Boston MA 02109
uucp: {alliant,think,wjh12}!maynard!campbell        +1 617 367 684

In one article, ghoti#@andrew.cmu.edu (Adam Stoller) writes:
>The Received headers are valuable tools to be able to determine where
>messages have been and when they were there - I would hate to lose this
>information as it has come in handy more than once for us to determine where

And in another article, campbell@maynard.UUCP (Larry Campbell) writes:
>I also would like to keep the "Received:" headers.  Mail to us is often
>delayed, and it's useful to know where the holdup is...
>Please retain the "Received:" headers.

Both of these articles miss my point. I accept that Received: headers
are useful. I suggest they are overused, however (as well as being
longer than they need to). Specifically, I suggested that they are
not necessary at the SENDING site (since there's a Date: field) and
at the RECEIVING site (since there's a delivery agent timestamp such
as the UUCP From_ line).

Would the implementors/maintainers of sendmail, smail et al. please
consider the above?

David Sherman
-- 
{ seismo!mnetor  cbosgd!utgpu  watmath  decvax!utcsri  ihnp4!utzoo } !lsuc!dave

In article <1761@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes:
>are useful. I suggest they are overused, however (as well as being
>longer than they need to). Specifically, I suggested that they are
>not necessary at the SENDING site (since there's a Date: field) and
>at the RECEIVING site (since there's a delivery agent timestamp such
>as the UUCP From_ line).
>
Remember, the Received: headers are generated by the message transfer
agents, smail, sendmail, et al. As such even if the different MTA's that a
message gets passed to are all on the same machine each is separate and
distinct, and must generate Received: header of it's own (assuming for the
moment that we believe that they are needed at all from any MTA).

So even though you are correct in saying that we have a date field etc in
the message (hopefully, but not necessarily generated by the user agent) we
are able to see where and how it was actually given to an MTA for
processing. This is important information that can show how a message has
been actually transferred from the sending UA to the receiving UA. 

I find the Received: headers interesting and useful in seeing the actual
handling of the messages from MTA to MTA, via what network.

-- 
Stuart Lynne	ihnp4!alberta!ubc-vision!van-bc!sl     Vancouver,BC,604-937-7532

I too find Received headers very useful, especially in trying to trace
a path to a uucp type of host.  Awhile back, I posted a request for
info on mail implementations.  I collected the responses and said that
if anyone was interested, I'd send them a copy.  I received about
fifteen replies.  Let me tell you, tracing the Received headers was the
only way I could generate replies to many of the requests.

I find it's becoming very difficult these days to tell which network a
host exists on.  There seems to be some sort of movement in the uucp
community to create addresses that look like internet addresses.
This makes looking at Received: headers a must for trying to route mail.

Since uucp hosts are starting to use domain format, does that mean that
they are registering their hosts with the NIC and future name resolution
will provide me with a path to that host?


				Oh well, I've said my share,
					joe

dzoey@terminus.umd.edu   (for people w/o domain resolvers: dzoey@umd5.umd.edu)
{seismo, inhp4!rlgvax!cvl}!terminus.umd.edu!dzoey
-- 
"Everything is wonderful until you know something about it."

In article <1606@umd5.umd.edu> dzoey@umd5.umd.edu.UUCP (Joe Herman) writes:
>There seems to be some sort of movement in the uucp
>community to create addresses that look like internet addresses.

No, I haven't seen anybody generating mail from addresses like
	root@[192.11.2.1]
which is what an internet address would look like.  Addresses like
"dzoey@umd5.umd.edu" and "mark@cbosgd.MIS.OH.ATT.COM" are *domain* addresses,
which are a widely implemented standard, they are by no means specific
to the Internet.  (I have no idea what "dzoey@umd5.umd.edu.UUCP" is.)

>Since uucp hosts are starting to use domain format, does that mean that
>they are registering their hosts with the NIC and future name resolution
>will provide me with a path to that host?

Of course, one of the basic principles of the domain system is that each
level has a unique registry.  Anyone who uses a domain name is obligated
to get it properly registered first.

As to name resolution, if your machine is up to current ARPA specs,
including RFC 973 and 974, everything works.  This has been in operation
for nearly a year now.

	Mark Horton
	Managing Director, the UUCP Project