`
`
`
`
`
`
`
`Implementlng ‘
`c. and X. 500.
`
`The PP and
`
`
`
`3”9U Systems
`
`Q“
`
`Stephen E. Kille
`
`Page 1 0f 30
`
`AT&T EXHIBIT 1018
`
`Page 1 of 30
`
`AT&T EXHIBIT 1018
`
`

`

`
`
`Library of Congress Cataloging-in-Publication Data
`Kille, Stephen E.
`‘
`Implementing X.400 and X.500: The PP and QUIPU Systems / Stephen E. Kille.
`p.
`cm.
`~
`1
`Includes bibliographical references and index.
`ISBN 0-89006-56470
`1. Electronic mail systems-Handbooks, manuals, etc. 2. Computer networks-Standards"
`Handbooks, manuals, etc. I. Title.
`II. Title: QUIPU implementation of X.400 and X.500.
`TK5105.73K55 1991
`'
`004.692--ch0
`
`91-21436
`CIP
`
`British Library Cataloguing in Publication Data
`Kille, Stephen E.
`'
`Implementing X.400 and X500: The PP and QUIPU Systems
`I. Title
`384.34
`
`ISBN 0-890061—564-0
`
`© 1991 Artech House, Inc.
`685 Canton Street
`
`Norwood, MA 02062
`
`All rights reserved. Printed and bound in the United States of America. No pan of
`this publication may be reproduced or utilizedin any form or by any means, elec-
`tronic or mechanical, including photocopying, recording, or by any information
`storage and retrieval system, without permission in writing from the publisher.
`
`International Standard Book Number: 0-89006-564-0
`
`Library of Congress Catalog Card Number: 91-21436
`
`10987654321
`
`Page 2 of 30
`
`Page 2 of 30
`
`

`

`
`
`Chapter 1
`
`Background
`
`1.1 ' OSI
`
`‘
`
`1‘
`
`This book is about the implementation of two OSI (Open Systems Interconnection)
`applications, and so in some senses OSI, is fundamental to the material presented
`here. This book is not an OSI tutorial, and the reader will need to be familiar
`with OSI in order to gain full benefit from this book. For a rigorous theoretical
`introduction, the book by Knowles, Larmouth and Knightson is useful [KLK87].
`For a more practical introduction, the Open Book by Rose is recommended [R0589].
`This book also describes the ISODE implementation, which is discussed further in
`Section 1.3. As the ISODE1s used by both PP and QUIPU, Rose’s bookis a sensible
`companion to this one.
`
`1.1.1 X.400 Message Handling
`
`i
`
`Use of electronic mail services is now established as an important service in many
`environments. This has been achieved by a range of different message protocols and
`by centralis ed “email” services, leading to a situation where there are islands of
`electronic mail connectivity. There is a clear need to have a common international
`standard, which can be used as a mechanism to glue together the disjoint services
`in order to provide a single coherent global electronic mail service.
`The CCITT X.400 recommendations on message handling services have versions
`published in 1984 and 1988 [MHSS4, MHS88a]. These recommendations describe‘
`how message transfer agents (MTAs) can operate collectively to provide an end-to-
`end Message Transfer Service. They specifically describe how the message transfer
`service can be used to provide an interpersonal messaging service between human
`users. X.400 specifies an interface, and is very appropriate for gatewaying onto
`systems which do not follow X.400 internally. A general introduction to X.400 can
`be found in the NCC Book [Chi89]. For those familiar with X.400(1984), Manros’s
`book is a useful introduction to X.400(1988) [Man89]. For further information, it
`is best to read the first parts of the standard itself.
`
`3
`
`Page 3 of 30
`
`Page 3 of 30
`
`

`

