root@ozdaltx.UUCP (root) (04/01/89)
Wouldn't it be wonderful to receive e-mail WITHOUT scads of
notations of 'Received by:' at the beginning of each
message? Does anyone really care what system received the
message, that systems ID number and a time stamp to boot? I
can tell what sites the message went through by looking at
the path line plus I can read the date the message was sent
and I know when I received it.
Not to mention the bytes saved in transmission by
eliminating all this garbage. What can be done????
Scotty
{ames,rutgers,texsun,smu}!killer!ozdaltx!sysop tadguy@cs.odu.edu (Tad Guy) (04/01/89)
In article <5463@ozdaltx.UUCP>, root@ozdaltx (root) writes: >Wouldn't it be wonderful to receive e-mail WITHOUT scads of >notations of 'Received by:' at the beginning of each >message? >What can be done???? Use a user agent that doesn't display these on your terminal. In Berkeley Mail (for example), you can put ``ignore Received'' in your .mailrc and you won't see those anymore. ...tad
roy@phri.UUCP (Roy Smith) (04/02/89)
In article <5463@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: > Wouldn't it be wonderful to receive e-mail WITHOUT scads of notations of > 'Received by:' at the beginning of each message? If you are talking about you, as the reader, not having to see all those lines, you're (probably) in luck. Most MUAs (Mail User Agent, i.e. the program you use to read your mail) have some way to surpress the display of header lines you don't want to see. In BSD mail and Sun's mailtool, you can put "ignore received-by" in your .mailrc file. The details may differ for other MUAs but there is probably something similar. Ask your local mail guru. > Does anyone really care what system received the message, that systems ID > number and a time stamp to boot? I do, but that's because I'm postmaster here. Most of the "just plain folks" around here probably don't even know that they exist, nor care about the information contained in them. My concern is not that 100 bytes get added to each message at each intermediate site, but that not every site bothers to put that information in as it relays the mail. Sometimes the Recieved-by: header is the only way I can figure out where mail came from. By the time a piece of mail has been mishandled by several uucp, bitnet, internet, csnet, etc. gateways, the From: line is often such a mess as to be totally unintelligible. > I can tell what sites the message went through by looking at the path line Path lines only pertain to news, not to mail, and even then it is not guaranteed that if you reverse a news path line you will get a valid mail route. There are unidirectional links and there are news links which don't provide mail service. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@phri.nyu.edu "The connector is the network"
tsmith@sem.BRL.MIL (Tim Smith) (04/02/89)
In article <5463@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: >Wouldn't it be wonderful to receive e-mail WITHOUT scads of >notations of 'Received by:' at the beginning of each >message? Does anyone really care what system received the >message, that systems ID number and a time stamp to boot? I >can tell what sites the message went through by looking at >the path line plus I can read the date the message was sent >and I know when I received it. > >Not to mention the bytes saved in transmission by >eliminating all this garbage. What can be done???? The received by lines are often times the only way to debug things. Lots of email does not have a "path"- all the world is not usenet. If you don't like looking at the receive lines find a decent mail reader- mine strips all of the received by lines when it prints the mail on my screen. The bytes are cheap- it would cost me more of my time to debug mail problems without the received by lines. Tim Smith (formerly of the US Naval Academy) US mail:US Army, BRL E-mail: SLCBR-SE internet:tsmith@brl.mil Aberdeen Proving Grounds, MD 21005-5066 uucp :...!uunet!brl!tsmith MaBell :(301)278-6678 (or 6808) Autovon: 298-6678 #define standard disclmaimer
jbayer@ispi.UUCP (Jonathan Bayer) (04/02/89)
In article <5463@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: >Wouldn't it be wonderful to receive e-mail WITHOUT scads of >notations of 'Received by:' at the beginning of each >message? Does anyone really care what system received the >message, that systems ID number and a time stamp to boot? I >can tell what sites the message went through by looking at >the path line plus I can read the date the message was sent >and I know when I received it. Use a good mail program such as Elm 2.2 (which is being released to the sources group today or tomorrow). It hides all of the headers unless you want to see them. > >Not to mention the bytes saved in transmission by >eliminating all this garbage. What can be done???? You don't want to do this since if there is a problem the headers are the only way to figure out what the problem is and where it might have occurred. These lines are the audit trail necessary to figure out everything that has been done to the poor message. JB -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 19 Virginia Ave. ...uunet!ispi!jbayer Rockville Centre, NY 11570 (516) 766-2867 jbayer@ispi.UUCP
hack@merkin.UUCP (04/02/89)
In article <5463@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: >Wouldn't it be wonderful to receive e-mail WITHOUT scads of >notations of 'Received by:' at the beginning of each >message? Does anyone really care what system received the >message, that systems ID number and a time stamp to boot? I >can tell what sites the message went through by looking at >the path line plus I can read the date the message was sent >and I know when I received it. If you are running smail 2.5 (w/o sendmail) on System 5, I can send some patches that undefine the headers at compile time. -- Greg Hackney net: hack@merkin.cactus.org uucp: bellcore!texbell!merkin!hack
rob@violet.berkeley.edu (Rob Robertson) (04/02/89)
In article <5463@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes:
Wouldn't it be wonderful to receive e-mail WITHOUT scads of
notations of 'Received by:' at the beginning of each
message? Does anyone really care what system received the
message, that systems ID number and a time stamp to boot? I
can tell what sites the message went through by looking at
the path line plus I can read the date the message was sent
and I know when I received it.
besides being a very good debugging tool in determining where
a mail message actually went, they also prevent intermachine
mail loops, ie .forward files on different machines pointing
at each other. i've seen this make an 8600 totally unusable.
robajudge@maths.tcd.ie (Alan Judge) (04/02/89)
In article <5463@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: >Wouldn't it be wonderful to receive e-mail WITHOUT scads of >notations of 'Received by:' at the beginning of each >message? Does anyone really care what system received the >message, that systems ID number and a time stamp to boot? I >can tell what sites the message went through by looking at >the path line plus I can read the date the message was sent >and I know when I received it. Most system administrators will tell you that the Received headers are very useful when diagnosing problems or holdups in mail. With the number of "intelligent" mailers out there now, they are also of considerable use in finding out how messages are being routed. Most mail messages do not have a "path line" (this is a news only phenomenon) and most smart mailers do *not* modify the mail headers (such as from:) to indicate what sites the message has been through. Therefore without the Received headers there is no way to determine the routing of the message. Without routing information it is sometimes impossible to reply at all. For example, a mail message I just received just said mmdf2@relay.cs.net in the From: line. Without Received lines I would not know it had been through tcdcs, ccvax.ucd.ie, irlearn.bitnet, cunyvm.cuny.edu, relay.cs.net Admittedly, some mailers put in useless information into headers, but I think that the host name and time should definitely be kept. Anyway, if you are using a nice mail reader you shouldn't even see headers like Received, Message-id etc.. unless you explicitly ask. >Not to mention the bytes saved in transmission by >eliminating all this garbage. What can be done???? Transmission times for mail are usually dwarfed by those for news anyway. >Scotty >{ames,rutgers,texsun,smu}!killer!ozdaltx!sysop -- Alan Judge, SysAdmin, Dept. of Maths, Trinity College, Dublin, Ireland. Smart: ajudge@maths.tcd.ie Stupid: ...!uunet!maths.tcd.ie!ajudge P.S. I have crossposted to comp.mail.headers and directed followups there since this does not belong in news.sysadmin.
root@ozdaltx.UUCP (root) (04/02/89)
Thanks for all the comments and replys re. the Recieved by:
line in the mail headers.... To the adverage user they are a
pain in the butt, but I suppose they do come in handy for
the sysadmins trying to track down a problem. I forgot to
mention that I'm running SCO XENIX and so I have to live
with their mail program. I'm not interested in trying to
get another mailer installed as my disk space is limited and
I don't like fixing something that ain't broke.
Thanks for the suggestions and comments.
Scotty
AIDS INFORMATION EXCHANGE BBS (214) 247-2367/247-5609
"Education is the best weapon"
{ames,rutgers,texsun,smu}!killer!ozdaltx!sysop bob@tinman.cis.ohio-state.edu (Bob Sutterfield) (04/04/89)
In article <5463@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes:
Wouldn't it be wonderful to receive e-mail WITHOUT scads of
notations of 'Received by:' at the beginning of each message?
If you don't want to see that sort of stuff on your screen, put
something like the following in your ~/.mailrc:
ignore address classification content-length email-version
ignore end-of-header end-of-protocol errors-to in-reply-to lines
ignore message-id message-version path phone posted-date precedence
ignore priority received references reply-to resent-date resent-from
ignore resent-message-id resent-sender resent-to return-message-id
ignore return-path security send-requests-to send-submissions-to
ignore sender status type ua-message-id x-mailer x-postmark
Does anyone really care what system received the message, that
systems ID number and a time stamp to boot?
Yes! `Received' is one of RFC822's (optional) trace fields:
4.3.2. RECEIVED
A copy of this field is added by each transport service that
relays the message. The information in the field can be quite
useful for tracing transport problems.
You're welcome not to add the trace fields to mail as it passes
through your machine, but it's much more polite to add them. It's a
way of accepting blame/credit for what you may have done to the
message as you passed it along. Other mail administrators will thank
you, and users are always able to ignore it.
I can tell what sites the message went through by looking at the
path line plus I can read the date the message was sent and I know
when I received it.
If you mean "Path:", then you're talking about a news article, not a
mail message. If you mean "Return-Path:", then you're welcome to
reconfigure your system's mail deliverer so as not to include it -
it's an optional field added by the final transport system. But
Return-Path: isn't an audit trail, only a suggestion of how you might
attempt to get back if you can't use From: and there's no Reply-To:.
Not to mention the bytes saved in transmission by eliminating all
this garbage. What can be done????
If you don't want to transport all those headers, then you're welcome
to establish a new standard by which you will exchange mail with your
neighbors. You'll probably need to write a gateway for them to run on
their machines, so that you can continue to receive mail from the rest
of the world.
If you come up with something that works, suggest it on
comp.mail.headers and/or write an RFC about it. The world will thank
you!
And if you don't like the verbosity of RFC822's headers, just wait
'till you see X.400 :-)david@ms.uky.edu (David Herron -- One of the vertebrae) (04/11/89)
If you don't want to see certain headers then use a mail reader
which doesn't *show* you those headers! Mush is a perfectly good
example of such a mail reader.
But *do* *not* suggest that we take away the Received: headers!
--
<- David Herron; an MMDF guy <david@ms.uky.edu>
<- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<-
<- The problem with mnemonics is they mean different things to different people.scott@dtscp1.UUCP (Scott Barman) (04/13/89)
In article <11470@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: >If you don't want to see certain headers then use a mail reader >which doesn't *show* you those headers! Mush is a perfectly good >example of such a mail reader. > >But *do* *not* suggest that we take away the Received: headers! 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. Just a thought: 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. 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? -- scott barman {gatech, emory}!dtscp1!scott
bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) (04/13/89)
In article <627@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: In article <11470@s.ms.uky.edu> david@ms.uky.edu (David Herron -- One of the vertebrae) writes: >But *do* *not* suggest that we take away the Received: headers! 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. Please read RFC822, section 4.3.2 on pages 20-21 for the definitive justification and explanation for the existence of Received. I am more interested in the message not what software, version number, or even system the note passed through to get here. You may not be interested, and you're welcome to ignore them by proper use of your mail-reading software. But if you ever have to figure out what happened to a particular mail message, nearly the first thing that you (or your postmaster) will need to look at will be the Received: headers. Are all these header lines needed because we have so many brain-dead machines running brain-damaged software? Yes. 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. It's the other 5% left over after that "pretty reliably" that make audit trails necessary. Also, it's an optional field. You're welcome to configure your system so as not to add it to headers as they pass through. It's not a friendly thing to do to your neighbors, though. Being only a five-year net veteran I have not had too many problems with mail. It sounds like your systems have been maintained well, and you've been corresponding with people on well-maintained systems over well-maintained connections. Others aren't so lucky, and need some help coping with the vagaries of life in an unreliable network.
rlk@think.com (Robert Krawitz) (04/13/89)
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-1111scott@cdp.UUCP (05/09/89)
> /* Written 7:38 am Apr 4, 1989 by bob in cdp:comp.mail.uucp */ > In article <5463@ozdaltx.UUCP> root@ozdaltx.UUCP (root) writes: > Wouldn't it be wonderful to receive e-mail WITHOUT scads of > notations of 'Received by:' at the beginning of each message? > > If you don't want to see that sort of stuff on your screen, put > something like the following in your ~/.mailrc: > > ignore address classification content-length email-version > ignore end-of-header end-of-protocol errors-to in-reply-to lines > ignore message-id message-version path phone posted-date precedence > ignore priority received references reply-to resent-date resent-from > ignore resent-message-id resent-sender resent-to return-message-id > ignore return-path security send-requests-to send-submissions-to > ignore sender status type ua-message-id x-mailer x-postmark You can also put the above lines in /usr/lib/mailx/mailx.rc (this may be different for Xenix) to have it affect all users. Scott Weikart Community Data Processing: 415-322-9069 cdp!scott%labrea@stanford.bitnet arisia.xerox.com!cdp!scott {decwrl,munnari,rutgers,sun,ut-sally,uunet}!cdp!scott