From owner-Big-Internet@munnari.OZ.AU Thu May 18 09:12:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12361; Thu, 18 May 1995 09:12:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA04837; Thu, 18 May 1995 09:12:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA04818; Thu, 18 May 1995 08:56:35 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11622; Thu, 18 May 1995 08:56:15 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA07145; Wed, 17 May 95 16:03:50 -0700 Date: Wed, 17 May 95 16:03:50 -0700 From: Eric Fleischman Message-Id: <9505172303.AA07145@atc.boeing.com> To: big-internet@munnari.OZ.AU Subject: SMTP versus X.400 results Precedence: bulk Dear Big-Internet mailing list, If you are not interested in electronic mail, please delete this message now. Nearly a year ago I sent a note to this list asking for "facts and data" concerning the strengths/weaknesses of SMTP vis-a-vis X.400. My query contained a specific request for feedback concerning 14 specific claims made by X.400 advocates. This query was part of a larger quest in which I was seeking to form a facts-based personal opinion concerning what my company's electronic mail strategy should be. The response from this list was stellar. I received more than a megabyte worth of data and had the honor of privately dialoging with many of you. I also received many requests stating that I "owed" this list a summary of my conclusions/findings. The purpose of this note is to fulfill that debt. I apologize for my tardiness in providing this summary. The wealth of information I received (which included reading several books, following scads of journals and "trade rag" articles, trying to follow the input from entities such as The Gartner Group and Forrester Research, and having numerous personal dialogs and interviews with knowledgable individuals -- in addition to the information you all provided) was quite overwhelming. The following summarizes my personal conclusions from this quest: 1) Both X.400 and SMTP need to be supported by Boeing today. Both will doubtlessly need to be supported in the foreseeable future as well. 2) I assume that X.400 and SMTP are currently in a "market share conflict" for the hearts and allegiance of Email users. I can not predict which will eventually "win out" and I would not be surprised if they both preservere in various markets/niches indefinitely. 3) I perceive that in the general case X.400 advocates are inadequately knowledgable about Internet Mail and that Internet Mail advocates are inadequately knowledgable about X.400. I suspect that much of the current "hype" surrounding Email would be reduced if a more adequate common knowledge-base existed. 4) Internet Mail (including SMTP, MIME, PEM) has superior value (price/performance characteristics) over X.400 today. Internet Mail is also the "lower risk" alternative for today. A probable/possible exception to these claims is in the specific case of application gateway usage. 5) I can write a business case stating that Internet Mail should be Boeing's preferable strategic direction today. I am very uncomfortable writing a similar business case for X.400 unless I either explicitly ignore the existence of Internet Mail or else propose that both are co-equals in today's strategic direction. The following is a presentation which summarizes the "high points" of my findings. I have earnestly tried to be non-biased and factual during this quest, though one must question the integrity of my personal "information filters" and the invariable bias/presuppositions which led me to conclude that certain information was more important than other information. I have continually sought after "the Truth" in these matters. However, my results doubtlessly diverge from "the Truth" in unknown ways due to my many personal limitations and failings. Fortunately, the following presentation has benefited from the inputs/enhancements provided by hostile audiences so that egregious errors have hopefully been reduced/eliminated. The following summary is also necessarily incomplete, being limited to what I considered to be the "maximum attention span" of interested management. For this reason, "balance" was unfortunately sacrificed in this presentation in order to ensure that management would be confronted with the subset of information which I personally believed to be the most critical for making a business decision. This summary was originally developed and produced in another format. It has been messily transcribed into ASCII text for transmission to you. I apologize in advance for the poor results of this transcription. (Please also note that the original named specific Fortune 100 companies by name within many of the bullets. Most of these references have been eliminated from this version.) Finally, I must affirm that everything in this note is my personal opinion. These opinions are emphatically NOT the established opinion of The Boeing Company, despite my alleged position within the corporation. Sincerely yours, --Eric Fleischman Data Communications Architect Boeing Information and Support Services (formerly Boeing Computer Services) ============================ presentation now follows ===================== I. Introduction II. Architecture III. Business Case Relevant Issues IV. Some Current X.400 Problems V. Examination of Reasons to Support X.400 ------------------ I. Introduction Key Points of Presentation * The Boeing Company will need to support both SMTP and X.400 for the foreseeable future due to actual business requirements. * The world's Email situation has dramatically changed since 1993. * Industry has traditionally not understood the close linkage between SMTP, MIME, PEM and the World Wide Web (WWW; e.g., HTTP, Mosaic). * SMTP is (debatably) the world's de facto Email standard. * Internet Mail should become Boeing's strategic Email direction. Boeing Email Diversity Boeing currently supports considerable internal and external Email diversity. Internal: A1 Mail, All-in-1, VMS Mail, Office Vision (Profs), Xerox, CC:Mail, HP Desk, Wang, SMTP, MS Mail, others. External: IBM Mail (Profs), SMTP, X.400 via VANs, X.400 via PRMD-PRMD, X.400-to-Telex, X.400-to-fax. ----------------- II. Architecture X.400 and SMTP: Similarities Of all the existing Email protocols, only X.400 and SMTP have a global addressing scheme. This enables them to create world-wide messaging infrastructures. It also means that other messaging approaches (generally) must be converted into either X.400 or SMTP to be carried between corporations/governments. Both are International standards: * X.400 is an ITU/T (CCITT) and ISO joint standard. * SMTP is an Internet Standard. (ISOC and ISO have "joint recognition" agreement in place.) Architectural Assumptions X.400 SMTP Designed to be a store-and-forward Provide an end-to-end messaging messaging infrastructure. service to the user. Seeks to "add value" to an X.25 Designed to be an "Internet network. application". Seeks to be a total integrated Seeks to be simple to build and messaging solution. maintain and simple and flexible to use. X.400 Architecture +--------------------------------------------P2 ---------+ | MTA | | / \ | | P1 P1 | | / \ | UA -------P3 ------- MTA MTA --------P3 ------- UA / \ / / P1 P1 / \ / UA------ P3 ------ MTA UA = User Agent | MS = Message Store P3 MTA = Message Transfer | Agent UA -------- P7 ---------------- MS Note: This is a simplified architectural view. P1, P2, P3, and P7 are distinct X.400 protocols. The distinct ITU/T X.400 (1988) protocol variants are not listed. The P2 protocol is an end-to-end protocol for UA-to-UA messages. SMTP Architecture Mail System <--------- SMTP --------------> Mail System SMTP tied to the Internet * SMTP comes "natively bundled" within TCP/IP products. (Note: It is not included in some/many Personal Computer TCP/IP products.) * The Internet is based upon TCP/IP. SMTP is the Internet's only standard Email protocol. * 20,000,000 native SMTP users world wide.* * SMTP is the basis for most List Servers. * SMTP and MIME are natively bundled into the World Wide Web (WWW). * Some corporations have build SMTP Email backbones to enhance their Internet connectivity. * Source: Internet Society News, 1994; Vol 3, No. 2, pg 11 What is Internet Mail ? * Simple Mail Transport Protocol (SMTP) Defines the Internet Electronic Mail protocol. RFC 821. * Multipurpose Internet Mail Extensions (MIME) Defines a flexible structure for identifying and carrying complex messages including multiple body parts within SMTP and HTTP protocols. RFC 1521, RFC 1522, RFC 1590 * Privacy Enhanced Mail (PEM) Defines Internet Email security for messages carried via SMTP protocols. RFC 1421-RFC 1424 * MIME Object Security Services (MOSS) A way to secure MIME-based messages. Internet-draft document. * MIME Encapsulated EDI objects. Specific MIME definition for Electronic Data Interchange objects. RFC 1767 * Notary Provides for receipt/non-receipt notification of SMTP-delivered mail. Internet-draft document. ----------------- III. Business Case Relevant Issues Implications of the Architectures * Because X.400 is a store-and-forward system, messages must be queued during the "hops" to their destination. This adds time to the ultimate message delivery, demands more network resources, and introduces more opportunities for errors. * Each message relaying "hop" may be a potential security vulnerability. * It is more difficult to build X.400 products. * It is more difficult to administer, maintain, and support X.400 implementations. Cost X.400 SMTP Products Every X.400 product costs Many SMTP products come bundled money to buy. within TCP/IP "for free". Internal X.400 infrastructure All SMTP services are completely Corporate demands special devices transparent to the network Network to perform its messaging demanding no special devices Infrastructure services as well as or services. significant (human) administrative overhead. Service Traditionally provided via Provided by the Internet Service Providers Value Added Networks providers as part of the (for relaying (VANs). VANs are basic connection charge messages expensive to use (e.g., X (e.g., Y spends essentially between spends nearly $250,000 a nothing for their SMTP-based corporations) MONTH for their VAN messaging beyond their normal charges). Internet connection charges). Security X.400 PEM (SMTP) Where X.400 (1984) has no security Security is done to the message Security provisions. The 1988 contents thereby ensuring end-to- is done. version does security at the end message integrity. message "envelope". Certifi- No trust rules for Rigid certification hierarchy cation certification hierarchy are specified to permit interoperation Hierarchy specified. Implementations between different implementations. need to make their own decisions which may potentially impact interoperability. Certifi- Optional method for placing Slot in mail header for placing cation certificates in the mail certificates. Intend for PEM to Distribu- header. Assumption is alternatively obtain certificates tion certificates will be from the directory. distributed via X.500. Encoding Three types of messages: Two types of messages: of Trans- unencrypted and signed, unencrypted and signed and mitted encrypted and signed, encrypted and signed. Unencrypted Messages and encrypted but not but not signed can be done via PGP. signed. Encryption Theoretically can use any Theoretically can use any encryption encryption approach. Not approach. In practice today aware of any actual it uses DES for encryption, DES or encryption between X.400 RSA for permanent keys. users today. Message Contents Both X.400 and SMTP's MIME provide a capability to flexibly carry binary messages and multiple body parts. SMTP's MIME has always permitted the identification of exactly what type of data is being carried and how it is encoded. The first X.400 products to also do this were just released earlier this month (May 1995). X.400 is thus several years behind MIME in the definition of Object IDs to empower message encoding capabilities. Usage Statistics 20,000,000 SMTP users world-wide.* Number of X.400 end users world-wide is unknown (100,000 ????). X.400 is traditionally deployed as Email gateways (e.g., Corporate Email Backbone, translating proprietary protocols for shipment between corporations). World's primary X.400 deployments believed to be within Europe and within governments: * In Europe, 90% of the inter-corporate/government Email traffic is SMTP and 10% is X.400.** * US Governemnt usage may be 81% TCP/IP (SMTP), 59% Novell NetWare (MHS), and 11% OSI (X.400).*** * Source: Internet Society News, 1994, Vol 3, No 2, page 11 ** Source: Survey done of Service Providers in Norway, Netherlands, Switzerland, and Italy during March 1995 ***Source: Government Computer News Magazine, September 5, 1994 Product Maturity Because of its greater market share and simplicity, Internet Mail products (i.e., SMTP, MIME, PEM) are more advanced than X.400 products feature-by- feature. Internet Mail's features tend to be deployed 2 or more years before the equivalent features begin to appear in X.400 products. The (debatable) exception to these observations may be receipt notification. Even though the development of X.400 and SMTP both started in 1978, SMTP implementations began in the 1979 timeframe while X.400 implmentations did not occur until the 1985 timeframe. The internal complexity of X.400 means that there are more potential bugs to be found and fixed in X.400 products. The lack of implementation orientation of the X.400 designers means that there are more issues to resolve before X.400 products can be used. All this means that X.400 products are generally demonstrably less mature than Internet Mail products even when they have the same feature set. The Forrester Report (Volume 12, Number 5; "Scaling Email" by Deutsch, Colony, and Rhinelander; March 1995, pages 6-7) Two Forrester Email Recommendations: 1) "Rationize the number of front ends." The race for the Email client is over. The winners are the three market leaders: Lotus, Microsoft, and Novell. Reports recommends that users should standardize on one of these three. 2) "Prepare for an SMTP backbone. Why SMTP? Why not X.400? Three reasons: 1) SMTP is the protocol of the Internet which will assume increasing importance in corporate computing; 2) SMTP supports essential features like multimedia enhancements and security; 3) X.400 is a complex dinosaur that never took root."* * Please note that the offensive language is a direct quotation from the report and is not the construct of the author. INRIA's Experience INRIA is a French company which acts as a consultant to the French government. INRIA found X.400 to be prohibitively expensive to administer and maintain. Today they exclusively use SMTP. They report a growing number of European industries forming similar conclusions. Source: Christian Huitema of INRIA ------------------ IV. X.400 Problems Some Problems with X.400 for Commerce * Slow speed by ADMDs -- 9.6 Kbps is the norm. * Acks among ADMDs are different affecting automated processing. * X.400 terminology is different (e.g., LN, FN, MI). * Can't send to some European ADMDs. * Inconsistent billing for messages between ADMDs. * Inconsistent use of E-signatures among ADMDs. * Lack of X.400 (1988) and X.435 support across ADMDs. * VANs don't monitor throughput and message flows, delays between nodes, end-to-end timings. * No performance measures among ADMDs, no standard or published measures. Source: EMA Electronic Commerce Committee ------------------ V. Reasons to Support X.400 Examination of Reasons to Support X.400 1) Some trading partners require X.400 usage. This is entirely true and is the best reason to use X.400. However, other trading partners require the use of SMTP. Therefore, appropriate backbone questions include "which usage predominates externally?" and "which approach minimizes the need for message translation?" 2) X.400 provides logging and tracking capabilities. True. X.400 MTAs do log messages and VANs also provide logging and tracking. There are business environments where these services are needed, particularly within some Electronic Data Interchange (EDI) applications. However, VAN services come at a high monetary cost and are not required in the general case. 3) X.400 is more secure than SMTP. True. However, X.400 is not more secure than SMTP with PEM. Security experts are divided as to which approach is the more secure, though most seem to agree that the SMTP with PEM usage is more secure than X.400 usage today. Some anticipate that the emerging MOSS technology may provide enhanced security services. Regardless, the key point is that SMTP is designed to work with other Internet protocols to supplement its basic service while X.400 is an integrated environment needing only X.500 directory services. 4) X.400 can do EDI while SMTP can not. False. What is true is that the EDI use of X.400 via X.435 is a very dynamic and exciting use of X.400 and that many entities are trying to use X.435 today. Even though EDI definitions were only recently made for (SMTP's) MIME, a surprising number of entities are already trying to use that technology for EDI. 5) X.400 can more flexibly carry diverse message components than SMTP. True. However, SMTP with MIME has equivalent or superior message flexibility characteristics than X.400 as was previously explained. 6) X.400 is a better Email backbone technology than SMTP. Both approaches have been successfully deployed by Fortune 100 companies. A key issue is whether one anticipates that X.400 or SMTP traffic will predominate. The explicit goal is to minimize the number of message conversions. 7) X.400 gives you receipt notification while SMTP does not. Both approaches have receipt notification but they approach it differently. SMTP requires the remote entity to explicitly enable this capability for it to work. The recent SMTP Notary work will enable SMTP have the same basic receipt notification approach as X.400. 8) X.400 is an International Standard with is officially sanctioned by the world's governments. True. However, SMTP is also an international standard which is more widely used by the world's governments than is X.400. 9) Personal Computer and LAN-based Email systems have defined X.400 to be their strategic direction. This was historically true and may still be true in part. However, as the Internet and the Web have "taken off" in popularity, most/all of these vendors have re-evaluated this direction. Most/all now support both X.400 and SMTP/MIME as their strategic directions. 10) The Electronic Messaging Association (EMA) is defining rich calendaring and scheduling services which rely upon X.400. These services are generally targeted to protocol-independent APIs. 11) Other standards bodies (e.g., X/Open, EMA, XAPIA) refer to X.400 but not to SMTP. The EMA refers to Internet technologies. Regardless, the products eminating from these bodies must confront existing market realities including the current importance of the Internet and TCP/IP. 12) The US Federal Government and its allies are replacing AUTODIN with an X.400-based service. True. AUTODIN is the government's secure command-to-command telex-based service which is being replaced by the X.400-based Defense Messaging System (DMS). Alterations to X.400 were made by DMS (e.g., DMS' P772 replacing P2 for secure messages) making it not directly interoperable with traditional X.400 implementations. DMS comes with manditory SMTP-to- DMS message conversion capabilities. Perhaps more importantly, current US military workstation procurements (e.g., TAC4) manditorily require SMTP, MIME, and PEM to be part of the basic offering. X.400 is an optional capability within these procurements costing extra money to purchase. From owner-Big-Internet@munnari.OZ.AU Thu May 18 13:34:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25291; Thu, 18 May 1995 13:34:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA05074; Thu, 18 May 1995 13:32:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA05057; Thu, 18 May 1995 13:20:30 +1000 From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Received: from clix.aarnet.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24513; Thu, 18 May 1995 13:20:20 +1000 (from Jeff.Latimer@FINANCE.ausgovfinance.telememo.au) X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 18 May 1995 13:16:47 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Thu, 18 May 1995 13:19:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Thu, 18 May 1995 13:19:44 +1000 Date: Thu, 18 May 1995 13:19:44 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: Big-Internet@munnari.OZ.AU X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL May 18 13:19:43 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 431913180595 Alternate-Recipient: Allowed Message-Id: <431913180595*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: Big-Internet@munnari.OZ.AU (Non Receipt Notification Requested) Subject: Re: SMTP versus X.400 results Precedence: bulk I read Eric's paper with interest and can see that the conclusions are well drawn. I am interested futures of the technologies given the Microsoft move to, reportedly, deploy a native X.400 implementation in Microsoft Exchange. If this is the case, will that have an effect on the deployment and the development rate of X.400? JTC1 SC6 has recently ratified RFC1006 as a valid transport mechanism for OSI applications which sort of makes OSI application Internet applications. (Don't shoot me for saying it) but does this combined move strengthen the presence of X.400? Jeff From owner-Big-Internet@munnari.OZ.AU Thu May 18 13:53:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26102; Thu, 18 May 1995 13:53:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA05111; Thu, 18 May 1995 13:52:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA05105; Thu, 18 May 1995 13:51:56 +1000 Received: from mail.mel.aone.net.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26042; Thu, 18 May 1995 13:51:52 +1000 (from ggm@ipx.bne.aone.net.au) Received: from ipx.bne.aone.net.au (ipx.office.bne.aone.net.au [203.12.179.65]) by mail.mel.aone.net.au (8.6.11/8.6.11) with ESMTP id NAA14671; Thu, 18 May 1995 13:51:47 +1000 Received: from localhost (ggm@localhost [127.0.0.1]) by ipx.bne.aone.net.au (8.6.9/8.6.12) with SMTP id NAA24708; Thu, 18 May 1995 13:51:33 +1000 X-Authentication-Warning: ipx.bne.aone.net.au: Host localhost didn't use HELO protocol To: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Cc: Big-Internet@munnari.OZ.AU (Non Receipt Notification Requested) Subject: Re: SMTP versus X.400 results In-Reply-To: Your message of "Thu, 18 May 1995 13:19:44 +1000." <431913180595*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <24701.800769091.1@ipx.bne.aone.net.au> Date: Thu, 18 May 1995 13:51:31 +1000 Message-Id: <24703.800769091@ipx.bne.aone.net.au> From: George Michaelson Precedence: bulk JTC1 SC6 has recently ratified RFC1006 as a valid transport mechanism for OSI applications which sort of makes OSI application Internet applications. Once again paperwork lagging behind reality & market forces, all the major X.400 shippers having supplied RFC1006 since inception & release in ISODE... Telstra should be doing this themselves instead of via the UQ gateway before 1996. (Don't shoot me for saying it) but does this combined move strengthen the presence of X.400? I think deployment of other infrastructure (bodypart registries, X.500/509 PEM key certification, key allocation/registration framework, MIME registry) and release of free-to-desktop code is more important than the carrier encoding mentality. I don't have a good feel for which is ahead. Web == RSA == RC40 keys worldwide maybe that is some pressure which puts things into the hands of punters and makes them use (semi)secured mail. mime-encoded contents == trivial drag/drop binary xfer in mail of PC/Mac contents, and its used in Web as well so once again, given desktop penetration of SMTP and Web, maybe MIME has already won. -George Email: ggm@labtam.oz.au | Labtam Australia Pty./Ltd. Phone: +61 7 250 1523 | 9th Floor, K-Tower, cnr Wickham & Ballow Streets Fax: +61 7 250 1585 | Fortitude Valley, Brisbane, Qld 4006, Australia From owner-Big-Internet@munnari.OZ.AU Thu May 18 21:00:56 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14899; Thu, 18 May 1995 21:00:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA20419 Thu, 18 May 1995 20:37:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA05474; Thu, 18 May 1995 20:32:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA05468; Thu, 18 May 1995 20:27:39 +1000 Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13975; Thu, 18 May 1995 20:27:32 +1000 (from Christian.Huitema@sophia.inria.fr) Received: by mitsou.inria.fr (8.6.12/8.6.12) id MAA01588; Thu, 18 May 1995 12:23:01 +0200 Message-Id: <199505181023.MAA01588@mitsou.inria.fr> To: Eric Fleischman Cc: big-internet@munnari.OZ.AU Subject: Re: SMTP versus X.400 results In-Reply-To: Your message of "Wed, 17 May 1995 16:03:50 PDT." <9505172303.AA07145@atc.boeing.com> Date: Thu, 18 May 1995 12:23:00 +0200 From: Christian Huitema Precedence: bulk Eric, A very well done report. Congratulations. One small nit, though: > INRIA is a French company which acts as a consultant to the French government. INRIA is actually a public research institution of France, responding to both the ministry of Industry and the ministry of Research. There are very few similar organisations in the US; you may think of us as something like a French NASA, except we research on computer science, not rocket science. Also, we only have 1500 employees. You may get a presentation of INRIA on the web (http://www.inria.fr). Christian Huitema From owner-Big-Internet@munnari.OZ.AU Fri May 19 06:16:29 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09464; Fri, 19 May 1995 06:16:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA06077; Fri, 19 May 1995 06:12:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA06049; Fri, 19 May 1995 05:53:23 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08292; Fri, 19 May 1995 05:53:19 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA03174; Thu, 18 May 95 13:01:09 -0700 Date: Thu, 18 May 95 13:01:09 -0700 From: Eric Fleischman Message-Id: <9505182001.AA03174@atc.boeing.com> To: Big-Internet@munnari.OZ.AU, Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Subject: Re: SMTP versus X.400 results Cc: ericf@munnari.OZ.AU Precedence: bulk Dear Jeff, The view from my knot-hole agrees with your statements. I believe that the support of Microsoft and other PC/LAN Email vendors for X.400 does significantly change the Email equation. For one thing, it makes it much more conceivable/possible to have native X.400 User Agents than was historically the case. Until now, should one have received an X.400 message, there was a high probability that it was actually translated into X.400 from some other system. For example, Boeing has historically had extensive X.400-based External communications without having even a single native X.400 "end user" within the company. This may now change due to the products of the PC/LAN Email vendors. On the other hand, these vendors are "market wise" and have not "risked the farm" by supporting X.400. Rather, they have "hedged their bets" by supporting SMTP/MIME as well as their traditional proprietary protocols within their products. The result is that end users are theoretically given products which do not contain the any given protocol allegiance. Thus, we end users can theoretically do that which make the best sense in our environments. This represents a very different market scenario for these vendors than was the case for the end systems vendors in the late 1980s and early 1990s who generally lost significant sums of money by developing OSI technologies. The difference is that these new Email products are theoretically "protocol independent" so their developers should simply not care about the relative success of the underlying protocols. This, by the way, is the market advantage of building "middleware" products. In the former pre-middleware scenario, the products were completely protocol dependent and thus were completely tied to the success of the protocol. The implication of RFC 1006 is that there is now an additional alternative for the X.400 user. They can now use the Internet (and, more importantly, our own internal corporate networks which also increasingly tend to be TCP/IP-dominant) in addition to the traditional choices of using VANs, "native X.25" (e.g., PRMD-PRMD), or private links for one's X.400 traffic. Companies will doubtlessly be interested in the pricing implications of each of the alternatives. However, the end-users' "bottom line" really is the following: 1) Communicators must have identical protocols to communicate -- either via natively using the same protocols or else by having intermediate "protocol translators". "Translators" are bottlenecks, lose information, are single-points of failure, scale poorly, and are expensive to maintain and support. 2) There is a significant cost differential between SMTP/MIME and X.400 affecting product purchase, internal infrastructural support, and external communications. This differential affects several business dimensions including ongoing network support and maintenance overheads. 3) There is a feature differential between the two approaches. This may be particularly problematic if all of your communicators do not use the same versions of the same software package. Simply put, diversity costs and we large users fight that cost by trying to deploy standards. But not all standards are created equal. Sincerely yours, --Eric Fleischman >From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au >Date: Thu, 18 May 1995 13:19:44 +1000 >To: Big-Internet@munnari.OZ.AU (Non Receipt Notification Requested) >Subject: Re: SMTP versus X.400 results > >I read Eric's paper with interest and can see that the conclusions are well >drawn. I am interested futures of the technologies given the Microsoft >move to, reportedly, deploy a native X.400 implementation in Microsoft >Exchange. If this is the case, will that have an effect on the deployment >and the development rate of X.400? > >JTC1 SC6 has recently ratified RFC1006 as a valid transport mechanism for >OSI applications which sort of makes OSI application Internet applications. >(Don't shoot me for saying it) but does this combined move strengthen the >presence of X.400? > >Jeff From owner-Big-Internet@munnari.OZ.AU Sun May 21 08:46:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04432; Sun, 21 May 1995 08:46:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA08702; Sun, 21 May 1995 08:33:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA08696; Sun, 21 May 1995 08:25:58 +1000 Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03809; Sun, 21 May 1995 08:25:52 +1000 (from medin@nsipo.nasa.gov) Received: from localhost.arc.nasa.gov by dscs.arc.nasa.gov (8.6.11/1.5T) id PAA16560; Sat, 20 May 1995 15:25:50 -0700 Message-Id: <199505202225.PAA16560@dscs.arc.nasa.gov> To: Eric Fleischman Cc: Big-Internet@munnari.OZ.AU, Jeff.Latimer@FINANCE.ausgovfinance.telememo.au, ericf@munnari.OZ.AU Subject: Re: SMTP versus X.400 results In-Reply-To: Your message of "Thu, 18 May 95 13:01:09 PDT." <9505182001.AA03174@atc.boeing.com> Date: Sat, 20 May 95 15:25:49 -0700 From: "Milo S. Medin" (NASA Ames Research Center) Precedence: bulk Eric, as someone who has real world experience with both X.400 and SMTP/MIME, let me chime in here with what I hope to be a good set of comments. 1) X.400 message routing is basically static without a well populated X.500 directory service. While NASA has such a service online, and operational (see the www.nasa.gov home page), few people do, resorting is static routing of email. This is a mess, and is simply unacceptable for anyone who takes email seriously. 2) I think you are dreaming if you are expecting to see X.400 native clients in PC mail systems. You'll see gateways all right, just as you see SMTP/MIME gateways in place today. But it's not in the PC mail system vendor's best interest to support any sort of direct SMTP/MIME or X.400 interface in the UA, because it makes it very much easier to replace their product with someone else's. Noone wants to be selling a commodity product. By maintaining a proprietary internal mail UA to server/gateway architecture, they trap you into sticking with their product line, because changing the UA is such a pain. 3) Because most X.400 systems today support VAN connected email systems, they are rarely designed with good performance in mind. Most if not all the X.400 servers I am familiar with would crumble in the face of what a major SMTP relay site has to deal with today. 4) The DoD DMS procurement will almost certainly end up supporting SMTP based systems as well as X.400 based systems, and history has shown that whenever this happens, the SMTP based vendors walk away with the bulk of the "seats". Don't expect to see an X.400 requirement necessarily turn into a large managed deployment of X.400 infrastructure. 5) While X.400 in theory supports a lot of functionality that the SMTP/MIME environment doesn't, a lot of this typically hasn't been implemented in products. This makes a paper comparison of features somewhat less than useful than a survey of actual products shipping. Nonethess, a few years ago, when NASA was working it's core email strategy, we decided to support BOTH x.400 and SMTP/MIME as transports. That initiative also created the first operational X.500 infrastructure in the Gov't that actually has all the staff at all the NASA field centers loaded into it and updated. It didn't deal with attachments however. Phase II, which is in progress now, will support full multipart enclosures, and also a support infrastructure for all the email servers in the agency, and it will almost certainly be based on an SMTP/MIME core, with X.400 relagated a gateway to public email systems where PTT's can control what people use for message transport. We really gave X.400 a chance to prove itself, but in the end, the marketplace and our own experience pushed us to SMTP/MIME. I predict that Phase III will focus on using the X.500 infrastructure to support X.509 crypto certificates, with their integration into MOSS based UA and gateway system, to support both privacy and authentication. I'm actually quite dissappointed that the standards have progressed so slowly here. Now, you can argue that we're making this sort of decision prematurely, and that affordable and robust X.400 products are just around the corner. But this what OSI proponents have said for some time. If I were making a decision on an enterprise wide mail system, I'd go with SMTP/MIME. It's far from perfect, but it's marketplace dominance provides strong incentives for vendors to help fix it's shortcomings to differentiate themselves from others. Thanks, Milo From owner-Big-Internet@munnari.OZ.AU Fri May 26 08:55:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15166; Fri, 26 May 1995 08:55:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA14882; Fri, 26 May 1995 08:55:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA14865; Fri, 26 May 1995 08:48:24 +1000 Received: from seismo.CSS.GOV by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15007; Fri, 26 May 1995 08:48:15 +1000 (from LEBECK_SUE@Tandem.COM) Received: from comm.Tandem.COM (comm.cpd.tandem.com) by seismo.CSS.GOV (4.1/SMI-4.1) id AA00508; Thu, 25 May 95 18:47:55 EDT Received: by comm.Tandem.COM (4.13/4.5) id AA4409; 25 May 95 15:47:27 -0700 Date: 25 May 95 14:40:00 -0700 From: LEBECK_SUE@tandem.com Message-Id: <199505251547.AA4409@comm.Tandem.COM> To: big-internet%munnari.OZ.AU@seismo.CSS.GOV Cc: ericf@atc.boeing.com Subject: Thoughts re: "SMTP vs X.400 results" Precedence: bulk I thought the following memo may be of interest. I sent it to an internal dlist, in reaction to discussion generated by Eric Fleischman's memo dated May 17 on the topic of SMTP vs. X.400. I was encouraged to share it, so here it is. Best, Sue Lebeck, Tandem Computers (p.s. I'm conveniently going on vacation, so while replies are welcome, they will be ignored for two weeks:-)) Best, Sue ------------ TEXT ATTACHMENT -------- SENT 05-25-95 FROM LEBECK_SUE Bruce, all: Certainly the support of SMTP is important in any corporate environment, and our plans going forward will be to further increase our support of SMTP. In considering the problem space of "X.400 vs. SMTP", the attached memo certainly is relevant and interesting. However, I strongly advise anyone to read it with caution, keeping several important considerations in mind: - Firstly, when the author says he does not speak officially for Boeing, believe him. I visited recently with several key members of the team which is building Boeing's internal network; they are actually rolling out an X.400 corporate backbone (tho' they also support SMTP gateways). Their reasons for selecting X.400 for their primary backbone technology are several, but two are key: - Government-related mandates - Microsoft's "Exchange" messaging server uses X.400 as its backbone technology Interestingly, the May 15 issue of Communications Weeks shows a pie chart on its front page which indicates that 43% of their polled audience was looking to buy X.400-based e-mail in the short term; 19% was looking to buy SMTP/MIME. - While many valid points are made in the memo, many erroneous arguments are also offered. The author's biases do indeed show up. A sampling of the erroneous arguments: * the author suggests pictorially that the X.400 architecture is complex, while the SMTP architecture is simple. The X.400 picture offered includes many optional components. In most cases, analogous optional components exist for SMTP, but are omitted from the SMTP picture. * X.400 is described as "store and forward", while SMTP is described as "point to point". In fact, both technologies accommodate both store and forward and point to point. The value of store and forward is that, while it doesn't require intermediate hops, it allows for them where point-to-point network connectivity is not available. The TCP/IP based Internet is a fairly fully connected network. Both SMTP and X.400 can be run over it. X.400 can operate point-to-point over fully connected networks; it just allows for the case where this isn't available; this is often the case in the real world. SMTP must also deal with the need to do store-and-forward; it does so by relying on "MX" records in the DNS database, and, in rare cases, by using source routing. Most corporate networks actually rely on the store-and-forward capability as part of their "firewall" implementation. * The author says that SMTP is the only standard for mail over the Internet. RFC1006 is an Internet standard for running X.400 (and other OSI applications) over the Internet. * SMTP is very simple, which allows for easy deployability and accessibility. This does not come for free; SMTP is so accessible, that, if I sit my 4-year down to any computer attached via TCP to a server running SMTP, she can submit a message to the SMTP server pretending she is whoever she wishes to claim. This makes SMTP unsuitable for carrying any critical authorship-sensitive messages, unless PEM or PGP is also available for digitally signing the message. The author's suggestion that it is easier to crack an X.400 network than an SMTP network is significantly, if not wholly, unsubstantiated. I in no way mean to suggest that SMTP/MIME is not important. It clearly is important, and its importance is on the rise. But the debate between X.400 and SMTP/MIME is not over; meanwhile, vendors must support both, and many/most enterprises will want to run both. Hope this is helpful, Best, Sue From owner-Big-Internet@munnari.OZ.AU Fri May 26 09:15:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15916; Fri, 26 May 1995 09:15:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA14923; Fri, 26 May 1995 09:15:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA14917; Fri, 26 May 1995 09:14:05 +1000 Received: from mail.mel.aone.net.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15817; Fri, 26 May 1995 09:13:56 +1000 (from ggm@ipx.office.bne.aone.net.au) Received: from ipx.office.bne.aone.net.au (ipx.office.bne.aone.net.au [203.12.179.65]) by mail.mel.aone.net.au (8.6.11/8.6.11) with ESMTP id JAA28836; Fri, 26 May 1995 09:13:46 +1000 Received: from ipx.office.bne.aone.net.au (ggm@ipx.office.bne.aone.net.au [203.12.179.65]) by ipx.office.bne.aone.net.au (8.6.11/8.6.12) with ESMTP id JAA06290; Fri, 26 May 1995 09:13:29 +1000 To: LEBECK_SUE@tandem.com Cc: big-internet@munnari.OZ.AU, ericf@atc.boeing.com Subject: Re: Thoughts re: "SMTP vs X.400 results" In-Reply-To: Your message of "25 May 1995 14:40:00 MST." <199505251547.AA4409@comm.Tandem.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <6283.801443607.1@ipx.office.bne.aone.net.au> Date: Fri, 26 May 1995 09:13:28 +1000 Message-Id: <6285.801443608@ipx.office.bne.aone.net.au> From: George Michaelson Precedence: bulk * SMTP is very simple, which allows for easy deployability and accessibility. This does not come for free; SMTP is so accessible, that, if I sit my 4-year down to any computer attached via TCP to a server running SMTP, she can submit a message to the SMTP server pretending she is whoever she wishes to claim. Yep. Just like the telephone network (modulo CID and voice-masking) in fact doesn't John Grisham have the ubiquitous 10 year old order $400 of pizza by phone in a revenge attack on police in "The Client" ? This makes SMTP unsuitable for carrying any critical authorship-sensitive messages, unless PEM or PGP is also available for digitally signing the message. But since PEM or PGP *IS* also available for digitally signing the message, this is a null statement. I am not aware of a significant platform for which X.400 is available, including X.509 and other authentication framework, for which SMTP/PGP/PEM is not also viable. I would in fact assert there are probably platforms for which X.400 is NOT available, dispite the availability of SMTP/PGP/PEM. The author's suggestion that it is easier to crack an X.400 network than an SMTP network is significantly, if not wholly, unsubstantiated. I too find this suggestion implausible. I asked a mailing list about 18 months ago to provide documented instances of X.25 source address spoofing from telco provider based X.25, and by extension show a lack of trust in X.400 MTA-MTA bilateral exchanges using telco infrastructure. I think that even allowing for differences in deployment numbers, the lack of evidence is compelling: X.25/X.400 is not undergoing significant fraud in terms of sender identity within its own protocol fabric. IPv4/SMTP is notable in (as deployed) being open to this threat, which is precicely why deploying PEM/PGP/Keydist is so vital to IPv6. Its also notable that forged SMTP is probably the major distraction preventing existing X.400/EDI from jumping ship right now. The pricepoints for telco lockins to use wierd and wonderful methods of paperless exchange are nothing like as good as MIME/SMTP... (I speak from experience here, having broached precicely this issue with Telecom Australia with respect to "tradernet") But the debate between X.400 and SMTP/MIME is not over; meanwhile, vendors must support both, and many/most enterprises will want to run both. Most Telco's seem to want it (like the billpoints) Most providers should consider it. (need the gatewaying) Most enterprises should learn about it. (and make the choices/hassle providers) Most users should avoid it. (don't need the hassle) -George From owner-Big-Internet@munnari.OZ.AU Fri May 26 10:55:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20021; Fri, 26 May 1995 10:55:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA15030; Fri, 26 May 1995 10:55:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA15013; Fri, 26 May 1995 10:53:13 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19936; Fri, 26 May 1995 10:53:08 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA01459; Thu, 25 May 95 18:01:05 -0700 Date: Thu, 25 May 95 18:01:05 -0700 From: Eric Fleischman Message-Id: <9505260101.AA01459@atc.boeing.com> To: LEBECK_SUE@tandem.com, big-internet@munnari.OZ.AU Subject: Re: Thoughts re: "SMTP vs X.400 results" Precedence: bulk Dear Sue, I don't object to being corrected when I make a misstatement. I definitely appreciate being corrected when I am in error. However, your statements that I made the following claims are not accurate: > > The TCP/IP based Internet is a fairly fully connected > network. Both SMTP and X.400 can be run over it. I did not address this point at any time in my descriptions. > * The author says that SMTP is the only standard for mail > over the Internet. RFC1006 is an Internet standard for > running X.400 (and other OSI applications) over the Internet. I did not say this. What I said is that SMTP is the Internet's Email standard. > The author's suggestion that it is easier to crack an > X.400 network than an SMTP network is significantly, > if not wholly, unsubstantiated. I never said such a statement. I never suggested such a statement. I never implied such a statement. The statement is simply absurd. As I tried to say in my introduction, I have found that the pursuit of truthful "facts and data" in regards to comparing X.400 and Internet Mail to be an ellusive and difficult quest -- a quest which I have diligently pursued for nearly a year. My goal in my posting was to fulfill my obligations to this list by posting my conclusions. This was done out of a profound gratitude to this list since it has been a spring-board for much of my investigation. It does not surprise me that some of my statements were not entirely accurate despite my best efforts to the contrary. As I said in the introduction, I am a finite and limited person who does make mistakes. That is why I value the interplay of information on this list as a method to ultimately learn the Truth. It also does not surprise me that some will dislike what I concluded due to a variety of reasons. However, it does sadden me greatly that not everyone seems to eagerly seek to know the Truth -- especially on those rare events when some resort to "argumentum ad hominem" arguments. I am especially saddened when ridiculous statements which I have never made are publically attributed to me. By saying this, I do not wish to imply that you are guilty of purposefully making such statements since you may have merely misread (or not carefully read) my statements. Such is quite understandable, especially in view of the length of my original submission. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Fri May 26 12:16:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23178; Fri, 26 May 1995 12:16:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA15114; Fri, 26 May 1995 12:15:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA15097; Fri, 26 May 1995 12:02:01 +1000 Received: from seismo.CSS.GOV by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22681; Fri, 26 May 1995 12:01:40 +1000 (from valdis@black-ice.cc.vt.edu) Received: from black-ice.cc.vt.edu by seismo.CSS.GOV (4.1/SMI-4.1) id AA03844; Thu, 25 May 95 22:01:32 EDT Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.6.11/8.6.10) with ESMTP id WAA19436; Thu, 25 May 1995 22:01:16 -0400 Message-Id: <199505260201.WAA19436@black-ice.cc.vt.edu> To: LEBECK_SUE@tandem.com Cc: big-internet%munnari.OZ.AU@seismo.CSS.GOV, ericf@atc.boeing.com Subject: Re: Thoughts re: "SMTP vs X.400 results" In-Reply-To: Your message of "25 May 1995 14:40:00 PDT." <199505251547.AA4409@comm.Tandem.COM> From: Valdis.Kletnieks@vt.edu Date: Thu, 25 May 1995 22:01:15 -0400 Precedence: bulk On 25 May 1995 14:40:00 PDT, LEBECK_SUE@tandem.com said: > Interestingly, the May 15 issue of Communications Weeks > shows a pie chart on its front page which indicates that > 43% of their polled audience was looking to buy X.400-based > e-mail in the short term; 19% was looking to buy SMTP/MIME. This statement is in and of itself misleading, and shows the need for care in interpreting statistics. Remember that you essentially have to buy X.400 for *every* machine you wish to deploy it on. However, SMTP and Mime are already bundled into most Unix vendor's base products, with no additional support needed. Also, there is no discussion of *number of seats* here. It could very well be that 43% of their audience is buying X.400 - but it could very well also be that most of these 43% are buying it only to interconnect with some legacy system that doesn't support SMTP. It could be XYZ Corp, a Fortune 100 company, with 20,000 deployed SMTP workstations already, no plans to buy more SMTP products since they already site-licensed for those platforms that it doesn't come bundled in - but they need to buy an X.400 package for those 5 machines in the one department... Valdis Kletnieks Computer Systems Engineer Virginia Tech From owner-Big-Internet@munnari.OZ.AU Fri May 26 14:15:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28165; Fri, 26 May 1995 14:15:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA15238; Fri, 26 May 1995 14:15:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA15221; Fri, 26 May 1995 14:07:31 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27811; Fri, 26 May 1995 14:07:27 +1000 (from dcrocker@mordor.stanford.edu) Received: from [204.118.88.27] (dial-cup1-15.iway.aimnet.com [204.118.88.15]) by Mordor.Stanford.EDU (8.6.11/8.6.6) with SMTP id VAA19953; Thu, 25 May 1995 21:07:37 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 25 May 1995 21:07:10 -0700 To: LEBECK_SUE@tandem.com From: Dave Crocker Subject: Re: Thoughts re: "SMTP vs X.400 results" Cc: Big-Internet@munnari.OZ.AU Precedence: bulk Sue, et al, At 2:40 PM 5/25/95, LEBECK_SUE@tandem.com wrote: >I thought the following memo may be of interest. indeed it is. thank you for forwarding it... with luck, we might get some real discussion going, but the tendency with a "vs." subject line of course is to get defensive and/or offensive. Mayhaps we can try to look, instead, at legitimate differences and -- better still -- at open requirements? > officially for Boeing, believe him. I visited recently > with several key members of the team which is building Boeing's > internal network; they are actually rolling out an X.400 most corporations are citing plans to implement X.400. If one looks at previous Internet-vs-OSI battles, a significant difference is that this time there is real and meaningful deployment. (There has ALWAYS been corporate commitment, but now there's real running code and running users. And after 15 years of development for X.400, one would hope that such was the case.) The question, however, is whether such corporate commitment necessarily dictates the future. Have we heard such assurances before? Are they always good predictors? usually? ever? Are there other forces at work which might (or will) create a different outcome than guaranteed by these assurances. And if so, why? > arguments are also offered. The author's biases do indeed show up. A real difficulty in responding to notes such as Eric's is to be very careful in the language. Quite frankly, I don't think any of Eric's comments reflect "bias". That doesn't mean all the statements are accurate (because not all of them are) but I've watched him enough in the last couple of years to believe pretty firmly that he tries quite hard to find and make accurate statements. > In most cases, analogous optional components exist for SMTP, > but are omitted from the SMTP picture. X.400 and Internet have the same architecture. Don't let anyone tell you otherwise. there are massive differences in the implementation choices among the more popular products, but that does not change the architecture. (Glad to debate this with anyone who cares to, but please note that the X.400 model was developed during work that I and other Internet email folks contributed to, a very long time ago.) > * X.400 is described as "store and forward", while SMTP is both are store-and-forward models, as you observe. I'm adding my own comment, here, because this assertion of difference is frequently made. It is not correct. > X.400 can operate point-to-point can, yes, but the ADMD/PRMD addressing constructs intrude pretty heavily in the real world of X.400. There are retro-fitted modifications to the use of those constructs, but my understanding is that they are not yet fully accepted or deployed globally. (We ARE talking about a global messaging service aren't we? That DOES mean universal behaviors, doesn't it?) > Most corporate networks actually rely on the store-and-forward > capability as part of their "firewall" implementation. exactly correct. > over the Internet. RFC1006 is an Internet standard for > running X.400 (and other OSI applications) over the Internet. not a helpful observation or assertion. RFC1006 refers to a transport service encapsulation scheme, not email. The fact that RFC1006 is a standard does not mean that all of its client services, such as X.400, are therefore Internet standards. Having said that, I'll note that the Internet and the IETF has done rather a lot to make X.400 viable and there certainly are quite a few standards-track specifications pertaining to the X.400 world. Having said THAT, I'll note that standards labels, even when given by such a lofty and successful body as the IETF, are irrelevant. What matters is use. How much native X.400 traffic is there with clients? How much native Internet traffic is there? How much "backbone" X.400 traffic? Internet? How much "gateway" X.400 (i.e., interconnect between organizations)? How much Internet? When talking about "how much", it is quite helpful to distinguish number of nodes, or the like, versus amount of traffic. Personally, I find traffic analysis far more useful than software implementation counting. It goes to the heart of 'use' versus 'availability'. > she can submit a message to the SMTP server pretending > she is whoever she wishes to claim. > This makes SMTP unsuitable for carrying any > critical authorship-sensitive messages, unless PEM or > PGP is also available for digitally signing the message. sigh. Now we get into a very sensitive area of debate. It is made particularly sensitive because most of us do not know enough about security to debate the issue well. And here we have an example of the problem: X.400 and SMTP are both spoofable. You seem to be saying that the complexity of X.400 better security than SMTPRFC822/MIME, but then you are arguing "security through obscurity". In the security world, there is a synonym for "security through obscurity". It is: "none". The only reasons that the breakin rate for Internet mail is higher than for X.400 are exposure and use. More people have access to it and more people use it. Build up similar numbers for X.400 as have existed for some years with Internet mail and you will see the same rate of compromise. There is one significant weakness to my assertion: It is true that some of the Internet email software in popular use was not designed with a specific eye towards safety. That is a matter of implementation choice and not protocol service details. If/when X.400 software gets equivalent use, it will be interesting to see how it hold up under similar efforts at compromise. To repeat: Both X.400 and Internet mail have the same level of basic security with respect to authentication and privacy: none. >meanwhile, vendors must support both, and many/most enterprises alas, this does seem to be a correct assessment, in my opinion. Would that it were otherwise and exactly one set of protocols dominated. But this leads to a question I'll ask the community: We can keep thrashing around and let things continue to toddle along or we can try to understand the critical deficiencies in each set and ask what is needed to make them adequate. What would it take to make X.400 completely deployable, sufficient to cause mass use quickly for the FULL range of messaging styles of Internet users? Equally we should ask: What would it take to accomplish this for SMTP/RFC822/MIME mail? d/ -------------------- Dave Crocker Brandenburg Consulting +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 page: +1 408 581 1174 USA email: dcrocker@aimnet.com From owner-Big-Internet@munnari.OZ.AU Fri May 26 23:15:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18286; Fri, 26 May 1995 23:15:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA15717; Fri, 26 May 1995 23:15:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA15700; Fri, 26 May 1995 23:09:36 +1000 Received: from seismo.CSS.GOV by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18138; Fri, 26 May 1995 23:09:33 +1000 (from pvm@ISI.EDU) Received: from zephyr.isi.edu by seismo.CSS.GOV (4.1/SMI-4.1) id AA03332; Fri, 26 May 95 09:09:23 EDT Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-17) id ; Fri, 26 May 1995 06:09:17 -0700 Message-Id: <199505261309.AA16378@zephyr.isi.edu> To: Valdis.Kletnieks@vt.edu Cc: LEBECK_SUE@tandem.com, big-internet%munnari.OZ.AU@seismo.CSS.GOV, ericf@atc.boeing.com Reply-To: pvm@isi.edu Subject: Re: Making contact with X.400 world In-Reply-To: Your message of Thu, 25 May 1995 22:01:15 -0400. <199505260201.WAA19436@black-ice.cc.vt.edu> Date: Fri, 26 May 95 06:09:16 PDT From: Paul Mockapetris Precedence: bulk As an internet person, I don't see much of an X.400 world in my day to day work. Like Eric, I suspect that internet people don't necessarily know the X.400 culture, and I assume the reverse applies. Bizzare things happen. I go to an ANSI meeting, and the meeting decides that X.400 should be THE standard mail system. OK, cool. The attendance sheet for the meeting has a spot for email address. 60-70% of the people there have them. All are internet-style. So my question is: How big is the X.400 world? How many organizations are connected? How many hosts? How many users? Are there separate islands? Is there the equivalent of a DNS survey for them? paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292 From owner-Big-Internet@munnari.OZ.AU Fri May 26 23:42:09 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19268; Fri, 26 May 1995 23:42:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA20684 Fri, 26 May 1995 23:41:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA15754; Fri, 26 May 1995 23:35:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA15748; Fri, 26 May 1995 23:34:52 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19030; Fri, 26 May 1995 23:34:39 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id JAA22540 for ; Fri, 26 May 1995 09:34:30 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id JAA09724 for ; Fri, 26 May 1995 09:50:56 -0400 Received: from bobsgrid.is.chrysler.com by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA01149; Fri, 26 May 95 09:39:04 EDT Message-Id: <9505261339.AA01149@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 May 1995 09:34:22 -0400 To: Big-Internet@munnari.OZ.AU From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: SMTP, X.400, TCP/IP, and the AIAG Precedence: bulk The Automotive Industry Action Group (AIAG) has specified TCP/IP as the communication protocol for all Trading Partner communications. This was announced via a white paper published last September by the AIAG (JED-1). The is now work in progress to make this TCP/IP network happen this year. I cannot elaborate more on it for about one month. The first applications on this network will be Interactive CAD and CAD file transfer. EMail will follow quickly but EDI will lag considerably (major converstion effort). The TCP/IP infrastructure task team is also the CAD team. There are separate teams for EMail and EDI. The EMail group is almost finished with their 'Recommended Business Practice for Electronic Mail'. This document specifies both X.400 and SMTP as mail systems that can be used for Trading Partner communications. An important point here about the X.400 is the desire by most Trading Partners to only need one communication pathway, will drive any X.400 implementation to IP based. I will come back to this point later. The EDI team will be reviewing the current general statement that EDI will move from 3780 to X.435. The auto industry is already doing various forms of interactive EDI over those 3780 links, with turn-around times for transaction sets measured in seconds (well within 60 of them :) ). Chrysler, the smallest of the OEM's does around 500,000 EDI transaction sets PER DAY. Store and forward EDI systems will only suit a small subset of the EDI transaction sets. So care will be given to insure that whatever method is chosen for EDI will support these business realities. Security will be a real concern for this venture. Industrial espionage is a business reality. Everything is suspect. In this light, X.400 over IP has to be viewed as open to assault as SMTP (today's X.400 security is the security of the systems it runs on (e.g. MVS with RACF for ADVANTIS)). X.400 on open systems will be found to have no cloths, just like SMTP and only digital signatures and encryption will offer any assurance. Stay tuned for more developments. This will be a large network. Estamates range from 10,000 to 100,000 trading partners. Will it be a private IP or a virtual IP network? Only technology and FUD can tell. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Sat May 27 01:17:35 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23707; Sat, 27 May 1995 01:17:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA15976; Sat, 27 May 1995 01:15:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA15959; Sat, 27 May 1995 01:07:05 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23215; Sat, 27 May 1995 01:06:44 +1000 (from aiken@es.net) Received: from seismo.CSS.GOV by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA22365 Sat, 27 May 1995 00:50:01 +1000 (from aiken@es.net) Received: from osi-east.es.net by seismo.CSS.GOV (4.1/SMI-4.1) id AA06888; Fri, 26 May 95 10:47:28 EDT Received: from sas-hp.nersc.gov by osi-east.es.net with ESnet SMTP (PP); Fri, 26 May 1995 07:46:45 -0700 Received: from [198.124.2.67] (bacon-mac.es.net) by sas-hp.nersc.gov with SMTP (1.37.109.16/16.3) id AA054979589; Fri, 26 May 1995 07:46:29 -0700 X-Sender: aiken@sas-sun.nersc.gov Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 May 1995 07:27:04 -0800 To: pvm@ISI.EDU, Valdis.Kletnieks@vt.edu From: aiken@es.net (Robert J. Aiken) Subject: Re: Making contact with X.400 world Cc: LEBECK_SUE@tandem.com, big-internet%munnari.OZ.AU@seismo.CSS.GOV, ericf@atc.boeing.com Precedence: bulk Another issue that clouds the facts is that if an organization has X.400 addresses I would venture to say (based on the X.400 mail systems that I have seen at DOE and elsewhere in GOvs) the majority of those are e-mail dual homed either in transport (ie. they actually have both X.400 and SMTP or MIME UAs and transfer systems) or at least have a gateway (or set of ) that can accept both X.400 and SMTP or MIME mail. Since most people recognize internet mail addresses (at least in US) and not X.400 (or consider it too long or ugly to post as their email address) the majority of the people who have valid email addresses (note I say addresses since the gateway behind may be one or the other) use the internet address. So what people sign on the attendence lists may more importantly reflect the preffered email naming and not the actuall transport (most users really don't care). Therefore any attempts at trying to determine the actual usuage of X.400 vs SMTP needs to break it up into names, preferred WAN transport (X.400, SMTP,..) , and then preffered LAN transport (could be SMTP, X.400, CCMail etc.). Another issue is who is going to use X.400. Well I know that the US DoD's DMS is a morphed version of X.400 (added security ) and that it is expected to be used by NATO. In addition, many factions within the US GOV are using the DMS as their reference model due to need for "business quality" email (ie. receipts, notifictaions, security, signatures, and the like). Now one can argue whether this Thing will fly (with thing either = pig or = a bumblebee) but the THRUST for X.400 in these spheres (and by the way anyone doing BIZ with these folks with need to use the same kind of email) is still strong enough of my .02 bob aiken At 6:09 AM 5/26/95, Paul Mockapetris wrote: >As an internet person, I don't see much of an X.400 world in my day to >day work. Like Eric, I suspect that internet people don't necessarily >know the X.400 culture, and I assume the reverse applies. > >Bizzare things happen. I go to an ANSI meeting, and the meeting >decides that X.400 should be THE standard mail system. OK, cool. The >attendance sheet for the meeting has a spot for email address. 60-70% >of the people there have them. All are internet-style. > >So my question is: How big is the X.400 world? How many >organizations are connected? How many hosts? How many users? Are >there separate islands? > >Is there the equivalent of a DNS survey for them? > >paul > >USC/Information Sciences Institute phone: 310-822-1511 x285 >4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 >90292 Robert J. Aiken, Department of Energy/ Lawrence Livermore Lab 301-903-9960, 301-903-7774 (fax). aiken@es.net "Always drink upstream from the herd" From owner-Big-Internet@munnari.OZ.AU Sat May 27 01:57:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25139; Sat, 27 May 1995 01:57:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA16072; Sat, 27 May 1995 01:55:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA16031; Sat, 27 May 1995 01:38:18 +1000 Received: from seismo.CSS.GOV by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24368; Sat, 27 May 1995 01:38:10 +1000 (from rcallon@BayNetworks.com) Received: from lobster.wellfleet.com by seismo.CSS.GOV (4.1/SMI-4.1) id AA08348; Fri, 26 May 95 11:38:02 EDT Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA27701; Fri, 26 May 95 11:36:33 EDT Received: from cabernet.engeast by BayNetworks.com (4.1/SMI-4.1) id AA10967; Fri, 26 May 95 11:37:57 EDT Date: Fri, 26 May 95 11:37:57 EDT From: rcallon@BayNetworks.com (Ross Callon) Message-Id: <9505261537.AA10967@BayNetworks.com> To: LEBECK_SUE@tandem.com, Valdis.Kletnieks@vt.edu Subject: Re: Thoughts re: "SMTP vs X.400 results" Cc: big-internet%munnari.OZ.AU@seismo.CSS.GOV, ericf@atc.boeing.com Precedence: bulk > On 25 May 1995 14:40:00 PDT, LEBECK_SUE@tandem.com said: > > Interestingly, the May 15 issue of Communications Weeks > > shows a pie chart on its front page which indicates that > > 43% of their polled audience was looking to buy X.400-based > > e-mail in the short term; 19% was looking to buy SMTP/MIME. > > This statement is in and of itself misleading, and shows the need for > care in interpreting statistics. I had a similar reaction to this statistic. My first reaction was "hmm, this means that 19% do not *already* have SMTP operating in their networks". A more useful statistic would be the total of the number of organizations who already have a protocol in use, plus the number planning to add it. I don't understand what is to be gained by having more competing mail standards rather than less. When I go to ATM Forum meetings, IETFs, or back when I used to go to ANSI meetings, when you pass around the attendance list folks provide STMP / DNS names, not X.400 or X.500 names. On the odd case where someone does put down an X.400 or X.500 address, it is not at all clear how one is supposed to send them mail. Rather than argue about which underlying mail protocol to use, how about if we get better User Agents? That is something that it would make sense to spend money on. Ross From owner-Big-Internet@munnari.OZ.AU Sat May 27 02:58:38 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27207; Sat, 27 May 1995 02:58:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA16144; Sat, 27 May 1995 02:55:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA16127; Sat, 27 May 1995 02:51:36 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27003; Sat, 27 May 1995 02:51:32 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id MAA25133 for ; Fri, 26 May 1995 12:51:19 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id NAA10637 for ; Fri, 26 May 1995 13:06:44 -0400 Received: from bobsgrid.is.chrysler.com by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA02643; Fri, 26 May 95 12:54:49 EDT Message-Id: <9505261654.AA02643@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 26 May 1995 12:50:02 -0400 To: big-internet@munnari.OZ.AU From: rgm3@is.chrysler.com (Robert Moskowitz) Subject: Mail on big internets Precedence: bulk In keeping with the spirit of this list, yet continuing this line of thought :) There are two aspects to any mail system, it seems. Transport and Use. X.400 defines both. SMTP is only Transport. In fact in many cases it is only a part of Transport with POP or IMAP finshing up where it left off, so to speak. Use of SMTP has grown independent of SMTP. Mailers abound, and they all mesh very well with SMTP (well those that are native to SMTP, not proprietary gateway beasties). So SMTP has concentrated on delivery over a very large multiconnected internet. X.400, though designed to include both transport and use, and transport over point to point links and an internet, has grown instead to be, for the most part, strickly a point to point backbone. Most UAs are proprietary mail systems with X.400 gateways. Just look at Advantis that uses IBMMail (good old PROFS), GEIS with Quickcomm, and COMPUSERVE with CIS! Lotus Notes will soon let you have your cake and eat it too. LCS will use either its proprietary interserver protocol or X.400 or SMTP. But no other X.400 or SMTP service will directly understand the contents, only LCS. So in a very diverse user community, SMTP may be better suited due to the simplisity of the overall implementation. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Sat May 27 23:35:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06732; Sat, 27 May 1995 23:35:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA17167; Sat, 27 May 1995 23:35:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA17150; Sat, 27 May 1995 23:20:40 +1000 From: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06218; Sat, 27 May 1995 23:20:37 +1000 (from Jeff.Latimer@FINANCE.ausgovfinance.telememo.au) Received: from clix.aarnet.edu.au by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA20215 Sat, 27 May 1995 22:45:33 +1000 (from Jeff.Latimer@FINANCE.ausgovfinance.telememo.au) X400-Received: by mta clix.aarnet.edu.au in /PRMD=OZ.AU/ADMD=TELEMEMO/C=AU/; Relayed; Sat, 27 May 1995 22:39:30 +1000 X400-Received: by /ADMD=telememo/C=au/; Relayed; Sat, 27 May 1995 22:42:00 +1000 X400-Received: by /PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/; Relayed; Sat, 27 May 1995 22:41:18 +1000 Date: Sat, 27 May 1995 22:41:18 +1000 X400-Originator: Jeff.Latimer@FINANCE.ausgovfinance.telememo.au X400-Recipients: Big-Internet@munnari.OZ.AU X400-Mts-Identifier: [/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/;CCMAIL May 27 22:41:18 1995] X400-Content-Type: P2-1984 (2) Content-Identifier: 184122270595 Alternate-Recipient: Allowed Message-Id: <184122270595*/G=Jeff/S=Latimer/O=FINANCE/PRMD=AUSGOVFINANCE/ADMD=TELEMEMO/C=AU/@MHS> To: Big-Internet@munnari.OZ.AU (Non Receipt Notification Requested) Subject: Re[2]: Making contact with X.400 world X-Sender: aiken@sas-sun.nersc.gov Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk >Since most people recognize internet >mail addresses (at least in US) and not X.400 (or consider it too long >or ugly to post as their email address) the majority of the people who have >valid email addresses (note I say addresses since the gateway behind may >be one or the other) use the internet address. So what people sign on the >attendence lists may more importantly reflect the preffered email >naming and not the actuall transport (most users really don't care). When we discuss the addressing conceived in hell we sort of glass over the mythical directory. My vision, cataracts and all, would see a level of abstraction being introduced by directories. Once that is in place then it would be essentially immaterial as the mail transport used. Anyway the argument seems almost, if the X.400 address looked RFC-822 like then X.400 is better than SMTP. I there would be a few holws over that conclusion. I prefer the deeper discussions on real strengths and weaknesses. >>Bizzare things happen. I go to an ANSI meeting, and the meeting >>decides that X.400 should be THE standard mail system. OK, cool. The >>attendance sheet for the meeting has a spot for email address. 60-70% >>of the people there have them. All are internet-style. The interesting thing about standards meetings, in Australia and elsewhere, is that the organisations represented tend to be conservative, tend to have long term plans and tend not to veer to much from the plans even when faced with opposing reality. The interesting question for me is the effect Microsoft Exchange has on the market. Will it justify those conservatives qualities? Regards Jeff Latimer Department of Finance From owner-Big-Internet@munnari.OZ.AU Sun May 28 22:17:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14851; Sun, 28 May 1995 22:17:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA18330; Sun, 28 May 1995 22:15:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18313; Sun, 28 May 1995 21:57:47 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14269; Sun, 28 May 1995 21:57:43 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch id AA20245; Sun, 28 May 1995 13:57:37 +0200 Received: by dxcoms.cern.ch id AA00996; Sun, 28 May 1995 13:57:35 +0200 Message-Id: <9505281157.AA00996@dxcoms.cern.ch> Subject: Re: SMTP versus X.400 results To: Big-Internet@munnari.OZ.AU Date: Sun, 28 May 1995 13:57:34 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <199505202225.PAA16560@dscs.arc.nasa.gov> from "Milo S. Medin" at May 20, 95 03:25:49 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 381 Precedence: bulk Milo, > > Now, you can argue that we're making this sort of decision prematurely, > and that affordable and robust X.400 products are just around the corner. > But this what OSI proponents have said for some time. "OSI has the constant property of being just around the corner" - Horst Huenke, a senior official of the European Commission, speaking in about 1990. Brian