`
`
`' 4
`
`‘
`
`CHAPTER 1. BACKGROUND
`
`1.1.2 The OSI Directory
`
`The need for a global directory service to support a variety of applications has been
`seen for some while. Some of these requirements are:
`
`Message Handling Systems During the development of the 1984 X.4OO series
`recommendations for message handling systems, many people foresaw the re-
`quirement for directory services [Whi84]. These requirements have resulted in
`a complex specification of usage in the 1988 version of X400 [MHSS8a]
`
`OSI Applications The whole approach to naming and addressing within OSI as—
`sumes the availability of a directory service [(301881)].
`
`White Pages Service There would be substantial advantage in upgrading the
`current telephone directory system to give online access. The French Minitel
`system has shown the feasibility of this.
`
`Because of such requirements, a standardised OSI directory service has been
`specified as CCITT X.500 series recommendations / ISO DIS 9594 [001881)]. This
`is known generically as the “OSI Directory”. The OSI Directory standard gives a
`clear and general introduction to X.500. Rose’s The Little Black Book gives a useful
`discussion of some aspects of the directory, and in particular problems related to
`use of the OSI Directory [R0591}.
`
`1.2 Deployed Systems
`
`Over the last decade, there has been massive activity in the deployment and oper~
`ation of computer networks. A good overall picture of this activity is given in John
`Quarterman’s book The Matrix [Qua90]. In the international research community,
`TCP/IP based networking, especially that related to the DARPA/NSF Internet
`is particularly important andis dominantin the international research community,
`both academic and industrial. Operationalissues, and the relationship to existing
`systems will often be discussed1n the context of tliis environment. There have been
`a range of systems and services deployed to provide both messaging and directory
`type services. From a user’s standpoint, the OSI Services are just one more set of
`services to be added to the already existing services. This is particularly true for
`messaging, where there are many existing systems, often based on the RFC 822
`format specification [Cr082]. The dominance of these existing systems has certainly
`delayed the deployment of X.400. Another factor is that many early implementa-
`tions of X.400 have been very minimal. Thus, while the protocols may be more
`powerful, the local facilities and management options on the systems have been
`restricted. This has lead to a situation where X.400 based systems do not offer an
`overall improvement of service. There are now quite ‘a number of X.400 products
`
`,
`
`Page 4 of 30
`
`Page 4 of 30
`
`

`

`1.3.
`
`ISODE
`
`5
`
`on offer, but the number of systems in service is very small in comparison to older
`non-X400 systems.
`The situation for the OSI directory is somewhat different. There are a number
`of deployed databases and directory services, but none really fulfill the role of the
`OSI Directory. Existing services fall into two categories:
`
`1. Name service type functions, which enable lookup of precisely specified names.
`These may be widely distributed. A good example of this is the domain
`naming scheme[Moc84].
`2. Centralised database services
`
`»
`
`There is a significant requirement for a large scale distributed database which
`provides searching capabilities. There is a particular requirement to look up users
`to determine information such as electronic mail addresses and telephone numbers.
`Because the OSI directory fills this niche, its deployment has been able to proceed
`much more rapidly, as there is a vacuum. This expansion is particularly notable in
`directory pilot exercises in the UK and the US, which are discussed in Section 2.10.
`
`1.3 , ISODE ‘
`
`The ISODE (ISO development environment), whose principal is Marshall T. Rose of
`Performance Systems International, is a key component of the two systems described
`here. The ISODE is an implementation of the OSI upper layers. It contains:
`the
`layer services of session and presentation; the A0513, ROSE and RTSE application
`service elements; FTAM and VTP applications; and ASN.1 handling tools. A key
`choice in ISODE is to be able to operate over a TCP/IP network. It does this by use
`of a mapping defined in RFC 1006 [RCS7, R086]. This has enabled OSI applications,
`including PP and QUIPU to be deployed ahead of provision of a global OSI network
`service.
`I
`_
`y
`.
`The ISODE is openly available, which puts it effectively in the public domain.
`QUIPU is packaged as a part of ISODE, and there is a symbiotic relationship
`between PP and ISODE. All three systems can be regarded as being a part of the
`same family. The ISODE has been a very popular implementation of OSI, and has
`been taken up in many quarters. A number of manufacturers are using ISODE in
`their products.
`
`1.4 Availability
`
`The availability of PP and QUIPU are described in their respective manuals. The
`expected procedures for the releases are included. The contact addresses are correct.
`It is posssible that the prices "may be» altered.
`As far as possible the manuals are presented in their original form, although
`some small changes are made for this book.
`
`Page 5 of 30
`
`Page 5 of 30
`
`

