jmwobus@cmx.npac.syr.edu (John Wobus) (10/12/89)
Re the new Host requirements RFCs. The good news: we now know what an Internet host is. The bad news: there is no Internet host in the world! The shocking news: of the two vendors I heard speak on the subject at Interop, neither plans to fully comply! I'm happy that the RFCs are completed and I appreciate the work involved. However, I'm sure a lot of us users were hoping for something we could refer to in procurement specifications. Besides requiring some less-than-generally-useful features like source routing, it avoids the issue of implementations not meant to include all the applications mentioned, i.e., a single-user system which wisely makes no effort to offer SMTP service. We will be happier if either vendors change their attitudes or if another paper (RFC?) is developed to fill the gap--I can imagine a paper describing everything a host ought to do if it can claim to offer "TELNET" service, if it can claim to offer "FTP" service, etc. Perhaps it could also address the different protocols below IP too. Once again, the Host Requirement RFCs represent signficant work in the right direction. It is just that they might not turn out to be QUITE as useful as I had hoped. John Wobus Syracuse University
randall@uvaarpa.virginia.edu (Randall Atkinson) (10/12/89)
In article <1949@cmx.npac.syr.edu> jmwobus@cmx.npac.syr.edu (John Wobus) writes: > However, I'm sure a lot of us users were hoping for >something we could refer to in procurement specifications. The new host requirement RFCs are "something we can refer to in procurement specifications" and I think a lot of vendors will be seeing them referred to in that fashion in the future. >Besides requiring some less-than-generally-useful features like source >routing, it avoids the issue of implementations not meant to include >all the applications mentioned, i.e., a single-user system which >wisely makes no effort to offer SMTP service. I strongly disagree with the notion that RFC-822 source routing is "not generally useful." The mail systems I manage for GE all fully support source routing as specified in RFC-822 and I put use them in some outgoing mail (e.g. in mail to DECnet gateways that are less than correctly defined { not GE mind you, our DECnet nodes can all be reached as "userid@decnet-node-name.DNET.GE.COM" and don't need the "% hack" of any other non-standard syntax. } ). My systems do not support the "% hack" popularised by BSD sendmail and will not as long as I manage their mail systems. The "% hack" is ugly, difficult to parse correctly at Internet--othernet gateways, and not needed. If your system doesn't support source routing, it is broken and has been at least since RFC-822 came out. A single-user, multitasking system should be able to handle SMTP. IF your single-user system is single-tasking, I'd suggest that it will never be much more than a very bright terminal to the rest of the Internet. Watering down an RFC to account for DOS machines or the like strikes me as inappropriate. >We will be happier if either vendors change their attitudes or if >another paper (RFC?) is developed to fill the gap--I can imagine >a paper describing everything a host ought to do if it can claim >to offer "TELNET" service, if it can claim to offer "FTP" service, >etc. Perhaps it could also address the different protocols below >IP too. I predict that vendors will be moving strongly in towards supporting the host requirements RFC precisely because I expect sites to cite those RFCs in procurement requests. (See Above).
craig@NNSC.NSF.NET (Craig Partridge) (10/12/89)
John:
I think the picture is much better than you present. Many users have
already expressed plans to put use the HR in their specifications.
Furthermore, the HR was sensitive to the needs of single-user systems.
As James Van Bokkelen stated at Interop, he thinks the MUSTs
in the HR are consistent with doing a DOS implementation. (Except he
didn't like IP source-routing -- and then he confessed to recently
encountering a situation where he wished he had source-route support
in his IP. I think James will concede he was biting his tail there...:-)
My impression is that one of the vendors' biggest concerns is that
HR will require some effort to make existing, "working" code conform,
while at the same time, trying to enhance their products to keep up with
a changing world. For most products which have tried earnestly
to track the TCP/IP protocol suite, these changes should not be very
extensive, but the concern is valid. And to address this concern, the
IETF is planning to try to enforce a "quiet time" over the next 9 months
to a year during which we will not make new standards that affect hosts.
In other words, we'll try to make the protocol suite a fixed target for
the next year, so vendors have a chance to catch their breath and make
their implementations HR conformant.
Craig Partridge
IETF Area Director - Host and User Serviceslazear@GATEWAY.MITRE.ORG (10/12/89)
It seems quite appropriate for someone who wants the help and definition that the RFC provides, but who only needs a portion of the functionality, to specify the parts of the RFC that are "optional" for his/her procurement. Thus, if you don't want your DOS "super-terminal" to do SMTP, make it an optional part of the specs you put in your RFP. The downside is that *you* have to decide what will affect your interoperability, not some committee from a larger community of interest. Cutting out the "wrong" part of the RFC may cut off your options later, but that's part of being an informed consumer (i.e., buying what you asked for, not just what you meant to ask for). Walt (Lazear@gateway.mitre.org)
jbvb@VAX.FTP.COM (James Van Bokkelen) (10/13/89)
It wasn't so much that I didn't like IP Source-Routing; we do it in our PING
as a (useful) debugging tool. The point I was trying to make was that there
were two IP options I felt were useful in day-to-day applications (Telnet,
FTP, etc.): Source Routing and IP Security. Of the two, IP Security is
relatively easy (and small) to code (on a DOS PC). In contrast, IP Source
Routing (loose or strict) is harder to code, hard to do a user interface
for ("telnet foo.bar.com via baz.lusing.net, bar.winning.net", maybe?),
and tremendously hard to explain to the average user:
"Well, first you find out who is black-holing you with traceroute,
and then you play around trying to find a gateway somewhere off to
one side which can actually reach the place you want to go, and then
you name that gateway in a loose source route..."
I still don't intend to hurry on Source Routing for the applications; the
amount of playing around it took me that day to find a gateway (me not being
a routing hacker) that knew where I wanted to go is not something I want
to inflict on my support people right now. Maybe if the DNS is extended to
provide some way of querying for gateways by geographic region or the
like, but I don't know of anyone working on that.
James B. VanBokkelen 26 Princess St., Wakefield, MA 01880
FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901almquist@JESSICA.STANFORD.EDU (10/13/89)
John, > [RFC1122/RFC1123] avoids the issue of implementations not meant to > include all the applications mentioned, i.e., a single-user system which > wisely makes no effort to offer SMTP service... I can imagine a paper > describing everything a host ought to do if it can claim to offer > "TELNET" service, if it can claim to offer "FTP" service, etc. As one of the authors of the Host Requirements RFCs, I don't think that there was ever any intention that a host would be non-compliant simply because it didn't choose to support certain applications. In my opinion, a host which doesn't support email is compliant with the SMTP requirements of RFC1122. However, if the vendor claims a compliant implementation of SMTP, you can expect that he will meet the requirements put forth in the SMTP chapter (and also the chapters describing protocols needed to support SMTP, such as TCP, DNS, ...). > Perhaps it could also address the different protocols below IP too. The Host Requirements RFCs defer to the Gateway Requirements RFC for layers below IP (since these are the same for hosts and gateways). Philip
rick@UUNET.UU.NET (Rick Adams) (10/15/89)
and will not as long as I manage their mail systems. The "% hack" is ugly, difficult to parse correctly at Internet--othernet gateways, and not needed. Funny, thats exactly how I (and lots of others) have been describing the rfc822 source routing. I assure you that the rfc822 source routing is MUCH more difficult to parse that the % hack.
henry@utzoo.uucp (Henry Spencer) (10/17/89)
In article <8910141823.AA20101@uunet.uu.net> rick@UUNET.UU.NET (Rick Adams) writes: > ... The "% hack" > is ugly, difficult to parse correctly at Internet--othernet gateways, > and not needed. > >Funny, thats exactly how I (and lots of others) have been describing >the rfc822 source routing. I assure you that the rfc822 source routing >is MUCH more difficult to parse that the % hack. Also, if I am not mistaken -- I am behind on my RFC reading, and could be wrong about this -- the host-requirements RFCs say source routes may contain only Internet-registered domains. That is, you *need* the % hack to do *real* internetworking (talking to other networks). -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
lear@NET.BIO.NET (Eliot Lear) (10/17/89)
I think you have it backwards. Source routing MUST NOT be specified in an RCPT command. MUAs MAY circumvent source routing but MUST NOT produce a 5xx error on receipt of a route addr (cf. RFC 1123 section 5.2.6). The only way that compliant implementations must change is that they may not send route addrs. The goal here is to phase out source routing. The belief was that we should simply not go from a MUST to a MUST NOT state on its handling, or we'd have mail bouncing all over the place. -- Eliot Lear [lear@net.bio.net]
jmwobus@cmx.npac.syr.edu (John Wobus) (10/20/89)
In article <8910122223.AA06605@jessica.Stanford.EDU> almquist@JESSICA.STANFORD.EDU writes: > As one of the authors of the Host Requirements RFCs, I don't >think that there was ever any intention that a host would be >non-compliant simply because it didn't choose to support certain >applications. In my opinion, a host which doesn't support email is >compliant with the SMTP requirements of RFC1122. However, if the vendor >claims a compliant implementation of SMTP, you can expect that he will >meet the requirements put forth in the SMTP chapter (and also the >chapters describing protocols needed to support SMTP, such as TCP, DNS, >...). >> Perhaps it could also address the different protocols below IP too. > The Host Requirements RFCs defer to the Gateway Requirements RFC >for layers below IP (since these are the same for hosts and gateways). > Philip Thanks. That is how I should have said it. I have two other comments on other follow-ups to my original comment: (1) When I referred to source routing, I meant IP source routing rather than mail source routing. However, I don't mind hearing discussion of mail source routing. (2) I have been reassurred to hear some of the authors remind us that vendors will comply. However, I remain uncomfortable that my original comment hasn't brought forth even ONE protestation from any vendor, either on the list or private. Nor did I hear even one vendor promise more than an "attempt" at Interop. John Wobus Syracuse University P.S. The more I look at RFCs 1122 and 1123, the more impressed I am.
barns@GATEWAY.MITRE.ORG (10/21/89)
The HR RFCs don't seem to explicitly state that source routes are limited to Internet-registered domains, but that was certainly the idea in mind. The possibility of allowing non-Internet-registered names was brought up and discussed quite a bit during the lengthy discussion of mail source routing in the HRWG. The mail source route discussion probably constituted 10 or 15% of the total verbiage burning up the wires during that effort. I have a file containing most if not all of the relevant messages which I hereby offer (not without misgivings) to mail to anyone who wishes to read about 280KB on the subject. I might edit it down a bit first if I have some free time - not to remove the content on this subject, but to strip out other topics from multi-topic messages. A big part of the justification (or excuse, depending on your religion) for sticking with Internet-registered names was a feeling that most of the uses of the %-hack could be replaced by an appropriate usage of MX records, including perhaps some strategically chosen wildcard MX's. This theory holds that even if you're not on the Internet, you can register yourself and get your name into some server with an MX pointing to the appropriate gateway(s) for mail to your non-Internet network. According to this reasoning, you don't actually need the % hack for what (I think) Henry Spencer is talking about. Perhaps there are objections to this. Some people seem to object in principle to universal registries; this leads back to the Absolute vs. Relative issue, which is even older than TCP/IP. RFC 733 defined a sort of source route syntax using multiple @ characters; when some people started using it, there were loud screams and (so I am told, I wasn't working in the mail arena at the time so I can't speak from direct knowledge) a meeting was called by or at DARPA at which it was outlawed. This was probably about 8 to 10 years ago - I've forgotten. Anyhow, there is religion involved here, I think. A different objection might be that it is difficult in practice, for one reason or another, for the off-Internet people to get registered with appropriate MX's. I haven't heard this specific complaint, but if it is a problem in practice, maybe the people hurt by it should speak up, and perhaps something can be worked out eventually to improve matters. Bill Barns / MITRE-Washington / barns@gateway.mitre.org
RAF@CU.NIH.GOV ("Roger Fajman") (10/23/89)
> A different objection might be that it is difficult in practice, for > one reason or another, for the off-Internet people to get registered > with appropriate MX's. I haven't heard this specific complaint, but if > it is a problem in practice, maybe the people hurt by it should speak > up, and perhaps something can be worked out eventually to improve matters. Much of BITNET does not support domain addressing (and therefore cannot register with MXs) and is not likely to in the near future. Many people, including me, would like to see it happen. Unfortunately there are quite significant problems to be overcome and few resources to overcome them. Defacto standards on BITNET support domain addressing for mail, but there's no standard protocols for domain addresses with file transfer and interactive messages. Why not, you may say, just do away with BITNET? Well, BITNET, EARN, and NETNORTH go to a lot of places that the Internet does not. It's easier and cheaper for some machines (mainly, but not entirely, IBM mainframes) to connect to BITNET. And BITNET has services, primarily the sender-initiated file transfer and interactive messages, that aren't available on the Internet. LISTSERV makes use of these functions to offer services that would be difficult to duplicate on the Internet. The point is that BITNET and related networks, while not without their problems, provide a number of useful services that the Internet currently does not. That's not to say that the Internet could not provide those functions, but little interest has been shown so far in doing so. So, for the time being, we'll stay connected to BITNET and continue to work on getting our Internet connection to work better so that our users can make use of what each network does best. Perhaps the recent merger of BITNET and CSNET will help the networks to move closer together. Roger Fajman RAF@CU.NIH.GOV (Internet) RAF@NIHCU (BITNET)
henry@utzoo.uucp (Henry Spencer) (10/24/89)
In article <8910201839.AA29376@arcturus.mitre.org> barns@GATEWAY.MITRE.ORG writes: >This theory holds that even if you're not on the Internet, you can >register yourself and get your name into some server with an MX pointing >to the appropriate gateway(s) for mail to your non-Internet network. >According to this reasoning, you don't actually need the % hack... The problem with this theory is that it doesn't really address the issue of *inter*networking at all. What it says is "join our network, then there's no problem". Defining the problem out of existence is not the same as solving it. At any time in the foreseeable future, there *will* be unregistered sites that one wants to get mail to. So the people in charge of moving mail will continue to do what they've always done: move the mail, and ignore inconvenient RFCs that try to legislate a perfect world. The % hack, or something similar, remains necessary. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
cliff@violet.berkeley.edu (Cliff Frost) (10/24/89)
In article <8910231055.AA04607@alw.nih.gov> RAF@CU.NIH.GOV ("Roger Fajman") writes: >> it is a problem in practice, maybe the people hurt by it should speak >> up, and perhaps something can be worked out eventually to improve matters. > >Much of BITNET does not support domain addressing (and therefore cannot >register with MXs) and is not likely to in the near future. Many Actually, any BITNET domain can register with the NIC and MX record support will be supplied by UC Berkeley and Harvard U. There are currently 43 domains taking advantage of this--this is available for BITNET and related nets; eg Singapore (*.SG), Taiwan (*.TW), etc. As Rick Adams pointed out, though, it is far easier to deal with the %-hack syntax. Consider the problem faced by a mail relay into the Internet (eg relay.x.edu): It gets mail destined for an Internet host, from node "JOE" on the non-internet side. It can no longer just say it comes from user%JOE@relay.x.edu, nor can it even say [@relay.x.edu:user@joe]. In order to be "correct" it now has to figure out what is the Internet name of node "JOE", in order to construct a return address like [@relay.x.edu:user@joe.foo.gov]. (I think I messed up the source route syntax, but I hope the idea is clear.) So, by requiring all names to be valid, registered names, you require all mail relays to keep reverse MX tables for all their non-internet nodes. That might be a tremendous amount of extra work. Cliff Frost Central Computing Services UC Berkeley
karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) (10/24/89)
I have to disagree, Henry. If the problem is reaching unregistered sites, the solution is to register them - somewhere - I'm not sure I care where. NIC-registered domains are fine, comp.mail.maps UUCP registration is nearly as fine in a practical sense; other registries exist, but those are the two I deal with most. This is not a "join our network" coercion technique, either. CompuServe has not "joined" the Internet by any stretch of the imagination. But they are registered (in both registries; I registered compuserve.com before I even told CServe what I was building), and mail gets there as seamlessly as it gets anywhere else. I considered the RFCs not to be inconvenient, but to provide the standard against which to implement. Since the first time that email has been able to get between CServe and The Greater Out Here, no % hack (or other ill-advised routing nonsense) has ever been necessary. Getting registered is easy. Building a gateway is easy. They're both too easy to go to the effort of avoiding the issue with things like % hacks. --Karl
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (10/25/89)
In article <KARL.89Oct24124105@cheops.cis.ohio-state.edu> karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) writes: >no % >hack (or other ill-advised routing nonsense) has ever been necessary. > >Getting registered is easy. Building a gateway is easy. They're both >too easy to go to the effort of avoiding the issue with things like % >hacks. As one of the originators of the % hack, I'd like to point out that the % hack predated the ability to get registered. The % hack may be ill-advised today, but in its time it was a clean way around a nasty problem. Mark Crispin / 6158 Lariat Loop NE / Bainbridge Island, WA 98110-2020 mrc@CAC.Washington.EDU / MRC@WSMR-SIMTEL20.Army.Mil / (206) 842-2385 Atheist & Proud / 450cc Rebel pilot -- a step up from 250cc's!!! tabesaserarenakerebanaranakattarashii...kisha no kisha ga kisha de kisha-shita sumomo mo momo, momo mo momo, momo ni mo iroiro aru uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iru
RAF@CU.NIH.GOV ("Roger Fajman") (10/25/89)
> >> it is a problem in practice, maybe the people hurt by it should speak > >> up, and perhaps something can be worked out eventually to improve matters. > > > >Much of BITNET does not support domain addressing (and therefore cannot > >register with MXs) and is not likely to in the near future. Many > > Actually, any BITNET domain can register with the NIC and MX record > support will be supplied by UC Berkeley and Harvard U. There are > currently 43 domains taking advantage of this--this is available for > BITNET and related nets; eg Singapore (*.SG), Taiwan (*.TW), etc. 43 isn't very many. Yes, of course that's true. But you have to have the software on your machine to support domains. Many BITNET sites don't have it. In some cases it exists, but the site does not use it for one reason or another. In other cases it just doesn't exist. Domains on BITNET are supported only for mail, so it's not currently feasible to convert over completely to domain naming. BITNET protocols for domain naming for file transfer and interactive messages have yet to be standardized. Even if BITNET converted over completely to domain naming, the difference between BITNET and the Internet would not be transparent to the user. The two networks use very different methods for transfering files. Interactive messages are not widely implemented on the Internet. Remote logon is not possible on BITNET. I wish the Internet had BITNET-style sender-initiated file transfer that did not require the sender to know the receiver's password. It's very convenient. Sending files as email is not very user friendly. UUENCODEing binary files in email is a horrible thing to have to do. Does X.400 have the capability for attaching arbitrary files to an email message, as many PC-based email systems do? That would satisfy the need.
RAF@CU.NIH.GOV ("Roger Fajman") (10/26/89)
> This is not a "join our network" coercion technique, either. > CompuServe has not "joined" the Internet by any stretch of the > imagination. But they are registered (in both registries; I > registered compuserve.com before I even told CServe what I was > building), and mail gets there as seamlessly as it gets anywhere else. > I considered the RFCs not to be inconvenient, but to provide the > standard against which to implement. Since the first time that email > has been able to get between CServe and The Greater Out Here, no % > hack (or other ill-advised routing nonsense) has ever been necessary. > > Getting registered is easy. Building a gateway is easy. They're both > too easy to go to the effort of avoiding the issue with things like % > hacks. But CompuServe is essentially a single host (as it appears to the outside world, anyway). When you have a network of many non-Internet hosts operated by independent organizations the problem becomes much more difficult. One can either adopt domain naming on the non-Internet network (as the UUCP network did, I believe) or build some sort of translation between the two name spaces into the gateway. Neither one is necessarily very easy to do. In the latter case, the biggest problem is getting all the organiztions registered and collecting the information to do the translation. And when you are done, users still have to be aware of two forms of addresses. If I'm on XYZ net (which does not use domains) and I want to tell my friend on the Internet how to mail to me, I will still have know the name of my host on the Internet. P.S. - If it's all so easy, how come the From address in the message that I am replying to had an ! in the local part?
wicinski@zamna.sgi.com (10/27/89)
In article <KARL.89Oct24124105@cheops.cis.ohio-state.edu> you write: >I have to disagree, Henry. If the problem is reaching unregistered >sites, the solution is to register them - somewhere - I'm not sure I >care where. NIC-registered domains are fine, comp.mail.maps UUCP >registration is nearly as fine in a practical sense; other registries >exist, but those are the two I deal with most. Sorry dude, but i have to disagree. To say "register your domain" is easier said than done. As someone who has registered his own .COM domain, (not sgi.com) after growing tired of .US domains, it is NOT trivial. If you're not connected to the Internet, you dig up a uucp connection (no problem), then you fill out all the NIC forms and try to comprehend the catch-22 (do you need a network #, well you need a domain. you need a domain? you have someone to sponsor you? etc, ad nauseum). THEN you have to go around and grovel at people who have MX nameservers to see if they will put in records for you (luckily i found two people who did), and then MAYBE if the net dieziens decide you are "okay", they give you a domain. Sure, you could pay uunet 35 bucks for almost the same thing, but their forms are just the NIC forms redone, and they stay make you look for the nameservers yourself. >Getting registered is easy. Building a gateway is easy. They're both >too easy to go to the effort of avoiding the issue with things like % >hacks. Becoming registered is NOT easy. Getting connected is not a simple task either. If you really want people to "join your network" there should be a place where the rules are laid out CLEARLY (the nic is helpful in general, but not that awesome), and perhaps there could be a place where people can go look at past registrations to get an idea (that's the main bitch), AND if there was some place joe geek who wants to register his pc with a .COM domain can go look for a list of people who will be willing put an alias in his/her nameserver for them, THEN MAYBE it might become easier to join, and then we can do away with the damn % hack. tim
rick@uunet.UU.NET (Rick Adams) (10/27/89)
In article <8910252236.AA14405@alw.nih.gov>, RAF@CU.NIH.GOV ("Roger Fajman") writes: > P.S. - If it's all so easy, how come the From address in the message > that I am replying to had an ! in the local part? Why do you care whats in the LOCAL part? It's none of your business.
rick@uunet.UU.NET (Rick Adams) (10/27/89)
In article <1136@odin.SGI.COM>, wicinski@zamna.sgi.com writes: > give you a domain. Sure, you could pay uunet 35 bucks for almost the > same thing, but their forms are just the NIC forms redone, and they > stay make you look for the nameservers yourself. No. The $35 is to pay for the hassle involved with reading and correcting the forms (30% arrive with errors in them) and for RUNNING THE NAMESERVERS. Frankly the $35 one time fee doesn't cover the time and effort involved. What we do make you do is find your own FORWARDER (not too hard) or get the PERMISSION of a site directly connected to uunet to allow your mail to be forwarded through them (not an unreasonable position). uunet provides over 400 nameservers of the type you describe. It IS easy. ---rick
karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) (10/27/89)
raf@cu.nih.gov writes:
But CompuServe is essentially a single host
No, it most emphatically is not. There are numerous subdomains of
compuserve.com. E.g.,
csi.compuserve.com CompuServe, Incorporated (employees)
doi.compuserve.com US Department of the Interior
ncr.compuserve.com NCR is a CompuServe business services customer
and if there weren't blocks in place on both sides of the gateway,
these would work:
fax.compuserve.com email => FAX
mci.compuserve.com (oh, just imagine what MCI would have
thought of that...:-)
CompuServe has hundreds (thousands?) of business services customers,
plus connections to (what I understand is) quite a variety of external
gateways. They are all addressable.
Internally, an address somebody@csi.compuserve.com translates to
something twisted like ">csi:somebody." There are 3rd-level
subdomains of doi.compuserve.com as well (e.g., fws.doi.compuserve.com,
mms.doi.compuserve.com); I don't even know how those addresses map
internally.
When you have a network of many non-Internet
hosts operated by independent organizations the problem becomes much
more difficult.
I operate nameserver and mailer arrangements in varying levels of
peculiarity for something like 20 organizations, not including
anything at Ohio State proper. That's the sort of thing I do in my
spare time, for fun. Anyone with a serious, job-dedicated need to do
such things could manage an order of magnitude more than that with
little change in complexity.
One can either adopt domain naming on the non-Internet
network (as the UUCP network did, I believe) or build some sort of
translation between the two name spaces into the gateway. Neither one
is necessarily very easy to do.
If it isn't trivial to do, then the organization's internal mailer
arrangement is in a serious state of disrepair, and deserves to be
overhauled anyway. CompuServe's internal arrangement appears to me to
be internally consistent, so the mapping is truly trivial. There was
no internal overhaul in their case. In fact, the original,
proof-of-concept alpha test gateway didn't affect any software on the
CompuServe side at all. CompuServe literally didn't know what I'd
built until I told them (by writing mail to relevant people through
the gateway, of course :-).
In the latter case, the biggest
problem is getting all the organiztions registered and collecting the
information to do the translation.
Each organization can be responsible for providing such a collection
of registry information. If the organization can't provide that sort
of information, I really must question their ability to manage email
of any kind. Even FIDONet manages that (fidonet.org, IFNA
[International FIDONet Association]).
And when you are done, users still
have to be aware of two forms of addresses.
CompuServe users are aware of only one generic style of addressing:
">GatewayName:WhateverThatGatewayUnderstands". Thus, they address FAX
stuff as >fax:phone#, and MCIMail users as >mci:someusername, and
Internet sites as >internet:user@host.domain. Very generic, in their
view. Similarly, I prefer only one addressing standard, domain style,
and that's all I have to deal with for CompuServe.
If I'm on XYZ net (which
does not use domains) and I want to tell my friend on the Internet how
to mail to me, I will still have know the name of my host on the
Internet.
That is exactly why the concept of the DNS works so well. Tell me, on
what network does CompuServe exist, that they get email of any kind?
You don't know - you don't have to know, and that's the whole point of
domains. They remove the transport-centric forms of mail addressing
and leave that to lower levels of software which care where the bytes
get sent. Users don't (shouldn't) care. The idea of telling someone
"I'm on XYZ net" is passe'. (BTW, if you're guessing, no, CompuServe
is not UUCP-based, either. Should I have created "B-Protocol Net" and
then tried to tell everyone, "CompuServe is addressable as
user.name@compuserve.bprot," after the fashion currently required by
non-DNS-cognizant BITNET sites? Only inertia keeps .BITNET alive.)
For that matter, on what network is, e.g., MorningStar.COM or HDL.ORG
or UDayton.EDU, entities for which I also do nameservice and mailer
support? Same response: You don't know because you shouldn't care.
The mail "just gets there." If your network doesn't use domains, it
should, and it is very clear to me that this is not because it is "the
Internet standard," but rather because it works, from anywhere. All
you need is a way to query the DNS registries. UUCP does this via
comp.mail.maps info, the Internet via nameservers.
P.S. - If it's all so easy, how come the From address in the message
that I am replying to had an ! in the local part?
My mailers and news software generate @-format DNS, RFC-compliant
addresses in every case except for UUCP mail gatewaying, and even
then, it's still usually @-format. I posted my note as a Usenet news
article, guaranteed to have been in @-format as
karl@cheops.cis.ohio-state.edu. If you've got a ! in the From:
address, it's because somebody's gateway mailer botched the job. An
error in implementation does not invalidate the standards which were
supposed to have been implemented.
--Karlcliff@violet.berkeley.edu (Cliff Frost) (10/28/89)
In article <KARL.89Oct27124632@cheops.cis.ohio-state.edu> karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) writes: >... >If it isn't trivial to do, then the organization's internal mailer >arrangement is in a serious state of disrepair, and deserves to be >overhauled anyway. That's accurate enough (modulo the negative tone). In other words: "If the problem faced by a mail-relay is trivial, then it is trivial to solve." The fact remains that universal MX records don't relieve all mail-relays of the need to do source routing. I'm sure the Host Requirements folks understood the problem, but whichever way they could go is imperfect so looks like they stayed with Architectural Purity. Cliff Frost
RAF@CU.NIH.GOV ("Roger Fajman") (10/28/89)
> > P.S. - If it's all so easy, how come the From address in the message > > that I am replying to had an ! in the local part? > > Why do you care whats in the LOCAL part? It's none of your business. The author of the message I refered to was making the point that everyone on other networks, such as BITNET, should register a domain and use MX records, so as to eliminate the need to use % in the local part. Yet that person had a ! in his local part, which is just as much of a hack as %. Sauce for the goose...
karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) (10/28/89)
cliff@violet.berkeley.edu writes:
(modulo the negative tone)
I am sorry if I came across harshly. It was unintentional.
The fact remains that universal MX records don't relieve all mail-relays
of the need to do source routing.
I keep seeing people discuss these cases that are supposed to be
intractable in the DNS. I've been hammering (repeatedly, sigh) on my
best personal example where it worked flawlessly. Perhaps I'm seeing
things from the wrong end. Can someone provide me with a real world
case where the % hack is _needed_? (A pointer into the appropriate
spot in the HR RFCs will do, if applicable.)
--Karlrayan@cs.toronto.edu (Rayan Zachariassen) (10/28/89)
>Can someone provide me with a real world case where the % hack is _needed_?
I don't think so, mostly due to your definition of 'needed'.
A%B@C can always be expressed as A@B.C or A.B@C or similar (although it isn't
in general possible to translate in the other direction due to strange rfc822
tokens). I doubt people would challenge the technical feasibility of doing
that. The problem is when *YOU* don't control the mailer on C but you still
have to get to a host B that you know C knows because it is a local name,
nickname, secret host, in the backwaters of the campus, or whatever. It isn't
reasonable to demand that every mail system is prim and proper and will
accept DNS names for all hosts it knows about, or translate a DNS name to
whatever magic needed on the remote host based on the hostname (as opposed
to the syntax used to address that host). One has to deal with reality. Alas.
rayanlear@NET.BIO.NET (Eliot Lear) (10/28/89)
Rayan Zachariassen writes that it isn't reasonable to expect sites to demand that every mailer support DNS properly. Yes it is. How long has DNS been out in the world? It isn't reasonable to have to break a model because system administrators won't upgrade their software, and it is even less reasonable to introduce a new method to support the old broken ones. That is to say, why should we expect sites to support the % hack, when we cannot expect other sites to support MXes? The % hack is far from universal. However, what you do with your local part is your business. -- Eliot Lear [lear@net.bio.net]
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (10/29/89)
In article <Oct.28.02.52.01.1989.5606@NET.BIO.NET>, lear@NET.BIO.NET (Eliot Lear) writes: > ... That is to say, why should we expect sites to > support the % hack, when we cannot expect other sites to support MXes? > ... > Eliot Lear > [lear@net.bio.net] As I understand and use the stupid %-hack, it need not be supported by any other site. Rather, it is parsed here to allow mail from remote sites suffering, for whatever reasons, trouble with MX wild cards. A quick look at the queue here shows a lot of mail to @blah.de.blah,@sdaf...asdf:stuf%more@some.dom.ain For many reasons, I'm sure that such addresses were not invented here. That is, a lot of people are telling other people to use the %-kludge to reach them. Some have proposed rewriting ! to % in mail passing thru a site. That seems Wrong. Vernon Schryver Silicon Graphics vjs@sgi.com
rayan@cs.toronto.edu (Rayan Zachariassen) (10/29/89)
lear@NET.BIO.NET (Eliot Lear) writes: >Rayan Zachariassen writes that it isn't reasonable to expect sites to >demand that every mailer support DNS properly. Yes it is. ... >... That is to say, why should we expect sites to >support the % hack, when we cannot expect other sites to support MXes? Eliot, that's not what I said. Perhaps I should rephrase: I don't think it is reasonable to expect every site to map all the hosts reachable from that site into the DNS. Therefore there must be some way of specifying the hosts that are not mapped in this way. I don't care which method is used but there must be some (perhaps specific to the site), unless the intention is to have no communication. There is a long way from "Your mailer must support the DNS" to "Your mailer must ONLY support the DNS (from our point of view)". This doesn't belong in tcp-ip, or anywhere else I can think of. I'll create a mailing list for this kind of stuff if people still want to discuss it.
amanda@intercon.com (Amanda Walker) (10/29/89)
In article <89Oct27.235825edt.2687@neat.cs.toronto.edu>, rayan@cs.toronto.edu (Rayan Zachariassen) writes: > It isn't > reasonable to demand that every mail system is prim and proper and will > accept DNS names for all hosts it knows about, or translate a DNS name to > whatever magic needed on the remote host based on the hostname (as opposed > to the syntax used to address that host). One has to deal with reality. Alas. Ah. It may not be reasonable to *expect* that they will, currently, but I'd argue that it is quite reasonable to *demand* it. If a host or gateway exchanges mail with the Internet, then it must deal with mail addressing (both incoming and outgoing) like an Internet host (currently, by using DNS with MX records if necessary), else mail will not get through it properly and people will be annoyed. The translation that you refer to is part of what being a mail gateway is all about. If you want to use source routing, that means that you know more about delivering mail than your mail gateway. This shows that your mail gateway is Really And Truly Broken, not that you need to use %s. The more people stop supporting the %-hack, the more broken mail gateways will become their owners problems, and not the rest of the world's. This will be a Good Thing, as far as I am concerned. -- Amanda Walker <amanda@intercon.com> -- "If your application does not run correctly, do not blame the operating system." -- Geoffrey James, _The_Zen_of_Programming
henry@utzoo.uucp (Henry Spencer) (10/29/89)
In article <1514@intercon.com> amanda@intercon.com (Amanda Walker) writes: >... If you want to use source routing, that means that you know >more about delivering mail than your mail gateway. This shows that your >mail gateway is Really And Truly Broken, not that you need to use %s. No, it merely means that you know more than your gateway. This is not an unusual state of affairs outside the cozy little best-case Internet world. In the cold, ugly outside world, information about things like topology changes and new hosts can take quite a while to propagate and is often incomplete. In the real world of inter-networking, the gateways *do not* dependably have the most complete and current information. >The more people stop supporting the %-hack, the more broken mail gateways >will become their owners problems, and not the rest of the world's. This >will be a Good Thing, as far as I am concerned. (Modulo the above considerations...) It is a Good Thing if your objective is to get the gateways fixed. It very definitely is not if you are one of the long-suffering users who has no power over the local gateway and just wants to get his mail through! In practice, people tend to have this strange idea that a mail system should give mail delivery priority over ideological purity. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
wicinski@zamna.sgi.com (10/29/89)
>rick@uunet.UU.NET (Rick Adams) says: Did he listen to what i said - NO. I stated: getting registered is NOT easy. The forms are confusing The instrustions are opaque Everything is geared for people who are directly connected. }>No. The $35 is to pay for the hassle involved with reading and correcting the }>forms (30% arrive with errors in them) and for RUNNING THE NAMESERVERS. }> }>Frankly the $35 one time fee doesn't cover the time and effort involved. What a MINUTE - Don't you think something might be WRONG if 30% of them come back with ERRORS? perhaps what i said could be true - ie, the instructions were not written for the people who are filling them out. When i see an error rate of 30 percent i have to say "WHOA, something is wrong with the paradigm." Is everyone committing the same error - perhaps then something should be done to clarify the process. And maybe if you do that, the error rate will drop and you can you time more relevant tasks. The problem boils down to this: When you are directly connected to the Internet, registering is easy. The forms are simple, quick, and direct (i know, I've filled them out this way). When you are not directly connected to the Internet the forms are really a hassle. Most of it becomes non relevant. The problem is the NIC hasn't quite caught on to the fact that more and more domains are non-connecting. Another problem with forwarders and going around begging for one is how it can/will turn into a subtle form of censorinship, turning domain server masters into net nazis for the sake of making sure there systmes are "pure" (and if you don't believe me, i can pull TWO cases out of my mail archives where i received notes from systems nerds stating the content of the flow of mail through their system was "inappropriate behavior for their machines to handle", and in both cases it was caused by pathalias totally botching my direct *source routes*... and peoplewonder why i crypt all my mail...). tim
amanda@intercon.com (Amanda Walker) (10/29/89)
In article <1989Oct29.040104.17081@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > >The more people stop supporting the %-hack, the more broken mail gateways > >will become their owners problems, and not the rest of the world's. This > >will be a Good Thing, as far as I am concerned. > > (Modulo the above considerations...) It is a Good Thing if your objective > is to get the gateways fixed. It very definitely is not if you are one > of the long-suffering users who has no power over the local gateway and > just wants to get his mail through! In practice, people tend to have > this strange idea that a mail system should give mail delivery priority > over ideological purity. Well, so do I, but the two are not entirely separate. My objective in this case is indeed to get the gateways fixed, since that will improve mail delivery for everyone involved. As I said at the beginning of my article, it may not be reasonable to expect all mail flowing on the Internet to involve simple domain-style addresses; the %-hack is in my sendmail.cf, even though I don't think it's ever been used here, for that very reason. However, I still maintain that it should not be considered an acceptable way to specify a mail destination on any kind of permanent basis, as some people have been arguing. I send mail regularly to people via %-!-@ paths, because it's the only way to get mail to them, but in every single case, I consider the mail gateway to be broken. I feel that I shouldn't have to source route my mail any more than I should have to source route my telnet sessions... -- Amanda Walker <amanda@intercon.com> -- "If your application does not run correctly, do not blame the operating system." -- Geoffrey James, _The_Zen_of_Programming
nelson@sun.soe.clarkson.edu (Russ Nelson) (10/30/89)
In article <1989Oct29.040104.17081@utzoo.uucp> henry@utzoo.uucp (Henry Spencer) writes: In article <1514@intercon.com> amanda@intercon.com (Amanda Walker) writes: >... If you want to use source routing, that means that you know >more about delivering mail than your mail gateway. This shows that your >mail gateway is Really And Truly Broken, not that you need to use %s. No, it merely means that you know more than your gateway. [ and Henry goes on to argue for % for pragmatic reasons.] But Henry, some of the local E-mail users have very few clues on how to force mail past Broken gateways. They are all PhDs and are used to solving their own problems. If they can't solve the problem themselves, they figure that it must be unsolvable[1]. Telling people to use % doesn't work for me because I never get asked. I suspect that the same applies to most people who have to support PhDs. These PhDs would be better served by working software. [1] I am not willing to argue these two sentences. They are true in *my* experience, and that is all I am asserting. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Live up to the light thou hast, and more will be granted thee. A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989.
rick@uunet.UU.NET (Rick Adams) (10/30/89)
No. The majority of the errors come from people not following the instructions. Consider the simple instruction: Fill in questions 1, 2, 3 and leave 4, 5, 6 alone and return the entire form to me. about 15% of the people "change the answers to 4,5 and 6 to something wrong. I dont know how much more simple you can make it than "leave #4 alone"
epsilon@wet.UUCP (Eric P. Scott) (10/30/89)
In article <71081@uunet.UU.NET> rick@uunet.UU.NET (Rick Adams) writes: >No. The majority of the errors come from people not following the >instructions. Maybe we should have the IRS handle domain registration. :-) -=EPS=-
henry@utzoo.uucp (Henry Spencer) (10/31/89)
In article <NELSON.89Oct29203312@image.clarkson.edu> nelson@clutx.clarkson.edu writes: > >... If you want to use source routing, that means that you know > >more about delivering mail than your mail gateway. This shows that your > >mail gateway is Really And Truly Broken... > > No, it merely means that you know more than your gateway... > >But Henry, some of the local E-mail users have very few clues on how >to force mail past Broken gateways. They are all PhDs... >...would be better served by working software. The answer to how an ignorant PhD (a species I am familiar with) gets mail to an unregistered host using strictly-conforming mail software without asking for help is "he can't". However, a sophisticated user, or someone who has the sense to ask advice of a sophisticated user, can... if the relevant gateway has the decency to admit its limitations and support %. Everybody would be better served by working software; there is no doubt about that. However, the notion that "working software" will automatically have complete and correct knowledge of every destination to which one might want to send mail is simply wrong. For the foreseeable future, there will always be situations -- typically involving non-Internet sites -- in which the user knows more than the mailer does, and should be able to exploit this information. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu