ajs@hpfcla.UUCP (08/13/84)
> During the last month, I have cutting down on the number of replies > I make to authors of articles. The reason: only about half get through... Autorouting tools help a lot. But I don't expect anything with an "@" in it to get through, so I'm not disappointed when it doesn't. My simple-minded (real user) perception of this aspect of e-mail is that "it just don't work too hot".
jad@hpfcla.UUCP (jad) (08/07/85)
> /***** hpfclo:net.mail / nsc!chuqui / 7:03 pm Jul 22, 1985*/ > I'm starting to see problems that look like smart mailers messing up > addresses. I **think** it may have something to do with some of the > assumptions in the gatech sendmail configuration files -- I'm hacking on > them now and some things don't look quite right. Thanks, by the way, for starting a religious debate. ;-) Seriously -- crossing domains is a severe problem. I got mail from John Quarterman in response to a posting. Let me share with you part of the header. My question is "how can I reply to this?" ... pretend I am a beginner. > Date: Tue, 6 Aug 85 11:02:34 cdt > From: ihnp4!purdue!jsq%im4u.UTEXAS@ut-sally.ARPA (John Quarterman) The system I am on does not talk to the ARPAnet, but the mailer I use (MH) gives '@' the highest precedence. In trying to reply I try to send to ut-sally.ARPA. Ugh. The actual return addr. generated by MH looks like this: To: ut-sally.ARPA!ihnp4!purdue!jsq%im4u.UTEXAS (John Quarterman) Could be that MH is damaged, but it should NOT be this tough to figure out how to reply to someone! How was this problem caused? He sent mail to my Purdue account, via the ARPAnet, which forwarded to me, via UUCP. Hence, the ihnp4!purdue tacked on. Mailers should leave the sender's address the hell alone. I would see something like jsq@im4u.UTEXAS.ARPA ... now, my machine does not know im4u (perhaps it came into existance since my database was last generated -- the inherent problem with databases is that they always seem to be out of date). But I do know the ARPA domain (well, OK, this should be the .EDU domain); and I may even know UTEXAS, so I don't go home hungry. When I reply to this mail (consider me a novice), my user-agent constructs the reply address, which (SHOCK!) just happens to be the exact same thing as is in his mail (ie. NO MUNGING EVER!). When I ship off my mail with the address jsq@im4u.UTEXAS.EDU (if I may), my mail delivery agent notices the mail is non-local, and sends it off. Okay, easier said than done. There's a big difference between ut-sally.UTEXAS.EDU in the UUCP network (which it is) and the same ut-sally.UTEXAS.EDU in the ARPA network ... for one thing the UUCP mail will get there a hell of a lot slower and for another the ARPA mail will get there for sure (nearly). Perhaps network information should be encoded in the domain? -- jad -- John A. Dilley, FSD Fort Collins, CO ARPA: terrapin@Purdue.EDU UUCP: {ihnp4}! hpfcla!jad PHONE: (303)226-3800 x4166
rs@mirror.UUCP (08/26/85)
The following shar file contains two programs. The first is a /bin/sh
script that reads an official DoD Internet table (in colon-syntax),
and writes a pathalias-suitable list of all ARPA hosts. The official
name, as well as the nicknames, are listed. (There might be a problem
if a host has no nicknames, but the current hosttable (274, 8/21/85)
has no such hosts.) The filter also ignores all the single-user
machines it can find: I DON'T want somebody's office SUN in my tables!
The second is a small word-wrapper for those people who don't have
fmt.
Enjoy!
------------------------------cut here------------------------
# This is a shell archive. Remove anything before this line,
# then unpack it by saving it in a file and typing "sh file".
#
# Wrapped by mirror!rs on Mon Aug 26 11:33:30 EDT 1985
# Contents: filter ww.c
echo x - filter
sed 's/^XX//' > "filter" <<'@//E*O*F filter//'
XX#! /bin/sh
XX# A small script to read an offficial internet hosts file, and
XX# put it into something that can be used with pathalias.
XX#
XX# The process is:
XX# 1. Get all (not commented-out) host entries that aren't
XX# single-user machines (an arbitrary list, I admit).
XX# 2. Transliterate, strip off ARPA domain, and punt any
XX# other domains.
XX# 3. Sort, deleting multiple occurrences.
XXT=/tmp/hosts$$
XXtrap 'exec rm -f $T Arpa.pathalias' 1 2 3 15
XXecho 'ARPA = {' >Arpa.pathalias
XX grep -v '^;' hosts.txt |\
XX fgrep 'HOST' |\
XX awk -F: '\
XX$4 !~ /.*(ALTO|IMSAI|PC|SUN|SYMBOLICS|TRS).*/ {
XX i = split($3, names, ",")
XX for (j = 1; j <= i; j++)
XX print names[j]
XX}' |\
XX tr 'A-Z' 'a-z ' |\
XX sed -e 's/\.arpa//' -e '/.*\./d' -e 's/$/,/' |
XX tr -d ' \010' |\
XX sort -u |\
XX fmt >>Arpa.pathalias
XXrm -f $T
XXexec echo ' VOID }' >>Arpa.pathalias
@//E*O*F filter//
chmod u=rwx,g=r,o=r filter
echo x - ww.c
sed 's/^XX//' > "ww.c" <<'@//E*O*F ww.c//'
XX/*
XX** WW
XX**
XX** Copy stdin to stdout, doing word-wrap so that no lines are longer
XX** than a proscribed width. It doesn't expand tabs, but if you put
XX** tabs in wrapped text, you deserve what you get! It also seems to
XX** mess up sometimes.
XX**
XX** Written August 26, 1985 by Rich $alz at Mirror Systems (mirror!rs).
XX*/
XX#include <stdio.h>
XX#define WIDTH 80
XXextern char *gets();
XXchar Ibuff[256];
XXchar Obuff[WIDTH + 1];
XXmain()
XX{
XX register char *I;
XX register char *O;
XX register char *Ispace;
XX register char *Ospace;
XX register int C;
XX for (C = 0, O = Ospace = Obuff; I = fgets(Ibuff, sizeof Ibuff, stdin); )
XX {
XX if (*I == '\0')
XX {
XX *O = 0;
XX (void)puts(Obuff);
XX (void)putchar('\n');
XX C = 0;
XX O = Obuff;
XX continue;
XX }
XX for (I[strlen(I) - 1] = ' ', Ispace = I; *I; )
XX {
XX while (C < WIDTH && *I)
XX {
XX *O++ = *I++;
XX C++;
XX if (*I == ' ')
XX {
XX Ospace = O;
XX Ispace = I;
XX }
XX }
XX if (C >= WIDTH)
XX {
XX if (Ospace == Obuff && *Obuff != ' ')
XX Obuff[WIDTH] = '\0';
XX else
XX {
XX *Ospace = '\0';
XX if (*I)
XX I = Ispace;
XX }
XX (void)puts(Obuff);
XX C = 0;
XX O = Ospace = Obuff;
XX }
XX }
XX }
XX *O = '\0';
XX (void)puts(Obuff);
XX exit(0);
XX}
@//E*O*F ww.c//
chmod u=rw,g=rw,o=rw ww.c
exit 0
--
Rich $alz {mit-eddie, ihnp4!inmet, wjh12, cca, datacube} !mirror!rs
Mirror Systems 2067 Massachusetts Ave.
617-661-0777 Cambridge, MA, 02140tp@ndm20 (09/16/85)
>Instead of just going over and over this, why don't you explain the >algorithm you recommend for guessing the next site to choose? That would >help in furthering the discussion. And while you are doing it, remember that idealism is nice, but to really get the mail through in the real world, you had better not assume that any machine along the way has a mailer that can send to a non-adjacent site unless you have certain knowledge. If I were host1 in your example your mail would be returned to you as undeliverable. I have pathalias, but I don't have an intelligent mailer that can be told to look things up in it, since I am not running 4BSD. And if you hand me user@host, my mailer will be real unhappy, because it doesn't like @'s. Terry Poot Nathan D. Maier Consulting Engineers (214)739-4741 Usenet: ...!{allegra|ihnp4}!convex!smu!ndm20!tp CSNET: ndm20!tp@smu ARPA: ndm20!tp%smu@csnet-relay.ARPA
tp@ndm20 (09/16/85)
(A consensus has been reached? Could someone mail me a summary of
the consensus. I must have missed it.) (No smiley face, that is a
serious request.)
The map data will have to change completely before any of this stuff
will work. All the names will have to have their domains attached.
I would suggest still making the full map available, as good routes
have nothing to do with domains. Besides, if you channel all the
mail for, say, northern california through one site, you may have a
lot of trouble finding a volunteer to be that site.
Domain names should have nothing to do with routes. All they really
solve is the name-space collision problem. Trying to use them for
routing will be a disaster, as all the mail will bottle-neck at
certain systems, who will probably not be happy about it. The other
benefit of domains is that if the mail can't be delivered along the
path it was sent, you can try sending it along the domain tree, as
those sites should have up to date routing information.
Since I started I might as well present my (lowly peon) suggestion
(on mechanics only, not policy). I suggest that all mail should have
RFC-822 headers with *just* the address (as opposed to any gateway
routing garbage) in the To: line. As the RFC tells us, this is the
envelope, not part of the message, as someone has suggested. The
mailer would take this and look up the route with pathalias and send
it along. Note that the address and the route are unrelated, as they
are supposed to be. If a gateway is required, or the database does
not have the name in it, it should be sent to the gateway or
name-server with out a destination address on the transport line
(i.e. the gateway system would get an rmail command from its
neighbor without an address. This would be something of the form
rmail host1!host2!host3! somewhere down the line). This system,
being a name-server or gateway, must of course have an equally
sophisticated mailer. It would then look at the RFC-822 To: line,
and take whatever steps neccessary to deliver the mail. In the case
of a gate-way, it would send it out on the appropriate net. In the
case of a name-server, it would generate a proper route and mail it.
No return routes need to be maintained in either case because any
system that re-routes a message can presumably generate a return
route through the pathalias database. Remember this is assuming
domain addressing, so that host names are unique.
This is compatible with existing software. Standard UUCP address
still work. Using a gateway manually (i.e. without up-to-date
software) actually becomes easier: Just put an RFC-822 compliant To:
line in your message and mail it to a gateway. No precedence to
worry about, no syntax to learn. Systems with dumb mailers can just
get in the habit of mailing it to a smart neighbor for delivery.
(Under this scheme, any site with the appropriate mailer and
pathalias database can be considered a name server, thus distributing
the load more evenly net-wide).
Of course the map data needs to change, as I said. Also pathalias
needs to know about domains. This can probably handled more by
changing the map data than the program. I think the program will
already do it, by entering each domain as a subnetwork, and making
the hosts with smart mailers gateways. Since a subnetwork is a
psuedo host, you can nest them easily. I am no expert on pathalias,
so I could be wrong about this.
I would leave it to the mailer to access the database with
successively more general names, rather than making pathalias do it.
For example, when handed user@x.y.z, the mailer should ask for a
route to x.y.z. If such a host exists in the database, the mailer
should generate a full route (i.e. host1!...!hostn!x.y.z!user). If
such a host is not in the database, the mailer should ask for a route
to y.z and then z. If a route for y.z is known, the mailer would
generate host1!...!hostn!y.z! indicating to that machine that it
needs to generate a route for the message. If no route to any higher
domain can be found, the mailer should bump the message to the
nameserver for his domain. By this passing of the buck the mail will
get through as long as the top level domains all know about each
other. For example, if I mail from tp@a.b.c to user@x.y.z, and my
machine knows nothing of x.y.z, y.z, or z, I should send it to b.c.
If that machine can't deliver it, it should be sent to c. If that
machine can't deliver it, it can't be delivered.
This scheme gets the mail to gateways automatically. (There is
really no difference between a name-server and a gateway insofar as
the software should be concerned. They are both systems that can
forward mail that can not be directly delivered.)
I have used the names of domains as host names intentionally. My
intent is that when sending to y.z, for instance, the mailer would
consult pathalias for a route to that pseudo-system (sub-network),
and the mail would actually go to one of the gateways for that domain
(i.e. someone with a smart mailer who can act as a name-server for
the domain.) This results in the mail getting to the domain and a
name-server request happens automatically, which is exactly the
desired result in such a situation.
This is a general mechanism and not tied to any particular
arrangement of domains or any political decisions on how it should be
done or who is in charge. Those are political decisions, and while I
do have opinions on them, they are not represented in the above
discussion.
Thanks,
Terry Poot
Nathan D. Maier Consulting Engineers
(214)739-4741
Usenet: ...!{allegra|ihnp4}!convex!smu!ndm20!tp
CSNET: ndm20!tp@smu
ARPA: ndm20!tp%smu@csnet-relay.ARPAtp@ndm20 (09/16/85)
NOT EVERYONE RUNS 4BSD ON A VAX!!!
Everyone proposing standard ways of doing things please repeat this
to yourself until you understands what it means! Every proposal that
has been made so far about the proper way to address and route mail
will require me to retire my mailer and run (and probably port
myself) something from elsewhere, and you people are talking about
changing the whole damn thing because of a bug in ONE version of
unix! Is none of this stuff worth doing if you have to edit a
configuration file? Talk about laziness! Do you people not realize
that there are people out here who don't even have sendmail, and
could care less if your mailer has a bug, and are not very
sympathetic about it? Of course whatever Mark Horton puts in the map
data will stick, but for chrissakes, think about it first!
Terry Poot
Nathan D. Maier Consulting Engineers
(214)739-4741
Usenet: ...!{allegra|ihnp4}!convex!smu!ndm20!tp
CSNET: ndm20!tp@smu
ARPA: ndm20!tp%smu@csnet-relay.ARPA
Sorry for the flames. Please accept my apologies for the tone of
the message and consider the content only. The point is valid.avolio@decuac.UUCP (Frederick M. Avolio) (09/28/85)
In article <3700008@ndm20>, tp@ndm20 writes: > Everyone proposing standard ways of doing things please repeat this > to yourself until you understands what it means! Every proposal that > has been made so far about the proper way to address and route mail > will require me to retire my mailer and run (and probably port > myself) something from elsewhere, and you people are talking about > changing the whole damn thing because of a bug in ONE version of > unix! I understand Terry's frustration. I would be too if it looked like with some wonderful "fix" that other's implement I'd be cut off from electronic mail. But no one will be or need be forced to change software. There are different levels of sophistication in mailers and all will be accommodated. For example, if your mailer can only handle explicite paths, then you juts use the explicite path if you have it -- nothing changes. Terry might see this address in the From_ line if I sent him mail smu!texsun!ut-sally!seismo!decuac.ATL.UUCP!avolio So your mailer can handle that. Just send it on to smu ... So nothing need change -- especially if it cannot -- at your site. Fred.