`

`6
`
`CHAPTER 1. BACKGROUND
`
`The QUIPU manual is a pre-release of the manual for version 7.0 of the code.
`The manual is usually packaged as Volume 5 of the ISODE manual [Ros90a]. The
`common ISODE introductory material is retained as it contains useful pointers to
`the rest of the ISODE. Any differences between this book and version 7.0 will be
`noted clearly in the version 7.0 release.
`The PP manual relates to version 5.3 of the code. Version 6.0 is expected to
`be broadly similar. This manual is usually packaged as a four-volume set. Each
`volume is presented as a part of this book. Any differences between this book and
`' version 6.0 will‘be noted clearly in the version 6.0 release.
`
`‘
`
`
`
`
`Page 6 of 30
`
`Page 6 of 30
`
`

`

`
`
`Chapter 3
`
`PP
`
`PP is a message transfer agent oriented towards support of the X.400 series rec—
`ommendations [MHSS4, MHSSSa]. PP is implemented in C to run under the UNIX
`operating system. There has been extensive experience with a number of sophis-
`ticated text-based message transfer systems, usually based on the RFC 822 stan-
`dards [Cr082, Kin84, A1183, Pre85]. Many emerging X400 systems, while offering
`the superior X.400 protocols, in many respects offer a poorer service than the older-
`systems. PP was evolved when a group of us aimed to draw on the results of earlier
`work and create a message transfer system with high functionality. The major goals
`of PP are:
`‘
`
`0 Provision of a clean interface for message submission and delivery, so that a
`wide range of user agents may be supported.
`
`0 Support for all of the message transfer service elements specified by the 1984
`and 1988 versions of X.400.
`‘
`
`0 Support for some services not provided by X.400.
`
`0 Specific support to facilitate the handling of multimedia messages.
`
`0 Robustness and efficiency required to support high levels of traffic.
`
`0 Scheduling of message delivery in a sophisticated manner, to optimise local
`and communication resources.
`
`0 Provision of a range of management, authorisation and monitoring facilities.
`
`0 Reformatting between, body part types in a general manner.
`0 Support for multiple address formats (initially two).
`
`0 Use of standardised OSI directory services [CCISSb].
`
`9 Support for message protocol conversion in an integrated fashion.
`
`0 Full access to the message transfer service for applications other than inter-
`personal messaging.
`The rest of this chapter discusses the features of PP in more detail, and explains
`how they are used to achieve the listed goals.
`
`‘25
`
`Page 7 of 30
`
`Page 7 of 30
`
`

