steve@CS.UCL.AC.UK (Steve Kille) (06/17/88)
I propose the following change. Comments welcome? Many mailers need to access gateways by use of source routes (e.g. @gateway:user@x400-domain) - alternatively using a % style routing. RFC 987 maps this into domain defined attributes (to ensure reversability of the mapping). It is suggested that a 987 gateway should recognise (in an RFC 822 header), the source routes with the local domain explicitly identified, and treat the address as if the component was not present (e.g. map @my-gateway:user@dmn as if it was user@dmn). This is ugly because: - It is assymetrical - 822 Mailers should be able to route properly It is pragmatic because: - Many 822 mailers cannot route properly - Many X.400 systems do not deal cleanly with DD atributes - In practice it will behave in the "right way" On balance, I vote for the pragmatic change (as it will keep some of our users happy). What do people think? Steve
Crispin@SUMEX-AIM.STANFORD.EDU (Mark Crispin) (06/19/88)
I second Steve Kille's suggestion. In fact, I believe that MX records should obliviate the need for source routes and they should be removed from the protocol entirely. -------
piet@cwi.nl (Piet Beertema) (06/20/88)
It is pragmatic because: - Many 822 mailers cannot route properly Often you can't blame the mailers for that, unless you assume that the underying network those mailers work on is a true internet. In practive 822 mailers have to mail/gateway to other networks too - e.g. the UUCP network - where any direct translation of a source route is usually highly meaningless. So, yes, we should take the pragmatic approach. Piet
huitema@mirsa.inria.Fr (Christian Huitema) (06/21/88)
The MAILWAY implementation of RFC-987 which INRIA has issued follows exactly Steve's "pragmatic approach", for exactly te reasons stated by Steve. Thus, I suggest to agree his proposal. Another reason for removing source routes as much as possible is indeed user convenience: showing the source in the receipients addresses will lead to ackward routes for "replies to third parties", directing the mail to unnecessary gateways even when direct routes exists. Christian Huitema
steve@CS.UCL.AC.UK (Steve Kille) (06/21/88)
Damm it - you lot really disapoint me. Everyone standing up for pragmatic hacks, and no-one wanting to do things properly. Have we really been buried in the swamps that long??? Steve
huitema@mirsa.inria.Fr (Christian Huitema) (06/22/88)
> > Damm it - you lot really disapoint me. Everyone standing up for pragmatic > hacks, and no-one wanting to do things properly. It all depends what you call "hacks" and what you call "properly". In practice, "properly" implies convincing the whole Internet to stop using gateway addresses -- probably a lengthy process. And the "hack" is often needed to get rid of the source routing which was not present at first, but which has been elegantly added by address rewriters (a la sendmail) in the successive relays.. Fact is that the swamps are muddy. Christian Huitema
rayan@ai.toronto.EDU (Rayan Zachariassen) (06/27/88)
The use of source-routes or %-hacks to "access gateways" is incidental to the real purpose and goal of such mechanisms. It is necessary to be able to specify a series of MTA's a message must pass through, and to be able to predict the address seen by each of those MTAs (the latter is pretty irrelevant for attribute-based routing but essential for RFC822). One of the problems I see with X.400 is the lack of such a facility (although I gather it might show up in some form). It is necessary for: - testing, where route predicatibility is important - manual routing when you know something the intermediate MTAs don't - automatic partial routing (e.g. to override normal routing of downstream MTA) out of technical/political/administrative concerns. - the final destination (or originator) address need not be specified in a globally unique or well-understood form in a source route (the wording of the spec makes this arguable, but in practise this is true) I don't understand the comment that RFC822 source routes are at best hazardous when gatewayed into a non-SMTP (which is the real distinction) network like UUCP. Works for me. The idea of a one-way translation is repulsive; it should be possible to send an RFC822 message through an X.400 network and recover the original message (modulo trace info and address translation) on the outgoing end. Similarly it should be possible to send an X.400 message through an RFC822 network without losing information. We also need to distinguish between source routes in the envelope and in the header. It is the envelope address which is significant, but current RFC822 UAs usually default the envelope information from the header. So even though lack of source route information in the header is not a terrible loss, envelope information cannot be treated as nonchalantly. I think RFC987 already is incomplete in terms of transparency, the suggested change would make it more so. It'd be more and more of a trap door for messages, which means it would inherently limit the use of X.400 as a transport mechanism between heterogenous (mail-protocol-wise) nets. Putting the routing info into DD attributes is ok, although I'd prefer that whatever mechanism is being cooked up to address this in native X.400 is the one used. I don't know for sure if this is happening and if it is what the plans are (I don't remember where I got this notion from). One of my perspectives on this is that I dream of building a merged RFC822/X.400 router (i.e. merging X.400 into my RFC822 MTA). This will be relatively easy to do iff there is a well-defined and appropriate textual representation for 100% of the P1/P2 information in an X.400 message. RFC987 to me looks like a good basis, but isn't yet mature/extensive enough to be used for this. The proposed change is therefore a change in the wrong direction. regards, rayan
dfk@cwi.nl (Daniel Karrenberg) (06/30/88)
> The diffiuclty is all of these things, which APPEAR to be globally valid > addresses, but in fact are only recognised in some parts of the world. Just to name them: The locally invented RFC920 names of European X.400 domains. I sure hope they will vanish yesterday.
dfk@cwi.nl (Daniel Karrenberg) (07/04/88)
> My (perhaps faulty) impression is that the loud YES came from: > - someone with a lot of Internet experience (MRC), i.e. from a homogeneous > environment where source routes are superfluous (ideally at least, modulo > politics and %-hacks) > - someone with a lot of UUCP/BITNET background (Piet) whose experiences are > different from mine. There was another YES from me (sent to Steve privately). Reasons: I like gateways to simplify addresses in the domains a message is relayed to. They shouldn't of course be simplified beyond "replyability". My experiences with users and the actual problems they have is that this creates the least problems. Yes, I agree that it sometimes "hides" information from an experienced user but you can't have it all. Background: Running UUCP/BITNET/Internet gateways for some five years. As to your call for a textual representation for X.400 addresses: We have it. It's specified in RFC987. Cheers Daniel
pv@SUN.COM (Peter Vanderbilt) (07/07/88)
I think the header/envelope distinction is important. There are two uses of source routes: (a) for testing and measurement and (b) to compensate for limited routing knowledge. Compensating for limited routing knowledge is such a swamp that it's not at all clear that we could do the right thing even if we wanted to; I would vote that we put our efforts into getting the routing knowledge distributed correctly and modify RFC 987 to say that all source route info is removed from header addresses before translation. But for (a), it does make sense to allow for source routing in the envelope -- an X.400 administrator should be able to add routing info to the envelope's recipient addresses to control the path that a message takes (like through the gateway and back or use the Internet for some of the hops). To accomplish this, we need only handle source routes in the envelope. Your mail transport system may do this already because some systems forward by adding an "@gateway:" (or "...%...@gateway") to envelope addresses (so your system would have to strip the "@gateway"). Actually, forwarding as described above is a third legitimate use of source routes -- if my 822 system (sendmail) wants to forward through X.400 to another 822 system, it does so by prepending "@gateway2:" to the recipient's address (where gateway2 is the 822 address of the remote gateway) and passing the message to the local gateway. What we need to define is what source routes we allow for in recipient addresses (P1.recipient ORNames with rfc-822 DDA's). Do we allow for 822-style "@host1,@host2,...:user@hostn" or the informal "user%hostn%...%host2@host1" or both? Must host1 be the destination gateway's 822 address or must host1 *not* be the destination gateway's 822 address or doesn't it matter? My answers are "both" and "doesn't matter" respectively. Pete