zben@umcp-cs.UUCP (Ben Cranston) (10/11/85)
Since I have had the luxury of doing little else but electronic mail for the
past few years, and have been looking at it from a fairly global viewpoint
(by this I mean avoiding "unix tunnel vision") I thought to clog up the net
with a few random thoughts. If this seems a bit disconnected, consider that
I have just read roughly 300 messages from this newsgroup, over the past
eight hours or so. (Catching up is h*ll).
One: since there are user agents and mail programs, there may be one or two
levels of translation between what the user types to the mail agent in the
way of addresses and what actually comes out the wire to the next site. One
level of translation is done somewhere between the user agent and the mail
delivery program, another is typified by the IBM VM/CMS NAMES facility or the
VMS names thing - a mapping between a private universe of short rememberable
names and the ugly strings we use to get from machine to machine.
Even though we are a BitNet and ARPA Internet site, and not a UUCP site
(I speak of UMD2.UMD.EDU/UMD2.BITNET here), I happen to like the bang syntax.
Since I am a Christian, I read from left to right. I think the RFC822 forward
syntax (@one,@two:user@three) is a real crock! The user%three%two@one syntax
requires me to read from right to left. If we were doing things from a
cognitive engineering/user friendly viewpoint, we would have the user talk
bang to the mail agent, and have the delivery program do whatever translation
is required for whatever connection we FIRST send the message through.
In this spirit the examples given below are given in bang syntax, please feel
free to translate to whatever you happen to like.
Two: with mixed-syntax addresses like one!two!user@three there will always be
the parse ambiguity. One of the terrible things about electronic mail is
that to create a workable multihop address one needs to cobble together a form
that not only is acceptable to the source and destination machines, but also
to EVERY MACHINE THAT THE MESSAGE MUST PASS THROUGH! Given this constraint,
I have no choice but to argue that ANY ADDRESS, AT ANY TIME, MUST BE CODED IN
ONLY ONE SYNTAX. That is, we declare mixed mode addresses like the above as
invalid.
Three: now, let us contemplate a complex address that passes through two relays
(inter-network gateways, er, ah, you know what I mean):
gun!bullet!arpauucp!elf!wizard!uucpbnet!blue!user
Note that though this address is given in bang format, gun and bullet are
ARPA Internet sites, arpauucp is a gate, elf and wizard are UUCP sites,
uucpbnet is a uucp to BitNet gate, and blue is a BitNet site. Presumably
when the user at an ARPA Internet site types this address, the software
translates it to:
@gun,@bullet,@arpauucp,@elf,@wizard,@uucpbnet:user@blue
before putting it out into the ARPA Internet. I also assume that at the
gate site arpauucp the remainder of the address gets rewritten as:
elf!wizard!uucpbnet!blue!user
and that at the gate site uucpbnet the remainder of the address becomes:
user@blue
again.
There are those here on the net who claim that ALL sites in the address must
be known to EACH site in the path. Perhaps to substitute official names, as
the 82x standards claim must be done in intersite communications. Perhaps
even the authors of the RFCs thought that they could subsume UUCP and all the
other networks within the domaining scheme. Regretably this is not now the
case, and given the choice between a strict interpretation of the standard
and having things WORK, I am inclined to bend the standard just a little bit.
Some people tie the site lookup function to the exact syntax. If it is
decided that the address is in bang form, they look in the UUCP list, if it
is in @ form they look in the Internet list, etc. The problem with this
approach is that it REQUIRES mixed-form addresses, and we are back to the old
"do we parse ! or @ first" question.
As an example to clarify these viewpoints, some would claim that the address:
@gun.arpa,@bullet.arpa:user@blue.bitnet
is prima facie illegal because .bitnet is not a recognized ARPA domain.
While this may be true given a strict reading of the standards, and will work
well if there ever IS a real .bitnet domain with an accessable nameserver,
just by bending the rules a bit we can accept it now, and have mail WORK.
Others cry "cruft" at this address:
@gun,@bullet,@elf,user@wizard
and would require the address be given as:
@gun:elf!wizard!user@bullet
so that "elf" is looked up in the UUCP list and not the ARPA list.
By taking the viewpoint that addresses are syntactically changed at gates,
but that site names in the list need not be known at the gates (except for
the first one, the one we will forward to, of course), we get the best of
both worlds. What this boils down to is this: if we ever WERE to want to
completely process an address, looking up the sites, the universe or set of
default domains or whatever would change at the point in the address a gate
was mentioned. But, if we leave the substitution of the official name, the
only reason we really need to LOOK at the site names, to be done incrementally
at each gate, we never NEED to process site names beyond the first one. As
an example:
@gun.arpa,@bullet.arpa:user@blue.bitnet
the software at "gun" never NEEDS to lookup "blue.bitnet". It might very
well substitute "bullet-m16" as the official name for "bullet", but it can
leave the lookup of "blue.bitnet" to site "bullet", which as a gate is
presumed to have access to the .bitnet name list.
Last: there seem to be sites out there that love to talk to multiple
networks, but are less sanguine about playing by the rules. Every time a
message comes through my Arpa-BitNet gateway with a header field like:
From: Joe Luser <luser@podunk.UUCP>
my software drops a five page print file complaining that it can hardly cast
this address into a BitNet address when it doesn't know ANYTHING about the
.UUCP domain. Whatever cutesy site let this monstrousity into the Arpanet
*SHOULD* have rewritten the address as something like:
From: Joe Luser <@cutesy.ARPA:luser@podunk.UUCP>
In which case my software would be satisfied that it knows how to get to
"cutesy.ARPA" (never bothering trying to lookup "podunk.UUCP") and finally
would rewrite the field something like:
From: Joe Luser <luser%podunk.UUCP%cutesy.ARPA@umd2>
and replies would actually work! If somebody replied to the address, it
would come back to me as:
luser%podunk.UUCP%cutesy.ARPA@umd2
I would rewrite it as:
@cutesy.ARPA:luser@podunk.UUCP
"cutesy" would rewrite it as:
podunk!luser
QED.
I am not holding my breath. Sigh. Well, at least I get three or four
random samples a day of what my software is REALLY doing. Good for debugging
and riding herd on the d*mn thing.
--
Ben Cranston ...seismo!umcp-cs!zben zben@umd2.ARPAscott@cstvax.UUCP (Scott Larnach) (10/25/85)
>Two: with mixed-syntax addresses like one!two!user@three there will always be >the parse ambiguity. > [ ... ] >Given this constraint, >I have no choice but to argue that ANY ADDRESS, AT ANY TIME, MUST BE CODED IN >ONLY ONE SYNTAX. That is, we declare mixed mode addresses like the above as >invalid. > >Ben Cranston ...seismo!umcp-cs!zben zben@umd2.ARPA Yup, I agree. WITHIN any network, an address should be in the style standard to that network. All the three addressing styles I have come across (uucp, 822, Greybook (UK)) have standard ways of specifying source routes (ok, 822 is a bit funny). Conversion is possible (without going in to the limitations of particular mailers). Then "all" you need to do to ensure that routes work is to require gateways to properly convert between those styles. Now there's the rub. I once made this suggestion publicly and I got lots of people mailing back saying you're living in a fantasy world chum, you'll never get the gateways to come round to doing that. But I can't help thinking it would be worth the effort. The alternative seems to be the same old hassles dragging on & on & on.... -- Scott Larnach Janet: scott@uk.ac.ed.cstvax Edinburgh Unix Support Arpa: scott@cstvax.ed.ac.uk Tel: +44 31 667 1081 x2629 Uucp: scott@cstvax.uucp
jer@peora.UUCP (J. Eric Roskos) (10/27/85)
I see that in the 2 weeks that I've been off converting MH.5 to run under
System V (and our site has been converting itself to System V, for that
matter), despite my exhortation that people not followup on my article
with reiterations of things said in the past, people have continued to
repost the same ancient, tired arguments. Except those who have decided
to resort to ad hominems by claiming I don't know the definition of AI
(I used to work for an AI software company, so naturally I am hopelessly
out of touch with what academia feels is the definition, regardless of
what people who have just encountered me may think of my position in that
regard (-:).
We have seen reiterated the statement that routing strings with "@" in
them are "dangerous" (the point at which Mark Horton and I reached an
impasse on this debate by mail, incidentally) because they are
"ambiguous". In fact, that seems to be the "jist" of all the counter-
arguments regurgitated. We have also seen disconnected statements that
say "!-precedence is preferable in the UUCP network" and then go on to
assert, without intervening premises, that therefore "@" in a routing
string should be "declared invalid".
I've only seen one marginally close counterargument, and that is the one
that argues that @ should be given precedence for "consistency". Well,
that is fine in the theoretical world, but not in reality; as I have
pointed out to some of you who have recently sent me mail, RFC822 does not
require consistency, however, for the message envelope, and the attempts
to force consistency retroactively on the UUCP network are what I am claiming
is itself dangerous.
Now, for those of you who insist on making their arguments by quoting Mr.
Rogers or popular comedians, let me point out that the last clause on the
above sentence is a proposition which I am about to informally demonstrate.
Prior to the introduction of software which was intended to integrate the
networks, the character "@" had no significance as a distinct token in the
UUCP routing language. [An aside for the stubborn: the UUCP routing language
is the language in those files named "D.mysiteX123AB", or
"X.mysite1234AB", in the UUCP queues. It has nothing to do with the plain
D. files containing the messages which, except for routing stamps at the
front, most of us (including me) agree should be RFC822-compliant.]
Therefore, one would send mail destined for a "gateway" through using
the "!" syntax, with a destination mailbox name looking something like
"joe@bigvax.ARPA". Now, if your average UUCP site tried to send to a
mailbox with that name, it would go looking for a user in /etc/passwd with
that name, wouldn't find one, and would reject the address as erroneous.
However, some sites, the gateways, were smarter, and would treat it as an
address on another network, which they would send it to.
Then someone produced a product which they introduced into a software
distribution, which was intended to help these gateway sites. But it was
distributed to everyone, and soon many people installed it, whether they
needed it or not. And furthermore, AND THIS HAS BEEN MY POINT, they in-
stalled it in violation of what has come recently to be called Lauren's
rule, because an arbitrary site out there, say mine, whose users had
been trained to use the old syntax, couldn't any more, because suddenly
that site was *no longer accepting the syntax that had formerly been in use*.
It was accepting a *new language* entirely.
Recent arguments have overlooked this; in typical self-centered fashion,
they say instead "now that I've installed @-precedence transport agents
here, *that* will be the standard; all the old sites just accidentally
didn't know about @, and they are wrong."
In fact, however, standard AT&T Unix mail still does not give @-precedence.
It probably won't do so until AT&T either adopts Sendmail, or Smail, or
another of the new smart mailers.
Ironically, I guess, I am *not* making my argument from a similar
position, since our mailer here can handle either syntax, simultaneously,
and in fact presently does: it uses "@" when going through mailers at
certain industrial sites which don't recognize the new syntax, and uses
"!" when going through some of the newer sites, particularly Seismo.
(Presently it can't do this when using the probabilistic gateway selection
scheme for distributed nameservers, but that is a present limitation, not
a feature.)
The real problem here, I've recently come to conclude, is a psychological
one. Sendmail is so difficult to reconfigure that now that most sites have
some semblance of a working sendmail.cf file, everyone is in grave terror
of ever having to change it. And, ironically too, the approach I have
been proposing would not require changing any sendmail.cf files! It would
require sites that are currently in violation of Lauren's rule replace
their sendmail-invoking rmail with a slightly "smarter" rmail that didn't
give @-precedence, voluntarily, if they wanted to comply. And, even yet
more ironically, the UUCP Project is about to release just such a product,
which could provide just that facility; but instead it provides @-precedence.
Actually it's true that this has become a "religious debate". My site can
handle either syntax, in compliance with the original UUCP routing
language; sites that install smail will handle it just fine, as will
Sendmail sites. The only ones that won't are the ones with "dumb mailers,"
such as mailx or plain Unix mail, where the users will suddenly have to
be instructed to write their routing strings slightly differently, or edit
their alias files if they have them.
Well, my religion says you should be kind to people, and my argument is
largely one from kindness and upward-compatibility.
That's all I have to say on the matter, then. Maybe I should end with an
ad hominem! But no, this is a "religious" debate, so I will turn the
other cheek and all that.
It is a sad thing, though, that I have seen so little logic (in the form
of extended argument) and so much regurgitation of simple facts and
superstitions. Also that the supporters all write by *mail*, while the
ad-hominem detractors post news messages!
So maybe I can get back to work now... and if users at dumb-mailer sites
grumble and complain, I could always smugly say "GO NEM!" I guess upward
compatibility is our middle name (not "who" :-)).
-----------
Disclaimer: The above does not necessarily reflect the opinion of the
Perkin-Elmer Corporation. Furthermore, I am not involved in the implem-
entation of present Perkin-Elmer mail products.
NEM is a trademark of the Perkin-Elmer Corporation.
--
Shyy-Anzr: J. Eric Roskos
UUCP: Ofc: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
Home: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer
US Mail: MS 795; Perkin-Elmer SDC;
2486 Sand Lake Road, Orlando, FL 32809-7642hokey@plus5.UUCP (Hokey) (10/31/85)
JER, I'm sorry you spent 2 weeks making MH.5 run under SysV. MH.6 requires
almost no effort, and should be out very soon.
You also state that after privately debating with MRH the viability of hybrid
routes (due to the ambiguity problem), the two of you reached "an impasse".
Gee, whiz! I tried to explain the problem to you as well. The conversation
sort of died on the vine. I wonder who else has tried to sway you toward
our perception of reality.
Problem #1: ! vs. @ parsing ambiguity in the UUCP transport layer.
Solution: resolve the ambiguity
Implementation #1: Permit hybrid routes, and make everybody parse them
the same way.
Problems: Doesn't work at gateways. Requires smart mailers in lots
of places, or requires users to know how to specify the route.
Falls apart when a site decides to become a gateway, because the
routing rules change for everybody who passed mail through that site.
Requires *everybody* who is accepting either ! or @ mail to make sure
they follow the "rules", and possibly change the way they parse. This
last bit means work for the admin, and an overall education program for
lots of people. It has not been demonstrated that this implementation
is even workable, due to the problems of routing *through* gateway sites.
Implementation #2: Permit hybrid routes, and make every site which accepts
! or @ make an "intelligent" choice about what the sender really wants.
Problem: Pathparse has't been released yet. When it is released, it
will require an "appropriately" sized database, which must be maintained.
Maintenance is not a big issue.
Implementation #3: Prohibit hybrid routes.
Problem: Unless a site has a mailer which can handle minimal routing, users
who wish to *initiate* (*not* reply to net articles) have to know how to
specify the path to the nearest smart machine. This implementation has
the dubious advantage of breaking things no more than once. It brings
to a head the issue of education.
Problem #2: Many sendmail sites *always* prepend their name to the From: line.
This is especially nasty since @ has clear precedence over ! in this field,
and changing a@b to c!a@b means b->c->a, *not* c->b->a.
Solution: Find them, and fix them.
Implementation: Get the offender to correct it.
Extra Protection: Keep the From: line in ! format in UUCP land. This way,
sites which prepend their name will take b!a and produce c!b!a or b!a@c,
either of which is "correct".
The To: line is used by mailers to build the recipient list. This includes
"traditional" dumb mailers (binmail).
Problem #3: Dumb mailers will produce hybrid routes if any recipient has
an @ in his address.
Solution: Keep recipient fields in ! format.
Implementation: Do it!
Anyway, you go on to state (correctly, I believe) the problem lies with the
relatively difficult job of making sendmail work in the UUCP environment.
Yes, if people didn't run sendmail, we wouldn't have the problem. However,
people use sendmail. (Unfortunately, the major solutions you propose *require*
people to change their software. Additionally, I *think* your solutions will
not work at gateway sites.)
Sendmail.cf files are not easy for everybody to handle. I know I have
problems with them.
HOWEVER, newer versions of sendmail make it *much* easier to write config
files, and several people are writing versions which are capable of
supporting a wide variety of system configurations with very little
maintenance effort.
I have it on good authority that sendmail source can be put on any system
licensed for SysV or 4.2 (or later) BSD. These sources seemed to think
that there is a 99% chance that sites with 32V, V7, or SysIII licenses
would also be able to have sendmail. 4.1BSD was not mentioned, but I doubt
there would be a problem.
--
Hokey ..ihnp4!plus5!hokey
314-725-9492jer@peora.UUCP (J. Eric Roskos) (11/01/85)
> JER, I'm sorry you spent 2 weeks making MH.5 run under SysV. MH.6 requires > almost no effort, and should be out very soon. You've obviously never tried to order an outside piece of software from within a large software organization! It was no problem, really... much of the time was spent in porting our router and nameserver. I had promised earlier to write an article on porting MH.5, but then Mr. Rose wrote and told me that MH.6 was coming out soon, so I decided not to. Anyway, to turn to the issues you raised... I can certainly appreciate the arguments against using "@'s" in UUCP routing strings. I strongly disagree with calling them "hybrid addresses," however, because they are not addresses, they are routes, and they are not hybrid, since "@" doesn't mean anything to any but a few modified Unix sites. > I wonder who else has tried to sway you toward our perception of reality. No one. The funny thing is, it seems to be a vocal minority who advocate giving "@" special status in the routing language. Thus the only people who have tried to convince me (other than the folks at Seismo) are the ones who have written in here. > Implementation #1: Permit hybrid routes, and make everybody parse them > the same way. > Problems: Doesn't work at gateways. It does, too. But we've been over this so many times, algorithms and all, that I'm tired of reiterating it. > Requires smart mailers in lots of places, or requires users to know > how to specify the route. No it doesn't... it doesn't require any more smartness to write in one routing language than the other... what's the difference between (assuming a site that only has Unix mail and no router) writing petsd!vax135!ucbvax!sam@slowvax.ARPA or petsd!vax135!ucbvax!slowvax.ARPA!sam It just involves permuting the last two name tokens, and replacing the last @ with a !. > Falls apart when a site decides to become a gateway, because the > routing rules change for everybody who passed mail through that site. No it doesn't... this site presently is not a gateway, however it is a domain nameserver and a site many people route through here in Florida. However, I wrote the router with the intent that someday it would become a gateway, since we have machines here that are not on the UUCP network. If we ever make that conversion, I will have to add the change to rmail which the person at NCR in Torrey Pines recommended awhile back, whereby the domain table also specifies the program to run to exit the UUCP network (there's even an unused field in the domain table for that purpose... many people have been trying to guess what it's for). Presently it's much simpler; since the original code didn't support the ..!slowvax.ARPA!... syntax (although I agree that that is a good addition) it was not necessary to give any special handling, so when the "!'s" ran out, I would route it out of the network and into the inter-network delivery program. The model I presently use is that the local mail system is a separate network; under this model, all sites are "gateways", and this is entirely reasonable, very regular and orthogonal. With the new syntax, when it does a domain lookup it needs to also decide whether it's time to leave the UUCP network, which there's a field but no code for yet. But the syntax will not change. > Requires *everybody* who is accepting either ! or @ mail to make sure > they follow the "rules", and possibly change the way they parse. This > last bit means work for the admin, and an overall education program for > lots of people. It has not been demonstrated that this implementation > is even workable, due to the problems of routing *through* gateway sites. In fact, this is exactly the problem with the no-@ approach. Presently everyone follows the "rules" automatically, except at a few sites; and Gene Spafford just posted a Sendmail configuration file that makes the sendmail sites work too. However, now it is being proposed to distribute a new program that imposes new rules (an excellent program, I understand, and not one I am criticizing except on this one minor point). There also should be no problem with routing through gateway sites. The problem you are alluding to, I think, is the one in which some gateway sites route all their mail through Sendmail, and have sendmail always give "@" precedence. As for requiring additional education for people... people are now using a particular syntax to reach the ARPAnet, for example. Soon it won't work any more, and they will have to be >reeducated<. > Implementation #2: Permit hybrid routes, and make every site which accepts > ! or @ make an "intelligent" choice about what the sender really wants. But not an artificially intelligent choice, you understand... :-) > Problem: Pathparse has't been released yet. When it is released, it > will require an "appropriately" sized database, which must be maintained. > Maintenance is not a big issue. I've stated repeatedly here that the *sender* should write RFC822 addresses, which should be parsed with "@" precedence, and that sites along the way should give "!" precedence. Pathparse is a very good enhancement that allows the user to have more flexibility in writing what he or she wants to be the destination of the message, but I am making an argument on behalf of sites that have no special software at all. > Extra Protection: Keep the From: line in ! format in UUCP land. This way, > sites which prepend their name will take b!a and produce c!b!a or b!a@c, > either of which is "correct". I don't like this approach, and I wish we could discuss this, or some other topic, instead of going over and over the @-precedence issue. Presently the many strange ways sendmail sites macerate the routing stamps on the fronts of the messages cause a lot of problems generating replies. If you are going to argue in favor of RFC822 compliance (which I think you should), then you shouldn't compromise on these issues. > I have it on good authority that sendmail source can be put on any system > licensed for SysV or 4.2 (or later) BSD. These sources seemed to think > that there is a 99% chance that sites with 32V, V7, or SysIII licenses > would also be able to have sendmail. 4.1BSD was not mentioned, but I doubt > there would be a problem. I don't see the point to this. Why would other sites want to install Sendmail? I recall what they told me when I first started working on the mail system here... "Don't even think of installing Sendmail." Why should your average site install sendmail? It was written for use at gateways. I get all the advantages of Sendmail, even a nice "Received:" line on the message, with much simpler software, since I don't need to make any of the transformations that Sendmail makes in the headers. If I was at a gateway, and the other network(s) didn't take the RFC822 syntax, then I would probably be interested in Sendmail. (Though I wouldn't change the current transport software for UUCP.) Now let's talk about something new. -- Shyy-Anzr: J. Eric Roskos UUCP: Ofc: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer Home: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642
hokey@plus5.UUCP (Hokey) (11/03/85)
JER, you are certainly correct that this issue has been "discussed" far too much. However, there are some points you (re)state to which I choose to examine. >I can certainly appreciate the arguments against using "@'s" in UUCP >routing strings. I strongly disagree with calling them "hybrid addresses," >however, because they are not addresses, they are routes, and they are >not hybrid, since "@" doesn't mean anything to any but a few modified Unix >sites. Are you saying that there are only a few sites running sendmail? Are you inviting them to identify themselves in order to substantiate their number? >> I say: >> Implementation #1: Permit hybrid routes, and make everybody parse them >> the same way. >> Problems: Doesn't work at gateways. > >It does, too. But we've been over this so many times, algorithms and all, >that I'm tired of reiterating it. Does not! So there. Here is a contrived example: wucs!kurt sends me mail via seismo. Seismo puts the thing into 822 format before sending it to me. I see wucs!kurt@seismo. I reply, and being a good bangist, send it to wucs, which then sends the mail to kurt@seismo. Wrong. I speak with both wucs and seismo. How do I choose? I don't recall *ever* seeing any real-world solution to this problem. This problem has been acknowledged for years (since before you or I got into this mess). One reason so few discuss it is because the Old Timers are even more burned out than we are. >... what's the difference between (assuming >a site that only has Unix mail and no router) writing > > petsd!vax135!ucbvax!sam@slowvax.ARPA >or > petsd!vax135!ucbvax!slowvax.ARPA!sam > >It just involves permuting the last two name tokens, and replacing the last >@ with a !. You are semantically disambiguating the beast. How do you know that ucbvax!sam didn't route the mail via slowvax.ARPA to vax135? The assumption you make says it all. What happens when/if you become a gateway which speaks to Arpa? At that time, you will suddenly be trying to send mail along the route slowvax.arpa->petsd->vax135->ucbvax->sam. >> Extra Protection: Keep the From: line in ! format in UUCP land. This way, >> sites which prepend their name will take b!a and produce c!b!a or b!a@c, >> either of which is "correct". > >I don't like this approach, and I wish we could discuss this, or some other >topic, instead of going over and over the @-precedence issue. Presently the >many strange ways sendmail sites macerate the routing stamps on the fronts >of the messages cause a lot of problems generating replies. If you are >going to argue in favor of RFC822 compliance (which I think you should), >then you shouldn't compromise on these issues. RFC822 compliance is swell if that is what you want. It doesn't really matter. Since RFC822 compliance can't be enforced on arbitrary UUCP sites, we have to have a way to transport mail between sites. The *only* thing I am advocating is the use of strict bang format when shuffling mail between UUCP sites. If you choose to take the mail and make it RFC822 compliant where you are, that's your business. Please make the mail look like ! mail when it leaves your scope of control when passing it to a UUCP neighbor. >> I have it on good authority that sendmail source can be put on any system >> licensed for SysV or 4.2 (or later) BSD. These sources seemed to think >> that there is a 99% chance that sites with 32V, V7, or SysIII licenses >> would also be able to have sendmail. 4.1BSD was not mentioned, but I doubt >> there would be a problem. > >I don't see the point to this. Why would other sites want to install >Sendmail? You raise a very good point. I thought about it, and came up with the following benefits of using sendmail: user aliases (not everybody can afford the 3-4 Mbytes occupied by all the MH software), mail to files, mail to pipes, decent forwarding capabilities, and local "services" (sending mail to the lineprinter, for example). Granted, much of this *could* be done by dedicated, smaller programs. I haven't seen them yet. I have heard rumors about them, but that's all. -- Hokey ..ihnp4!plus5!hokey 314-725-9492
jer@peora.UUCP (J. Eric Roskos) (11/04/85)
> JER, you are certainly correct that this issue has been "discussed" far > too much. However, there are some points you (re)state to which I choose > to examine. Gee, Hokey, if you are going to introduce some new stuff, that's fine. > Are you saying that there are only a few sites running sendmail? Are you > inviting them to identify themselves in order to substantiate their number? Only if you let all the non-sendmail sites do so too... :-) it's a matter of proportion, not numbers. > Does not! So there. Here is a contrived example: wucs!kurt sends me mail > via seismo. Seismo puts the thing into 822 format before sending it to me. > I see wucs!kurt@seismo. I reply, and being a good bangist, send it to wucs, > which then sends the mail to kurt@seismo. Wrong. I speak with both wucs > and seismo. How do I choose? I don't recall *ever* seeing any real-world > solution to this problem. Seismo did it wrong! (Now, don't get mad, Seismo-folks, I didn't say you'd really do it this way...) They should have written kurt@wucs.UUCP. It's the responsibility of the nameservers on the path back to figure out how to get it to wucs. The fact that it came through Seismo coming here is of no interest at all; besides, you can look in the Received: lines if you want to know. The From: line should tell the mailbox name and the system the message came from; that's all you know to reply, and all you need to know. >> petsd!vax135!ucbvax!sam@slowvax.ARPA > You are semantically disambiguating the beast. How do you know that > ucbvax!sam didn't route the mail via slowvax.ARPA to vax135? Because, if it's in the UUCP routing strings, it's not an RFC822 address, and so "!" has precedence. If it's in the From: line of the message, it is an RFC822 address (since it's in the message text, which is what RFC822 is for), and so "@" has precedence. You're right; unambiguous grammars generate syntactically unambiguous languages, and the semantics of the tokens are already unambiguous, so the semantics are unambiguous. {What? Don't like two different languages? What's all this "RCPT TO" stuff I keep reading about here?} > Since RFC822 compliance can't be enforced on arbitrary UUCP sites, we have to > have a way to transport mail between sites. The *only* thing I am advocating > is the use of strict bang format when shuffling mail between UUCP sites. Me too! But here again, standard UUCP mail doesn't know anything about anything in the message text except for "From_" lines. However, the RFC822 does let you rewrite the headers "to force data to conform to a network's local conventions". Thereby "the 'next' network's local idiosyncrasies are imposed on the message". I wish we could stay away from situations, in the UUCP mail network, in which machines have to read the headers on the message text, since we started out with only one (very hard to deal with) such header, and could put on clean addresses without causing any problems. However, I won't argue with you on this; our mailer handles it fine, and I don't have to deal with yours! When it leaves here, actually it has both... the RFC-822 address in the <route-addr>, and the UUCP path that was used in the <phrase>. (Not in the From: line, though. How do I know the path from there to here?) Except when I don't get replies, which is what the mung-resistant (not recognized by Sendmail) headers are for. > user aliases (not everybody can afford the 3-4 Mbytes occupied > by all the MH software), mail to files, mail to pipes, decent > forwarding capabilities, and local "services" (sending mail to > the lineprinter, for example). MH.5 supports all of these. However, you're right, the software is very large; but the program that does all it (post) is probably much smaller than Sendmail. (Actually I don't know if they handle "mail to pipes" or not.) Anyhow, what I am arguing for/about here are not the programs in the roles sendmail and post occupy, but rather the simple transport-level software. Those can be, and are, very small. -- Shyy-Anzr: J. Eric Roskos UUCP: Ofc: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer Home: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642
greg@ncr-sd.UUCP (Greg Noel) (11/06/85)
I don't want to enter this philosophical debate; I think the two sides are both right and wrong, and that the discussion will eventually reveal that they are trying to do the same thing different ways, and that the cross-fertilization of ideas will be mutually beneficial. But I do want to point out one misconception that shows that the issue is more subtle than meets the eye. In article <1761@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: > ..... what's the difference between (assuming >a site that only has Unix mail and no router) writing > > petsd!vax135!ucbvax!sam@slowvax.ARPA >or > petsd!vax135!ucbvax!slowvax.ARPA!sam > >It just involves permuting the last two name tokens, and replacing the last >@ with a !. No, this doesn't work. As a case in point, Peter Honeyman sent me a note last week. I presume that he just used the reverse path of a news item rather than calculating the path, since the message went from his machine (down) to princeton to seismo, then over the ARPAnet to noscvax, then via UUCP to me. If you look at the reverse path at each point, it is: hop 1 -- down!honey hop 2 -- princeton!down!honey hop 3 -- princeton!down!honey@seismo.something.GOV hop 4 -- noscvax!princeton!down!honey@seismo.something.GOV Applying the simple algorithm above, this reverse route becomes noscvax!princeton!down!seismo.something.GOV!honey instead of the correct noscvax!seismo.something.GOV!princeton!down!honey which would reach him, assuming that noscvax would handle this form of address (I don't know if it does). This is yet another case of the confusion between an \address/ and a \route/ and each network's bias toward one over the other. In terms of the discussion before us, what would happen to your first example if vax135 suddenly became an ARPAnet gateway? Then it would have both @ and ! routing available, and it would be able to reach \both/ possible destinations; it would have a hard time deciding what to do with the message. The point is that \you/ would have to change how the mail is sent, based upon a change in status that you can't control and of which you may not even be aware. >However, I wrote the router with the intent that someday it would become >a gateway, since we have machines here that are not on the UUCP network. >If we ever make that conversion, I will have to add the change to rmail >which the person at NCR in Torrey Pines recommended awhile back, whereby >the domain table also specifies the program to run to exit the UUCP network Hmmmmm..... Thank you, I think, although that is not quite what I was recommending -- I wanted the "UUCP network" just to be a special case of a generalized network routing, handled by the same logic as all other networks and invoked in the same manner as all other networks. The thing I was trying to emphasize was that network routing is something that can be done pretty much indepentantly of the details of how the route is physically implemented; in other words, to borrow an expression out of context, that the physical transport layer is a implementation decision that can be factored out of the choice of which link is to be chosen to use for the message. Perhaps when our copy of smail arrives (that's a \hint/, Mark), I will have a chance to actually explore some of those ideas -- it may turn out that the seperation between decision and implementation isn't workable for some reason we don't yet know. I didn't get a chance to proof this for spelling; I hope it isn't \too/ awful. -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
hokey@plus5.UUCP (Hokey) (11/06/85)
Well, you may be in luck. I am going out of town for a week, so I probably won't see your followup! >> Me: >> Are you saying that there are only a few sites running sendmail? Are you >> inviting them to identify themselves in order to substantiate their number? > > JER: >Only if you let all the non-sendmail sites do so too... :-) it's a matter of >proportion, not numbers. Did you mean to put the :-) at the end of the sentence? If not, we should all begin using Chinese because it will "normalize" communications. After all, it is a matter of proportion, not numbers. >> Contrived example: wucs!kurt sends me mail via seismo. Seismo puts the >> thing into 822 format before sending it to me. I see wucs!kurt@seismo. > >Seismo did it wrong! (Now, don't get mad, Seismo-folks, I didn't say you'd >really do it this way...) They should have written kurt@wucs.UUCP. It's >the responsibility of the nameservers on the path back to figure out how >to get it to wucs. The fact that it came through Seismo coming here is of >no interest at all; besides, you can look in the Received: lines if you >want to know. The From: line should tell the mailbox name and the system >the message came from; that's all you know to reply, and all you need to >know. I never said *where* the route/address was! Seismo may have done a perfectly legal thing and put a domain name (seismo) on a localpart (wucs!kurt). This could happen in the To: line, which would be used in a reply. Let's say I have a dumb mailer, but seismo doesn't know it. This is one of the points I have been making which you don't seem to see. Furthermore, If I have a dumb mailer, I *couldn't even reply* to "kurt@wucs.UUCP"! This is another of the points I make which you don't seem to see. The fact that it came through seismo is *very* significant if I have a dumb mailer and I want to send something back without editing headers! >> Since RFC822 compliance can't be enforced on arbitrary UUCP sites, we have to >> have a way to transport mail between sites. The *only* thing I am advocating >> is the use of strict bang format when shuffling mail between UUCP sites. > >Me too! But here again, standard UUCP mail doesn't know anything about >anything in the message text except for "From_" lines. Still wrong! How many times must you be told about the To: line, which is also used by binmail to handle multiple recipients? If this line is a "simple" @ address, dumb mailers can't reply. If it is a hybrid, dumb mailers will mess up the wucs!kurt@seismo example I gave above. My primary goal is to have a reliable, verifyable mail transport system. If we use strict ! format *within UUCP land* we *will not* have the transport problems we have now. Furthermore, it will be *easy* to identify sites which do not conform to this scheme, making it even easier to track down sites which can be potential troublemakers. -- Hokey ..ihnp4!plus5!hokey 314-725-9492
greg@ncr-sd.UUCP (Greg Noel) (11/12/85)
In article <912@plus5.UUCP> hokey@plus5.UUCP (Hokey) writes: > ... (((Replying to JER, he makes the same point I made about > disabiguating ! and @ addresses, then continues with a reply > to another point))) ... >You raise a very good point. I thought about it, and came up with the >following benefits of using sendmail: > user aliases (not everybody can afford the 3-4 Mbytes occupied > by all the MH software), mail to files, mail to pipes, decent > forwarding capabilities, and local "services" (sending mail to > the lineprinter, for example). >Granted, much of this *could* be done by dedicated, smaller programs. I >haven't seen them yet. I have heard rumors about them, but that's all. If you have heard rumors about them, I'd love to hear more. I still think that the domain server is the right place to do this, since it is just a generalization of routing mail. How easy would it be to add this kind of thing to smail? -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-sd.UUCP or Greg@nosc.ARPA
jer@peora.UUCP (J. Eric Roskos) (11/14/85)
[Due to some problems with long text lines in the message I am replying to,
I can't include the article being commented on here. See the references.]
Thank you for commenting on my discussion of routing languages.
After discussing the lack of progress on this subject with an
epistemologist over the weekend, I have come to realize that no more
progress in this discussion can be made simply because, whereas I
recognize the points you are making, you refuse to acknowledge mine, and
thus nothing I can say will change your mind. In particular, you have
simply reiterated once again the old objection to having an "@" in the
path, which is founded in the unwillingness to acknowledge the fine
distinctions I have been trying for months to point out.
Go read some of Aho and Ullman's texts on formal language theory instead,
and think about the relative complexity of different classes of grammars.
Regarding your saying that what I had implemented was not what you wanted,
actually it is exactly what you wanted, but your feeling that it is not is
again founded in this same dilemma. If the UUCP network were a more
sophisticated communications network, it would be readily apparent that
the distinction between the transport-level protocols and the applications
protocols in the user agent was a necessary one; however, the relative
simplicity of UUCP makes it easy in this network to integrate together
some few transport mechanisms. In a more sophisticated network, this
muddying of the layers is not so easy to accomplish, and the confusion
that now exists could not have arisen.
I've said enough on a topic that is only of theoretical interest, so I hope
the above is sufficiently devoid of new material to discourage any further
debate at this time; our concepts of what constitute the "Truth" on this
issue are simply too disjoint to allow any further discussion.
--
Shyy-Anzr: J. Eric Roskos, Ph.D. @ CONCURRENT Computer (A Perkin-Elmer Co.)
UUCP: Ofc: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer
Home: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jerpc!jer
US Mail: MS 795; CONCURRENT Computer Corp. SDC;
2486 Sand Lake Road, Orlando, FL 32809-7642honey@down.FUN (Peter Honeyman) (11/16/85)
greg describes a gruesome case of hybrid address generation; let me fill in the details. i sent mail to nosc!greg, which pathalias turned into princeton!seismo!nosc.arpa!greg. nosc forwards greg's mail to ncr-sd. return addresses were generated as follows: host return address ---- -------------- down honey princeton down!honey seismo princeton!down!honey nosc princeton!down!honey@seismo.css.gov ncr-sd noscvax!princeton!down!honey@seismo.css.gov note that seismo changed syntax; seismo is gatewaying into rfc-land, where local-part@domain is required. (incidentally, i concur with this treatment.) note that nosc \did not/ do it's part when gatewaying back into bang-land, and further confused matters by using different host names for arpa and uucp. while pathparse disambiguates the resulting address with ease, nosc would be a better citizen if it converted princeton!down!honey@seismo.css.gov to seismo.css.gov!princeton!down!honey when gatewaying to bang-land. as to whether smail has the answer, i wouldn't expect much; the smail crowd seems adamant about rejecting existing practices. peter
honey@down.FUN (Peter Honeyman) (11/20/85)
oh god damn it. s/it's/its/. peter