`

`
`
`26
`
`3. 1 History
`
`‘
`
`CHAPTER 3. PP
`
`PP began in 1985 when a group of people wished to produce a system to supports
`X.400. It was clear that existing RFC 822 MTAs were not going to be extensible to
`do all that we wanted. We had looked at some existing X400 systems, and these
`did not seem to be a suitable basis for our work. PP arose as the solution to the
`problems raised in these discussions. The ideas for the basic structure draw heavily
`on the MMDF system [Kin84], and it is fair to say that MMDF is the parent of PP.
`The initial coding proceeded steadily.
`PP received its first public airing at CEBIT (Hannover Fair) in March 1989,
`where it carried ODIF over X400, and converted it into local format by use of
`private conversion tools. It interworked with a number of X.400(84) systems at this
`point. This was as a part of the ESPRIT PODA project. PP 4.0 was. released at
`the very end of 1989 to 15 beta sites. Three more beta releases were made during
`1990 to an increasing number of beta sites. The first openly available release was
`PP.5.0 in September 1990. Funding for PP has been from a number of sources, the
`most significant being the UK Joint Network Team.
`
`1
`
`3.2 ‘Design Overview
`
`The PP MTA makes extensive use of UNIX processes to provide the modularity
`which is fundamental to PP. The aim has been to make each process perform a
`single function. This allows for flexible construction of complex processing, and
`. minimises side effects. The overall process structure is illustrated in Figure 3.1.
`' PP has a single queue. This is important for the following reasons:
`
`1. It increases robustness.
`2. It facilitates uniform handling of errors.
`
`3. It simplifies management.
`There are two critical processes with complex functionality. All of the others
`are “dumb.” The first key process in PP is submit. Submit takes an incoming
`message (local or remote), and places it in the queue. Submit will perform all
`calculations of the processing required for a given message, and determine how it will
`be delivered. Early checking ensures that errors are detected at the earliest point,
`and that later processes can be implemented in a more straightforward fashion. The.
`initial checking includes all management and address verification. Messages may
`. be passed to Submit either by a user agent or by a protocol server known as an
`inbound channel.
`The second key process is the QMGR, or queue manager, which schedules all
`operations within PP. The QMGR holds the full queue status in memory, and
`controls the processes which perform the work. By centralising this information in
`i a single process, a range of useful schedulingand management options are made
`
`Page 8 of 30
`
`Page 8 of 30
`
`

`

`
`
`3.3. QUEUE STRUCTURE
`
`27
`
`
`
`Figure 3.1: PP Process Structure
`
`available, and performance is also improved. The major components controlled by
`the QMGR are channels, which perform one of two functions:
`1. Delivery of a message, either locally or by use of a message transfer protocol
`(e;g., the X.400 P1).
`‘
`2. Manipulation of the message within the queue (e.g., to carry out a format
`conversion).
`
`For a given MTA’, there is a single queue and a single QMGR. There. may be
`multiple instances of the Submit process acting at any one time. Channel processes
`and UA processes are generic (i.e., there are different types), and there may be
`multiple instances of any specific channel or UA.
`
`3.3 Queue Structure
`
`For each message in the queue, there are two components:
`
`1. A file containing the control information for processing the message. This
`roughly corresponds to the envelope information of X.400.
`2. A UNIX directory 1 containing the message as it arrived and zero or more
`processed forms of the message, together with any associated delivery notifi-
`cations.
`
`1The term UNIX directory is used explicitly to distinguish it from the OSI directory.
`
`k
`
`Page 9 of 30
`
`Page 9 of 30
`
`

`

`
`
`28
`
`CHAPTER 3. PP
`
`The control file is text encoded, as there is a big advantage in being able to
`view and manipulate a queued message by use of a text editor. While this should
`definitely not be a normal event, it is hard to design management tools for every
`eventuality. The queue encoding format is designed to be generic, and not tied
`to a specific protocol. This is important when attempting to support a range of
`protocols: The key element of the control file is a single line of information for each
`recipient. The more important parameters associated with each recipient are:
`0 A unique (integer) key.
`0 The address of the recipient in one or more-forms.
`o The sequence of channels which the message should bepassed through.
`0 The status of processing for the recipient, which would include the formatting
`channels which have been applied, whether the message has been delivered to
`that recipient, and any delivery notifications needed.
`The recipient parameters which change while the message is being processed are
`encoded in a fixed format, to maximise robustness when a control file is altered.
`There are also a large number of parameters which apply to'the‘whole message.
`These include parameters to represent all of the X.400 message transfer service:
`0 The message originator, using the same encoding as a recipient, to facilitate
`error returns.
`,
`
`o The message ID.
`0 A list of encoded information types.
`
`a Deferred delivery date.
`
`a Trace information.
`In addition, there are various services not supported by X.400:
`0 Control of logging on a per message basis.
`0 Provision of message delayed delivery warnings at a user controlled interval.
`. 0 Specification of non-delivery timeout (this can be represented in an extension
`feature of X.400(1988)).
`An example address file is given in Figure 3.2.
`The message itself is stored within a UNIX directory, which contains several
`things:
`0 A UNIX directory called base, which contains the message as submitted.
`0 Zero or more additional UNIX directories, which contain modified ferms of
`the original message. These UNIX directories are labeled according to the
`sequence of modifications (channels) which have been applied.
`0 Zero or more delivery notifications, which are referenced from the control
`file. Several recipients can share one delivery notification. The advantages of
`storing the delivery notification with the original message are discussed later.
`
`Page 10 of 30
`
`Page 10 of 30
`
`

