dave@lsuc.UUCP (03/31/87)
It seems to me that mail headers are getting a little out of hand.
Mail now accounts for a substantial portion of network traffic
(2/3 of seismo's traffic, for example).
Excess mail headers affect (a) transmission costs; (b) storage
space en route; (c) storage space when messages are saved for
future reference; (d) reading time (and general annoyance) for
those reading Mail without an interface which will suppress such
headers.
News 2.11 has removed headers that had at best marginal utility
(such as Posting-Version and Relay-Version), recognizing that the
cost of transferring and storing these headers exceeded their benefits.
The time has come to address mail headers as well. In particular,
the "Received:" header seems to me to be (a) longer than necessary
(a site and date/time should be enough), and (b) not necessary
at all when the mail is received from a local user (in which
case the "Date:" field suffices) and when the mail is destined
for a local user (in which case the delivery agent will time-stamp
the mail within a few seconds).
Can we at least consider having smail et al. suppress "Received:"
for locally-generated and locally-destined mail?
David Sherman
The Law Society of Upper Canada
Toronto
--
{ seismo!mnetor cbosgd!utgpu watmath decvax!utcsri ihnp4!utzoo } !lsuc!davestephen@dcl-cs.UUCP (04/05/87)
In article <1676@lsuc.UUCP> dave@lsuc.UUCP (David Sherman) writes: >The time has come to address mail headers as well. In particular, >the "Received:" header seems to me to be (a) longer than necessary >(a site and date/time should be enough), and (b) not necessary >at all when the mail is received from a local user (in which ... The "Received:" header is useful for: - checking the route mail travels and the time delays - helping to check the authenticity of mail - rebuilding a route for error messages when other means fail This header should be added by a machine when it receives mail from another machine (thus local mail should not have any "Received:" lines). A mail user interface should hide these lines normally, but should have a means of making them visible when required. The machine the header says it is received *from* should be calculated by the receiving host by, say, a reverse lookup on the DoD Internet table given the n.n.n.n address the mail connection originated from or, say, the UUCP system name that was in use at the time of the transfer. This is the basis of authenticity checking. -- EMAIL: stephen@comp.lancs.ac.uk | Post: University of Lancaster, UUCP: ...!mcvax!ukc!dcl-cs!stephen | Department of Computing, Phone: +44 524 65201 Ext. 4120 | Bailrigg, Lancaster, UK. Project:Alvey ECLIPSE Distribution | LA1 4YR
gmp@rayssd.UUCP (04/09/87)
In article <323@dcl-csvax.comp.lancs.ac.uk> stephen@comp.lancs.ac.uk (Stephen J. Muir) writes: > The machine the header says it is received *from* should be calculated by the > receiving host by, say, a reverse lookup on the DoD Internet table given the > n.n.n.n address the mail connection originated from or, say, the UUCP system > name that was in use at the time of the transfer. This is the basis of > authenticity checking. The ARPA/ethernet host name lookup is easy, and sendmail already does this. But what about the uucp case? How can sendmail find out the "system name that was in use at the time of the transfer?" If you know how to code this in to sendmail, please let me know, cuz I haven't figured it out. The sendmail that we're running now (4.2BSD's version) doesn't do this at all. I tried figuring it out by looking at the argument passed to sendmail with the -f flag, using the "last hop" part of the address, but now with domain-style addresses being passed around via uucp, I've noticed that often this last hop is some domain that we don't talk to at all. Yipes! Not much authenticity there! I ended up taking it out, since I'd rather say nothing than lie (usually, anyway). Suggestions? -- Greg Paris ............................. gmp@rayssd.RAY.COM (a UUCP domain) {cci632,cbosgd,gatech,ihnp4,linus,mirror,necntc,uiucdcs,umcp-cs}!rayssd!gmp ................................... What is your present form of execution?
gmp@rayssd.UUCP (04/10/87)
In article <43258@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes: > The simplest way to do it is to modify rmail.c. Here is a diff -c from > the 4.3 bsd rmail.c. to what we are running. > > ---rick If you decide to modify your 4.2 BSD rmail in a similar manner, beware that it will probably not work. The line below from Rick's patch is what aggravates an apparent bug in 4.2's sendmail. > (void) sprintf(cmd, "exec %s -em -i -oMrUUCP -oMs%s.%s -f%s", The two -oM options don't work; the second one is ignored. To fix this, you could get rid of the -oMrUUCP, since (at least in my configuration) it wasn't used anyway, or if you have source, you could modify sendmail's main.c where it calls setoption for the -o flag. The line should look like what follows. setoption(p[2], &p[3], FALSE, p[2] == 'M' ? FALSE : TRUE); This change prevents the sticky flag from being set when setting a macro value from the command line. I made this change and all works fine. -- Greg Paris ............................. gmp@rayssd.RAY.COM (a UUCP domain) {cci632,cbosgd,gatech,ihnp4,linus,mirror,necntc,uiucdcs,umcp-cs}!rayssd!gmp ................. People like you should not be allowed to start any fires.
sysop@killer.UUCP (04/12/87)
I agree completely with this. It seems that the .signatures were limited
to 4 lines yet I receive many mail messages that the headers far exceed the
body of the message. This seems like far too much increased traffic that is
generated by mailers. A couple of the latest messages contained 30 lines
of headers for ten lines of message - including the .signature !
Charles F. Boykin
{cuae2, ihnp4!killer!sysopghoti#@andrew.cmu.edu.UUCP (04/18/87)
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
problems were occurring....both in our system and in those from which we were
receiving messages.
If the body of a message is so insignificant in size to the headers, perhaps
the problem is people sending terse commentary through when it would have
been better to either include more information or not bother sending it at
all.
I will admit that not all messages need to be 100 lines long in order to be
considered worthy of posting - but I wouldn't put down the usefulness of
Received headers because someone sent a one line message with a signature
file and it happened to have bounced through 50 mailers - if anything, this
might alert you to some inefficiencies in the routing that was used.
We have also received posts here with more than 50 lines of headers, and this
has at times caused problems for our local system, but our software was
devloped to handle the information and this merely pointed out areas in which
we assumed limitations that weren't accurate.
This doesn't mean I like having messages with 80% headers, but merely that I
think you are looking in the wrong place for a solution if you think removing
the Received headers will solve problems.
(For what it's worth, the message I am responding to contained 20 lines of
headers - but I am not shown them by default - so it doesn't bother me.)
Adam Stoller
Andrew Message System Group
Carnegie-Mellon University
<ghoti#@andrew.cmu.edu>
(412)268-6723campbell@maynard.BSW.COM (Larry Campbell) (04/19/87)
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 684dave@lsuc.UUCP (04/30/87)
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
sl@van-bc.UUCP (Stuart Lynne) (05/01/87)
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
dzoey@umd5.umd.edu (Joe Herman) (05/03/87)
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."nsb#@andrew.cmu.edu (Nathaniel Borenstein) (05/07/87)
X-Andrew-Authenticated-as: 327 X-Trace: MS Version 3.25 on ibm032 host larimer.itc.cmu.edu, by nsb (327). To: outnews#ext.nn.comp.mail.headers@andrew.cmu.edu In-Reply-To: <1606@umd5.umd.edu> The "received" headers are also useful even for mail "within one site" when that site is actually a distributed system. For example, what the world sees as "andrew.cmu.edu" is actually a network of many hundreds (soon to be many thousands) of workstations sharing a distributed central file system. Mail transfer even within such a system is decidedly non-trivial, and the received headers trace the "internal" path that mail delivery takes, which may vary if file servers are down, for example. In short, the received lines are useful *almost everywhere*. I'd hate to see them reduced. -- Nathaniel Borenstein Andrew Message System group nsb+@andrew.cmu.edu
mark@cbosgd.ATT.COM (Mark Horton) (05/08/87)
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