idnits 2.17.1 draft-kille-mixer-rfc1327bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 175 form feeds but 178 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' Security considerations are not discussed in this RFC.' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 54 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 258 instances of too long lines in the document, the longest one being 18 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 42 has weird spacing: '...ch will enabl...' == Line 43 has weird spacing: '...working betwe...' == Line 47 has weird spacing: '...2 mail proto...' == Line 49 has weird spacing: '...systems which...' == Line 50 has weird spacing: '...ervices offer...' == (49 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1995) is 10480 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 46 looks like a reference -- Missing reference section? '13' on line 1679 looks like a reference -- Missing reference section? '15' on line 46 looks like a reference -- Missing reference section? '16' on line 2534 looks like a reference -- Missing reference section? '9' on line 4072 looks like a reference -- Missing reference section? '17' on line 54 looks like a reference -- Missing reference section? '18' on line 54 looks like a reference -- Missing reference section? '20-22' on line 54 looks like a reference -- Missing reference section? '5' on line 56 looks like a reference -- Missing reference section? '31' on line 270 looks like a reference -- Missing reference section? '10' on line 2675 looks like a reference -- Missing reference section? '11' on line 340 looks like a reference -- Missing reference section? '12' on line 374 looks like a reference -- Missing reference section? '29' on line 5478 looks like a reference -- Missing reference section? '6' on line 6242 looks like a reference -- Missing reference section? '23' on line 6236 looks like a reference -- Missing reference section? '7' on line 555 looks like a reference -- Missing reference section? '3' on line 634 looks like a reference -- Missing reference section? '28' on line 4877 looks like a reference -- Missing reference section? '0' on line 1626 looks like a reference -- Missing reference section? '14' on line 1636 looks like a reference -- Missing reference section? '24' on line 2037 looks like a reference -- Missing reference section? '4' on line 2312 looks like a reference -- Missing reference section? '27' on line 2315 looks like a reference -- Missing reference section? '19' on line 2985 looks like a reference -- Missing reference section? '25' on line 3153 looks like a reference -- Missing reference section? '26' on line 3154 looks like a reference -- Missing reference section? '8' on line 4792 looks like a reference -- Missing reference section? '33' on line 4915 looks like a reference -- Missing reference section? '32' on line 5422 looks like a reference -- Missing reference section? '30' on line 6125 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 34 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working S.E. Kille 2 Group ISODE Consortium 3 INTERNET-DRAFT August 1995 4 Expires: February 1996 5 File: draft-kille-mixer-rfc1327bis-01.txt 7 MIXER (Mime Internet X.400 Enhanced Relay): 9 Mapping between X.400 and RFC 822/MIME 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. Internet Drafts are draft 17 documents valid for a maximum of six months. Internet Drafts may be 18 updated, replaced, or obsoleted by other documents at any time. It is 19 not appropriate to use Internet Drafts as reference material or to 20 cite them other than as a ``working draft'' or ``work in progress.'' 21 Please check the I-D abstract listing contained in each Internet Draft 22 directory to learn the current status of this or any other Internet 23 Draft. 25 NOTE: This document (version 2.2) is change-barred relative to version 26 2.1. Some obvious formatting errors have been introducted by this 27 process, and these will not be present in the final version. 29 Network Working Group S.E. Kille 30 Internet Draft ISODE Consortium 31 RFC 1327bis August 1995 32 Obsoletes: RFCs 987, 1026, 1138, 1148, 1327, 1495 33 Updates: RFC 822 34 | 36 MIXER (Mime Internet X.400 Enhanced Relay): 38 Mapping between X.400 and RFC 822/MIME 40 Status of this Memo: 42 This document describes a set of mappings which will enable 43 interworking between systems operating the CCITT X.400 44 Recommendations on Message Handling Systems (1984, 1988 and 45 1992 versions) / ISO IEC 10021 Message Oriented Text 46 Interchange Systems (MOTIS) [2,13,15], and systems using the 47 RFC 822 mail protocol [16] or protocols derived from RFC 48 822, supplemented by the MIME specifications [9]. Older 49 systems which do not use MIME are still supported. The 50 approach aims to maximise the services offered across the 51 boundary, whilst not requiring unduly complex mappings. The 52 mappings should not require any changes to end systems. This 53 document is a revision based on the evolving sequence of 54 RFCs 987, 1026, 1138, 1148 and 1327 [17,18,20-22], which it 55 obsoletes. It incorporates changes specified in RFC 1495 56 [5], which it also obsoletes. 58 This document specifies a mapping between two families of 59 protocols, which includes both protocol/service mappings and 60 use of a mandatory global mappings. This specification 61 should be used when this mapping is performed. This | 62 specification may be modified in the light of implementation 63 experience, but no substantial changes are expected. 65 This draft document will be submitted to the RFC editor as 66 a protocol specification. Distribution of this memo is 67 unlimited. Please send comments to the author. 69 RFC 1327bis 70 MIXER DRAFT Version 2.2 72 2 - Service Elements .............................. 16 73 2.1 - The Notion of Service Across a Gateway ........ 16 74 2.2 - RFC 822 ....................................... 17 75 2.3 - X.400 ......................................... 24 76 3 - Basic Mappings ................................ 35 77 3.1 - Notation ...................................... 35 78 3.2 - ASCII and IA5 ................................. 37 79 3.3 - Standard Types ................................ 37 80 3.4 - Encoding ASCII in Printable String ............ 40 81 3.5 - RFC 1522 ...................................... 42 82 4 - Addressing and Message IDs .................... 43 83 4.1 - A textual representation of MTS.ORAddress ..... 44 84 4.2 - Global Address Mapping ........................ 51 85 4.3 - EBNF.822-address <-> MTS.ORAddress ............ 54 86 4.4 - Repeated Mappings ............................. 67 87 4.5 - Directory Names ............................... 69 88 4.6 - MTS Mappings .................................. 70 89 4.7 - IPMS Mappings ................................. 75 90 5 - Detailed Mappings ............................. 81 92 RFC 1327bis 93 MIXER DRAFT Version 2.2 95 5.1 - RFC 822 -> X.400: Detailed Mappings ........... 81 96 5.2 - Return of Contents ............................ 101 97 5.3 - X.400 -> RFC 822: Detailed Mappings ........... 102 98 Appendix A - Mappings Specific to SMTP ..................... 139 99 6 - Probes ........................................ 139 100 7 - Long Lines .................................... 139 101 8 - SMTP Extensions ............................... 139 102 8.1 - SMTP Extension mapping to X.400 ............... 139 103 8.2 - X.400 Mapping to SMTP Extensions .............. 140 104 Appendix B - Mapping with X.400(1984) ................. 141 105 Appendix C - RFC 822 Extensions for X.400 access 143........ [ 106 Appendix D - Object Identifier Assignment 144............... [ 107 Appendix E - BNF Summary ................................... 145 108 Appendix F - Format of address mapping tables .............. 156 109 1 - Global Mapping Information .................... 156 110 2 - Mechanisms to register and to distribute 111 Mapping Rules .............................................. 156 112 3 - Syntax Definitions ............................ 157 113 4 - Table Lookups ................................. 158 114 5 - Domain -> O/R Address format .................. 159 115 6 - O/R Address -> Domain format .................. 159 116 7 - Domain -> O/R Address of Gateway table ........ 160 117 Appendix G - Conformance ................................... 161 118 Appendix H - Change History: RFC 987, 1026, 1138, 1148 119 ............................................................ 163 120 1 - Introduction .................................. 163 121 2 - Service Elements .............................. 163 122 3 - Basic Mappings ................................ 164 123 4 - Addressing .................................... 164 124 5 - Detailed Mappings ............................. 164 125 6 - Appendices .................................... 165 126 Appendix I - Change History: RFC 1148 to RFC 1327 .......... 166 127 1 - General ....................................... 166 128 2 - Basic Mappings ................................ 166 129 3 - Addressing .................................... 166 130 4 - Detailed Mappings ............................. 167 131 5 - Appendices .................................... 167 132 Appendix J - Change History: RFC 1327 to this Document 133 ............................................................ 168 134 1 - General ....................................... 168 135 2 - Service Elements .............................. 168 136 3 - Basic Mappings ................................ 168 137 4 - Addressing .................................... 168 138 5 - Detailed Mappings ............................. 169 140 RFC 1327bis 141 MIXER DRAFT Version 2.2 143 6 - Appendices .................................... 169 145 Table of Contents 147 1 - Overview ...................................... 6 148 1.1 - X.400 ......................................... 6 149 1.2 - RFC 822 and MIME .............................. 6 150 1.3 - The need for conversion ....................... 7 151 1.4 - General approach .............................. 7 152 1.5 - Gatewaying Model .............................. 8 153 1.6 - X.400 (1984) .................................. 11 154 1.7 - X.400 (1992) .................................. 12 155 1.8 - MIME .......................................... 12 156 1.9 - Body Parts .................................... 12 157 1.10 - Compatibility with previous versions ......... 13 158 1.11 - Aspects not covered ......13.................. [ 159 1.12 - Subsetting ................................... 13 160 1.13 - .mc | ......14................................ | 161 1.14 - .mc .......................................... 14 162 1.15 - Document Structure ........................... 14 163 1.16 - Acknowledgements ............................. 15 164 2 - Service Elements .............................. 16 165 2.1 - The Notion of Service Across a Gateway ........ 16 166 2.2 - RFC 822 ....................................... 17 167 2.3 - X.400 ......................................... 24 168 3 - Basic Mappings ................................ 35 169 3.1 - Notation ...................................... 35 170 3.2 - ASCII and IA5 ................................. 37 171 3.3 - Standard Types ................................ 37 172 3.4 - Encoding ASCII in Printable String ............ 40 173 3.5 - RFC 1522 ...................................... 42 174 4 - Addressing and Message IDs .................... 43 175 4.1 - A textual representation of MTS.ORAddress ..... 44 176 4.2 - Global Address Mapping ........................ 51 177 4.3 - EBNF.822-address <-> MTS.ORAddress ............ 54 178 4.4 - Repeated Mappings ............................. 67 179 4.5 - Directory Names ............................... 69 180 4.6 - MTS Mappings .................................. 70 181 4.7 - IPMS Mappings ................................. 75 182 5 - Detailed Mappings ............................. 81 184 RFC 1327bis 185 MIXER DRAFT Version 2.2 187 5.1 - RFC 822 -> X.400: Detailed Mappings ........... 81 188 5.2 - Return of Contents ............................ 101 189 5.3 - X.400 -> RFC 822: Detailed Mappings ........... 102 190 Appendix A - Mappings Specific to SMTP ..................... 139 191 6 - Probes ........................................ 139 192 7 - Long Lines .................................... 139 193 8 - SMTP Extensions ............................... 139 194 8.1 - SMTP Extension mapping to X.400 ............... 139 195 8.2 - X.400 Mapping to SMTP Extensions .............. 140 196 Appendix B - Mapping with X.400(1984) ................. 141 197 Appendix C - RFC 822 Extensions for X.400 access 143........ [ 198 Appendix D - Object Identifier Assignment 144............... [ 199 Appendix E - BNF Summary ................................... 145 200 Appendix F - Format of address mapping tables .............. 156 201 1 - Global Mapping Information .................... 156 202 2 - Mechanisms to register and to distribute 203 Mapping Rules .............................................. 156 204 3 - Syntax Definitions ............................ 157 205 4 - Table Lookups ................................. 158 206 5 - Domain -> O/R Address format .................. 159 207 6 - O/R Address -> Domain format .................. 159 208 7 - Domain -> O/R Address of Gateway table ........ 160 209 Appendix G - Conformance ................................... 161 210 Appendix H - Change History: RFC 987, 1026, 1138, 1148 211 ............................................................ 163 212 1 - Introduction .................................. 163 213 2 - Service Elements .............................. 163 214 3 - Basic Mappings ................................ 164 215 4 - Addressing .................................... 164 216 5 - Detailed Mappings ............................. 164 217 6 - Appendices .................................... 165 218 Appendix I - Change History: RFC 1148 to RFC 1327 .......... 166 219 1 - General ....................................... 166 220 2 - Basic Mappings ................................ 166 221 3 - Addressing .................................... 166 222 4 - Detailed Mappings ............................. 167 223 5 - Appendices .................................... 167 224 Appendix J - Change History: RFC 1327 to this Document 225 ............................................................ 168 226 1 - General ....................................... 168 227 2 - Service Elements .............................. 168 228 3 - Basic Mappings ................................ 168 229 4 - Addressing .................................... 168 230 5 - Detailed Mappings ............................. 169 232 RFC 1327bis 233 MIXER DRAFT Version 2.2 235 6 - Appendices .................................... 169 236 Chapter 1 -- Overview 238 1.1. X.400 240 This document relates primarily to the ITU 1988 and 1992 X.400 241 Series Recommendations / ISO IEC 10021 on the Message Oriented 242 Text Interchange Service (MOTIS). This ISO/ITU standard is 243 referred to in this document as "X.400", which is a convenient 244 shorthand. Any reference to the 1984 ITU Recommendations will be 245 explicit. Any mappings relating to elements which are in the 246 1992 version and not in the 1988 version will be noted 247 explicitly. X.400 defines an Interpersonal Messaging System 248 (IPMS), making use of a store and forward Message Transfer 249 System. This document relates to the IPMS, and not to wider | 250 application of X.400, such as EDI as defined in X.435. 252 1.2. RFC 822 and MIME 254 RFC 822 evolved as a messaging standard on the DARPA (the US 255 Defense Advanced Research Projects Agency) Internet. RFC 822 256 specifies an end to end message format, consisting of a header 257 and an unstructured text body. MIME (Multipurpose Internet Mail 258 Extensions) specifies a structured message body format for use 259 with RFC 822. The term "RFC 822" is used in this document to 260 refer to the combination of MIME and RFC 822. RFC 822 and MIME 261 are used in conjunction with a number of different message 262 transfer protocol environments. The core of the MIXER 263 specification is designed to work with any supporting message 264 transfer protocol. 266 One transfer protocol, SMTP, is of particular importance and 267 is covered in MIXER. On the Internet and other TCP/IP networks, 268 RFC 822 is used in conjunction with 269 RFC 821, also known as Simple Mail Transfer Protocol (SMTP) 270 [31], in a manner conformant with the host requirements 271 specification [10]. Use of MIXER with SMTP is defined in 272 Appendix A. 274 RFC 1327bis 275 MIXER DRAFT Version 2.2 277 1.3. The need for conversion 279 There is a large community using RFC 822 based protocols for mail 280 services, who will wish to communicate with users of the IPMS 281 provided by X.400 systems. This will also be a requirement in 282 cases where communities intend to make a transition to use of an 283 X.400 IPMS, as conversion will be needed to ensure a smooth 284 service transition. It is expected that there will be more than 285 one gateway, and this specification will enable them to behave in 286 a consistent manner. Note that the term gateway is used to 287 describe a component performing the protocol mappings between RFC 288 822 and X.400. This is standard usage amongst mail implementors, 289 but should be noted carefully by transport and network service 290 implementors. 292 Consistency between gateways is desirable to provide: 294 1. Consistent service to users. 296 2. The best service in cases where a message passes through 297 multiple gateways. 299 1.4. General approach 301 There are a number of basic principles underlying the details of 302 the specification. These principles are goals, and are not 303 achieved in all aspects of the specification. 305 1. The specification should be pragmatic. There should not be 306 a requirement for complex mappings for "Academic" reasons. 307 Complex mappings should not be required to support trivial 308 additional functionality. 310 2. Subject to 1), functionality across a gateway should be as 311 high as possible. 313 3. It is always a bad idea to lose information as a result of 314 any transformation. Hence, it is a bad idea for a gateway 315 to discard information in the objects it processes. This 316 includes requested services which cannot be fully mapped. 318 4. All mail gateways actually operate at exactly one level 319 above the layer on which they conceptually operate. This 320 implies that the gateway must not only be cognisant of the 322 RFC 1327bis 323 MIXER DRAFT Version 2.2 325 semantics of objects at the gateway level, but also be 326 cognisant of higher level semantics. If meaningful 327 transformation of the objects that the gateway operates on 328 is to occur, then the gateway needs to understand more than 329 the objects themselves. 331 5. Subject to 1), the specification should be reversible. That 332 is, a double transformation should bring you back to where 333 you started. 335 1.5. Gatewaying Model 337 1.5.1. X.400 339 X.400 defines the IPMS Abstract Service in X.420/ISO 10021-7 , 340 [11] which comprises of three basic services: 342 1. Origination 344 2. Reception 346 3. Management 348 Management is a local interaction between the user and the IPMS, 349 and is therefore not relevant to gatewaying. The first two 350 services consist of operations to originate and receive the 351 following two objects: 353 1. IPM (Interpersonal Message). This has two components: a 354 heading, and a body. The body is structured as a sequence 355 of body parts, which may be basic components (e.g., IA5 356 text, or G3 fax), or Interpersonal Messages. The heading 357 consists of fields containing end to end user information, 358 such as subject, primary recipients (To:), and importance. 360 2. IPN (Inter Personal Notification). A notification about 361 receipt of a given IPM at the UA level. 363 The Origination service also allows for origination of a probe, 364 which is an object to test whether a given IPM could be correctly 365 received. 367 The Reception service also allows for receipt of Delivery Reports 368 (DR), which indicate delivery success or failure. 370 RFC 1327bis 371 MIXER DRAFT Version 2.2 373 These IPMS Services utilise the Message Transfer (MT) 374 Abstract Service [12]. The MT Abstract Service provides the 375 following three basic services: 377 1. Submission (used by IPMS Origination) 379 2. Delivery (used by IPMS Reception) 381 3. Administration (used by IPMS Management) 383 Administration is a local issue, and so does not affect this 384 standard. Submission and delivery relate primarily to the MTS 385 Message (comprising Envelope and Content), which carries an IPM 386 or IPN (or other uninterpreted contents). There is also an 387 Envelope, which includes an ID, an originator, and a list of 388 recipients. Submission also includes the probe service, which 389 supports the IPMS Probe. Delivery also includes Reports, which 390 indicate whether a given MTS Message has been delivered or not. 392 The MTS is provided by MTAs which interact using the MTA | 393 (Message Transfer Agent) Service, which defines the interaction 394 between MTAs, along with the procedures for distributed 395 operation. This service provides for transfer of MTS Messages, 396 Probes, and Reports. 398 1.5.2. RFC 822 400 RFC 822 is based on the assumption that there is an underlying 401 service, which is here called the 822-MTS service. The 822-MTS 402 service provides three basic functions: 404 1. Identification of a list of recipients. 406 2. Identification of an error return address. 408 3. Transfer of an RFC 822 message. 410 It is possible to achieve 2) within the RFC 822 header. | 412 This specification will be used most commonly with SMTP as | 413 the 822-MTS service. The core MIXER specification is written so | 414 that it does not rely on non-basic 822-MTS services. Use of | 415 non-basic SMTP services is described in Appendix A. The core of | 416 this document is written using SMTP terminology for 822-MTS | 418 RFC 1327bis 419 MIXER DRAFT Version 2.2 421 services, for clarity in its usual domain of application. | 423 An RFC 822 message consists of a header, and content which 424 is uninterpreted ASCII text. The header is divided into fields, 425 which are the protocol elements. Most of these fields are 426 analogous to P2 heading fields, although some are analogous to 427 MTS Service Elements or MTA Service Elements. 429 RFC 822 supports delivery status notifications by use of the 430 NOTARY mechanisms [29]. 432 1.5.3. The Gateway 434 Given this functional description of the two services, the 435 functional nature of a gateway can now be considered. It would | 436 be elegant to consider the SMTP (822-MTS) service mapping onto 437 the MTS Service Elements and RFC 822 mapping onto an IPM, but 438 reality just does not fit. Another elegant approach would be to 439 treat this document as the definition of an X.400 Access Unit 440 (AU). Again, reality does not fit. It is necessary to consider 441 that the IPM format definition, the IPMS Service Elements, the 442 MTS Service Elements, and MTA Service Elements on one side are | 443 mapped into RFC 822 + SMTP on the other in a slightly tangled 444 manner. The details of the tangle will be made clear in Chapter 445 5. Access to the MTA Service Elements is minimised. 447 The following basic mappings are thus defined. When going 448 from RFC 822 to X.400, an RFC 822 message and the associated SMTP | 449 information is always mapped into an IPM (MTA, MTS, and IPMS 450 Services) and a Delivery Status Notification is mapped onto a 451 Report. Going from X.400 to RFC 822, an RFC 822 message and the | 452 associated SMTP information may be derived from: 454 1. An IPN (MTA, MTS, and IPMS services) 456 2. An IPM (MTA, MTS, and IPMS services) 458 A Report (MTA, and MTS Services) is mapped onto a delivery status 459 notification. 461 Probes (MTA Service) must be processed by the gateway, as 462 discussed in Chapter 5. MTS Messages containing Content Types 463 other than those defined by the IPMS are not mapped by the 464 gateway, and should be rejected at the gateway. | 466 RFC 1327bis 467 MIXER DRAFT Version 2.2 469 This specification is concerned with X.400 IPMS. Future | 470 specifications may defined mappings for other X.400 content | 471 types. 473 1.5.4. Repeated Mappings 475 The primary goal of this specification is to support single 476 mappings, so that X.400 and RFC 822 users can communicate with 477 maximum functionality. 479 The mappings specified here are designed to work where a 480 message traverses multiple times between X.400 and RFC 822. This 481 is often essential, particularly in the case of distribution 482 lists. However, in general, this will lead to a level of service 483 which is the lowest common denominator (approximately the 484 services offered by RFC 822). 486 Some RFC 822 networks may wish to use X.400 as an 487 interconnection mechanism (typically for policy reasons), and 488 this is fully supported. 490 Where an X.400 message transfers to RFC 822 and then back to 491 X.400, there is no expectation of X.400 services which do not 492 have an equivalent service in standard RFC 822 being preserved - 493 although this may be possible in some cases. 495 1.6. X.400 (1984) 497 Much of this work is based on the initial specification of RFC 498 987 and in its addendum RFC 1026, which defined a mapping between 499 X.400(1984) and RFC 822. A basic decision is that the mapping 500 defined in this document is to the full 1988 version of X.400, 501 and not to a 1984 compatible subset. New features of X.400(1988) 502 can be used to provide a much cleaner mapping than that defined 503 in RFC 987. This is important, to give good support to 504 communities which will utilise full X.400 at an early date. To 505 interwork with 1984 systems, Appendix B shall be followed. 507 If a message is being transferred to an X.400(1984) system 508 by way of X.400(1988) MTA it will give a slightly better service 509 to follow the rules of Appendix B, than to downgrade without this 510 knowledge. Downgrading specifications which supplement those 511 specified in X.400 are given in RFC 1328 and RFC 1496 (HARPOON) 512 [6,23]. 514 RFC 1327bis 515 MIXER DRAFT Version 2.2 517 1.7. X.400 (1992) 519 X.400 (1992) features are not used by the core of this mapping, 520 and so there is not an equivalent downgrade problem. 522 1.8. MIME 524 MIME format messages are generated by this mapping. As MIME 525 messages are fully RFC 822 compliant, this will not cause 526 problems with systems which are not MIME capable. 528 1.9. Body Parts 530 MIME and X.400 IPMS can both carry arbitrary body parts. This 531 specification describes mapping of the framework for structured 532 messages, but does not specify how specific body parts shall be 533 mapped. Body part mapping is an open ended problem, as new body 534 parts (attachments) will continue to be added to both X.400 and 535 MIME. 537 MIME defines a mechanism for adding new body parts, and new 538 body parts are registered with the IANA. 540 X.400 defines a mechanism adding new body parts, usually 541 referred to as Body Part 15. Extensions are defined by Object 542 Identifiers, so there is no requirement for a body part 543 registration authority. The Electronic Mail Association (EMA) 544 maintains a list of some commonly used body parts. The EMA has 545 specified a mechanism to use the File Transfer Body Part (FTBP) 546 as a more generic means to support message attachments. This 547 approach is gaining widespread commercial support. MIXER defines 548 how to map between MIME and both the Body Part 15 and EMA/FTBP 549 extension mechanisms for X.400. In many cases, this will enable 550 a gateway implementor to map between the same body part carried 551 by these mechanisms. 553 Mapping of standard IPM and MIME body parts, and some 554 extended MIME and X.400 body parts, is defined in RFC 1494bis 555 [7]. This also gives a model for specifying further mappings. 557 It will not be possible to specify all mappings. Therefore, 558 MIXER defines encapsulation mechanisms for both MIME and X.400. 559 This will allow all body parts to be transferred end to end, 560 irrespective of a mapping being defined. 562 RFC 1327bis 563 MIXER DRAFT Version 2.2 565 To provide a gateway service, it is therefore necessary for 566 an implementation to conform to both this specification and to 567 provide various body part mappings, such as those defined in RFC 568 1494bis. 570 1.10. Compatibility with previous versions 572 The changes between this and older versions of the document are 573 given in Appendices H, I and J. These are RFCs 987, 1026, | 574 1138, 1148 and 1327. This document is a revision of RFC 1327 . [ 575 As far as possible, changes have been made in a compatible [ 576 fashion. [ 578 1.11. Aspects not covered [ 580 There have been a number of cases where previous versions of this | 581 document were used in a manner which was not intended. This | 582 section is to make clear some limitations of scope. In 583 particular, this specification does not specify: 585 - Extensions of RFC 822 to provide access to all X.400 586 services 588 - X.400 user interface definition 590 These are really coupled. To map the X.400 services, this 591 specification defines a number of extensions to RFC 822. As a 592 side effect, these give the 822 user access to SOME X.400 593 services. However, the aim on the RFC 822 side is to preserve 594 current service, and it is intentional that access is not given 595 to all X.400 services. Thus, it will be a poor choice for X.400 596 implementors to use MIXER as an interface - there are too many 597 aspects of X.400 which cannot be accessed through it. If a text 598 interface is desired, a specification targeted at X.400, without 599 RFC 822 restrictions, would be more appropriate. Some optional 600 and limited extensions in this area have proved useful, and are 601 defined in Appendix C. 603 1.12. Subsetting 605 This proposal specifies a mapping which is appropriate to 606 preserve services in existing RFC 822 communities. 607 Implementations and specifications which subset this | 608 specification are non-conformant and strongly discouraged. 610 RFC 1327bis 611 MIXER DRAFT Version 2.2 613 1.13. | 614 Specification Language | 616 ISO and Internet standards have clear definitions as to the style | 617 of language used. This specification maps between ISO/ITU | 618 protocol and Internet protocols. This document uses ISO | 619 terminology for the following reasons: | 621 1. This was done in previous versions. | 623 2. ISO language may be mechanically converted to Internet | 624 language, but not vice versa. | 626 To interpet this document according to Internet rules, replace | 627 every occurrence of "shall" with "must". | 629 1.14. 630 Related Specifications 632 Mappings between Mail-11 and X.400 and Mail-11 and rfc822 are 633 described in RFC1405, using mappings related to those defined 634 here [3]. 636 1.15. Document Structure 638 This document has five chapters: 640 1. Overview - this chapter. 642 2. Service Elements - This describes the (end user) services 643 mapped by a gateway. 645 3. Basic mappings - This describes some basic notation used in 646 Chapters 3-5, the mappings between character sets, and some 647 fundamental protocol elements. 649 4. Addressing - This considers the mapping between X.400 O/R 650 names and RFC 822 addresses, which is a fundamental gateway 651 component. 653 5. Detailed Mappings - This describes the details of all other 654 mappings. 656 There are also ten appendices. 658 RFC 1327bis 659 MIXER DRAFT Version 2.2 661 WARNING: 662 THE REMAINDER OF THIS SPECIFICATION IS TECHNICALLY DETAILED. 663 IT WILL NOT MAKE SENSE, EXCEPT IN THE CONTEXT OF RFC 822 AND 664 X.400 (1988). DO NOT ATTEMPT TO READ THIS DOCUMENT UNLESS 665 YOU ARE FAMILIAR WITH THESE SPECIFICATIONS. 667 1.16. Acknowledgements 669 The work in this specification was substantially based on RFC 987 670 and RFC 1148, which had input from many people, who are credited 671 in the respective documents. 673 A number of comments from people on RFC 1148 lead to RFC 674 1327. In particular, there were comments and suggestions from: 675 Maurice Abraham (HP); Harald Alvestrand (Sintef); Peter Cowen 676 (X-Tel); Jim Craigie (JNT); Ella Gardner (MITRE); Christian 677 Huitema (Inria); Erik Huizer (SURFnet); Neil Jones (DEC); Ignacio 678 Martinez (IRIS); Julian Onions (X-Tel); Simon Poole (SWITCH); 679 Clive Roberts (Data General); Pete Vanderbilt (SUN); Alan Young 680 (Concurrent). 682 RFC 1327 has been widely adopted, and a review team was 683 formed. This comprised of: Urs Eppenberger (SWITCH)(Chair); 684 Claudio Allocchio (INFN); Harald Alvestrand (UNINETT); Dave 685 Crocker (Brandenburg); Ned Freed (Innosoft); Erik Huizer 686 (SURFnet); Steve Kille (ISODE Consortium); Peter Sylvester 687 (EdelWeb) 689 Harald Alvestrand also supplied the tables mapping DSN 690 status codes with X.400 codes. Ned Freed defined parts of the 691 File Transfer Body Part mapping. 693 Comment and input has also been received from: Samir | 694 Albadine (Transpac); Jacqui Caren (Cray); Allan Cargille (MCI); | 695 Kevin Carrosso (Innosoft); Eamon Doyle (Isocor); Jeroun Houttin 696 (Terena); Jyrki Heikkinen (ICL); Kevin Jordan (CDS); Paul | 697 Kingsnorth (DEC); Carl-Uno Manros (Manros Consulting); Robert 698 Miles (Softswitch); Michel Musy (Bull); Kenji Nonaka (NTT): Tom | 699 Oliphant (SWITCH); Julian Onions (NEXOR); Mary la Roche | 700 (Citicorp); Eftimios Tsigros (Universite Libre de Bruxelles); | 701 David Wilson (ISODE Consortium); Alan Young (ISODE Consortium); 703 RFC 1327bis 704 MIXER DRAFT Version 2.2 706 Chapter 2 - Service Elements 708 This chapter considers the services offered across a gateway 709 built according to this specification. It gives a view of the 710 functionality provided by such a gateway for communication with 711 users in the opposite domain. This chapter considers service 712 mappings in the context of SINGLE transfers only, and not 713 repeated mappings through multiple gateways. 715 2.1. The Notion of Service Across a Gateway 717 RFC 822 and X.400 provide a number of services to the end user. 718 This chapter describes the extent to which each service can be 719 supported across an X.400 <-> RFC 822 gateway. The cases 720 considered are single transfers across such a gateway, although 721 the problems of multiple crossings are noted where appropriate. 723 2.1.1. Origination of Messages 725 When a user originates a message, a number of services are 726 available. Some of these imply actions (e.g., delivery to a 727 recipient), and some are insertion of known data (e.g., 728 specification of a subject field). This chapter describes, for 729 each offered service, to what extent it is supported for a 730 recipient accessed through a gateway. There are three levels of 731 support: 733 Supported 734 The corresponding protocol elements map well, and so the 735 service can be fully provided. 737 Not Supported 738 The service cannot be provided, as there is a complete 739 mismatch. 741 Partial Support 742 The service can be partially fulfilled. 744 In the first two cases, the service is simply marked as 745 "Supported" or "Not Supported". Some explanation may be given if 746 there are additional implications, or the (non) support is not 747 intuitive. For partial support, the level of partial support is 749 RFC 1327bis 750 MIXER DRAFT Version 2.2 752 summarised. Where partial support is good, this will be 753 described by a phrase such as "Supported by use of.....". A 754 common case of this is where the service is mapped onto a non- 755 standard service on the other side of the gateway, and this would 756 have lead to support if it had been a standard service. In many 757 cases, this is equivalent to support. For partial support, an 758 indication of the mechanism is given, in order to give a feel for 759 the level of support provided. Note that this is not a 760 replacement for Chapter 5, where the mapping is fully specified. 762 If a service is described as supported, this implies: 764 - Semantic correspondence. 766 - No (significant) loss of information. 768 - Any actions required by the service element. 770 An example of a service gaining full support: If an RFC 822 771 originator specifies a Subject: field, this is considered to be 772 supported, as an X.400 recipient will get a subject indication. 774 In many cases, the required action will simply be to make the 775 information available to the end user. In other cases, actions 776 may imply generating a delivery report. 778 All RFC 822 services are supported or partially supported 779 for origination. The implications of non-supported X.400 780 services is described under X.400. 782 2.1.2. Reception of Messages 784 For reception, the list of service elements required to support 785 this mapping is specified. This is really an indication of what 786 a recipient might expect to see in a message which has been 787 remotely originated. 789 2.2. RFC 822 791 RFC 822 does not explicitly define service elements, as distinct 792 from protocol elements. However, all of the RFC 822 header 793 fields, with the exception of trace, can be regarded as 794 corresponding to implicit RFC 822 service elements. 796 RFC 1327bis 797 MIXER DRAFT Version 2.2 799 2.2.1. Origination in RFC 822 801 A mechanism of mapping, used in several cases, is to map the RFC 802 822 header into a heading extension in the IPM (InterPersonal 803 Message). This can be regarded as partial support, as it makes 804 the information available to any X.400 implementations which are 805 interested in these services. Communities which require 806 significant RFC 822 interworking are recommended to require that 807 their X.400 User Agents are able to display these heading 808 extensions. Support for the various service elements (headers) 809 is now listed. 811 Date: 812 Supported. 814 From: 815 Supported. For messages where there is also a sender field, 816 the mapping is to "Authorising Users Indication", which has 817 subtly different semantics to the general RFC 822 usage of 818 From:. 820 Sender: 821 Supported. 823 Reply-To: 824 Supported. 826 To: Supported. 828 Cc: Supported. 830 Bcc: Supported. 832 Message-Id: 833 Supported. 835 In-Reply-To: 836 Supported, for a single reference. Where multiple 837 references are given, partial support is given by mapping to 838 "Cross Referencing Indication". This gives similar 839 semantics. 841 References: 842 Supported. 844 RFC 1327bis 845 MIXER DRAFT Version 2.2 847 Keywords: 848 Supported by use of a heading extension. 850 Subject: 851 Supported. 853 Comments: 854 Supported by use of a heading extension. 856 Encrypted: 857 Supported by use of a heading extension. 859 Resent-* 860 Supported by use of a heading extension. Note that 861 addresses in these fields are mapped onto text, and so are 862 not accessible to the X.400 user as addresses. In 863 principle, fuller support would be possible by mapping onto 864 a forwarded IP Message, but this is not suggested. 866 Other Fields 867 In particular X-* fields, and "illegal" fields in common 868 usage (e.g., "Fruit-of-the-day:") are supported by use of 869 heading extensions. 871 MIME introduces the following headings, which are supported as 872 follows: 874 Content-Type: 875 Supported. The definition of MIME Content Type is somewhat 876 like X.400 Encoded Information Type, but has some aspects 877 of X.400 Content Type. The mapping is complex, but it will 878 either be mapped to an equivalent X.400 piece of information 879 or tunnelled by use of a special extended body part defined 880 in RFC 1494bis. | 882 Content-Transfer-Encoding: 883 Supported. The encoding of the information in X.400 will be 884 appropriate to the data being transferred. The service is 885 mapped in an appropriate manner. 887 Content-ID: 888 Supported in some cases. Support depend on the body part 889 and the mapping selected by the gateway. 891 RFC 1327bis 892 MIXER DRAFT Version 2.2 894 Content-Description: 895 Supported in some cases. Support depend on the body part 896 and the mapping selected by the gateway. 898 MIME-Version: 899 Supported by use of a heading extension. 901 MIME, like RFC 822, does not explicitly define services. It is 902 useful in the service section to note support for MIME Content 903 types that do not map directly to atomic body parts: 905 multipart/mixed 906 Supported. 908 multipart/alternative 909 Partially supported. No data is lost. The fact that the 910 body parts are alternatives is indicated in a heading 911 extension, and there is no guarantee that this can be 912 interpreted by an X.400 user agent, and by a subject line. 914 multipart/digest 915 Supported. 917 multipart/parallel 918 Partially supported. No data is lost. The fact that the | 919 body parts are parallel is indicated in a heading extension, 920 which may not be interpreted by an X.400 user agent, and by 921 a subject line. 923 multipart/unknown 924 Supported. Unknown semantics are not mapped. 926 message/rfc822 927 Supported. 929 message/partial 930 Supported by mapping of message fragments to X.400 messages. 931 X.400 User Agents will not in general be able to 932 automatically reassemble fragments. 934 message/external-body 935 Supported by incorporating the external body into the X.400 936 message. 938 RFC 1327bis 939 MIXER DRAFT Version 2.2 941 message/unknown 942 Supported. Unknown semantics are not mapped. 944 other | 946 RFC 1327bis 947 MIXER DRAFT Version 2.2 949 Support for the other MIME content types (text, application, 950 image, audio, video) is defined in RFC 1494bis, with a | 951 fallback mechanism for undefined an unrecognised types | 952 defined in MIXER. 954 2.2.2. Reception by RFC 822 956 This considers reception by an RFC 822 User Agent of a message 957 originated in an X.400 system and transferred across a gateway. 958 The following standard services (headers) may be present in such 959 a message: 961 Date: 963 From: 965 Sender: 967 Reply-To: 969 To: 971 Cc: 973 Bcc: 975 Message-Id: 977 In-Reply-To: 979 References: 981 Subject: 983 Content-Type: 985 Content-Transfer-Encoding: 987 MIME-Version: 989 RFC 1327bis 990 MIXER DRAFT Version 2.2 992 The following non-standard services (headers) may be present in 993 the header of a message. These are defined in more detail in 994 Chapter 5 (5.3.4, 5.3.6, 5.3.7): 996 Autoforwarded: 998 Autosubmitted: 1000 X400-Content-Identifier: 1002 Content-Language: 1004 Conversion: 1006 Conversion-With-Loss: 1008 Delivery-Date: 1010 Discarded-X400-IPMS-Extensions: 1012 Discarded-X400-MTS-Extensions: 1014 DL-Expansion-History: 1016 Deferred-Delivery: 1018 Expiry-Date: 1020 Importance: 1022 Incomplete-Copy: 1024 Latest-Delivery-Time: 1026 Message-Type: 1028 Obsoletes: 1030 Original-Encoded-Information-Types: 1032 Originator-Return-Address: 1034 Priority: 1036 RFC 1327bis 1037 MIXER DRAFT Version 2.2 1039 Reply-By: 1041 Requested-Delivery-Method: 1043 Sensitivity: 1045 X400-Content-Type: 1047 X400-MTS-Identifier: 1049 X400-Originator: 1051 X400-Received: 1053 X400-Recipients: 1055 2.3. X.400 1057 2.3.1. Origination in X.400 1059 When mapping services from X.400 to RFC 822 which are not 1060 supported by RFC 822, new RFC 822 headers are defined, and | 1061 registered by publication in this standard. It is intended that | 1062 co-operating RFC 822 systems may also use them. Where these new 1063 fields are used, and no system action is implied, the service can 1064 be regarded as being partially supported. Chapter 5 describes 1065 how to map X.400 services onto these new headers. Other elements 1066 are provided, in part, by the gateway as they cannot be provided 1067 by RFC 822. 1069 Some service elements are marked N/A (not applicable). 1070 There are five cases, which are marked with different comments: 1072 N/A (local) 1073 These elements are only applicable to User Agent / Message 1074 Transfer Agent interaction and so they cannot apply to RFC 1075 822 recipients. 1077 N/A (PDAU) 1078 These service elements are only applicable where the 1079 recipient is reached by use of a Physical Delivery Access 1080 Unit (PDAU), and so do not need to be mapped by the gateway. 1082 N/A (reception) 1084 RFC 1327bis 1085 MIXER DRAFT Version 2.2 1087 These services are only applicable for reception. 1089 N/A (prior) 1090 If requested, this service must be performed prior to the 1091 gateway. 1093 N/A (MS) 1094 These services are only applicable to Message Store (i.e., a 1095 local service). 1097 Finally, some service elements are not supported. In 1098 particular, the new security services are not mapped onto RFC 1099 822. Unless otherwise indicated, the behaviour of service 1100 elements marked as not supported will depend on the criticality 1101 marking supplied by the user. If the element is marked as 1102 critical for transfer or delivery, a non-delivery notification 1103 will be generated. Otherwise, the service request will be 1104 ignored. 1106 2.3.1.1. Basic Interpersonal Messaging Service 1108 These are the mandatory IPM services as listed in Section 19.8 of 1109 X.400 / ISO/IEC 10021-1, listed here in the order given. Section 1110 19.8 has cross references to short definitions of each service. 1112 Access management 1113 N/A (local). 1115 Content Type Indication 1116 Supported by a new RFC 822 header (X400-Content-Type:). | 1118 Converted Indication 1119 Supported by a new RFC 822 header (X400-Received:). 1121 Delivery Time Stamp Indication 1122 N/A (reception). 1124 IP Message Identification 1125 Supported. 1127 Message Identification 1128 Supported, by use of a new RFC 822 header 1129 (X400-MTS-Identifier). This new header is required, as 1130 X.400 has two message-ids whereas RFC 822 has only one (see 1132 RFC 1327bis 1133 MIXER DRAFT Version 2.2 1135 IP Message Identification 1137 Non-delivery Notification 1138 Not supported in all cases. Supported where the recipient 1139 system supports NOTARY DSNs. In general all RFC 822 systems 1140 will return error reports by use of IP messages. In other 1141 service elements, this pragmatic result can be treated as 1142 effective support of this service element. 1144 Original Encoded Information Types Indication 1145 Supported as a new RFC 822 header 1146 (Original-Encoded-Information-Types:). 1148 Submission Time Stamp Indication 1149 Supported. 1151 Typed Body 1152 The mapping of ForwardedIPMessage and IA5 body parts is 1153 defined and supported. A framework form mapping other body 1154 parts, including encapsulation mechanism is defined. 1155 Mapping of standard body parts and selected other body parts 1156 is defined in RFC 1494bis. 1158 User Capabilities Registration 1159 N/A (local). 1161 2.3.1.2. IPM Service Optional User Facilities 1163 This section describes support for the optional (user selectable) 1164 IPM services as listed in Section 19.9 of X.400 / ISO/IEC 10021- 1165 1, listed here in the order given. Section 19.9 has cross 1166 references to short definitions of each service. 1168 Additional Physical Rendition 1169 N/A (PDAU). 1171 Alternate Recipient Allowed 1172 Not supported. There is no RFC 822 service equivalent to 1173 prohibition of alternate recipient assignment (e.g., an RFC 1174 822 system may freely send an undeliverable message to a 1175 local postmaster). Thus, the gateway cannot prevent 1176 assignment of alternative recipients on the RFC 822 side. 1177 This service really means giving the user control as to 1178 whether or not an alternate recipient is allowed. This 1180 RFC 1327bis 1181 MIXER DRAFT Version 2.2 1183 specification requires transfer of messages to RFC 822 1184 irrespective of this service request, and so this service is 1185 not supported. 1187 Authorising User's Indication 1188 Supported. 1190 Auto-forwarded Indication 1191 Supported as new RFC 822 header (Auto-Forwarded:). 1193 Basic Physical Rendition 1194 N/A (PDAU). 1196 Blind Copy Recipient Indication 1197 Supported. 1199 Body Part Encryption Indication 1200 Supported by use of a new RFC 822 header 1201 (Original-Encoded-Information-Types:), although in most 1202 cases it will not be possible to map the body part in 1203 question. 1205 Content Confidentiality 1206 Not supported. 1208 Content Integrity 1209 Not supported. 1211 Conversion Prohibition 1212 Supported. Operation defined in RFC 1494bis. | 1214 Conversion Prohibition in Case of Loss of Information 1215 Supported. Operation defined in RFC 1494bis. | 1217 Counter Collection 1218 N/A (PDAU). 1220 Counter Collection with Advice 1221 N/A (PDAU). 1223 Cross Referencing Indication 1224 Supported. 1226 Deferred Delivery 1228 RFC 1327bis 1229 MIXER DRAFT Version 2.2 1231 N/A (prior). This service should always be provided by the 1232 MTS prior to the gateway. A new RFC 822 header 1233 (Deferred-Delivery:) is provided to transfer information on 1234 this service to the recipient. 1236 Deferred Delivery Cancellation 1237 N/A (local). 1239 Delivery Notification 1240 Supported. This is performed at the gateway, but may be 1241 performed at the end system if the end system supports 1242 NOTARY. Thus, a notification is sent by the gateway to the 1243 originator. * 1245 Delivery via Bureaufax Service 1246 N/A (PDAU). 1248 Designation of Recipient by Directory Name 1249 N/A (local). 1251 Disclosure of Other Recipients 1252 Supported by use of a new RFC 822 header (X400-Recipients:). 1253 This is descriptive information for the RFC 822 recipient, 1254 and is not reverse mappable. 1256 DL Expansion History Indication 1257 Supported by use of a new RFC 822 header 1258 (DL-Expansion-History:). 1260 DL Expansion Prohibited 1261 Distribution List means MTS supported distribution list, in 1262 the manner of X.400. This service does not exist in the RFC 1263 822 world. RFC 822 distribution lists should be regarded in | 1264 X.400 terms as an informal redistribution mechanism, beyond 1265 the scope of this control. Messages will be sent to RFC 822 | 1266 distribution lists, irrespective of whether this service is | 1267 requested. Theoretically therefore, this service is | 1268 supported, although in practice it is not supported. 1270 Express Mail Service 1271 N/A (PDAU). 1273 Expiry Date Indication 1274 Supported as new RFC 822 header (Expiry-Date:). In general, 1276 RFC 1327bis 1277 MIXER DRAFT Version 2.2 1279 no automatic action can be expected. 1281 Explicit Conversion 1282 N/A (prior). 1284 Forwarded IP Message Indication 1285 Supported. | 1287 Grade of Delivery Selection 1288 Not Supported. There is no equivalent service in RFC 822. | 1290 Importance Indication 1291 Supported as new RFC 822 header (Importance:). 1293 Incomplete Copy Indication 1294 Supported as new RFC 822 header (Incomplete-Copy:). 1296 Language Indication 1297 Supported as new RFC 822 header (Language:). 1299 Latest Delivery Designation 1300 Not supported. A new RFC 822 header (Latest-Delivery-Time:) 1301 is provided, which may be used by the recipient. 1303 Message Flow Confidentiality 1304 Not supported. 1306 Message Origin Authentication 1307 N/A (reception). 1309 Message Security Labelling 1310 Not supported. 1312 Message Sequence Integrity 1313 Not supported. 1315 Multi-Destination Delivery 1316 Supported. 1318 Multi-part Body 1319 Supported. 1321 Non Receipt Notification Request 1322 Not supported. 1324 RFC 1327bis 1325 MIXER DRAFT Version 2.2 1327 Non Repudiation of Delivery 1328 Not supported. 1330 Non Repudiation of Origin 1331 N/A (reception). 1333 Non Repudiation of Submission 1334 N/A (local). 1336 Obsoleting Indication 1337 Supported as new RFC 822 header (Obsoletes:). 1339 Ordinary Mail 1340 N/A (PDAU). 1342 Originator Indication 1343 Supported. 1345 Originator Requested Alternate Recipient 1346 Not supported, but is placed as comment next to address 1347 (X400-Recipients:). 1349 Physical Delivery Notification by MHS 1350 N/A (PDAU). 1352 Physical Delivery Notification by PDS 1353 N/A (PDAU). 1355 Physical Forwarding Allowed 1356 Supported by use of a comment in a new RFC 822 header 1357 (X400-Recipients:), associated with the recipient in 1358 question. 1360 Physical Forwarding Prohibited 1361 Supported by use of a comment in a new RFC 822 header 1362 (X400-Recipients:), associated with the recipient in 1363 question. 1365 Prevention of Non-delivery notification 1366 Supported where SMTP and NOTARY are available. In other | 1367 cases formally supported, as delivery notifications cannot | 1368 be generated by RFC 822. In practice, errors will be 1369 returned as IP Messages, and so this service may appear not 1370 to be supported (see Non-delivery Notification). 1372 RFC 1327bis 1373 MIXER DRAFT Version 2.2 1375 Primary and Copy Recipients Indication 1376 Supported 1378 Probe 1379 Supported at the gateway (i.e., the gateway services the 1380 probe). 1382 Probe Origin Authentication 1383 N/A (reception). 1385 Proof of Delivery 1386 Not supported. 1388 Proof of Submission 1389 N/A (local). 1391 Receipt Notification Request Indication 1392 Not supported. | 1394 Redirection Disallowed by Originator | 1395 Redirection means MTS supported redirection, in the manner 1396 of X.400. This service does not exist in the RFC 822 world. 1397 RFC 822 redirection (e.g., aliasing) should be regarded as 1398 an informal redirection mechanism, beyond the scope of this 1399 control. Messages will be sent to RFC 822, irrespective of | 1400 whether this service is requested. In practice, control of | 1401 this service is not supported. 1403 Registered Mail 1404 N/A (PDAU). 1406 Registered Mail to Addressee in Person 1407 N/A (PDAU). 1409 Reply Request Indication 1410 Supported as comment next to address. 1412 Replying IP Message Indication 1413 Supported. 1415 Report Origin Authentication 1416 N/A (reception). 1418 Request for Forwarding Address 1420 RFC 1327bis 1421 MIXER DRAFT Version 2.2 1423 N/A (PDAU). 1425 Requested Delivery Method 1426 N/A (local). The services required must be dealt with at 1427 submission time. Any such request is made available through 1428 the gateway by use of a comment associated with the 1429 recipient in question. 1431 Return of Content 1432 Supported where SMTP and NOTARY are used. In principle for | 1433 other situations, this is N/A, as non-delivery notifications | 1434 are not supported. In practice, most RFC 822 systems will 1435 return part or all of the content along with the IP Message 1436 indicating an error (see Non-delivery Notification). 1438 Sensitivity Indication 1439 Supported as new RFC 822 header (Sensitivity:). 1441 Special Delivery 1442 N/A (PDAU). 1444 Stored Message Deletion 1445 N/A (MS). 1447 Stored Message Fetching 1448 N/A (MS). 1450 Stored Message Listing 1451 N/A (MS). 1453 Stored Message Summary 1454 N/A (MS). 1456 Subject Indication 1457 Supported. 1459 Undeliverable Mail with Return of Physical Message 1460 N/A (PDAU). 1462 Use of Distribution List 1463 In principle this applies only to X.400 supported 1464 distribution lists (see DL Expansion Prohibited). 1465 Theoretically, this service is N/A (prior). In practice, 1466 because of informal RFC 822 lists, this service can be 1468 RFC 1327bis 1469 MIXER DRAFT Version 2.2 1471 regarded as supported. 1473 Auto-Submitted Indication 1474 Supported 1476 2.3.2. Reception by X.400 1478 2.3.2.1. Standard Mandatory Services 1480 The following standard IPM mandatory user facilities are 1481 required for reception of RFC 822 originated mail by an X.400 UA. 1483 Content Type Indication 1485 Delivery Time Stamp Indication 1487 IP Message Identification 1489 Message Identification 1491 Non-delivery Notification 1493 Original Encoded Information Types Indication 1495 Submission Time Stamp Indication 1497 Typed Body 1499 2.3.2.2. Standard Optional Services 1501 The following standard IPM optional user facilities are required 1502 for reception of RFC 822 originated mail by an X.400 UA. 1504 Authorising User's Indication 1506 Blind Copy Recipient Indication 1508 Cross Referencing Indication 1510 Originator Indication 1512 Primary and Copy Recipients Indication 1514 RFC 1327bis 1515 MIXER DRAFT Version 2.2 1517 Replying IP Message Indication 1519 Subject Indication 1521 2.3.2.3. New Services 1523 A new X.400 service "RFC 822 Header Field" is defined using the | 1524 extension facilities. This allows for any RFC 822 header field 1525 to be represented. It may be present in RFC 822 originated | 1526 messages which are received by an X.400 UA. 1528 RFC 1327bis 1529 MIXER DRAFT Version 2.2 1531 Chapter 3 Basic Mappings 1533 3.1. Notation 1535 The X.400 protocols are encoded in a structured manner according 1536 to ASN.1, whereas RFC 822 is text encoded. To define a detailed 1537 mapping, it is necessary to refer to detailed protocol elements 1538 in each format. A notation to achieve this is described in this 1539 section. 1541 3.1.1. RFC 822 1543 Structured text is defined according to the Extended Backus Naur 1544 Form (EBNF) defined in Section 2 of RFC 822 [16]. In the EBNF 1545 definitions used in this specification, the syntax rules given in 1546 Appendix D of RFC 822 are assumed. When these EBNF tokens are 1547 referred to outside an EBNF definition, they are identified by 1548 the string "822." appended to the beginning of the string (e.g., 1549 822.addr-spec). Additional syntax rules, to be used throughout 1550 this specification, are defined in this chapter. 1552 The EBNF is used in two ways. 1554 1. To describe components of RFC 822 messages (or of SMTP | 1555 components). When these new EBNF tokens are referred to 1556 outside an EBNF definition, they are identified by the 1557 string "EBNF." appended to the beginning of the string 1558 (e.g., EBNF.importance). 1560 2. To describe the structure of IA5 or ASCII information not in 1561 an RFC 822 message. 1563 For all new EBNF, tokens will either be self delimiting, or be 1564 delimited by self delimiting tokens. Comments and LWSP are not 1565 used as delimiters, except for the following cases, where LWSP 1566 may be inserted according to RFC 822 rules. 1568 - Around the ":" in all headers 1570 - EBNF.labelled-integer 1572 RFC 1327bis 1573 MIXER DRAFT Version 2.2 1575 - EBNF.object-identifier 1577 - EBNF.encoded-info 1579 RFC 822 folding rules are applied to all headers. Comments are 1580 never used in these new headers. 1582 This notation is used in a modified form to refer to NOTARY 1583 ENBF [29]. For this EBNF, the keyword EBNF it replaces with DSN, | 1584 for example DSN.final-recipient-field fields. 1586 3.1.2. ASN.1 1588 An element is referred to with the following syntax, defined in 1589 EBNF: 1591 element = service "." definition *( "." definition ) 1592 service = "IPMS" / "MTS" / "MTA" 1593 definition = identifier / context 1594 identifier = ALPHA *< ALPHA or DIGIT or "-" > 1595 context = "[" 1*DIGIT "]" 1597 The EBNF.service keys are shorthand for the following service 1598 specifications: 1600 IPMS IPMSInformationObjects defined in Annex E of X.420 / ISO 1601 10021-7. 1603 MTS MTSAbstractService defined in Section 9 of X.411 / ISO 1604 10021-4. 1606 MTA MTAAbstractService defined in Section 13 of X.411 / ISO 1607 10021-4. 1609 FTBP File Transfer Body Part, as defined in [28]. LP The first 1610 EBNF.identifier identifies a type or value key in the 1611 context of the defined service specification. Subsequent 1612 EBNF.identifiers identify a value label or type in the 1613 context of the first identifier (SET or SEQUENCE). 1614 EBNF.context indicates a context tag, and is used where 1615 there is no label or type to uniquely identify a component. 1616 The special EBNF.identifier keyword "value" is used to 1617 denote an element of a sequence. 1619 RFC 1327bis 1620 MIXER DRAFT Version 2.2 1622 For example, IPMS.Heading.subject defines the subject element of 1623 the IPMS heading. The same syntax is also used to refer to 1624 element values. For example, 1625 MTS.EncodedInformationTypes.[0].g3Fax refers to a value of 1626 MTS.EncodedInformationTypes.[0] . 1628 3.2. ASCII and IA5 1630 A gateway will interpret all IA5 as ASCII. Thus, mapping between 1631 these forms is conceptual. 1633 3.3. Standard Types 1635 There is a need to convert between ASCII text and some of the | 1636 types defined in ASN.1 [14]. For each case, an EBNF syntax 1637 definition is given, for use in all of this specification, which 1638 leads to a mapping between ASN.1, and an EBNF construct. All 1639 EBNF syntax definitions of ASN.1 types are in lower case, whereas 1640 ASN.1 types are referred to with the first letter in upper case. 1641 Except as noted, all mappings are symmetrical. 1643 3.3.1. Boolean 1645 Boolean is encoded as: 1647 boolean = "TRUE" / "FALSE" 1649 3.3.2. NumericString 1651 NumericString is encoded as: 1653 numericstring = *DIGIT 1655 3.3.3. PrintableString 1657 PrintableString is a restricted IA5String defined as: 1659 printablestring = *( ps-char ) 1660 ps-restricted-char = 1DIGIT / 1ALPHA / " " / "'" / "+" 1661 / "," / "-" / "." / "/" / ":" / "=" / "?" 1662 ps-delim = "(" / ")" 1663 ps-char = ps-delim / ps-restricted-char 1665 RFC 1327bis 1666 MIXER DRAFT Version 2.2 1668 This can be used to represent real printable strings in EBNF. 1670 3.3.4. T.61String 1672 In cases where T.61 strings are only used for conveying human 1673 interpreted information, the aim of a mapping is to render the 1674 characters appropriately in the remote character set, rather than 1675 to maximise reversibility. For these cases, there are two 1676 options, both of which are conformant to this specification: 1678 1. The mappings to IA5 defined in ITU Recommendation X.408 1679 (1988) may be used [13]. These will then be encoded in 1680 ASCII. This is the approach mandated in RFC 1327. 1682 2. This mapping may be used if the characters are not contained 1683 within ASCII repertoire, but are all in an IANA-registered 1684 character set. Use the encoding defined in RFC 1522 [9]. | 1685 to generate appropriate encoded-words. If this mapping is | 1686 used, the character set ISO-8859-1 shall be used if all of | 1687 the characters needed are available in this repertoire. In | 1688 other cases, the character set TELETEX shall be used. The | 1689 details of these mappings are defined in the Appendix of | 1690 RFC1494bis. 1692 There is also a need to represent Teletex Strings in ASCII, 1693 for some aspects of O/R Address. For these, the following 1694 encoding is used: 1696 teletex-string = *( ps-char / t61-encoded ) 1697 t61-encoded = "{" 1* t61-encoded-char "}" 1698 t61-encoded-char = 3DIGIT 1700 Characters in EBNF.ps-char are mapped simply. Other octets, | 1701 including control characters, are mapped using a quoting 1702 mechanism similar to the printable string mechanism. Each octet 1703 is represented as 3 decimal digits. 1705 There are a number of places where a string may have a Teletex 1706 and/or Printable String representation. The following BNF is 1707 used to represent this. 1709 teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ] 1711 The natural mapping is restricted to EBNF.ps-char, in order to 1713 RFC 1327bis 1714 MIXER DRAFT Version 2.2 1716 make the full BNF easier to parse. 1718 3.3.5. UTCTime 1720 Both UTCTime and the RFC 822 822.date-time syntax contain: Year 1721 (lowest two digits), Month, Day of Month, hour, minute, second 1722 (optional), and Timezone. 822.date-time also contains an 1723 optional day of the week, but this is redundant. Therefore a 1724 symmetrical mapping can be made between these constructs. 1726 Note: 1727 In practice, a gateway will need to parse various illegal 1728 variants on 822.date-time. In cases where 822.date-time 1729 cannot be parsed, it is recommended that the derived UTCTime 1730 is set to the value at the time of translation. 1732 When mapping to X.400, the UTCTime format which specifies the 1733 timezone offset shall be used. 1735 When mapping to RFC 822, the 822.date-time format shall include a 1736 numeric timezone offset (e.g., +0000). 1738 When mapping time values, the timezone shall be preserved as 1739 specified. The date shall not be normalised to any other 1740 timezone. 1742 3.3.6. Integer 1744 A basic ASN.1 Integer will be mapped onto EBNF.numericstring. In 1745 many cases ASN.1 will enumerate Integer values or use ENUMERATED. 1746 An EBNF encoding labelled-integer is provided. When mapping from 1747 EBNF to ASN.1, only the integer value is mapped, and the 1748 associated text is discarded. When mapping from ASN.1 to EBNF, 1749 addition of an appropriate text label is strongly encouraged. 1751 labelled-integer ::= [ key-string ] "(" numericstring ")" 1753 key-string = *key-char 1754 key-char = 1756 3.3.7. Object Identifier 1758 Object identifiers are represented in a form similar to that 1760 RFC 1327bis 1761 MIXER DRAFT Version 2.2 1763 given in ASN.1. The order is the same as for ASN.1 (big-endian). 1764 The numbers are mandatory, and used when mapping from the ASCII 1765 to ASN.1. The key-strings are optional. It is recommended that 1766 as many strings as possible are generated when mapping from ASN.1 1767 to ASCII, to facilitate user recognition. 1769 object-identifier ::= oid-comp object-identifier 1770 | oid-comp 1772 oid-comp ::= [ key-string ] "(" numericstring ")" 1774 An example representation of an object identifier is: 1776 joint-iso-ccitt(2) mhs (6) ipms (1) ep (11) ia5-text (0) 1778 or 1780 (2) (6) (1)(11)(0) 1782 Because of the use of brackets and the conflict with the RFC 822 | 1783 comment convention, this syntax is not used in structures fields. 1785 3.4. Encoding ASCII in Printable String 1787 Some information in RFC 822 is represented in ASCII, and needs to 1788 be mapped into X.400 elements encoded as printable string. For 1789 this reason, a mechanism to represent ASCII encoded as 1790 PrintableString is needed. 1792 A structured subset of EBNF.printablestring is now defined. 1793 This shall be used to encode ASCII in the PrintableString 1794 character set. 1796 ps-encoded = *( ps-restricted-char / ps-encoded-char ) 1797 ps-encoded-char = "(a)" ; (@) 1798 / "(p)" ; (%) 1799 / "(b)" ; (!) 1800 / "(q)" ; (") 1801 / "(u)" ; (_) 1802 / "(l)" ; "(" 1803 / "(r)" ; ")" 1804 / "(" 3DIGIT ")" 1806 The 822.3DIGIT in EBNF.ps-encoded-char must have range 0-127, and 1808 RFC 1327bis 1809 MIXER DRAFT Version 2.2 1811 is interpreted in decimal as the corresponding ASCII character. 1812 Special encodings are given for: at sign (@), percent (%), 1813 exclamation mark/bang (!), double quote ("), underscore (_), left 1814 bracket ((), and right bracket ()). These characters, with the 1815 exception of round brackets, are not included in PrintableString, 1816 but are common in RFC 822 addresses. The abbreviations will ease 1817 specification of RFC 822 addresses from an X.400 system. These 1818 special encodings shall be interpreted in a case insensitive 1819 manner, but always generated in lower case. 1821 A reversible mapping between PrintableString and ASCII can 1822 now be defined. The reversibility means that some values of 1823 printable string (containing round braces) cannot be generated 1824 from ASCII. Therefore, this mapping must only be used in cases 1825 where the printable strings may only be derived from ASCII (and 1826 will therefore have a restricted domain). For example, in this 1827 specification, it is only applied to a Domain Defined Attribute 1828 which will have been generated by use of this specification and a 1829 value such as "(" would not be possible. 1831 To encode ASCII as PrintableString, the EBNF.ps-encoded 1832 syntax is used, with all EBNF.ps-restricted-char mapped directly. 1833 All other 822.CHAR are encoded as EBNF.ps-encoded-char. 1835 To encode PrintableString as ASCII, parse PrintableString as 1836 EBNF.ps-encoded, and then reverse the previous mapping. If the 1837 PrintableString cannot be parsed, then the mapping is being 1838 applied in to an inappropriate value, and an error shall be given 1839 to the procedure doing the mapping. In some cases, it may be 1840 preferable to pass the printable string through unaltered. 1842 Some examples are now given. Note the arrows which indicate 1843 asymmetrical mappings: 1845 PrintableString ASCII 1847 'a demo.' <-> 'a demo.' 1848 foo(a)bar <-> foo@bar 1849 (q)(u)(p)(q) <-> "_%" 1850 (a) <-> @ 1851 (A) -> @ 1852 (l)a(r) <-> (a) 1853 (126) <-> ~ 1854 ( -> ( 1856 RFC 1327bis 1857 MIXER DRAFT Version 2.2 1859 (l) <-> ( 1861 3.5. RFC 1522 1863 RFC 1522 defines a mechanism for encoding other character set 1864 information into elements of RFC 822 Headers. A gateway may 1865 ignore this encoding and treat the elements as ASCII. 1867 A preferred approach is for the gateway to interpret the RFC 1868 1522 encoding. This will not always be straightforward, because: 1870 1. RFC 1522 permits an openly extensible character set choice, 1871 which may be broader than T.61. 1873 2. It may not be possible to map all characters into the 1874 equivalent X.400 field. 1876 RFC 1522 is only applied to fields which are "for information 1877 only". A gateway which interprets header elements according to 1878 RFC 1522 may apply reasonable heuristics to minimise information 1879 loss. 1881 RFC 1327bis 1882 MIXER DRAFT Version 2.2 1884 Chapter 4 - Addressing and Message IDs 1886 Addressing is the most complex aspect of X.400 <-> RFC 822 1887 gateway and is therefore given a separate chapter. This chapter 1888 also discusses message identifiers, as they are closely linked to 1889 addresses. This chapter, as a side effect, also defines a 1890 textual representation of an X.400 O/R Address. This 1891 specification has much similarity to the X.400(92) representation 1892 of addresses. This was because early versions of this 1893 specification were a major input to this work. This 1894 specification retains compatibility with earlier versions. The | 1895 the X.400 specification of address representation can be parsed | 1896 but is not generated. 1898 Initially we consider an address in the (human) mail user 1899 sense of "what is typed at the mailsystem to reference a mail 1900 user". A basic RFC 822 address is defined by the EBNF 1901 EBNF.822-address: 1903 822-address = [ route ] addr-spec 1905 In SMTP (or another 822-MTS protocol), the originator and each | 1906 recipient are considered to be defined by such a construct. In 1907 an RFC 822 header, the EBNF.822-address is encapsulated in the 1908 822.address syntax rule, and there may also be associated 1909 comments. None of this extra information has any semantics, 1910 other than to the end user. 1912 The basic X.400 O/R Address, used by the MTS for routing, is 1913 defined by MTS.ORAddress. In IPMS, the MTS.ORAddress is 1914 encapsulated within IPMS.ORDescriptor. 1916 It can be seen that RFC 822 822.address must be mapped with 1917 IPMS.ORDescriptor, and that RFC 822 EBNF.822-address must be 1918 mapped with MTS.ORAddress. 1920 Section 4.1 defines a textual representation of an O/R 1921 Address, which is used throughout the rest of this specification. 1922 This text representation is designed to represent an X.400 1923 address in the LHS (local part) of an RFC 822 address, and so 1924 this representation gives a mechanism to represent X.400 | 1925 addresses within RFC 822 addresses. 1927 RFC 1327bis 1928 MIXER DRAFT Version 2.2 1930 Section 4.2 describes a global equivalence mapping between 1931 parts of the X.400 and RFC 822 name spaces, which gateways 1932 conforming to this specification must support. 1934 Section 4.3 is the core part of this chapter, and defines 1935 the mapping mechanism. 1937 4.1. A textual representation of MTS.ORAddress 1939 MTS.ORAddress is structured as a set of attribute value pairs. 1940 It is clearly necessary to be able to encode this in ASCII for 1941 gatewaying purposes. All components shall be encoded, in order 1942 to guarantee return of error messages, and to optimise third 1943 party replies. 1945 4.1.1. Basic O/R Address Representation 1947 An O/R Address has a number of structured and unstructured 1948 attributes. For each unstructured attribute, a key and an 1949 encoding is specified. For structured attributes, the X.400 1950 attribute is mapped onto one or more attribute value pairs. For 1951 domain defined attributes, each element of the sequence will be 1952 mapped onto a triple (key and two values), with each value having 1953 the same encoding. The attributes are as follows, with 1984 1954 attributes given in the first part of the table. For each 1955 attribute, a reference is given, consisting of the relevant 1956 sections in X.402 / ISO 10021-2, and the extension identifier for 1957 88 only attributes: 1959 Attribute (Component) Key Enc Ref Id 1961 84/88 Attributes 1963 MTS.CountryName C P 18.3.3 1964 MTS.AdministrationDomainName ADMD P 18.3.1 1965 MTS.PrivateDomainName PRMD P 18.3.21 1966 MTS.NetworkAddress X121 N 18.3.7 1967 MTS.TerminalIdentifier T-ID P 18.3.23 1968 MTS.OrganizationName O P/T 18.3.9 1969 MTS.OrganizationalUnitNames.value OU P/T 18.3.10 1970 MTS.NumericUserIdentifier UA-ID N 18.3.8 1971 MTS.PersonalName PN P/T 18.3.12 1972 MTS.PersonalName.surname S P/T 18.3.12 1973 RFC 1327bis 1974 MIXER DRAFT Version 2.2 1976 MTS.PersonalName.given-name G P/T 18.3.12 1977 MTS.PersonalName.initials I P/T 18.3.12 1978 MTS.PersonalName 1979 .generation-qualifier GQ P/T 18.3.12 1980 MTS.DomainDefinedAttribute.value DD P/T 18.1 1982 88 Attributes 1984 MTS.CommonName CN P/T 18.3.2 1 1985 MTS.TeletexCommonName CN P/T 18.3.2 2 1986 MTS.TeletexOrganizationName O P/T 18.3.9 3 1987 MTS.TeletexPersonalName PN P/T 18.3.12 4 1988 MTS.TeletexPersonalName.surname S P/T 18.3.12 4 1989 MTS.TeletexPersonalName.given-name G P/T 18.3.12 4 1990 MTS.TeletexPersonalName.initials I P/T 18.3.12 4 1991 MTS.TeletexPersonalName 1992 .generation-qualifier GQ P/T 18.3.12 4 1993 MTS.TeletexOrganizationalUnitNames 1994 .value OU P/T 18.3.10 5 1995 MTS.TeletexDomainDefinedAttribute 1996 .value DD P/T 18.1 6 1997 MTS.PDSName PD-SERVICE P 18.3.11 7 1998 MTS.PhysicalDeliveryCountryName PD-C P 18.3.13 8 1999 MTS.PostalCode PD-CODE P 18.3.19 9 2000 MTS.PhysicalDeliveryOfficeName PD-OFFICE P/T 18.3.14 10 2001 MTS.PhysicalDeliveryOfficeNumber PD-OFFICE-NUM P/T 18.3.15 11 2002 MTS.ExtensionORAddressComponents PD-EXT-ADDRESS P/T 18.3.4 12 2003 MTS.PhysicalDeliveryPersonName PD-PN P/T 18.3.17 13 2004 MTS.PhysicalDeliveryOrganizationName PD-O P/T 18.3.16 14 2005 MTS.ExtensionPhysicalDelivery 2006 AddressComponents PD-EXT-DELIVERY P/T 18.3.5 15 2007 MTS.UnformattedPostalAddress PD-ADDRESS UPA 18.3.25 16| 2008 MTS.StreetAddress PD-STREET P/T 18.3.22 17 2009 MTS.PostOfficeBoxAddress PD-BOX P/T 18.3.18 18 2010 MTS.PosteRestanteAddress PD-RESTANTE P/T 18.3.20 19 2011 MTS.UniquePostalName PD-UNIQUE P/T 18.3.26 20 2012 MTS.LocalPostalAttributes PD-LOCAL P/T 18.3.6 21 2013 MTS.ExtendedNetworkAddress 2014 .e163-4-address.number NET-NUM N 18.3.7 22 2015 MTS.ExtendedNetworkAddress 2016 .e163-4-address.sub-address NET-SUB N 18.3.7 22 2017 MTS.ExtendedNetworkAddress 2018 .psap-address NET-PSAP X 18.3.7 22 2019 MTS.TerminalType T-TY I 18.3.24 23 2020 RFC 1327bis 2021 MIXER DRAFT Version 2.2 2023 The following keys identify different EBNF encodings, which are 2024 associated with the ASCII representation of MTS.ORAddress. 2026 Key Encoding 2028 P printablestring 2029 N numericstring 2030 T teletex-string 2031 P/T teletex-and-or-ps 2032 UPA upa-string | 2033 I labelled-integer 2034 X presentation-address 2036 The BNF for presentation-address is taken from the specification 2037 RFC 1278 "A String Encoding of Presentation Address" [24]. 2039 In most cases, the EBNF encoding maps directly to the ASN.1 2040 encoding of the attribute. There are a few exceptions. In cases 2041 where an attribute can be encoded as either a PrintableString or 2042 NumericString (Country, ADMD, PRMD), either form is mapped into 2043 the BNF. When generating ASN.1, the NumericString encoding shall | 2044 be used if the string contains digits and only digits. 2046 There are a number of cases where the P/T (teletex-and-or-ps) 2047 representation is used. Where the key maps to a single 2048 attribute, this choice is reflected in the encoding of the 2049 attribute (attributes 10-21). For most of the 1984 attributes 2050 and common name, there is a printablestring and a teletex 2051 variant. This pair of attributes is mapped onto the single 2052 component here. This will give a clean mapping for the common 2053 cases where only one form of the name is used. | 2055 The Unformatted Postal Address has a slightly more complex | 2056 mapping onto a variant of (teletex-and-or-ps), defined as: | 2058 upa-string = [ printable-upa ] [ "*" teletex-string ] 2059 printable-upa = printablestring *( "|" printablestring ) 2061 The optional teletex part is straightforward. There is an | 2062 (optional) sequence of printable strings which are mapped in | 2063 order. For example: | 2065 /PD-ADDRESS=The Dome|The Square|Richmond|England/ 2067 RFC 1327bis 2068 MIXER DRAFT Version 2.2 2070 X.400 (1992) has introduced as string representation of O/R 2071 Addresses. This has specified a number of string keywords for 2072 attributes. As earlier versions of this specification were an | 2073 input to this work, many of the keywords are the same. To 2074 increase compatibility, the following alternative values shall be 2075 recognised when mapping from RFC 822 to X.400. These shall not 2076 be generated when mapping from X.400 to RFC 822. 2078 Keyword Alternative 2080 ADMD A 2081 PRMD P 2082 GQ Q 2083 X121 X.121 2084 UA-ID N-ID 2085 PD-OFFICE-NUM PD-OFFICE NUMBER 2086 PD-OFFICE-NUM PD-OFN 2087 PD-EXT-ADDRESS PD-EA 2088 PD-EXT-DELIVERY PD-ED 2089 PD-OFFICE PD-OF 2090 PD-STREET PD-S 2091 PD-UNIQUE PD-U 2092 PD-LOCAL PD-L 2093 PD-RESTANTE PD-R 2094 PD-BOX PD-B 2095 PD-CODE PD-PC 2096 PD-SERVICE PD-SN 2097 DD DDA 2099 When mapping from RFC 822 to X.400, the keywords: OU1, OU2, OU3, 2100 and OU4, shall be recognised. If these are present, no keyword 2101 OU shall be present. These will be treated as ordered values of 2102 OU. PD-A1, PD-A2, PD-A3, PD-A4, PD-A5, PD-A6 shall be treated as 2103 ordered lines. If present, these will be assembled with 2104 separating line feeds to form a single physical address. In this 2105 case PD-ADDRESS shall not be present. 2107 If ISDN is present, is may be interpreted as an E.163/164 2108 address, using local heuristics to parse the string. X.400 2109 defines the key, but does not give an interpretation of the 2110 value. 2112 For T-TY, the X.400 recommended values are preferred, but 2113 other values are allowed. These values are: tlx (3); ttx (4); | 2115 RFC 1327bis 2116 MIXER DRAFT Version 2.2 2118 g3fax (5); g4fax (6); ia5 (7); and vtx (8). 2120 4.1.2. Encoding of Personal Name 2122 Handling of Personal Name and Teletex Personal Name based purely 2123 on the EBNF.standard-type syntax defined above is likely to be 2124 clumsy. It seems desirable to utilise the "human" conventions 2125 for encoding these components. A syntax is defined, which is 2126 designed to provide a clean encoding for the common cases of O/R 2127 Address specification where: 2129 1. There is no generational qualifier 2131 2. Initials, if present, contain only letters 2133 3. Given Name, if present, does not contain full stop ("."), 2134 and is at least two characters long. 2136 4. Surname does not contain full stop in the first two 2137 characters. 2139 5 If Surname is the only component, it does not contain full 2140 stop. 2142 The following EBNF is defined: 2144 encoded-pn = [ given "." ] *( initial "." ) surname 2146 given = 2* 2148 initial = ALPHA 2150 surname = printablestring 2152 This is used to map from any string containing only printable 2153 string characters to an O/R address personal name. To map from a 2154 string to O/R Address components, parse the string according to 2155 the EBNF. The given name and surname are assigned directly. All 2156 EBNF.initial tokens are concatenated without intervening full 2157 stops to generate the initials component. 2159 For an O/R address which follows the above restrictions, a 2160 string is derived in the natural manner. In this case, the 2162 RFC 1327bis 2163 MIXER DRAFT Version 2.2 2165 mapping will be reversible. 2167 For example: 2169 GivenName = "Marshall" 2170 Surname = "Rose" 2172 Maps with "Marshall.Rose" 2174 Initials = "MT" 2175 Surname = "Rose" 2177 Maps with "M.T.Rose" 2179 GivenName = "Marshall" 2180 Initials = "MT" 2181 Surname = "Rose" 2183 Maps with "Marshall.M.T.Rose" 2185 Note that X.400 suggests that Initials is used to encode ALL | 2186 initials. Therefore, the defined encoding is "natural" when 2187 either GivenName or Initials, but not both, are present. The | 2188 case where both are present can be encoded. 2190 4.1.3. Standard Encoding of MTS.ORAddress 2192 Given this structure, we can specify a BNF representation of an | 2193 O/R Address. The output format of addresses is defined by | 2194 EBNF.std-or-address. The more flexible input format is defined | 2195 by EBNF.std-or-address-input. The input BNF has been added | 2196 subsequent to RFC 1327, to reflect the formal incorporation of a | 2197 number of heuristics. The output format is used in all examples. 2199 std-or-address = 1*( "/" attribute "=" value ) "/" | 2200 attribute = standard-type | 2201 / "RFC-822" | 2202 / registered-dd-type | 2203 / dd-key "." std-printablestring | 2205 RFC 1327bis 2206 MIXER DRAFT Version 2.2 2208 std-or-address-input = ( sep ) (pair) *( sep pair ) ( sep) | 2209 sep = "/" / ";" | 2210 pair = input-attribute "=" value | 2211 input-attribute = attribute | 2212 / dd-key ":" std-printablestring | 2214 standard-type = key-string 2216 registered-dd-type 2217 = key-string dd-key = key-string 2219 value = std-printablestring 2221 std-printablestring 2222 = *( std-char / std-pair ) std-char 2223 = <"{", "}", "*", and any ps-char | 2224 except "/" and "=" > 2225 std-pair = "$" ps-char 2227 The standard-type is any key defined in the table in Section 4.2, 2228 except PN, and DD. The BNF leads to a set of attribute/value 2229 pairs. The value is interpreted according to the EBNF encoding 2230 defined in the table. 2232 If the standard-type is PN, the value is interpreted 2233 according to EBNF.encoded-pn, and the components of 2234 MTS.PersonalName and/or MTS.TeletexPersonalName derived 2235 accordingly. 2237 If dd-key is the recognised Domain Defined string (DD), then 2238 the type and value are interpreted according to the syntax 2239 implied from the encoding, and aligned to either the teletex or 2240 printable string form. Key and value shall have the same 2241 encoding. 2243 If value is "RFC-822", then the (printable string) Domain 2244 Defined Type of "RFC-822" is assumed. This is an optimised 2245 encoding of the domain defined type defined by this 2246 specification. 2248 The matching of all keywords shall be done in a case- 2250 RFC 1327bis 2251 MIXER DRAFT Version 2.2 2253 independent manner. 2255 EBNF.std-or-address uses the characters "/" and "=" as 2256 delimiters. Domain Defined Attributes and any value may contain 2257 these characters. A quoting mechanism, using the non-printable 2258 string "$" is used to allow these characters to be represented. 2260 If the value is registered-dd-type, and the value is 2261 registered at the Internet Assigned Numbers Authority (IANA) as 2262 an accepted Domain Defined Attribute type, then the value shall 2263 be interpreted accordingly. This restriction maximises the 2264 syntax checking which can be done at a gateway. | 2266 If an address of this syntax is parsed, and a country value | 2267 is present, but no ADMD, the string shall be interpreted as is an | 2268 ADMD value of single space had been specified. 2270 4.2. Global Address Mapping 2272 From a user perspective, the ideal mapping would be entirely 2273 symmetrical and global, to enable addresses to be referred to 2274 transparently in the remote system, with the choice of gateway 2275 being left to the Message Transfer Service. There are two 2276 fundamental reasons why this is not possible: 2278 1. The syntaxes are sufficiently different to make this 2279 impossible. 2281 2 There is insufficient administrative co-operation between 2282 the X.400 and RFC 822 name registration authorities for this 2283 to work. 2285 Another way to view this situation is to see that there is not a 2286 full global equivalence between X.400 and RFC 822 addressing. To 2287 meet user needs to the extent possible, this specification 2288 provides for equivalence where there is sufficient co-operation. 2289 To be useful, this equivalence must be recognised and interpreted 2290 in the same way by all gateways. Therefore, an asymmetrical 2291 mapping is defined, which can be symmetrical where there is 2292 appropriate administrative co-operation. Section 4.3 describes 2293 consider the asymetrical aspects. This section describes how 2294 the administrative co-ordination for symmetrical mappings is 2295 achieved. 2297 RFC 1327bis 2298 MIXER DRAFT Version 2.2 2300 In order to achieve a symmetrical mapping which is supported 2301 by all gateways which conform to this specification, there is a 2302 need to define an administrative equivalence between parts of the 2303 O/R Address and Domain namespaces. This information is defined 2304 globally, and must be used by any gateway which conforms to this 2305 specification. Currently, three ways are defined to access this 2306 mapping information. 2308 1. Distribution of text tables. This is described in Appendix 2309 F of this specification. 2311 2. Distribution by Domain Name Service. This is described in 2312 RFC 1664 [4]. 2314 3. Distribution by X.500 Directory Service. This is defined 2315 in RFC tbs [27]. 2317 The following sections define how the namespace equivalence 2318 is modelled. The Internet Domain Namespace defines a simple 2319 hierarchy. For the purposes of this mapping, only parts of the 2320 namespace where domains conform to the EBNF domain-syntax are 2321 allowed. 2323 domain-syntax = alphanum [ *alphanumhyphen alphanum ] 2324 alphanum = 2325 alphanumhyphen = 2327 Although RFC 822 allows for a more general syntax, this 2328 restricted syntax is chosen as it is the one chosen by the 2329 various domain service administrations. In practice, it reflects 2330 all RFC 822 usage. 2332 The following O/R Address attributes are considered as a 2333 hierarchy, and may be specified by the domain. They are (in 2334 order of the hierarchy defined by MIXER): 2336 Country, ADMD, PRMD, Organization, Organizational Unit 2338 There may be multiple Organizational Units. This hierarchy 2339 reflects most usage of X.400, although X.400 may be used in other 2340 ways. In particular, it covers the Mnemonic O/R Address using a 2341 1984 compatible encoding. This is seen as the dominant form of 2342 O/R Address. MIXER equivalence mappings may only be used when 2344 RFC 1327bis 2345 MIXER DRAFT Version 2.2 2347 this hierarchy applies. 2349 An equivalence mapping is defined between two nodes in the 2350 respective hierarchies. For example: 2352 => "AC.UK" might be mapped with 2353 C="GB", ADMD="GOLD 400", PRMD="UK.AC" 2355 The mapping identifies that the management of these points in the 2356 respective hierarchies is the same (or co-operate very closely). 2357 The equivalence means that the namespaces below this equivalence 2358 point map 1:1, except where the mapping is overridden by further 2359 equivalence mappings lower down the hierarchy. This equivalence 2360 may be achieved in three ways: 2362 1. All of the nodes below this point are RFC 822, and the MIXER 2363 mapping defines the X.400 addresses for these nodes. 2365 2. All of the nodes below this point are X.400, and the MIXER 2366 mapping defines the RFC 822 addresses for these nodes. 2368 3. There are X.400 and RFC 822 nodes below this point, and 2369 addressing is managed in a manner which ensures the 2370 equivalence. The rules to achieve this are defined by 2371 MIXER. 2373 A set of global mappings to enable a clean transformation between 2374 the X.400 and RFC 822 namespaces is therefore defined by 2375 deployment of MIXER. 2377 When an equivalence point is defined, a systematic mapping 2378 for the the inferior nodes in the two hierarchies follows. This 2379 is a 1:1 the mapping between the nodes in the subtrees. For 2380 example, given the the equivalence defined above: 2382 the domain "R-D.Salford.AC.UK" algorithmically maps with 2383 C="GB", ADMD="GOLD 400", PRMD="UK.AC", O="Salford", OU="R-D" 2385 Note that when an equivalence is defined, that this can be re- 2386 defined for lower points in the hierarchy. However, it is not 2387 possible to declare contained subtrees to be un-mappable. 2389 The equivalence mapping also provides a mechanism to deal | 2391 RFC 1327bis 2392 MIXER DRAFT Version 2.2 2394 with missing elements in the X.400 hierarchy (most commonly the 2395 PRMD). A domain may be associated with an omitted attribute in 2396 conjunction with several present ones. When performing the 2397 algorithmic insertion of components lower in the hierarchy, the 2398 omitted value shall be skipped. For example: 2400 If the domain HNE.EGM" is mapped with 2401 "C=TC", "ADMD=ECQ", "PRMD=HNE", and omitted organization 2403 then 2405 "ZI.HNE.EGM" is algorithmically mapped with 2406 "C=TC", "ADMD=ECQ", "PRMD=HNE", "OU=ZI" 2408 Attributes may have null values, and this is treated separately 2409 from omitted attributes (while it is not ideal 2410 to make this distinction, it is useful in practice). 2412 4.2.1. Directory and Nameserve Mappings | 2414 When the global mapping is supported by X.500 or DNS, there is 2415 the possibility that results will be indeterminate due to 2416 timeout. Lookup should be repeated until a value is determined, 2417 in order to maintain a correct and consistent global mapping. | 2419 Where the mapping relates to addresses in the message | 2420 header, there shall be a timeout in the range of 1-4 hours. If | 2421 a mapping cannot be done in this time, address encapsulation | 2422 shall be used. 2424 4.3. EBNF.822-address <-> MTS.ORAddress 2426 This section defines the basic address mapping. 2428 4.3.1. X.400 encoded in RFC 822 2430 This section defines how X.400 addresses are represented in RFC 2431 822 the addresses. 2433 The std-or-address syntax is used to encode O/R Address 2434 information in the 822.local-part of EBNF.822-address. Where 2435 there is an applicable equivalence mapping, further O/R Address 2436 information is associated with the 822.domain component. This 2437 cannot be used in the general case, due to character set 2439 RFC 1327bis 2440 MIXER DRAFT Version 2.2 2442 problems, and to the variants of X.400 O/R Addresses which use 2443 different attribute types. The only way to encode the full 2444 PrintableString character set in a domain is by use of the 2445 822.domain-ref syntax (i.e. 822.atom). This is likely to cause 2446 problems on many systems. The effective character set of domains 2447 is in practice reduced from the RFC 822 set, by restrictions 2448 imposed by domain conventions and policy [10], and by the BNF | 2449 definition in SMTP. 2451 A generic 822.address consists of a 822.local-part and a 2452 sequence of 822.domains (e.g., <@domain1,@domain2:user@domain3>). 2453 All except the 822.domain associated with the 822.local-part 2454 (domain3 in this case) are considered to specify routing within 2455 the RFC 822 world, and will not be interpreted by the gateway 2456 (although they may have identified the gateway from within the 2457 RFC 822 world). 2459 The 822.domain associated with the 822.local-part 2460 identifies the gateway from within the RFC 822 world. This final 2461 822.domain may be used to determine some number of O/R Address 2462 attributes, where this does not conflict with the first role. 2463 RFC 822 routing to gateways will usually be set up to facilitate 2464 the 822.domain being used for both purposes. 2466 In the case that there is no applicable equivalence mapping, 2467 all of the X.400 address is encoded in the 822.local-part and the | 2468 the 822.domain identifies the gateway to which the message is 2469 being sent. This technique may be used by the RFC 822 user for | 2470 any X.400 address where the equivalence mapping is not known. 2472 In the case that there is an applicable equivalence mapping, 2473 the the maximum number of attributes are encoded in the 2474 822.domain. The remaining attributes are encoded on the LHS, 2475 using the EBNF.std-or-address syntax. For example: 2477 /I=J/S=Linnimouth/GQ=5/@Marketing.Widget.COM 2479 encodes the MTS.ORAddress consisting of: 2481 RFC 1327bis 2482 MIXER DRAFT Version 2.2 2484 MTS.CountryName = "TC" 2485 MTS.AdministrationDomainName = "BTT" 2486 MTS.OrganizationName = "Widget" 2487 MTS.OrganizationalUnitNames.value = "Marketing" 2488 MTS.PersonalName.surname = "Linnimouth" 2489 MTS.PersonalName.initials = "J" 2490 MTS.PersonalName.generation-qualifier = "5" 2492 on the basis of an equivalence between: 2494 Domain: Widget.COM 2495 O/R Address: C="TC", ADMD="BTT", O="Widget" 2497 Given the O/R address, the domain Widget.COM is determined from 2498 the the equivalence mapping and the next component is determined 2499 algorithmically to give Marketing.Widget.COM. The remaining 2500 attributes are encoded on the LHS in 822.local-part. 2502 There is a further mechanism to simplify the encoding of 2503 common cases, where the only attributes to be encoded on the LHS | 2504 are (non-Teletex) Personal Name attributes which comply with the 2505 restrictions of 4.2.1. To achieve this, the 822.local-part shall 2506 be encoded as EBNF.encoded-pn. In the previous example, if the 2507 GenerationQualifier was not present in the O/R Address, it would 2508 map with the RFC 822 address: J.Linnimouth@Marketing.Widget.COM. 2510 From the standpoint of the RFC 822 Message Transfer System, 2511 the domain specification is used to route the message in the 2512 standard manner. The standard domain mechanisms are used to 2513 select appropriate gateways for the corresponding O/R Address 2514 space. It is the responsibility of the management that defines 2515 the equivalence mapping to define routing in a the manner which 2516 will enable the message to be delivered. 2518 4.3.2. RFC 822 encoded in X.400 2520 The previous section showed a mapping from X.400 to RFC 822. In 2521 the case where the mapping was symmetrical and based on the the 2522 equivalence mapping, this has also shown how RFC 822 is encoded 2523 in the X.400. This equivalence cannot be used for all RFC 822 2524 addresses. 2526 The general case is mapped by use of domain defined 2528 RFC 1327bis 2529 MIXER DRAFT Version 2.2 2531 attributes. A Domain defined type "RFC-822" is defined. The 2532 associated attribute value is an ASCII string encoded according 2533 to Section 3.3.3 of this specification. The interpretation of the 2534 ASCII string follows RFC 822, and RFC 1123 [10,16]. Domains 2535 shall always be fully qualified. 2537 Other O/R Address attributes will be used to identify a 2538 context in which the O/R Address will be interpreted. This might 2539 be a Management Domain, or some part of a Management Domain which 2540 identifies a gateway MTA. For example: 2542 C = "GB" 2543 ADMD = "GOLD 400" 2544 PRMD = "UK.AC" 2545 O = "UCL" 2546 OU = "CS" 2547 "RFC-822" = "Jimmy(a)WIDGET-LABS.CO.UK" 2549 OR 2551 C = "TC" 2552 ADMD = "Wizz.mail" 2553 PRMD = "42" 2554 "rfc-822" = "postel(a)venera.isi.edu" 2556 Note in each case the PrintableString encoding of "@" as "(a)". 2557 In the second example, the "RFC-822" domain defined attribute is 2558 interpreted everywhere within the (Private) Management Domain. 2559 In the first example, further attributes are needed within the 2560 Management Domain to identify a gateway. Thus, this scheme can 2561 be used with varying levels of Management Domain co-operation. 2563 There is a limit of 128 characters in the length of value of 2564 a domain defined attribute, and an O/R Address can have a 2565 maxmimum of four domain defined attributes. Where the printable 2566 string generated from the RFC 822 address exceeds this value, 2567 additional domain defined attributes are used to enable up to 512 2568 characters to be encoded. These attributes shall be filled 2569 completely before the next one is started. The DDA keywords 2570 are: RFC822C1; RFC822C2; RFC822C3. Longer addresses cannot be 2571 encoded. 2573 There is, analogous with 4.3.1, a means to associate parts 2574 of the O/R Address hierarchy with domains. There is an analogous 2576 RFC 1327bis 2577 MIXER DRAFT Version 2.2 2579 global mapping, which in most cases will be the inverse of the 2580 domain to O/R address mapping. The mapping is maintained 2581 separately, as there may be differences (e.g., two alternate 2582 domain names map to the same set of O/R address components). 2584 4.3.3. Component Ordering 2586 In most cases, ordering of O/R Address components is not 2587 significant for the mappings specified. However, Organizational 2588 Units (printable string and teletex forms) and Domain Defined 2589 Attributes are specified as SEQUENCE in MTS.ORAddress, and so 2590 their order may be significant. This specification needs to take 2591 account of this: 2593 1. To allow consistent mapping into the domain hierarchy 2595 2. To ensure preservation of order over multiple mappings. 2597 There are three places where an order is specified: 2599 1. The text encoding (std-or-address) of MTS.ORAddress as used 2600 in the local-part of an RFC 822 address. An order is needed 2601 for those components which may have multiple values 2602 (Organizational Unit, and Domain Defined Attributes). When 2603 generating an 822.std-or-address, components of a given type 2604 shall be in hierarchical order with the most significant 2605 component on the RHS. If there is an Organization 2606 Attribute, it shall be to the right of any Organizational 2607 Unit attributes. These requirements are for the following 2608 reasons: 2610 - Alignment to the hierarchy of other components in RFC 2611 822 addresses (thus, Organizational Units will appear 2612 in the same order, whether encoded on the RHS or LHS). | 2614 - Backwards compatibility with RFC 987/1026. 2616 - To ensure that gateways generate consistent addresses. 2617 This is both to help end users, and to generate 2618 identical message ids. 2620 Further, it is recommended that all other attributes are 2621 generated according to this ordering, so that all attributes 2622 so encoded follow a consistent hierarchy. When generating 2624 RFC 1327bis 2625 MIXER DRAFT Version 2.2 2627 822.msg-id, this order shall be followed. 2629 2. For the Organizational Units (OU) in MTS.ORAddress, the 2630 first OU in the SEQUENCE is the most significant, as 2631 specified in X.400. 2633 3. For the Domain Defined Attributes in MTS.ORAddress, the 2634 First Domain Defined Attribute in the SEQUENCE is the most 2635 significant. 2637 Note that although this ordering is mandatory for this 2638 mapping, there are NO implications on ordering significance 2639 within X.400, where this is a Management Domain issue. 2641 4.3.4. RFC 822 -> X.400 Basic Address Mapping 2643 There are two basic cases: 2645 1. X.400 addresses encoded in RFC 822. This will also include 2646 RFC 822 addresses which are given reversible encodings. 2648 2. "Genuine" RFC 822 addresses. 2650 The mapping shall proceed as follows, by first assuming case 1). 2652 STAGE I. 2654 1. If the 822-address is not of the form: 2656 local-part "@" domain 2658 take the domain which will be routed on and apply step 2 of 2659 stage 1 to derive (a possibly null) set of attributes. Then 2660 go to stage II. 2662 NOTE:It may be appropriate to reduce a source route address 2663 to this form by removal of all bar the last domain. In 2664 terms of the design intentions of RFC 822, this would | 2665 be an incorrect action. (Note that a an address of the | 2666 form local%part@domain is not a source route). 2667 However, in most real cases, it will do the "right" 2668 thing and provide a better service to the end user. 2669 This is a reflection on the excessive and inappropriate 2670 use of source routing in RFC 822 based systems, despite 2672 RFC 1327bis 2673 MIXER DRAFT Version 2.2 2675 the discussion in the Host Requirements [10]. Either 2676 approach, or the intermediate approach of stripping 2677 only domain references which reference the local 2678 gateway are conformant to this specification. 2680 2. Attempt to parse EBNF.domain as: 2682 *( domain-syntax "." ) known-domain 2684 Where EBNF.known-domain is the longest possible match in the 2685 set of globally defined mappings described in Section 4.2. 2686 EBNF.domain-syntax is the restricted domain syntax defined 2687 in Section 4.2, to which all of the domain components must 2688 conform for the parse to be successful. If this fails, and 2689 the EBNF.domain does not explicitly identify the local 2690 gateway, go to stage II. Otherwise no gateway is explicitly | 2691 identified and all of the information is used by the local 2692 gateway. In this case allocate the attributes associated 2693 with EBNF.known-domain. For each component, systematically 2694 allocate the attribute implied by each EBNF.domain-syntax 2695 component in the order: C, ADMD, PRMD, O, OU. Note that if 2696 the mapping used identifies an "omitted attribute", then 2697 this attribute should be omitted in the systematic 2698 allocation. If this new component exceed an upper bound 2699 (ADMD: 16; PRMD: 16; O: 64; OU: 32) or it would lead to 2700 more than four OUs, then go to stage II with the attributes 2701 derived. 2703 At this stage, a set of attributes has been derived, which 2704 will give appropriate routing within X.400. If any of the 2705 later steps of Stage I force use of Stage II, then these 2706 attributes should be used in Stage II. | 2708 3. If the 822.local-part uses the 822.quoted-string encoding, 2709 remove this quoting. If this unquoted 822.local-part has 2710 leading space, trailing space, or two adjacent spaces go to 2711 stage II. 2713 4. If the unquoted 822.local-part contains any characters not 2714 in PrintableString, go to stage II. 2716 RFC 1327bis 2717 MIXER DRAFT Version 2.2 2719 5. Parse the (unquoted) 822.local-part according to the EBNF 2720 EBNF.std-or-address. Checking of upper bounds should not be 2721 done at this point. If this parse fails, parse the local- 2722 part according to the EBNF EBNF.encoded-pn. If this parse 2723 fails, go to stage II. The result is a set of type/value 2724 pairs. If the set of attributes leads to an address of any 2725 form other than mnemonic form, then only these attributes 2726 should be taken. If (for mnemonic form) the values generated 2727 conflict with those derived in step 2 (e.g., a duplicated 2728 country attribute), the domain is assumed to be a remote 2729 gateway. In this case, take only the LHS derived 2730 attributes, together with any RHS derived attributes which 2731 are more significant than the most significant attribute 2732 which is duplicated (e.g., if there is a duplicate PRMD, but 2733 no LHS derived ADMD and country, then the ADMD and country 2734 should be taken from the RHS). Otherwise add LHS and RHS 2735 derived attributes together. 2737 6. Associate the EBNF.attribute-value syntax (determined from 2738 the identified type) with each value, and check that it 2739 conforms. If not, go to stage II. 2741 7. Ensure that the set of attributes conforms both to the 2742 MTS.ORAddress specification and to the restrictions on this 2743 set given in X.400, and that no upper bounds are exceeded 2744 for any attribute. If not go to stage II. 2746 8. Build the O/R Address from this information. 2748 STAGE II. 2750 This will only be reached if the RFC 822 EBNF.822-address is not 2751 a valid X.400 encoding. This implies that the address must refer 2752 to a recipient on an RFC 822 system. Such addresses shall be 2753 encoded in an X.400 O/R Address using a domain defined attribute. 2755 1. Convert the EBNF.822-address to PrintableString, as 2756 specified in Chapter 3. 2758 2. Generate the "RFC-822" domain defined attribute from this 2759 string. 2761 3. Build the rest of the O/R Address in the manner described 2763 RFC 1327bis 2764 MIXER DRAFT Version 2.2 2766 below. 2768 It may not be possible to encode the domain defined attribute due 2769 to length restrictions. If the limit is exceeded by a mapping at 2770 the MTS level, then the gateway shall reject the message in 2771 question. If this occurs at the IPMS level, then the action will 2772 depend on the policy being taken for IPMS encoding, which is 2773 discussed in Section 5.1.3. 2775 If Stage I has identified a set of attributes, use these to build 2776 the remainder of the address. The administrative equivalence of 2777 the mappings will ensure correct routing through X.400 to a 2778 gateway back to RFC 822. 2780 If Stage I has not identified a set of attributes, the 2781 remainder of the O/R address effectively identifies a source 2782 route to a gateway from the X.400 side. There are three cases, 2783 which are handled differently: | 2785 SMTP Return Address | 2786 This shall be set up so that errors are returned through the 2787 same gateway. Therefore, the O/R Address of the local 2788 gateway shall be used. 2790 IPMS Addresses 2791 These are optimised for replying. In general, the message 2792 may end up anywhere within the X.400 world, and so this 2793 optimisation identifies a gateway appropriate for the RFC 2794 822 address being converted. The 822.domain to which the 2795 address would be routed is used to select an appropriate 2796 gateway. A globally defined set of mappings is used, which 2797 identifies (the O/R Address components of) appropriate 2798 gateways for parts of the domain namespace. The longest 2799 possible match on the 822.domain defines which gateway to 2800 use, according to the equivalence mappings defined in 2801 Section 4.2. 2803 This global mapping is used for parts of the RFC 822 2804 namespace which do not have an administrative equivalence 2805 with any part of the X.400 namespace, but for which it is 2806 desirable to identify a preferred X.400 gateway in order to 2807 optimise routing. 2809 If no mapping is found for the 822.domain, a default value 2811 RFC 1327bis 2812 MIXER DRAFT Version 2.2 2814 (typically that of the local gateway) is used. It is never 2815 appropriate to ignore the globally defined mappings. In 2816 some cases, it may be appropriate to locally override the 2817 globally defined mappings (e.g., to identify a gateway close 2818 to a recipient of the message). This is likely to be where 2819 the global mapping identifies a public gateway, and the 2820 local gateway has an agreement with a private gateway which 2821 it prefers to use. | 2823 SMTP Recipient | 2824 As the RFC 822 and X.400 worlds are in principle fully 2825 connected, there should be no technical reason for this 2826 situation to occur. In practice, this is not the case. In | 2827 some cases, routing may be configured to use X.400 to | 2828 connect an RFC 822 island to the Internet. The information 2829 that this part of the domain space should be routed by X.400 2830 rather than remaining within the RFC 822 world will be 2831 configured privately into the gateway in question. The O/R 2832 address shall then be generated in the same manner as for an 2833 IPMS address, using the globally defined mappings. It is to 2834 support this case that the definition of the global domain 2835 to gateway mapping is important, as the use of this mapping 2836 will lead to a remote X.400 address, which can be routed by 2837 X.400 routing procedures. The information in this mapping 2838 shall not be used as a basis for deciding to convert a 2839 message from RFC 822 to X.400. 2841 Two examples are given: 2843 Example 1: (Address not in "localpart" "@" "domainpart") 2845 @relay.co.uk:userb@host2 2846 maps to 2847 c=gb; a= ; p=uk.ac; o=mhs-relay; dd.rfc-822=(a)relay.co.uk:userb(a)host2; 2849 Example 2: (Address with non printablestring characters) 2851 Tom_Harris@cs.widget.com 2852 maps to 2853 c=us; a=MCI; P=relay; dd.rfc-822=Tom(u)Harris(a)cs.widget.com; 2855 RFC 1327bis 2856 MIXER DRAFT Version 2.2 2858 4.3.4.1. Heuristics for mapping RFC 822 to X.400 2860 The following heuristic, which relates to ordering of address | 2861 components, may be used when mapping from RFC 822 to X.400. The 2862 ordering of attributes may be inverted or mixed. For this 2863 reason, the following heuristics may be applied: 2865 6. If there is an Organization attribute to the left of any Org 2866 Unit attribute, assume that the hierarchy is inverted. This 2867 is to facilitate the situation where a user has input the 2868 attributes in reverse hierarchical order. To do this the 2869 gateway shall first map according to the order defined in 2870 4.3.3. If this mapping generates an address which X.400 2871 address verification shows to be invalid, this heuristic may 2872 be applied as an alternative to immediate rejection of the 2873 address. 2875 4.3.5. X.400 -> RFC 822 Basic Address Mapping 2877 There are two basic cases: 2879 1. RFC 822 addresses encoded in X.400. 2881 2. "Genuine" X.400 addresses. This may include symmetrically 2882 encoded RFC 822 addresses. 2884 When a MTS Recipient O/R Address is interpreted, gatewaying will 2885 be selected if there is a single "RFC-822" domain defined | 2886 attribute present. In this case, use mapping A and in other | 2887 cases, use mapping B. | 2889 RFC 1327 specified that this should only be done when the | 2890 gateway identfied is local or otherwise known, and identified the | 2891 approach specified here as a pragmatic option. Experience has | 2892 shown that this is effective in practice, despite theoretical | 2893 problems. | 2895 If a gateway wishes to make a mapping in a manner similar to | 2896 RFC 1327, but does not wish for this global interpretation (e.g., | 2897 to support an RFC 822 local systems, which does not use global | 2898 addressing), then it should choose a private domain defined | 2899 attribute, different to "RFC-822". An RFC 1327 gateway might be | 2900 configurable to operate in this manner. 2902 RFC 1327bis 2903 MIXER DRAFT Version 2.2 2905 Mapping A * 2907 1. Map the domain defined attribute value to ASCII, as defined 2908 in Chapter 3, and drop all other attributes. 2910 Mapping B. 2912 This is used for X.400 addresses which do not use the explicit 2913 RFC 822 encoding. 2915 1. For all string encoded attributes, remove any leading or 2916 trailing spaces, and replace adjacent spaces with a single 2917 space. 2919 The only attribute which is permitted to have zero length is 2920 the ADMD. This should be mapped onto a single space. 2922 These transformations are for lookup only. If an 2923 EBNF.std-or-address mapping is used as in 4), then the 2924 original values should be used. 2926 2. Map numeric country codes to the two letter values (as | 2927 defined in ISO 3166). 2929 3. Noting the hierarchy specified in 4.3.1 and including 2930 omitted attributes, determine the maximum set of attributes 2931 which have an associated domain specification in the 2932 globally defined mapping. If no match is found, allocate | 2933 the domain as described below, and go to step 5. The default | 2934 domain to be used is the specification of the local gateway. | 2935 A gateway may use other domains according to private mapping | 2936 tables or heuristics. For example, it may choose a domain | 2937 which it knows to provide a free gateway service to the | 2938 mapped address. 2940 In cases where the address refers to an X.400 UA, it is 2941 important that the generated domain will correctly route to 2942 a gateway. In general, this is achieved by carefully co- 2943 ordinating RFC 822 routing with the definition of the global 2944 mappings, as there is no easy way for the gateway to make 2945 this check. One rule that shall be used is that domains 2946 with only one component will not route to a gateway. If the 2947 generated domain does not route correctly, the address is 2948 treated as if no match is found. 2950 RFC 1327bis 2951 MIXER DRAFT Version 2.2 2953 4. The mapping identified in 3) gives a domain, and an O/R 2954 address prefix. Follow the hierarchy: C, ADMD, PRMD, O, OU. 2955 For each successive component below the O/R address prefix, 2956 which conforms to the syntax EBNF.domain-syntax (as defined 2957 in 4.3.1), allocate the next subdomain. At least one 2958 attribute of the X.400 address shall not be mapped onto 2959 subdomain, as 822.local-part cannot be null. If there are 2960 omitted attributes in the O/R address prefix, these will 2961 have correctly and uniquely mapped to a domain component. 2962 Where there is an attribute omitted below the prefix, all 2963 attributes remaining in the O/R address shall be encoded on 2964 the LHS. This is to ensure a reversible mapping. For 2965 example, if there is an address /S=XX/O=YY/ADMD=A/C=NN/ and 2966 a mapping for /ADMD=A/C=NN/ is used, then /S=XX/O=YY/ is 2967 encoded on the LHS. 2969 5. If the address contains any attribute not used in mnemonic 2970 form, then all of the attributes in the address should be 2971 encoded on the LHS in EBNF.std-or-address syntax, as 2972 described below. 2974 For addresses of mnemonic form, if the remaining components 2975 are personal-name components, conforming to the restrictions 2976 of 4.2.1, then EBNF.encoded-pn is derived to form 2977 822.local-part. In other cases the remaining components are 2978 simply encoded as 822.local-part using the 2979 EBNF.std-or-address syntax. If necessary, the 2980 822.quoted-string encoding is used. The following are 2981 examples of legal quoting: "a b".c@x; "a b.c"@x. Either 2982 form may be generated, but the latter is preferred. 2984 If the derived 822.local-part can only be encoded by use of 2985 822.quoted-string, then use of the mapping defined in[19] 2986 may be appropriate. Use of this mapping is discouraged. | 2988 Editor's Note: | 2989 Can we remove the previous paragraph? 2991 Three examples are given. | 2993 Editor's Note: | 2994 I have had a lot of comments on the inaccuracy of these | 2995 examples. Are they worth retaining? If so, can they be | 2996 carefully verified. 2998 RFC 1327bis 2999 MIXER DRAFT Version 2.2 3001 Example 1: (Address with missing X.400 elements and no specific 3002 mapping rule for "o=sales; a=Master400; C=it", where a mapping | 3003 exsits for master400.it) 3005 C=it; A=Master400; O=sales; S=Support; | 3006 maps to 3007 /S=Support/o=sales/@Master400.it | 3009 Example 2: (Address with illegal characters in RFC822 generated 3010 domain if default hierarchical translation (specific mapping rule 3011 is existing for c=fr; a=atlas; p=autoroutes) is used) 3013 C=fr; A=atlas; P=autoroutes; O=Region Parisienne; S=rensignments; | 3014 maps to 3015 "/S=rensignments/o=Region Parisienne/"@autoroutes.fr | 3017 Example 3: (Address containing elements not mappable into RFC822 3018 local part) 3020 C=it; A=PtPostel; DDA.cap=20100; DDA.ph1=Via Maggiore 11; DDAs.city=Milano; S=Rossi;| 3021 MAPS TO 3022 "/DD.Cap=20100/DD.ph1=Via Maggiore 11/DD.City=Milano/S=Rossi/"@ptpostel.it| 3024 4.4. Repeated Mappings 3026 There are two types of repeated mapping: 3028 1. A recursive mapping, where the repeat is within one gateway 3030 2 A source route, where the repetition occurs across multiple 3031 gateways 3033 4.4.1. Recursive Mappings 3035 It is possible to supply an address which is recursive at a 3036 single gateway. For example: 3038 C = "XX" 3039 ADMD = "YY" 3040 O = "ZZ" 3041 "RFC-822" = "Smith(a)ZZ.YY.XX" 3043 RFC 1327bis 3044 MIXER DRAFT Version 2.2 3046 This is mapped first to an RFC 822 address, and then back to the 3047 X.400 address: 3049 C = "XX" 3050 ADMD = "YY" 3051 O = "ZZ" 3052 Surname = "Smith" 3054 In some situations this type of recursion may be frequent. It is 3055 important where this occurs, that no unnecessary protocol | 3056 conversion occurs. This will minimise loss of service. 3058 4.4.2. Source Routes 3060 The mappings defined are symmetrical and reversible across a 3061 single gateway. The symmetry is particularly useful in cases of 3062 (mail exploder type) distribution list expansion. For example, 3063 an X.400 user sends to a list on an RFC 822 system which he 3064 belongs to. The received message will have the originator and 3065 any 3rd party X.400 O/R Addresses in correct format (rather than 3066 doubly encoded). In cases (X.400 or RFC 822) where there is 3067 common agreement on gateway identification, then this will apply 3068 to multiple gateways. 3070 When a message traverses multiple gateways, the mapping will 3071 always be reversible, in that a reply can be generated which will 3072 correctly reverse the path. In many cases, the mapping will also 3073 be symmetrical, which will appear clean to the end user. For 3074 example, if countries "AB" and "XY" have RFC 822 networks, but 3075 are interconnected by X.400, the following may happen: The 3076 originator specifies: 3078 Joe.Soap@Widget.PTT.XY 3080 This is routed to a gateway, which generates: 3082 C = "XY" 3083 ADMD = "PTT" 3084 PRMD = "Griddle MHS Providers" 3085 Organization = "Widget Corporation" 3086 Surname = "Soap" 3087 Given Name = "Joe" 3089 This is then routed to another gateway where the mapping is 3091 RFC 1327bis 3092 MIXER DRAFT Version 2.2 3094 reversed to give: 3096 Joe.Soap@Widget.PTT.XY 3098 Here, use of the gateway is transparent. 3100 Mappings will only be symmetrical where mapping equivalences | 3101 are defined. In other cases, the reversibility is more important, 3102 due to the (far too frequent) cases where RFC 822 and X.400 3103 services are partitioned. 3105 The syntax may be used to source route. THIS IS STRONGLY 3106 DISCOURAGED. For example: 3108 X.400 -> RFC 822 -> X.400 3110 C = "UK" 3111 ADMD = "Gold 400" 3112 PRMD = "UK.AC" 3113 "RFC-822" = "/PN=Duval/DD.Title=Manager/(a)Inria.ATLAS.FR" 3115 This will be sent to an arbitrary UK Academic Community gateway 3116 by X.400. Then it will be sent by JNT Mail to another gateway 3117 determined by the domain Inria.ATLAS.FR (FR.ATLAS.Inria). This 3118 will then derive the X.400 O/R Address: 3120 C = "FR" 3121 ADMD = "ATLAS" 3122 PRMD = "Inria" 3123 PN.S = "Duval" 3124 "Title" = "Manager" 3126 Similarly: 3127 RFC 822 -> X.400 -> RFC 822 3129 "/RFC-822=jj(a)seismo.css.gov/PRMD=AC/ADMD=BT/C=GB/"@monet.berkeley.edu 3131 This will be sent to monet.berkeley.edu by RFC 822, then to the 3132 AC PRMD by X.400, and then to jj@seismo.css.gov by RFC 822. 3134 4.5. Directory Names 3136 Directory Names are an optional part of O/R Name, along with O/R 3137 Address. The RFC 822 addresses are mapped onto the O/R Address 3139 RFC 1327bis 3140 MIXER DRAFT Version 2.2 3142 component. As there is no functional mapping for the Directory 3143 Name on the RFC 822 side, a textual mapping is used. There is no 3144 requirement for reversibility in terms of the goals of this 3145 specification. There may be some loss of functionality in terms 3146 of third party recipients where only a directory name is given, 3147 but this seems preferable to the significant extra complexity of 3148 adding a full mapping for Directory Names. 3150 The Directory Name shall be represented within an RFC 822 3151 comment. Any reasonable format for representing the directory 3152 name may be used. It is recommended that the directory string 3153 format of RFC 1485 is used [25]. The User Friendly Name form of 3154 RFC 1484 may also be used [26]. 3156 4.6. MTS Mappings 3158 The basic mappings at the MTS level are: 3160 1) SMTP originator -> | 3161 MTS.PerMessageSubmissionFields.originator-name 3162 MTS.OtherMessageDeliveryFields.originator-name -> 3163 SMTP originator | 3165 2) SMTP recipient -> | 3166 MTS.PerRecipientMessageSubmissionFields 3167 MTS.OtherMessageDeliveryFields.this-recipient-name -> 3168 SMTP recipient | 3170 SMTP recipients and return addresses are encoded as | 3171 EBNF.822-address. 3173 The MTS Originator is always encoded as MTS.OriginatorName, 3174 which maps onto MTS.ORAddressAndOptionalDirectoryName, which in 3175 turn maps onto MTS.ORName. 3177 4.6.1. RFC 822 -> X.400 MTS Mappings 3179 From the SMTP Originator, use the basic ORAddress mapping, to | 3180 generate MTS.PerMessageSubmissionFields.originator-name 3181 (MTS.ORName), without a DirectoryName. 3183 For recipients, the following settings are made for each 3184 component of MTS.PerRecipientMessageSubmissionFields. 3186 RFC 1327bis 3187 MIXER DRAFT Version 2.2 3189 recipient-name 3190 This is derived from the SMTP recipient by the basic | 3191 ORAddress mapping. 3193 originator-report-request 3194 This is be set according to content return policy, as 3195 discussed in Section 5.2. 3197 explicit-conversion 3198 This optional component is omitted, as this service is not 3199 needed 3201 extensions 3202 The default value (no extensions) is used 3204 4.6.2. X.400 -> RFC 822 MTS Mappings 3206 The basic functionality is to generate the SMTP originator and | 3207 recipients. There is information present on the X.400 side, 3208 which cannot be mapped into analogous SMTP services. For this | 3209 reason, new RFC 822 fields are added for the MTS Originator and 3210 Recipients. The information discarded at the SMTP level will be | 3211 present in these fields. In some cases a (positive) delivery 3212 report will be generated. 3214 4.6.2.1. SMTP Mappings | 3216 Use the basic ORAddress mapping, to generate the SMTP originator | 3217 (return address) from 3218 MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName). If 3219 MTS.ORName.directory-name is present, it is discarded. (Note 3220 that it will be presented to the user, as described in 4.6.2.2). 3222 The mapping uses the MTA level information, and maps each | 3223 value of MTA.PerRecipientMessageTransferFields.recipient-name, | 3224 where the responsibility bit is set, onto an SMTP recipient. | 3226 Note:The SMTP recipient is conceptually generated from 3227 MTS.OtherMessageDeliveryFields.this-recipient-name. This is 3228 done by taking 3229 MTS.OtherMessageDeliveryFields.this-recipient-name, and | 3230 generating an SMTP recipient according to the basic | 3231 ORAddress mapping, discarding MTS.ORName.directory-name if 3232 present. However, if this model was followed exactly, there 3234 RFC 1327bis 3235 MIXER DRAFT Version 2.2 3237 would be no possibility to have multiple SMTP recipients on | 3238 a single message. This is unacceptable, and so layering is 3239 violated. * 3241 4.6.2.2. Generation of RFC 822 Headers 3243 Not all per-recipient information can be passed at the SMTP | 3244 level. For this reason, two new RFC 822 headers are created, in 3245 order to carry this information to the RFC 822 recipient. These 3246 fields are "X400-Originator:" and "X400-Recipients:". 3248 The "X400-Originator:" field is set to the same value as the | 3249 SMTP originator. In addition, if 3250 MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName) 3251 contains MTS.ORName.directory-name then this Directory Name shall 3252 be represented in an 822.comment. 3254 Recipient names, taken from each value of 3255 MTS.OtherMessageDeliveryFields.this-recipient-name and 3256 MTS.OtherMessageDeliveryFields.other-recipient-names are made 3257 available to the RFC 822 user by use of the "X400-Recipients:" 3258 field. By taking the recipients at the MTS level, disclosure of 3259 recipients will be dealt with correctly. However, this conflicts 3260 with a desire to optimise mail transfer. There is no problem 3261 when disclosure of recipients is allowed. Similarly, there is no 3262 problem if there is only one RFC 822 recipient, as the 3263 "X400-Recipients" field is only given one address. 3265 There is a problem if there are multiple RFC 822 recipients, 3266 and disclosure of recipients is prohibited. In this case, | 3267 discard the per-recipient information, and insert a field: 3269 X400-Recipients: non-disclosure:; 3271 If any MTS.ORName.directory-name is present, it shall be * 3272 represented in an 822.comment. 3274 If 3275 MTS.OtherMessageDeliveryFields.orignally-intended-recipient-name 3276 is present, then there has been redirection, or there has been 3277 distribution list expansion. Distribution list expansion is a 3278 per-message option, and the information associated with this is 3279 represented by the "DL-Expansion-History:" field described in 3281 RFC 1327bis 3282 MIXER DRAFT Version 2.2 3284 Section 5.3.6. Other information is represented in an 3285 822.comment associated associated with 3286 MTS.OtherMessageDeliveryFields.this-recipient-name, The message 3287 may be delivered to different RFC 822 recipients, and so several 3288 addresses in the "X400-Recipients:" field may have such comments. 3289 The non-commented recipient is the RFC 822 recipient. The EBNF of 3290 the comment is: 3292 redirect-comment = 3293 [ "Originally To:" ] mailbox "Redirected" 3294 [ "Again" ] "on" date-time 3295 "To:" redirection-reason 3297 redirection-reason = 3298 "Recipient Assigned Alternate Recipient" 3299 / "Originator Requested Alternate Recipient" 3300 / "Recipient MD Assigned Alternate Recipient" 3301 / "Recipient Directory Substitution Alternate Recipient" 3303 It is derived from 3304 MTA.PerRecipientMessageTransferFields.extension.redirection-history. 3305 An example of this is: 3307 X400-Recipients: postmaster@widget.com (Originally To: 3308 sales-manager@sales.widget.com Redirected 3309 on Thu, 30 May 91 14:39:40 +0100 To: Originator Assigned 3310 Alternate Recipient postmaster@sales.widget.com Redirected 3311 Again on Thu, 30 May 91 14:41:20 +0100 To: Recipient MD 3312 Assigned Alternate Recipient) 3314 In addition the following per-recipient services from 3315 MTS.OtherMessageDeliveryFields.extensions are represented in 3316 comments if they are used. None of these services can be 3317 provided on RFC 822 networks, and so in general these will be 3318 informative strings associated with other MTS recipients. In some 3319 cases, string values are defined. For the remainder, the string 3320 value shall be chosen by the implementor. If the parameter has 3321 a default value, then no comment shall be inserted when the 3322 parameter has that default value. 3324 requested-delivery-method 3326 RFC 1327bis 3327 MIXER DRAFT Version 2.2 3329 physical-forwarding-prohibited 3330 "(Physical Forwarding Prohibited)". 3332 physical-forwarding-address-request 3333 "(Physical Forwarding Address Requested)". 3335 physical-delivery-modes 3337 registered-mail-type 3339 recipient-number-for-advice 3341 physical-rendition-attributes 3343 physical-delivery-report-request 3344 "(Physical Delivery Report Requested)". 3346 proof-of-delivery-request 3347 "(Proof of Delivery Requested)". 3349 4.6.2.3. Delivery Report Generation 3351 If SMTP is used, the behaviour is specified in Appendix A. In | 3352 other cases, if | 3353 MTA.PerRecipientMessageTransferFields.per-recipient-indicators 3354 requires a positive delivery notification, this shall be 3355 generated by the gateway. Supplementary Information shall be set 3356 to indicate that the report is gateway generated. This 3357 information shall include the name of the gateway generating the 3358 report. 3360 4.6.3. Message IDs (MTS) 3362 A mapping from 822.msg-id to MTS.MTSIdentifier is defined. The 3363 reverse mapping is not needed, as MTS.MTSIdentifier is always 3364 mapped onto new RFC 822 fields. The value of 3365 MTS.MTSIdentifier.local-part will facilitate correlation of 3366 gateway errors. 3368 To map from 822.msg-id, apply the standard mapping to 3369 822.msg-id, in order to generate an MTS.ORAddress. The Country, 3370 ADMD, and PRMD components of this are used to generate 3371 MTS.MTSIdentifier.global-domain-identifier. 3372 MTS.MTSIdentifier.local-identifier is set to the 822.msg-id, 3374 RFC 1327bis 3375 MIXER DRAFT Version 2.2 3377 including the braces "<" and ">". If this string is longer than 3378 MTS.ub-local-id-length (32), then it is truncated to this length. 3380 The reverse mapping is not used in this specification. It 3381 would be applicable where MTS.MTSIdentifier.local-identifier is 3382 of syntax 822.msg-id, and it algorithmically identifies 3383 MTS.MTSIdentifier. 3385 4.7. IPMS Mappings 3387 All RFC 822 addresses are assumed to use the 822.mailbox syntax. 3388 This includes all 822.comments associated with the lexical tokens 3389 of the 822.mailbox. In the IPMS O/R Names are encoded as 3390 MTS.ORName. This is used within the IPMS.ORDescriptor, 3391 IPMS.RecipientSpecifier, and IPMS.IPMIdentifier. An asymmetrical 3392 mapping is defined between these components. 3394 4.7.1. RFC 822 -> X.400 3396 To derive IPMS.ORDescriptor from an RFC 822 address. 3398 1. Take the address, and extract an EBNF.822-address. Any | 3399 source routing shall be removed. This can be derived 3400 trivially from either the 822.addr-spec or 822.route-addr 3401 syntax. This is mapped to MTS.ORName as described above, 3402 and used as IMPS.ORDescriptor.formal-name. 3404 2. A string shall be built consisting of (if present): 3406 - The 822.phrase component if the 822.address is an 3407 822.phrase 822.route-addr construct. 3409 - Any 822.comments, in order, retaining the parentheses. 3411 This string is then encoded into T.61 using a human oriented | 3412 mapping (as described in Section 3.5). If the string is not 3413 null, it is assigned to IPMS.ORDescriptor.free-form-name. 3415 3. IPMS.ORDescriptor.telephone-number is omitted. 3417 If IPMS.ORDescriptor is being used in IPMS.RecipientSpecifier, 3418 IPMS.RecipientSpecifier.reply-request and 3419 IPMS.RecipientSpecifier.notification-requests are set to default 3420 values (false and none). 3422 RFC 1327bis 3423 MIXER DRAFT Version 2.2 3425 If the 822.group construct is present, any included 3426 822.mailbox is encoded as above to generate a separate 3427 IPMS.ORDescriptor. The 822.group is mapped to T.61 (as 3428 described in Section 3.5), and a IPMS.ORDescriptor with only an 3429 free-form-name component built from it. 3431 4.7.2. X.400 -> RFC 822 3433 Mapping from IPMS.ORDescriptor to RFC 822 address. In the basic 3434 case, where IPMS.ORDescriptor.formal-name is present, proceed as 3435 follows. 3437 1. Encode IPMS.ORDescriptor.formal-name (MTS.ORName) as 3438 EBNF.822-address. 3440 2a. If IPMS.ORDescriptor.free-form-name is present, convert it 3441 to ASCII or T.61 (Section 3.5), and use this as the 3442 822.phrase component of 822.mailbox using the 822.phrase 3443 822.route-addr construct. 3445 2b. If IPMS.ORDescriptor.free-form-name is absent. If 3446 EBNF.822-address is parsed as 822.addr-spec use this as the 3447 encoding of 822.mailbox. If EBNF.822-address is parsed as | 3448 822.route 822.addr-spec, then an 822.phrase taken from 3449 822.local-part is added. 3451 3 If IPMS.ORDescriptor.telephone-number is present, this is 3452 placed in an 822.comment, with the string "Tel ". The 3453 normal international form of number is used. For example: 3455 (Tel +44-181-333-7777) 3457 4. If IPMS.ORDescriptor.formal-name.directory-name is present, 3458 then a text representation is placed in a trailing 3459 822.comment. 3461 5. If IPMS.RecipientSpecifier.report-request has any non- 3462 default values, then an 822.comment "(Receipt Notification 3463 Requested)", and/or "(Non Receipt Notification Requested)", 3464 and/or "(IPM Return Requested)" may be appended to the | 3465 address. "(Receipt Notification Requested)" may be used to | 3466 infer "(Non Receipt Notification Requested)". The effort of 3467 correlating P1 and P2 information is too great to justify 3469 RFC 1327bis 3470 MIXER DRAFT Version 2.2 3472 the gateway sending Receipt Notifications. 3474 In RFC 1327, inclusion of these comments was mandatory. 3475 Experience has shown that the clutter and confusion caused 3476 to RFC 822 users does not justify the information conveyed. 3477 Implementors are recommended to not include these comments. 3478 Unless an application is found where retention of these 3479 comments is desirable, they will be dropped from the next 3480 version. 3482 6. If IPMS.RecipientSpecifier.reply-request is True, an 3483 822.comment "(Reply requested)" is appended to the address. 3485 If IPMS.ORDescriptor.formal-name is absent, 3486 IPMS.ORDescriptor.free-form-name is converted to ASCII, and used 3487 as 822.phrase within the RFC 822 822.group syntax. For example: 3489 Free Form Name ":" ";" 3491 Steps 3-6 are then followed. 3493 4.7.3. IP Message IDs 3495 There is a need to map both ways between 822.msg-id and 3496 IPMS.IPMIdentifier. This allows for X.400 Receipt Notifications, 3497 Replies, and Cross References to reference an RFC 822 Message ID, 3498 which is preferable to a gateway generated ID. A reversible and 3499 symmetrical mapping is defined. This provides fully reversible 3500 mappings when messages pass multiple times across the X.400/RFC 3501 822 boundary. 3503 An important issue with messages identifiers is mapping to 3504 the exact form, as many systems use these ids as uninterpreted 3505 keys. The use of table driven mappings is not always 3506 symmetrical, particularly in the light of alternative domain 3507 names, and alternative management domains. For this reason, a 3508 purely algorithmic mapping is used. A mapping which is simpler 3509 than that for addresses can be used for two reasons: 3511 - There is no major requirement to make message IDs "natural" 3513 - There is no issue about being able to reply to message IDs. 3514 (For addresses, creating a return path which works is more 3515 important than being symmetrical). 3517 RFC 1327bis 3518 MIXER DRAFT Version 2.2 3520 The mapping works by defining a way in which message IDs 3521 generated on one side of the gateway can be represented on the 3522 other side in a systematic manner. The mapping is defined so 3523 that the possibility of clashes is is low enough to be treated as 3524 impossible. 3526 4.7.3.1. 822.msg-id represented in X.400 3528 IPMS.IPMIdentifier.user is omitted. The 3529 IPMS.IPMIdentifier.user-relative-identifier is set to a printable 3530 string encoding of the 822.msg-id with the angle braces ("<" and 3531 ">") removed. The upper bound on this component is 64. The 3532 options for handling this are discussed in Section 5.1.3. 3534 4.7.3.2. IPMS.IPMIdentifier represented in RFC 822 3536 The 822.domain of 822.msg-id is set to the value "MHS". The 3537 822.local-part of 822.msg-id is constructed as follows. A string 3538 is build of syntax EBNF.id-loc from IPMS.IPMIdentifier. 3540 id-loc ::= [ printablestring ] "*" [ std-or-address ] 3542 EBNF.printablestring is the 3543 IPMS.IPMIdentifier.user-relative-identifier, and EBNF.std-or- 3544 address being an encoding of the IPMS.IPMIdentifier.user derived 3545 according to this specification. 822.local-part is derived from 3546 EBNF.id-loc, if necessary using the 822.quoted-string encoding. 3547 For example: 3549 <"147*/S=Dietrich/O=Siemens/ADMD=DBP/C=DE/"@MHS> 3551 4.7.3.3. 822.msg-id -> IPMS.IPMIdentifier 3553 If the 822.local-part can be parsed as: 3555 [ printablestring ] "*" [ std-or-address ] 3557 and the 822.domain is "MHS", then this ID was X.400 generated. 3558 If EBNF.printablestring is present, the value is assigned to 3559 IPMS.IPMIdentifier.user-relative-identifier. If 3560 EBNF.std-or-address is present, the O/R Address components 3561 derived from it are used to set IPMS.IPMIdentifier.user. 3563 RFC 1327bis 3564 MIXER DRAFT Version 2.2 3566 Otherwise, this is an RFC 822 generated ID. In this case, 3567 set IPMS.IPMIdentifier.user-relative-identifier to a printable 3568 string encoding of the 822.msg-id without the angle braces. 3570 4.7.3.4. IPMS.IPMIdentifier -> 822.msg-id 3572 If IPMS.IPMIdentifier.user is absent, and 3573 IPMS.IPMIdentifier.user-relative-identifier mapped to ASCII and 3574 angle braces added parses as 822.msg-id, then this is an RFC 822 3575 generated ID. 3577 Otherwise, the ID is X.400 generated. Use the 3578 IPMS.IPMIdentifier.user to generate an EBNF.std-or-address form 3579 string. Build the 822.local-part of the 822.msg-id with the 3580 syntax: 3582 [ printablestring ] "*" [ std-or-address ] 3584 The printablestring is taken from 3585 IPMS.IPMIdentifier.user-relative-identifier. Use 3586 822.quoted-string if necessary. The 822.msg-id is generated with 3587 this 822.local-part, and "MHS" as the 822.domain. 3589 4.7.3.5. Phrase form 3591 In "In-Reply-To:" and "References:", the encoding 822.phrase may | 3592 be used as an alternative to 822.msg-id. To map from 822.phrase 3593 to IPMS.IPMIdentifier, assign 3594 IPMS.IPMIdentifier.user-relative-identifier to the phrase. When 3595 mapping from IPMS.IPMIdentifier for "In-Reply-To:" and 3596 "References:", if IPMS.IPMIdentifier.user is absent and 3597 IPMS.IPMIdentifier.user-relative-identifier does not parse as 3598 822.msg-id, generate an 822.phrase rather than adding the domain 3599 MHS. 3601 4.7.3.6. RFC 987 backwards compatibility 3603 The mapping defined here is different to that used in RFC 987, as 3604 the RFC 987 mapping lead to changed message IDs in many cases. 3605 Fixing the problems is preferable to retaining backwards 3606 compatibility. An implementation of this standard is encouraged 3607 to recognise message IDs generated by RFC 987. This is not 3608 required. 3610 RFC 1327bis 3611 MIXER DRAFT Version 2.2 3613 RFC 987 generated encodings may be recognised as follows. 3614 When mapping from X.400 to RFC 822, if the 3615 IPMS.IPMIdentifier.user-relative-identifier is "RFC-822" the id 3616 is RFC 987 generated. When mapping from RFC 822 to X.400, if the 3617 822.domain is not "MHS", and the 822.local-part can be parsed as 3619 [ printablestring ] "*" [ std-or-address ] 3621 then it is RFC 987 generated. In each of these cases, it is 3622 recommended to follow the RFC 987 rules. 3624 RFC 1327bis 3625 MIXER DRAFT Version 2.2 3627 Chapter 5 - Detailed Mappings 3629 This chapter specifies detailed mappings for the functions 3630 outlined in Chapters 1 and 2. It makes extensive use of the 3631 notations and mappings defined in Chapters 3 and 4. 3633 5.1. RFC 822 -> X.400: Detailed Mappings 3635 The mapping of RFC 822 and MIME messages to X.400 InterPersonal 3636 Messages is described in Sections 5.1.1 to 5.1.7. Mapping of 3637 NOTARY format delivery status notifications, which are all 3638 messages of type multipart/report and subtype 3639 delivery-status-notifications to X.400 delivery reports is 3640 covered in Section 5.1.8. 3642 5.1.1. Basic Approach 3644 A single IP Message is generated from an RFC 822 message. The | 3645 RFC 822 headers are used to generate the IPMS.Heading. 3647 Some RFC 822 fields cannot be mapped onto a standard IPM 3648 Heading field, and so an extended field is defined in Section 3649 5.1.2. This is then used for fields which cannot be mapped onto 3650 existing services. 3652 The message is submitted to the MTS, and the services 3653 required can be defined by specifying 3654 MTS.MessageSubmissionEnvelope. A few parameters of the MTA 3655 Abstract service are also specified, which are not in principle 3656 available to the MTS User. Use of these services allows RFC 822 3657 MTA level parameters to be carried in the analogous X.400 service 3658 elements. The advantages of this mapping far outweigh the 3659 layering violation. 3661 5.1.2. X.400 Extension Field 3663 An IPMS Extension is defined: 3665 RFC 1327bis 3666 MIXER DRAFT Version 2.2 3668 rfc-822-field HEADING-EXTENSION 3669 VALUE RFC822FieldList 3670 ::= id-rfc-822-field-list 3672 RFC822FieldList ::= SEQUENCE OF RFC822Field 3674 RFC822Field ::= IA5String 3676 The Object Identifier id-rfc-822-field-list is defined in 3677 Appendix D. 3679 To encode any RFC 822 Header using this extension, an 3680 RFC822Field element is built using the 822.field omitting the 3681 trailing CRLF (e.g., "Fruit-Of-The-Day: Kiwi Fruit"). All fields 3682 shall be unfolded. There shall be no space before the ":". The 3683 reverse mapping builds the RFC 822 field in a straightforward 3684 manner. This RFC822Field is appended to the RFC822FieldList, 3685 which is added to the IPM Heading as an extension field. 3687 5.1.3. Generating the IPM 3689 The IPM (IPMS Service Request) is generated according to the 3690 rules of this section. The IPMS.IPM.body is generated from the 3691 RFC 822 message body in the manner described in Section 5.1.5. 3693 If no specific 1988 features are used, the IPM generated is 3694 encoded as content type 2. Otherwise, it is encoded as content 3695 type 22. The latter will always be the case if extension heading 3696 fields are generated. 3698 When generating the IPM, the issue of upper bounds are | 3699 handled as follows. Truncate fields to the upper bounds specified 3700 in X.400. This will prevent problems with UAs which enforce 3701 upper bounds, but will sometimes discard useful information. 3702 This approach will cause more problems for some fields than 3703 others (e.g., truncating an O/R Address component that would be 3704 used to route a reply would be a more severe problem than 3705 truncating a Free Form Name). If the Free Form name is 3706 truncated, it shall be done so that it does not break RFC 822 | 3707 comments and RFC 1522 encoding. | 3709 Note:This approach removes a choice of options given in RFC 1327, | 3711 RFC 1327bis 3712 MIXER DRAFT Version 2.2 3714 based on operational experience. 3716 The rest of this section concerns IPMS.IPM.heading 3717 (IPMS.Heading). The only mandatory component of IPMS.Heading is 3718 the IPMS.Heading.this-IPM (IPMS.IPMIdentifier). A default is 3719 generated by the gateway. With the exception of "Received:", the 3720 values of multiple fields are merged (e.g., If there are two 3721 "To:" fields, then the mailboxes of both are merged to generate a 3722 single list which is used in the IPMS.Heading.primary-recipients. 3723 Information shall be generated from the standard RFC 822 Headers 3724 as follows: 3726 Date: 3727 Ignore (Handled at MTS level) 3729 Received: 3730 Ignore (Handled at MTA level) 3732 Message-Id: 3733 Mapped to IPMS.Heading.this-IPM. For these, and all other 3734 fields containing 822.msg-id the mappings of Chapter 4 are 3735 used for each 822.msg-id. 3737 From: 3738 If Sender: is present, this is mapped to 3739 IPMS.Heading.authorizing-users. If not, it is mapped to 3740 IPMS.Heading.originator. For this, and other components 3741 containing addresses, the mappings of Chapter 4 are used for 3742 each address. 3744 Sender: 3745 Mapped to IPMS.Heading.originator. 3747 Reply-To: 3748 Mapped to IPMS.Heading.reply-recipients. 3750 To: Mapped to IPMS.Heading.primary-recipients 3752 Cc: Mapped to IPMS.Heading.copy-recipients. 3754 Bcc: Mapped to IPMS.Heading.blind-copy-recipients if there is at 3755 least one BCC: recipient. If there are no recipients in 3756 this field, it should be mapped to a zero length sequence. 3758 RFC 1327bis 3759 MIXER DRAFT Version 2.2 3761 In-Reply-To: 3762 If there is one value, it is mapped to 3763 IPMS.Heading.replied-to-IPM, using the 822.phrase or 3764 822.msg-id mapping as appropriate. If there are several 3765 values, they are mapped to IPMS.Heading.related-IPMs, along 3766 with any values from a "References:" field. 3768 References: 3769 Mapped to IPMS.Heading.related-IPMs. 3771 Keywords: 3772 Mapped onto a heading extension. 3774 Subject: 3775 Mapped to IPMS.Heading.subject. The field-body uses the 3776 human oriented mapping referenced in Section 3.3.4. 3778 Comments: 3779 Mapped onto a heading extension. This is a change from 3780 1327, which specified to generate an IPMS.BodyPart of type 3781 IPMS.IA5TextBodyPart with 3782 IPMS.IA5TextBodyPart.parameters.repertoire set to the 3783 default (ia5), containing the value of the fields, preceded 3784 by the string "Comments: " and that this body part shall 3785 precede the other one. Experience has shown that this 3786 complexity is not justified. This text is retained to 3787 facilitate backwards compatibility. 3789 Encrypted: 3790 Mapped onto a heading extension. 3792 Resent-* 3793 Mapped onto a heading extension. 3795 Note that it would be possible to use a ForwardedIPMessage 3796 for these fields, but the semantics are (arguably) slightly 3797 different, and it is probably not worth the effort. 3799 Content-Language: 3800 This fields is defined in RFC 1766 [8]. Map the first two | 3801 characters of each value given onto the IPM Languages | 3802 extension. If any comments or values longer than two | 3803 characters occur, a header extension shall also be | 3804 generated. 3806 RFC 1327bis 3807 MIXER DRAFT Version 2.2 3809 Other Fields 3810 In particular X-* fields, and "illegal" fields in common 3811 usage (e.g., "Fruit-of-the-day:") are mapped onto a heading 3812 extension, unless covered by another section or appendix of 3813 this specification. The same treatment is applied to RFC 3814 822 fields where the content of the field does not conform 3815 to RFC 822 (e.g., a Date: field with unparseable syntax). 3817 The MIME heading are mapped as follows. When performing a reverse | 3818 mapping from X.400 to MIME, these fields may be treated as a hint 3819 to help convert the message as well as possible. Only one value 3820 for each field shall be present in the MIME message that is thus 3821 generated. 3823 MIME-Version: 3824 Mapped onto a heading extension. 3826 Content-Transfer-Encoding: 3827 Mapped onto a heading extension. 3829 Content-Type 3830 Mapped onto a heading extension. 3832 Content-ID 3833 Mapped onto a heading extension. 3835 Content-Description 3836 Mapped onto a heading extension. 3838 5.1.4. Generating the IPM Body 3840 If the header does not contain a 822.MIME-Version field, then 3841 generate a IPMS.Body with a single IPMS.BodyPart of type 3842 IPMS.IA5TextBodyPart with 3843 IPMS.IA5TextBodyPart.parameters.repertoire set to the default 3844 (ia5) containing the body of the RFC 822 message. 3846 If 822.MIME-Version is present, then the body part is 3847 analysed as a MIME message and the elements treated as described 3848 below. 3850 5.1.4.1. Mapping Multiparts 3852 A MIME multipart is a set of content-types and not a message with 3854 RFC 1327bis 3855 MIXER DRAFT Version 2.2 3857 a set of content types. When the multipart is at the outermost 3858 MIME header and is either multipart/digest or multipart/mixed, 3859 elements of the multipart are mapped directly onto IPMS.BodyPart. 3860 In other cases, a MIME multipart is mapped to an 3861 IPMS.MessageBodyPart containing an IPMS.BodyPart for each element 3862 of the multipart. 3864 When a nested IPMS.Message is generated from a multipart, an 3865 IPMS.heading shall always be generated. The only mandatory field 3866 is the IPMS.Heading.this-IPM message id, which shall be generated 3867 by the gateway. An IPMS.Heading.subject field shall also be 3868 generated, in order to provide useful information to non-MIME 3869 capable X.400(88) UAs and to all X.400(84) UAs. The subject 3870 field is set as follows according to the multipart subtype: 3872 mixed: "Multipart Message" 3873 alternative: "Alternative Body Parts containing the same information" 3874 digest: "Message Digest" 3875 parallel: "Body Parts interpreted in parallel" 3876 other: "Multipart Message ()" 3878 For other types of multipart, the multipart subtype shall be 3879 included in the subject line. 3881 For each multipart, the following IPMS.HeadingExtension shall be 3882 generated, with the enumerated value set according to the 3883 subtype: 3885 multipart-message HEADING-EXTENSION 3886 VALUE MultipartType 3887 ::= id-hex-multipart-message 3889 MultipartType ::= IA5String 3891 The MultipartType contains the subtype, for example "digest". If 3892 this heading is present when mapping from X.400 to MIME, the the 3893 appropriate multipart may be generated. 3895 5.1.4.2. Mapping Content Type Message 3897 When a message subtype is contained within a MIME message, it is 3898 mapped to an IPMS.MessageBodyPart according to this 3899 specification. Any mappings that would have been made to the MTS 3900 Abstract Service are placed in 3902 RFC 1327bis 3903 MIXER DRAFT Version 2.2 3905 IPMS.MessageBodyPart.parameters.delivery-envelope. 3907 Content type message has three subtypes, which are handled 3908 as follows: 3910 message/rfc822 3911 Mapped onto IPMS.ForwardedIPMessage. 3913 message/external 3914 This points to an external body part. As this will not in 3915 general be accessible to the X.400 recipient, the body part 3916 shall be resolved at the gateway, unless it is already | 3917 included in a multipart/alternative or the recipient UA is | 3918 known to be capable of handling a message/external tunnelled | 3919 body part. The gateway shall obtain the body part and then | 3920 map it as if it had been included. If the expiration date 3921 of the external body part has expired, the gateway may | 3922 tunnel the body part. | 3924 Editor's Note: | 3925 There has been comment that this dereference should be made | 3926 more optional or the text changed in some way. Input is | 3927 solicited. 3929 message/partial 3930 The following heading extension is added, derived from the 3931 message/partial parameters, in order to facilitate MIME 3932 capable X.400 UAs to handle messages of this type: 3934 partial-message HEADING-EXTENSION 3935 VALUE PartialMessage 3936 ::= id-hex-partial-message 3938 PartialMessage ::= 3939 SEQUENCE { 3940 number INTEGER, 3941 total INTEGER, 3942 id IA5String 3943 } 3945 message/other 3946 No specific treatment is defined for other subtypes of 3947 message. Treatment for new message subtypes may be defined 3949 RFC 1327bis 3950 MIXER DRAFT Version 2.2 3952 in future versions of MIXER. 3954 5.1.4.3. Mapping Other Content Types 3956 All other MIME content types are atomic data, and can be regarded 3957 as message attachments. 3959 The following basic types and some subtypes are defined in 3960 MIME: text; application; image; audio; video. The mapping to 3961 X.400 of the types defined in MIME is specified in RFC 1494bis. 3963 5.1.4.4. Mapping to Body Part 15 3965 RFC 1494bis defines mappings onto Body Part 15. Similar | 3966 considerations apply to body parts 1-14. MIME defines fields | 3967 which add information to MIME contents. Two of these are | 3968 "Content-ID", and "Content-Description". When mapping to body 3969 part 15, this information must be discarded, unless the specific 3970 body part 15 mapping allows it to be retained. 3972 5.1.4.5. Mapping to the EMA FTBP 3974 EMA has defined a profile for use of the File Transfer Body Part 3975 (FTBP) . [28] MIXER spepcifies mapping to FTBP, as defined by | 3976 this profile. MIXER does not define when this mapping is to be | 3977 used. This is a matter for gateway configuration and the user | 3978 agent capabilities. 3980 The exact mapping will depend on the attachment being 3981 mapped, and so cannot be defined here. The MIME headers are 3982 mapped as follows: 3984 Content-ID: 3985 If this is present, create an element 3986 FTBP.FileTransferParameters.related-stored-file. | 3987 file-identifier.cross-refernce.message-reference 3988 FTBP.FileTransferParameters.related-stored-file. | 3989 file-identifier.cross-refernce.message-reference and set it 3990 to the IPM.MessageIdentifier derived from the "Content-ID:". 3991 FTBP.FileTransferParameters.related-stored-file. 3992 relationship.descriptive-relationship is set to the string 3993 "Internet MIME Body Part". 3994 FTBP.FileTransferParameters.related-stored-file. | 3995 file-identifier.cross-refernce.application-crossreference is 3997 RFC 1327bis 3998 MIXER DRAFT Version 2.2 4000 set to a null OCTET STRING. 4002 Content-Descriptor: 4003 This is mapped to the first string in 4004 FTBP.FileTransferParameters.environment.user-visible-string. | 4006 A specific mapping for multipart/appledouble is defined. Noting | 4007 that the fileTransferData component of an FTBP is a SEQUENCE of | 4008 EXTERNAL, the file data component of the multipart is mapped onto | 4009 the first of two elements of the SEQUENCE, and the | 4010 application/applefile component (the finder and resource info) is | 4011 mapped onto the second element of the sequence. Applications | 4012 which don't care about the finder and resource info can, | 4013 therefore, simply ignore the second element and extract the data | 4014 from the first element. The direct reference component of the | 4015 first element is set to reflect the original type/subtype of the | 4016 MIME data component, according the OID's defined in RFC1494bis. | 4018 Editor's Note: | 4019 This specification is clearly useful and needed. Does it | 4020 belong in MIXER? Comments solicited. 4022 5.1.4.6. Encapsulation in X.400 4024 Where no mapping is possible, the gateway may choose to discard 4025 the body part or to reject the message. This will depend on 4026 gateway policy, and configuration knowledge. Another option is 4027 to "tunnel" the body part, by encapsulating it in X.400. This 4028 section defines an extended body part, based on body part 15, 4029 which may be used to hold any MIME content. 4031 RFC 1327bis 4032 MIXER DRAFT Version 2.2 4034 mime-body-part EXTENDED-BODY-PART-TYPE 4035 PARAMETERS MimeParameters 4036 IDENTIFIED BY id-mime-body-part-parameters 4037 DATA OCTET STRING 4038 ::= id-mime-body-part 4040 MimeParameters ::= 4041 SEQUENCE { 4042 content-type IA5String, 4043 content-parameters SEQUENCE OF 4044 SEQUENCE { 4045 parameter IA5String, 4046 parameter-value IA5String 4047 } 4048 other-header-fields RFC822FieldList 4049 } 4051 The OBJECT IDENTIFIERS id-mime-body-part and | 4052 id-mime-body-part-parameters are defined in Appendix D. A MIME 4053 content is mapped onto this body part. The MIME headers of the 4054 body part are mapped as follows: 4056 Content-Type: 4057 The "type/subtype" string is mapped to 4058 MimeParameters.content-type. 4060 For each "parameter=value" string create a 4061 MimeParameters.content-parameters element. The 4062 MimeParameters.content-Parameters.parameter field is set to 4063 the parameter and the 4064 MimeParameters.content-parameters.parameter-value field is 4065 set to the value. 4067 OtherTake all other headers and create 4068 MimeParameters.other-header-fields, by concatenating them 4069 together. 4071 Convert the MIME body part into its canonical form, as specified 4072 in Appendix H of MIME [9]. This canonical form is used to 4073 generate the mime-body-part.data octet string. 4075 The Parameter mapping may be used independently of the body 4076 part mapping (e.g., in order to use a different encoding for a | 4078 RFC 1327bis 4079 MIXER DRAFT Version 2.2 4081 mapped MIME body part). 4083 This body part contains all of the MIME information, and so 4084 can be mapped back to MIME without loss of information. 4086 5.1.5. Mappings to the MTS Abstract Service 4088 The MTS.MessageSubmissionEnvelope comprises 4089 MTS.PerMessageSubmissionFields, and 4090 MTS.PerRecipientMessageSubmissionFields. The mandatory 4091 parameters are defaulted as follows. 4093 MTS.PerMessageSubmissionFields.originator-name 4094 This is always generated from SMTP, as defined in Chapter 4. | 4096 MTS.PerMessageSubmissionFields.content-type 4097 Set to the value implied by the encoding of the IPM (2 or 4098 22). 4100 MTS.PerRecipientMessageSubmissionFields.recipient-name 4101 These will always be supplied from SMTP, as defined in | 4102 Chapter 4. 4104 Optional components are omitted, and default components 4105 defaulted. This means that disclosure of recipients is 4106 prohibited and conversion is allowed. There are two exceptions 4107 to the defaulting. For 4108 MTS.PerMessageSubmissionFields.per-message-indicators, the 4109 following settings are made: 4111 - Alternate recipient is allowed, as it seems desirable to 4112 maximise the opportunity for (reliable) delivery. * 4114 If SMTP is used, Appendix A shall be followed in setting these | 4115 parameters. 4117 MTS.PerMessageSubmissionFields.original-encoded-information-types | 4118 is derived from the message generated by the gateway, and shall | 4119 reflect all body parts. | 4121 The MTS.PerMessageSubmissionFields.content-correlator is encoded 4122 as IA5String, and contains the Subject:, Message-ID:, Date:, and 4123 To: fields (if present). This includes the strings "Subject:", 4124 "Date:", "To:", "Message-ID:", and appropriate folding to make | 4126 RFC 1327bis 4127 MIXER DRAFT Version 2.2 4129 the field appear readable. This shall be truncated to 4130 MTS.ub-content-correlator-length (512) characters. In addition, 4131 if there is a "Subject:" field, the 4132 MTS.PerMessageSubmissionFields.content-identifier, is set to a 4133 printable string representation of the contents of it. If the 4134 length of this string is greater than MTS.ub-content-id-length 4135 (16), it should be truncated to 13 characters and the string 4136 "..." appended. Both are used, due to the much larger upper bound 4137 of the content correlator, and that the content id is available 4138 in X.400(1984). 4140 5.1.6. Mappings to the MTA Abstract Service 4142 There is a need to map directly onto some aspects of the MTA 4143 Abstract service, for the following reasons: 4145 - So the the MTS Message Identifier can be generated from the 4146 RFC 822 Message-ID:. 4148 - So that the submission date can be generated from the 4149 822.Date. 4151 - To prevent loss of trace information 4153 - To prevent RFC 822/X.400 looping caused by distribution 4154 lists or redirects 4156 The following mappings are defined. 4158 Message-Id: 4159 If this is present, the 4160 MTA.PerMessageTransferFields.message-identifier is generated 4161 from it, using the mappings described in Chapter 4. 4163 This mapping arguably generates messages which do not 4164 conform to US GOSIP (1984 version only), which states: | 4166 RFC 1327bis 4167 MIXER DRAFT Version 2.2 4169 6.7.e MPDI Identifier Validation | 4171 (1) Validation of the GlobalDomainIdentifier component of the MPDU| 4172 Identifier is performed on reception of a message (i.e. the result| 4173 of a TRANSFER.Indication). | 4174 | 4175 (2) The country name should be known to the validating domain, and| 4176 depending on the country name, validation of the ADMD name may also| 4177 be possible. | 4179 (3) Additional validation of the GlobalDomainIdentifier is performed| 4180 against the corresponding first entry in the TraceInformation. If| 4181 inconsistencies are found during the comparison, a non-delivery| 4182 notice with the above defined reason and diagnosticcode is | 4183 generated. | 4185 (4) A request will be generated to the CCITT for a more meaningful| 4186 diagnostic code (such as "InconsistentMPUTIdentifier"). | 4188 This applies to ADMDs only, and is specified in the 1984 4189 version and not the 1988 version. Conformance depends on the 4190 interpretation of "inconsistency". The specification makes 4191 the most sensible choice, and so is not being changed in the 4192 update from RFC 1327. 4194 Date: 4195 This is used to set the first component of 4196 MTA.PerMessageTransferFields.trace-information 4197 (MTA.TraceInformationElement). The SMTP originator is | 4198 mapped into an MTS.ORAddress, and used to derive 4199 MTA.TraceInformationElement.global-domain-identifier. The 4200 optional components of 4201 MTA.TraceInformationElement.domain-supplied-information are 4202 omitted, and the mandatory components are set as follows: 4204 MTA.DomainSuppliedInformation.arrival-time 4205 This is set to the date derived from Date: 4207 MTA.DomainSuppliedInformation.routing-action 4208 Set to relayed. 4210 The first element of 4212 RFC 1327bis 4213 MIXER DRAFT Version 2.2 4215 MTA.PerMessageTransferFields.internal-trace-information is 4216 generated in an analogous manner, although this can be 4217 dropped later in certain circumstances (see the procedures 4218 for "Received:"). The 4219 MTA.InternalTraceInformationElement.mta-name is derived from 4220 the 822.domain in the 822 MTS Originator address. 4222 Received: 4223 All RFC 822 trace is used to derive 4224 MTA.PerMessageTransferFields.trace-information and 4225 MTA.PerMessageTransferFields.internal-trace-information. 4226 Processing of Received: lines follows processing of Date:, 4227 and is be done from the the bottom to the top of the RFC 822 4228 header (i.e., in chronological order). When other trace 4229 elements (in particular X400-Received:) are processed the | 4230 relative ordering (top to bottom of the header) shall be | 4231 retained correctly. The initial element of 4232 MTA.PerMessageTransferFields.trace-information will be 4233 generated already (from Date:), unless the message has 4234 previously been in X.400, when it will be derived from the 4235 X.400 trace information. 4237 Consider the Received: field in question. If the "by" part 4238 of the received is present, use it to derive an 4239 MTS.GlobalDomainIdentifier. If this is different from the 4240 one in the last element of 4241 MTA.PerMessageTransferFields.trace-information 4242 (MTA.TraceInformationElement.global-domain-identifier) 4243 create a new MTA.TraceInformationElement, and optionally 4244 remove 4245 MTA.PerMessageTransferFields.internal-trace-information. 4246 This removal shall be done in cases where the message is 4247 being transferred to another MD where there is no bilateral 4248 agreement to preserve internal trace beyond the local MD. 4249 The trace creation is as for internal trace described below, 4250 except that no MTA field is needed. | 4252 Editor's Note: | 4253 It has been proposed to remove this paragraph, as this | 4254 should be done by the MTA beyond the gateway. Input | 4255 solicited. 4257 Then add a new element (MTA.InternalTraceInformationElement) 4258 to MTA.PerMessageTransferFields.internal-trace-information, 4260 RFC 1327bis 4261 MIXER DRAFT Version 2.2 4263 creating this if needed. This shall be done, even if 4264 inter-MD trace is created. The 4265 MTA.InternalTraceInformationElement.global-domain-identifier 4266 is set to the value derived. The 4267 MTA.InternalTraceInformationElement.mta-supplied-information 4268 (MTA.MTASuppliedInformation) is set as follows: 4270 MTA.MTASuppliedInformation.arrival-time 4271 Derived from the date of the Received: line 4273 MTA.MTASuppliedInformation.routing-action 4274 Set to relayed 4276 The MTA.InternalTraceInformationElement.mta-name is taken 4277 from the "by" component of the "Received:" field, truncated 4278 to MTS.ub-mta-name-length (32). For example: 4280 Received: from computer-science.nottingham.ac.uk by 4281 vs6.Cs.Ucl.AC.UK via Janet with NIFTP id aa03794; 4282 28 Mar 89 16:38 GMT 4284 Generates the string 4286 vs6.Cs.Ucl.AC.UK 4288 Note that before transferring the message to some ADMDs, 4289 additional trace stripping may be required, as the implied path 4290 through multiple MDs would violate ADMD policy. This will 4291 depend on bilateral agreement with the ADMD. 4293 The gateway itself shall not add trace information. 4294 However, for trace purposes, the gateway shall be considered as 4295 an X.400 and Internet MTA back to back, and both of these shall 4296 add trace elements. 4298 5.1.7. Mapping New Fields 4300 This specification defines a number of new fields for Reports, 4301 Notifications and IP Messages. A gateway conforming to this | 4302 specification shall map all of these fields to X.400, except as | 4303 defined below. 4305 RFC 1327bis 4306 MIXER DRAFT Version 2.2 4308 The mapping of two extended fields is particularly | 4309 important, in order to prevent looping. "DL-Expansion-History:" 4310 is mapped to 4311 MTA.PerMessageTransferFields.extensions.dl-expansion-history 4312 X400-Received: must be mapped to 4313 MTA.PerMessageTransferFields.trace-information and 4314 MTA.PerMessageTransferFields.internal-trace-information. In 4315 cases where X400-Received: is present, the usual mapping of Date: 4316 to generate the first element of trace should not be done. This 4317 is because the message has come from X.400, and so the first 4318 element of trace can be taken from the first X400-Received:. 4320 The following fields shall not be mapped, and shall be 4321 discarded: 4323 - Discarded-X400-MTS-Extensions: 4325 - Message-Type: 4327 - Discarded-X400-IPMS-Extensions: 4329 - X400-Content-Type: 4331 - X400-Originator: 4333 - X400-Recipients: 4335 - X400-MTS-Identifier: Mapping this field would be useful in | 4336 some circumstances, but very dangerouts in others (e.g., | 4337 following an internet list expansion). Therefore it is not | 4338 mapped. 4340 5.1.8. Mapping Delivery Status Notifications to X.400 4342 5.1.8.1. Basic Model 4344 Internet Mail delivery status notifications (DSN) are mapped to 4345 X.400 delivery reports. With message mapping, information 4346 without a mapping is carried by an IPM Extension. This cannot | 4347 be done for delivery reports. Two mechanisms are used for 4348 information where there is not a direct mapping. 4350 The first mechanism is to define extensions, which allow all 4352 RFC 1327bis 4353 MIXER DRAFT Version 2.2 4355 of the DSN information to be carried in the delivery report. 4356 This is not completely satisfactory for two reasons: 4358 1. User defined extensions are supported by the ISO version of 4359 the standard, but not the CCITT one. Therefore, 4360 implementation support for these extensions will not be 4361 universal. 4363 2 X.400 User Agent implementations will not in general 4364 recognise these extensions. Therefore, although the 4365 information will be present, it will often not be available | 4366 to the user. This may be very problematic, as this 4367 information may be critical to diagnosing the reason for a 4368 failure. 4370 Therefore a second mechanism is defined. This shall always 4371 be used when the DSN contains non-delivery information, and may 4372 be used in other cases. This mechanism is to map the whole DSN | 4373 (as if it were an ordinary multipart) into the return of content. 4374 This will make the DSN information available as a text body part 4375 in the outer message, with the real returned content as an 4376 enclosed message. This mechanism will ensure that information is 4377 not lost at the gateway. 4379 5.1.8.2. DSN Extensions 4381 Two X.400 MTS extensions are defined as follows: 4383 dsn-header-list EXTENSION 4384 RFC822FieldList 4385 ::= id-dsn-header-list 4387 dsn-field-list EXTENSION 4388 RFC822FieldList 4389 ::= id-dsn-field-list 4391 The Object Identifiers id-dsn-header-list and id-dsn-field-list | 4392 are defined in Appendix D. These extension is used in the same 4393 way as the IPM extension rfc-822-field, described in Section | 4394 5.1.2. These extensions may only be used with ISO-10021, and | 4395 not X.400 (which does not allow user extensions at the MTS | 4396 level). 4398 RFC 1327bis 4399 MIXER DRAFT Version 2.2 4401 5.1.8.3. DSN to Delivery Report Mapping 4403 Reports may not be submitted in the X.400 model, and so the 4404 report submission is considered in terms of the MTA Abstract 4405 Service. An MTA.Report is constructed. The 4406 MTA.ReportTransferFields.report-identifier is generated from the 4407 Message-Id of the DSN (if present) and otherwise generated as the 4408 MTA would generate one for a submitted message. 4410 The DSN has an RFC 822 header. Trace is mapped in the same 4411 manner as for a message to 4412 MTA.ReportTransferEnvelope.trace-information. All other headers 4413 are used to create a dsn-header-list extension, which is added to | 4414 MTA.ReportTransferFields.extensions. 4416 The DSN will have a single SMTP recipient. This is mapped | 4417 to the MTA.ReportTransferEnvelope.report-destination-name. 4419 The DSN is then treated as a normal MIME message, and an 4420 X.400 IPM is generated. This IPM is used as 4421 MTA.PerReportTransferFields.returned-content, and its type is 4422 used to set MTA.PerReportTransferFields.content-type. The DSN 4423 body part is mapped as if it was IA5 text/plain. 4425 All other mappings are made from the DSN body part. A dsn- 4426 field-list extension is created and added to 4427 MTA.ReportTransferFields.extensions. This is referred to as the 4428 per report extension list. The DSN.per-message-fields are mapped 4429 as follows: 4431 original-envelope-id-field 4432 reporting-mta-field | 4433 dsn-gateway-field | 4434 received-from-mta-field | 4435 arrival-date-field | 4436 extension-field | 4437 other | 4438 All of these fields are added to the per report extension 4439 list. Currently there are no other mappings defined. 4441 Each reported recipient is considered in turn, and a 4442 MTA.PerRecipientReportTransferFields created for each. The 4443 parameters of this are defaulted as follows: 4445 RFC 1327bis 4446 MIXER DRAFT Version 2.2 4448 originally-specified-recipient-number 4449 In general, these are not available, and so are assigned 4450 incrementally. 4452 last-trace-information 4453 The arrival-time is generated from DSN.arrival-date if | 4454 present, and if not from the Date: of the DSN. 4456 A dsn-field-list extension is created and added to 4457 MTA.PerRecipientTransferFields.extensions. This is referred to 4458 as the per recipient extension list. The 4459 DSN.per-recipient-fields are mapped as follows 4461 original-recipient-field 4462 Mapped to 4463 MTA.PerRecipientReportTransferFields.originally-intended-recipient-name. 4465 final-recipient-field 4466 Mapped to 4467 MTA.PerRecipientReportTransferFields.actual-recipient-name. 4469 action-field 4470 If this is set to "failed", a non-delivery report is 4471 generated. Otherwise a delivery report is generated. Bit 4472 one or two of 4473 MTA.PerRecipientTransferFields.per-recipient-indicators is 4474 set accordingly. This also controls the encoding of 4475 MTA.PerRecipientTransferFields.last-trace-information, and 4476 the selection of the report type. 4478 status-field 4479 This is added to the per report extension list. For non- 4480 delivery, it is also used to generate the reason and 4481 diagnostic codes contained within 4482 MTA.PerRecipientReportTransferFields.last-trace. The 4483 mappings are defined below. 4485 remote-mta-field 4487 diagnostic-code-field 4489 last-attempt-date-field 4491 will-retry-until-field 4493 RFC 1327bis 4494 MIXER DRAFT Version 2.2 4496 extension-field 4498 other 4499 All of these fields are added to the per recipient extension | 4500 list. 4502 5.1.8.4. Status Value Mappings 4504 Status values are mapped to X.400 reason and diagnostic codes as 4505 follows. 4507 DSN code Meaning X400 code Meaning | 4509 X.0.0 Other status 1/None 4511 X.1.0 Other Address Status 1/None 4512 X.1.1 Bad mailbox address 1/0 Unrecognized 4513 X.1.2 Bad system address 1/0 Unrecognized 4514 X.1.3 Bad mailbox address syntax 1/0 Unrecognized 4515 X.1.4 Mailbox address ambiguous 1/1 4517 X.2.0 Other or undefined mailbox status 1/None 4518 X.2.1 Mailbox disabled, not accepting 1/4 Recipient unavailable 4519 X.2.2 Mailbox full 1/4 4520 X.2.3 Message length exceeds admin limit. 1/7 Content too long 4521 X.2.4 Mailing list expansion problem 1/30 DL expansion failure 4523 X.3.0 Other or undefined system status 0/None 4524 X.3.1 System full 1/2 MTS congestion 4525 X.3.2 System not accepting network messages 1/2 MTS congestion 4526 X.3.3 System not capable of selected feat 1/18 Unsupp. crit. func 4527 X.3.4 Message too big for system 1/7 4529 X.4.0 Other or undefined network or routing 0/None 4530 X.4.1 No answer from host 0/None 4531 X.4.2 Bad connection 0/None 4532 X.4.3 Routing server failure 6/None Directory op unsucc. 4533 X.4.4. Unable to route 0/None 4534 X.4.5 Network congestion 1/2 MTS congest. 4535 X.4.6 Routing loop detected 1/3 4536 X.4.7 Delivery time expired 1/5 4538 RFC 1327bis 4539 MIXER DRAFT Version 2.2 4541 X.5.0 Other or undefined protocol status 1/None 4543 X.5.1 Invalid command 1/14 Protocol viol. 4544 X.5.2 Syntax error 1/14 4545 X.5.3 Too many recipients 1/16 4546 X.5.4 Invalid command arguments 1/14 4547 X.5.5 Wrong protocol version 1/18 Unsupp.crit.func 4549 X.6.0 Other or undefined media error 2/None Conv. not perf 4550 X.6.1 Media not supported 1/6 EIT unsupp. 4551 X.6.2 Conversion required and prohibited 1/9 4552 X.6.3 Conversion required but not supported 2/8 4553 X.6.4 Conversion with loss performed POSITIVE only 4555 X.7.0 Other or undefined security status 1/46 4556 X.7.1 Delivery not authorized, message ref 1/29 No DL submit perm 4557 X.7.2 Mailing list expansion prohibited 1/28 4558 X.7.3 Security conversion req but not poss 1/46 Secure mess. error 4559 X.7.4 Security features not supported 1/46 4560 X.7.5 Cryptographic failure 1/46 4561 X.7.6 Cryptographic algorithm not supported 1/46 4562 X.7.7 Message integrity failure 1/46 4564 5.1.8.5. DSNs that originated in X.400 4566 The mapping of X.400 delivery reports to DSNs will in general 4567 provide sufficient information to make a useful reverse mapping. 4568 Messages will often be mapped multiple times, commonly due to 4569 forwarding messages and to distribution lists. Multiple 4570 mappings for delivery reports will be a good deal less common. 4571 For this reason, the reverse mapping of the X.400 DSN extensions 4572 defined in MIXER is optional. 4574 5.2. Return of Contents 4576 It is not clear how widely supported the X.400 return of contents 4577 service will be. Experience with X.400(1984) suggests that 4578 support of this service may not be universal. As this service is 4579 expected in the RFC 822 world, two approaches are specified. The 4580 choice will depend on the use of X.400 return of contents withing 4581 the X.400 community being serviced by the gateway. 4583 RFC 1327bis 4584 MIXER DRAFT Version 2.2 4586 In environments where return of contents is widely 4587 supported, content return can be requested as a service. The 4588 content return service can then be passed back to the end (RFC 4589 822) user in a straightforward manner. * 4591 5.3. X.400 -> RFC 822: Detailed Mappings 4593 5.3.1. Basic Approach 4595 A single RFC 822 message is generated from the incoming IP 4596 Message, Report, or IP Notification. All IPMS.BodyParts are 4597 mapped onto a single RFC 822 body. Other services are mapped 4598 onto RFC 822 header fields. Where there is no appropriate 4599 existing field, new fields are defined for IPMS, MTS and MTA 4600 services. 4602 The gateway mechanisms will correspond to MTS Delivery. As 4603 with submission, there are aspects where the MTA (transfer) 4604 services are also used. In particular, there is an optimisation | 4605 to allow for multiple SMTP recipients. 4607 5.3.2. RFC 822 Settings 4609 An RFC 822 Message has a number of mandatory fields in the RFC | 4610 822 Header. Some SMTP services mandate specification of an SMTP 4611 Originator. Even in cases where this is optional, it is usually 4612 desirable to specify a value. The following defaults are 4613 defined, which shall be used if the mappings specified do not 4614 derive a value: | 4616 SMTP Originator | 4617 If this is not generated by the mapping (e.g., for a 4618 Delivery Report), a value pointing at a gateway 4619 administrator shall be assigned. 4621 Date: 4622 A value will always be generated 4624 From: 4625 If this is not generated by the mapping, it is assigned 4626 equal to the SMTP Originator. If this is gateway generated, | 4627 an appropriate 822.phrase shall be added. 4629 At least one recipient field 4631 RFC 1327bis 4632 MIXER DRAFT Version 2.2 4634 If no recipient fields are generated, a field "To: list:;", 4635 shall be added. 4637 This will ensure minimal RFC 822 compliance. When generating RFC 4638 822 headers, folding may be used. It is recommended to do this, 4639 following the guidelines of RFC 822. 4641 5.3.3. Basic Mappings 4643 5.3.3.1. Encoded Information Types 4645 This mapping from MTS.EncodedInformationTypes is needed in 4646 several disconnected places. EBNF is defined as follows: 4648 encoded-info = 1#encoded-type 4650 encoded-type = built-in-eit / object-identifier 4652 built-in-eit = "Undefined" ; undefined (0) 4653 / "Telex" ; tLX (1) 4654 / "IA5-Text" ; iA5Text (2) 4655 / "G3-Fax" ; g3Fax (3) 4656 / "TIF0" ; tIF0 (4) 4657 / "Teletex" ; tTX (5) 4658 / "Videotex" ; videotex (6) 4659 / "Voice" ; voice (7) 4660 / "SFD" ; sFD (8) 4661 / "TIF1" ; tIF1 (9) 4663 MTS.EncodedInformationTypes is mapped onto EBNF.encoded-info. 4664 MTS.EncodedInformationTypes.non-basic-parameters is ignored. 4665 Built in types are mapped onto fixed strings (compatible with 4666 X.400(1984) and RFC 987), and other types are mapped onto 4667 EBNF.object-identifier. 4669 5.3.3.2. Global Domain Identifier 4671 The following simple EBNF is used to represent 4672 MTS.GlobalDomainIdentifier: 4674 global-id = std-or-address 4676 This is encoded using the std-or-address syntax, for the 4678 RFC 1327bis 4679 MIXER DRAFT Version 2.2 4681 attributes within the Global Domain Identifier. 4683 5.3.4. Mappings from the IP Message 4685 Consider that an IPM has to be mapped to RFC 822. The IPMS.IPM 4686 comprises an IPMS.IPM.heading and IPMS.IPM.body. The heading is 4687 considered first. Some EBNF for new fields is defined: 4689 ipms-field = "Obsoletes" ":" 1#msg-id 4690 / "Expiry-Date" ":" date-time 4691 / "Reply-By" ":" date-time 4692 / "Importance" ":" importance 4693 / "Sensitivity" ":" sensitivity 4694 / "Autoforwarded" ":" boolean 4695 / "Incomplete-Copy" ":" 4696 / "Content-Language" ":" 1#language | 4697 / "Message-Type" ":" message-type 4698 / "Discarded-X400-IPMS-Extensions" ":" 1#object-identifier 4699 / "Autosubmitted" ":" autosubmitted 4701 importance = "low" / "normal" / "high" 4703 sensitivity = "Personal" / "Private" / 4704 "Company-Confidential" 4706 language = 2*ALPHA [ language-description ] 4707 language-description = printable-string 4709 message-type = "Delivery Report" 4710 / "InterPersonal Notification" 4711 / "Multiple Part" 4713 autosubmitted = "not-auto-submitted" 4714 / "auto-generated" 4715 / "auto-replied" 4716 / "auto-forwarded" 4718 RFC 1327bis 4719 MIXER DRAFT Version 2.2 4721 The mappings and actions for the IPMS.Heading are now specified | 4722 for each element. Addresses and Message Identifiers are mapped 4723 according to Chapter 4. Other mappings are explained, or are 4724 straightforward (algorithmic). If a field with addresses 4725 contains zero elements, it should be discarded, except for 4726 IPMS.Heading.blind-copy-recipients, which can be mapped onto BCC: 4727 (the only RFC 822 field which allows zero recipients). 4729 IPMS.Heading.this-IPM 4730 Mapped to "Message-ID:". 4732 IPMS.Heading.originator 4733 If IPMS.Heading.authorizing-users is present this is mapped 4734 to Sender:, if not to "From:". 4736 IPMS.Heading.authorizing-users 4737 Mapped to "From:". 4739 IPMS.Heading.primary-recipients 4740 Mapped to "To:". 4742 IPMS.Heading.copy-recipients 4743 Mapped to "Cc:". 4745 IPMS.Heading.blind-copy-recipients 4746 Mapped to "Bcc:". 4748 IPMS.Heading.replied-to-ipm 4749 Mapped to "In-Reply-To:". 4751 IPMS.Heading.obsoleted-IPMs 4752 Mapped to the extended RFC 822 field "Obsoletes:" 4754 IPMS.Heading.related-IPMs 4755 Mapped to "References:". 4757 IPMS.Heading.subject 4758 Mapped to "Subject:". The contents are converted to ASCII 4759 or T.61 (as defined in Section 3.5). Any CRLF are not 4760 mapped, but are used as points at which the subject field 4761 must be folded. 4763 IPMS.Heading.expiry-time 4764 Mapped to the extended RFC 822 field "Expiry-Date:". 4766 RFC 1327bis 4767 MIXER DRAFT Version 2.2 4769 IPMS.Heading.reply-time 4770 Mapped to the extended RFC 822 field "Reply-By:". 4772 IPMS.Heading.reply-recipients 4773 Mapped to "Reply-To:". 4775 IPMS.Heading.importance 4776 Mapped to the extended RFC 822 field "Importance:". 4778 IPMS.Heading.sensitivity 4779 Mapped to the extended RFC 822 field "Sensitivity:". 4781 IPMS.Heading.autoforwarded 4782 Mapped to the extended RFC 822 field "Autoforwarded:". 4784 The standard extensions (Annex H of X.420 / ISO 10021-7) are 4785 mapped as follows: 4787 incomplete-copy 4788 Mapped to the extended RFC 822 field "Incomplete-Copy:". 4790 language 4791 Mapped to the RFC 822 field "Content-Language:", defined in 4792 RFC 1766 [8]. This mapping may be made without loss of 4793 information. 4795 auto-submitted 4796 Map to the extended RFC 822 field "Autosubmitted:". 4798 If the RFC 822 extended header is found, this shall be 4799 mapped onto an RFC 822 header, as described in Section 5.1.2. 4801 If a non-standard extension is found, it shall be discarded, 4802 unless the gateway understands the extension and can perform an 4803 appropriate mapping onto an RFC 822 header field. If extensions 4804 are discarded, the list is indicated in the extended RFC 822 4805 field "Discarded-X400-IPMS-Extensions:". 4807 5.3.4.1. Mapping the IPMS Body 4809 The IPMS.Body is mapped into the RFC 822 message body. If the 4810 IPMS.Body consists of a single IPMS.Bodypart, there are three 4811 possibilities. 4813 RFC 1327bis 4814 MIXER DRAFT Version 2.2 4816 1. If it is of type IPMS.IA5Text, then this is mapped directly 4817 and no MIME encoding is used. 4819 2. If it is of type IPMS.MessageBodyPart, then a MIME message 4820 with content type message/rfc822 is generated, following the 4821 mappings described for IPMS.BodyPart given below, except in | 4822 the case where a multipart-message heading extension is | 4823 present. In the latter case the mapping of 5.1 shall be | 4824 reversed. 4826 3. The mapping of other body parts is specified below. 4828 If the IPMS.Body contains multiple IPMS.BodyPart fields, then a 4829 MIME message of content type multipart is generated. If all of 4830 the body parts are messages, then this is multipart/digest. 4831 Otherwise it is multipart/mixed. The components of the multipart 4832 are generated in the same order as in the IPMS.Body. Body parts 4833 which are not messages are mapped according to RFC 1494bis. | 4835 To map an IPMS.MessageBodyPart, the full X.400 -> RFC 822 4836 mapping is recursively applied, to generate an RFC 822 Message. 4837 If present, the IPMS.MessageBodyPart.parameters.delivery-envelope 4838 is used for the MTS Abstract Service Mappings. If present, the 4839 IPMS.MessageBodyPart.parameters.delivery-time is mapped to the 4840 extended RFC 822 field "Delivery-Date:". 4842 To support X.400(1984) mappings of Internet Messages, the 4843 following procedure shall also be followed. If there is more 4844 than one body part, and the first body part is IA5 starts with 4845 the string "RFC-822-Headers:" as the first line, then the 4846 remainder of this body part shall be appended to the RFC 822 | 4847 header. This relies that this body part has been generated | 4848 according to Appedix B of MIXER. A gateway shall check the | 4849 consistency and syntax of this body part, to ensure that the | 4850 resulting message is conformant. 4852 5.3.4.2. Mapping Body Parts 4854 X.400 and MIME define extensible approaches for body parts, and 4855 the ability to map a specific body part depends on the gateway's 4856 knowledge. Mapping of all standard X.400 body parts, and some 4857 extended body parts is defined in RFC 1494bis. 4859 The case of File Transfer Body Part (FTBP) is described 4861 RFC 1327bis 4862 MIXER DRAFT Version 2.2 4864 below. 4866 Where no mapping is known by the gateway, it may choose to 4867 drop the body part, or reject the message. It may also 4868 encapsulate the body part in a mechanism which can be used for 4869 any extended X.400 body part. This is specified below. The 4870 option will depend on the gateway configuration and its knowledge 4871 of the recipient capabilities. 4873 5.3.4.3. File Transfer Body Part 4875 X.400 specifies a file transfer body part (FTBP). Generic 4876 mapping of FTBP is beyond the scope of MIXER. EMA have defined 4877 a profile of FTBP to carry attachments [28]. MIXER defines a 4878 mapping of FTBP to MIME, which is intended for use in conjunction 4879 with this profile. FTBP is used to carry various pieces of 4880 information associated with an attachment. The key mapping will 4881 be to correctly convert the contents of the attachment. This 4882 specification also provides a mechanism for mapping the 4883 parameters which EMA have recommended to be used in version 1.4 4884 of the specification. A BNF is defined below: 4886 ftbp-field = "FTBP-Object-Size" ":" integer | 4887 / "FTBP-Creation-Date" ":" date-time 4888 / "FTBP-Modification-Date" ":" date-time 4889 "FTBP-Read-Date" ":" date-time 4891 Some parameters are encoded as graphical strings. To map | 4892 these to ASCII, those characters that map directly are mapped, 4893 and others are translated to "?". This simple non-reversible 4894 mapping is seen as appropriate for the application, and in line 4895 with the spirit of the EMA profile. 4897 Mapping of the data will be dependent on the attachment, its 4898 encoding, and the MIME representation. These cannot be 4899 specified here. 4901 Other FTBP Parameters are mapped as follows: 4903 FileTransferParameters.environment.user-visible-string 4904 This is mapped to the "Content-Descriptor:" header. 4906 The following elements of FileTransferParameters.file-attributes 4908 RFC 1327bis 4909 MIXER DRAFT Version 2.2 4911 are mapped as follows: 4913 pathname 4914 Mapped to "Content-Dispostion:", as defined in RFC 1806 | 4915 [33]. The EBNF.disposition-type is set to "attachment", and | 4916 the filename is included as a parameter. For example: | 4918 Content-Disposition: attachment; filename=/var/joe/dodo.doc 4920 It is expected that only the incomplete option will be 4921 found, but the mapping is used for either variant. The 4922 separator between multiple components is "/". 4924 date-and-time-of-creation 4925 Mapped to "FTBP-Creation-Date:". 4927 date-and-time-of-last-modification 4928 Mapped to "FTBP-Modification-Date:". 4930 date-and-time-of-last-read-access 4931 Mapped to "FTBP-Read-Date:". 4933 object-size 4934 Mapped to "FTBP-Object-Size:". 4936 5.3.4.4. Tunnelling X.400 Body Parts 4938 This section specifies a generic mechanism to map X.400 body 4939 parts to a MIME content. This allows for the body part to be 4940 tunnelled through MIME. It may also be used directly by an 4941 appropriately configured MIME UA. 4943 This content-type is defined to carry any X.400 extended 4944 body part. The mapping of all standard X.400 body parts is 4945 defined in RFC1494bis. The content-type field is 4946 "application/x400-bp". The parameter is defined by the EBNF: 4948 mime-parameter = "bp-type=" object-identifier 4950 The EBNF.object-identifier is set to the OBJECT IDENTIFIER 4951 from IPMS.body.externally-defined.data.direct-reference . 4953 For example, a Videotex body part will have 4955 RFC 1327bis 4956 MIXER DRAFT Version 2.2 4958 Content-type=application/x400-bp; bp-type=2.6.1.4.5 4960 The body contains the raw ASN.1 IPM.body octet stream, 4961 including the initial tag octet. The content may use a content- 4962 transfer-encoding of either base64 or quoted-printable when 4963 carried in 7-bit MIME. It is recommended to use the one which 4964 gives the more compact encoding of the data. If this cannot be 4965 determined, Base64 is recommended. No attempt is made to turn 4966 the parameters of Extended Body Parts into MIME parameters, as 4967 this cannot be done in a general manner. 4969 Standard X.400 body parts may not be encoded directly by 4970 this mechanism, but may be encoded indirectly by first 4971 translating to the extended representation. * 4973 5.3.4.5. Example Message 4975 An example message, illustrating a number of aspects is given 4976 below. 4978 RFC 1327bis 4979 MIXER DRAFT Version 2.2 4981 Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP 4982 id <7906-0@bells.cs.ucl.ac.uk>; Thu, 30 May 1991 18:24:55 +0100 4983 X400-Received: by mta "mhs-relay.ac.uk" in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; 4984 Thu, 30 May 1991 18:23:26 +0100 4985 X400-Received: by /PRMD=HMG/ADMD=GOLD 400/C=GB/; Relayed; 4986 Thu, 30 May 1991 18:20:27 +0100 4987 Message-Type: Multiple Part 4988 Date: Thu, 30 May 1991 18:20:27 +0100 4989 X400-Originator: Stephen.Harrison@gosip-uk.hmg.gold-400.gb 4990 X400-MTS-Identifier: 4991 [/PRMD=HMG/ADMD=GOLD 400/C=GB/;PC1000-910530172027-57D8] 4992 Original-Encoded-Information-Types: ia5 | 4993 X400-Content-Type: P2-1984 (2) 4994 X400-Content-Identifier: Email Problems 4995 From: Stephen.Harrison@gosip-uk.hmg.gold-400.gb (Tel +44 71 217 3487) 4996 Message-ID: 4997 To: Jim Craigie , 4998 Tony Bates , 4999 Steve Kille 5000 Subject: Email Problems 5001 Sender: Stephen.Harrison@gosip-uk.hmg.gold-400.gb 5002 MIME-Version: 1.0 5003 Content-Type: multipart/mixed; boundary=boundary-1 5005 --boundary-1 5006 Content-Type: text/plain; charset=US-ASCII 5008 Hope you gentlemen....... 5010 Regards, 5012 Stephen Harrison 5013 UK GOSIP Project 5015 ..... continued on next page 5017 RFC 1327bis 5018 MIXER DRAFT Version 2.2 5020 --boundary-1 5021 Content-Type: message/rfc822 5023 From: Urs Eppenberger 5024 Message-ID: 5025 <562*/S=Eppenberger/OU=verw/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> 5026 To: "Stephen.Harrison" 5027 Cc: kimura@bsdarc.bsd.fc.nec.co.jp 5028 Subject: Response to Email link 5029 Content-Type: multipart/mixed; boundary=boundary-2 5031 --boundary-2 5033 Dear Mr Harrison...... 5035 --boundary-2-- | 5037 --boundary-1-- | 5039 5.3.5. Mappings from an IP Notification 5041 Because of the service setting, IP Notifications will not usually | 5042 need to be mapped by a MIXER gateway. A message is generated, 5043 with the following fields: 5045 From: 5046 Set to the IPMS.IPN.ipn-originator. 5048 To: Set to the recipient from MTS.MessageSubmissionEnvelope. 5049 If there have been redirects, the original address should be 5050 used. 5052 Subject: 5053 Set to the string "X.400 Inter-Personal Notification" for a 5054 receipt notification and to "X.400 Inter-Personal 5055 Notification (failure)" for a non-receipt notification. 5057 Message-Type: 5059 RFC 1327bis 5060 MIXER DRAFT Version 2.2 5062 Set to "InterPersonal Notification" 5064 References: 5065 Set to IPMS.IPN.subject-ipm 5067 Discarded-X400-IPMS-Extensions: 5068 Used for any discarded IPN extensions. 5070 The following EBNF is defined for the body of the Message. This 5071 format is defined to ensure that all information from an 5072 interpersonal notification is available to the end user in a 5073 uniform manner. 5075 RFC 1327bis 5076 MIXER DRAFT Version 2.2 5078 ipn-body-format = ipn-description 5079 [ ipn-extra-information ] 5080 [ ipn-content-return ] 5082 ipn-description = ipn-receipt / ipn-non-receipt 5084 ipn-receipt = "Your message to:" preferred-recipient 5085 "was received at" receipt-time 5086 "This notification was generated" 5087 acknowledgement-mode 5088 "The following extra information was given:" 5089 ipn-suppl 5091 ipn-non-receipt "Your message to:" 5092 preferred-recipient 5093 ipn-reason 5095 ipn-reason = ipn-discarded / ipn-auto-forwarded 5097 ipn-discarded = "was discarded for the following reason:" 5098 discard-reason 5100 ipn-auto-forwarded = "was automatically forwarded." 5101 [ "The following comment was made:" 5102 auto-comment ] 5104 ipn-extra-information = 5105 "The following information types were converted:" 5106 encoded-info 5108 ipn-content-return = "The Original Message is not available" 5109 / "The Original Message follows:" 5111 preferred-recipient = mailbox 5112 receipt-time = date-time 5113 auto-comment = printablestring 5114 ipn-suppl = printablestring 5116 RFC 1327bis 5117 MIXER DRAFT Version 2.2 5119 discard-reason = "Expired" / "Obsoleted" / 5120 "User Subscription Terminated" 5122 acknowledgement-mode = "Manually" / "Automatically" 5124 The mappings for elements of the common fields of IPMS.IPN 5125 (IPMS.CommonFields) onto this structure and the message header 5126 are: 5128 subject-ipm 5129 Mapped to "References:" 5131 ipn-originator 5132 Mapped to "From:". 5134 ipn-preferred-recipient 5135 Mapped to EBNF.preferred-recipient 5137 conversion-eits 5138 Mapped to EBNF.encoded-info in EBNF.ipn-extra-information 5140 The mappings for elements of IPMS.IPN.non-receipt-fields 5141 (IPMS.NonReceiptFields) are: 5143 non-receipt-reason 5144 Used to select between EBNF.ipn-discarded and 5145 EBNF.ipn-auto-forwarded 5147 discard-reason 5148 Mapped to EBNF.discard-reason 5150 auto-forward-comment 5151 Mapped to EBNF.auto-comment 5153 returned-ipm 5154 This applies only to non-receipt notifications. 5155 EBNF.ipn-content-return should always be omitted for receipt 5156 notifications, and always be present in non-receipt 5157 notifications. If present, the second option of 5158 EBNF.ipn-content-return is chosen, and the message is 5159 included. In this case, the message is formatted as 5160 multipart/mixed, and the returned message included as 5161 message/rfc822 after the text body part. Otherwise the first 5163 RFC 1327bis 5164 MIXER DRAFT Version 2.2 5166 option is chosen. 5168 The mappings for elements of IPMS.IPN.receipt-fields 5169 (IPMS.ReceiptFields) are: 5171 receipt-time 5172 Mapped to EBNF.receipt-time 5174 acknowledgement-mode 5175 Mapped to EBNF.acknowledgement-mode 5177 suppl-receipt-info 5178 Mapped to EBNF.ipn-suppl 5180 An example notification is: 5182 From: Steve Kille 5183 To: Julian Onions 5184 Subject: X.400 Inter-personal Notification 5185 Message-Type: InterPersonal Notification 5186 References: <1229.614418325@UK.AC.NOTT.CS> 5187 Date: Wed, 21 Jun 89 08:45:25 +0100 5189 Your message to: Steve Kille 5190 was automatically forwarded. 5191 The following comment was made: 5192 Sent on to a random destination 5194 The following information types were converted: g3fax 5196 5.3.6. Mappings from the MTS Abstract Service 5198 This section describes the MTS mappings for User Messages (IPM 5199 and IPN). This mapping is defined by specifying the mapping of 5200 MTS.MessageDeliveryEnvelope. The following extensions to RFC 822 5201 are defined to support this mapping: 5203 RFC 1327bis 5204 MIXER DRAFT Version 2.2 5206 mts-field = "X400-MTS-Identifier" ":" mts-msg-id 5207 / "X400-Originator" ":" mailbox 5208 / "X400-Recipients" ":" 1#mailbox 5209 / "Original-Encoded-Information-Types" ":" 5210 encoded-info 5211 / "X400-Content-Type" ":" mts-content-type 5212 / "Content-Identifier" ":" printablestring 5213 / "Priority" ":" priority 5214 / "Originator-Return-Address" ":" 1#mailbox 5215 / "DL-Expansion-History" ":" mailbox ";" date-time ";" 5216 / "Conversion" ":" prohibition 5217 / "Conversion-With-Loss" ":" prohibition 5218 / "Requested-Delivery-Method" ":" 5219 1*( labelled-integer ) 5220 / "Delivery-Date" ":" date-time 5221 / "Discarded-X400-MTS-Extensions" ":" 5222 1#( object-identifier / labelled-integer ) 5224 prohibition = "Prohibited" / "Allowed" 5226 mts-msg-id = "[" global-id ";" *text "]" 5228 mts-content-type = "P2" / labelled-integer 5229 / object-identifier 5231 priority = "normal" / "non-urgent" / "urgent" 5233 The mappings for each element of MTS.MessageDeliveryEnvelope can 5234 now be considered. 5236 MTS.MessageDeliveryEnvelope.message-delivery-identifier 5237 Mapped to the extended RFC 822 field "X400-MTS-Identifier:". 5239 MTS.MessageDeliveryEnvelope.message-delivery-time 5240 Discarded, as this time will be represented in an 5241 appropriate trace element. 5243 The mappings for elements of 5244 MTS.MessageDeliveryEnvelope.other-fields 5245 (MTS.OtherMessageDeliveryFields) are: 5247 RFC 1327bis 5248 MIXER DRAFT Version 2.2 5250 content-type 5251 Mapped to the extended RFC 822 field "X400-Content-Type:". 5252 The string "P2" is retained for backwards compatibility with 5253 RFC 987. This shall not be generated, and either the 5254 EBNF.labelled-integer or EBNF.object-identifier encoding 5255 used. 5257 originator-name 5258 Mapped to the SMTP originator, and to the extended RFC 822 | 5259 field "X400-Originator:". This is described in 5260 Section 4.6.2. 5262 original-encoded-information-types 5263 Mapped to the extended RFC 822 field 5264 "Original-Encoded-Information-Types:". 5266 priority 5267 Mapped to the extended RFC 822 field "Priority:". 5269 delivery-flags 5270 If the conversion-prohibited bit is set, add an extended RFC 5271 822 field "Conversion:". 5273 this-recipient-name and other-recipient-names 5275 originally-intended-recipient-name 5276 The handling of these elements is described in 5277 Section 4.6.2. 5279 converted-encoded-information-types 5280 Discarded. This information will be mapped in the trace. | 5282 message-submission-time 5283 Mapped to Date:. 5285 content-identifier 5286 Mapped to the extended RFC 822 field 5287 "X400-Content-Identifier:". In RFC 1327, this was 5288 "Content-Identifier:". This has been changed to avoid 5289 confusion with MIME defined fields. Gateways which reverse 5290 map, may support the old field. 5292 If any extensions 5293 (MTS.MessageDeliveryEnvelope.other-fields.extensions) are 5295 RFC 1327bis 5296 MIXER DRAFT Version 2.2 5298 present, and they are marked as critical for transfer or 5299 delivery, then the message shall be rejected. The extensions 5300 (MTS.MessageDeliveryEnvelope.other-fields.extensions) are mapped 5301 as follows. 5303 conversion-with-loss-prohibited 5304 If set to 5305 MTS.ConversionWithLossProhibited.conversion-with-loss-prohibited, 5306 then add the extended RFC 822 field "Conversion-With-Loss:". 5308 requested-delivery-method 5309 Mapped to the extended RFC 822 field 5310 "Requested-Delivery-Method:". 5312 originator-return-address 5313 Mapped to the extended RFC 822 field 5314 "Originator-Return-Address:". 5316 physical-forwarding-address-request 5317 physical-delivery-modes 5318 registered-mail-type 5319 recipient-number-for-advice 5320 physical-rendition-attributes 5321 physical-delivery-report-request 5322 physical-forwarding-prohibited 5324 These elements are only appropriate for physical delivery. 5325 They are represented as comments in the "X400-Recipients:" 5326 field, as described in Section 4.6.2.2. 5328 originator-certificate 5329 message-token 5330 content-confidentiality-algorithm-identifier 5331 content-integrity-check 5332 message-origin-authentication-check 5333 message-security-label 5334 proof-of-delivery-request 5336 These elements imply use of security services not available 5337 in the RFC 822 environment. If they are marked as critical 5338 for transfer or delivery, then the message shall be 5339 rejected. Otherwise they are discarded. 5341 RFC 1327bis 5342 MIXER DRAFT Version 2.2 5344 redirection-history 5345 This is described in Section 4.6.2. 5347 dl-expansion-history 5348 Each element is mapped to the extended RFC 822 field 5349 "DL-Expansion-History:". They shall be ordered in the 5350 message header, so that the most recent expansion comes 5351 first (same order as trace). 5353 If any MTS (or MTA) Extensions not specified in X.400 are 5354 present, and they are marked as critical for transfer or 5355 delivery, then the message shall be rejected. If they are not so 5356 marked, they can safely be discarded. The list of discarded 5357 fields shall be indicated in the extended header 5358 "Discarded-X400-MTS-Extensions:". 5360 5.3.7. Mappings from the MTA Abstract Service 5362 There are some mappings at the MTA Abstract Service level which 5363 are done for IPM and IPN. These can be derived from 5364 MTA.MessageTransferEnvelope. The reasons for the mappings at 5365 this level, and the violation of layering are: 5367 - Allowing for multiple recipients to share a single RFC 822 5368 message 5370 - Making the X.400 trace information available on the RFC 822 5371 side 5373 - Making any information on deferred delivery available 5375 The SMTP recipients are calculated from the full list of X.400 | 5376 recipients. This is all of the members of 5377 MTA.MessageTransferEnvelope.per-recipient-fields being passed 5378 through the gateway, where the responsibility bit is set. In 5379 some cases, a different RFC 822 message would be calculated for 5380 each recipient, due to differing service requests for each 5381 recipient. As discussed in 4.6.2.2, this specification allows 5382 either for multiple messages to be generated, or for the per- 5383 recipient information to be discarded. 5385 The following EBNF is defined for extended RFC 822 headers: 5387 RFC 1327bis 5388 MIXER DRAFT Version 2.2 5390 mta-field = "X400-Received" ":" x400-trace 5391 / "Deferred-Delivery" ":" date-time 5392 / "Latest-Delivery-Time" ":" date-time 5394 x400-trace = "by" md-and-mta ";" 5395 [ "deferred until" date-time ";" ] 5396 [ "converted" "(" encoded-info ")" ";" ] 5397 [ "attempted" md-or-mta ";" ] 5398 action-list 5399 ";" arrival-time 5401 md-and-mta = [ "mta" mta "in" ] global-id 5402 mta = word 5403 arrival-time = date-time 5405 md-or-mta = "MD" global-id 5406 / "MTA" mta 5408 Action-list = 1#action 5409 action = "Redirected" 5410 / "Expanded" 5411 / "Relayed" 5412 / "Rerouted" 5414 Note the EBNF.mta is encoded as 822.word. If the character | 5415 set does not allow encoding as 822.atom, the 822.quoted-string 5416 encoding is used. 5418 If MTA.PerMessageTransferFields.deferred-delivery-time is 5419 present, it is used to generate a Deferred-Delivery: field. For 5420 some reason, X.400 does not make this information available at 5421 the MTS level on delivery. X.400 profiles, and in particular the 5422 CEN/CENELEC profile for X.400(1984) [32], specify that this 5423 element must be supported at the first MTA. If it is not, the 5424 function may optionally be implemented by the gateway: that is, 5425 the gateway may hold the message until the time specified in the 5427 RFC 1327bis 5428 MIXER DRAFT Version 2.2 5430 protocol element. Thus, the value of this element will usually 5431 be in the past. For this reason, the extended RFC 822 field is 5432 primarily for information. 5434 Merge MTA.PerMessageTransferFields.trace-information, and 5435 MTA.PerMessageTransferFields.internal-trace-information to 5436 produce a single ordered trace list. If Internal trace from 5437 other management domains has not been stripped, this may require 5438 complex interleaving. Where an element of internal trace and 5439 external trace are identical, except for the MTA in the internal 5440 trace, only the internal trace element shall be presented. Use 5441 this to generate a sequence of "X400-Received:" fields. The only 5442 difference between external trace and internal trace will be the 5443 extra MTA information in internal trace elements. 5445 When generating an RFC 822 message all trace fields (X400- 5446 Received and Received) shall be at the beginning of the header, 5447 before any other fields. Trace shall be in chronological order, 5448 with the most recent element at the front of the message. This 5449 ordering is determined from the order of the fields, not from 5450 timestamps in the trace, as there is no guarantee of clock 5451 synchronisation. A simple example trace (external) is: 5453 X400-Received: by /PRMD=UK.AC/ADMD=Gold 400/C=GB/ ; Relayed ; 5454 Tue, 20 Jun 89 19:25:11 +0100 5456 A more complex example (internal): 5458 X400-Received: by mta "UK.AC.UCL.CS" in /PRMD=UK.AC/ADMD=Gold 400/C=GB/ ; 5459 deferred until Tue, 20 Jun 89 14:24:22 +0100 ; 5460 converted (undefined, g3fax) ; attempted /ADMD=Foo/C=GB/ ; 5461 Relayed, Expanded, Redirected ; Tue, 20 Jun 89 19:25:11 +0100 5463 The gateway itself shall not add trace information. 5464 However, for trace purposes, the gateway shall be considered as 5465 an X.400 and Internet MTA back to back, and both of these shall 5466 add trace elements. 5468 5.3.8. Mappings from Report Delivery 5470 Delivery reports are mapped at the MTS service level. This means 5471 that only reports destined for the MTS user will be mapped. Some 5472 additional services are also taken from the MTA service. X.400 5474 RFC 1327bis 5475 MIXER DRAFT Version 2.2 5477 Delivery Reports are Mapped onto Delivery Status Notifications, 5478 as defined by NOTARY [29]. 5480 5.3.8.1. MTS Mappings 5482 A Delivery Report service will be represented as 5483 MTS.ReportDeliveryEnvelope, which comprises of per-report-fields 5484 (MTS.PerReportDeliveryFields) and per-recipient-fields. 5486 A message of type delivery-status is generated with the following 5487 fields: 5489 From: 5490 An administrator at the gateway system. This is also the | 5491 SMTP originator. 5493 To: A mapping of the 5494 MTA.ReportTransferEnvelope.report-destination-name. This is | 5495 also the SMTP recipient. 5497 Message-Type: 5498 Set to "Delivery Report". This is strictly redundant, but 5499 retained for backwards compatibility with RFC 1327. 5501 Subject: 5502 The EBNF for the subject line is: 5504 subject-line = "Delivery-Report" "(" status ")" 5505 [ "for" destination ] 5507 status = "success" / "failure" / "success and failures" 5509 destination = mailbox / "MTA" word 5511 The subject is intended to give a clear indication as to the 5512 nature of the message, and summarise its contents. EBNF.status is 5513 set according to whether the reports are all successes, all 5514 failures, or a mixture. The EBNF.destination is used to indicate 5515 the addresses in the reports. If the report is for a single 5516 address, EBNF.mailbox is used to give the RFC 822 representation 5517 of the address. If all of the reports share a common MTA this is 5518 included in EBNF.word. A common MTA is determined from the 5520 RFC 1327bis 5521 MIXER DRAFT Version 2.2 5523 delivery report's trace. 5525 The format of the body of the message follows the NOTARY 5526 delivery status notification format, and is defined to ensure 5527 that all information is conveyed to the RFC 822 user in a 5528 consistent manner. The format is structured as if it was a 5529 message coming from the gateway, with three body parts. The first 5530 body part is ASCII text structured as follows: 5532 1. A few lines giving keywords to indicate the original 5533 message. 5535 2. A human summary of the status of each recipient being 5536 reported on. 5538 The second body part is the NOTARY delivery status 5539 notification, which contains detailed information extracted from 5540 the report. This information may be critical to diagnosing an 5541 obscure problem. 5543 This body part may be omitted in positive DRs. For RFC 5544 1327, this was recommended as appropriate for most gateways. As 5545 NOTARY becomes more widely adopted, this will make less sense. 5546 It is likely that this body part will be mandatory in future 5547 versions of this specification. 5549 The third (optional) body part contains the returned message 5550 (return of content). This structure is useful to the RFC 822 5551 recipient, as it enables the original message to be extracted. 5552 It shall be included if the original message is available. 5554 The enclosing message is a MIME message of content type 5555 multipart/report, with report-type=delivery-status. The first 5556 body part containing the user oriented description is of type 5557 text/plain. The format of this body part is defined below as 5558 EBNF.dr-user-info. 5560 RFC 1327bis 5561 MIXER DRAFT Version 2.2 5563 dr-user-info = dr-summary 5564 dr-recipients 5565 dr-content-return 5567 dr-content-return = "The Original Message is not available" 5568 / "The Original Message follows:" 5570 dr-summary = "This report relates to your message:" 5571 content-correlator 5572 "of" date-time 5574 dr-recipients = *(dr-recipient ) 5576 dr-recipient = dr-recip-success / dr-recip-failure 5578 dr-recip-success = 5579 "Your message was successfully delivered to:" 5580 mailbox "at" date-time 5582 dr-recip-failure = "Your message was not delivered to:" 5583 mailbox 5584 "for the following reason:" *word 5586 report-point = [ "mta" word "in" ] global-id 5587 content-correlator = *word 5589 EBNF.dr-summary 5590 The EBNF.content-correlator is taken from the content 5591 correlator (or content identifier if there is no content 5592 correlator) and the EBNF.date-time from the trace, as 5593 described below. LWSP may be added to improve the layout of 5594 the body part. 5596 EBNF.dr-recipients 5597 There is an element for each recipient in the delivery 5598 report. In each case, EBNF.mailbox is taken from the RFC 5599 822 form of the originally specified recipient, which is 5600 taken from the originally specified recipient element if 5601 present or from the actual recipient. When reporting 5603 RFC 1327bis 5604 MIXER DRAFT Version 2.2 5606 success, the message delivery time is used to derive 5607 EBNF.date-time. When reporting failure, the information 5608 includes a human readable interpretation of the X.400 5609 diagnostic and reason codes, and the supplementary 5610 information. 5612 EBNF.dr-content-return 5613 This is set according to whether or not the content is being 5614 returned. 5616 The EBNF of this body part is designed for english-speaking 5617 users. The language of the strings in the EBNF may be altered. 5619 The EBNF used in the delivery status notification is: 5621 dr-per-message-fields = 5622 / "X400-Conversion-Date" ":" date-time 5623 / "X400-Subject-Submision-Identifier" ":" 5624 mts-msg-id 5625 / "X400-Content-Identifier" ":" printablestring 5626 / "X400-Content-Type" ":" mts-content-type 5627 / "X400-Original-Encoded-Information-Types" ":" 5628 encoded-info 5629 / "X400-Originator-and-DL-Expansion-History" ":" 5630 dl-history 5631 / "X400-Reporting-DL-Name" ":" mailbox 5632 / "X400-Content-Correlator" ":" content-correlator 5633 / "X400-Recipient-Info" ":" recipient-info 5634 / "X400-Subject-Intermediate-Trace-Information" ":" 5635 x400-trace 5636 / dr-extensions 5638 RFC 1327bis 5639 MIXER DRAFT Version 2.2 5641 dr-per-recipient-fields = 5642 / "X400-Redirect-Recipient" ":" "x400" ";" std-or 5643 / "X400-Mapped-Redirect-Recipient" ":" "rfc822" ";" mailbox 5644 / "X400-Converted-EITs" ":" encoded-info ";" 5645 / "X400-Delivery-Time" ":" date-time 5646 / "X400-Type-of-MTS-User" ":" labelled-integer 5647 / "X400-Last-Trace" ":" [ encoded-info ] date-time 5648 / "X400-Supplementary-Info" ":" 5649 <"> printablestring <"> ";" 5650 / "X400-Redirection-History" ":" redirection-comment 5651 / "X400-Physical-Forwarding-Address" ":" printablestring 5652 / "X400-Originally-Specified-Recipient-Number" ":" 5653 integer 5654 / dr-extensions 5656 dr-extensions = "X400-Discarded-DR-Extensions" ":" 5657 1# (object-identifier / labelled-integer) 5659 dl-history = 1#( mailbox "(" date-time ")") 5661 / "X400-Diagnostic" ":" labelled-integer 5662 / "X400-Reason" ":" labelled-integer 5664 dr-diagnostic = "Reason" labelled-integer 5665 [ ";" "Diagnostic" labelled-integer ] 5667 A body part of type delivery status, as defined by NOTARY, is 5668 generated. MIXER extends this delivery status notification (DSN) 5669 specification, by defining additional per message fields in 5670 EBNF.dr-per-message-fields and additional per recipient fields in 5671 EBNF.dr-per-recipient-fields. These are used as extensions to 5672 DSN.per-message-fields and DSN.per-recipient-fields. 5674 The following DSN.per-message-fields are always generated: 5676 DSN.reporting-mta-field 5677 The DSN.mta-name-type is set to "x400", and this string is 5678 reserved by MIXER. The DSN.mta-name has its syntax 5679 specified by EBNF.report-point, with the information derived 5680 from the first element of the DR's trace. 5682 RFC 1327bis 5683 MIXER DRAFT Version 2.2 5685 DSN.arrival-date-field 5686 This is derived from the date of the first element of trace 5687 in the DR. 5689 The following two EBNF.per-message-fields are generated by 5690 the MIXER gateway: 5692 DSN.dsn-gateway-field 5693 The type is set to "dns" and the domain set to the local 5694 domain of the gateway. 5696 X400-Conversion-Date: 5697 The EBNF.date-time is set to the time of the MIXER 5698 conversion. 5700 The elements of MTS.ReportDeliveryEnvelope.per-report-fields 5701 are mapped as follows onto the DSN per message fields as follows: 5703 subject-submission-identifier 5704 Mapped to DSN.original-envelope-id-field. The encoding of 5705 this MTS Identifier follows the format EBNF.mts-msg-id. 5707 content-identifier 5708 Mapped to X400-Content-Identifier: 5710 content-type 5711 Mapped to X400-Content-Type: 5713 original-encoded-information-types 5714 Mapped to X400-Encoded-Info: 5716 The extensions from 5717 MTS.ReportDeliveryEnvelope.per-report-fields.extensions are 5718 mapped as follows: 5720 originator-and-DL-expansion-history 5721 Mapped to X400-Originator-and-DL-Expansion-History: 5723 reporting-DL-name 5724 Mapped to X400-Reporting-DL-Name: 5726 content-correlator 5727 Mapped to X400-Content-Correlator:, provided that the 5728 encoding is IA5String (this will always be the case). 5730 RFC 1327bis 5731 MIXER DRAFT Version 2.2 5733 message-security-label 5734 reporting-MTA-certificate 5735 report-origin-authentication-check 5737 These security parameters will not be present unless there 5738 is an error in a remote MTA. If they are present, they 5739 shall be discarded in preference to discarding the whole 5740 report. They shall be listed in the X400-Discarded-DR- 5741 Extensions: field. 5743 If there are any other DR extensions, they shall also be 5744 discarded and listed in the X400-Discarded-DR-Extensions: field. 5746 For each element of 5747 MTS.ReportDeliveryEnvelope.per-recipient-fields, a set of 5748 DSN.per-recipient-fields is generated. The fields are filled in 5749 as follows: 5751 actual-recipient-name 5752 If originally-intended-recipient-name is not present, | 5753 generate a DSN.final-recipient-field fields, with | 5754 DSN.address-type of "rfc822", and with an RFC 822 mailbox 5755 generated from the address encoded as specified by NOTARY. 5756 Also generate a DSN.original-recipient-field field, which 5757 holds the X.400 representation of the same address. If the 5758 directory name is present, it should be added as a trailing 5759 comment in the X.400 form. 5761 If originally-intended-recipient-name is present, generate | 5762 an "X400-Mapped-Redirect-Recipient:" field, with | 5763 DSN.address-type of "rfc822", and with an RFC 822 mailbox 5764 generated from the address encoded as specified by NOTARY. 5765 Also generate an X400-Redirect-Recipient:" field, which 5766 holds the X.400 representation of the same address. If the 5767 directory name is present, it should be added as a trailing 5768 comment in the X.400 form. 5770 report 5771 If it is MTS.Report.delivery, then set DSN.action-field to 5772 "delivered", and set "X400-Delivery-Time:" and 5773 "X400-Type-of-MTS-User:" from the information in the report. 5774 DSN.status field is set to "2.0.0". 5776 If it is MTS.Report.non-delivery, then set DSN.action-field 5778 RFC 1327bis 5779 MIXER DRAFT Version 2.2 5781 to "failure". DSN.diagnostic-code-field is encoded 5782 according to the syntax EBNF.dr-diagnostic, with the 5783 labelled integers set from the reason and diagnotic codes. 5784 DSN.status-field is derived from the reason and diagnostic 5785 codes, as described below. 5787 converted-encoded-information-types 5788 Set X400-Converted-EITs: 5790 originally-intended-recipient 5791 Generate a DSN.final-recipient-field field, with | 5792 DSN.address-type of "rfc822", and with an RFC 822 mailbox 5793 generated from the address encoded as specified by NOTARY. 5794 Also generate a DSN.original-recipient-field field, which 5795 holds the X.400 representation of the same address. If the 5796 directory name is present, it should be added as a trailing 5797 comment in the X.400 form. 5799 supplementary-info 5800 Set X400-Supplementary-Info: 5802 redirection-history 5803 Set X400-Redirection-History: 5805 physical-forwarding-address 5806 Set X400-Physical-Forwarding-Address: 5808 recipient-certificate 5809 Discard 5811 proof-of-delivery 5812 Discard 5814 Any unknown extensions shall be discarded, irrespective of 5815 criticality. All discarded extensions shall be included in a 5816 "X400-Discarded-DR-Extensions:" field. 5818 The number from the 5819 MTA.PerRecipientReportTransferFields.originally-specified-recipient-number 5820 shall be mapped to "X400-Originally-Specified-Recipient-Number:", 5821 in order to facilitate reverse mapping of delivery reports. 5823 The original message shall be included in the delivery 5824 status notification if it is available. The original message will 5826 RFC 1327bis 5827 MIXER DRAFT Version 2.2 5829 usually be available at the gateway, as discussed in Section 5.2. 5830 If the original message is available, but is not a legal message | 5831 format, a dump of the ASN.1 may be included, encoded as 5832 application/octet-string. This is recommended, but not required. 5834 Where the original message is included, it shall be encoded 5835 according to the MIME specifications as content type 5836 message/rfc822. 5838 5.3.8.2. Status Code Mappings 5840 This section defines the mappings from X.400 diagnostic and 5841 status codes to the NOTARY Status field. 5843 C/D X400 meaning DSN code Means 5845 0/Any Transfer failure (may be temporary) 4.4.0 Other net/route 5846 1/Any Unable to transfer 5.0.0 Other, unknown 5847 2/Any Conversion not performed 5.6.3 Conv not supported 5848 3/Any Physical rendition not performed 5.6.0 Other media error 5849 4/Any Physical delivery not performed 5.1.0 Other address status 5850 5/Any Restricted delivery 5.7.1 5851 6/Any Directory operation unsuccessful 5.4.3 Routing server failure 5852 7/Any Deferred delivery not performed 5.3.3 Not capable 5854 RFC 1327bis 5855 MIXER DRAFT Version 2.2 5857 1/0 Unrecognized O/R name 5.1.1 5858 1/1 Ambiguous O/R name 5.1.4 5859 1/2 MTS congestion 4.3.1 5860 1/3 Loop detected 5.4.6 5861 1/4 Recipient unavailable 4.2.1 5862 1/5 Delivery time expired 4.4.7 5863 1/6 Encoded information types unsupported 5.6.1 Media unsupp. 5864 1/7 Content too long 5.2.3 5865 2/8 Conversion impractical 5.6.3 5866 2/9 Conversion prohibited 5.6.3 5867 1/10 Implicit conversion not subscribed 5.6.3 5868 1/11 Invalid arguments 5.5.2 5869 1/12 Content syntax error 5.5.2 5870 1/13 Size constraint violation 5.5.2 5871 1/14 Protocol violation 5.5.0 5872 1/15 Content type not supported 5.6.1 Media unsupp. 5873 1/16 Too many recipients 5.5.3 5874 1/17 No bilateral agreement 5.4.4 5875 1/18 Unsupported critical function 5.3.3 System not capable 5876 2/19 Conversion with loss prohibited 5.6.2 5877 2/20 Line too long 5.6.0 5878 2/21 Page split 5.6.0 5879 2/22 Pictorial symbol loss 5.6.2 5880 2/23 Punctuation symbol loss 5.6.2 5881 2/24 Alphabetic character loss 5.6.2 5882 2/25 Multiple information loss 5.6.2 5883 1/26 Recipient reassignment prohibited 5.4.0 Undefined net/route 5884 1/27 Redirection loop detected 5.4.6 5885 1/28 DL expansion prohibited 5.7.2 5886 1/29 No DL submit permission 5.7.1 Delivery not authorized 5887 1/30 DL expansion failure 4.2.4 5888 4/31 Physical rendition attrs not supported 5.6.0 Undefined media error 5889 4/32-45 Various physical mail stuff 5.1.0 Other address status 5890 1/46 Secure messaging error 5.7.0 Other security status 5891 2/47 Unable to downgrade 5.3.3 System not capable 5892 0/48 Unable to complete transfer 5.3.4 Message too big 5893 0/49 Transfer attempts limit reached 4.4.7 Delivery time expired 5895 5.3.8.3. MTA Mappings 5897 The single SMTP recipient is constructed from | 5899 RFC 1327bis 5900 MIXER DRAFT Version 2.2 5902 MTA.ReportTransferEnvelope.report-destination-name, using the 5903 mappings of Chapter 4. Unlike with a user message, this 5904 information is not available at the MTS level. 5906 The following additional mappings are made, which results in 5907 fields in the outer header of the DSN. 5909 MTA.ReportTransferEnvelope.report-destination-name 5910 This is used to generate the To: field. 5912 MTA.ReportTransferEnvelope.identifier 5913 Mapped to the extended RFC 822 field "X400-MTS-Identifier:". 5914 It may also be used to derive a "Message-Id:" field. 5916 MTA.ReportTransferEnvelope.trace-information 5917 and 5919 MTA.ReportTransferEnvelope.internal-trace-information 5920 Mapped onto the extended RFC 822 field "X400-Received:", as 5921 described in Section 5.3.7. 5923 The following additional mappings are made, which result in per 5924 message fields in the DSN body part: 5926 MTA.PerRecipientReportTransferFields.last-trace-information 5927 Mapped to X400-Last-Trace:". 5929 MTA.PerReportTransferFields.subject-intermediate-trace- 5930 information Mapped to 5931 X400-Subject-Intermediate-Trace-Information:". These fields 5932 are ordered so that the most recent trace element comes 5933 first. 5935 5.3.8.4. Example Delivery Reports 5937 This section contains sample delivery reports. These are the 5938 same examples used in RFC 1327, and so they also illustrate the 5939 changes between RFC 1327 and this document. Example Delivery 5940 Report 1: 5942 RFC 1327bis 5943 MIXER DRAFT Version 2.2 5945 Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk 5946 via Delivery Reports Channel id <27699-0@bells.cs.ucl.ac.uk>; 5947 Thu, 7 Feb 1991 15:48:39 +0000 5948 From: UCL-CS MTA 5949 To: S.Kille@cs.ucl.ac.uk 5950 Subject: Delivery Report (failure) for H.Hildegard@bbn.com 5951 Message-Type: Delivery Report 5952 Date: Thu, 7 Feb 1991 15:48:39 +0000 5953 Message-ID: <"bells.cs.u.694:07.01.91.15.48.34"@cs.ucl.ac.uk> 5954 X400-Content-Identifier: Greetings. 5955 MIME-Version: 1.0 5956 Content-Type: multipart/report; report-type=delivery-status; 5957 boundary=boundary-1 5959 --boundary-1 5961 This report relates to your message: Greetings. 5963 of Thu, 7 Feb 1991 15:48:20 +0000 | 5965 Your message was not delivered to 5966 H.Hildegard@bbn.com for the following reason: 5967 Bad Address 5968 MTA 'bbn.com' gives error message (USER) Unknown user name in 5969 "H.Hildegard@bbn.com" 5971 The Original Message follows: 5973 --boundary-1 5974 content-type: message/delivery-status 5976 RFC 1327bis 5977 MIXER DRAFT Version 2.2 5979 Reporting-MTA: x400; bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/ 5980 Arrival-Date: Thu, 7 Feb 1991 15:48:34 +0000 5981 DSN-Gateway: dns; bells.cs.ucl.ac.uk 5982 X400-Conversion-Date: Thu, 7 Feb 1991 15:48:40 +0000 5983 Original-Envelope-Id: 5984 [/PRMD=uk.ac/ADMD=gold 400/C=gb/;<1803.665941698@UK.AC.UCL.CS>] 5985 X400-Content-Identifier: Greetings. 5986 X400-Subject-Intermediate-Trace-Information: /PRMD=uk.ac/ADMD=gold 400/C=gb/; 5987 arrival Thu, 7 Feb 1991 15:48:20 +0000 action Relayed 5988 X400-Subject-Intermediate-Trace-Information: /PRMD=uk.ac/ADMD=gold 400/C=gb/; 5989 arrival Thu, 7 Feb 1991 15:48:18 +0000 action Relayed 5991 Original-Recipient: rfc822; H.Hildegard@bbn.com 5992 Final-Recipient: x400; 5993 /RFC-822=H.Hildegard(a)bbn.com/OU=cs/O=ucl/PRMD=uk.ac/ADMD=gold 400/C=gb/; 5994 Action: failure 5995 Status: 5.1.1 5996 Diagnostic Code: x400; Reason Unable-To-Transfer (1); 5997 Diagnostic Unrecognised-ORName (0) 5998 X400-Last-Trace: (ia5) Thu, 7 Feb 1991 15:48:18 +0000; 5999 X400-Originally-Specified-Recipient-Number: 1 6000 X400-Supplementary-Info: "MTA 'bbn.com' gives error message (USER) 6001 Unknown user name in "H.Hildegard@bbn.com""; 6003 RFC 1327bis 6004 MIXER DRAFT Version 2.2 6006 --boundary-1 6007 Content-Type: message/rfc822 6009 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk 6010 with SMTP inbound id <27689-0@bells.cs.ucl.ac.uk>; 6011 Thu, 7 Feb 1991 15:48:21 +0000 6012 To: H.Hildegard@bbn.com 6013 Subject: Greetings. 6014 Phone: +44-71-380-7294 6015 Date: Thu, 07 Feb 91 15:48:18 +0000 6016 Message-ID: <1803.665941698@UK.AC.UCL.CS> 6017 From: Steve Kille 6019 Steve 6021 --boundary-1-- | 6023 RFC 1327bis 6024 MIXER DRAFT Version 2.2 6026 Example Delivery Report 2: 6028 Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk 6029 via Delivery Reports Channel id <27718-0@bells.cs.ucl.ac.uk>; 6030 Thu, 7 Feb 1991 15:49:11 +0000 6031 X400-Received: by mta bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; 6032 Relayed; Thu, 7 Feb 1991 15:49:08 +0000 6033 X400-Received: by /PRMD=DGC/ADMD=GOLD 400/C=GB/; Relayed; 6034 Thu, 7 Feb 1991 15:48:40 +0000 6035 From: UCL-CS MTA 6036 To: S.Kille@cs.ucl.ac.uk 6037 Subject: Delivery Report (failure) for 6038 j.nosuchuser@dle.cambridge.DGC.gold-400.gb 6039 Message-Type: Delivery Report 6040 Date: Thu, 7 Feb 1991 15:46:11 +0000 6041 Message-ID: <"DLE/910207154840Z/000"@cs.ucl.ac.uk> 6042 X400-Content-Identifier: A useful mess... 6043 MIME-Version: 1.0 6044 Content-Type: multipart/report; report-type=delivery-status; 6045 boundary=boundary-1 6047 --boundary-1 6049 This report relates to your message: A useful mess... 6051 of Thu, 7 Feb 1991 15:43:20 +0000 | 6053 Your message was not delivered to 6054 j.nosuchuser@dle.cambridge.DGC.gold-400.gb 6055 for the following reason: 6056 Bad Address 6057 DG 21187: (CEO POA) Unknown addressee. 6059 The Original Message is not available 6061 RFC 1327bis 6062 MIXER DRAFT Version 2.2 6064 --boundary-1 6065 content-type: message/delivery-status 6067 Reporting-MTA: x400; /PRMD=DGC/ADMD=GOLD 400/C=GB/ 6068 Arrival-Date: Thu, 7 Feb 1991 15:48:40 +0000 6069 DSN-Gateway: dns; bells.cs.ucl.ac.uk 6070 X400-Conversion-Date: Thu, 7 Feb 1991 15:49:12 +0000 6071 Original-Envelope-Id: 6072 [/PRMD=uk.ac/ADMD=gold 400/C=gb/;<1796.665941626@UK.AC.UCL.CS>] 6073 X400-Content-Identifier: A useful mess... 6075 Original-Recipient: rfc822; j.nosuchuser@dle.cambridge.DGC.gold-400.gb 6076 Final-Recipient: x400; 6077 /I=j/S=nosuchuser/OU=dle/O=cambridge/PRMD=DGC/ADMD=GOLD 400/C=GB/ 6078 Action: failure 6079 Status: 5.1.1 6080 Diagnostic Code: x400; Reason Unable-To-Transfer (1); 6081 Diagnostic Unrecognised-ORName (0) 6082 X400-Supplementary-Info: "DG 21187: (CEO POA) Unknown addressee." 6083 X400-Originally-Specified-Recipient-Number: 1 6085 --boundary-1-- | 6087 5.3.9. Probe 6089 This is an MTS internal issue. Any probe shall be serviced by 6090 the gateway, as there is no equivalent RFC 822 functionality. 6091 The value of the reply is dependent on whether the gateway could 6092 service an MTS Message with the values specified in the probe. 6093 The reply shall make use of MTS.SupplementaryInformation to 6094 indicate that the probe was serviced by the gateway. 6096 RFC 1327bis 6097 MIXER DRAFT Version 2.2 6099 Appendix A - Mappings Specific to SMTP 6101 This Appendix is specific to the Simple Mail Transfer Protocol 6102 (RFC 821). It describes specific changes in the context of this | 6103 protocol. When MIXER is used with SMTP, conformance to this | 6104 appendix is mandatory. 6106 6. Probes 6108 When servicing a probe, as described in section 5.3.9, use may be 6109 made of the SMTP VRFY command to increase the accuracy of 6110 information contained in the delivery report. 6112 7. Long Lines 6114 SMTP is a text oriented protocol, and is required to support a 6115 line length of at least 1000 characters. Some implementations 6116 do not support line lengths greater than 1000 characters. This 6117 can cause problems. Where body parts have long lines, it is 6118 recommended to use a MIME encoding that folds lines (quoted 6119 printable). 6121 8. SMTP Extensions 6123 There are several RFCs that specify extensions to SMTP. Most of 6124 these are not relevant to MIXER. The NOTARY work to support 6125 delivery report defines extensions which are relevant [30]. Use 6126 of these extensions by a MIXER gateway is optional. If these 6127 extensions are used, they shall be used in the manner described 6128 below. | 6130 Editor's Note: | 6131 It has been proposed to make these extensions mandatory. | 6132 Input is solicited. 6134 8.1. SMTP Extension mapping to X.400 6136 Mappings are defined for the following extensions: 6138 NOTIFY | 6139 This is used to set the report and non-delivery bits of 6140 MTS.MTS.PerRecipientMessageSubmissionFields.originator-report-request. 6141 If the value is NEVER, both bits are zero. If SUCCESS is 6142 present, the report bit is set. Otherwise, the non- 6144 RFC 1327bis 6145 MIXER DRAFT Version 2.2 6147 delivery-report bit is set. If the gateway uses the NOTIFY 6148 command, it shall perform this mapping in all cases. 6150 ORCPT | 6151 This may be used at the MTS level, to generate an element of 6152 redirection history, with the redirection date being the 6153 date of conversion. 6155 8.2. X.400 Mapping to SMTP Extensions 6157 The following extensions may be used as a part of the MIXER 6158 mapping: 6160 NOTIFY | 6161 The report and non-delivery bits of 6162 MTS.MTS.PerRecipientMessageSubmissionFields.originator-report-request 6163 determine how this is used. If both bits are zero, the 6164 parameter is NEVER. If the report bit is set, SUCCESS is 6165 used. Otherwise, FAILURE is used. If this is done, the 6166 gateway shall not generate a delivery report for this 6167 recipient. 6169 ORCPT | 6170 If the 6171 MTS.perRecipientReportDeliveryFields.originally-intended-recipient-name 6172 is present, the ORCPT command may be used to carry this 6173 value. 6175 ENVID | 6176 This may be generated, with the value taken from the 6177 MTS.MessgeDeliveryEnvelope.message-delivery-identifer, 6178 encoded as EBNF.mts-msg-id. 6180 RFC 1327bis 6181 MIXER DRAFT Version 2.2 6183 Appendix B - Mapping with X.400(1984) 6185 This appendix defines modifications to the mapping for use with | 6186 X.400(1984). 6188 The X.400(1984) protocols are a proper subset of 6189 X.400(1988). When mapping from X.400(1984) to RFC 822, no 6190 changes to this specification are needed. 6192 When mapping from RFC 822 to X.400(1984), no use can be made 6193 of 1988 specific features. No use of such features is made at 6194 the MTS level. One feature is used at the IPMS level, and this 6195 must be replaced by the RFC 987 approach. All header information 6196 which would usually be mapped into the rfc-822-heading-list | 6197 extension is mapped into a single IA5 body part, which is the | 6198 first body part in the message. This body part will start with 6199 the string "RFC-822-Headers:" as the first line. The headers 6200 then follow this line. This specification requires correct 6201 reverse mapping of this format, either from 1988 or 1984. RFC 6202 822 extended headers which could be mapped into X.400(1988) 6203 elements, are also mapped to the body part. 6205 In an environment where RFC 822 is of major importance, it 6206 may be desirable for downgrading to consider the case where the 6207 message was originated in an RFC 822 system, and mapped according 6208 to this specification. The rfc-822-heading-list extension may be 6209 mapped according to this appendix. 6211 When parsing std-or, the following restrictions must be 6212 observed: 6214 - Only the 84/88 attributes identified in the table in 6215 Section 4.2 are present. 6217 - No teletex encoding is allowed. 6219 If an address violates this, it should be treated as an RFC 822 6220 address, which will usually lead to encoding as a DDA "RFC-822". 6222 It is possible that null attributes may be present in an O/R 6223 Address. This is not legal in 1988, except for ADMD where the 6224 case is explicitly described in Section 4.3.5. Null attributes 6225 are deprecated (the attribute should be omitted), and should 6227 RFC 1327bis 6228 MIXER DRAFT Version 2.2 6230 therefore be unusual. However, some systems generate them and 6231 rely on them. Therefore, any null attribute shall be enoded 6232 using the std-or encoding (e.g., /O=/). 6234 If a non-Teletex Common Name (CN) is present, it should be 6235 mapped onto a Domain Defined Attribute "Common". This is in line 6236 with RFC 1328 on X.400 1988 to 1984 downgrading [23]. 6238 This specification defines a mapping of the Internet message 6239 framework to X.400. Body part mappings are defined in RFC | 6240 1494bis , which relies on X.400(88) features. Downgrading to [ 6241 X.400(84) for body parts is defined in RFC 1496 (HARPOON), which [ 6242 shall be followed in the context of this appendix [6]. [ 6244 RFC 1327bis 6245 MIXER DRAFT Version 2.2 6247 Appendix C - RFC 822 Extensions for X.400 access [ 6249 This appendix defines a number of optional mappings which may be [ 6250 provided to give access from RFC 822 to a number of X.400 [ 6251 services. These mappings are beyond the basic scope of this [ 6252 specification. There has been a definite demand to use extended [ 6253 RFC 822 as a mechanism to access X.400, and these extensions [ 6254 provide access to certain features. If this functionality is [ 6255 provided, this appendix shall be followed. The following [ 6256 headings are defined: [ 6258 extended-heading = 6259 "Prevent-NonDelivery-Report" ":" 6260 / "Generate-Delivery-Report" ":" 6261 / "Alternate-Recipient" ":" prohibition 6262 / "Disclose-Recipients" ":" prohibition 6263 / "Content-Return" ":" prohibition 6265 Prevent-NonDelivery-Report and Generate-Delivery-Report allow [ 6266 setting of [ 6267 MTS.PerRecipientSubmissionFields.originator-report-request. The [ 6268 setting will be the same for all recipients. [ 6270 Alternate-Recipient, Disclose-Recipients, and Content-Return [ 6271 allow for override of the default settings for [ 6272 MTS.PerMessageIndicators. [ 6274 RFC 1327bis 6275 MIXER DRAFT Version 2.2 6277 Appendix D - Object Identifier Assignment [ 6279 The following Object Identifiers shall be used. [ 6281 internet ::= OBJECT IDENTIFIER { iso org(3) dod(6) 1 } -- from RFC 1155| 6282 | 6283 mail OBJECT IDENTIFIER ::= { internet 7 } -- IANA assigned | 6285 mixer OBJECT IDENTIFIER ::= { mail mixer(1) } -- inherited from RFC 1495| 6286 mixer-headings OBJECT IDENTIFIER ::= { mixer headings(1) } | 6287 mixer-bodies OBJECT IDENTIFIER ::= { mixer bodies(2) } | 6288 | 6289 id-rfc-822-field-list OBJECT IDENTIFIER ::= {mixer-headings 3} | 6290 id-hex-multipart-message OBJECT IDENTIFIER ::= {mixer-headings 4} | 6291 id-hex-partial-message OBJECT IDENTIFIER ::= {mixer-headings 1} | 6292 id-dsn-header-list OBJECT IDENTIFIER ::= {mixer-headings 5} | 6293 id-dsn-field-list OBJECT IDENTIFIER ::= {mixer-headings 6} | 6294 id-mime-body-part OBJECT IDENTIFIER ::= {mixer-bodies 1} | 6295 id-mime-body-part-parameters OBJECT IDENTIFIER ::= {mixer-bodies 2}| 6297 This object identifier for id-rfc-822-field-list is different to [ 6298 the one assigned in RFC 1327, which was erroneous. * 6300 RFC 1327bis 6301 MIXER DRAFT Version 2.2 6303 Appendix E - BNF Summary 6305 boolean = "TRUE" / "FALSE" 6307 numericstring = *DIGIT 6309 printablestring = *( ps-char ) 6310 ps-restricted-char = 1DIGIT / 1ALPHA / " " / "'" / "+" 6311 / "," / "-" / "." / "/" / ":" / "=" / "?" 6312 ps-delim = "(" / ")" 6313 ps-char = ps-delim / ps-restricted-char 6315 ps-encoded = *( ps-restricted-char / ps-encoded-char ) 6316 ps-encoded-char = "(a)" ; (@) 6317 / "(p)" ; (%) 6318 / "(b)" ; (!) 6319 / "(q)" ; (") 6320 / "(u)" ; (_) 6321 / "(l)" ; "(" 6322 / "(r)" ; ")" 6323 / "(" 3DIGIT ")" 6325 teletex-string = *( ps-char / t61-encoded ) 6326 t61-encoded = "{" 1* t61-encoded-char "}" 6327 t61-encoded-char = 3DIGIT 6329 teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ] 6331 labelled-integer ::= [ key-string ] "(" numericstring ")" 6333 key-string = *key-char 6334 key-char = 6336 RFC 1327bis 6337 MIXER DRAFT Version 2.2 6339 object-identifier ::= oid-comp object-identifier 6340 | oid-comp 6342 oid-comp ::= [ key-string ] "(" numericstring ")" 6344 encoded-info = 1#encoded-type 6346 encoded-type = built-in-eit / object-identifier 6348 built-in-eit = "Undefined" ; undefined (0) 6349 / "Telex" ; tLX (1) 6350 / "IA5-Text" ; iA5Text (2) 6351 / "G3-Fax" ; g3Fax (3) 6352 / "TIF0" ; tIF0 (4) 6353 / "Teletex" ; tTX (5) 6354 / "Videotex" ; videotex (6) 6355 / "Voice" ; voice (7) 6356 / "SFD" ; sFD (8) 6357 / "TIF1" ; tIF1 (9) 6359 encoded-pn = [ given "." ] *( initial "." ) surname 6361 given = 2* 6363 initial = ALPHA 6365 surname = printablestring 6367 std-or-address = 1*( "/" attribute "=" value ) "/" | 6368 attribute = standard-type | 6369 / "RFC-822" | 6370 / registered-dd-type | 6371 / dd-key "." std-printablestring | 6373 RFC 1327bis 6374 MIXER DRAFT Version 2.2 6376 std-or-address-input = ( sep ) (pair) *( sep pair ) ( sep) | 6377 sep = "/" / ";" | 6378 pair = input-attribute "=" value | 6379 input-attribute = attribute | 6380 / dd-key ":" std-printablestring | 6382 standard-type = key-string 6384 registered-dd-type 6385 = key-string dd-key = key-string 6387 value = std-printablestring 6389 std-printablestring 6390 = *( std-char / std-pair ) std-char 6391 = <"{", "}", "*", and any ps-char | 6392 except "/" and "=" > 6393 std-pair = "$" ps-char 6395 global-id = std-or-address 6397 mta-field = "X400-Received" ":" x400-trace 6398 / "Deferred-Delivery" ":" date-time 6399 / "Latest-Delivery-Time" ":" date-time 6401 x400-trace = "by" md-and-mta ";" 6402 [ "deferred until" date-time ";" ] 6403 [ "converted" "(" encoded-info ")" ";" ] 6404 [ "attempted" md-or-mta ";" ] 6405 action-list 6406 ";" arrival-time 6408 RFC 1327bis 6409 MIXER DRAFT Version 2.2 6411 md-and-mta = [ "mta" mta "in" ] global-id 6412 mta = word 6413 arrival-time = date-time 6415 md-or-mta = "MD" global-id 6416 / "MTA" mta 6418 Action-list = 1#action 6419 action = "Redirected" 6420 / "Expanded" 6421 / "Relayed" 6422 / "Rerouted" 6424 RFC 1327bis 6425 MIXER DRAFT Version 2.2 6427 dr-user-info = dr-summary 6428 dr-recipients 6429 dr-content-return 6431 dr-content-return = "The Original Message is not available" 6432 / "The Original Message follows:" 6434 dr-summary = "This report relates to your message:" 6435 content-correlator 6436 "of" date-time 6438 dr-recipients = *(dr-recipient ) 6440 dr-recipient = dr-recip-success / dr-recip-failure 6442 dr-recip-success = 6443 "Your message was successfully delivered to:" 6444 mailbox "at" date-time 6446 dr-recip-failure = "Your message was not delivered to:" 6447 mailbox 6448 "for the following reason:" *word 6450 report-point = [ "mta" word "in" ] global-id 6451 content-correlator = *word 6453 RFC 1327bis 6454 MIXER DRAFT Version 2.2 6456 dr-per-message-fields = 6457 / "X400-Conversion-Date" ":" date-time 6458 / "X400-Subject-Submision-Identifier" ":" 6459 mts-msg-id 6460 / "X400-Content-Identifier" ":" printablestring 6461 / "X400-Content-Type" ":" mts-content-type 6462 / "X400-Original-Encoded-Information-Types" ":" 6463 encoded-info 6464 / "X400-Originator-and-DL-Expansion-History" ":" 6465 dl-history 6466 / "X400-Reporting-DL-Name" ":" mailbox 6467 / "X400-Content-Correlator" ":" content-correlator 6468 / "X400-Recipient-Info" ":" recipient-info 6469 / "X400-Subject-Intermediate-Trace-Information" ":" 6470 x400-trace 6471 / dr-extensions 6473 RFC 1327bis 6474 MIXER DRAFT Version 2.2 6476 dr-per-recipient-fields = 6477 / "X400-Redirect-Recipient" ":" "x400" ";" std-or 6478 / "X400-Mapped-Redirect-Recipient" ":" "rfc822" ";" mailbox 6479 / "X400-Converted-EITs" ":" encoded-info ";" 6480 / "X400-Delivery-Time" ":" date-time 6481 / "X400-Type-of-MTS-User" ":" labelled-integer 6482 / "X400-Last-Trace" ":" [ encoded-info ] date-time 6483 / "X400-Supplementary-Info" ":" 6484 <"> printablestring <"> ";" 6485 / "X400-Redirection-History" ":" redirection-comment 6486 / "X400-Physical-Forwarding-Address" ":" printablestring 6487 / "X400-Originally-Specified-Recipient-Number" ":" 6488 integer 6489 / dr-extensions 6491 dr-extensions = "X400-Discarded-DR-Extensions" ":" 6492 1# (object-identifier / labelled-integer) 6494 dl-history = 1#( mailbox "(" date-time ")") 6496 / "X400-Diagnostic" ":" labelled-integer 6497 / "X400-Reason" ":" labelled-integer 6499 dr-diagnostic = "Reason" labelled-integer 6500 [ ";" "Diagnostic" labelled-integer ] 6502 RFC 1327bis 6503 MIXER DRAFT Version 2.2 6505 mts-field = "X400-MTS-Identifier" ":" mts-msg-id 6506 / "X400-Originator" ":" mailbox 6507 / "X400-Recipients" ":" 1#mailbox 6508 / "Original-Encoded-Information-Types" ":" 6509 encoded-info 6510 / "X400-Content-Type" ":" mts-content-type 6511 / "Content-Identifier" ":" printablestring 6512 / "Priority" ":" priority 6513 / "Originator-Return-Address" ":" 1#mailbox 6514 / "DL-Expansion-History" ":" mailbox ";" date-time ";" 6515 / "Conversion" ":" prohibition 6516 / "Conversion-With-Loss" ":" prohibition 6517 / "Requested-Delivery-Method" ":" 6518 1*( labelled-integer ) 6519 / "Delivery-Date" ":" date-time 6520 / "Discarded-X400-MTS-Extensions" ":" 6521 1#( object-identifier / labelled-integer ) 6523 prohibition = "Prohibited" / "Allowed" 6525 mts-msg-id = "[" global-id ";" *text "]" 6527 mts-content-type = "P2" / labelled-integer 6528 / object-identifier 6530 priority = "normal" / "non-urgent" / "urgent" 6532 RFC 1327bis 6533 MIXER DRAFT Version 2.2 6535 ipn-body-format = ipn-description 6536 [ ipn-extra-information ] 6537 [ ipn-content-return ] 6539 ipn-description = ipn-receipt / ipn-non-receipt 6541 ipn-receipt = "Your message to:" preferred-recipient 6542 "was received at" receipt-time 6543 "This notification was generated" 6544 acknowledgement-mode 6545 "The following extra information was given:" 6546 ipn-suppl 6548 ipn-non-receipt "Your message to:" 6549 preferred-recipient 6550 ipn-reason 6552 ipn-reason = ipn-discarded / ipn-auto-forwarded 6554 ipn-discarded = "was discarded for the following reason:" 6555 discard-reason 6557 ipn-auto-forwarded = "was automatically forwarded." 6558 [ "The following comment was made:" 6559 auto-comment ] 6561 ipn-extra-information = 6562 "The following information types were converted:" 6563 encoded-info 6565 ipn-content-return = "The Original Message is not available" 6566 / "The Original Message follows:" 6568 preferred-recipient = mailbox 6569 receipt-time = date-time 6570 auto-comment = printablestring 6571 ipn-suppl = printablestring 6573 RFC 1327bis 6574 MIXER DRAFT Version 2.2 6576 discard-reason = "Expired" / "Obsoleted" / 6577 "User Subscription Terminated" 6579 acknowledgement-mode = "Manually" / "Automatically" 6581 ipms-field = "Obsoletes" ":" 1#msg-id 6582 / "Expiry-Date" ":" date-time 6583 / "Reply-By" ":" date-time 6584 / "Importance" ":" importance 6585 / "Sensitivity" ":" sensitivity 6586 / "Autoforwarded" ":" boolean 6587 / "Incomplete-Copy" ":" 6588 / "Content-Language" ":" 1#language | 6589 / "Message-Type" ":" message-type 6590 / "Discarded-X400-IPMS-Extensions" ":" 1#object-identifier 6591 / "Autosubmitted" ":" autosubmitted 6593 importance = "low" / "normal" / "high" 6595 sensitivity = "Personal" / "Private" / 6596 "Company-Confidential" 6598 language = 2*ALPHA [ language-description ] 6599 language-description = printable-string 6601 message-type = "Delivery Report" 6602 / "InterPersonal Notification" 6603 / "Multiple Part" 6605 autosubmitted = "not-auto-submitted" 6606 / "auto-generated" 6607 / "auto-replied" 6608 / "auto-forwarded" 6610 RFC 1327bis 6611 MIXER DRAFT Version 2.2 6613 redirect-comment = 6614 [ "Originally To:" ] mailbox "Redirected" 6615 [ "Again" ] "on" date-time 6616 "To:" redirection-reason 6618 redirection-reason = 6619 "Recipient Assigned Alternate Recipient" 6620 / "Originator Requested Alternate Recipient" 6621 / "Recipient MD Assigned Alternate Recipient" 6622 / "Recipient Directory Substitution Alternate Recipient" 6624 subject-line = "Delivery-Report" "(" status ")" 6625 [ "for" destination ] 6627 status = "success" / "failure" / "success and failures" 6629 destination = mailbox / "MTA" word 6631 extended-heading = 6632 "Prevent-NonDelivery-Report" ":" 6633 / "Generate-Delivery-Report" ":" 6634 / "Alternate-Recipient" ":" prohibition 6635 / "Disclose-Recipients" ":" prohibition 6636 / "Content-Return" ":" prohibition 6638 ftbp-field = "FTBP-Object-Size" ":" integer | 6639 / "FTBP-Creation-Date" ":" date-time 6640 / "FTBP-Modification-Date" ":" date-time 6641 "FTBP-Read-Date" ":" date-time 6643 RFC 1327bis 6644 MIXER DRAFT Version 2.2 6646 Appendix F - Format of address mapping tables 6648 1. Global Mapping Information 6650 The consistent operation of gateways which follow this 6651 specification relies of the existence of three globally defined 6652 mappings: 6654 1. Domain Name Space -> O/R Address Space 6656 2. O/R Address Space -> Domain Name Space 6658 3. Domain Name Space -> O/R Address of preferred gateway 6660 All gateways conforming to this specification shall have access | 6661 to and use these mappings. The gateway may use standardised or 6662 private mechanisms to access this mapping information. 6664 One means of distributing this information is in three 6665 files. This appendix defines a format for these files. 6667 2. Mechanisms to register and to distribute Mapping Rules 6669 The global coordination of the mapping rules is a part of 6670 the DANTE 6671 MailFLOW Project. New mapping rules can be defined by the 6672 authority 6673 responsible for the relevant name space. The rules must be 6674 registered 6675 with a national mapping registration authority, which in 6676 turn passes 6677 them on to the central mapping registration authority. 6678 All the collected mapping rules are merged together into the 6679 globally 6680 coordinated mapping tables by the MailFLOW Project Team. The 6681 three 6682 tables are available from the national mapping registration 6683 authorities. 6685 To get a contact address of the mapping registration 6686 authority for the 6687 respective country or more information about the MailFLOW 6689 RFC 1327bis 6690 MIXER DRAFT Version 2.2 6692 Project 6693 contact: 6695 SWITCH 6696 MailFLOW Project Team 6697 Limmatquai 138 6698 8001 Zuerich 6699 Switzerland 6701 email: mailflow@mailflow.dante.net 6702 S=MailFLOW;O=MailFLOW;P=DANTE;A=mailnet;C=fi; 6704 fax: +41 1 268 15 68 6705 tel: +41 1 268 15 20 6707 3. Syntax Definitions 6709 An address syntax is defined, which is compatible with the syntax 6710 used for 822.domains. By representing the O/R addresses as 6711 domains, all lookups can be mechanically implemented as domain -> 6712 domain mappings. This syntax defined is initially for use in 6713 table format, but the syntax is defined in a manner which makes 6714 it suitable to be adapted for use with the Domain Name Service. 6715 This syntax allows for a general representation of O/R addresses, 6716 so that it can be used in other applications. Not all attributes 6717 are used in the table formats defined. 6719 To allow the mapping of null attributes to be represented, 6720 the pseudo-value "@" (not a printable string character) is used 6721 to indicate omission of a level in the hierarchy. This is 6722 distinct from the form including the element with no value, 6723 although a correct X.400 implementation will interpret both in 6724 the same manner. 6726 This syntax is not intended to be handled by users. 6728 RFC 1327bis 6729 MIXER DRAFT Version 2.2 6731 dmn-or-address = dmn-part *( "." dmn-part ) 6732 mn-part = dmn-attribute "$" value 6733 dmn-attribute = standard-type 6734 / "~" dmn-printablestring 6735 value = dmn-printablestring 6736 / "@" 6737 dmn-printablestring = 6738 = *( dmn-char / dmn-pair ) 6739 dmn-char = <"{", "}", "*", and any ps-char 6740 except "."> 6741 dmn-pair = "\." 6743 An example usage: 6745 ~ROLE$Big\.Chief.ADMD$ATT.C$US 6746 PRMD$DEC.ADMD$@.C$US 6748 The first example illustrates quoting of a "." and a domain 6749 define attribute (ROLE). The second example illustrates 6750 omission of the ADMD level. There must be a strict ordering of 6751 all components in this table, with the most significant 6752 components on the RHS. This allows the encoding to be treated 6753 as a domain. 6755 Various further restrictions are placed on the usage of 6756 dmn-or-address in the address space mapping tables. 6758 1. Only C, ADMD, PRMD, O, and up to four OUs may be used. 6760 2. No components shall be omitted from this hierarchy, although 6761 the hierarchy may terminate at any level. If the mapping is 6762 to an omitted component, the "@" syntax is used. 6764 4. Table Lookups 6766 When determining a match, there are aspects which apply to all 6767 lookups. Matches are always case independent. The key for all 6768 three tables is a domain. The longest possible match shall be 6769 obtained. Suppose the table has two entries with the following 6770 keys: 6772 RFC 1327bis 6773 MIXER DRAFT Version 2.2 6775 K.L 6776 J.K.L 6778 Domain "A.B.C" will not return any matches. Domain "I.J.K.L" 6779 will match the entry "J.K.L:. 6781 5. Domain -> O/R Address format 6783 The BNF is: 6785 domain-syntax "#" dmn-or-address "#" 6787 EBNF.domain-syntax is defined in Section 4.2. Note that the 6788 trailing "#" is used for clarity, as the dmn-or-address syntax 6789 might lead to values with trailing blanks. Lines starting with 6790 "#" are comments. 6792 For example: 6793 AC.UK#PRMD$UK\.AC.ADMD$GOLD 400.C$GB# 6794 XEROX.COM#O$Xerox.ADMD$ATT.C$US# 6795 GMD.DE#O$@.PRMD$GMD.ADMD$DBP.C$DE# 6797 A domain is looked up to determine the top levels of an O/R 6798 Address. Components of the domain which are not matched are used 6799 to build the remainder of the O/R address, as described in 6800 Section 4.3.4. 6802 6. O/R Address -> Domain format 6804 The syntax of this table is: 6806 dmn-or-address "#" domain-syntax "#" 6808 For example: 6810 # 6811 # Mapping table 6812 # 6813 PRMD$UK\.AC.ADMD$GOLD 400.C$GB#AC.UK# 6815 The O/R Address is used to generate a domain key. It is 6816 important to order the components correctly, and to fill in 6818 RFC 1327bis 6819 MIXER DRAFT Version 2.2 6821 missing components in the hierarchy. Use of this mapping is 6822 described in Section 4.3.2. 6824 7. Domain -> O/R Address of Gateway table 6826 This uses the same format as the domain -> O/R address mapping. 6827 In this case, the restriction to only use C/ADMD/PRMD/O/OU does 6828 not apply. Use of this mapping is described in Section 4.3.4. A 6829 domain cannot appear in this table and in the domain to O/R 6830 Address table. 6832 RFC 1327bis 6833 MIXER DRAFT Version 2.2 6835 Appendix G - Conformance 6837 This appendix defines a number of options, which a conforming 6838 gateway should specify. Conformance to this specification shall 6839 not be claimed if any of the mandatory features are not 6840 implemented. A specification of conformance may list the service 6841 elements of Chapter 2, in order to be clear that full conformance 6842 is provied. In particular: 6844 - Formats for all fields shall be followed. 6846 - The global mappings shall be supported. 6848 - Formats for subject lines, delivery reports and IPNs shall 6849 be followed. A system which followed the syntax, but 6850 translated text into a language other than english would be 6851 conformant. 6853 - RFC 1137 shall not be followed when mapping to SMTP. 6855 - All mappings of trace shall be implemented. 6857 - There must be a mechanism to access all three global 6858 mappings. 6860 - RFC 1494bis shall be followed for mapping body parts. | 6862 - When it is specified that a MIME format message is 6863 generated, RFC 1521 shall be followed. 6865 A gateway should specify: 6867 - Which Interent Message Transport (822-MTS) protocols are | 6868 supported. If SMTP is supported, Appendex A of MIXER shall 6869 be used. 6871 - Which X.400 versions are supported (84, 88, 92). 6873 - The means by which it can access the global mappings. 6874 Currently, the tables of the formats define in Appendix F 6875 is the only means available. 6877 - The mechanism or mechanisms by which the global mapping * 6879 RFC 1327bis 6880 MIXER DRAFT Version 2.2 6882 information is accessed. 6884 The following are optional parts of this specification. A 6885 conforming implementation should specify which of these it 6886 supports. 6888 - Generation of extended RFC 822 fields is mandatory. 6889 Optionally, they may be parsed and mapped back to X.400. A 6890 gateway should should indicate if this is done, listing the 6891 mappings performed according to each service element of 6892 Chapter 2. 6894 - Support for the extension mappings of Appendix C. 6896 - Support for returning illegal format content in a delivery 6897 report 6899 - Which address interpretation heuristics are supported 6900 (4.3.4.1) 6902 - If RFC 987 generated message ids are handled in a backwards 6903 compatible manner (4.7.3.6) 6905 - Support for FTBP. 6907 RFC 1327bis 6908 MIXER DRAFT Version 2.2 6910 Appendix H - Change History: RFC 987, 1026, 1138, 1148 6912 RFC 987 was the original document, and contained the key elements 6913 of this specification. It was specific to X.400(1984). RFC 1026 6914 specified a small number of necessary changes to RFC 987. 6916 RFC 1138 was based on the RFC 987 work. It contained an 6917 editorial error, and was reissued a few months later as RFC 1148. 6918 RFC 1148 will be referred to here, as it is the document which is 6919 widely referred to elsewhere. The major goal of RFC 1148 was to 6920 upgrade RFC 987 to X.400(1988). It did this, but did not 6921 obsolete RFC 987, which was recommended for use with X.400(1984). 6922 This appendix summarises the changes made in going from RFC 987 6923 to RFC 1148. 6925 RFC 1148 noted the following about its upgrade from RFC 987: 6926 Unnecessary change is usually a bad idea. Changes on the RFC 822 6927 side are avoided as far as possible, so that RFC 822 users do 6928 not see arbitrary differences between systems conforming to this 6929 specification, and those following RFC 987. Changes on the X.400 6930 side are minimised, but are more acceptable, due to the mapping 6931 onto a new set of services and protocols. 6933 1. Introduction 6935 The model has shifted from a protocol based mapping to a service 6936 based mapping. This has increased the generality of the 6937 specification, and improved the model. This change affects the 6938 entire document. 6940 A restriction on scope has been added. 6942 2. Service Elements 6944 - The new service elements of X.400 are dealt with. 6946 - A clear distinction is made between origination and 6947 reception 6949 RFC 1327bis 6950 MIXER DRAFT Version 2.2 6952 3. Basic Mappings 6954 - Add teletex support 6956 - Add object identifier support 6958 - Add labelled integer support 6960 - Make PrintableString <-> ASCII mapping reversible 6962 - The printable string mapping is aligned to the NBS mapping 6963 derived from RFC 987. 6965 4. Addressing 6967 - Support for new addressing attributes 6969 - The message ID mapping is changed to not be table driven 6971 5. Detailed Mappings 6973 - Define extended IPM Header, and use instead of second body 6974 part for RFC 822 extensions 6976 - Realignment of element names 6978 - New syntax for reports, simplifying the header and 6979 introducing a mandatory body format (the RFC 987 header 6980 format was unusable) 6982 - Drop complex autoforwarded mapping 6984 - Add full mapping for IP Notifications, defining a body 6985 format 6987 - Adopt an MTS Identifier syntax in line with the O/R Address 6988 syntax 6990 - A new format for X400 Trace representation on the RFC 822 6991 side 6993 RFC 1327bis 6994 MIXER DRAFT Version 2.2 6996 6. Appendices 6998 - Move Appendix on restricted 822 mappings to a separate RFC 7000 - Delete Phonenet and SMTP Appendixes 7002 RFC 1327bis 7003 MIXER DRAFT Version 2.2 7005 Appendix I - Change History: RFC 1148 to RFC 1327 7007 1. General 7009 - The scope of the document was changed to cover X.400(1984), 7010 and so obsolete RFC 987. 7012 - Changes were made to allow usage to connect RFC 822 networks 7013 using X.400 7015 - Text was tightened to be clear about optional and mandatory 7016 aspects 7018 - A good deal of clarification 7020 - A number of minor EBNF errors 7022 - Better examples are given 7024 - Further X.400 upper bounds are handled correctly 7026 2. Basic Mappings 7028 - The encoding of object identifier is changed slightly 7030 3. Addressing 7032 - A global mapping of domain to preferred gateway is 7033 introduced. 7035 - An overflow mechanism is defined for RFC 822 addresses of 7036 greater than 128 bytes 7038 - Changes were made to improve compatibility with the PDAM on 7039 writing O/R Addresses. 7041 + The PD and Terminal Type keywords were aligned to the 7042 PDAM. It is believed that minimal use has been made of 7043 the RFC 1148 keywords. 7045 RFC 1327bis 7046 MIXER DRAFT Version 2.2 7048 + P and A are allowed as alternate keys for PRMD and ADMD 7050 + Where keywords are different, the PDAM keywords are 7051 alternatives on input. This is mandatory. 7053 4. Detailed Mappings 7055 - The format of the Subject: lines is defined. 7057 - Illegal use (repetition) of the heading EXTENSION is 7058 corrected, and a new object identifier assigned. 7060 - The Delivery Report format is extensively revised in light 7061 of operational experience. 7063 - The handling of redirects is significantly changed, as the 7064 previous mechanism did not work. 7066 5. Appendices 7068 - An SMTP appendix is added, allowing optional use of the VRFY 7069 command to improve probe information. 7071 - Handling of JNT Mail Acknowledge-To is changed slightly. 7073 - A DDA JNT-MAIL is allowed on input. 7075 - The format definitions of Appendix F are explained further, 7076 and a third table definition added. 7078 - An appendix on use with X.400(1984) is added. 7080 - Optional extensions are defined to give RFC 822 access to 7081 further X.400 facilities. 7083 - An appendix on conformance is added. 7085 RFC 1327bis 7086 MIXER DRAFT Version 2.2 7088 Appendix J - Change History: RFC 1327 to this Document 7090 1. General 7092 This update is primarily for stability, and to fold in 7093 compatibility for MIME and to add support for the new NOTARY 7094 delivery status notifications. Other general changes: 7096 - Various editorial updates 7098 - Minor EBNF errors 7100 - Reference to mapping table support by DNS and X.500. 7102 - Alignment to X.400(92) 7104 - Assignment of a new object identifier 7106 - Support for the EMA profile of the File Transfer Body Part. 7108 2. Service Elements 7110 - Support of Auto-Submitted service 7112 3. Basic Mappings 7114 - Comments may not be used in new headers, to remove parsing 7115 ambiguity 7117 - RFC 1522 encoding may be used as an alternative to X.408 7118 downgrade, where appropriate. 7120 4. Addressing 7122 - Restructure of text to emphasise the global mappings 7124 - Add codes and add a heuristic to align to the standard X.400 7125 form of writing O/R Addresses. 7127 RFC 1327bis 7128 MIXER DRAFT Version 2.2 7130 - Improved text on ordering heuristic 7132 - Leading "/" interpretation added | 7134 - All bar one of the address mapping heuristics made | 7135 mandatory. | 7137 - Interpretation of domain defined attribute "RFC-822" made | 7138 mandatory in all cases | 7140 - Make report request comments optional 7142 5. Detailed Mappings 7144 - Comments no longer maps to separate body part | 7146 - Allow Langauges to be multi-valued 7148 - Change Content-Identifier to X400-Content-Identifier, in 7149 order to avoid confusion with MIME. | 7151 - Reverse mapping of MIXER defined fields made mandatory 7153 6. Appendices 7155 - Relaxation of restrictions on mapping 3 in Appendix F. 7157 - Add linkage to HARPOON in Appendix B. 7159 - RFC 1494bis added to the conformance statement of Appendix | 7160 G. 7162 RFC 1327bis 7163 MIXER DRAFT Version 2.2 7165 SECURITY CONSIDERATIONS 7167 Security considerations are not discussed in this RFC. 7169 AUTHOR'S ADDRESS 7171 Steve Kille 7172 ISODE Consortium 7173 The Dome 7174 The Square 7175 Richmond 7176 TW9 1DT 7177 England 7179 Phone: +44-181-332-9091 7181 Internet EMail: S.Kille@ISODE.COM 7183 X.400 Email: I=S; S=Kille; O=ISODE Consortium; P=ISODE; A=Mailnet; C=FI; 7185 UFN: S.Kille, ISODE Consortium, GB 7187 RFC 1327bis 7188 MIXER DRAFT Version 2.2 7190 References 7192 1. 7194 2. CCITT SG 5/VII, "Recommendations X.400," Message Handling 7195 Systems: System Model - Service Elements, October 1984. 7197 3. C. Allocchio, "Mapping between X.400(1984/1988) and Mail-11 7198 (DECnet mail)," RFC 1405, jan 1993. 7200 4. C. Allocchio, B. Cole, S. Giordano, and R. Hagens, "Using 7201 the Internet DNS to Distribute RFC 1327 Mail Address Mapping 7202 Tables," RFC 1664, aug 1994. 7204 5. H.T. Alvestrand, S.E. Kille, R. Miles, M. Rose, and S. 7205 Thompson, "Mapping between X.400 and RFC-822 Message 7206 Bodies," RFC 1495, Aug 1993. 7208 6. H.T. Alvestrand, J. Romaguera, and K. Jordan, "Rules for 7209 Downgrading Messages for X.400(88) to X.400(84) When MIME 7210 Consent-Types are Present in the Messages (Harpoon)," RFC 7211 1496, Aug 1993. 7213 7. H.T. Alvestrand and S. Thompson, "Equivalences between X.400 7214 and RFC-822 Message Bodies," RFC 1494, Aug 1993. 7216 8. H.T. Alvestrand, "Tags for the Identification of Languages," 7217 RFC 17566, March 1995. 7219 9. N. Borenstein and N. Freed, "MIME (Multipurpose Internet 7220 Mail Extensions)," RFC 1521, Sep 1993. 7222 10. R.T. Braden, "Requirements for Internet Hosts -- Application 7223 and Support," RFC 1123, Oct 1989. 7225 11. CCITT/ISO, "CCITT Recommendations X.420/ ISO IS 10021-7," 7226 Message Handling Systems: Interpersonal Messaging System, 7227 December 1988. 7229 12. CCITT/ISO, "CCITT Recommendations X.411/ ISO IS 10021-4," 7230 Message Handling Systems: Message Transfer System: Abstract 7231 Service Definition and Procedures, December 1988. 7233 RFC 1327bis 7234 MIXER DRAFT Version 2.2 7236 13. CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1," 7237 Message Handling: System and Service Overview , December 7238 1988. 7240 14. CCITT/ISO, "Specification of Abstract Syntax Notation One 7241 (ASN.1)," CCITT Recommendation X.208 / ISO IS 8824, December 7242 1988. 7244 15. CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1," 7245 Message Handling: System and Service Overview , December 7246 1992. 7248 16. D.H. Crocker, "Standard of the Format of ARPA Internet Text 7249 Messages," RFC 822, August 1982. 7251 17. S.E. Kille, "Mapping Between X.400 and RFC 822," UK Academic 7252 Community Report (MG.19) / RFC 987, June 1986. 7254 18. S.E. Kille, "Addendum to RFC 987," UK Academic Community 7255 Report (MG.23) / RFC 1026, August 1987. 7257 19. S.E. Kille, "Mapping between full RFC 822 and RFC 822 with 7258 restricted encoding," RFC 1137, October 1989. 7260 20. S.E. Kille, "Mapping Between X.400(1988) / ISO 10021 and RFC 7261 822," RFC 1138, October 1989. 7263 21. S.E. Kille, "Mapping Between X.400(1988) / ISO 10021 and RFC 7264 822," RFC 1148, March 1990. 7266 22. S.E. Kille, "Mapping Between X.400(1988) / ISO 10021 and RFC 7267 822," RFC 1327, May 1992. 7269 23. S.E. Kille, "X.400 1988 to 1984 downgrading," RFC 1328, May 7270 1992. 7272 24. S.E. Kille, "A String Encoding of Presentation Address," RFC 7273 1278, Nov 1992. 7275 25. S.E. Kille, "A String Representation of Distinguished Name," 7276 RFC 1485, Jan 1992. 7278 26. S.E. Kille, "Using the OSI Directory to achieve User 7279 Friendly Naming," RFC 1484, Jan 1992. 7281 RFC 1327bis 7282 MIXER DRAFT Version 2.2 7284 27. S.E. Kille, "Use of the X.500 Directory to support mapping 7285 between X.400 and RFC 822 Addresses," RFC in preparation, 7286 Sep 1994. 7288 28. N. Koorland, "Message Attachmment Work Group (MAWG): MAWG 7289 Feasibility Project Guide," EMA Report, Version 1.3, March 7290 1995. 7292 29. K. Moore and G. Vaudreuil, "An Extensible Message Format for 7293 Delivery Status Notifications," RFC Draft, May 1995. 7295 30. K. Moore, "SMTP Service Extensions for Delivery Status 7296 Notifications," RFC Draft, May 1995. 7298 31. J.B. Postel, "SIMPLE MAIL TRANSFER PROTOCOL," RFC 821, 7299 August 1982. 7301 32. CEN/CENELEC/Information Technology/Working Group on Private 7302 Message Handling Systems, "FUNCTIONAL STANDARD A/3222," 7303 CEN/CLC/IT/WG/PMHS N 17, October 1985. 7305 33. R. Troot and S. Dorner, "Communicating Presentation 7306 Information in Internet Messages: The Content Dispostion 7307 Header," RFC 1806, June 1995. 7309 1 - General ....................................... 166 7310 2 - Basic Mappings ................................ 166 7311 3 - Addressing .................................... 166 7312 4 - Detailed Mappings ............................. 167 7313 5 - Appendices .................................... 167 7314 Appendix J - Change History: RFC 1327 to this Document 7315 ............................................................ 168 7316 1 - General ....................................... 168 7317 2 - Service Elements .............................. 168 7318 3 - Basic Mappings ................................ 168 7319 4 - Addressing .................................... 168 7320 5 - Detailed Mappings ............................. 169 7322 RFC 1327bis 7323 MIXER DRAFT Version 2.2 7325 6 - Appendices .................................... 169