`

`
`
`3.3. QUEUE STRUCTURE
`
`29
`
`Start-of-MngnvPrm
`
`Message-type User-Mpdu
`Message—size 971
`Return-interval 72
`
`Content-type p2
`
`Encoded-info EncTypes="hdr.p2.ia5"
`Original—encoded-info EncTypes=ia5
`cont-return true
`
`Inbound—channel x400in
`
`Inbound-mta dec
`
`MsgId string="91516161700991/1578700JOCKEY" Country=G
`Admin="GDLD 400" Prmd=DIGITAL
`
`Trace Country=GB Admin="GOLD 400" Prmd=DIGITAL
`arrival="Tue, 17 Jul 1990 19:31:08 +0000" action=0
`End—of—block
`‘
`
`Trace mta="bells.cs.ucl.ac.uk" Country=gb Admin="gold 400"
`Prmd="uk.ac" arriva1="Tue, 17 Jul 1990 21:40:07 +0000"
`action=0 End-of-block
`
`Queued—time "Tue, 17 Jul 1990 21:40:09 +0000"
`Origs rno=000 status=done reform-done=000 outchan=x4000ut
`outmta=dec ext-id=0 resp=false mta-rreqébasic
`
`usr—rreqébasic type=x400
`orig="/G=ANDREW/S=BUSH/UU=SWS/0U=E00/0U=EUR/0=DIGITAL/
`PRMD= DIGITAL/ADMD= GOLD 400/C= GBl"
`
`x400="/G= ANDREW/S=BUSH/0U=SWS/DU=E00/0U=EUR/0=DIGITAL/
`
`PRMD=DIGITAL/ADMD= GOLD 4oo/c= GB/"
`
`rfc="ANDREW.BUSH@SWS.E00.EUR.DIGITAL.DIGITAL.gold-400.gb"
`End-of-addr
`
`Recip rno=001 status=pend reform—done=004
`
`reform-list="p2explode,p2t0822,822t0jnt,822flatten"
`outchan=gb—janet
`7
`
`outmta="central-administration.cambridge.ac.uk"
`ext-id=1 resp=true mta—rreq=basic usr-rreq?basic type=822
`eits="ia5,hdr.822-jntmail" content=822
`orig="/S=SANDHAM_D/0U=ADMIN/0=CAM/PRMD=UK.AC/
`ADMD=GDLD 4oo/c=GB/"
`’
`
`x400="/S=SANDHAM_D/0U=ADMIN/0=CAMIPRMD=UK.AC/
`
`ADMD=GOLD 400/C=GB/"
`Ifc="SANDBAM_D@central-administiation.cambridge.ac.uk"
`End-of-addr
`
`Figure 3.2: Example PP Address File
`
`Page 11 of 30 '
`
`Page 11 of 30
`
`

`

`
`
`30
`
`CHAPTER 3. PP
`
`
`
`addr.nnn
`
`Figure 3.3: PP Queue Entry Structure
`
`Page 12 of 30
`
`Page 12 of 30
`
`

