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-1111mju@mudos.ann-arbor.mi.us (Marc Unangst) (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. I am more interested >in the message not what software, version number, or even system the note >passed through to get here. The Received: headers come in VERY handy when your mail hasn't gotten from point A to point B, and you'd like to know why. They're often useful in discovering sites that do "active" rerouting (and thus enabling you to route around them if it's a problem). Yes, they're primarily a debugging aid, and they're not needed in most cases. But in those few cases where they're necessary, it's nice to have them. You might try using a mailreader that lets you configure which header lines you want to see. -- Marc Unangst UUCP : mju@mudos.ann-arbor.mi.us UUCP bang : ...!uunet!sharkey!mudos!mju UUCP bang alt.: ...!{ames, rutgers}!mailrus!clip!mudos!mju Internet : mju@mudos.ann-arbor.mi.us
scott@dtscp1.UUCP (Scott Barman) (04/15/89)
In article <248.244422A4@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >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. I am more interested > >in the message not what software, version number, or even system the note > >passed through to get here. > >The Received: headers come in VERY handy when your mail hasn't gotten from >point A to point B, and you'd like to know why. They're often useful >in discovering sites that do "active" rerouting (and thus enabling you >to route around them if it's a problem). Then why all the verbosity? As I recall from my old version 7 days, what happened to the "From" lines as post marks? It seems that this would work just the same without creating more "garbage" to unreliably transmit. Also, I worry more about someone's mailer munging the contents of my note by going in and altering things than I do mail not getting to where I want it! >Yes, they're primarily a debugging aid, and they're not needed in most >cases. But in those few cases where they're necessary, it's nice to >have them. You might try using a mailreader that lets you configure >which header lines you want to see. Up until now, /bin/mail has been fine to use (sort of). It goes into the mailbox, and displays the mail on the screen, one at a time, and lets me do things with it (save, forward, reply, etc.). NOW, because "someone" decided that my mail has to be delivered with the finger prints of every system it touches, I have to go out and get software loaded with "creeping featurisms" just to read the darned mail without all the garbage! What ever happened to the original Unix idea that small and simple is elegant? I think we should reconsider email in that light! -- scott barman {gatech, emory}!dtscp1!scott
leonard@qiclab.UUCP (Leonard Erickson) (04/17/89)
In article <636@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: <In article <248.244422A4@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: <>The Received: headers come in VERY handy when your mail hasn't gotten from <>point A to point B, and you'd like to know why. They're often useful <>in discovering sites that do "active" rerouting (and thus enabling you <>to route around them if it's a problem). < <Then why all the verbosity? As I recall from my old version 7 days, <what happened to the "From" lines as post marks? It seems that this <would work just the same without creating more "garbage" to unreliably <transmit. Also, I worry more about someone's mailer munging the contents <of my note by going in and altering things than I do mail not getting <to where I want it! All too many systems *don't* edit themselves into the From line (and some put themselves in the From: line!!! Grrr) As for munging things by going in and changing things, what do you think asdding to the From lines is? Adding Recieved lines just takes generating the line(s) and then appending the message to them! Much less chance of munging things. Much of the mail I get comes thru one or another site that doesn't add itself to the from line. This makes "reply" useless unless I remember to edit the header before sending. So I need to be able to go thru the Received lines to check for sites that are unfriendly enough to not add themselves... -- Leonard Erickson ...!tektronix!reed!percival!bucket!leonard CIS: [70465,203] "I'm all in favor of keeping dangerous weapons out of the hands of fools. Let's start with typewriters." -- Solomon Short
dan@ccnysci.UUCP (Dan Schlitt) (04/18/89)
In article <636@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: :In article <248.244422A4@mudos.ann-arbor.mi.us> mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: :>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! :> > :>The Received: headers come in VERY handy when your mail hasn't gotten from :>point A to point B, and you'd like to know why. They're often useful :>in discovering sites that do "active" rerouting (and thus enabling you :>to route around them if it's a problem). : :Then why all the verbosity? As I recall from my old version 7 days, :what happened to the "From" lines as post marks? : :NOW, because :"someone" decided that my mail has to be delivered with the finger :prints of every system it touches, I have to go out and get software :loaded with "creeping featurisms" just to read the darned mail without :all the garbage! : :-- :scott barman :{gatech, emory}!dtscp1!scott I don't understand this "NOW" bit. I don't remember a time when the uucp mail didn't have Received: lines. And that goes back 8 years or so. The From line is a uucp relic and is not useful for much of anything. The official header line is the From: line and it should contain an address, not a route. Those people who complain about having this information in their messages evidently don't have users come around and ask why the address (route) their friend told them to use to send them mail doesn't work. (Often they even have received mail from their friend.) The headers are the only real tool that I have to help solve this problem for them. If the message is bounced back then I can tell where it has been. With the multitude of networks and the gateways between them some sort of audit trail in the message is essential. If you don't encounter this sort of problem them maybe you aren't getting the full use out of the communications network that you have at your finger-tips. :-) -- Dan Schlitt Manager, Science Division Computer Facility dan@ccnysci City College of New York dan@ccnysci.bitnet New York, NY 10031 (212)690-6868
weening@Gang-of-Four.Stanford.EDU (Joe Weening) (04/20/89)
In article <641@dtscp1.UUCP> scott@dtscp1.UUCP (Scott Barman) writes: OK. Now that everyone has publicly and privately flamed me (and that most of you have said the same thing--basically), I would like to formally state my position and drop this. Hopefully, those who decide will just consider my side. One has to recognize that the Internet and its protocols have become dominant, and are supplanting any "standards" that ever existed in the UUCP world. Since I come from an Internet-based environment, I'm obviously biased in favor of this. The reference to "those who decide" is pretty meaningless, since there is no serious proposal to change anything here. But I'd like to reply to a few of Mr. Barman's comments. Now I don't understand this "official" bit. Where is it written that "this is the way?" I check through all the Usenet documentation including what can be found in *.newusers and I do not see this as official. I've been also "guided" to RFC 822. Well, the last I heard, RFC stands for Request For Comment and not "this is the standard!" RFCs are used to present Internet standards as well as experimental protocols. They are usually clear about when they do so, but RFC 822 came slightly before the rest of the Internet protocols were in wide use, so it may not say that it is a standard. Later RFCs, however, do say that RFC 822 is a standard for Internet mail transmission. I send mail to a!b!c!user then the From lines would look like From mail-agent date >From mail-agent date remote from b >From mail-agent date remote from a >From my-userid date remote from my-machine It has almost the same information as the Received lines and each machine would produce the "postmark" and append the mail to it before passing it along without having to go in and edit the headers. Also, from this I can write a function that will recreate the return path since this is consistant and many of the Received lines I have seen are not. It is also less verbose and less cumbersome. Now would someone please tell me (without flames) why this is no good? Unix was not a predominant operating system when the Internet stand- ards were designed. The "!" character acts as a comment character on several systems. This may seem like a minor point, but the protocol designers needed to come up with a syntax that would work across diverse systems. It necessarily had to be a compromise of some sort. I'm sorry I don't have time to respond to the many other points in the original message. But please consider the following: 1. Between Internet hosts, there is generally no problem delivering mail. 2. Between UUCP hosts using a path that contains no Internet links, there are also not many problems. So your solution is simple: if you don't want to join the Internet, just find paths that stay away from it! Unfortunately this is no longer practical. So in return for all of the extra connectivity you now have compared to the "good old days" of V7, you are going to have to accept some of the things that make life easier for us Internet folks. -- Joe Weening Computer Science Dept. weening@Gang-of-Four.Stanford.EDU Stanford University
david@ms.uky.edu (David Herron -- One of the vertebrae) (04/21/89)
>What ever happened to the original Unix idea that small and simple >is elegant? I think we should reconsider email in that light! >scott barman >{gatech, emory}!dtscp1!scott Ever think that some problems just *aren't* small and simple or for some other reason don't (yet) have elegant solutions? -- <- 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.
pcg@aber-cs.UUCP (Piercarlo Grandi) (04/21/89)
In article <10716@bloom-beacon.MIT.EDU> tytso@athena.mit.edu (Theodore Y. Ts'o) writes: Yes, there should always be a way to do source routing. However, most of the time it is _not_ the best way to do things. [...additional reasons for not doing source routing, e.g. not forcing everyone to update their maps, and avoiding users writing very long routes...] Again on smart routing! Actually, even UUCP routes need not be source routes; you can always leave them udnerspecified, if you feel like it, and let the MTAs at yours and other sites flesh them out. It has been a long time since users have been required to type themselves the routes. Nowadays, even on UUCP only machines, they type dest!user or use@dest, and the MTAs generate the route. Now the question is: should intervening MTAs rewrite the route generated by previous MTAs or not? the non smarting rule is: NEVER. The only permissible thing is to put in missing links at the BEGINNING of the route. Now, a fully dynamical UUCP routing system would just at every step add one component to the path. Example: mail f!u, from a, and let us see what can happen: Fully specified source route: b!c!d!e!f!u Weakly specified route: b!d!f!u Here what happens is a's MTA asks b's MTA to find a route to d; then d's MTA will have to find a route to f. But is is guaranteed that (in the absence of path rewriting) mail will pass thru d on its way to f. Unspecified route: b!f!u Here b is asked to devise the entire route to f. When b's MTA see f!u, it can again choose whether to use fully, weakly, or unspecified routing. If every MTA on the path uses unspecified routing,then we have fully dynamic routing, in which each MTA only selects the next MTA in the chain (and then we have the usual problems with loops, etc... of dynamic routing algorithms). Note that this is because the rule is that an MTA may only, and always (well...) has a right to, prepend components to a path, never to delete or rewrite them. E.G., even the b!c!d!e!fu fully specified route may become in the end b!c!d!g!e!f, but this is a moditication that is only allowed to d's MTA, if it reckons that going through g is the best way to reach e. By the way, this also applies to Arpa routes etc... All this has been discussed to death in the past, but it may pay repeating it here; someday maybe some smart rerouter may be persuaded... -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
tytso@athena.mit.edu (Theodore Y. Ts'o) (04/23/89)
In article <841@aber-cs.UUCP> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >Again on smart routing! Actually, even UUCP routes need not be source routes; >you can always leave them udnerspecified, if you feel like it, and let >the MTAs at yours and other sites flesh them out. It has been a long >time since users have been required to type themselves the routes. Nowadays, >even on UUCP only machines, they type dest!user or use@dest, and the MTAs >generate the route. Perhaps I'm being confused, but I was under the impression that "most" UUCP sites do not handle smart routing; that most sites did not run pathalias or something like it, so that if you sent mail to b!d!f, and site b did not talk directly to site d, it would normally bounce. Thus sites like ihnp4 (before it got shutdown) were "used" as smart routers to generate uucp routes becuase most sites couldn't do it on their own. That was why I made the statement I did that UUCP does _not_ do smart routing, and that you _do_ need to give a fully specified route, since you can't depend on sites running a smart uucp mailer. Is this still true, or do most people really use a smart mailer that can figure out routes these days? Send responses to me, and I will summarize. BTW, for sites that do use pathalias, I completely agree with you that MTA should _never_ try to rewrite paths. However, saying that seems to do as much good as proclaiming that mailers should never rewrite From: addresses or that people should not use the Path: line found in news articles for mail purposes..... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Theodore Ts'o bloom-beacon!mit-athena!tytso 3 Ames St., Cambridge, MA 02139 tytso@athena.mit.edu Everybody's playing the game, but nobody's rules are the same!
henry@utzoo.uucp (Henry Spencer) (04/25/89)
In article <WEENING.89Apr19185059@Gang-of-Four.Stanford.EDU> weening@Gang-of-Four.Stanford.EDU (Joe Weening) writes: >One has to recognize that the Internet and its protocols have become >dominant, and are supplanting any "standards" that ever existed in the >UUCP world... It depends on what you mean by "supplanting"; if you measure it by counting systems, I think you might be surprised. The trend is clearly that way, but the uucp world has a huge head start in sheer number of machines. > [from earlier posting] > From mail-agent date > >From mail-agent date remote from b > >From mail-agent date remote from a > >From my-userid date remote from my-machine > > It has almost the same information as the Received lines and each machine > would produce the "postmark" and append the mail to it before passing > it along without having to go in and edit the headers. Also, from this > I can write a function that will recreate the return path since this > is consistant and many of the Received lines I have seen are not. It is > also less verbose and less cumbersome. Now would someone please tell > me (without flames) why this is no good? It's not that it's no good, it's just that it's different. The situation isn't helped by a lot of Unix software that tries to smush the two conventions together rather than converting between them at gateways. (Thanks, Berkeley. :-[) Given the Internet's political backing, its way of doing things is, perhaps unfortunately, increasingly dominant. >... So in return for all of the extra connectivity you now >have compared to the "good old days" of V7, you are going to have to >accept some of the things that make life easier for us Internet folks. And of course, you Internet folks wouldn't even *consider* accepting some of the things that make life easier for us uucp folks, in return for all the extra connectivity *you* now have, even though we are (by some measures at least) the larger community. Heavens no. We all know that the Internet is divinely ordained, and all others are inferior heathens. The fact that the Internet is the smaller of the two groups is totally irrelevant, because the Internet way of doing things is the One True Way that all should follow. The above is *slightly* overstated... but many of us in the uucp world have never been terribly happy about the Internet world's parochial and patronizing "do it our way" approach to [dare I use the sacred word?] internetworking. Understand, I'm not saying that the Internet Way is necessarily bad. On the whole, it's okay. But when the answer to problems in internetworking (*real* internetworking, not just two TCP/IP networks talking to each other) is invariably "let them eat RFCs", one should expect a bit of resentment from the heathens. -- Mars in 1980s: USSR, 2 tries, | Henry Spencer at U of Toronto Zoology 2 failures; USA, 0 tries. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
tytso@athena.mit.edu (Theodore Y. Ts'o) (04/25/89)
In article <1989Apr24.203137.5835@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: >It depends on what you mean by "supplanting"; if you measure it by counting >systems, I think you might be surprised. The trend is clearly that way, >but the uucp world has a huge head start in sheer number of machines. > ..... >And of course, you Internet folks wouldn't even *consider* accepting some >of the things that make life easier for us uucp folks, in return for all >the extra connectivity *you* now have, even though we are (by some measures >at least) the larger community. Heavens no. We all know that the Internet >is divinely ordained, and all others are inferior heathens. The fact that >the Internet is the smaller of the two groups is totally irrelevant, because >the Internet way of doing things is the One True Way that all should follow. Well, let's see.... doing an analysis of our pathalias output, which is based on all of comp.mail.maps, I get: # sites hops 4 25 ! 188 !! 710 !!! 2043 !!!! 5639 !!!!! 3444 !!!!!! 3631 !!!!!!! 1442 !!!!!!!! 216 !!!!!!!!! 20 !!!!!!!!!! ----- 17,362 uucp mail sites registered in comp.mail.maps Granted, this doesn't get all uucp hosts, since people haven't registered their machines and it doesn't count hosts which are hidden behind another machines. Does anyone have a better figure? The best estimate of the number of Internet sites (which includes Arpanet, NSFnet, etc.) which I have is 56,000. Again, does anybody have a better figure? Given these figures, though, I have to question Henry's statement about the uucp world being a much larger community than the Internet. Even if the Internet is bigger though, it is still not a reason by itself to ignore the needs of the uucp community. It *is* possible to set up your mail system so that the right thing (mostly) happens when gatewaying between the two worlds. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Theodore Ts'o bloom-beacon!mit-athena!tytso 3 Ames St., Cambridge, MA 02139 tytso@athena.mit.edu Everybody's playing the game, but nobody's rules are the same!
barnett@crdgw1.crd.ge.com (Bruce G. Barnett) (04/25/89)
In article <10825@bloom-beacon.MIT.EDU>, tytso@athena (Theodore Y. Ts'o) writes: >The best estimate of the number of Internet sites (which includes >Arpanet, NSFnet, etc.) which I have is 56,000. Again, does anybody >have a better figure? I just attended a course given by Paul Mockapetris, and he believes the figure is closer to 100,000. He knows of two companies that have ~20,000 hosts that aren't connected/publicized. -- Bruce G. Barnett <barnett@crdgw1.ge.com> a.k.a. <barnett@[192.35.44.4]> uunet!steinmetz!barnett, <barnett@steinmetz.ge.com>
wcs) (04/26/89)
In article <10766@bloom-beacon.MIT.EDU> tytso@athena.mit.edu (Theodore Y. Ts'o) writes:
:Perhaps I'm being confused, but I was under the impression that "most"
:UUCP sites do not handle smart routing; that most sites did not run
:pathalias or something like it, so that if you sent mail to b!d!f, and
:site b did not talk directly to site d, it would normally bounce.
Well, first of all, uucp doesn't *do* routing, mailers do.
Uucp sends things one hop; traditional mailers use uucp to
uux an rmail command at the next site. rmail routes.
But if you're a site with a dumb mailer, and you know a site
with a smart mailer, you can use it. When I send mail from
skep2 (my newsbox) to an internet site, I normally send it to
att!foo.bar.edu!person
Skep2 knows how to reach att (and most other AT&T machines),
and att takes care of the rest.
On the subject of Received: lines vs From lines, both of
them are things mailers do to articles they're transmitting,
but neither one is the One True Header approach,and other
mailers do even different things which may or may not show up.
I prefer From ... \n>, partly because it's a wrapper rather
than something inside the message, but mainly because I'm
used to it. (I also get annoyed that Received: is typically
two lines, so I can't just g/re/d it away in vi.)
Rewriting From: lines is generally viewed as evil, and I
don't trust them any more than I trust Path: - but Rnmail
uses Path: and it usually works, so I use it on my old
news server. Now that I'm using Mark's news server, I'll
use whatever he provides :-).
--
# Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs
# also found at 201-271-4712 tarpon.att.com!wcs pozar@hoptoad.uucp (Tim Pozar) (04/27/89)
In article <10825@bloom-beacon.MIT.EDU> tytso@athena.mit.edu (Theodore Y. Ts'o) writes: >The best estimate of the number of Internet sites (which includes >Arpanet, NSFnet, etc.) which I have is 56,000. Again, does anybody >have a better figure? I hope you included the >6000 machines that are in FidoNet :-). Tim -- ...sun!hoptoad!\ Tim Pozar >fidogate!pozar Fido: 1:125/406 ...lll-winken!/ PaBell: (415) 788-3904 USNail: KKSF / 77 Maiden Lane / San Francisco CA 94108
cks@ziebmef.uucp (Chris Siebenmann) (04/29/89)
I've just discovered another case where Received: headers would be
very useful if only the systems involved would give them to me. I
recently posted some messages to comp.unix.ultrix, which used to be
moderated and is now unmoderated. So far, I have got 24 bounce messages
from mailers; either because people gateway the newsgroup into a
mailing list or because they're trying to send it to the
ex-moderator's machine and not having much success.
If the bounce messages had included Received: headers on the messages,
I could have found out the systems that gatewayed between the newsgroup
and email. As it is, I'm going to have to bother the sysadmins at the
sites that are bouncing my messages instead.
Received: headers are fluff most of the time ... but once in a while
you want them BADLY.
--
"Oh BLESS you, sir! The ANGEL OF DEATH was after me just as SURE as
you're standing there, yes he WAS!"
Chris Siebenmann uunet!{utgpu!moore,attcan!telly}!ziebmef!cks
cks@ziebmef.UUCP or .....!utgpu!{,ontmoh!,ncrcan!brambo!}ckssnoopy@sopwith.UUCP (Snoopy) (05/12/89)
In article <1989Apr24.203137.5835@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: |In article <WEENING.89Apr19185059@Gang-of-Four.Stanford.EDU> weening@Gang-of-Four.Stanford.EDU (Joe Weening) writes: |>One has to recognize that the Internet and its protocols have become |>dominant, and are supplanting any "standards" that ever existed in the |>UUCP world... And one has to wonder why yet another case of inferior "standards" are being allowed to become dominant. UUCP is clearly superior. Those who are tempted to argue for the ARPA Internet conventions should read and understand "The Hideous Name", by Rob Pike and P.J. Weinberger, in the Summer 1985 Usenix Conference Proceedings. A few short quotes to whet your interest: research!ucbvax!@cmu-cs-pt.arpa:@CMU-ITC-LINUS:dave%CMU-ITC-LINUS@CMU-CS-PT -Carnegie-Mellon University mailer I cannot tell what the dickens his name is. -Shakespeare, Merry Wives of Windsor, II. ii, 20. "specification of a fully qualified address can become inconvenient." - RFC 822 Second, there are at least two special characters, '@' and '.', although the @ serves no purpose. Finally, the standard requires 'registered' domain names: all the names that occur as domains in valid names must be registered before use, thus arrogating to ARPA Internet administration the authority to legislate naming. As a result, the whole thing is encompassed in a closed society and there are very few registered names. So much for internetworking. -R.P. & P.J.W. Some standards are sound and indispensable; some simply celebrate bureaucratic littleness of mind. -Doug McIlroy They [RFC 822 & 882] represent the unilateral imposition of a deficient standard that is poluting those communities that have comprehensible naming schemes. -R.P. & P.J.W. To those who argue which network is larger, consider (a) the large and growing population of 'personal', 'home', and 'small business' machines using UUCP protocols; and (b) whether technical issues should be decided by the method of might-makes-right. _____ /_____\ Snoopy "My dot-matrix does Postscript." /_______\ |___| tekecs.gwd.tek.com!sopwith!snoopy |___| sun!nosun!illian!sopwith!snoopy parsely!sopwith!snoopy