kit@gateway.mitre.ORG (07/03/90)
FYI, per the request of several respondents, appended is my original list of X.400 implementation questions from a month ago, and the responses I got to it...I would still like to get additional responses, if you have anything to add. Thanks for your time. Kit Lueder, MITRE Corporation. From kit@gateway.mitre.org Wed Jun 13 16:00:32 1990 Received: by gateway.mitre.org (5.54/SMI-2.2) id AA11167; Wed, 13 Jun 90 16:00:23 EDT Return-Path: <kit@gateway.mitre.org> Received: by neptune.mitre.org (5.54/SMI-2.2) id AA00535; Wed, 13 Jun 90 15:58:50 EDT Date: Wed, 13 Jun 90 15:58:50 EDT From: kit@gateway.mitre.org Message-Id: <9006131958.AA00535@neptune.mitre.org> To: iso@nic.ddn.mil, mhsnews@ics.uci.edu Subject: questions about X.400 implementations Cc: kit@gateway.mitre.org Status: R I am working at MITRE Corporation, working on some issues for a messaging system for Department of Defense. I had some questions about how actual X.400 implementations supported some features. Note that I understand the protocol specifications; I am interested in implemetations, not theory, here. Thank you in advance. Kit Lueder, MITRE Corporation. Phone 703-883-5205. 1. Support of alternate recipient assignment. How is the alternate recipient identified--in the directory, in some other non-X.500 table? Can specific alternate recipients be assigned for each actual recipient, or is it more of a "dead letter office" where all undeliverable mail gets dropped? Can the alternate recipient reside on another Message Transfer Agent (MTA), or must it be on the same MTA as the originally intended recipient? 2. Multiple connections of UA to MTA. Can a Remote UA be connected to more than one MTA? If so, can it still have the same ORName/ORAddress regardless of which MTA it uses? 3. Gateways and end-to-end DN/NDN. If you have a gateway from X.400 into the non-X.400 world, can you have the DN/NDN (Delivery Notice, Non-Delivery Notice) go end-to-end, so that the X.400 message originator does not get a notice back until the message was successfully (or not) delivered to the non-X.400 end system? Or does the DN/NDN get triggered when the MTA gives the message to the first gateway, regardless of what happens to the message after it passes through the gateway? (See below for an elaboration of this question.) 4. Co-located UA/MS. Is a co-located UA and MS (Message Store) any different than just a UA by itself (if there is no visible P7 protocol)? 5. Probe knowledge of UA status. When an MTA receives an X.400 Probe which identifies a recipient supported by that MTA, how much knowledge does the MTA have about that recipient's UA status? Can the MTA know that the UA is down (especially in the case where the UA is remote), and thus do an NDN, even though the recipient name is registered correctly? (The following is an elaboration of question number 3 above.) I can see two possible ways of gateways supporting delivery notices end-to-end. The gateway can be either an MTS-level gateway or a UA-level gateway. An MTS-level gateway would have a P1 interface to the X.400 MTA domain, so the generation of a DN/NDN response is straight-forward in this case. A UA-level gateway would have something like a P3 interface (submit and deliver interface) with an MTA, and the handling of DN/NDN is less clear here. To simplify, let's say that a message is sent from a pure vanilla X.400 UA, via an X.400 MTA (or several MTAs), to the gateway UA: the X.400 UA would do a P3 submit, the MTAs would do a P1 transfer to the destination MTA, and the last MTA would do a P3 Deliver operation. The gateway would at that point delay doing the P3 Deliver-Confirm until it had converted and transferred/delivered the message to the non-X.400 end-system. After the gateway heard back from the non-X.400 end-system, it would do a P3 Deliver-Confirm (with either a positive or negative indication), which would trigger the MTA to generate either a DN or NDN back to the originating X.400 UA. It is not clear that this second case is legal (not that that has stopped implementations in the past, where there is a market need). For one thing, CCITT 1988 X.411, clause 8.3.1.1 Message-delivery states "The MTS-user shall not refuse delivery of a message unless the delivery would violate the Delivery-control restrictions then in force." Even if it was allowed, what Deliver-confirm operation Error response could be used (since DeliveryControlViolated, SecurityError and UnsupportedCriticalFunction do not seem applicable)? Do the implementations you have dealt with support one or the other of these approaches, or are there other approaches as well? From cargille@cs.wisc.edu Wed Jun 13 17:28:02 1990 Return-Path: <cargille@cs.wisc.edu> Received: by gateway.mitre.org (5.54/SMI-2.2) id AA12630; Wed, 13 Jun 90 17:28:00 EDT From: cargille@cs.wisc.edu (Allan Cargille) Message-Id: <9006132127.AA03751@rivendell.cs.wisc.edu> Received: by rivendell.cs.wisc.edu; Wed, 13 Jun 90 16:27:24 -0500 Subject: Re: questions about X.400 implementations To: kit@gateway.mitre.org Date: Wed, 13 Jun 90 16:21:48 CDT In-Reply-To: <9006131958.AA00535@neptune.mitre.org>; from "kit@gateway.mitre.ORG" at Jun 13, 90 3:58 pm X-Mailer: ELM [version 2.2 PL13] Status: R > I am working at MITRE Corporation, working on some issues > for a messaging system for Department of Defense. > I had some questions about how actual X.400 implementations > supported some features. Note that I understand the protocol > specifications; I am interested in implemetations, not theory, here. > ... Hello Kit, I'm doing X.400 work at the University of Wisconsin. I have been working with Judy Messing of MITRE. I'm afraid I can't answer your questions, but I am very interested in the answers. Could you please collect the responses and forward them to the list? I'd really appreciate it. Thanks, allan -- Allan Cargille Computer Sciences Department Associate Researcher University of Wisconsin-Madison cargille@cs.wisc.edu 1210 West Dayton Street uwvax!cargille Madison, WI 53706 USA +1 (608) 262-5084 Fax +1 (608) 262-9777 From eskovgaa@uvcw.uvic.ca Thu Jun 14 12:24:00 1990 Return-Path: <eskovgaa@uvcw.uvic.ca> Received: by gateway.mitre.org (5.54/SMI-2.2) id AA23432; Thu, 14 Jun 90 12:23:02 EDT Received: by relay.CDNnet.CA (4.1/1.14) id AA21871; Thu, 14 Jun 90 09:20:56 PDT Date: 14 Jun 90 9:15 -0700 From: Erik Skovgaard <eskovgaa@uvcw.uvic.ca> To: kit@gateway.mitre.org In-Reply-To: <9006131958.AA00535@neptune.mitre.org> Message-Id: <92*eskovgaa@uvcw.UVic.ca> Subject: questions about X.400 implementations Status: R Hi Kit! I can tell you how the old Sydney code worked (that is used on quite a few systems, so it may be interesting): Alternate recipient: forwarded to a specific recipient when O/R-name is ambiguous (not invalid); i.e. when an MTA has a number of users, but the address is only specified to the Org or OU level. It is NOT the same as a deadletter box (which, incidentally, is only for NDNs that cannot be routed or potentially messages nuked by loop detection). CO-located UA/MS: This is a part of the deception that creative product managers use. I have seen it used quite a lot. It is obviously a local issue how you implement, if they are co-located. I don't think you will find many experiences with P3 - I am not aware of any real implementations - only some that claim they use P3, but if you look at it in more detail, they usually use some sort of proprietary protocols. We have just been through an evaluation of a number of X.400 products, so if you need up-to-date info, I may be able to help you out. As I indicated above, I find that many sales people use somewhat misleading terms, so it is hard to sort out what is real. Good luck! ....Erik. P.S. I will be in the D.C. area in September. Hope to see you there. Will you be at the NIST meeting in Vancouver? From retix!chet@uunet.UU.NET Fri Jun 15 17:09:51 1990 Return-Path: <retix!chet@uunet.UU.NET> Received: by gateway.mitre.org (5.54/SMI-2.2) id AA16507; Fri, 15 Jun 90 17:09:47 EDT Received: from retix.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA27709; Fri, 15 Jun 90 17:09:08 -0400 Received: by retix.retix.com (5.51/smail2.5/06-04-90) id AA05568; Fri, 15 Jun 90 13:43:45 PDT Date: Fri, 15 Jun 90 13:43:45 PDT From: chet@retix.retix.com (Chet Mazur) Message-Id: <9006152043.AA05568@retix.retix.com> To: kit@gateway.mitre.org Subject: [kit@gateway.mitre.org: Re: questions about X.400 implementations] Status: R 1. Support of alternate recipient assignment. How is the alternate recipient identified--in the directory, in some other non-X.500 table? Can specific alternate recipients be assigned for each actual recipient, or is it more of a "dead letter office" where all undeliverable mail gets dropped? Can the alternate recipient reside on another Message Transfer Agent (MTA), or must it be on the same MTA as the originally intended recipient? You'll love my answers... I have never seen alt. recip. implemented... But as you stated it could be the x.500 or thru a propriatary scheme.... and it's intended to be a per-recipient and not just a dead-letter. 2. Multiple connections of UA to MTA. Can a Remote UA be connected to more than one MTA? If so, can it still have the same ORName/ORAddress regardless of which MTA it uses? To my understanding..... no.... otherwise there would be no way to know which MTA to send the mail to if there was a duplication of ornames... 3. Gateways and end-to-end DN/NDN. If you have a gateway from X.400 into the non-X.400 world, can you have the DN/NDN (Delivery Notice, Non-Delivery Notice) go end-to-end, so that the X.400 message originator does not get a notice back until the message was successfully (or not) delivered to the non-X.400 end system? Or does the DN/NDN get triggered when the MTA gives the message to the first gateway, regardless of what happens to the message after it passes through the gateway? seeing that I'm implementing a gateway right now I can specifically comment on this one.... My g/w will have end-to-end DN as well has reciept notifcation (P2).... since the propriatry mail system I'm mapping to has equivalent protocol elements.... If, however, this was an RFC 987 gateway (SMTP <-> X.400) there would be no end-to-end possible since RFC-822 doesn't have such a feature.. 4. Co-located UA/MS. Is a co-located UA and MS (Message Store) any different than just a UA by itself (if there is no visible P7 protocol)? This is 88 X.400 and I'm less confident here... (and there are few "implementation" to speak from fact about).... From my 1 month stint on our 88 project I would have to say...... Your question is unclear. a UA is a UA and a MS is a MS.... independent of co-location or not.... I don't undersatnd the part about "visible P7" (as opposed to invisible???? hahahahahah)... 5. Probe knowledge of UA status. When an MTA receives an X.400 Probe which identifies a recipient supported by that MTA, how much knowledge does the MTA have about that recipient's UA status? Can the MTA know that the UA is down (especially in the case where the UA is remote), and thus do an NDN, even though the recipient name is registered correctly? I suppose this depends on implementation..... The MTA in general has no knowledge of the UA's status..... for example if the user is "logged off" (his/her terminal is off), then the UA is down..... but the MTA can recieve a msg for that use just fine.... it shouldn't send a NDN.... hope this helps... if you get any conflict answers please let me know other people points of view... THESE comments are strictly my own and have nothing to do with my company or any of it's products.... thanks... Chet Mazur (chet@retix.retix.com) Retix Software Engineer 2644 30th ST Santa Monica, CA 90405 (213) 399-1611 X.400 C=US; ADMD=TELEMAIL; PRMD=RETIX; ORG=OSI ONE; S=Mazur; G=Chet From dml@sarah.ssw.com Mon Jun 25 13:17:39 1990 Return-Path: <dml@sarah.ssw.com> Received: by gateway.mitre.org (5.54/SMI-2.2) id AA24576; Mon, 25 Jun 90 13:17:34 EDT Received: from sfswitch.ssw.com by gateway.ssw.com (5.61/SSW-2.3(3)) id AA00557; Mon, 25 Jun 90 13:10:56 -0400 Received: from sarah.ssw.com by sfswitch.ssw.com (5.61/SSW-2.3(3)) id AA03426; Mon, 25 Jun 90 13:09:21 -0400 Received: by sarah.ssw.com (5.51/SSW-2.2(2)) id AA07663; Mon, 25 Jun 90 13:15:49 EDT Date: Mon, 25 Jun 90 13:15:49 EDT From: Dave M. Leonard <dml@sarah.ssw.com> Message-Id: <9006251715.AA07663@sarah.ssw.com> To: kit@gateway.mitre.org Subject: X.400 Questions From Kit Lueder Status: R === Reply to MEMO 06.13.90 16.49 === Although I don't have a whole lot to say about your other questions, Kit, I can speak volumes about question #3 about delivery reports passing through gateways. This is one of the more complicated issues in electronic mail gateway design. I will try to touch on the major issues. The first big question is: what kind of mail system are you connecting to? Does it have a concept of "architected" status? If not then you really have no choice but to reflect a delivery report at the gateway boundary. If it does, then when you convert the P1 envelope to the native mail system format, turn on the appropriate indicator to cause a delivery report to flow back to your gateway. When you get the native mail system's version of a delivery report back, simply convert into an X.400 delivery (or non-delivery) report and send it on its way. Simple enough, right? Except how do you know what the MPDU-id of the original distribution was? There are two methods: stuff it into a correlation field in the native mail system's envelope (if there is one and if it is big enough), and failing that, maintain, in the gateway, a context database which is indexed by the native mail system's (and possibly by the X.400) MPDU-id. The data portion of the context database entry would be the corresponding ID in the other environment. You need to always store in the context database even if a delivery report was not requested, since you always have the potential to receive a non-delivery report, so you need a scheme to clean out dead entries in your context database. Also, you will need one entry per recipient, to keep track of the extension ids. The preceding discussion refers only to the P1 report request. As for P2 read receipt, the question is: does the native mail system make the distinction between P1 report request type of status and the P2 receiptNotification type of status? If there is no equivalent of P2 status (that is, status which is not generated until the recipient actually reads it - theoretically anyway), then you have to decide what to do about it. There are a couple of approaches: use whatever level of status the native mail system supports and "lie" to the X.400 originator, or send back some sort of message saying "I sent this along to the native system but read receipt is not supported". There are a lot of other issues as well which are related, such as multiple body parts. If the native mail system does not support them, and you break up the MPDU into multiple mail items, how will status work in that case? etc., etc., etc. If this does not answer your question, feel free to call me or reply. David M. Leonard Engineering Manager Soft-Switch, Inc. Wayne, PA dml@softsw.ssw.com (215) 640-7483