`

`
`
`3. 4, MESSAGE SUBMISSION
`
`-
`
`31
`
`A PP message content is stored as UNIX directory. An example is given in
`Figure 3.3. The message header (P2 or equivalent), and each body part are stored
`as, files. Forwarded messages are stored as subdirectories ~——- the format definition is
`recursive. Each component is labeled according to its type. Body parts also have
`a number, so that sequencing canbe preserved. For example: a file called “3.ia5”
`would be the third body part containing IA5 text; a file called “‘hdr.P2” would
`contain a heading encoded according to P2. This structure is not constrained to
`interpersonal messaging (IPM), although IPM is the major target. The main reason
`for this structure is to facilitate reformatting. By putting the various components
`into separate files, reformatting can be carried out in a straightforward manner. It
`is expected that a PP related user agent would also use this structure, as it appears
`to offer a good basis for flexible construction of Multimedia messages.
`Io,
`
`3.4 Message Submission
`
`The process of message submission is now considered in a little more detail. A
`message is submitted by either a user agent (local submission) or by an inbound
`channel, which interacts with Submit through a protocol. The current version
`of this protocol uses a UNIX interprocess communication (IPC) mechanism (pipes
`or sockets). The encoding of the current protocol is text based, with parameters
`equivalent to the queue structure.
`The first stage of message submission is for the submitting process to initialise
`a Submit process. Then all the per—message parameters will be sent to Submit,
`_which will perform validity checks and initial management checks. Submit then
`acknowledges these parameters, and address checking begins.
`PP currently recognises two forms of address: RFC 822 address, and X.400
`O / R address. Both of these are handled using a text encoding. For X.400, this uses
`the RFC 987/ RFC 1148 [Ki186b, Ki190b] domain-oriented encoding. A submitting
`process will select the appropriate form, and then offer each address in‘turn. There
`are two modes of interaction:
`
`1. Any errors will be passed back to the submitting process. This is useful for
`user agents, and interactive protocols such as SMTP [P0582].
`2. A successful response is always passed back to the submitting process, and
`delivery notifications are generated if necessary '(these reside in the queue for
`later processing). This mechanism is useful for protocols such as X400 P1,
`X.400 P3, or JNT mail protocol [Ki184].
`
`Address checking will first determine the .MTA to which the message should
`be sent. After the MTA is determined, an outbound channel is selected. Where
`an MTA is accessible by multiple channels, channel binding attempts to minimise
`protocol conversions. Management checking is also carried out at this point, as it
`is sometimes important to control channel choice for administrative reasons. This
`includes application of authorisation controls, so that routing can be regulated on
`
`‘ Page 13 of 30
`
`Page 13 of 30
`
`

`

`
`
`32
`
`' CHAPTER 3. PP
`
`the basis of host, network and user. A description of the general approach from
`which the PP implementation is derived is given in a paper by Kille and Brink
`[KB85].
`.
`_
`. Following the determination of the outbound channel, the reformatting require-
`ments are calculated. This will result in a sequence of channels, which will perform
`the correct series of protocol and body part reformatting on the message in ques-
`tion. This is a surprisingly difficult calculation to make, but it can be done in a
`reasonably general manner. All of the submission time checking is discussed further
`
`message stored in the queue. For example:
`0 An RFC 822 message is submitted as two files.
`
`a A P2 message is submitted as one file.
`0' A local submission of a complex UNIX directory hierarchy is submitted di-
`rectly.
`Submit understands the P1 level aspects of RFC 1148 [Ki190b, Ki186a]. This
`means that it can map addresses between the two forms, and will correctly handle
`trace and message identifiers. Finally, any remaining management checks are done
`(for example, any required checks on message content), and the message is locked
`into the queue. Statistical logging is done at this point.
`
`3.5 Channels
`
`The term “channel” is used in PP to describe a number of somewhat different
`components. In essence, each channel takes a message as input, and then provides
`a different message as output. A channel, may put a message into the queue, remove
`a message from the queue, or transform a message within the queue. Channels which
`are controlled by the QMGR access the queue through a library. They are trusted
`processes, and will update the queue. A channel will operate entirely under the
`direction of the QMGR, and no intelligence is involved. There are several types of
`channel, which are now described.
`
`3.5.1 Outbound Protocol Channels
`
`This basic type of channel will take a message from the queue and transfer it using
`a message transfer protocol. The outbound protocol channels supported by PP are:
`. x.400/P1 (1984)
`
`. X.400/P1 (1988)
`
`. JNT Mail
`
`Page 14 of 30
`
`Page 14 of 30
`
`

`

`l ll l
`
`ll l l
`
`33
`
`3.5. CHANNELS
`
`o SMTP
`
`o UUCP
`
`0 DEC Mail 11
`
`Interestingly, the implementation of the X.400 protocol is not really a major
`problem. The use of thePEPY ASN.1 compiler from the ISODE package has made
`the mapping of the PP message transfer services onto OSI a relatively mechanical
`operation [Ros90a, OR88].
`
`3.5.2 Other Outbound Channels
`
`An outbound channel is always the last applied to. a recipient, and so will cause the
`message to leave the queue (for that recipient). This does not include handling of
`delivery notifications, which will happen after the outbound channel is run. There
`are a number of outbound channels, which are not protocol channels. The first is
`local delivery, Where the message is simply delivered into a local file. PP supports
`two styles of local delivery:
`
`1. Delivery into a UNIX-style text mailbox.
`2. Delivery into a U NIX directory—structured message, equivalent to the PP queue
`model. This is a flexible format, which has proved very useful for prototyping
`multimedia user agents.
`
`Local delivery supports delivery time processing based on the delivery param-
`eters and contents of the message. This allows for the user to file messages and
`to make private'actions such as holiday notification or user alert in an X Window
`System alert program.
`An outbound channelis also used to support distribution lists The destination,
`in terms of the1ncoming message, will be the list. The list channel will expand the
`list, perform any necessary management checks (e.g., permission to send to the list),
`and resubmit the message as a new message. This means that lists will be provided
`at the P2 level, rather than at the P1 level. For PP, the major consideration is the
`ability to support distribution lists for RFC 822 and X.400(1984) systems in a pro-
`tocol independent manner. The X.400(1988) (protocol dependent) list mechanisms
`will be fully supported in future releases of PP. In practice, the main difference is
`whether or not the MTS identifier is preserved across list expansion.
`There is also an outbound channel to support the RFC 1148 mapping of delivery
`notifications onto text messages. PP will map all errors onto delivery notifications;
`therefore this channel is a critical component, because RFC 822 based systems do
`not support delivery notifications as protocol elements.
`Use is made of appropriate Nameservers and Directories. The SMTP channel
`uses the BIND nameserver [T'PRZ84]. The distribution list channel utilises the OSI
`directory service by use of the QUIPU DUA API. Further use of the OSI directory
`is planned.
`
`.
`
`Page'15 of 30
`
`Page 15 of 30
`
`

`

`
`
`34
`
`.
`
`.
`
`'
`
`'
`
`CHAPTER 3. PP
`
`There is a special channel to deliver messages via G3 fax. This can be seen as a
`PP-specific implementation of a G3 fax access unit. This is a very useful component
`for operational services.
`
`3.5.3
`
`Inbound Channels
`
`Inbound channels perform the opposite to outbound channels. For each of the
`protocols supported, there is a channel which will act as a server for the protocol.
`When an inbound message is received, the channel will invoke Submit. The channel
`will then pass messages into Submit.
`‘It is also possible for a channel to act as both inbound and outbound. This
`is necessary to support two-way alternate mode reliable transfer for XAOO, or to
`support P3/P7 style message retrieval which is user agent initiated. In this case, the
`channel will start as an inbound channel, typically by being invoked as a protocol
`server. Then it will connect to the QMGR using ROS. The QMGR can choose to
`accept or reject the association. If it accepts the association, the QMGR will take
`control and then the channel will behave as an outbound channel. In terms of the
`QMGR, the use of ROS makes this control model straightforward to provide.
`‘
`
`3.5.4 Message Reformatting and Protoéol Conversion
`
`The flexible handling of reformatting is one of the most important components
`of PP. This is achieved by reformatting channels which map from one message
`form into another. As discussed, Submit will Calculate a sequence of reformatting
`channels for each recipient in order to provide the correct conversions. Internally,
`PP represents different body part and header formats as strings (e.g., “ia5” or
`“jnt-mail”). Channels will support a set of formats, represented by these strings.
`The channel may choose to map these into protocol specific encodings (e.g., MTS
`encoded information types). This approach allows for complex mappings to be
`calculated and for general extension.
`In terms of the overall queue structure, a reformatting channel will take the
`message directory of a given name, and then create a parallel directory with the
`new, reformatted message in it. The new directory will have the name of the
`old one, with the name of the formatting channel appended (e.g., when channel
`“bitmap2fax” is applied to message directory base, a directory base. bitmap2fax is
`created). This will ensure uniqueness when a message undergoes seVeral complex
`sequences of transformations for different recipients, and will optimise reformatting
`for multiple recipients.
`those which preserve the directory
`There are two basic types of reformatting:
`structure, and those which do not. The channels which change directory structure
`are typically single processes specifically designed for the transformation in question.
`Channels in PP which fall into this category are:
`
`. Page 16 of 30
`
`Page 16 of 30
`
`

`

`
`
`3.6. ROB USTNESS ISSUES
`
`»
`
`35
`
`0 Mapping from a flat l(i.e., ASN.1 encoded) P2 message into a PP directory
`hierarchy.
`
`o The reverse of the previous mapping.
`0 Mapping from a directory hierarchy into an RFC 822 message, according to
`RFC 934 [R885].
`
`Many other reformatting channels preserve the directory hierarchy, and simply
`map from one body part syntax to another. These channels are supported by use
`of a generic reformatting channel which will drive a simple filter to perform the
`mapping. Body parts which are not affected by the filter are simply linked across,
`which avoids unnecessary copying of data. This will enable a Wide range of body
`part types to be supported independently of the core PP code.
`In terms of the
`Protocol Conversion is an important form ‘of reformatting.
`PP model, protocol conversion channels are no different from other reformatting
`channels. PP will support RFC 1148 reformatting between X.400 and RFC 822, and
`also reformatting between variants of RFC 822. X.400 1988 to 1984 downgrading
`is also supported with a mapping from content type 22 to content type 2 (P2
`downgrading).
`
`3.5.5 Housekeeping Channels
`
`There are a number of channels which are used for housekeeping operations on the
`queue. These functions are:
`
`c Removing messages which have been fully processed.
`
`o Tidying up “orphan” entries in the queue.
`
`0 Loading the queue from disk.
`
`3.6 Robustness Issues
`
`The manner in which delivery notifications are handled is of interest. Delivery
`notifications are stored with the message, as described above. The queue interface
`library allows any channel to add a delivery notification. Thus, if a processing
`error occurs, the channel detecting the error will update the queue and create an
`appropriate delivery notification. At a later stage, the QMGR can invoke processing
`of delivery notifications through a channel appropriate for the message originator.
`When return of content is requested as a service, this is achieved by use of
`protocol. It was originally intended that the QMGR may ask for delivery acknowl-
`edgement and hold the message locally, rather than asking for return of content as
`a remote service, and this approach may still be implemented. When the appropri-
`ate delivery notification returns, Submit will determine (from the QMGR) which
`message to associate it with, so that a given recipient can be marked as “delivered
`
`Page 17 of 30
`
`Page 17 of 30
`
`

`

`36
`
`CHAPTER 3. PP
`
`and confirmed.” This approach seemed a useful way to provide the return of con-
`tent service (which is particularly important for protocol conversion) in the light of
`many X.400 services which do not provide it as a remote service. There are real
`problems associated to guarantee the routing the delivery report back to the ‘MTA
`which holds it. With this approach is the option to specify “reliable delivery,” where
`PP will specify positive delivery notification, and not remove the message from the
`queue until it arrives, which may prove to be a valuable user service.
`PP goes