idnits 2.17.1 draft-kille-mixer-rfc1327bis-00.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-27) 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 1563 instances of too long lines in the document, the longest one being 18 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 44 has weird spacing: '...ch will enabl...' == Line 45 has weird spacing: '...working betwe...' == Line 49 has weird spacing: '... mail proto...' == Line 53 has weird spacing: '... not requi...' == Line 54 has weird spacing: '...ocument is a...' == (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 (June 1995) is 10544 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? '21' on line 1516 looks like a reference -- Missing reference section? '14' on line 4026 looks like a reference -- Missing reference section? '22' on line 56 looks like a reference -- Missing reference section? '23' on line 56 looks like a reference -- Missing reference section? '25-27' on line 56 looks like a reference -- Missing reference section? '10' on line 57 looks like a reference -- Missing reference section? '35' on line 270 looks like a reference -- Missing reference section? '16' on line 339 looks like a reference -- Missing reference section? '17' on line 373 looks like a reference -- Missing reference section? '33' on line 5437 looks like a reference -- Missing reference section? '11' on line 6187 looks like a reference -- Missing reference section? '28' on line 504 looks like a reference -- Missing reference section? '12' on line 6185 looks like a reference -- Missing reference section? '26' on line 568 looks like a reference -- Missing reference section? '8' on line 612 looks like a reference -- Missing reference section? '32' on line 3947 looks like a reference -- Missing reference section? '0' on line 1598 looks like a reference -- Missing reference section? '18' on line 1608 looks like a reference -- Missing reference section? '4' on line 2003 looks like a reference -- Missing reference section? '9' on line 2254 looks like a reference -- Missing reference section? '31' on line 2257 looks like a reference -- Missing reference section? '15' on line 2611 looks like a reference -- Missing reference section? '24' on line 2971 looks like a reference -- Missing reference section? '29' on line 3127 looks like a reference -- Missing reference section? '30' on line 3128 looks like a reference -- Missing reference section? '13' on line 4760 looks like a reference -- Missing reference section? '36' on line 5381 looks like a reference -- Missing reference section? '34' on line 6079 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 31 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 June 1995 4 Expires: December 1995 5 File: 7 MIXER (Mime Internet X.400 Enhanced Relay): 9 Mapping between X.400 and RFC 822/MIME 11 13 Status of this Memo 15 This document is an Internet Draft. Internet Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its Areas, 17 and its Working Groups. Note that other groups may also distribute 18 working documents as Internet Drafts. Internet Drafts are draft 19 documents valid for a maximum of six months. Internet Drafts may be 20 updated, replaced, or obsoleted by other documents at any time. It is 21 not appropriate to use Internet Drafts as reference material or to 22 cite them other than as a ``working draft'' or ``work in progress.'' 23 Please check the I-D abstract listing contained in each Internet Draft 24 directory to learn the current status of this or any other Internet 25 Draft. 27 NOTE: This document is change-barred relative to RFC 1327. Some 28 obvious formatting errors have been introducted by this process, 29 and these will not be present in the final version. 31 Network Working Group S.E. Kille 32 Internet Draft ISODE Consortium 33 RFC 1327bis June 1995 34 Obsoletes: RFCs 987, 1026, 1138, 1148, 1327, 1495 35 Updates: RFC 822 36 | 38 MIXER (Mime Internet X.400 Enhanced Relay): | 40 Mapping between X.400 and RFC 822/MIME | 42 Status of this Memo: | 44 This document describes a set of mappings which will enable | 45 interworking between systems operating the CCITT X.400 | 46 Recommendations on Message Handling Systems (1984, 1988 and | 47 1992 versions) / ISO IEC 10021 Message Oriented Text | 48 Interchange Systems (MOTIS) , and systems using the RFC 822 | 49 mail protocol [21] or protocols derived from RFC 822, | 50 supplemented by the MIME specifications [14]. Older systems | 51 which do not use MIME are still supported. The approach aims 52 to maximise the services offered across the boundary, whilst 53 not requiring unduly complex mappings. The mappings should 54 not require any changes to end systems. This document is a 55 revision based on the evolving sequence of RFCs 987, 1026, 56 1138, 1148 and 1327 [22,23,25-27], which it obsoletes. It | 57 incorporates changes specified in RFC 1495 [10], which it | 58 also obsoletes. 60 This document specifies a mapping between two families of | 61 protocols, which includes both protocol/service mappings and | 62 use of a mandatory global mappings. This specification 63 should be used when this mapping is performed on the DARPA 64 Internet or in the UK Academic Community. This specification 65 may be modified in the light of implementation experience, 66 but no substantial changes are expected. 68 This draft document will be submitted to the RFC editor as 69 a protocol specification. Distribution of this memo is 70 unlimited. Please send comments to the author. 72 INTERNET DRAFT 73 MIXER DRAFT Version 2.1 75 2.1 - The Notion of Service Across a Gateway ........ 16 76 2.2 - RFC 822 ....................................... 17 77 2.3 - X.400 ......................................... 23 78 3 - Basic Mappings ................................ 34 79 3.1 - Notation ...................................... 34 80 3.2 - ASCII and IA5 ................................. 36 81 3.3 - Standard Types ................................ 36 82 3.4 - Encoding ASCII in Printable String ............ 39 83 3.5 41 RFC 1522 ...................................... | 84 4 - Addressing and 42ssage IDs .................... | 85 4.1 - A textual representation of MTS.ORAddress ..... 43 86 4.2 50 - .mc | ......................................... | 87 4.3 - EBNF.822-address <-> MT53ORAddress ............ | 88 4.4 - Repeated Mappings ............................. 67 89 4.5 - Directory Names ............................... 69 90 4.6 - MTS Mappings .................................. 70 91 4.7 - IPMS Mappings ................................. 75 92 5 - Detailed Mappings ............................. 81 93 5.1 - .mc | ..81..................................... | 95 INTERNET DRAFT 96 MIXER DRAFT Version 2.1 98 5.2 - Return of Contents ............................ 100 99 5.3 - .mc | ..101.................................... | 100 Appendix A - Mappings Specific to SMTP ..................... 139 101 6 - Probes .139.................................... | 102 7 - Long Lines .139................................ | 103 8 - SMTP Extensions .139........................... | 104 8.1 - SMTP Extension mapping to X.400 .139........... | 105 8.2 - X.400 Mapping to SMTP Extensions .140.......... | 106 Appendix B - Mapping with X.400(1984) .141............. | 107 Appendix C - RFC 822 Extensions for X.400 access 143........ | 108 Appendix D - Object Identifier Assignment .................. 144 109 Appendix E - BNF Summary .............................. 145 110 Appendix F - Format of address mapping tables .............. 156 111 1 - Global Mapping Information .................... 156 112 2 - Mechanisms to register and to distribute | 113 Mapping Rules 156........................................... | 114 3 - Syntax Definitions ............................ 157 115 4 - Table Lookups ................................. 158 116 5 - Domain -> O/R Address format .................. 159 117 6 - O/R Address -> Domain format .................. 159 118 7 - Domain -> O/R Address of Gateway table ........ 160 119 Appendix G - Conformance 161................................ | 120 Appendix H - Change History: RFC 987, 1026, 1138, 1148 | 121 ............................................................ 163 122 1 - Introduction .................................. 163 123 2 - Service Elements .............................. 163 124 3 - Basic Mappings ................................ 164 125 4 - Addressing .................................... 164 126 5 - Detailed Mappings ............................. 164 127 6 - Appendices .................................... 165 128 Appendix I - Change History: RFC 1148 to RFC 1327 166....... | 129 1 - General ....................................... 166 130 2 - Basic Mappings ................................ 166 131 3 - Addressing .................................... 166 132 4 - Detailed Mappings ............................. 167 133 5 - Appendices .................................... 167 134 Appendix J - Change History: RFC 1327 to this Document | 135 168......................................................... | 136 1 - General 168.................................... | 137 2 - Service Elements 168........................... | 138 3 - Basic Mappings 168............................. | 139 4 - Addressing 168................................. | 140 5 - Detailed Mappings 169.......................... | 141 6 - Appendices 169................................. | 143 INTERNET DRAFT 144 MIXER DRAFT Version 2.1 146 Table of Contents 148 1 - Overview ...................................... 6 149 1.1 - X.400 ......................................... 6 150 1.2 - .mc | ......6.................................. | 151 1.3 - The need for conversion ....................... 7 152 1.4 - General approach .............................. 7 153 1.5 - Gatewaying Model .............................. 8 154 1.6 - X.400 (1984) .................................. 11 155 1.7 - .mc | .....11.................................. | 156 1.8 - MIME .....12................................... | 157 1.9 - Body Parts .....12............................. | 158 1.10 - .mc .......................................... 13 159 1.11 - Aspects not covered .......................... 13 160 1.12 - Subsetting ................................... 13 161 1.13 - .mc | .....13................................. | 162 1.14 - .mc .......................................... 14 163 1.15 - Acknowledgements ............................. 14 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 ......................................... 23 168 3 - Basic Mappings ................................ 34 169 3.1 - Notation ...................................... 34 170 3.2 - ASCII and IA5 ................................. 36 171 3.3 - Standard Types ................................ 36 172 3.4 - Encoding ASCII in Printable String ............ 39 173 3.5 41 RFC 1522 ...................................... | 174 4 - Addressing and 42ssage IDs .................... | 175 4.1 - A textual representation of MTS.ORAddress ..... 43 176 4.2 50 - .mc | ......................................... | 177 4.3 - EBNF.822-address <-> MT53ORAddress ............ | 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 183 5.1 - .mc | ..81..................................... | 185 INTERNET DRAFT 186 MIXER DRAFT Version 2.1 188 5.2 - Return of Contents ............................ 100 189 5.3 - .mc | ..101.................................... | 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.......................... | 231 6 - Appendices 169................................. | 233 INTERNET DRAFT 234 MIXER DRAFT Version 2.1 235 Chapter 1 -- Overview 237 1.1. X.400 239 This document relates primarily to the ITU 1988 and 1992 X.400 | 240 Series Recommendations / ISO IEC 10021 on the Message Oriented | 241 Text Interchange Service (MOTIS). This ISO/ITU standard is | 242 referred to in this document as "X.400", which is a convenient | 243 shorthand. Any reference to the 1984 ITU Recommendations will be | 244 explicit. Any mappings relating to elements which are in the | 245 1992 version and not in the 1988 version will be noted | 246 explicitly. X.400 defines an Interpersonal Messaging System | 247 (IPMS), making use of a store and forward Message Transfer | 248 System. This document relates to the IPMS, and not to wider | 249 application of X.400. 251 1.2. | 252 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 [35], in a manner conformant with the host requirements | 271 specification . Use of MIXER with SMTP is defined in Appendix A. | 273 INTERNET DRAFT 274 MIXER DRAFT Version 2.1 276 1.3. The need for conversion 278 There is a large community using RFC 822 based protocols for mail 279 services, who will wish to communicate with users of the IPMS 280 provided by X.400 systems. This will also be a requirement in 281 cases where communities intend to make a transition to use of an 282 X.400 IPMS, as conversion will be needed to ensure a smooth 283 service transition. It is expected that there will be more than 284 one gateway, and this specification will enable them to behave in 285 a consistent manner. Note that the term gateway is used to 286 describe a component performing the protocol mappings between RFC 287 822 and X.400. This is standard usage amongst mail implementors, 288 but should be noted carefully by transport and network service 289 implementors. 291 Consistency between gateways is desirable to provide: 293 1. Consistent service to users. 295 2. The best service in cases where a message passes through 296 multiple gateways. 298 1.4. General approach 300 There are a number of basic principles underlying the details of 301 the specification. These principles are goals, and are not 302 achieved in all aspects of the specification. 304 1. The specification should be pragmatic. There should not be 305 a requirement for complex mappings for "Academic" reasons. 306 Complex mappings should not be required to support trivial 307 additional functionality. 309 2. Subject to 1), functionality across a gateway should be as 310 high as possible. 312 3. It is always a bad idea to lose information as a result of 313 any transformation. Hence, it is a bad idea for a gateway 314 to discard information in the objects it processes. This 315 includes requested services which cannot be fully mapped. 317 4. All mail gateways actually operate at exactly one level 318 above the layer on which they conceptually operate. This 319 implies that the gateway must not only be cognisant of the 321 INTERNET DRAFT 322 MIXER DRAFT Version 2.1 324 semantics of objects at the gateway level, but also be 325 cognisant of higher level semantics. If meaningful 326 transformation of the objects that the gateway operates on 327 is to occur, then the gateway needs to understand more than 328 the objects themselves. 330 5. Subject to 1), the specification should be reversible. That 331 is, a double transformation should bring you back to where 332 you started. 334 1.5. Gatewaying Model 336 1.5.1. X.400 338 X.400 defines the IPMS Abstract Service in X.420/ISO 10021-7 , 339 [16] which comprises of three basic services: 341 1. Origination 343 2. Reception 345 3. Management 347 Management is a local interaction between the user and the IPMS, 348 and is therefore not relevant to gatewaying. The first two 349 services consist of operations to originate and receive the 350 following two objects: 352 1. IPM (Interpersonal Message). This has two components: a 353 heading, and a body. The body is structured as a sequence 354 of body parts, which may be basic components (e.g., IA5 | 355 text, or G3 fax), or Interpersonal Messages. The heading 356 consists of fields containing end to end user information, 357 such as subject, primary recipients (To:), and importance. 359 2. IPN (Inter Personal Notification). A notification about 360 receipt of a given IPM at the UA level. 362 The Origination service also allows for origination of a probe, 363 which is an object to test whether a given IPM could be correctly 364 received. 366 The Reception service also allows for receipt of Delivery Reports 367 (DR), which indicate delivery success or failure. 369 INTERNET DRAFT 370 MIXER DRAFT Version 2.1 372 These IPMS Services utilise the Message Transfer (MT) 373 Abstract Service [17]. The MT Abstract Service provides the 374 following three basic services: 376 1. Submission (used by IPMS Origination) 378 2. Delivery (used by IPMS Reception) 380 3. Administration (used by IPMS Management) 382 Administration is a local issue, and so does not affect this 383 standard. Submission and delivery relate primarily to the MTS 384 Message (comprising Envelope and Content), which carries an IPM 385 or IPN (or other uninterpreted contents). There is also an 386 Envelope, which includes an ID, an originator, and a list of 387 recipients. Submission also includes the probe service, which 388 supports the IPMS Probe. Delivery also includes Reports, which 389 indicate whether a given MTS Message has been delivered or not. 391 The MTS is REFINED into the MTA (Message Transfer Agent) 392 Service, which defines the interaction between MTAs, along with 393 the procedures for distributed operation. This service provides 394 for transfer of MTS Messages, Probes, and Reports. 396 1.5.2. RFC 822 398 RFC 822 is based on the assumption that there is an underlying 399 service, which is here called the 822-MTS service. The 822-MTS 400 service provides three basic functions: 402 1. Identification of a list of recipients. 404 2. Identification of an error return address. 406 3. Transfer of an RFC 822 message. 408 It is possible to achieve 2) within the RFC 822 header. Some 409 822-MTS protocols, in particular SMTP, can provide additional 410 functionality, but as these are neither mandatory in SMTP, nor 411 available in other 822-MTS protocols, they are not considered 412 here. Details of aspects specific to two 822-MTS protocols are 413 given in Appendices B and C. An RFC 822 message consists of a 414 header, and content which is uninterpreted ASCII text. The 415 header is divided into fields, which are the protocol elements. 417 INTERNET DRAFT 418 MIXER DRAFT Version 2.1 420 Most of these fields are analogous to P2 heading fields, although 421 some are analogous to MTS Service Elements or MTA Service 422 Elements. | 424 RFC 822 supports delivery status notifications by use of the | 425 NOTARY mechanisms [33]. 427 1.5.3. The Gateway 429 Given this functional description of the two services, the 430 functional nature of a gateway can now be considered. It would 431 be elegant to consider the 822-MTS service mapping onto the MTS 432 Service Elements and RFC 822 mapping onto an IPM, but reality 433 just does not fit. Another elegant approach would be to treat 434 this document as the definition of an X.400 Access Unit (AU). 435 Again, reality does not fit. It is necessary to consider that 436 the IPM format definition, the IPMS Service Elements, the MTS 437 Service Elements, and MTA Service Elements on one side are mapped 438 into RFC 822 + 822-MTS on the other in a slightly tangled manner. 439 The details of the tangle will be made clear in Chapter 5. 440 Access to the MTA Service Elements is minimised. 442 The following basic mappings are thus defined. When going 443 from RFC 822 to X.400, an RFC 822 message and the associated | 444 822-MTS information is always mapped into an IPM (MTA, MTS, and | 445 IPMS Services) and a Delivery Status Notification is mapped onto | 446 a Report. Going from X.400 to RFC 822, an RFC 822 message and 447 the associated 822-MTS information may be derived from: 449 1. An IPN (MTA, MTS, and IPMS services) | 451 2. An IPM (MTA, MTS, and IPMS services) 453 A Report (MTA, and MTS Services) is mapped onto a delivery status | 454 notification. | 456 Probes (MTA Service) must be processed by the gateway, as 457 discussed in Chapter 5. MTS Messages containing Content Types 458 other than those defined by the IPMS are not mapped by the 459 gateway, and should be rejected at the gateway. 461 1.5.4. Repeated Mappings 463 The primary goal of this specification is to support single 465 INTERNET DRAFT 466 MIXER DRAFT Version 2.1 468 mappings, so that X.400 and RFC 822 users can communicate with 469 maximum functionality. 471 The mappings specified here are designed to work where a 472 message traverses multiple times between X.400 and RFC 822. This 473 is often essential, particularly in the case of distribution 474 lists. However, in general, this will lead to a level of service 475 which is the lowest common denominator (approximately the 476 services offered by RFC 822). 478 Some RFC 822 networks may wish to use X.400 as an 479 interconnection mechanism (typically for policy reasons), and 480 this is fully supported. 482 Where an X.400 message transfers to RFC 822 and then back to | 483 X.400, there is no expectation of X.400 services which do not 484 have an equivalent service in standard RFC 822 being preserved - 485 although this may be possible in some cases. 487 1.6. X.400 (1984) 489 Much of this work is based on the initial specification of RFC 490 987 and in its addendum RFC 1026, which defined a mapping between 491 X.400(1984) and RFC 822. A basic decision is that the mapping 492 defined in this document is to the full 1988 version of X.400, 493 and not to a 1984 compatible subset. New features of X.400(1988) 494 can be used to provide a much cleaner mapping than that defined 495 in RFC 987. This is important, to give good support to 496 communities which will utilise full X.400 at an early date. To | 497 interwork with 1984 systems, Appendix B shall be followed. 499 If a message is being transferred to an X.400(1984) system 500 by way of X.400(1988) MTA it will give a slightly better service | 501 to follow the rules of Appendix B, than to downgrade without this | 502 knowledge. Downgrading specifications which supplement those | 503 specified in X.400 are given in RFC 1328 and RFC 1496 (HARPOON) | 504 [11,28]. 506 1.7. | 507 X.400 (1992) | 509 X.400 (1992) features are not used by the core of this mapping, | 510 and so there is not an equivalent downgrade problem. | 512 INTERNET DRAFT 513 MIXER DRAFT Version 2.1 515 1.8. MIME | 517 MIME format messages are generated by this mapping. As MIME | 518 messages are fully RFC 822 compliant, this will not cause | 519 problems with systems which are not MIME capable. | 521 1.9. Body Parts | 523 MIME and X.400 IPMS can both carry arbitrary body parts. This | 524 specification describes mapping of the framework for structured | 525 messages, but does not specify how specific body parts shall be | 526 mapped. Body part mapping is an open ended problem, as new body | 527 parts (attachments) will continue to be added to both X.400 and | 528 MIME. | 530 MIME defines a mechanism for adding new body parts, and new | 531 body parts are registered with the IANA. | 533 X.400 defines a mechanism adding new body parts, usually | 534 referred to as Body Part 15. Extensions are defined by Object | 535 Identifiers, so there is no requirement for a body part | 536 registration authority. The Electronic Mail Association (EMA) | 537 maintains a list of some commonly used body parts. The EMA has | 538 specified a mechanism to use the File Transfer Body Part (FTBP) | 539 as a more generic means to support message attachments. This | 540 approach is gaining widespread commercial support. MIXER defines | 541 how to map between MIME and both the Body Part 15 and EMA/FTBP | 542 extension mechanisms for X.400. In many cases, this will enable | 543 a gateway implementor to map between the same body part carried | 544 by these mechanisms. | 546 Mapping of standard IPM and MIME body parts, and some | 547 extended MIME and X.400 body parts, is defined in RFC 1494bis | 548 [12]. This also gives a model for specifying further mappings. | 550 It will not be possible to specify all mappings. Therefore, | 551 MIXER defines encapsulation mechanisms for both MIME and X.400. | 552 This will allow all body parts to be transferred end to end, | 553 irrespective of a mapping being defined. | 555 To provide a gateway service, it is therefore necessary for | 556 an implementation to conform to both this specification and to | 557 provide various body part mappings, such as those defined in RFC | 558 1494bis. | 560 INTERNET DRAFT 561 MIXER DRAFT Version 2.1 563 1.10. 564 Compatibility with previous versions 566 The changes between this and older versions of the document are 567 given in Appendices I and J. These are RFCs 987, 1026, 1138, 568 and 1148. This document is a revision of RFC 1148 [26]. As far 569 as possible, changes have been made in a compatible fashion. 571 1.11. Aspects not covered 573 There have been a number of cases where previous version of this | 574 document | 575 were used in a manner which was not intended. This section is 576 to make clear some limitations of scope. In particular, this 577 specification does not specify: 579 - Extensions of RFC 822 to provide access to all X.400 580 services 582 - X.400 user interface definition * 584 These are really coupled. To map the X.400 services, this | 585 specification defines a number of extensions to RFC 822. As a 586 side effect, these give the 822 user access to SOME X.400 587 services. However, the aim on the RFC 822 side is to preserve 588 current service, and it is intentional that access is not given 589 to all X.400 services. Thus, it will be a poor choice for X.400 590 implementors to use MIXER as an interface - there are too many | 591 aspects of X.400 which cannot be accessed through it. If a text 592 interface is desired, a specification targeted at X.400, without 593 RFC 822 restrictions, would be more appropriate. Some optional 594 and limited extensions in this area have proved useful, and are | 595 defined in Appendix C. 597 1.12. Subsetting 599 This proposal specifies a mapping which is appropriate to 600 preserve services in existing RFC 822 communities. 601 Implementations and specifications which subset this 602 specification are strongly discouraged. 604 1.13. | 605 Related Specifications | 607 INTERNET DRAFT 608 MIXER DRAFT Version 2.1 610 Mappings between Mail-11 and X.400 and Mail-11 and rfc822 are | 611 described in RFC1405, using mappings related to those defined | 612 here [8]. | 614 1.14. 615 Document Structure 617 This document has five chapters: 619 1. Overview - this chapter. 621 2. Service Elements - This describes the (end user) services 622 mapped by a gateway. 624 3. Basic mappings - This describes some basic notation used in 625 Chapters 3-5, the mappings between character sets, and some 626 fundamental protocol elements. 628 4. Addressing - This considers the mapping between X.400 O/R 629 names and RFC 822 addresses, which is a fundamental gateway 630 component. 632 5. Detailed Mappings - This describes the details of all other 633 mappings. 635 There are also ten appendices. | 637 WARNING: 638 THE REMAINDER OF THIS SPECIFICATION IS TECHNICALLY DETAILED. 639 IT WILL NOT MAKE SENSE, EXCEPT IN THE CONTEXT OF RFC 822 AND 640 X.400 (1988). DO NOT ATTEMPT TO READ THIS DOCUMENT UNLESS 641 YOU ARE FAMILIAR WITH THESE SPECIFICATIONS. 643 1.15. Acknowledgements 645 The work in this specification was substantially based on RFC 987 646 and RFC 1148, which had input from many people, who are credited 647 in the respective documents. 649 A number of comments from people on RFC 1148 lead to RFC | 650 1327. In particular, there were comments and suggestions from: 651 Maurice Abraham (HP); Harald Alvestrand (Sintef); Peter Cowen 653 INTERNET DRAFT 654 MIXER DRAFT Version 2.1 656 (X-Tel); Jim Craigie (JNT); Ella Gardner (MITRE); Christian | 657 Huitema (Inria); Erik Huizer (SURFnet); Neil Jones (DEC); Ignacio 658 Martinez (IRIS); Julian Onions (X-Tel); Simon Poole (SWITCH); 659 Clive Roberts (Data General); Pete Vanderbilt (SUN); Alan Young 660 (Concurrent). | 662 RFC 1327 has been widely adopted, and a review team was | 663 formed. This comprised of: Urs Eppenberger (SWITCH)(Chair); | 664 Claudio Allocchio (INFN); Harald Alvestrand (UNINETT); Dave | 665 Crocker (Brandenburg); Ned Freed (Innosoft); Erik Huizer | 666 (SURFnet); Steve Kille (ISODE Consortium); Peter Sylvester | 667 (EdelWeb) | 669 Harald Alvestrand also supplied the tables mapping DSN | 670 status codes with X.400 codes. Ned Freed defined parts of the | 671 File Transfer Body Part mapping. | 673 Comment and input has also been received from: Jacqui Caren | 674 (Cray); Kevin Carrosso (Innosoft); Eamon Doyle (Isocor); Jeroun | 675 Houttin (Terena); Carl-Uno Manros (Manros Consulting); Robert | 676 Miles (Softswitch); Tom Oliphant (SWITCH); Mary la Roche | 677 (Citicorp); Eftimios Tsigros (Universite Libre de Bruxelles); | 678 Alan Young (ISODE Consortium); | 680 INTERNET DRAFT 681 MIXER DRAFT Version 2.1 683 Chapter 2 - Service Elements 685 This chapter considers the services offered across a gateway 686 built according to this specification. It gives a view of the 687 functionality provided by such a gateway for communication with 688 users in the opposite domain. This chapter considers service 689 mappings in the context of SINGLE transfers only, and not 690 repeated mappings through multiple gateways. 692 2.1. The Notion of Service Across a Gateway 694 RFC 822 and X.400 provide a number of services to the end user. 695 This chapter describes the extent to which each service can be 696 supported across an X.400 <-> RFC 822 gateway. The cases 697 considered are single transfers across such a gateway, although 698 the problems of multiple crossings are noted where appropriate. 700 2.1.1. Origination of Messages 702 When a user originates a message, a number of services are 703 available. Some of these imply actions (e.g., delivery to a 704 recipient), and some are insertion of known data (e.g., 705 specification of a subject field). This chapter describes, for 706 each offered service, to what extent it is supported for a 707 recipient accessed through a gateway. There are three levels of 708 support: 710 Supported 711 The corresponding protocol elements map well, and so the 712 service can be fully provided. 714 Not Supported 715 The service cannot be provided, as there is a complete 716 mismatch. 718 Partial Support 719 The service can be partially fulfilled. 721 In the first two cases, the service is simply marked as 722 "Supported" or "Not Supported". Some explanation may be given if 723 there are additional implications, or the (non) support is not 724 intuitive. For partial support, the level of partial support is 726 INTERNET DRAFT 727 MIXER DRAFT Version 2.1 729 summarised. Where partial support is good, this will be 730 described by a phrase such as "Supported by use of.....". A 731 common case of this is where the service is mapped onto a non- 732 standard service on the other side of the gateway, and this would 733 have lead to support if it had been a standard service. In many 734 cases, this is equivalent to support. For partial support, an 735 indication of the mechanism is given, in order to give a feel for 736 the level of support provided. Note that this is not a 737 replacement for Chapter 5, where the mapping is fully specified. 739 If a service is described as supported, this implies: 741 - Semantic correspondence. 743 - No (significant) loss of information. 745 - Any actions required by the service element. 747 An example of a service gaining full support: If an RFC 822 748 originator specifies a Subject: field, this is considered to be 749 supported, as an X.400 recipient will get a subject indication. 751 In many cases, the required action will simply be to make the 752 information available to the end user. In other cases, actions 753 may imply generating a delivery report. 755 All RFC 822 services are supported or partially supported 756 for origination. The implications of non-supported X.400 757 services is described under X.400. 759 2.1.2. Reception of Messages 761 For reception, the list of service elements required to support 762 this mapping is specified. This is really an indication of what 763 a recipient might expect to see in a message which has been 764 remotely originated. 766 2.2. RFC 822 768 RFC 822 does not explicitly define service elements, as distinct 769 from protocol elements. However, all of the RFC 822 header 770 fields, with the exception of trace, can be regarded as 771 corresponding to implicit RFC 822 service elements. 773 INTERNET DRAFT 774 MIXER DRAFT Version 2.1 776 2.2.1. Origination in RFC 822 778 A mechanism of mapping, used in several cases, is to map the RFC 779 822 header into a heading extension in the IPM (InterPersonal 780 Message). This can be regarded as partial support, as it makes 781 the information available to any X.400 implementations which are 782 interested in these services. Communities which require 783 significant RFC 822 interworking are recommended to require that 784 their X.400 User Agents are able to display these heading 785 extensions. Support for the various service elements (headers) 786 is now listed. 788 Date: 789 Supported. 791 From: 792 Supported. For messages where there is also a sender field, 793 the mapping is to "Authorising Users Indication", which has 794 subtly different semantics to the general RFC 822 usage of 795 From:. 797 Sender: 798 Supported. 800 Reply-To: 801 Supported. 803 To: Supported. 805 Cc: Supported. 807 Bcc: Supported. 809 Message-Id: 810 Supported. 812 In-Reply-To: 813 Supported, for a single reference. Where multiple 814 references are given, partial support is given by mapping to 815 "Cross Referencing Indication". This gives similar 816 semantics. 818 References: 819 Supported. 821 INTERNET DRAFT 822 MIXER DRAFT Version 2.1 824 Keywords: 825 Supported by use of a heading extension. 827 Subject: 828 Supported. 830 Comments: 831 Supported by use of a heading extension. | 833 Encrypted: 834 Supported by use of a heading extension. 836 Resent-* 837 Supported by use of a heading extension. Note that 838 addresses in these fields are mapped onto text, and so are 839 not accessible to the X.400 user as addresses. In 840 principle, fuller support would be possible by mapping onto 841 a forwarded IP Message, but this is not suggested. 843 Other Fields 844 In particular X-* fields, and "illegal" fields in common 845 usage (e.g., "Fruit-of-the-day:") are supported by use of 846 heading extensions. | 848 MIME introduces the following headings, which are supported as | 849 follows: | 851 Content-Type: | 852 Supported. The definition of MIME Content Type is somewhat | 853 like X.400 Encoded Information Type, but has some aspects | 854 of X.400 Content Type. The mapping is complex, but it will | 855 either be mapped to an equivalent X.400 piece of information | 856 or tunnelled by use of a special extended body part defined | 857 in RFC 1494. | 859 Content-Transfer-Encoding: | 860 Supported. The encoding of the information in X.400 will be | 861 appropriate to the data being transferred. The service is | 862 mapped in an appropriate manner. | 864 Content-ID: | 865 Supported in some cases. Support depend on the body part | 866 and the mapping selected by the gateway. | 868 INTERNET DRAFT 869 MIXER DRAFT Version 2.1 871 Content-Description: | 872 Supported in some cases. Support depend on the body part | 873 and the mapping selected by the gateway. | 875 MIME-Version: | 876 Supported by use of a heading extension. | 878 MIME, like RFC 822, does not explicitly define services. It is | 879 useful in the service section to note support for MIME Content | 880 types that do not map directly to atomic body parts: | 882 multipart/mixed | 883 Supported. | 885 multipart/alternative | 886 Partially supported. No data is lost. The fact that the | 887 body parts are alternatives is indicated in a heading | 888 extension, and there is no guarantee that this can be | 889 interpreted by an X.400 user agent, and by a subject line. | 891 multipart/digest | 892 Supported. | 894 multipart/parallel | 895 Partially supported. Not data is lost. The fact that the | 896 body parts are parallel is indicated in a heading extension, | 897 which may not be interpreted by an X.400 user agent, and by | 898 a subject line. | 900 multipart/unknown | 901 Supported. Unknown semantics are not mapped. | 903 message/rfc822 | 904 Supported. | 906 message/partial | 907 Supported by mapping of message fragments to X.400 messages. | 908 X.400 User Agents will not in general be able to | 909 automatically reassemble fragments. | 911 message/external-body | 912 Supported by incorporating the external body into the X.400 | 913 message. | 915 INTERNET DRAFT 916 MIXER DRAFT Version 2.1 918 message/unknown | 919 Supported. Unknown semantics are not mapped. | 921 otherSupport for the other MIME content types (text, application, | 922 image, audio, video) is defined in RFC 1494. 924 2.2.2. Reception by RFC 822 926 This considers reception by an RFC 822 User Agent of a message 927 originated in an X.400 system and transferred across a gateway. 928 The following standard services (headers) may be present in such 929 a message: 931 Date: 933 From: 935 Sender: 937 Reply-To: 939 To: 941 Cc: 943 Bcc: 945 Message-Id: 947 In-Reply-To: 949 References: 951 Subject: 953 Content-Type: | 955 Content-Transfer-Encoding: | 957 MIME-Version: | 959 INTERNET DRAFT 960 MIXER DRAFT Version 2.1 962 The following non-standard services (headers) may be present in | 963 the header of a message. These are defined in more detail in 964 Chapter 5 (5.3.4, 5.3.6, 5.3.7): 966 Autoforwarded: 968 Autosubmitted: | 970 X400-Content-Identifier: | 972 Content-Language: | 974 Conversion: 976 Conversion-With-Loss: 978 Delivery-Date: 980 Discarded-X400-IPMS-Extensions: 982 Discarded-X400-MTS-Extensions: 984 DL-Expansion-History: 986 Deferred-Delivery: 988 Expiry-Date: 990 Importance: 992 Incomplete-Copy: 994 Latest-Delivery-Time: * 996 Message-Type: 998 Obsoletes: 1000 Original-Encoded-Information-Types: 1002 Originator-Return-Address: 1004 Priority: 1006 INTERNET DRAFT 1007 MIXER DRAFT Version 2.1 1009 Reply-By: 1011 Requested-Delivery-Method: 1013 Sensitivity: 1015 X400-Content-Type: 1017 X400-MTS-Identifier: 1019 X400-Originator: 1021 X400-Received: 1023 X400-Recipients: 1025 2.3. X.400 1027 2.3.1. Origination in X.400 1029 When mapping services from X.400 to RFC 822 which are not 1030 supported by RFC 822, new RFC 822 headers are defined. It is 1031 intended that these fields will be registered, and that co- 1032 operating RFC 822 systems may use them. Where these new fields 1033 are used, and no system action is implied, the service can be 1034 regarded as being partially supported. Chapter 5 describes how 1035 to map X.400 services onto these new headers. Other elements are 1036 provided, in part, by the gateway as they cannot be provided by 1037 RFC 822. 1039 Some service elements are marked N/A (not applicable). 1040 There are five cases, which are marked with different comments: 1042 N/A (local) 1043 These elements are only applicable to User Agent / Message 1044 Transfer Agent interaction and so they cannot apply to RFC 1045 822 recipients. 1047 N/A (PDAU) 1048 These service elements are only applicable where the 1049 recipient is reached by use of a Physical Delivery Access 1050 Unit (PDAU), and so do not need to be mapped by the gateway. 1052 N/A (reception) 1054 INTERNET DRAFT 1055 MIXER DRAFT Version 2.1 1057 These services are only applicable for reception. 1059 N/A (prior) 1060 If requested, this service must be performed prior to the 1061 gateway. 1063 N/A (MS) 1064 These services are only applicable to Message Store (i.e., a 1065 local service). 1067 Finally, some service elements are not supported. In 1068 particular, the new security services are not mapped onto RFC 1069 822. Unless otherwise indicated, the behaviour of service 1070 elements marked as not supported will depend on the criticality 1071 marking supplied by the user. If the element is marked as 1072 critical for transfer or delivery, a non-delivery notification 1073 will be generated. Otherwise, the service request will be 1074 ignored. 1076 2.3.1.1. Basic Interpersonal Messaging Service 1078 These are the mandatory IPM services as listed in Section 19.8 of 1079 X.400 / ISO/IEC 10021-1, listed here in the order given. Section 1080 19.8 has cross references to short definitions of each service. 1082 Access management 1083 N/A (local). 1085 Content Type Indication 1086 Supported by a new RFC 822 header (Content-Type:). 1088 Converted Indication 1089 Supported by a new RFC 822 header (X400-Received:). 1091 Delivery Time Stamp Indication 1092 N/A (reception). 1094 IP Message Identification 1095 Supported. 1097 Message Identification 1098 Supported, by use of a new RFC 822 header 1099 (X400-MTS-Identifier). This new header is required, as 1100 X.400 has two message-ids whereas RFC 822 has only one (see | 1102 INTERNET DRAFT 1103 MIXER DRAFT Version 2.1 1105 IP Message Identification 1107 Non-delivery Notification 1108 Not supported in all cases. Supported where the recipient | 1109 system supports NOTARY DSNs. In general all RFC 822 systems | 1110 will return error reports by use of IP messages. In other 1111 service elements, this pragmatic result can be treated as 1112 effective support of this service element. 1114 Original Encoded Information Types Indication 1115 Supported as a new RFC 822 header 1116 (Original-Encoded-Information-Types:). 1118 Submission Time Stamp Indication 1119 Supported. 1121 Typed Body 1122 The mapping of ForwardedIPMessage and IA5 body parts is | 1123 defined and supported. A framework form mapping other body | 1124 parts, including encapsulation mechanism is defined. | 1125 Mapping of standard body parts and selected other body parts | 1126 is defined in RFC 1494bis. 1128 User Capabilities Registration 1129 N/A (local). 1131 2.3.1.2. IPM Service Optional User Facilities 1133 This section describes support for the optional (user selectable) 1134 IPM services as listed in Section 19.9 of X.400 / ISO/IEC 10021- 1135 1, listed here in the order given. Section 19.9 has cross 1136 references to short definitions of each service. 1138 Additional Physical Rendition 1139 N/A (PDAU). 1141 Alternate Recipient Allowed 1142 Not supported. There is no RFC 822 service equivalent to 1143 prohibition of alternate recipient assignment (e.g., an RFC 1144 822 system may freely send an undeliverable message to a 1145 local postmaster). Thus, the gateway cannot prevent 1146 assignment of alternative recipients on the RFC 822 side. 1147 This service really means giving the user control as to 1148 whether or not an alternate recipient is allowed. This 1150 INTERNET DRAFT 1151 MIXER DRAFT Version 2.1 1153 specification requires transfer of messages to RFC 822 1154 irrespective of this service request, and so this service is 1155 not supported. 1157 Authorising User's Indication 1158 Supported. 1160 Auto-forwarded Indication 1161 Supported as new RFC 822 header (Auto-Forwarded:). 1163 Basic Physical Rendition 1164 N/A (PDAU). 1166 Blind Copy Recipient Indication 1167 Supported. 1169 Body Part Encryption Indication 1170 Supported by use of a new RFC 822 header 1171 (Original-Encoded-Information-Types:), although in most 1172 cases it will not be possible to map the body part in 1173 question. 1175 Content Confidentiality 1176 Not supported. 1178 Content Integrity 1179 Not supported. 1181 Conversion Prohibition 1182 Supported in line with RFC 1494. | 1184 Conversion Prohibition in Case of Loss of Information 1185 Supported in line with RFC 1494. | 1187 Counter Collection 1188 N/A (PDAU). 1190 Counter Collection with Advice 1191 N/A (PDAU). 1193 Cross Referencing Indication 1194 Supported. 1196 Deferred Delivery 1198 INTERNET DRAFT 1199 MIXER DRAFT Version 2.1 1201 N/A (prior). This service should always be provided by the 1202 MTS prior to the gateway. A new RFC 822 header 1203 (Deferred-Delivery:) is provided to transfer information on 1204 this service to the recipient. 1206 Deferred Delivery Cancellation 1207 N/A (local). 1209 Delivery Notification 1210 Supported. This is performed at the gateway, but may be | 1211 performed at the end system if the end system supports | 1212 NOTARY. Thus, a notification is sent by the gateway to the 1213 originator. If the 822-MTS protocol is JNT Mail, a 1214 notification may also be sent by the recipient UA. 1216 Delivery via Bureaufax Service 1217 N/A (PDAU). 1219 Designation of Recipient by Directory Name 1220 N/A (local). 1222 Disclosure of Other Recipients 1223 Supported by use of a new RFC 822 header (X400-Recipients:). 1224 This is descriptive information for the RFC 822 recipient, 1225 and is not reverse mappable. 1227 DL Expansion History Indication 1228 Supported by use of a new RFC 822 header 1229 (DL-Expansion-History:). 1231 DL Expansion Prohibited 1232 Distribution List means MTS supported distribution list, in 1233 the manner of X.400. This service does not exist in the RFC 1234 822 world. RFC 822 distribution lists should be regarded as 1235 an informal redistribution mechanism, beyond the scope of 1236 this control. Messages will be sent to RFC 822, 1237 irrespective of whether this service is requested. 1238 Theoretically therefore, this service is supported, although 1239 in practice it may appear that it is not supported. 1241 Express Mail Service 1242 N/A (PDAU). 1244 Expiry Date Indication 1246 INTERNET DRAFT 1247 MIXER DRAFT Version 2.1 1249 Supported as new RFC 822 header (Expiry-Date:). In general, 1250 no automatic action can be expected. 1252 Explicit Conversion 1253 N/A (prior). 1255 Forwarded IP Message Indication 1256 Supported, with some loss of information. The message is 1257 forwarded in an RFC 822 body, and so can only be interpreted 1258 visually. 1260 Grade of Delivery Selection 1261 N/A (PDAU) 1263 Importance Indication 1264 Supported as new RFC 822 header (Importance:). 1266 Incomplete Copy Indication 1267 Supported as new RFC 822 header (Incomplete-Copy:). 1269 Language Indication 1270 Supported as new RFC 822 header (Language:). 1272 Latest Delivery Designation 1273 Not supported. A new RFC 822 header (Latest-Delivery-Time:) 1274 is provided, which may be used by the recipient. 1276 Message Flow Confidentiality 1277 Not supported. 1279 Message Origin Authentication 1280 N/A (reception). 1282 Message Security Labelling 1283 Not supported. 1285 Message Sequence Integrity 1286 Not supported. 1288 Multi-Destination Delivery 1289 Supported. 1291 Multi-part Body 1292 Supported. | 1294 INTERNET DRAFT 1295 MIXER DRAFT Version 2.1 1297 Non Receipt Notification Request 1298 Not supported. 1300 Non Repudiation of Delivery 1301 Not supported. 1303 Non Repudiation of Origin 1304 N/A (reception). 1306 Non Repudiation of Submission 1307 N/A (local). 1309 Obsoleting Indication 1310 Supported as new RFC 822 header (Obsoletes:). 1312 Ordinary Mail 1313 N/A (PDAU). 1315 Originator Indication 1316 Supported. 1318 Originator Requested Alternate Recipient 1319 Not supported, but is placed as comment next to address 1320 (X400-Recipients:). 1322 Physical Delivery Notification by MHS 1323 N/A (PDAU). 1325 Physical Delivery Notification by PDS 1326 N/A (PDAU). 1328 Physical Forwarding Allowed 1329 Supported by use of a comment in a new RFC 822 header 1330 (X400-Recipients:), associated with the recipient in 1331 question. 1333 Physical Forwarding Prohibited 1334 Supported by use of a comment in a new RFC 822 header 1335 (X400-Recipients:), associated with the recipient in 1336 question. 1338 Prevention of Non-delivery notification 1339 Supported, as delivery notifications cannot be generated by 1340 RFC 822. In practice, errors will be returned as IP 1342 INTERNET DRAFT 1343 MIXER DRAFT Version 2.1 1345 Messages, and so this service may appear not to be supported 1346 (see Non-delivery Notification). 1348 Primary and Copy Recipients Indication 1349 Supported 1351 Probe 1352 Supported at the gateway (i.e., the gateway services the 1353 probe). 1355 Probe Origin Authentication 1356 N/A (reception). 1358 Proof of Delivery 1359 Not supported. 1361 Proof of Submission 1362 N/A (local). 1364 Receipt Notification Request Indication 1365 Not supported. 1367 Redirection Allowed by Originator 1368 Redirection means MTS supported redirection, in the manner 1369 of X.400. This service does not exist in the RFC 822 world. 1370 RFC 822 redirection (e.g., aliasing) should be regarded as 1371 an informal redirection mechanism, beyond the scope of this 1372 control. Messages will be sent to RFC 822, irrespective of 1373 whether this service is requested. Theoretically therefore, 1374 this service is supported, although in practice it may 1375 appear that it is not supported. 1377 Registered Mail 1378 N/A (PDAU). 1380 Registered Mail to Addressee in Person 1381 N/A (PDAU). 1383 Reply Request Indication 1384 Supported as comment next to address. 1386 Replying IP Message Indication 1387 Supported. 1389 INTERNET DRAFT 1390 MIXER DRAFT Version 2.1 1392 Report Origin Authentication 1393 N/A (reception). 1395 Request for Forwarding Address 1396 N/A (PDAU). 1398 Requested Delivery Method 1399 N/A (local). The services required must be dealt with at 1400 submission time. Any such request is made available through 1401 the gateway by use of a comment associated with the 1402 recipient in question. 1404 Return of Content 1405 In principle, this is N/A, as non-delivery notifications are 1406 not supported. In practice, most RFC 822 systems will 1407 return part or all of the content along with the IP Message 1408 indicating an error (see Non-delivery Notification). 1410 Sensitivity Indication 1411 Supported as new RFC 822 header (Sensitivity:). 1413 Special Delivery 1414 N/A (PDAU). 1416 Stored Message Deletion 1417 N/A (MS). 1419 Stored Message Fetching 1420 N/A (MS). 1422 Stored Message Listing 1423 N/A (MS). 1425 Stored Message Summary 1426 N/A (MS). 1428 Subject Indication 1429 Supported. 1431 Undeliverable Mail with Return of Physical Message 1432 N/A (PDAU). 1434 Use of Distribution List 1435 In principle this applies only to X.400 supported 1437 INTERNET DRAFT 1438 MIXER DRAFT Version 2.1 1440 distribution lists (see DL Expansion Prohibited). 1441 Theoretically, this service is N/A (prior). In practice, 1442 because of informal RFC 822 lists, this service can be 1443 regarded as supported. | 1445 Auto-Submitted Indication | 1446 Supported 1448 2.3.2. Reception by X.400 1450 2.3.2.1. Standard Mandatory Services 1452 The following standard IPM mandatory user facilities are 1453 required for reception of RFC 822 originated mail by an X.400 UA. 1455 Content Type Indication 1457 Delivery Time Stamp Indication 1459 IP Message Identification 1461 Message Identification 1463 Non-delivery Notification 1465 Original Encoded Information Types Indication 1467 Submission Time Stamp Indication 1469 Typed Body 1471 2.3.2.2. Standard Optional Services 1473 The following standard IPM optional user facilities are required 1474 for reception of RFC 822 originated mail by an X.400 UA. 1476 Authorising User's Indication 1478 Blind Copy Recipient Indication 1480 Cross Referencing Indication 1482 Originator Indication 1484 INTERNET DRAFT 1485 MIXER DRAFT Version 2.1 1487 Primary and Copy Recipients Indication 1489 Replying IP Message Indication 1491 Subject Indication 1493 2.3.2.3. New Services 1495 A new service "RFC 822 Header Field" is defined using the 1496 extension facilities. This allows for any RFC 822 header field 1497 to be represented. It may be present in RFC 822 originated 1498 messages, which are received by an X.400 UA. 1500 INTERNET DRAFT 1501 MIXER DRAFT Version 2.1 1503 Chapter 3 Basic Mappings 1505 3.1. Notation 1507 The X.400 protocols are encoded in a structured manner according 1508 to ASN.1, whereas RFC 822 is text encoded. To define a detailed 1509 mapping, it is necessary to refer to detailed protocol elements 1510 in each format. A notation to achieve this is described in this 1511 section. 1513 3.1.1. RFC 822 1515 Structured text is defined according to the Extended Backus Naur 1516 Form (EBNF) defined in Section 2 of RFC 822 [21]. In the EBNF 1517 definitions used in this specification, the syntax rules given in 1518 Appendix D of RFC 822 are assumed. When these EBNF tokens are 1519 referred to outside an EBNF definition, they are identified by 1520 the string "822." appended to the beginning of the string (e.g., 1521 822.addr-spec). Additional syntax rules, to be used throughout 1522 this specification, are defined in this chapter. 1524 The EBNF is used in two ways. 1526 1. To describe components of RFC 822 messages (or of 822-MTS 1527 components). When these new EBNF tokens are referred to * 1528 outside an EBNF definition, they are identified by the 1529 string "EBNF." appended to the beginning of the string 1530 (e.g., EBNF.importance). 1532 2. To describe the structure of IA5 or ASCII information not in 1533 an RFC 822 message. | 1535 For all new EBNF, tokens will either be self delimiting, or be 1536 delimited by self delimiting tokens. Comments and LWSP are not 1537 used as delimiters, except for the following cases, where LWSP 1538 may be inserted according to RFC 822 rules. | 1540 - Around the ":" in all headers 1542 - EBNF.labelled-integer 1544 INTERNET DRAFT 1545 MIXER DRAFT Version 2.1 1547 - EBNF.object-identifier 1549 - EBNF.encoded-info | 1551 RFC 822 folding rules are applied to all headers. Comments are | 1552 never used in these new headers. | 1554 This notation is used in a modified form to refer to NOTARY | 1555 ENBF [33]. For this EBNF, the keyword EBNF is replaces with DSN, | 1556 for example DSN.final-recipient-field fields. 1558 3.1.2. ASN.1 1560 An element is referred to with the following syntax, defined in 1561 EBNF: 1563 element = service "." definition *( "." definition ) 1564 service = "IPMS" / "MTS" / "MTA" 1565 definition = identifier / context 1566 identifier = ALPHA *< ALPHA or DIGIT or "-" > 1567 context = "[" 1*DIGIT "]" 1569 The EBNF.service keys are shorthand for the following service 1570 specifications: 1572 IPMS IPMSInformationObjects defined in Annex E of X.420 / ISO 1573 10021-7. 1575 MTS MTSAbstractService defined in Section 9 of X.411 / ISO 1576 10021-4. 1578 MTA MTAAbstractService defined in Section 13 of X.411 / ISO 1579 10021-4. | 1581 FTBP File Transfer Body Part, as defined in [32]. LP The first 1582 EBNF.identifier identifies a type or value key in the 1583 context of the defined service specification. Subsequent 1584 EBNF.identifiers identify a value label or type in the 1585 context of the first identifier (SET or SEQUENCE). 1586 EBNF.context indicates a context tag, and is used where 1587 there is no label or type to uniquely identify a component. 1588 The special EBNF.identifier keyword "value" is used to 1589 denote an element of a sequence. 1591 INTERNET DRAFT 1592 MIXER DRAFT Version 2.1 1594 For example, IPMS.Heading.subject defines the subject element of 1595 the IPMS heading. The same syntax is also used to refer to 1596 element values. For example, 1597 MTS.EncodedInformationTypes.[0].g3Fax refers to a value of 1598 MTS.EncodedInformationTypes.[0] . 1600 3.2. ASCII and IA5 1602 A gateway will interpret all IA5 as ASCII. Thus, mapping between 1603 these forms is conceptual. 1605 3.3. Standard Types 1607 There is a need to convert between ASCII text, and some of the 1608 types defined in ASN.1 [18]. For each case, an EBNF syntax 1609 definition is given, for use in all of this specification, which 1610 leads to a mapping between ASN.1, and an EBNF construct. All 1611 EBNF syntax definitions of ASN.1 types are in lower case, whereas 1612 ASN.1 types are referred to with the first letter in upper case. 1613 Except as noted, all mappings are symmetrical. 1615 3.3.1. Boolean 1617 Boolean is encoded as: 1619 boolean = "TRUE" / "FALSE" 1621 3.3.2. NumericString 1623 NumericString is encoded as: 1625 numericstring = *DIGIT 1627 3.3.3. PrintableString 1629 PrintableString is a restricted IA5String defined as: 1631 printablestring = *( ps-char ) 1632 ps-restricted-char = 1DIGIT / 1ALPHA / " " / "'" / "+" 1633 / "," / "-" / "." / "/" / ":" / "=" / "?" 1634 ps-delim = "(" / ")" 1635 ps-char = ps-delim / ps-restricted-char 1637 INTERNET DRAFT 1638 MIXER DRAFT Version 2.1 1640 This can be used to represent real printable strings in EBNF. 1642 3.3.4. T.61String 1644 In cases where T.61 strings are only used for conveying human 1645 interpreted information, the aim of a mapping is to render the 1646 characters appropriately in the remote character set, rather than 1647 to maximise reversibility. For these cases, there are two | 1648 options, both of which are conformant to this specification: | 1650 1. The mappings to IA5 defined in ITU Recommendation X.408 | 1651 (1988) may be used . These will then be encoded in ASCII. | 1652 This is the approach mandated in RFC 1327. | 1654 2. This mapping may be used if the characters are not contained | 1655 within ASCII repertoire, but are all in an IANA-registered | 1656 character set. Use the encoding defined in RFC 1522 [14]. | 1657 to generate appropriate encoded-words. | 1659 Editor's | 1660 T.61 is an IANA registered set and could be specified here. | 1661 It has been suggested that ISO 8859-1 should be preferred. | 1662 MIXER could allow options or mandate. Input is solicited. | 1663 Default approach will be to allow use of any character set. 1665 There is also a need to represent Teletex Strings in ASCII, 1666 for some aspects of O/R Address. For these, the following 1667 encoding is used: 1669 teletex-string = *( ps-char / t61-encoded ) 1670 t61-encoded = "{" 1* t61-encoded-char "}" 1671 t61-encoded-char = 3DIGIT 1673 Common characters are mapped simply. Other octets, including | 1674 control characters, are mapped using a quoting mechanism similar 1675 to the printable string mechanism. Each octet is represented as 1676 3 decimal digits. 1678 There are a number of places where a string may have a Teletex 1679 and/or Printable String representation. The following BNF is 1680 used to represent this. 1682 teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ] 1684 INTERNET DRAFT 1685 MIXER DRAFT Version 2.1 1687 The natural mapping is restricted to EBNF.ps-char, in order to 1688 make the full BNF easier to parse. 1690 3.3.5. UTCTime 1692 Both UTCTime and the RFC 822 822.date-time syntax contain: Year 1693 (lowest two digits), Month, Day of Month, hour, minute, second 1694 (optional), and Timezone. 822.date-time also contains an 1695 optional day of the week, but this is redundant. Therefore a 1696 symmetrical mapping can be made between these constructs. 1698 Note: 1699 In practice, a gateway will need to parse various illegal 1700 variants on 822.date-time. In cases where 822.date-time 1701 cannot be parsed, it is recommended that the derived UTCTime 1702 is set to the value at the time of translation. 1704 When mapping to X.400, the UTCTime format which specifies the 1705 timezone offset shall be used. 1707 When mapping to RFC 822, the 822.date-time format shall include a 1708 numeric timezone offset (e.g., +0000). 1710 When mapping time values, the timezone shall be preserved as 1711 specified. The date shall not be normalised to any other 1712 timezone. 1714 3.3.6. Integer 1716 A basic ASN.1 Integer will be mapped onto EBNF.numericstring. In 1717 many cases ASN.1 will enumerate Integer values or use ENUMERATED. 1718 An EBNF encoding labelled-integer is provided. When mapping from 1719 EBNF to ASN.1, only the integer value is mapped, and the 1720 associated text is discarded. When mapping from ASN.1 to EBNF, 1721 addition of an appropriate text label is strongly encouraged. 1723 labelled-integer ::= [ key-string ] "(" numericstring ")" 1725 key-string = *key-char 1726 key-char = 1728 INTERNET DRAFT 1729 MIXER DRAFT Version 2.1 1731 3.3.7. Object Identifier 1733 Object identifiers are represented in a form similar to that 1734 given in ASN.1. The order is the same as for ASN.1 (big-endian). 1735 The numbers are mandatory, and used when mapping from the ASCII 1736 to ASN.1. The key-strings are optional. It is recommended that 1737 as many strings as possible are generated when mapping from ASN.1 1738 to ASCII, to facilitate user recognition. 1740 object-identifier ::= oid-comp object-identifier 1741 | oid-comp 1743 oid-comp ::= [ key-string ] "(" numericstring ")" 1745 An example representation of an object identifier is: 1747 joint-iso-ccitt(2) mhs (6) ipms (1) ep (11) ia5-text (0) 1749 or 1751 (2) (6) (1)(11)(0) 1753 3.4. Encoding ASCII in Printable String 1755 Some information in RFC 822 is represented in ASCII, and needs to 1756 be mapped into X.400 elements encoded as printable string. For 1757 this reason, a mechanism to represent ASCII encoded as 1758 PrintableString is needed. 1760 A structured subset of EBNF.printablestring is now defined. 1761 This shall be used to encode ASCII in the PrintableString 1762 character set. 1764 ps-encoded = *( ps-restricted-char / ps-encoded-char ) 1765 ps-encoded-char = "(a)" ; (@) 1766 / "(p)" ; (%) 1767 / "(b)" ; (!) 1768 / "(q)" ; (") 1769 / "(u)" ; (_) 1770 / "(l)" ; "(" 1771 / "(r)" ; ")" 1772 / "(" 3DIGIT ")" 1774 INTERNET DRAFT 1775 MIXER DRAFT Version 2.1 1777 The 822.3DIGIT in EBNF.ps-encoded-char must have range 0-127, and 1778 is interpreted in decimal as the corresponding ASCII character. 1779 Special encodings are given for: at sign (@), percent (%), 1780 exclamation mark/bang (!), double quote ("), underscore (_), left 1781 bracket ((), and right bracket ()). These characters, with the 1782 exception of round brackets, are not included in PrintableString, 1783 but are common in RFC 822 addresses. The abbreviations will ease 1784 specification of RFC 822 addresses from an X.400 system. These 1785 special encodings shall be interpreted in a case insensitive 1786 manner, but always generated in lower case. 1788 A reversible mapping between PrintableString and ASCII can 1789 now be defined. The reversibility means that some values of 1790 printable string (containing round braces) cannot be generated 1791 from ASCII. Therefore, this mapping must only be used in cases 1792 where the printable strings may only be derived from ASCII (and 1793 will therefore have a restricted domain). For example, in this 1794 specification, it is only applied to a Domain Defined Attribute 1795 which will have been generated by use of this specification and a 1796 value such as "(" would not be possible. 1798 To encode ASCII as PrintableString, the EBNF.ps-encoded 1799 syntax is used, with all EBNF.ps-restricted-char mapped directly. 1800 All other 822.CHAR are encoded as EBNF.ps-encoded-char. 1802 To encode PrintableString as ASCII, parse PrintableString as 1803 EBNF.ps-encoded, and then reverse the previous mapping. If the 1804 PrintableString cannot be parsed, then the mapping is being 1805 applied in to an inappropriate value, and an error shall be given 1806 to the procedure doing the mapping. In some cases, it may be 1807 preferable to pass the printable string through unaltered. 1809 Some examples are now given. Note the arrows which indicate 1810 asymmetrical mappings: 1812 PrintableString ASCII 1814 'a demo.' <-> 'a demo.' 1815 foo(a)bar <-> foo@bar 1816 (q)(u)(p)(q) <-> "_%" 1817 (a) <-> @ 1818 (A) -> @ 1819 (l)a(r) <-> (a) 1820 (126) <-> ~ 1822 INTERNET DRAFT 1823 MIXER DRAFT Version 2.1 1825 ( -> ( 1826 (l) <-> ( 1828 3.5. RFC 1522 | 1830 RFC 1522 defines a mechanism for encoding other character set | 1831 information into elements of RFC 822 Headers. A gateway may | 1832 ignore this encoding and treat the elements as ASCII. | 1834 A preferred approach is for the gateway to interpret the RFC | 1835 1522 encoding. This will not always be straightforward, because: | 1837 1. RFC 1522 permits an openly extensible character set choice, | 1838 which may be broader than T.61. | 1840 2. It may not be possible to map all characters into the | 1841 equivalent X.400 field. | 1843 RFC 1522 is only applied to fields which are "for information | 1844 only". A gateway which interprets header elements according to | 1845 RFC 1522 may apply reasonable heuristics to minimise information | 1846 loss. 1848 INTERNET DRAFT 1849 MIXER DRAFT Version 2.1 1851 Chapter 4 - Addressing and Message IDs | 1853 Addressing is the most complex aspect of X.400 <-> RFC 822 | 1854 gateway and is therefore given a separate chapter. This chapter | 1855 also discusses message identifiers, as they are closely linked to | 1856 addresses. This chapter, as a side effect, also defines a 1857 textual representation of an X.400 O/R Address. This | 1858 specification has much similarity to the X.400(92) representation | 1859 of addresses. This was because early versions of this | 1860 specification were a major input to this work. This | 1861 specification retains compatibility with earlier versions. There | 1862 is optional compatibility with the X.400 specification. 1864 Initially we consider an address in the (human) mail user 1865 sense of "what is typed at the mailsystem to reference a mail 1866 user". A basic RFC 822 address is defined by the EBNF 1867 EBNF.822-address: 1869 822-address = [ route ] addr-spec 1871 In an 822-MTS protocol, the originator and each recipient are 1872 considered to be defined by such a construct. In an RFC 822 1873 header, the EBNF.822-address is encapsulated in the 822.address 1874 syntax rule, and there may also be associated comments. None of 1875 this extra information has any semantics, other than to the end 1876 user. 1878 The basic X.400 O/R Address, used by the MTS for routing, is 1879 defined by MTS.ORAddress. In IPMS, the MTS.ORAddress is 1880 encapsulated within IPMS.ORDescriptor. 1882 It can be seen that RFC 822 822.address must be mapped with 1883 IPMS.ORDescriptor, and that RFC 822 EBNF.822-address must be 1884 mapped with MTS.ORAddress. | 1886 Section 4.1 defines a textual representation of an O/R | 1887 Address, which is used throughout the rest of this specification. | 1888 This text representation is designed to represent an X.400 | 1889 address in the LHS (local part) of an RFC 822 address, and so | 1890 this representation gives a mechanism to represent X.400 | 1891 addresses withing RFC 822 addresses. | 1893 Section 4.2 describes a global equivalence mapping between | 1895 INTERNET DRAFT 1896 MIXER DRAFT Version 2.1 1898 parts of the X.400 and RFC 822 name spaces, which gateways | 1899 conforming to this specification must support. | 1901 Section 4.3 is the core part of this chapter, and defines | 1902 the mapping mechanism. 1904 4.1. A textual representation of MTS.ORAddress 1906 MTS.ORAddress is structured as a set of attribute value pairs. 1907 It is clearly necessary to be able to encode this in ASCII for 1908 gatewaying purposes. All components shall be encoded, in order 1909 to guarantee return of error messages, and to optimise third 1910 party replies. | 1912 4.1.1. Basic O/R Address Representation 1914 An O/R Address has a number of structured and unstructured 1915 attributes. For each unstructured attribute, a key and an 1916 encoding is specified. For structured attributes, the X.400 1917 attribute is mapped onto one or more attribute value pairs. For 1918 domain defined attributes, each element of the sequence will be 1919 mapped onto a triple (key and two values), with each value having 1920 the same encoding. The attributes are as follows, with 1984 1921 attributes given in the first part of the table. For each 1922 attribute, a reference is given, consisting of the relevant 1923 sections in X.402 / ISO 10021-2, and the extension identifier for 1924 88 only attributes: 1926 Attribute (Component) Key Enc Ref Id 1928 84/88 Attributes 1930 MTS.CountryName C P 18.3.3 1931 MTS.AdministrationDomainName ADMD P 18.3.1 1932 MTS.PrivateDomainName PRMD P 18.3.21 1933 MTS.NetworkAddress X121 N 18.3.7 1934 MTS.TerminalIdentifier T-ID P 18.3.23 1935 MTS.OrganizationName O P/T 18.3.9 1936 MTS.OrganizationalUnitNames.value OU P/T 18.3.10 1937 MTS.NumericUserIdentifier UA-ID N 18.3.8 1938 MTS.PersonalName PN P/T 18.3.12 1939 MTS.PersonalName.surname S P/T 18.3.12 1940 MTS.PersonalName.given-name G P/T 18.3.12 1941 INTERNET DRAFT 1942 MIXER DRAFT Version 2.1 1944 MTS.PersonalName.initials I P/T 18.3.12 1945 MTS.PersonalName 1946 .generation-qualifier GQ P/T 18.3.12 1947 MTS.DomainDefinedAttribute.value DD P/T 18.1 1949 88 Attributes 1951 MTS.CommonName CN P/T 18.3.2 1 1952 MTS.TeletexCommonName CN P/T 18.3.2 2 1953 MTS.TeletexOrganizationName O P/T 18.3.9 3 1954 MTS.TeletexPersonalName PN P/T 18.3.12 4 1955 MTS.TeletexPersonalName.surname S P/T 18.3.12 4 1956 MTS.TeletexPersonalName.given-name G P/T 18.3.12 4 1957 MTS.TeletexPersonalName.initials I P/T 18.3.12 4 1958 MTS.TeletexPersonalName 1959 .generation-qualifier GQ P/T 18.3.12 4 1960 MTS.TeletexOrganizationalUnitNames 1961 .value OU P/T 18.3.10 5 1962 MTS.TeletexDomainDefinedAttribute 1963 .value DD P/T 18.1 6 1964 MTS.PDSName PD-SERVICE P 18.3.11 7 1965 MTS.PhysicalDeliveryCountryName PD-C P 18.3.13 8 1966 MTS.PostalCode PD-CODE P 18.3.19 9 1967 MTS.PhysicalDeliveryOfficeName PD-OFFICE P/T 18.3.14 10 1968 MTS.PhysicalDeliveryOfficeNumber PD-OFFICE-NUM P/T 18.3.15 11 1969 MTS.ExtensionORAddressComponents PD-EXT-ADDRESS P/T 18.3.4 12 1970 MTS.PhysicalDeliveryPersonName PD-PN P/T 18.3.17 13 1971 MTS.PhysicalDeliveryOrganizationName PD-O P/T 18.3.16 14 1972 MTS.ExtensionPhysicalDelivery 1973 AddressComponents PD-EXT-DELIVERY P/T 18.3.5 15 1974 MTS.UnformattedPostalAddress PD-ADDRESS P/T 18.3.25 16 1975 MTS.StreetAddress PD-STREET P/T 18.3.22 17 1976 MTS.PostOfficeBoxAddress PD-BOX P/T 18.3.18 18 1977 MTS.PosteRestanteAddress PD-RESTANTE P/T 18.3.20 19 1978 MTS.UniquePostalName PD-UNIQUE P/T 18.3.26 20 1979 MTS.LocalPostalAttributes PD-LOCAL P/T 18.3.6 21 1980 MTS.ExtendedNetworkAddress 1981 .e163-4-address.number NET-NUM N 18.3.7 22 1982 MTS.ExtendedNetworkAddress 1983 .e163-4-address.sub-address NET-SUB N 18.3.7 22 1984 MTS.ExtendedNetworkAddress 1985 .psap-address NET-PSAP X 18.3.7 22 1986 MTS.TerminalType T-TY I 18.3.24 23 1987 INTERNET DRAFT 1988 MIXER DRAFT Version 2.1 1990 The following keys identify different EBNF encodings, which are 1991 associated with the ASCII representation of MTS.ORAddress. 1993 Key Encoding 1995 P printablestring 1996 N numericstring 1997 T teletex-string 1998 P/T teletex-and-or-ps 1999 I labelled-integer 2000 X presentation-address 2002 The BNF for presentation-address is taken from the specification | 2003 RFC 1278 "A String Encoding of Presentation Address" [4]. 2005 In most cases, the EBNF encoding maps directly to the ASN.1 2006 encoding of the attribute. There are a few exceptions. In cases 2007 where an attribute can be encoded as either a PrintableString or 2008 NumericString (Country, ADMD, PRMD), either form is mapped into 2009 the BNF. When generating ASN.1, the NumericString encoding shall 2010 be used if the string contains only digits. 2012 There are a number of cases where the P/T (teletex-and-or-ps) 2013 representation is used. Where the key maps to a single 2014 attribute, this choice is reflected in the encoding of the 2015 attribute (attributes 10-21). For most of the 1984 attributes 2016 and common name, there is a printablestring and a teletex 2017 variant. This pair of attributes is mapped onto the single 2018 component here. This will give a clean mapping for the common 2019 cases where only one form of the name is used. 2021 X.400 (1992) has introduced as string representation of O/R | 2022 Addresses. This has specified a number of string keywords for 2023 attributes. As earlier version of this specification were an | 2024 input to this work, many of the keywords are the same. To | 2025 increase compatibility, the following alternative values shall be 2026 recognised when mapping from RFC 822 to X.400. These shall not 2027 be generated when mapping from X.400 to RFC 822. 2029 Keyword Alternative 2031 ADMD A 2032 PRMD P 2033 GQ Q 2035 INTERNET DRAFT 2036 MIXER DRAFT Version 2.1 2038 X121 X.121 2039 UA-ID N-ID 2040 PD-OFFICE-NUM PD-OFFICE NUMBER | 2041 PD-OFFICE-NUM PD-OFN | 2042 PD-EXT-ADDRESS PD-EA | 2043 PD-EXT-DELIVERY PD-ED | 2044 PD-OFFICE PD-OF | 2045 PD-STREET PD-S | 2046 PD-UNIQUE PD-U | 2047 PD-LOCAL PD-L | 2048 PD-RESTANTE PD-R | 2049 PD-BOX PD-B | 2050 PD-CODE PD-PC | 2051 PD-SERVICE PD-SN | 2052 DD DDA | 2054 When mapping from RFC 822 to X.400, the keywords: OU1, OU2, OU3, 2055 and OU4, shall be recognised. If these are present, no keyword | 2056 OU shall be present. These will be treated as ordered values of | 2057 OU. PD-A1, PD-A2, PD-A3, PD-A4, PD-A5, PD-A6 shall be treated as | 2058 ordered lines. If present, these will be assembled with | 2059 separating line feeds to form a single physical address. In this | 2060 case PD-ADDRESS shall not be present. | 2062 If ISDN is present, is may be interpreted as an E.163/164 | 2063 address, using local heuristics to parse the string. X.400 | 2064 defines the key, but does not give an interpretation of the | 2065 value. | 2067 For T-TY, the X.400 recommended values are preferred, but | 2068 other values are allowed. These values are: tlx; ttx; g3fax; | 2069 g4fax; ia5; and vtx. 2071 4.1.2. Encoding of Personal Name 2073 Handling of Personal Name and Teletex Personal Name based purely 2074 on the EBNF.standard-type syntax defined above is likely to be 2075 clumsy. It seems desirable to utilise the "human" conventions 2076 for encoding these components. A syntax is defined, which is 2077 designed to provide a clean encoding for the common cases of O/R 2078 Address specification where: 2080 1. There is no generational qualifier 2082 INTERNET DRAFT 2083 MIXER DRAFT Version 2.1 2085 2. Initials, if present, contain only letters | 2087 3. Given Name, if present, does not contain full stop ("."), | 2088 and is at least two characters long. 2090 4. Surname does not contain full stop in the first two 2091 characters. 2093 5 If Surname is the only component, it does not contain full 2094 stop. 2096 The following EBNF is defined: 2098 encoded-pn = [ given "." ] *( initial "." ) surname 2100 given = 2* 2102 initial = ALPHA 2104 surname = printablestring 2106 This is used to map from any string containing only printable 2107 string characters to an O/R address personal name. To map from a 2108 string to O/R Address components, parse the string according to 2109 the EBNF. The given name and surname are assigned directly. All 2110 EBNF.initial tokens are concatenated without intervening full 2111 stops to generate the initials component. 2113 For an O/R address which follows the above restrictions, a 2114 string is derived in the natural manner. In this case, the 2116 INTERNET DRAFT 2117 MIXER DRAFT Version 2.1 2119 mapping will be reversible. 2121 For example: 2123 GivenName = "Marshall" 2124 Surname = "Rose" 2126 Maps with "Marshall.Rose" 2128 Initials = "MT" 2129 Surname = "Rose" 2131 Maps with "M.T.Rose" 2133 GivenName = "Marshall" 2134 Initials = "MT" 2135 Surname = "Rose" 2137 Maps with "Marshall.M.T.Rose" 2139 Note that X.400 suggest that Initials is used to encode ALL 2140 initials. Therefore, the defined encoding is "natural" when 2141 either GivenName or Initials, but not both, are present. The 2142 case where both are present can be encoded, but this appears to 2143 be contrived! 2145 4.1.3. Standard Encoding of MTS.ORAddress 2147 Given this structure, we can specify a BNF representation of an 2148 O/R Address. 2150 INTERNET DRAFT 2151 MIXER DRAFT Version 2.1 2153 std-or-address = 1*( "/" attribute "=" value ) "/" 2154 attribute = standard-type 2155 / "RFC-822" 2156 / registered-dd-type 2157 / dd-key "." std-printablestring 2158 standard-type = key-string 2160 registered-dd-type 2161 = key-string 2162 dd-key = key-string 2164 value = std-printablestring 2166 std-printablestring 2167 = *( std-char / std-pair ) 2168 std-char = <"{", "}", "*", and any ps-char 2169 except "/" and "="> 2170 std-pair = "$" ps-char 2172 The standard-type is any key defined in the table in Section 4.2, 2173 except PN, and DD. The BNF leads to a set of attribute/value 2174 pairs. The value is interpreted according to the EBNF encoding 2175 defined in the table. 2177 If the standard-type is PN, the value is interpreted 2178 according to EBNF.encoded-pn, and the components of 2179 MTS.PersonalName and/or MTS.TeletexPersonalName derived 2180 accordingly. 2182 If dd-key is the recognised Domain Defined string (DD), then 2183 the type and value are interpreted according to the syntax 2184 implied from the encoding, and aligned to either the teletex or 2185 printable string form. Key and value shall have the same 2186 encoding. 2188 If value is "RFC-822", then the (printable string) Domain 2189 Defined Type of "RFC-822" is assumed. This is an optimised 2190 encoding of the domain defined type defined by this 2191 specification. 2193 The matching of all keywords shall be done in a case- 2194 independent manner. 2196 INTERNET DRAFT 2197 MIXER DRAFT Version 2.1 2199 EBNF.std-or-address uses the characters "/" and "=" as 2200 delimiters. Domain Defined Attributes and any value may contain 2201 these characters. A quoting mechanism, using the non-printable 2202 string "$" is used to allow these characters to be represented. 2204 If the value is registered-dd-type, and the value is 2205 registered at the Internet Assigned Numbers Authority (IANA) as 2206 an accepted Domain Defined Attribute type, then the value shall 2207 be interpreted accordingly. This restriction maximises the 2208 syntax checking which can be done at a gateway. 2210 4.2. | 2211 Global Address Mapping 2213 From a user perspective, the ideal mapping would be entirely | 2214 symmetrical and global, to enable addresses to be referred to 2215 transparently in the remote system, with the choice of gateway 2216 being left to the Message Transfer Service. There are two 2217 fundamental reasons why this is not possible: 2219 1. The syntaxes are sufficiently different to make this | 2220 impossible. | 2222 2 There is insufficient administrative co-operation between 2223 the X.400 and RFC 822 name registration authorities for this | 2224 to work. 2226 Another way to view this situation is to see that there is not a | 2227 full global equivalence between X.400 and RFC 822 addressing. To | 2228 meet user needs to the extent possible, this specification | 2229 provides for equivalence where there is sufficient co-operation. | 2230 To be useful, this equivalence must be recognised and interpreted | 2231 in the same way by all gateways. Therefore, an asymmetrical 2232 mapping is defined, which can be symmetrical where there is | 2233 appropriate administrative co-operation. Section 4.3 describes | 2234 consider the asymetrical aspects. This section describes how | 2235 the administrative co-ordination for symmetrical mappings is | 2236 achieved. | 2238 In order to achieve a symmetrical mapping which is supported | 2239 by all gateways which conform to this specification, there is a | 2240 need to define an administrative equivalence between parts of the | 2241 O/R Address and Domain namespaces. This information is defined | 2242 globally, and must be used by any gateway which conforms to this | 2244 INTERNET DRAFT 2245 MIXER DRAFT Version 2.1 2247 specification. Currently, three ways are defined to access this | 2248 mapping information. | 2250 1. Distribution of text tables. This is described in Appendix | 2251 F of this specification. | 2253 2. Distribution by Domain Name Service. This is described in | 2254 RFC 1664 [9]. | 2256 3. Distribution by X.500 Directory Service. This is defined | 2257 in RFC tbs [31]. | 2259 The following sections define how the namespace equivalence | 2260 is modelled. The Internet Domain Namespace defines a simple | 2261 hierarchy. For the purposes of this mapping, only parts of the | 2262 namespace where domains conform to the EBNF domain-syntax are | 2263 allowed. | 2265 domain-syntax = alphanum [ *alphanumhyphen alphanum ] 2266 alphanum = 2267 alphanumhyphen = 2269 Although RFC 822 allows for a more general syntax, this | 2270 restricted syntax is chosen as it is the one chosen by the | 2271 various domain service administrations. In practice, it reflects | 2272 all RFC 822 usage. | 2274 The following O/R Address attributes are considered as a | 2275 hierarchy, and may be specified by the domain. They are (in | 2276 order of the hierarchy defined by MIXER): | 2278 Country, ADMD, PRMD, Organization, Organizational Unit 2280 There may be multiple Organizational Units. This hierarchy | 2281 reflects most usage of X.400, although X.400 may be used in other | 2282 ways. In particular, it covers the Mnemonic O/R Address using a | 2283 1984 compatible encoding. This is seen as the dominant form of | 2284 O/R Address. MIXER equivalence mappings may only be used when | 2285 this hierarchy applies. | 2287 An equivalence mapping is defined between two nodes in the | 2288 respective hierarchies. For example: | 2290 INTERNET DRAFT 2291 MIXER DRAFT Version 2.1 2293 => "AC.UK" might be mapped with 2294 C="GB", ADMD="GOLD 400", PRMD="UK.AC" 2296 The mapping identifies that the management of these points in the | 2297 respective hierarchies is the same (or co-operate very closely). | 2298 The equivalence means that the namespaces below this equivalence | 2299 point map 1:1, except where the mapping is overridden by further | 2300 equivalence mappings lower down the hierarchy. This equivalence | 2301 may be achieved in three ways: | 2303 1. All of the nodes below this point are RFC 822, and the MIXER | 2304 mapping defines the X.400 addresses for these nodes. | 2306 2. All of the nodes below this point are X.400, and the MIXER | 2307 mapping defines the RFC 822 addresses for these nodes. | 2309 3. There are X.400 and RFC 822 nodes below this point, and | 2310 addressing is managed in a manner which ensures the | 2311 equivalence. The rules to achieve this are defined by | 2312 MIXER. | 2314 A set of global mappings to enable a clean transformation between | 2315 the X.400 and RFC 822 namespaces is therefore defined by | 2316 deployment of MIXER. | 2318 When an equivalence point is defined, a systematic mapping | 2319 for the the inferior nodes in the two hierarchies follows. This | 2320 is a 1:1 the mapping between the nodes in the subtrees. For | 2321 example, given the the equivalence defined above: | 2323 the domain "R-D.Salford.AC.UK" algorithmically maps with 2324 C="GB", ADMD="GOLD 400", PRMD="UK.AC", O="Salford", OU="R-D" 2326 Note that when an equivalence is defined, that this can be re- | 2327 defined for lower points in the hierarchy. However, it is not | 2328 possible to declare contained subtrees to be un-mappable. | 2330 The equivalence mapping also provides a mechanism to deal | 2331 with missing elements in the X.400 hierarchy (Most commonly the | 2332 PRMD). A domain may be associated with an omitted attribute in | 2333 conjunction with several present ones. When performing the | 2334 algorithmic insertion of components lower in the hierarchy, the | 2336 INTERNET DRAFT 2337 MIXER DRAFT Version 2.1 2339 omitted value shall be skipped. For example: | 2341 If the domain HNE.EGM" is mapped with 2342 "C=TC", "ADMD=ECQ", "PRMD=HNE", and omitted organization 2344 then | 2346 "ZI.HNE.EGM" is algorithmically mapped with 2347 "C=TC", "ADMD=ECQ", "PRMD=HNE", "OU=ZI" 2349 Attributes may have null values, and this is treated separately | 2350 from omitted attributes (while it is not ideal | 2351 to make this distinction, it is useful in practice). 2353 4.2.1. Dynamic Mappings | 2355 When the global mapping is supported by X.500 or DNS, there is | 2356 the possibility that results will be indeterminate due to | 2357 timeout. Lookup should be repeated until a value is determined, | 2358 in order to maintain a correct and consistent global mapping. | 2360 Editor's | 2361 This text is a place-holder, pending discussion. | 2363 4.3. EBNF.822-address <-> MTS.ORAddress | 2365 This section defines the basic address mapping. | 2367 4.3.1. X.400 encoded in RFC 822 2369 This section defines how X.400 addresses are represented in RFC | 2370 822 the addresses. | 2372 The std-or-address syntax is used to encode O/R Address 2373 information in the 822.local-part of EBNF.822-address. Where | 2374 there is an applicable equivalence mapping, further O/R Address 2375 information is associated with the 822.domain component. This 2376 cannot be used in the general case, due to character set 2377 problems, and to the variants of X.400 O/R Addresses which use 2378 different attribute types. The only way to encode the full 2379 PrintableString character set in a domain is by use of the 2380 822.domain-ref syntax (i.e. 822.atom). This is likely to cause 2381 problems on many systems. The effective character set of domains 2382 is in practice reduced from the RFC 822 set, by restrictions 2384 INTERNET DRAFT 2385 MIXER DRAFT Version 2.1 2387 imposed by domain conventions and policy, and by restrictions in 2388 RFC 821. 2390 A generic 822.address consists of a 822.local-part and a 2391 sequence of 822.domains (e.g., <@domain1,@domain2:user@domain3>). 2392 All except the 822.domain associated with the 822.local-part 2393 (domain3 in this case) are considered to specify routing within 2394 the RFC 822 world, and will not be interpreted by the gateway 2395 (although they may have identified the gateway from within the 2396 RFC 822 world). 2398 The 822.domain associated with the 822.local-part 2399 identifies the gateway from within the RFC 822 world. This final 2400 822.domain may be used to determine some number of O/R Address 2401 attributes, where this does not conflict with the first role. 2402 RFC 822 routing to gateways will usually be set up to facilitate 2403 the 822.domain being used for both purposes. * 2405 In the case that there is no applicable equivalence mapping, | 2406 all of the the X.400 address is encoded in the 822.local-part and | 2407 the the 822.domain identifies the gateway to which the message is | 2408 being the sent. This technique may be used by the RFC 822 user | 2409 for any the X.400 address where the equivalence mapping is not | 2410 known. 2412 In the case that there is an applicable equivalence mapping, | 2413 the the maximum number of attributes are encoded in the | 2414 822.domain. The remaining attributes are encoded on the LHS, 2415 using the EBNF.std-or-address syntax. For example: 2417 /I=J/S=Linnimouth/GQ=5/@Marketing.Widget.COM 2419 encodes the MTS.ORAddress consisting of: 2421 MTS.CountryName = "TC" 2422 MTS.AdministrationDomainName = "BTT" 2423 MTS.OrganizationName = "Widget" 2424 MTS.OrganizationalUnitNames.value = "Marketing" 2425 MTS.PersonalName.surname = "Linnimouth" 2426 MTS.PersonalName.initials = "J" 2427 MTS.PersonalName.generation-qualifier = "5" 2429 on the basis of an equivalence between: | 2431 INTERNET DRAFT 2432 MIXER DRAFT Version 2.1 2434 Domain: Widget.COM 2435 O/R Address: C="TC", ADMD="BTT", O="Widget" 2437 Given the O/R address, the domain Widget.COM is determined from | 2438 the the equivalence mapping and the next component is determined | 2439 algorithmically to give Marketing.Widget.COM. The remaining | 2440 attributes are encoded on the LHS in 822.local-part. 2442 There is a further mechanism to simplify the encoding of * 2443 common cases, where the only attributes to be encoded on the LHS 2444 is a (non-Teletex) Personal Name attributes which comply with the 2445 restrictions of 4.2.1. To achieve this, the 822.local-part shall 2446 be encoded as EBNF.encoded-pn. In the previous example, if the | 2447 GenerationQualifier was not present in the O/R Address, it would 2448 map with the RFC 822 address: J.Linnimouth@Marketing.Widget.COM. 2450 From the standpoint of the RFC 822 Message Transfer System, 2451 the domain specification is used to route the message in the | 2452 standard manner. The standard domain mechanisms are used to 2453 select appropriate gateways for the corresponding O/R Address | 2454 space. It is the responsibility of the management that defines | 2455 the equivalence mapping to define routing in a the manner which | 2456 will enable the message to be delivered. 2458 4.3.2. RFC 822 encoded in X.400 2460 The previous section showed a mapping from X.400 to RFC 822. In | 2461 the case where the mapping was symmetrical and based on the the | 2462 equivalence mapping, this has also shown how RFC 822 is encoded | 2463 in the X.400. This equivalence cannot be used for all RFC 822 | 2464 addresses. 2466 The general case is mapped by use of domain defined 2467 attributes. A Domain defined type "RFC-822" is defined. The 2468 associated attribute value is an ASCII string encoded according 2469 to Section 3.3.3 of this specification. The interpretation of the | 2470 ASCII string follows RFC 822, and RFC 1123 . Domains shall | 2471 always be fully qualified. 2473 Other O/R Address attributes will be used to identify a 2474 context in which the O/R Address will be interpreted. This might 2475 be a Management Domain, or some part of a Management Domain which 2476 identifies a gateway MTA. For example: 2478 INTERNET DRAFT 2479 MIXER DRAFT Version 2.1 2481 C = "GB" 2482 ADMD = "GOLD 400" 2483 PRMD = "UK.AC" 2484 O = "UCL" 2485 OU = "CS" 2486 "RFC-822" = "Jimmy(a)WIDGET-LABS.CO.UK" 2488 OR 2490 C = "TC" 2491 ADMD = "Wizz.mail" 2492 PRMD = "42" 2493 "rfc-822" = "postel(a)venera.isi.edu" 2495 Note in each case the PrintableString encoding of "@" as "(a)". 2496 In the second example, the "RFC-822" domain defined attribute is 2497 interpreted everywhere within the (Private) Management Domain. 2498 In the first example, further attributes are needed within the 2499 Management Domain to identify a gateway. Thus, this scheme can 2500 be used with varying levels of Management Domain co-operation. 2502 There is a limit of 128 characters in the length of value of 2503 a domain defined attribute, and an O/R Address can have a 2504 maxmimum of four domain defined attributes. Where the printable 2505 string generated from the RFC 822 address exceeds this value, | 2506 additional domain defined attributes are used to enable up to 512 2507 characters to be encoded. These attributes shall be filled 2508 completely before the next one is started. The DDA keywords 2509 are: RFC822C1; RFC822C2; RFC822C3. Longer addresses cannot be 2510 encoded. 2512 There is, analogous with 4.3.1, a means to associate parts | 2513 of the O/R Address hierarchy with domains. There is an analogous 2514 global mapping, which in most cases will be the inverse of the 2515 domain to O/R address mapping. The mapping is maintained 2516 separately, as there may be differences (e.g., two alternate 2517 domain names map to the same set of O/R address components). 2519 4.3.3. Component Ordering 2521 In most cases, ordering of O/R Address components is not 2522 significant for the mappings specified. However, Organizational | 2523 Units (printable string and teletex forms) and Domain Defined 2525 INTERNET DRAFT 2526 MIXER DRAFT Version 2.1 2528 Attributes are specified as SEQUENCE in MTS.ORAddress, and so 2529 their order may be significant. This specification needs to take 2530 account of this: 2532 1. To allow consistent mapping into the domain hierarchy 2534 2. To ensure preservation of order over multiple mappings. 2536 There are three places where an order is specified: 2538 1. The text encoding (std-or-address) of MTS.ORAddress as used 2539 in the local-part of an RFC 822 address. An order is needed 2540 for those components which may have multiple values | 2541 (Organizational Unit, and Domain Defined Attributes). When 2542 generating an 822.std-or-address, components of a given type 2543 shall be in hierarchical order with the most significant 2544 component on the RHS. If there is an Organization | 2545 Attribute, it shall be to the right of any Organizational | 2546 Unit attributes. These requirements are for the following 2547 reasons: 2549 - Alignment to the hierarchy of other components in RFC 2550 822 addresses (thus, Organizational Units will appear | 2551 in the same order, whether encoded on the RHS or LHS). 2552 Note the differences of JNT Mail as described in 2553 Appendix B. 2555 - Backwards compatibility with RFC 987/1026. 2557 - To ensure that gateways generate consistent addresses. 2558 This is both to help end users, and to generate 2559 identical message ids. 2561 Further, it is recommended that all other attributes are 2562 generated according to this ordering, so that all attributes 2563 so encoded follow a consistent hierarchy. When generating 2564 822.msg-id, this order shall be followed. 2566 2. For the Organizational Units (OU) in MTS.ORAddress, the | 2567 first OU in the SEQUENCE is the most significant, as 2568 specified in X.400. 2570 3. For the Domain Defined Attributes in MTS.ORAddress, the 2571 First Domain Defined Attribute in the SEQUENCE is the most 2573 INTERNET DRAFT 2574 MIXER DRAFT Version 2.1 2576 significant. 2578 Note that although this ordering is mandatory for this 2579 mapping, there are NO implications on ordering significance 2580 within X.400, where this is a Management Domain issue. 2582 4.3.4. RFC 822 -> X.400 Basic Address Mapping | 2584 There are two basic cases: 2586 1. X.400 addresses encoded in RFC 822. This will also include 2587 RFC 822 addresses which are given reversible encodings. 2589 2. "Genuine" RFC 822 addresses. 2591 The mapping shall proceed as follows, by first assuming case 1). 2593 STAGE I. 2595 1. If the 822-address is not of the form: 2597 local-part "@" domain 2599 take the domain which will be routed on and apply step 2 of 2600 stage 1 to derive (a possibly null) set of attributes. Then 2601 go to stage II. 2603 NOTE:It may be appropriate to reduce a source route address 2604 to this form by removal of all bar the last domain. In 2605 terms of the design intentions of RFC 822, this would 2606 be an incorrect action. However, in most real cases, 2607 it will do the "right" thing and provide a better 2608 service to the end user. This is a reflection on the 2609 excessive and inappropriate use of source routing in | 2610 RFC 822 based systems, despite the discussion in the | 2611 Host Requirements [15]. Either approach, or the 2612 intermediate approach of stripping only domain 2613 references which reference the local gateway are 2614 conformant to this specification. 2616 2. Attempt to parse EBNF.domain as: | 2618 INTERNET DRAFT 2619 MIXER DRAFT Version 2.1 2621 *( domain-syntax "." ) known-domain 2623 Where EBNF.known-domain is the longest possible match in the | 2624 set of globally defined mappings described in Section 4.2. | 2625 EBNF.domain-syntax is the restricted domain syntax defined | 2626 in Section 4.2, to which all of the domain components must | 2627 conform for the parse to be successful. If this fails, and 2628 the EBNF.domain does not explicitly identify the local 2629 gateway, go to stage II. If the domain explicitly 2630 identifies the gateway, allocate no attributes. Otherwise | 2631 no gateway is explicitly identified and all of the | 2632 information is used by the local gateway. In this case | 2633 allocate the attributes associated with EBNF.known-domain. 2634 For each component, systematically allocate the attribute 2635 implied by each EBNF.domain-syntax component in the order: 2636 C, ADMD, PRMD, O, OU. Note that if the mapping used 2637 identifies an "omitted attribute", then this attribute 2638 should be omitted in the systematic allocation. If this new 2639 component exceed an upper bound (ADMD: 16; PRMD: 16; O: 64; 2640 OU: 32) or it would lead to more than four OUs, then go to 2641 stage II with the attributes derived. 2643 At this stage, a set of attributes has been derived, which 2644 will give appropriate routing within X.400. If any of the 2645 later steps of Stage I force use of Stage II, then these 2646 attributes should be used in Stage II. 2648 3. If the 822.local-part uses the 822.quoted-string encoding, 2649 remove this quoting. If this unquoted 822.local-part has 2650 leading space, trailing space, or two adjacent spaces go to | 2651 stage II. 2653 4. If the unquoted 822.local-part contains any characters not 2654 in PrintableString, go to stage II. 2656 5. Parse the (unquoted) 822.local-part according to the EBNF 2657 EBNF.std-or-address. Checking of upper bounds should not be 2658 done at this point. If this parse fails, parse the local- 2659 part according to the EBNF EBNF.encoded-pn. If this parse 2660 fails, go to stage II. The result is a set of type/value 2661 pairs. If the set of attributes leads to an address of any 2662 form other than mnemonic form, then only these attributes 2664 INTERNET DRAFT 2665 MIXER DRAFT Version 2.1 2667 should be taken. If (for mnemonic form) the values generated 2668 conflict with those derived in step 2 (e.g., a duplicated 2669 country attribute), the domain is assumed to be a remote 2670 gateway. In this case, take only the LHS derived 2671 attributes, together with any RHS derived attributes which | 2672 are more significant than the most significant attribute 2673 which is duplicated (e.g., if there is a duplicate PRMD, but 2674 no LHS derived ADMD and country, then the ADMD and country 2675 should be taken from the RHS). Otherwise add LHS and RHS | 2676 derived attributes together. 2678 6. Associate the EBNF.attribute-value syntax (determined from 2679 the identified type) with each value, and check that it 2680 conforms. If not, go to stage II. 2682 7. Ensure that the set of attributes conforms both to the 2683 MTS.ORAddress specification and to the restrictions on this 2684 set given in X.400, and that no upper bounds are exceeded 2685 for any attribute. If not go to stage II. 2687 8. Build the O/R Address from this information. 2689 STAGE II. 2691 This will only be reached if the RFC 822 EBNF.822-address is not 2692 a valid X.400 encoding. This implies that the address must refer 2693 to a recipient on an RFC 822 system. Such addresses shall be 2694 encoded in an X.400 O/R Address using a domain defined attribute. 2696 1. Convert the EBNF.822-address to PrintableString, as 2697 specified in Chapter 3. 2699 2. Generate the "RFC-822" domain defined attribute from this 2700 string. 2702 3. Build the rest of the O/R Address in the manner described 2703 below. 2705 It may not be possible to encode the domain defined attribute due 2706 to length restrictions. If the limit is exceeded by a mapping at 2707 the MTS level, then the gateway shall reject the message in 2708 question. If this occurs at the IPMS level, then the action will 2709 depend on the policy being taken for IPMS encoding, which is 2711 INTERNET DRAFT 2712 MIXER DRAFT Version 2.1 2714 discussed in Section 5.1.3. 2716 If Stage I has identified a set of attributes, use these to build 2717 the remainder of the address. The administrative equivalence of 2718 the mappings will ensure correct routing through X.400 to a | 2719 gateway back to RFC 822. 2721 If Stage I has not identified a set of attributes, the 2722 remainder of the O/R address effectively identifies a source 2723 route to a gateway from the X.400 side. There are three cases, 2724 which are handled differently: 2726 822-MTS Return Address 2727 This shall be set up so that errors are returned through the 2728 same gateway. Therefore, the O/R Address of the local 2729 gateway shall be used. 2731 IPMS Addresses 2732 These are optimised for replying. In general, the message 2733 may end up anywhere within the X.400 world, and so this 2734 optimisation identifies a gateway appropriate for the RFC 2735 822 address being converted. The 822.domain to which the 2736 address would be routed is used to select an appropriate 2737 gateway. A globally defined set of mappings is used, which 2738 identifies (the O/R Address components of) appropriate 2739 gateways for parts of the domain namespace. The longest | 2740 possible match on the 822.domain defines which gateway to | 2741 use, according to the equivalence mappings defined in | 2742 Section 4.2. 2744 This global mapping is used for parts of the RFC 822 2745 namespace which do not have an administrative equivalence 2746 with any part of the X.400 namespace, but for which it is 2747 desirable to identify a preferred X.400 gateway in order to 2748 optimise routing. 2750 If no mapping is found for the 822.domain, a default value 2751 (typically that of the local gateway) is used. It is never 2752 appropriate to ignore the globally defined mappings. In 2753 some cases, it may be appropriate to locally override the 2754 globally defined mappings (e.g., to identify a gateway close 2755 to a recipient of the message). This is likely to be where 2756 the global mapping identifies a public gateway, and the 2757 local gateway has an agreement with a private gateway which 2759 INTERNET DRAFT 2760 MIXER DRAFT Version 2.1 2762 it prefers to use. 2764 822-MTS Recipient 2765 As the RFC 822 and X.400 worlds are in principle fully | 2766 connected, there should be no technical reason for this | 2767 situation to occur. In practice, this is not the case. | 2768 In some cases, routing may be configured to connect two 2769 parts of the RFC 822 world using X.400. The information 2770 that this part of the domain space should be routed by X.400 2771 rather than remaining within the RFC 822 world will be 2772 configured privately into the gateway in question. The O/R 2773 address shall then be generated in the same manner as for an 2774 IPMS address, using the globally defined mappings. It is to 2775 support this case that the definition of the global domain 2776 to gateway mapping is important, as the use of this mapping 2777 will lead to a remote X.400 address, which can be routed by 2778 X.400 routing procedures. The information in this mapping 2779 shall not be used as a basis for deciding to convert a 2780 message from RFC 822 to X.400. | 2782 Two examples are given: | 2784 Example 1: (Address not in "localpart" "@" "domainpart") | 2786 @relay.co.uk:userb@host2 2787 maps to 2788 c=gb; a= ; p=uk.ac; o=mhs-relay; dd.rfc-822=(a)relay.co.uk:userb(a)host2; 2790 Example 2: (Address with non printablestring characters) | 2792 Tom_Harris@cs.widget.com 2793 maps to 2794 c=us; a=MCI; P=relay; dd.rfc-822=Tom(u)Harris(a)cs.widget.com; 2796 4.3.4.1. Heuristics for mapping RFC 822 to X.400 2798 RFC 822 users will often use an LHS encoded address to identify 2799 an X.400 recipient. Because the syntax is fairly complex, a 2800 number of heuristics may be applied to facilitate this form of 2801 usage. A gateway should take care not to be overly "clever" with 2802 heuristics, as this may cause more confusion than a more 2803 mechanical approach. The heuristics are as follows: 2805 INTERNET DRAFT 2806 MIXER DRAFT Version 2.1 2808 1. Ignore the omission of a trailing "/" in the std-or syntax. 2810 2. If there is no ADMD component, and both country and PRMD are 2811 present, the value of /ADMD= / (single space) is assumed. 2813 3. Parse the unquoted local part according to the EBNF colon- 2814 or-address. This facilitate users used to this delimiter, | 2815 and also allows the standard string representation of X.400 | 2816 addresses to be used (in conjunction with alternate | 2817 attribute keys). 2819 colon-or-address = 1*(attribute "=" value ";" *(LWSP-char)) 2821 4. Allow the separator following "DD" or "DDA" to be ":" | 2822 instead of ".", to align with the standard string | 2823 representation of X.400 addresses. | 2825 5. Ignore the omission of a leading "/" in the std-or syntax. | 2826 This is to facilitate a workaround for (non-conformant) | 2827 systems which cannot support RFC 822 addresses with a | 2828 leading "/". 2830 The remaining heuristic relates to ordering of address 2831 components. The ordering of attributes may be inverted or mixed. 2832 For this reason, the following heuristics may be applied: | 2834 6. If there is an Organization attribute to the left of any Org | 2835 Unit attribute, assume that the hierarchy is inverted. This | 2836 is to facilitate the situation where a user has input the | 2837 attributes in reverse hierarchical order. To do this the | 2838 gateway shall first map according to the order defined in | 2839 4.3.3. If this mapping generates an address which X.400 | 2840 address verification shows to be invalid, this heuristic may | 2841 be applied as an alternative to immediate rejection of the | 2842 address. 2844 4.3.5. X.400 -> RFC 822 Basic Address Mapping | 2846 There are two basic cases: 2848 1. RFC 822 addresses encoded in X.400. 2850 INTERNET DRAFT 2851 MIXER DRAFT Version 2.1 2853 2. "Genuine" X.400 addresses. This may include symmetrically 2854 encoded RFC 822 addresses. 2856 When a MTS Recipient O/R Address is interpreted, gatewaying will 2857 be selected if there is a single "RFC-822" domain defined 2858 attribute present and the local gateway is identified by the 2859 remainder of the O/R Address. In this case, use mapping A. For 2860 other O/R Addresses which 2862 1. Contain the special attribute. 2864 AND 2866 2. Identifies the local gateway or any other known gateway with 2867 the other attributes. 2869 use mapping A. In other cases, use mapping B. 2871 NOTE: 2872 A pragmatic approach would be to assume that any O/R 2873 Address with the special domain defined attribute identifies 2874 an RFC 822 address. This will usually work correctly, but is 2875 in principle not correct. Use of this approach is 2876 conformant to this specification. | 2878 Editor's | 2879 It has been suggested that this pragmatic approach be | 2880 required (HTA), as it usually works. It has been suggested | 2881 that this approach should not be allowed (AWY), as it causes | 2882 severe problems in some cases. An alternate approach is to | 2883 define an alternate value for which this assumption shall | 2884 not be made. 2886 Mapping A 2888 1. Map the domain defined attribute value to ASCII, as defined 2889 in Chapter 3, and drop all other attributes. | 2891 Mapping B. 2893 This is used for X.400 addresses which do not use the explicit 2894 RFC 822 encoding. 2896 1. For all string encoded attributes, remove any leading or 2898 INTERNET DRAFT 2899 MIXER DRAFT Version 2.1 2901 trailing spaces, and replace adjacent spaces with a single 2902 space. 2904 The only attribute which is permitted to have zero length is 2905 the ADMD. This should be mapped onto a single space. 2907 These transformations are for lookup only. If an | 2908 EBNF.std-or-address mapping is used as in 4), then the | 2909 original values should be used. 2911 2. Map numeric country codes to the two letter values. 2913 3. Noting the hierarchy specified in 4.3.1 and including 2914 omitted attributes, determine the maximum set of attributes 2915 which have an associated domain specification in the 2916 globally defined mapping. If no match is found, allocate 2917 the domain as the domain specification of the local gateway, 2918 and go to step 5. 2920 Note: It might be appropriate to use a non-local domain. 2921 This would be selected by a global mapping analogous to | 2922 the one described at the end of 4.3.4. This is not | 2923 done. 2925 In cases where the address refers to an X.400 UA, it is 2926 important that the generated domain will correctly route to 2927 a gateway. In general, this is achieved by carefully co- 2928 ordinating RFC 822 routing with the definition of the global 2929 mappings, as there is no easy way for the gateway to make 2930 this check. One rule that shall be used is that domains 2931 with only one component will not route to a gateway. If the 2932 generated domain does not route correctly, the address is 2933 treated as if no match is found. 2935 4. The mapping identified in 3) gives a domain, and an O/R 2936 address prefix. Follow the hierarchy: C, ADMD, PRMD, O, OU. 2937 For each successive component below the O/R address prefix, 2938 which conforms to the syntax EBNF.domain-syntax (as defined 2939 in 4.3.1), allocate the next subdomain. At least one 2940 attribute of the X.400 address shall not be mapped onto 2941 subdomain, as 822.local-part cannot be null. If there are 2942 omitted attributes in the O/R address prefix, these will 2943 have correctly and uniquely mapped to a domain component. 2944 Where there is an attribute omitted below the prefix, all 2946 INTERNET DRAFT 2947 MIXER DRAFT Version 2.1 2949 attributes remaining in the O/R address shall be encoded on 2950 the LHS. This is to ensure a reversible mapping. For | 2951 example, if there is an address /S=XX/O=YY/ADMD=A/C=NN/ and | 2952 a mapping for /ADMD=A/C=NN/ is used, then /S=XX/O=YY/ is 2953 encoded on the LHS. 2955 5. If the address contains any attribute not used in mnemonic | 2956 form, then all of the attributes in the address should be 2957 encoded on the LHS in EBNF.std-or-address syntax, as 2958 described below. 2960 For addresses of mnemonic form, if the remaining components 2961 are personal-name components, conforming to the restrictions 2962 of 4.2.1, then EBNF.encoded-pn is derived to form 2963 822.local-part. In other cases the remaining components are 2964 simply encoded as 822.local-part using the 2965 EBNF.std-or-address syntax. If necessary, the 2966 822.quoted-string encoding is used. The following are 2967 examples of legal quoting: "a b".c@x; "a b.c"@x. Either 2968 form may be generated, but the latter is preferred. 2970 If the derived 822.local-part can only be encoded by use of 2971 822.quoted-string, then use of the mapping defined in[24] 2972 may be appropriate. Use of this mapping is discouraged. | 2974 Three examples are given. | 2976 Example 1: (Address with missing X.400 elements and no specific | 2977 mapping rule for "o=sales; a=Master400; C=it") | 2979 c=it; a=Master400; o=sales; S=Support; 2980 maps to 2981 "/S=Support/o=sales"@Master400.it 2983 Example 2: (Address with illegal characters in RFC822 generated | 2984 domain if default hierarchical translation (specific mapping rule | 2985 is existing for c=fr; a=atlas; p=autoroutes) is used) | 2987 c=fr; a=atlas; p=autoroutes; o=Region Parisienne; S=rensignments; 2988 maps to 2989 "/S=rensignments/o=Region Parisienne"@autoroutes.fr 2991 Example 3: (Address containing elements not mappable into RFC822 | 2993 INTERNET DRAFT 2994 MIXER DRAFT Version 2.1 2996 local part) | 2998 c=it; a=PtPostel; DD.cap=20100; DD.ph1=Via Maggiore 11; DD.city=Milano; S=Rossi; 2999 MAPS TO 3000 "/DD.Cap=20100/DD.ph1=Via Maggiore 11/DD.City=Milano/S=Rossi"@ptpostel.it 3002 4.4. Repeated Mappings 3004 There are two types of repeated mapping: 3006 1. A recursive mapping, where the repeat is within one gateway 3008 2 A source route, where the repetition occurs across multiple 3009 gateways 3011 4.4.1. Recursive Mappings 3013 It is possible to supply an address which is recursive at a | 3014 single gateway. For example: 3016 C = "XX" 3017 ADMD = "YY" 3018 O = "ZZ" 3019 "RFC-822" = "Smith(a)ZZ.YY.XX" 3021 This is mapped first to an RFC 822 address, and then back to the 3022 X.400 address: 3024 C = "XX" 3025 ADMD = "YY" 3026 O = "ZZ" 3027 Surname = "Smith" 3029 In some situations this type of recursion may be frequent. It is 3030 important that where this occurs, that no unnecessary protocol 3031 conversion occurs. This will minimise loss of service. 3033 4.4.2. Source Routes 3035 The mappings defined are symmetrical and reversible across a 3036 single gateway. The symmetry is particularly useful in cases of 3037 (mail exploder type) distribution list expansion. For example, 3038 an X.400 user sends to a list on an RFC 822 system which he 3040 INTERNET DRAFT 3041 MIXER DRAFT Version 2.1 3043 belongs to. The received message will have the originator and 3044 any 3rd party X.400 O/R Addresses in correct format (rather than 3045 doubly encoded). In cases (X.400 or RFC 822) where there is 3046 common agreement on gateway identification, then this will apply 3047 to multiple gateways. 3049 When a message traverses multiple gateways, the mapping will 3050 always be reversible, in that a reply can be generated which will 3051 correctly reverse the path. In many cases, the mapping will also 3052 be symmetrical, which will appear clean to the end user. For 3053 example, if countries "AB" and "XY" have RFC 822 networks, but 3054 are interconnected by X.400, the following may happen: The 3055 originator specifies: 3057 Joe.Soap@Widget.PTT.XY 3059 This is routed to a gateway, which generates: 3061 C = "XY" 3062 ADMD = "PTT" 3063 PRMD = "Griddle MHS Providers" 3064 Organization = "Widget Corporation" | 3065 Surname = "Soap" 3066 Given Name = "Joe" 3068 This is then routed to another gateway where the mapping is 3069 reversed to give: 3071 Joe.Soap@Widget.PTT.XY 3073 Here, use of the gateway is transparent. 3075 Mappings will only be symmetrical where mapping tables are 3076 defined. In other cases, the reversibility is more important, due 3077 to the (far too frequent) cases where RFC 822 and X.400 services 3078 are partitioned. 3080 The syntax may be used to source route. THIS IS STRONGLY 3081 DISCOURAGED. For example: 3083 INTERNET DRAFT 3084 MIXER DRAFT Version 2.1 3086 X.400 -> RFC 822 -> X.400 3088 C = "UK" 3089 ADMD = "Gold 400" 3090 PRMD = "UK.AC" 3091 "RFC-822" = "/PN=Duval/DD.Title=Manager/(a)Inria.ATLAS.FR" 3093 This will be sent to an arbitrary UK Academic Community gateway 3094 by X.400. Then it will be sent by JNT Mail to another gateway 3095 determined by the domain Inria.ATLAS.FR (FR.ATLAS.Inria). This 3096 will then derive the X.400 O/R Address: 3098 C = "FR" 3099 ADMD = "ATLAS" 3100 PRMD = "Inria" 3101 PN.S = "Duval" 3102 "Title" = "Manager" 3104 Similarly: 3105 RFC 822 -> X.400 -> RFC 822 3107 "/RFC-822=jj(a)seismo.css.gov/PRMD=AC/ADMD=BT/C=GB/"@monet.berkeley.edu| 3109 This will be sent to monet.berkeley.edu by RFC 822, then to the 3110 AC PRMD by X.400, and then to jj@seismo.css.gov by RFC 822. 3112 4.5. Directory Names 3114 Directory Names are an optional part of O/R Name, along with O/R 3115 Address. The RFC 822 addresses are mapped onto the O/R Address 3116 component. As there is no functional mapping for the Directory 3117 Name on the RFC 822 side, a textual mapping is used. There is no 3118 requirement for reversibility in terms of the goals of this 3119 specification. There may be some loss of functionality in terms 3120 of third party recipients where only a directory name is given, 3121 but this seems preferable to the significant extra complexity of 3122 adding a full mapping for Directory Names. | 3124 The Directory Name shall be represented within an RFC 822 | 3125 comment. Any reasonable format for representing the directory | 3126 name may be used. It is recommended that the directory string | 3127 format of RFC 1485 is used [29]. The User Friendly Name form of | 3128 RFC 1484 may also be used [30]. 3130 INTERNET DRAFT 3131 MIXER DRAFT Version 2.1 3133 4.6. MTS Mappings 3135 The basic mappings at the MTS level are: 3137 1) 822-MTS originator -> 3138 MTS.PerMessageSubmissionFields.originator-name 3139 MTS.OtherMessageDeliveryFields.originator-name -> 3140 822-MTS originator 3142 2) 822-MTS recipient -> 3143 MTS.PerRecipientMessageSubmissionFields 3144 MTS.OtherMessageDeliveryFields.this-recipient-name -> 3145 822-MTS recipient 3147 822-MTS recipients and return addresses are encoded as 3148 EBNF.822-address. 3150 The MTS Originator is always encoded as MTS.OriginatorName, 3151 which maps onto MTS.ORAddressAndOptionalDirectoryName, which in 3152 turn maps onto MTS.ORName. 3154 4.6.1. RFC 822 -> X.400 MTS Mappings | 3156 From the 822-MTS Originator, use the basic ORAddress mapping, to 3157 generate MTS.PerMessageSubmissionFields.originator-name 3158 (MTS.ORName), without a DirectoryName. 3160 For recipients, the following settings are made for each 3161 component of MTS.PerRecipientMessageSubmissionFields. 3163 recipient-name 3164 This is derived from the 822-MTS recipient by the basic 3165 ORAddress mapping. 3167 originator-report-request 3168 This is be set according to content return policy, as 3169 discussed in Section 5.2. 3171 explicit-conversion 3172 This optional component is omitted, as this service is not 3173 needed 3175 extensions 3176 The default value (no extensions) is used 3178 INTERNET DRAFT 3179 MIXER DRAFT Version 2.1 3181 4.6.2. X.400 -> RFC 822 MTS Mappings | 3183 The basic functionality is to generate the 822-MTS originator and 3184 recipients. There is information present on the X.400 side, 3185 which cannot be mapped into analogous 822-MTS services. For this 3186 reason, new RFC 822 fields are added for the MTS Originator and 3187 Recipients. The information discarded at the 822-MTS level will 3188 be present in these fields. In some cases a (positive) delivery 3189 report will be generated. 3191 4.6.2.1. 822-MTS Mappings 3193 Use the basic ORAddress mapping, to generate the 822-MTS 3194 originator (return address) from 3195 MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName). If 3196 MTS.ORName.directory-name is present, it is discarded. (Note 3197 that it will be presented to the user, as described in 4.6.2.2). 3199 The 822-MTS recipient is conceptually generated from 3200 MTS.OtherMessageDeliveryFields.this-recipient-name. This is done 3201 by taking MTS.OtherMessageDeliveryFields.this-recipient-name, and 3202 generating an 822-MTS recipient according to the basic ORAddress 3203 mapping, discarding MTS.ORName.directory-name if present. 3204 However, if this model was followed exactly, there would be no 3205 possibility to have multiple 822-MTS recipients on a single 3206 message. This is unacceptable, and so layering is violated. The 3207 mapping needs to use the MTA level information, and map each 3208 value of MTA.PerRecipientMessageTransferFields.recipient-name, 3209 where the responsibility bit is set, onto an 822-MTS recipient. 3211 4.6.2.2. Generation of RFC 822 Headers 3213 Not all per-recipient information can be passed at the 822-MTS 3214 level. For this reason, two new RFC 822 headers are created, in 3215 order to carry this information to the RFC 822 recipient. These 3216 fields are "X400-Originator:" and "X400-Recipients:". 3218 The "X400-Originator:" field is set to the same value as the 3219 822-MTS originator. In addition, if 3220 MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName) 3221 contains MTS.ORName.directory-name then this Directory Name shall 3222 be represented in an 822.comment. 3224 Recipient names, taken from each value of 3226 INTERNET DRAFT 3227 MIXER DRAFT Version 2.1 3229 MTS.OtherMessageDeliveryFields.this-recipient-name and 3230 MTS.OtherMessageDeliveryFields.other-recipient-names are made 3231 available to the RFC 822 user by use of the "X400-Recipients:" 3232 field. By taking the recipients at the MTS level, disclosure of 3233 recipients will be dealt with correctly. However, this conflicts 3234 with a desire to optimise mail transfer. There is no problem 3235 when disclosure of recipients is allowed. Similarly, there is no 3236 problem if there is only one RFC 822 recipient, as the | 3237 "X400-Recipients" field is only given one address. 3239 There is a problem if there are multiple RFC 822 recipients, 3240 and disclosure of recipients is prohibited. Two options are 3241 allowed: 3243 1. Generate one copy of the message for each RFC 822 recipient, 3244 with the "X400-Recipients field correctly set to the 3245 recipient of that copy. This is functionally correct, but 3246 is likely to be more expensive. 3248 2. Discard the per-recipient information, and insert a field: 3250 X400-Recipients: non-disclosure:; 3252 This is the recommended option. 3254 A third option of ignoring the disclosure flag is not allowed. 3255 If any MTS.ORName.directory-name is present, it shall be 3256 represented in an 822.comment. 3258 If 3259 MTS.OtherMessageDeliveryFields.orignally-intended-recipient-name 3260 is present, then there has been redirection, or there has been 3261 distribution list expansion. Distribution list expansion is a 3262 per-message option, and the information associated with this is 3263 represented by the "DL-Expansion-History:" field described in | 3264 Section 5.3.6. Other information is represented in an 3265 822.comment associated associated with 3266 MTS.OtherMessageDeliveryFields.this-recipient-name, The message 3267 may be delivered to different RFC 822 recipients, and so several 3268 addresses in the "X400-Recipients:" field may have such comments. 3269 The non-commented recipient is the RFC 822 recipient. The EBNF of 3270 the comment is: 3272 INTERNET DRAFT 3273 MIXER DRAFT Version 2.1 3275 redirect-comment = 3276 [ "Originally To:" ] mailbox "Redirected" 3277 [ "Again" ] "on" date-time 3278 "To:" redirection-reason 3280 redirection-reason = 3281 "Recipient Assigned Alternate Recipient" 3282 / "Originator Requested Alternate Recipient" 3283 / "Recipient MD Assigned Alternate Recipient" 3284 / "Recipient Directory Substitution Alternate Recipient"| 3286 It is derived from 3287 MTA.PerRecipientMessageTransferFields.extension.redirection-history. 3288 An example of this is: 3290 X400-Recipients: postmaster@widget.com (Originally To: 3291 sales-manager@sales.widget.com Redirected 3292 on Thu, 30 May 91 14:39:40 +0100 To: Originator Assigned 3293 Alternate Recipient postmaster@sales.widget.com Redirected 3294 Again on Thu, 30 May 91 14:41:20 +0100 To: Recipient MD 3295 Assigned Alternate Recipient) 3297 In addition the following per-recipient services from 3298 MTS.OtherMessageDeliveryFields.extensions are represented in 3299 comments if they are used. None of these services can be 3300 provided on RFC 822 networks, and so in general these will be 3301 informative strings associated with other MTS recipients. In some 3302 cases, string values are defined. For the remainder, the string 3303 value shall be chosen by the implementor. If the parameter has 3304 a default value, then no comment shall be inserted when the 3305 parameter has that default value. 3307 requested-delivery-method 3309 physical-forwarding-prohibited 3310 "(Physical Forwarding Prohibited)". 3312 physical-forwarding-address-request 3313 "(Physical Forwarding Address Requested)". 3315 physical-delivery-modes 3317 INTERNET DRAFT 3318 MIXER DRAFT Version 2.1 3320 registered-mail-type 3322 recipient-number-for-advice 3324 physical-rendition-attributes 3326 physical-delivery-report-request 3327 "(Physical Delivery Report Requested)". 3329 proof-of-delivery-request 3330 "(Proof of Delivery Requested)". 3332 4.6.2.3. Delivery Report Generation 3334 If MTA.PerRecipientMessageTransferFields.per-recipient-indicators 3335 requires a positive delivery notification, this shall be 3336 generated by the gateway. Supplementary Information shall be set 3337 to indicate that the report is gateway generated. This 3338 information shall include the name of the gateway generating the 3339 report. 3341 4.6.3. Message IDs (MTS) 3343 A mapping from 822.msg-id to MTS.MTSIdentifier is defined. The 3344 reverse mapping is not needed, as MTS.MTSIdentifier is always 3345 mapped onto new RFC 822 fields. The value of 3346 MTS.MTSIdentifier.local-part will facilitate correlation of 3347 gateway errors. 3349 To map from 822.msg-id, apply the standard mapping to 3350 822.msg-id, in order to generate an MTS.ORAddress. The Country, 3351 ADMD, and PRMD components of this are used to generate 3352 MTS.MTSIdentifier.global-domain-identifier. 3353 MTS.MTSIdentifier.local-identifier is set to the 822.msg-id, 3354 including the braces "<" and ">". If this string is longer than 3355 MTS.ub-local-id-length (32), then it is truncated to this length. 3357 The reverse mapping is not used in this specification. It 3358 would be applicable where MTS.MTSIdentifier.local-identifier is 3359 of syntax 822.msg-id, and it algorithmically identifies 3360 MTS.MTSIdentifier. 3362 INTERNET DRAFT 3363 MIXER DRAFT Version 2.1 3365 4.7. IPMS Mappings 3367 All RFC 822 addresses are assumed to use the 822.mailbox syntax. 3368 This includes all 822.comments associated with the lexical tokens 3369 of the 822.mailbox. In the IPMS O/R Names are encoded as 3370 MTS.ORName. This is used within the IPMS.ORDescriptor, 3371 IPMS.RecipientSpecifier, and IPMS.IPMIdentifier. An asymmetrical 3372 mapping is defined between these components. 3374 4.7.1. RFC 822 -> X.400 3376 To derive IPMS.ORDescriptor from an RFC 822 address. 3378 1. Take the address, and extract an EBNF.822-address. This can 3379 be derived trivially from either the 822.addr-spec or 3380 822.route-addr syntax. This is mapped to MTS.ORName as 3381 described above, and used as IMPS.ORDescriptor.formal-name. 3383 2. A string shall be built consisting of (if present): 3385 - The 822.phrase component if the 822.address is an 3386 822.phrase 822.route-addr construct. 3388 - Any 822.comments, in order, retaining the parentheses. 3390 This string is then encoded into T.61 use a human oriented 3391 mapping (as described in Section 3.5). If the string is not | 3392 null, it is assigned to IPMS.ORDescriptor.free-form-name. 3394 3. IPMS.ORDescriptor.telephone-number is omitted. 3396 If IPMS.ORDescriptor is being used in IPMS.RecipientSpecifier, 3397 IPMS.RecipientSpecifier.reply-request and 3398 IPMS.RecipientSpecifier.notification-requests are set to default 3399 values (false and none). | 3401 If the 822.group construct is present, any included 3402 822.mailbox is encoded as above to generate a separate 3403 IPMS.ORDescriptor. The 822.group is mapped to T.61 (as | 3404 described in Section 3.5), and a IPMS.ORDescriptor with only an 3405 free-form-name component built from it. 3407 INTERNET DRAFT 3408 MIXER DRAFT Version 2.1 3410 4.7.2. X.400 -> RFC 822 3412 Mapping from IPMS.ORDescriptor to RFC 822 address. In the basic 3413 case, where IPMS.ORDescriptor.formal-name is present, proceed as 3414 follows. 3416 1. Encode IPMS.ORDescriptor.formal-name (MTS.ORName) as 3417 EBNF.822-address. 3419 2a. If IPMS.ORDescriptor.free-form-name is present, convert it 3420 to ASCII or T.61 (Section 3.5), and use this as the | 3421 822.phrase component of 822.mailbox using the 822.phrase 3422 822.route-addr construct. 3424 2b. If IPMS.ORDescriptor.free-form-name is absent. If 3425 EBNF.822-address is parsed as 822.addr-spec use this as the 3426 encoding of 822.mailbox. If EBNF.822-address is parsed as 3427 822.route 822.addr-spec, then a 822.phrase taken from 3428 822.local-part is added. 3430 3 If IPMS.ORDescriptor.telephone-number is present, this is 3431 placed in an 822.comment, with the string "Tel ". The 3432 normal international form of number is used. For example: 3434 (Tel +44-181-333-7777) | 3436 4. If IPMS.ORDescriptor.formal-name.directory-name is present, 3437 then a text representation is placed in a trailing 3438 822.comment. 3440 5. If IPMS.RecipientSpecifier.report-request has any non- 3441 default values, then an 822.comment "(Receipt Notification 3442 Requested)", and/or "(Non Receipt Notification Requested)", 3443 and/or "(IPM Return Requested)" may be appended to the | 3444 address. The effort of correlating P1 and P2 information is 3445 too great to justify the gateway sending Receipt 3446 Notifications. | 3448 In RFC 1327, inclusion of these comments was mandatory. | 3449 Experience has shown that the clutter and confusion caused | 3450 to RFC 822 users does not justify the information conveyed. | 3451 Implementors are recommended to not include these comments. | 3452 Unless an application is found where retention of these | 3454 INTERNET DRAFT 3455 MIXER DRAFT Version 2.1 3457 comments is desirable, they will be dropped from the next | 3458 version. 3460 6. If IPMS.RecipientSpecifier.reply-request is True, an 3461 822.comment "(Reply requested)" is appended to the address. 3463 If IPMS.ORDescriptor.formal-name is absent, 3464 IPMS.ORDescriptor.free-form-name is converted to ASCII, and used 3465 as 822.phrase within the RFC 822 822.group syntax. For example: 3467 Free Form Name ":" ";" 3469 Steps 3-6 are then followed. 3471 4.7.3. IP Message IDs 3473 There is a need to map both ways between 822.msg-id and 3474 IPMS.IPMIdentifier. This allows for X.400 Receipt Notifications, 3475 Replies, and Cross References to reference an RFC 822 Message ID, 3476 which is preferable to a gateway generated ID. A reversible and 3477 symmetrical mapping is defined. This provides fully reversible | 3478 mappings when messages pass multiple times across the X.400/RFC 3479 822 boundary. 3481 An important issue with messages identifiers is mapping to 3482 the exact form, as many systems use these ids as uninterpreted 3483 keys. The use of table driven mappings is not always 3484 symmetrical, particularly in the light of alternative domain 3485 names, and alternative management domains. For this reason, a 3486 purely algorithmic mapping is used. A mapping which is simpler 3487 than that for addresses can be used for two reasons: 3489 - There is no major requirement to make message IDs "natural" 3491 - There is no issue about being able to reply to message IDs. 3492 (For addresses, creating a return path which works is more 3493 important than being symmetrical). 3495 The mapping works by defining a way in which message IDs 3496 generated on one side of the gateway can be represented on the 3497 other side in a systematic manner. The mapping is defined so 3498 that the possibility of clashes is is low enough to be treated as 3499 impossible. 3501 INTERNET DRAFT 3502 MIXER DRAFT Version 2.1 3504 4.7.3.1. 822.msg-id represented in X.400 3506 IPMS.IPMIdentifier.user is omitted. The 3507 IPMS.IPMIdentifier.user-relative-identifier is set to a printable 3508 string encoding of the 822.msg-id with the angle braces ("<" and 3509 ">") removed. The upper bound on this component is 64. The 3510 options for handling this are discussed in Section 5.1.3. 3512 4.7.3.2. IPMS.IPMIdentifier represented in RFC 822 3514 The 822.domain of 822.msg-id is set to the value "MHS". The | 3515 822.local-part of 822.msg-id is constructed as follows. A string | 3516 is build of syntax EBNF.id-loc from IPMS.IPMIdentifier. 3518 id-loc ::= [ printablestring ] "*" [ std-or-address ] | 3520 EBNF.printablestring is the | 3521 IPMS.IPMIdentifier.user-relative-identifier, and EBNF.std-or- | 3522 address being an encoding of the IPMS.IPMIdentifier.user derived | 3523 according to this specification. 822.local-part is derived from | 3524 EBNF.id-loc, if necessary using the 822.quoted-string encoding. 3525 For example: 3527 <"147*/S=Dietrich/O=Siemens/ADMD=DBP/C=DE/"@MHS> 3529 4.7.3.3. 822.msg-id -> IPMS.IPMIdentifier 3531 If the 822.local-part can be parsed as: 3533 [ printablestring ] "*" [ std-or-address ] 3535 and the 822.domain is "MHS", then this ID was X.400 generated. 3536 If EBNF.printablestring is present, the value is assigned to 3537 IPMS.IPMIdentifier.user-relative-identifier. If 3538 EBNF.std-or-address is present, the O/R Address components 3539 derived from it are used to set IPMS.IPMIdentifier.user. 3541 Otherwise, this is an RFC 822 generated ID. In this case, 3542 set IPMS.IPMIdentifier.user-relative-identifier to a printable 3543 string encoding of the 822.msg-id without the angle braces. 3545 INTERNET DRAFT 3546 MIXER DRAFT Version 2.1 3548 4.7.3.4. IPMS.IPMIdentifier -> 822.msg-id 3550 If IPMS.IPMIdentifier.user is absent, and 3551 IPMS.IPMIdentifier.user-relative-identifier mapped to ASCII and 3552 angle braces added parses as 822.msg-id, then this is an RFC 822 3553 generated ID. 3555 Otherwise, the ID is X.400 generated. Use the 3556 IPMS.IPMIdentifier.user to generate an EBNF.std-or-address form 3557 string. Build the 822.local-part of the 822.msg-id with the 3558 syntax: 3560 [ printablestring ] "*" [ std-or-address ] 3562 The printablestring is taken from 3563 IPMS.IPMIdentifier.user-relative-identifier. Use 3564 822.quoted-string if necessary. The 822.msg-id is generated with 3565 this 822.local-part, and "MHS" as the 822.domain. 3567 4.7.3.5. Phrase form 3569 In "InReply-To:" and "References:", the encoding 822.phrase may 3570 be used as an alternative to 822.msg-id. To map from 822.phrase 3571 to IPMS.IPMIdentifier, assign 3572 IPMS.IPMIdentifier.user-relative-identifier to the phrase. When 3573 mapping from IPMS.IPMIdentifier for "In-Reply-To:" and 3574 "References:", if IPMS.IPMIdentifier.user is absent and 3575 IPMS.IPMIdentifier.user-relative-identifier does not parse as 3576 822.msg-id, generate an 822.phrase rather than adding the domain 3577 MHS. 3579 4.7.3.6. RFC 987 backwards compatibility 3581 The mapping defined here is different to that used in RFC 987, as 3582 the RFC 987 mapping lead to changed message IDs in many cases. 3583 Fixing the problems is preferable to retaining backwards 3584 compatibility. An implementation of this standard is encouraged 3585 to recognise message IDs generated by RFC 987. This is not 3586 required. 3588 RFC 987 generated encodings may be recognised as follows. 3589 When mapping from X.400 to RFC 822, if the 3590 IPMS.IPMIdentifier.user-relative-identifier is "RFC-822" the id 3591 is RFC 987 generated. When mapping from RFC 822 to X.400, if the 3593 INTERNET DRAFT 3594 MIXER DRAFT Version 2.1 3596 822.domain is not "MHS", and the 822.local-part can be parsed as 3598 [ printablestring ] "*" [ std-or-address ] 3600 then it is RFC 987 generated. In each of these cases, it is 3601 recommended to follow the RFC 987 rules. 3603 INTERNET DRAFT 3604 MIXER DRAFT Version 2.1 3606 Chapter 5 - Detailed Mappings 3608 This chapter specifies detailed mappings for the functions 3609 outlined in Chapters 1 and 2. It makes extensive use of the 3610 notations and mappings defined in Chapters 3 and 4. 3612 5.1. | 3613 RFC 822 -> X.400: Detailed Mappings | 3615 The mapping of RFC 822 and MIME messages to X.400 InterPersonal | 3616 Messages is described in Sections 5.1.1 to 5.1.7. Mapping of | 3617 NOTARY format delivery status notifications, which are all | 3618 messages of type multipart/report and subtype | 3619 delivery-status-notifications to X.400 delivery reports is | 3620 covered in Section 5.1.8. 3622 5.1.1. Basic Approach 3624 A single IP Message is generated from an RFC 822 message The RFC 3625 822 headers are used to generate the IPMS.Heading. * 3627 Some RFC 822 fields cannot be mapped onto a standard IPM 3628 Heading field, and so an extended field is defined in Section 3629 5.1.2. This is then used for fields which cannot be mapped onto 3630 existing services. 3632 The message is submitted to the MTS, and the services 3633 required can be defined by specifying 3634 MTS.MessageSubmissionEnvelope. A few parameters of the MTA 3635 Abstract service are also specified, which are not in principle 3636 available to the MTS User. Use of these services allows RFC 822 3637 MTA level parameters to be carried in the analogous X.400 service 3638 elements. The advantages of this mapping far outweigh the 3639 layering violation. 3641 5.1.2. X.400 Extension Field 3643 An IPMS Extension is defined: 3645 INTERNET DRAFT 3646 MIXER DRAFT Version 2.1 3648 rfc-822-field HEADING-EXTENSION 3649 VALUE RFC822FieldList 3650 ::= id-rfc-822-field-list 3652 RFC822FieldList ::= SEQUENCE OF RFC822Field 3654 RFC822Field ::= IA5String 3656 The Object Identifier id-rfc-822-field-list is defined in 3657 Appendix D. 3659 To encode any RFC 822 Header using this extension, an 3660 RFC822Field element is built using the 822.field omitting the 3661 trailing CRLF (e.g., "Fruit-Of-The-Day: Kiwi Fruit"). All fields | 3662 shall be unfolded. There shall be no space before the ":". The 3663 reverse mapping builds the RFC 822 field in a straightforward 3664 manner. This RFC822Field is appended to the RFC822FieldList, 3665 which is added to the IPM Heading as an extension field. 3667 5.1.3. Generating the IPM 3669 The IPM (IPMS Service Request) is generated according to the 3670 rules of this section. The IPMS.IPM.body is generated from the | 3671 RFC 822 message body in the manner described in Section 5.1.5. 3673 If no specific 1988 features are used, the IPM generated is 3674 encoded as content type 2. Otherwise, it is encoded as content 3675 type 22. The latter will always be the case if extension heading 3676 fields are generated. 3678 When generating the IPM, the issue of upper bounds are | 3679 handled as follows. This approach removes a choice of options | 3680 given in RFC 1327, based on operational experience. Truncate | 3681 fields to the upper bounds specified in X.400. This will prevent | 3682 problems with UAs which enforce upper bounds, but will sometimes | 3683 discard useful information. This approach will cause more | 3684 problems for some fields than others (e.g., truncating an O/R | 3685 Address component that would be used to route a reply would be a | 3686 more severe problem than truncating a Free Form Name). If the | 3687 Free Form name is truncated, it shall be done so that it does not | 3688 break RFC 822 comments. 3690 INTERNET DRAFT 3691 MIXER DRAFT Version 2.1 3693 The rest of this section concerns IPMS.IPM.heading 3694 (IPMS.Heading). The only mandatory component of IPMS.Heading is 3695 the IPMS.Heading.this-IPM (IPMS.IPMIdentifier). A default is 3696 generated by the gateway. With the exception of "Received:", the 3697 values of multiple fields are merged (e.g., If there are two 3698 "To:" fields, then the mailboxes of both are merged to generate a 3699 single list which is used in the IPMS.Heading.primary-recipients. 3700 Information shall be generated from the standard RFC 822 Headers 3701 as follows: 3703 Date: 3704 Ignore (Handled at MTS level) 3706 Received: 3707 Ignore (Handled at MTA level) 3709 Message-Id: 3710 Mapped to IPMS.Heading.this-IPM. For these, and all other 3711 fields containing 822.msg-id the mappings of Chapter 4 are 3712 used for each 822.msg-id. 3714 From: 3715 If Sender: is present, this is mapped to 3716 IPMS.Heading.authorizing-users. If not, it is mapped to 3717 IPMS.Heading.originator. For this, and other components 3718 containing addresses, the mappings of Chapter 4 are used for 3719 each address. 3721 Sender: 3722 Mapped to IPMS.Heading.originator. 3724 Reply-To: 3725 Mapped to IPMS.Heading.reply-recipients. 3727 To: Mapped to IPMS.Heading.primary-recipients 3729 Cc: Mapped to IPMS.Heading.copy-recipients. 3731 Bcc: Mapped to IPMS.Heading.blind-copy-recipients if there is at 3732 least one BCC: recipient. If there are no recipients in 3733 this field, it should be mapped to a zero length sequence. 3735 In-Reply-To: 3736 If there is one value, it is mapped to 3738 INTERNET DRAFT 3739 MIXER DRAFT Version 2.1 3741 IPMS.Heading.replied-to-IPM, using the 822.phrase or 3742 822.msg-id mapping as appropriate. If there are several 3743 values, they are mapped to IPMS.Heading.related-IPMs, along 3744 with any values from a "References:" field. 3746 References: 3747 Mapped to IPMS.Heading.related-IPMs. 3749 Keywords: 3750 Mapped onto a heading extension. 3752 Subject: 3753 Mapped to IPMS.Heading.subject. The field-body uses the | 3754 human oriented mapping referenced in Section 3.3.4. 3756 Comments: 3757 Mapped onto a heading extension. This is a change from | 3758 1327, which specified to generate an IPMS.BodyPart of type 3759 IPMS.IA5TextBodyPart with 3760 IPMS.IA5TextBodyPart.parameters.repertoire set to the 3761 default (ia5), containing the value of the fields, preceded 3762 by the string "Comments: " and that this body part shall | 3763 precede the other one. Experience has shown that this | 3764 complexity is not justified. This text is retained to | 3765 facilitate backwards compatibility. 3767 Encrypted: 3768 Mapped onto a heading extension. 3770 Resent-* 3771 Mapped onto a heading extension. 3773 Note that it would be possible to use a ForwardedIPMessage 3774 for these fields, but the semantics are (arguably) slightly 3775 different, and it is probably not worth the effort. | 3777 Content-Language: | 3778 This fields is defined in RFC 1766 [13]. Map this onto the | 3779 IPM language extension. RFC 1766 allows for more | 3780 information than can be mapped onto the extension. If | 3781 information is lost in the mapping, a header extension shall | 3782 also be generated. 3784 Other Fields 3786 INTERNET DRAFT 3787 MIXER DRAFT Version 2.1 3789 In particular X-* fields, and "illegal" fields in common 3790 usage (e.g., "Fruit-of-the-day:") are mapped onto a heading 3791 extension, unless covered by another section or appendix of 3792 this specification. The same treatment is applied to RFC 3793 822 fields where the content of the field does not conform 3794 to RFC 822 (e.g., a Date: field with unparseable syntax). | 3796 The MIME heading are mapped as follows. They will only be | 3797 present for messages and not for other MIME content types. When | 3798 performing a reverse mapping from X.400 to MIME, these fields may | 3799 be treated as a hint to help convert the message as well as | 3800 possible. Only one value for each field shall be present in the | 3801 MIME message that is thus generated. | 3803 MIME-Version: | 3804 Mapped onto a heading extension. | 3806 Content-Transfer-Encoding: | 3807 Mapped onto a heading extension. | 3809 Content-Type | 3810 Mapped onto a heading extension. | 3812 Content-ID | 3813 Mapped onto a heading extension. | 3815 Content-Description | 3816 Mapped onto a heading extension. 3818 5.1.4. Generating the IPM Body | 3820 If the header does not contain a 822.MIME-Version field, then | 3821 generate a IPMS.Body with a single IPMS.BodyPart of type | 3822 IPMS.IA5TextBodyPart with | 3823 IPMS.IA5TextBodyPart.parameters.repertoire set to the default | 3824 (ia5) containing the body of the RFC 822 message. | 3826 If 822.MIME-Version is present, then the body part is | 3827 analysed as a MIME message and the elements treated as described | 3828 below. | 3830 5.1.4.1. Mapping Multiparts | 3832 A MIME multipart is a set of content-types and not a message with | 3834 INTERNET DRAFT 3835 MIXER DRAFT Version 2.1 3837 a set of content types. When the multipart is at the outermost | 3838 MIME header and is either multipart/digest or multipart/mixed, | 3839 elements of the multipart are mapped directly onto IPMS.BodyPart. | 3840 In other cases, a MIME multipart is mapped to an | 3841 IPMS.MessageBodyPart containing an IPMS.BodyPart for each element | 3842 of the multipart. | 3844 When a nested IPMS.Message is generated from a multipart, an | 3845 IPMS.heading shall always be generated. The only mandatory field | 3846 is the IPMS.Heading.this-IPM message id, which shall be generated | 3847 by the gateway. An IPMS.Heading.subject field shall also be | 3848 generated, in order to provide useful information to non-MIME | 3849 capable X.400(88) UAs and to all X.400(84) UAs. The subject | 3850 field is set as follows according to the multipart subtype: | 3852 mixed: "Multipart Message" 3853 alternative: "Alternative Body Parts containing the same information" 3854 digest: "Message Digest" 3855 parallel: "Body Parts interpreted in parallel" 3856 other: "Multipart Message ()" 3858 For other types of multipart, the multipart subtype shall be | 3859 included in the subject line. | 3861 For each multipart, the following IPMS.HeadingExtension shall be | 3862 generated, with the enumerated value set according to the | 3863 subtype: | 3865 multipart-message HEADING-EXTENSION 3866 VALUE MultipartType 3867 ::= id-hex-multipart-message 3869 MultipartType ::= IA5String 3871 The MultipartType contains the subtype, for example "digest". If | 3872 this heading is present when mapping from X.400 to MIME, the the | 3873 appropriate multipart may be generated. | 3875 5.1.4.2. Mapping Content Type Message | 3877 When a message subtype is contained within a MIME message, it is | 3878 mapped to an IPMS.MessageBodyPart according to this | 3879 specification. Any mappings that would have been made to the MTS | 3880 Abstract Service are placed in | 3882 INTERNET DRAFT 3883 MIXER DRAFT Version 2.1 3885 IPMS.MessageBodyPart.parameters.delivery-envelope. | 3887 Content type message has three subtypes, which are handled | 3888 as follows: | 3890 message/rfc822 | 3891 Mapped onto IPMS.ForwardedIPMessage. | 3893 message/external | 3894 This points to an external body part. As this will not in | 3895 general be accessible to the X.400 recipient, the body part | 3896 shall be resolved at the gateway. The gateway shall obtain | 3897 the body part and then map it as if it had been included. | 3898 If the expiration date of the external body part has | 3899 expired, the gateway may tunnel the body part as described | 3900 in RFC 1494. | 3902 message/partial | 3903 The following heading extension is added, derived from the | 3904 message/partial parameters, in order to facilitate MIME | 3905 capable X.400 UAs to handle messages of this type: | 3907 partial-message HEADING-EXTENSION 3908 VALUE PartialMessage 3909 ::= id-hex-partial-message 3911 PartialMessage ::= 3912 SEQUENCE { 3913 number INTEGER, 3914 total INTEGER, 3915 id IA5String 3916 } 3918 message/other | 3919 No specific treatment is defined for other subtypes of | 3920 message. Treatment for new message subtypes may be defined | 3921 in future versions of MIXER. | 3923 5.1.4.3. Mapping Other Content Types | 3925 All other MIME content types are atomic data, and can be regarded | 3926 as message attachments. | 3928 INTERNET DRAFT 3929 MIXER DRAFT Version 2.1 3931 The following basic types and some subtypes are defined in | 3932 MIME: text; application; image; audio; video. The mapping to | 3933 X.400 of the types defined in MIME is specified in RFC 1494bis. | 3935 5.1.4.4. Mapping to Body Part 15 | 3937 RFC 1494bis defines mappings onto Body Part 15. Similar | 3938 considerations apply to body parts 1-14. MIME defines two | 3939 fields which add information to MIME contents. These are | 3940 "Content-ID", and "Content-Description". When mapping to body | 3941 part 15, this information must be discarded, unless the specific | 3942 body part 15 mapping allows it to be retained. | 3944 5.1.4.5. Mapping to the EMA FTBP | 3946 EMA has defined a profile for use of the File Transfer Body Part | 3947 (FTBP) . [32] MIXER considers mapping to FTBP, as defined by | 3948 this profile. | 3950 The exact mapping will depend on the attachment being | 3951 mapped, and so cannot be defined here. The MIME headers are | 3952 mapped as follows: | 3954 Content-ID: | 3955 If this is present, create an element | 3956 FTBP.FileTransferParameters.related-stored-file. file- | 3957 identifier.cross-refernce.message-reference | 3958 FTBP.FileTransferParameters.related-stored-file. file- | 3959 identifier.cross-refernce.message-reference and set it to | 3960 the IPM.MessageIdentifier derived from the "Content-ID:". | 3961 FTBP.FileTransferParameters.related-stored-file. | 3962 relationship.descriptive-relationship is set to the string | 3963 "Internet MIME Body Part". | 3964 FTBP.FileTransferParameters.related-stored-file. file- | 3965 identifier.cross-refernce.application-crossreference is set | 3966 to a null OCTET STRING. | 3968 Content-Descriptor: | 3969 This is mapped to the first string in | 3970 FTBP.FileTransferParameters.environment.user-visible-string. | 3972 5.1.4.6. Encapsulation in X.400 | 3974 Where no mapping is possible, the gateway may choose to discard | 3976 INTERNET DRAFT 3977 MIXER DRAFT Version 2.1 3979 the body part or to reject the message. This will depend on | 3980 gateway policy, and configuration knowledge. Another option is | 3981 to "tunnel" the body part, by encapsulating it in X.400. This | 3982 section defines an extended body part, based on body part 15, | 3983 which may be used to hold any MIME content. | 3985 mime-body-part EXTENDED-BODY-PART-TYPE 3986 PARAMETERS MimeParameters 3987 IDENTIFIED BY id-mime-body-part-parameters 3988 DATA OCTET STRING 3989 ::= id-mime-body-part 3991 MimeParameters ::= 3992 SEQUENCE { 3993 content-type IA5String, 3994 content-parameters SEQUENCE OF 3995 SEQUENCE { 3996 parameter IA5String, 3997 parameter-value IA5String 3998 } 3999 other-header-fields RFC822FieldList 4000 } 4002 The OBJECT IDENTIFIERS id-mime-body-part and id-mime-parameters | 4003 are defined in Appendix D. A MIME content is mapped onto this | 4004 body part. The MIME headers of the body part are mapped as | 4005 follows: | 4007 Content-Type: | 4008 The "type/subtype" string is mapped to | 4009 MimeParameters.content-type. | 4011 For each "parameter=value" string create a | 4012 MimeParameters.content-parameters element. The | 4013 MimeParameters.content-Parameters.parameter field is set to | 4014 the parameter and the | 4015 MimeParameters.content-parameters.parameter-value field is | 4016 set to the value. | 4018 OtherTake all other headers and create | 4019 MimeParameters.other-header-fields, by concatenating them | 4020 together. | 4022 INTERNET DRAFT 4023 MIXER DRAFT Version 2.1 4025 Convert the MIME body part into its canonical form, as specified | 4026 in Appendix H of MIME [14]. This canonical form is used to | 4027 generate the mime-body-part.data octet string. | 4029 The Parameter mapping may be used independently of the body | 4030 part mapping (e.g., in order to use a different encoding is used | 4031 for the body part). | 4033 This body part contains all of the MIME information, and so | 4034 can be mapped back to MIME without loss of information. | 4036 5.1.5. Mappings to the MTS Abstract Service 4038 The MTS.MessageSubmissionEnvelope comprises 4039 MTS.PerMessageSubmissionFields, and 4040 MTS.PerRecipientMessageSubmissionFields. The mandatory 4041 parameters are defaulted as follows. 4043 MTS.PerMessageSubmissionFields.originator-name 4044 This is always generated from 822-MTS, as defined in 4045 Chapter 4. 4047 MTS.PerMessageSubmissionFields.content-type 4048 Set to the value implied by the encoding of the IPM (2 or 4049 22). 4051 MTS.PerRecipientMessageSubmissionFields.recipient-name 4052 These will always be supplied from 822-MTS, as defined in 4053 Chapter 4. 4055 Optional components are omitted, and default components 4056 defaulted. This means that disclosure of recipients is 4057 prohibited and conversion is allowed. There are two exceptions 4058 to the defaulting. For 4059 MTS.PerMessageSubmissionFields.per-message-indicators, the 4060 following settings are made: 4062 - Alternate recipient is allowed, as it seems desirable to 4063 maximise the opportunity for (reliable) delivery. 4065 - Content return request is set according to the issues 4066 discussed in Section 5.2. 4068 MTS.PerMessageSubmissionFields.original-encoded-information-types 4070 INTERNET DRAFT 4071 MIXER DRAFT Version 2.1 4073 is a set of one element BuiltInEncodedInformationTypes.ia5-text. 4075 The MTS.PerMessageSubmissionFields.content-correlator is encoded 4076 as IA5String, and contains the Subject:, Message-ID:, Date:, and 4077 To: fields (if present). This includes the strings "Subject:", 4078 "Date:", "To:", "Message-ID:", and appropriate folding. This 4079 shall be truncated to MTS.ub-content-correlator-length (512) 4080 characters. In addition, if there is a "Subject:" field, the 4081 MTS.PerMessageSubmissionFields.content-identifier, is set to a 4082 printable string representation of the contents of it. If the 4083 length of this string is greater than MTS.ub-content-id-length 4084 (16), it should be truncated to 13 characters and the string 4085 "..." appended. Both are used, due to the much larger upper bound 4086 of the content correlator, and that the content id is available 4087 in X.400(1984). 4089 5.1.6. Mappings to the MTA Abstract Service 4091 There is a need to map directly onto some aspects of the MTA 4092 Abstract service, for the following reasons: 4094 - So the the MTS Message Identifier can be generated from the 4095 RFC 822 Message-ID:. 4097 - So that the submission date can be generated from the 4098 822.Date. 4100 - To prevent loss of trace information 4102 - To prevent RFC 822/X.400 looping caused by distribution 4103 lists or redirects 4105 The following mappings are defined. 4107 Message-Id: 4108 If this is present, the 4109 MTA.PerMessageTransferFields.message-identifier is generated 4110 from it, using the mappings described in Chapter 4. | 4112 This mapping arguably generates messages which do not | 4113 conform to US GOSIP, which states: | 4115 INTERNET DRAFT 4116 MIXER DRAFT Version 2.1 4118 6.7.e MPDI Identifier Validation 4120 (1) Validation of the GlobalDomainIdentifier component of the MPDU 4121 Identifier is performed on reception of a message (i.e. the result 4122 of a TRANSFER.Indication). 4123 (2) The country name should be known to the validating domain, and 4124 depending on the country name, validation of the ADMD name may also 4125 be possible. 4126 (3) Additional validation of the GlobalDomainIdentifier is performed 4127 against the corresponding first entry in the TraceInformation. If 4128 inconsistencies are found during the comparison, a non-delivery 4129 notice with the above defined reason and diagnosticcode is 4130 generated. 4131 (4) A request will be generated to the CCITT for a more meaningful 4132 diagnostic code (such as "InconsistentMPUTIdentifier"). 4134 This applies to ADMDs only, and is specified in the 1984 | 4135 version and not the 1988 version. Conformance depends on the | 4136 interpretation of "inconsistency". The specification makes | 4137 the most sensible choice, and so is not being changed in the | 4138 update from RFC 1327. 4140 Date: 4141 This is used to set the first component of 4142 MTA.PerMessageTransferFields.trace-information 4143 (MTA.TraceInformationElement). The 822-MTS originator is 4144 mapped into an MTS.ORAddress, and used to derive 4145 MTA.TraceInformationElement.global-domain-identifier. The 4146 optional components of 4147 MTA.TraceInformationElement.domain-supplied-information are 4148 omitted, and the mandatory components are set as follows: 4150 MTA.DomainSuppliedInformation.arrival-time 4151 This is set to the date derived from Date: 4153 MTA.DomainSuppliedInformation.routing-action 4154 Set to relayed. 4156 The first element of 4157 MTA.PerMessageTransferFields.internal-trace-information is 4158 generated in an analogous manner, although this can be 4159 dropped later in certain circumstances (see the procedures 4161 INTERNET DRAFT 4162 MIXER DRAFT Version 2.1 4164 for "Received:"). The 4165 MTA.InternalTraceInformationElement.mta-name is derived from 4166 the 822.domain in the 822 MTS Originator address. 4168 Received: 4169 All RFC 822 trace is used to derive 4170 MTA.PerMessageTransferFields.trace-information and 4171 MTA.PerMessageTransferFields.internal-trace-information. 4172 Processing of Received: lines follows processing of Date:, 4173 and is be done from the the bottom to the top of the RFC 822 4174 header (i.e., in chronological order). When other trace | 4175 elements (in particular X400-Received:) are processed the 4176 relative ordering shall be retained correctly. The initial 4177 element of MTA.PerMessageTransferFields.trace-information 4178 will be generated already (from Date:), unless the message 4179 has previously been in X.400, when it will be derived from 4180 the X.400 trace information. 4182 Consider the Received: field in question. If the "by" part 4183 of the received is present, use it to derive an 4184 MTS.GlobalDomainIdentifier. If this is different from the 4185 one in the last element of 4186 MTA.PerMessageTransferFields.trace-information 4187 (MTA.TraceInformationElement.global-domain-identifier) 4188 create a new MTA.TraceInformationElement, and optionally 4189 remove 4190 MTA.PerMessageTransferFields.internal-trace-information. 4191 This removal shall be done in cases where the message is 4192 being transferred to another MD where there is no bilateral 4193 agreement to preserve internal trace beyond the local MD. 4194 The trace creation is as for internal trace described below, 4195 except that no MTA field is needed. 4197 Then add a new element (MTA.InternalTraceInformationElement) 4198 to MTA.PerMessageTransferFields.internal-trace-information, 4199 creating this if needed. This shall be done, even if 4200 inter-MD trace is created. The 4201 MTA.InternalTraceInformationElement.global-domain-identifier 4202 is set to the value derived. The 4203 MTA.InternalTraceInformationElement.mta-supplied-information 4204 (MTA.MTASuppliedInformation) is set as follows: 4206 MTA.MTASuppliedInformation.arrival-time 4207 Derived from the date of the Received: line 4209 INTERNET DRAFT 4210 MIXER DRAFT Version 2.1 4212 MTA.MTASuppliedInformation.routing-action 4213 Set to relayed 4215 The MTA.InternalTraceInformationElement.mta-name is taken 4216 from the "by" component of the "Received:" field, truncated 4217 to MTS.ub-mta-name-length (32). For example: 4219 Received: from computer-science.nottingham.ac.uk by 4220 vs6.Cs.Ucl.AC.UK via Janet with NIFTP id aa03794; 4221 28 Mar 89 16:38 GMT 4223 Generates the string 4225 vs6.Cs.Ucl.AC.UK 4227 Note that before transferring the message to some ADMDs, 4228 additional trace stripping may be required, as the implied path 4229 through multiple MDs would violate ADMD policy. This will 4230 depend on bilateral agreement with the ADMD. | 4232 The gateway itself shall not add trace information. | 4233 However, for trace purposes, the gateway shall be considered as | 4234 an X.400 and Internet MTA back to back, and both of these shall | 4235 add trace elements. 4237 5.1.7. Mapping New Fields 4239 This specification defines a number of new fields for Reports, 4240 Notifications and IP Messages in Section 5.3. As this 4241 specification only aims to preserve existing services, a gateway 4242 conforming to this specification does not need to map all of 4243 these fields to X.400. 4245 Two extended fields must be mapped, in order to prevent 4246 looping. "DL-Expansion-History:" is mapped to 4247 MTA.PerMessageTransferFields.extensions.dl-expansion-history 4248 X400-Received: must be mapped to 4249 MTA.PerMessageTransferFields.trace-information and 4250 MTA.PerMessageTransferFields.internal-trace-information. In 4251 cases where X400-Received: is present, the usual mapping of Date: 4252 to generate the first element of trace should not be done. This 4253 is because the message has come from X.400, and so the first 4255 INTERNET DRAFT 4256 MIXER DRAFT Version 2.1 4258 element of trace can be taken from the first X400-Received:. 4260 The following fields shall not be mapped, and shall be | 4261 discarded: 4263 - Discarded-X400-MTS-Extensions: 4265 - Message-Type: 4267 - Discarded-X400-IPMS-Extensions: * 4269 - X400-Content-Type: 4271 - X400-Originator: 4273 - X400-Recipients: 4275 - X400-MTS-Identifier: 4277 Other fields may be either discarded or mapped to X.400. It 4278 is usually desirable and beneficial to do map, particularly to 4279 facilitate support of a message traversing multiple gateways. 4280 These mappings may be onto MTA, MTS, or IPMS services. The level 4281 of support for this reverse mapping should be indicated in the | 4282 Gateway conformance statement. | 4284 5.1.8. Mapping Delivery Status Notifications to X.400 | 4286 5.1.8.1. Basic Model | 4288 Internet Mail delivery status notifications (DSN) are mapped to | 4289 X.400 delivery reports. With message mapping, information | 4290 without a mapping is carried by and IPM Extension. This cannot | 4291 be done for delivery reports. Two mechanisms are used for | 4292 information where there is not a direct mapping. | 4294 The first mechanism is to define extensions, which allow all | 4295 of the DSN information to be carried in the delivery report. | 4296 This is not completely satisfactory for two reasons: | 4298 1. User defined extensions are supported by the ISO version of | 4299 the standard, but not the CCITT one. Therefore, | 4300 implementation support for these extensions will not be | 4302 INTERNET DRAFT 4303 MIXER DRAFT Version 2.1 4305 universal. | 4307 2 X.400 User Agent implementations will not in general | 4308 recognise these extensions. Therefore, although the | 4309 information will be present, it will not be available. | 4310 This may be very problematic, as this information may be | 4311 critical to diagnosing the reason for a failure. | 4313 Therefore a second mechanism is defined. This shall always | 4314 be used when the DSN contains non-delivery information, and may | 4315 be used in other cases. This mechanism is to map the whole DSN | 4316 (as if it was an ordinary multipart) into the return of content. | 4317 This will make the DSN information available as a text body part | 4318 in the outer message, with the real returned content as an | 4319 enclosed message. This mechanism will ensure that information is | 4320 not lost at the gateway. | 4322 5.1.8.2. DSN Extensions | 4324 Two X.400 MTS extensions are defined as follows: | 4326 dsn-header-list EXTENSION 4327 RFC822FieldList 4328 ::= id-dsn-header-list 4330 dsn-field-list EXTENSION 4331 RFC822FieldList 4332 ::= id-dsn-field-list 4334 The Object Identifiers id-dsn-heade-list and id-dsn-field-list | 4335 are defined in Appendix D. These extension is used in the same | 4336 way as the IPM extension rfc-822-field, described in Section | 4337 5.1.2. | 4339 5.1.8.3. DSN to Delivery Report Mapping | 4341 Reports may not be submitted in the X.400 model, and so the | 4342 report submission is considered in terms of the MTA Abstract | 4343 Service. An MTA.Report is constructed. The | 4344 MTA.ReportTransferFields.report-identifier is generated from the | 4345 Message-Id of the DSN (if present) and otherwise generated as the | 4346 MTA would generate one for a submitted message. | 4348 INTERNET DRAFT 4349 MIXER DRAFT Version 2.1 4351 The DSN has an RFC 822 header. Trace is mapped in the same | 4352 manner as for a message to | 4353 MTA.ReportTransferEnvelope.trace-information. All other headers | 4354 are used to create a dsn-header-list extension, which is added to | 4355 MTA.ProbeTransferFields.extensions. | 4357 The DSN will have a single 822-MTS recipient. This is | 4358 mapped to the %MTA.ReportTransferEnvelope.report-destination- | 4359 name. | 4361 The DSN is then treated as a normal MIME message, and an | 4362 X.400 IPM is generated. This IPM is used as | 4363 MTA.PerReportTransferFields.returned-content, and its type is | 4364 used to set MTA.PerReportTransferFields.content-type. The DSN | 4365 body part is mapped as if it was IA5 text/plain. | 4367 All other mappings are made from the DSN body part. A dsn- | 4368 field-list extension is created and added to | 4369 MTA.ReportTransferFields.extensions. This is referred to as the | 4370 per report extension list. The DSN.per-message-fields are mapped | 4371 as follows: | 4373 original-envelope-id-field | 4375 reporting-mta-field | 4377 dsn-gateway-field | 4379 received-from-mta-field | 4381 arrival-date-field | 4383 extension-field | 4385 other | 4386 All of these fields are added to the per report extension | 4387 list. Currently there are no other mappings defined. | 4389 Each reported recipient is considered in turn, and a | 4390 MTA.PerRecipientReportTransferFields created for each. The | 4391 parameters of this are defaulted as follows: | 4393 originally-specified-recipient-number | 4394 In general, these are not available, and so are assigned | 4396 INTERNET DRAFT 4397 MIXER DRAFT Version 2.1 4399 incrementally. | 4401 last-trace-information | 4402 The arrival-time is generated from the Date: of the DSN. | 4404 A dsn-field-list extension is created and added to | 4405 MTA.PerRecipientTransferFields.extensions. This is referred to | 4406 as the per recipient extension list. The | 4407 DSN.per-recipient-fields are mapped as follows | 4409 original-recipient-field | 4410 Mapped to | 4411 MTA.PerRecipientReportTransferFields.originally-intended-recipient-name.| 4413 final-recipient-field | 4414 Mapped to | 4415 MTA.PerRecipientReportTransferFields.actual-recipient-name. | 4417 action-field | 4418 If this is set to "failed", a non-delivery report is | 4419 generated. Otherwise a delivery report is generated. Bit | 4420 one or two of | 4421 MTA.PerRecipientTransferFields.per-recipient-indicators is | 4422 set accordingly. This also controls the encoding of | 4423 MTA.PerRecipientTransferFields.last-trace-information, and | 4424 the selection of the report type. | 4426 status-field | 4427 This is added to the per report extension list. For non- | 4428 delivery, it is also used to generate the reason and | 4429 diagnostic codes contained within | 4430 MTA.PerRecipientReportTransferFields.last-trace. The | 4431 mappings are defined below. | 4433 remote-mta-field | 4435 diagnostic-code-field | 4437 last-attempt-date-field | 4439 will-retry-until-field | 4441 extension-field | 4443 INTERNET DRAFT 4444 MIXER DRAFT Version 2.1 4446 other | 4447 All of these fields are added to the per report extension | 4448 list. | 4450 5.1.8.4. Status Value Mappings | 4452 Status values are mapped to X.400 reason and diagnostic codes as | 4453 follows. | 4455 DSN code Meaning X400 C/D Meaning 4457 X.0.0 Other status 1/None 4459 X.1.0 Other Address Status 1/None 4460 X.1.1 Bad mailbox address 1/0 Unrecognized 4461 X.1.2 Bad system address 1/0 Unrecognized 4462 X.1.3 Bad mailbox address syntax 1/0 Unrecognized 4463 X.1.4 Mailbox address ambiguous 1/1 4465 X.2.0 Other or undefined mailbox status 1/None 4466 X.2.1 Mailbox disabled, not accepting 1/4 Recipient unavailable 4467 X.2.2 Mailbox full 1/4 4468 X.2.3 Message length exceeds admin limit. 1/7 Content too long 4469 X.2.4 Mailing list expansion problem 1/30 DL expansion failure 4471 X.3.0 Other or undefined system status 0/None 4472 X.3.1 System full 1/2 MTS congestion 4473 X.3.2 System not accepting network messages 1/2 MTS congestion 4474 X.3.3 System not capable of selected feat 1/18 Unsupp. crit. func 4475 X.3.4 Message too big for system 1/7 4477 X.4.0 Other or undefined network or routing 0/None 4478 X.4.1 No answer from host 0/None 4479 X.4.2 Bad connection 0/None 4480 X.4.3 Routing server failure 6/None Directory op unsucc. 4481 X.4.4. Unable to route 0/None 4482 X.4.5 Network congestion 1/2 MTS congest. 4483 X.4.6 Routing loop detected 1/3 4484 X.4.7 Delivery time expired 1/5 4486 INTERNET DRAFT 4487 MIXER DRAFT Version 2.1 4489 X.5.0 Other or undefined protocol status 1/None 4491 X.5.1 Invalid command 1/14 Protocol viol. 4492 X.5.2 Syntax error 1/14 4493 X.5.3 Too many recipients 1/16 4494 X.5.4 Invalid command arguments 1/14 4495 X.5.5 Wrong protocol version 1/18 Unsupp.crit.func 4497 X.6.0 Other or undefined media error 2/None Conv. not perf 4498 X.6.1 Media not supported 1/6 EIT unsupp. 4499 X.6.2 Conversion required and prohibited 1/9 4500 X.6.3 Conversion required but not supported 2/8 4501 X.6.4 Conversion with loss performed POSITIVE only 4503 X.7.0 Other or undefined security status 1/46 4504 X.7.1 Delivery not authorized, message ref 1/29 No DL submit perm 4505 X.7.2 Mailing list expansion prohibited 1/28 4506 X.7.3 Security conversion req but not poss 1/46 Secure mess. error 4507 X.7.4 Security features not supported 1/46 4508 X.7.5 Cryptographic failure 1/46 4509 X.7.6 Cryptographic algorithm not supported 1/46 4510 X.7.7 Message integrity failure 1/46 4512 5.1.8.5. DSNs that originated in X.400 | 4514 The mapping of X.400 delivery reports to DSNs will in general | 4515 provide sufficient information to make a useful reverse mapping. | 4516 Messages will often be mapped multiple times, commonly due to | 4517 forwarding messages and to distribution lists. Multiple | 4518 mappings for delivery reports will be a good deal less common. | 4519 For this reason, the reverse mapping of the X.400 DSN extensions | 4520 defined in MIXER is optional. 4522 5.2. Return of Contents 4524 It is not clear how widely supported the X.400 return of contents 4525 service will be. Experience with X.400(1984) suggests that 4526 support of this service may not be universal. As this service is 4527 expected in the RFC 822 world, two approaches are specified. The 4528 choice will depend on the use of X.400 return of contents withing 4529 the X.400 community being serviced by the gateway. 4531 INTERNET DRAFT 4532 MIXER DRAFT Version 2.1 4534 In environments where return of contents is widely 4535 supported, content return can be requested as a service. The 4536 content return service can then be passed back to the end (RFC 4537 822) user in a straightforward manner. 4539 In environments where return of contents is not widely 4540 supported, a gateway must make special provision to handle return 4541 of contents. For every message passing from RFC 822 -> X.400, 4542 content return request will not be requested, and report request 4543 always will be. When the delivery report comes back, the gateway 4544 can note that the message has been delivered to the recipient(s) 4545 in question. If a non-delivery report is received, a meaningful 4546 report (containing some or all of the original message) can be 4547 sent to the 822-MTS originator. If no report is received for a 4548 recipient, a (timeout) failure notice shall be sent to the 4549 822-MTS originator. The gateway may retransmit the X.400 message 4550 if it wishes. When this approach is taken, routing must be set 4551 up so that error reports are returned through the same MTA. 4552 This approach may be difficult to use in conjunction with some 4553 routing strategies. 4555 5.3. | 4556 X.400 -> RFC 822: Detailed Mappings 4558 5.3.1. Basic Approach 4560 A single RFC 822 message is generated from the incoming IP 4561 Message, Report, or IP Notification. All IPMS.BodyParts are 4562 mapped onto a single RFC 822 body. Other services are mapped 4563 onto RFC 822 header fields. Where there is no appropriate 4564 existing field, new fields are defined for IPMS, MTS and MTA 4565 services. 4567 The gateway mechanisms will correspond to MTS Delivery. As 4568 with submission, there are aspects where the MTA (transfer) 4569 services are also used. In particular, there is an optimisation 4570 to allow for multiple 822-MTS recipients. 4572 5.3.2. RFC 822 Settings 4574 An RFC 822 Service requires to have a number of mandatory fields 4575 in the RFC 822 Header. Some 822-MTS services mandate 4576 specification of an 822-MTS Originator. Even in cases where this 4577 is optional, it is usually desirable to specify a value. The 4579 INTERNET DRAFT 4580 MIXER DRAFT Version 2.1 4582 following defaults are defined, which shall be used if the 4583 mappings specified do not derive a value: 4585 822-MTS Originator 4586 If this is not generated by the mapping (e.g., for a 4587 Delivery Report), a value pointing at a gateway 4588 administrator shall be assigned. 4590 Date: 4591 A value will always be generated 4593 From: | 4594 If this is not generated by the mapping, it is assigned 4595 equal to the 822-MTS Originator. If this is gateway 4596 generated, an appropriate 822.phrase shall be added. 4598 At least one recipient field 4599 If no recipient fields are generated, a field "To: list:;", 4600 shall be added. 4602 This will ensure minimal RFC 822 compliance. When generating RFC 4603 822 headers, folding may be used. It is recommended to do this, 4604 following the guidelines of RFC 822. 4606 5.3.3. Basic Mappings 4608 5.3.3.1. Encoded Information Types 4610 This mapping from MTS.EncodedInformationTypes is needed in 4611 several disconnected places. EBNF is defined as follows: 4613 INTERNET DRAFT 4614 MIXER DRAFT Version 2.1 4616 encoded-info = 1#encoded-type 4618 encoded-type = built-in-eit / object-identifier 4620 built-in-eit = "Undefined" ; undefined (0) 4621 / "Telex" ; tLX (1) 4622 / "IA5-Text" ; iA5Text (2) 4623 / "G3-Fax" ; g3Fax (3) 4624 / "TIF0" ; tIF0 (4) 4625 / "Teletex" ; tTX (5) 4626 / "Videotex" ; videotex (6) 4627 / "Voice" ; voice (7) 4628 / "SFD" ; sFD (8) 4629 / "TIF1" ; tIF1 (9) 4631 MTS.EncodedInformationTypes is mapped onto EBNF.encoded-info. 4632 MTS.EncodedInformationTypes.non-basic-parameters is ignored. 4633 Built in types are mapped onto fixed strings (compatible with 4634 X.400(1984) and RFC 987), and other types are mapped onto 4635 EBNF.object-identifier. 4637 5.3.3.2. Global Domain Identifier 4639 The following simple EBNF is used to represent 4640 MTS.GlobalDomainIdentifier: 4642 global-id = std-or-address 4644 This is encoded using the std-or-address syntax, for the 4645 attributes within the Global Domain Identifier. 4647 5.3.4. Mappings from the IP Message 4649 Consider that an IPM has to be mapped to RFC 822. The IPMS.IPM 4650 comprises an IPMS.IPM.heading and IPMS.IPM.body. The heading is 4651 considered first. Some EBNF for new fields is defined: 4653 INTERNET DRAFT 4654 MIXER DRAFT Version 2.1 4656 ipms-field = "Obsoletes" ":" 1#msg-id 4657 / "Expiry-Date" ":" date-time 4658 / "Reply-By" ":" date-time 4659 / "Importance" ":" importance 4660 / "Sensitivity" ":" sensitivity 4661 / "Autoforwarded" ":" boolean 4662 / "Incomplete-Copy" ":" 4663 / "Language" ":" 1#language | 4664 / "Message-Type" ":" message-type 4665 / "Discarded-X400-IPMS-Extensions" ":" 1#object-identifier| 4666 / "Autosubmitted" ":" autosubmitted | 4668 importance = "low" / "normal" / "high" 4670 sensitivity = "Personal" / "Private" / 4671 "Company-Confidential" 4673 language = 2*ALPHA [ language-description ] 4674 language-description = printable-string 4676 message-type = "Delivery Report" | 4677 / "InterPersonal Notification" 4678 / "Multiple Part" 4680 autosubmitted = "not-auto-submitted" 4681 / "auto-generated" 4682 / "auto-replied" 4683 / "auto-forwarded" 4685 The mappings and actions for the IPMS.Heading is now specified | 4686 for each element. Addresses, and Message Identifiers are mapped 4687 according to Chapter 4. Other mappings are explained, or are 4688 straightforward (algorithmic). If a field with addresses 4689 contains zero elements, it should be discarded, except for | 4690 IPMS.Heading.blind-copy-recipients, which can be mapped onto BCC: 4691 (the only RFC 822 field which allows zero recipients). 4693 INTERNET DRAFT 4694 MIXER DRAFT Version 2.1 4696 IPMS.Heading.this-IPM 4697 Mapped to "Message-ID:". 4699 IPMS.Heading.originator 4700 If IPMS.Heading.authorizing-users is present this is mapped 4701 to Sender:, if not to "From:". 4703 IPMS.Heading.authorizing-users 4704 Mapped to "From:". 4706 IPMS.Heading.primary-recipients 4707 Mapped to "To:". 4709 IPMS.Heading.copy-recipients 4710 Mapped to "Cc:". 4712 IPMS.Heading.blind-copy-recipients 4713 Mapped to "Bcc:". 4715 IPMS.Heading.replied-to-ipm 4716 Mapped to "In-Reply-To:". 4718 IPMS.Heading.obsoleted-IPMs 4719 Mapped to the extended RFC 822 field "Obsoletes:" 4721 IPMS.Heading.related-IPMs 4722 Mapped to "References:". 4724 IPMS.Heading.subject 4725 Mapped to "Subject:". The contents are converted to ASCII | 4726 or T.61 (as defined in Section 3.5). Any CRLF are not 4727 mapped, but are used as points at which the subject field 4728 must be folded. 4730 IPMS.Heading.expiry-time 4731 Mapped to the extended RFC 822 field "Expiry-Date:". 4733 IPMS.Heading.reply-time 4734 Mapped to the extended RFC 822 field "Reply-By:". 4736 IPMS.Heading.reply-recipients 4737 Mapped to "Reply-To:". 4739 IPMS.Heading.importance 4741 INTERNET DRAFT 4742 MIXER DRAFT Version 2.1 4744 Mapped to the extended RFC 822 field "Importance:". 4746 IPMS.Heading.sensitivity 4747 Mapped to the extended RFC 822 field "Sensitivity:". 4749 IPMS.Heading.autoforwarded 4750 Mapped to the extended RFC 822 field "Autoforwarded:". 4752 The standard extensions (Annex H of X.420 / ISO 10021-7) are 4753 mapped as follows: 4755 incomplete-copy 4756 Mapped to the extended RFC 822 field "Incomplete-Copy:". | 4758 language | 4759 Mapped to the RFC 822 field "Content-Language:", defined in | 4760 RFC 1766 [13]. This mapping may be made without loss of | 4761 information. | 4763 auto-submitted | 4764 Map to the extended RFC 822 field "Autosubmitted:". 4766 If the RFC 822 extended header is found, this shall be 4767 mapped onto an RFC 822 header, as described in Section 5.1.2. 4769 If a non-standard extension is found, it shall be discarded, 4770 unless the gateway understands the extension and can perform an 4771 appropriate mapping onto an RFC 822 header field. If extensions 4772 are discarded, the list is indicated in the extended RFC 822 4773 field "Discarded-X400-IPMS-Extensions:". | 4775 5.3.4.1. Mapping the IPMS Body | 4777 The IPMS.Body is mapped into the RFC 822 message body. If the | 4778 IPMS.Body consists of a single IPMS.Bodypart, there are three | 4779 possibilities. | 4781 1. If it is of type IPMS.IA5Text, then this is mapped directly | 4782 and no MIME encoding is used. | 4784 2. If it is of type IPMS.MessageBodyPart, then a MIME message | 4785 with content type message/rfc822 is generated, following the | 4786 mappings described for IPMS.BodyPart given below. | 4788 INTERNET DRAFT 4789 MIXER DRAFT Version 2.1 4791 3. The mapping of other body parts is specified below. | 4793 If the IPMS.Body contains multiple IPMS.BodyPart fields, then a | 4794 MIME message of content type multipart is generated. If all of | 4795 the body parts are messages, then this is multipart/digest. | 4796 Otherwise it is multipart/mixed. The components of the multipart | 4797 are generated in the same order as in the IPMS.Body. Body parts | 4798 which are not messages are mapped according to RFC 1494. 4800 To map an IPMS.MessageBodyPart, the full X.400 -> RFC 822 | 4801 mapping is recursively applied, to generate an RFC 822 Message. 4802 If present, the IPMS.MessageBodyPart.parameters.delivery-envelope 4803 is used for the MTS Abstract Service Mappings. If present, the 4804 IPMS.MessageBodyPart.parameters.delivery-time is mapped to the 4805 extended RFC 822 field "Delivery-Date:". | 4807 To support X.400(1984) mappings of Internet Messages, the | 4808 following procedure shall also be followed. If there is more | 4809 than one body part, and the first body part is IA5 starts with | 4810 the string "RFC-822-Headers:" as the first line, then the | 4811 remainder of this body part shall be appended to the RFC 822 | 4812 header. | 4814 5.3.4.2. Mapping Body Parts | 4816 X.400 and MIME define extensible approaches for body parts, and | 4817 the ability to map a specific body part depends on the gateway's | 4818 knowledge. Mapping of all standard X.400 body parts, and some | 4819 extended body parts is defined in RFC 1494bis. | 4821 The case of File Transfer Body Part (FTBP) is described | 4822 below. | 4824 Where no mapping is known by the gateway, it may choose to | 4825 drop the body part, or reject the message. It may also | 4826 encapsulate the body part in a mechanism which can be used for | 4827 any extended X.400 body part. This is specified below. The | 4828 option will depend on the gateway configuration and its knowledge | 4829 of the recipient capabilities. | 4831 5.3.4.3. File Transfer Body Part | 4833 X.400 specifies a file transfer body part (FTBP). Generic | 4834 mapping of FTBP is beyond the scope of MIXER. EMA have defined | 4836 INTERNET DRAFT 4837 MIXER DRAFT Version 2.1 4839 a profile of FTBP to carry attachments . MIXER defines a mapping | 4840 of FTBP to MIME, which is intended for use in conjunction with | 4841 this profile. FTBP is used to carry various pieces of | 4842 information associated with an attachment. The key mapping will | 4843 be to correctly convert the contents of the attachment. This | 4844 specification also provides a mechanism for mapping the | 4845 parameters which EMA have recommended to be used in version 1.4 | 4846 of the specification. A BNF is defined below: | 4848 ftbp-field = "FTBP-Pathname" ":" *text 4849 / "FTBP-Object-Size" ":" integer 4850 / "FTBP-Creation-Date" ":" date-time 4851 / "FTBP-Modification-Date" ":" date-time 4852 "FTBP-Read-Date" ":" date-time 4854 Some parameters are encoded as graphical string. To map | 4855 these to ASCII, those characters that map directly are mapped, | 4856 and others are translated to "?". This simple non-reversible | 4857 mapping is seen as appropriate for the application, and in line | 4858 with the spirit of the EMA profile. | 4860 Mapping of the data will be dependent on the attachment, its | 4861 encoding, and the MIME representation. These cannot be | 4862 specified here. | 4864 Other FTBP Parameters are mapped as follows: | 4866 FileTransferParameters.environment.user-visible-string | 4867 This is mapped to the "Content-Descriptor:" header. | 4869 The following elements of FileTransferParameters.file-attributes | 4870 are mapped as follows: | 4872 pathname | 4873 Mapped to "FTBP-Pathname". It is expected that only the | 4874 incomplete option will be found, but the mapping is used for | 4875 either variant. The separator between multiple components | 4876 is "/". | 4878 date-and-time-of-creation | 4879 Mapped to "FTBP-Creation-Date:". | 4881 date-and-time-of-last-modification | 4883 INTERNET DRAFT 4884 MIXER DRAFT Version 2.1 4886 Mapped to "FTBP-Modification-Date:". | 4888 date-and-time-of-last-read-access | 4889 Mapped to "FTBP-Read-Date:". | 4891 object-size | 4892 Mapped to "FTBP-Object-Size:". | 4894 5.3.4.4. Tunnelling X.400 Body Parts | 4896 This section specifies a generic mechanism to map X.400 body | 4897 parts to a MIME content. This allows for the body part to be | 4898 tunnelled through MIME. It may also be used directly by an | 4899 appropriately configured MIME UA. | 4901 This content-type is defined to carry any X.400 extended | 4902 body part. The mapping of all standard X.400 body parts is | 4903 defined in RFC1494bis. The content-type field is | 4904 "application/x400-bp". The parameter is defined by the EBNF: | 4906 mime-parameter = "bp-type=" object-identifier 4908 The EBNF.object-identifier is set to the OBJECT IDENTIFIER | 4909 from IPMS.body.externally-defined.data.direct-reference . | 4911 For example, a Videotex body part will have 4913 Content-type=application/x400-bp; bp-type=2.6.1.4.5 | 4915 The body contains the raw ASN.1 IPM.body octet stream, | 4916 including the initial tag octet. The content may use a content- | 4917 transfer-encoding of either base64 or quoted-printable when | 4918 carried in 7-bit MIME. It is recommended to use the one which | 4919 gives the more compact encoding of the data. If this cannot be | 4920 determined, Base64 is recommended. No attempt is made to turn | 4921 the parameters of Extended Body Parts into MIME parameters, as | 4922 this cannot be done in a general manner. 4924 Standard X.400 body parts may not be encoded directly by | 4925 this mechanism, but may be encoded indirectly by first | 4926 translating to the extended representation. | 4928 INTERNET DRAFT 4929 MIXER DRAFT Version 2.1 4931 Editor's | 4932 I've changed this from RFC 1494. I think that is much | 4933 cleaner and better. We should review this choice. | 4935 5.3.4.5. Example Message | 4937 An example message, illustrating a number of aspects is given 4938 below. 4940 INTERNET DRAFT 4941 MIXER DRAFT Version 2.1 4943 Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP * 4944 id <7906-0@bells.cs.ucl.ac.uk>; Thu, 30 May 1991 18:24:55 +0100 4945 X400-Received: by mta "mhs-relay.ac.uk" in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; 4946 Thu, 30 May 1991 18:23:26 +0100 4947 X400-Received: by /PRMD=HMG/ADMD=GOLD 400/C=GB/; Relayed; 4948 Thu, 30 May 1991 18:20:27 +0100 4949 Message-Type: Multiple Part 4950 Date: Thu, 30 May 1991 18:20:27 +0100 4951 X400-Originator: Stephen.Harrison@gosip-uk.hmg.gold-400.gb 4952 X400-MTS-Identifier: 4953 [/PRMD=HMG/ADMD=GOLD 400/C=GB/;PC1000-910530172027-57D8] 4954 Original-Encoded-Information-Types: ia5, undefined 4955 X400-Content-Type: P2-1984 (2) 4956 X400-Content-Identifier: Email Problems | 4957 From: Stephen.Harrison@gosip-uk.hmg.gold-400.gb (Tel +44 71 217 3487) 4958 Message-ID: 4959 To: Jim Craigie , | 4960 Tony Bates , | 4961 Steve Kille | 4962 Subject: Email Problems 4963 Sender: Stephen.Harrison@gosip-uk.hmg.gold-400.gb 4964 MIME-Version: 1.0 | 4965 Content-Type: multipart/mixed; boundary=boundary-1 | 4967 --boundary-1 | 4968 Content-Type: text/plain; charset=US-ASCII | 4970 Hope you gentlemen....... * 4972 Regards, 4974 Stephen Harrison 4975 UK GOSIP Project 4977 ..... continued on next page 4979 INTERNET DRAFT 4980 MIXER DRAFT Version 2.1 4982 --boundary-1 | 4983 Content-Type: message/rfc822 | 4985 From: Urs Eppenberger 4986 Message-ID: 4987 <562*/S=Eppenberger/OU=verw/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> 4988 To: "Stephen.Harrison" 4989 Cc: kimura@bsdarc.bsd.fc.nec.co.jp 4990 Subject: Response to Email link 4991 Content-Type: multipart/mixed; boundary=boundary-2 | 4993 --boundary-2 | 4995 Dear Mr Harrison...... 4997 --boundary-2 | 4999 --boundary-1 | 5001 5.3.5. Mappings from an IP Notification 5003 A message is generated, with the following fields: 5005 From: 5006 Set to the IPMS.IPN.ipn-originator. 5008 To: Set to the recipient from MTS.MessageSubmissionEnvelope. 5009 If there have been redirects, the original address should be 5010 used. 5012 Subject: 5013 Set to the string "X.400 Inter-Personal Notification" for a 5014 receipt notification and to "X.400 Inter-Personal 5015 Notification (failure)" for a non-receipt notification. 5017 Message-Type: 5018 Set to "InterPersonal Notification" 5020 INTERNET DRAFT 5021 MIXER DRAFT Version 2.1 5023 References: 5024 Set to IPMS.IPN.subject-ipm | 5026 Discarded-X400-IPMS-Extensions: | 5027 Used for any discarded IPN extensions. 5029 The following EBNF is defined for the body of the Message. This 5030 format is defined to ensure that all information from an 5031 interpersonal notification is available to the end user in a 5032 uniform manner. 5034 INTERNET DRAFT 5035 MIXER DRAFT Version 2.1 5037 ipn-body-format = ipn-description * 5038 [ ipn-extra-information ] 5039 [ ipn-content-return ] 5041 ipn-description = ipn-receipt / ipn-non-receipt 5043 ipn-receipt = "Your message to:" preferred-recipient 5044 "was received at" receipt-time 5045 "This notification was generated" 5046 acknowledgement-mode 5047 "The following extra information was given:" 5048 ipn-suppl 5050 ipn-non-receipt "Your message to:" 5051 preferred-recipient 5052 ipn-reason 5054 ipn-reason = ipn-discarded / ipn-auto-forwarded 5056 ipn-discarded = "was discarded for the following reason:" 5057 discard-reason 5059 ipn-auto-forwarded = "was automatically forwarded." 5060 [ "The following comment was made:" 5061 auto-comment ] 5063 ipn-extra-information = 5064 "The following information types were converted:" 5065 encoded-info 5067 ipn-content-return = "The Original Message is not available" 5068 / "The Original Message follows:" 5070 preferred-recipient = mailbox 5071 receipt-time = date-time 5072 auto-comment = printablestring 5073 ipn-suppl = printablestring 5075 INTERNET DRAFT 5076 MIXER DRAFT Version 2.1 5078 discard-reason = "Expired" / "Obsoleted" / 5079 "User Subscription Terminated" 5081 acknowledgement-mode = "Manually" / "Automatically" 5083 The mappings for elements of the common fields of IPMS.IPN 5084 (IPMS.CommonFields) onto this structure and the message header 5085 are: 5087 subject-ipm 5088 Mapped to "References:" 5090 ipn-originator 5091 Mapped to "From:". 5093 ipn-preferred-recipient 5094 Mapped to EBNF.preferred-recipient 5096 conversion-eits 5097 Mapped to EBNF.encoded-info in EBNF.ipn-extra-information 5099 The mappings for elements of IPMS.IPN.non-receipt-fields 5100 (IPMS.NonReceiptFields) are: 5102 non-receipt-reason 5103 Used to select between EBNF.ipn-discarded and 5104 EBNF.ipn-auto-forwarded 5106 discard-reason 5107 Mapped to EBNF.discard-reason 5109 auto-forward-comment 5110 Mapped to EBNF.auto-comment 5112 returned-ipm 5113 This applies only to non-receipt notifications. 5114 EBNF.ipn-content-return should always be omitted for receipt 5115 notifications, and always be present in non-receipt 5116 notifications. If present, the second option of 5117 EBNF.ipn-content-return is chosen, and the message is | 5118 included. In this case, the message is formatted as | 5119 multipart/mixed, and the returned message included as | 5120 message/rfc822 after the text body part. Otherwise the first | 5122 INTERNET DRAFT 5123 MIXER DRAFT Version 2.1 5125 option is chosen. 5127 The mappings for elements of IPMS.IPN.receipt-fields 5128 (IPMS.ReceiptFields) are: 5130 receipt-time 5131 Mapped to EBNF.receipt-time 5133 acknowledgement-mode 5134 Mapped to EBNF.acknowledgement-mode 5136 suppl-receipt-info 5137 Mapped to EBNF.ipn-suppl 5139 An example notification is: 5141 From: Steve Kille 5142 To: Julian Onions 5143 Subject: X.400 Inter-personal Notification 5144 Message-Type: InterPersonal Notification 5145 References: <1229.614418325@UK.AC.NOTT.CS> 5146 Date: Wed, 21 Jun 89 08:45:25 +0100 5148 Your message to: Steve Kille 5149 was automatically forwarded. 5150 The following comment was made: 5151 Sent on to a random destination 5153 The following information types were converted: g3fax 5155 5.3.6. Mappings from the MTS Abstract Service 5157 This section describes the MTS mappings for User Messages (IPM 5158 and IPN). This mapping is defined by specifying the mapping of 5159 MTS.MessageDeliveryEnvelope. The following extensions to RFC 822 5160 are defined to support this mapping: 5162 INTERNET DRAFT 5163 MIXER DRAFT Version 2.1 5165 mts-field = "X400-MTS-Identifier" ":" mts-msg-id 5166 / "X400-Originator" ":" mailbox 5167 / "X400-Recipients" ":" 1#mailbox 5168 / "Original-Encoded-Information-Types" ":" 5169 encoded-info 5170 / "X400-Content-Type" ":" mts-content-type 5171 / "Content-Identifier" ":" printablestring 5172 / "Priority" ":" priority 5173 / "Originator-Return-Address" ":" 1#mailbox 5174 / "DL-Expansion-History" ":" mailbox ";" date-time ";" 5175 / "Conversion" ":" prohibition 5176 / "Conversion-With-Loss" ":" prohibition 5177 / "Requested-Delivery-Method" ":" 5178 1*( labelled-integer ) 5179 / "Delivery-Date" ":" date-time 5180 / "Discarded-X400-MTS-Extensions" ":" 5181 1#( object-identifier / labelled-integer )| 5183 prohibition = "Prohibited" / "Allowed" 5185 mts-msg-id = "[" global-id ";" *text "]" 5187 mts-content-type = "P2" / labelled-integer 5188 / object-identifier | 5190 priority = "normal" / "non-urgent" / "urgent" 5192 The mappings for each element of MTS.MessageDeliveryEnvelope can 5193 now be considered. 5195 MTS.MessageDeliveryEnvelope.message-delivery-identifier 5196 Mapped to the extended RFC 822 field "X400-MTS-Identifier:". 5198 MTS.MessageDeliveryEnvelope.message-delivery-time 5199 Discarded, as this time will be represented in an 5200 appropriate trace element. 5202 The mappings for elements of 5203 MTS.MessageDeliveryEnvelope.other-fields 5204 (MTS.OtherMessageDeliveryFields) are: 5206 INTERNET DRAFT 5207 MIXER DRAFT Version 2.1 5209 content-type 5210 Mapped to the extended RFC 822 field "X400-Content-Type:". 5211 The string "P2" is retained for backwards compatibility with 5212 RFC 987. This shall not be generated, and either the 5213 EBNF.labelled-integer or EBNF.object-identifier encoding 5214 used. 5216 originator-name 5217 Mapped to the 822-MTS originator, and to the extended RFC 5218 822 field "X400-Originator:". This is described in 5219 Section 4.6.2. 5221 original-encoded-information-types 5222 Mapped to the extended RFC 822 field 5223 "Original-Encoded-Information-Types:". 5225 priority 5226 Mapped to the extended RFC 822 field "Priority:". 5228 delivery-flags 5229 If the conversion-prohibited bit is set, add an extended RFC 5230 822 field "Conversion:". 5232 this-recipient-name and other-recipient-names 5234 originally-intended-recipient-name 5235 The handling of these elements is described in 5236 Section 4.6.2. 5238 converted-encoded-information-types 5239 Discarded, as it will always be IA5 only. 5241 message-submission-time 5242 Mapped to Date:. 5244 content-identifier 5245 Mapped to the extended RFC 822 field | 5246 "X400-Content-Identifier:". In RFC 1327, this was | 5247 "Content-Identifier:". This has been changed to avoid | 5248 confusion with MIME defined fields. Gateways which reverse | 5249 map, may support the old field. 5251 If any extensions 5252 (MTS.MessageDeliveryEnvelope.other-fields.extensions) are 5254 INTERNET DRAFT 5255 MIXER DRAFT Version 2.1 5257 present, and they are marked as critical for transfer or 5258 delivery, then the message shall be rejected. The extensions 5259 (MTS.MessageDeliveryEnvelope.other-fields.extensions) are mapped 5260 as follows. 5262 conversion-with-loss-prohibited 5263 If set to 5264 MTS.ConversionWithLossProhibited.conversion-with-loss-prohibited, 5265 then add the extended RFC 822 field "Conversion-With-Loss:". 5267 requested-delivery-method 5268 Mapped to the extended RFC 822 field 5269 "Requested-Delivery-Method:". 5271 originator-return-address 5272 Mapped to the extended RFC 822 field 5273 "Originator-Return-Address:". 5275 physical-forwarding-address-request 5276 physical-delivery-modes 5277 registered-mail-type 5278 recipient-number-for-advice 5279 physical-rendition-attributes 5280 physical-delivery-report-request 5281 physical-forwarding-prohibited 5283 These elements are only appropriate for physical delivery. 5284 They are represented as comments in the "X400-Recipients:" 5285 field, as described in Section 4.6.2.2. 5287 originator-certificate 5288 message-token 5289 content-confidentiality-algorithm-identifier 5290 content-integrity-check 5291 message-origin-authentication-check 5292 message-security-label 5293 proof-of-delivery-request 5295 These elements imply use of security services not available 5296 in the RFC 822 environment. If they are marked as critical 5297 for transfer or delivery, then the message shall be 5298 rejected. Otherwise they are discarded. 5300 INTERNET DRAFT 5301 MIXER DRAFT Version 2.1 5303 redirection-history 5304 This is described in Section 4.6.2. 5306 dl-expansion-history 5307 Each element is mapped to the extended RFC 822 field 5308 "DL-Expansion-History:". They shall be ordered in the 5309 message header, so that the most recent expansion comes 5310 first (same order as trace). 5312 If any MTS (or MTA) Extensions not specified in X.400 are 5313 present, and they are marked as critical for transfer or 5314 delivery, then the message shall be rejected. If they are not so 5315 marked, they can safely be discarded. The list of discarded 5316 fields shall be indicated in the extended header 5317 "Discarded-X400-MTS-Extensions:". 5319 5.3.7. Mappings from the MTA Abstract Service 5321 There are some mappings at the MTA Abstract Service level which 5322 are done for IPM and IPN. These can be derived from 5323 MTA.MessageTransferEnvelope. The reasons for the mappings at 5324 this level, and the violation of layering are: 5326 - Allowing for multiple recipients to share a single RFC 822 5327 message 5329 - Making the X.400 trace information available on the RFC 822 5330 side 5332 - Making any information on deferred delivery available 5334 The 822-MTS recipients are calculated from the full list of X.400 5335 recipients. This is all of the members of 5336 MTA.MessageTransferEnvelope.per-recipient-fields being passed 5337 through the gateway, where the responsibility bit is set. In 5338 some cases, a different RFC 822 message would be calculated for 5339 each recipient, due to differing service requests for each | 5340 recipient. As discussed in 4.6.2.2, this specification allows | 5341 either for multiple messages to be generated, or for the per- 5342 recipient information to be discarded. 5344 The following EBNF is defined for extended RFC 822 headers: 5346 INTERNET DRAFT 5347 MIXER DRAFT Version 2.1 5349 mta-field = "X400-Received" ":" x400-trace 5350 / "Deferred-Delivery" ":" date-time 5351 / "Latest-Delivery-Time" ":" date-time 5353 x400-trace = "by" md-and-mta ";" 5354 [ "deferred until" date-time ";" ] 5355 [ "converted" "(" encoded-info ")" ";" ] 5356 [ "attempted" md-or-mta ";" ] 5357 action-list 5358 ";" arrival-time 5360 md-and-mta = [ "mta" mta "in" ] global-id 5361 mta = word 5362 arrival-time = date-time 5364 md-or-mta = "MD" global-id 5365 / "MTA" mta 5367 Action-list = 1#action 5368 action = "Redirected" 5369 / "Expanded" 5370 / "Relayed" 5371 / "Rerouted" 5373 Note the EBNF.mta is encoded as 822.word. If the character 5374 set does no allow encoding as 822.atom, the 822.quoted-string 5375 encoding is used. 5377 If MTA.PerMessageTransferFields.deferred-delivery-time is 5378 present, it is used to generate a Deferred-Delivery: field. For 5379 some reason, X.400 does not make this information available at 5380 the MTS level on delivery. X.400 profiles, and in particular the 5381 CEN/CENELEC profile for X.400(1984) [36], specify that this 5382 element must be supported at the first MTA. If it is not, the 5383 function may optionally be implemented by the gateway: that is, 5384 the gateway may hold the message until the time specified in the 5386 INTERNET DRAFT 5387 MIXER DRAFT Version 2.1 5389 protocol element. Thus, the value of this element will usually 5390 be in the past. For this reason, the extended RFC 822 field is 5391 primarily for information. 5393 Merge MTA.PerMessageTransferFields.trace-information, and 5394 MTA.PerMessageTransferFields.internal-trace-information to 5395 produce a single ordered trace list. If Internal trace from 5396 other management domains has not been stripped, this may require 5397 complex interleaving. Where an element of internal trace and 5398 external trace are identical, except for the MTA in the internal 5399 trace, only the internal trace element shall be presented. Use 5400 this to generate a sequence of "X400-Received:" fields. The only 5401 difference between external trace and internal trace will be the 5402 extra MTA information in internal trace elements. 5404 When generating an RFC 822 message all trace fields (X400- 5405 Received and Received) shall be at the beginning of the header, 5406 before any other fields. Trace shall be in chronological order, 5407 with the most recent element at the front of the message. This 5408 ordering is determined from the order of the fields, not from 5409 timestamps in the trace, as there is no guarantee of clock 5410 synchronisation. A simple example trace (external) is: 5412 X400-Received: by /PRMD=UK.AC/ADMD=Gold 400/C=GB/ ; Relayed ; 5413 Tue, 20 Jun 89 19:25:11 +0100 5415 A more complex example (internal): 5417 X400-Received: by mta "UK.AC.UCL.CS" in /PRMD=UK.AC/ADMD=Gold 400/C=GB/ ; 5418 deferred until Tue, 20 Jun 89 14:24:22 +0100 ; 5419 converted (undefined, g3fax) ; attempted /ADMD=Foo/C=GB/ ; | 5420 Relayed, Expanded, Redirected ; Tue, 20 Jun 89 19:25:11 +0100 5422 The gateway itself shall not add trace information. | 5423 However, for trace purposes, the gateway shall be considered as | 5424 an X.400 and Internet MTA back to back, and both of these shall | 5425 add trace elements. 5427 5.3.8. Mappings from Report Delivery 5429 Delivery reports are mapped at the MTS service level. This means 5430 that only reports destined for the MTS user will be mapped. Some | 5431 additional services are also taken from the MTA service. X.400 | 5433 INTERNET DRAFT 5434 MIXER DRAFT Version 2.1 5436 Delivery Reports are Mapped onto Delivery Status Notifications, | 5437 as defined by NOTARY [33]. 5439 5.3.8.1. MTS Mappings 5441 A Delivery Report service will be represented as 5442 MTS.ReportDeliveryEnvelope, which comprises of per-report-fields 5443 (MTS.PerReportDeliveryFields) and per-recipient-fields. 5445 A message of type delivery-status is generated with the following | 5446 fields: 5448 From: 5449 An administrator at the gateway system. This is also the 5450 822-MTS originator. 5452 To: A mapping of the 5453 MTA.ReportTransferEnvelope.report-destination-name. This is 5454 also the 822-MTS recipient. 5456 Message-Type: 5457 Set to "Delivery Report". This is strictly redundant, but | 5458 retained for backwards compatibility with RFC 1327. 5460 Subject: 5461 The EBNF for the subject line is: 5463 subject-line = "Delivery-Report" "(" status ")" 5464 [ "for" destination ] 5466 status = "success" / "failure" / "success and failures" 5468 destination = mailbox / "MTA" word 5470 The subject is intended to give a clear indication as to the | 5471 nature of the message, and summarise its contents. EBNF.status is | 5472 set according to whether the reports are all successes, all | 5473 failures, or a mixture. The EBNF.destination is used to indicate | 5474 the addresses in the reports. If the report is for a single | 5475 address, EBNF.mailbox is used to give the RFC 822 representation | 5476 of the address. If all of the reports share a common MTA this is | 5477 included in EBNF.word. A common MTA is determined from the | 5479 INTERNET DRAFT 5480 MIXER DRAFT Version 2.1 5482 delivery report's trace. | 5484 The format of the body of the message follows the NOTARY | 5485 delivery status notification format, and is defined to ensure | 5486 that all information is conveyed to the RFC 822 user in a 5487 consistent manner. The format is structured as if it was a | 5488 message coming from the gateway, with three body parts. The first | 5489 body part is ASCII text structured as follows: 5491 1. A few lines giving keywords to indicate the original 5492 message. 5494 2. A human summary of the status of each recipient being 5495 reported on. | 5497 The second body part is the NOTARY delivery status | 5498 notification, which contains detailed information extracted from | 5499 the report. This information may be critical to diagnosing an 5500 obscure problem. | 5502 This body part may be omitted in positive DRs. For RFC | 5503 1327, this was recommended as appropriate for most gateways. As | 5504 NOTARY becomes more widely adopted, this will make less sense. | 5505 It is likely that this body part will be mandatory in future | 5506 versions of this specification. | 5508 The third (optional) body part contains the returned message | 5509 (return of content). This structure is useful to the RFC 822 | 5510 recipient, as it enables the original message to be extracted. | 5511 It shall be included if the original message is available. | 5513 The enclosing message is a MIME message of content type | 5514 multipart/report, with report-type=delivery-status. The first | 5515 body part containing the user oriented description is of type | 5516 text/plain. The format of this body part is defined below as | 5517 EBNF.dr-user-info. 5519 INTERNET DRAFT 5520 MIXER DRAFT Version 2.1 5522 dr-user-info = dr-summary | 5523 dr-recipients 5524 dr-content-return * 5526 dr-content-return = "The Original Message is not available" 5527 / "The Original Message follows:" 5529 dr-summary = "This report relates to your message:" 5530 content-correlator 5531 "of" date-time 5533 dr-recipients = *(dr-recipient ) 5535 dr-recipient = dr-recip-success / dr-recip-failure 5537 dr-recip-success = 5538 "Your message was successfully delivered to:" 5539 mailbox "at" date-time 5541 dr-recip-failure = "Your message was not delivered to:" 5542 mailbox 5543 "for the following reason:" *word 5545 report-point = [ "mta" word "in" ] global-id | 5546 content-correlator = *word | 5548 EBNF.dr-summary | 5549 The EBNF.content-correlator is taken from the content | 5550 correlator (or content identifier if there is no content | 5551 correlator) and the EBNF.date-time from the trace, as | 5552 described below. LWSP may be added to improve the layout of | 5553 the body part. | 5555 EBNF.dr-recipients | 5556 There is an element for each recipient in the delivery | 5557 report. In each case, EBNF.mailbox is taken from the RFC | 5558 822 form of the originally specified recipient, which is | 5559 taken from the originally specified recipient element if | 5560 present or from the actual recipient. When reporting | 5562 INTERNET DRAFT 5563 MIXER DRAFT Version 2.1 5565 success, the message delivery time is used to derive | 5566 EBNF.date-time. When reporting failure, the information | 5567 includes a human readable interpretation of the X.400 | 5568 diagnostic and reason codes, and the supplementary | 5569 information. | 5571 EBNF.dr-content-return | 5572 This is set according to whether or not the content is being | 5573 returned. | 5575 The EBNF of this body part is designed for english-speaking | 5576 users. The language of the strings in the EBNF may be altered. | 5578 The EBNF used in the delivery status notification is: | 5580 dr-per-message-fields = | 5581 / "X400-Conversion-Date" ":" date-time | 5582 / "X400-Subject-Submision-Identifier" ":" | 5583 mts-msg-id 5584 / "X400-Content-Identifier" ":" printablestring | 5585 / "X400-Content-Type" ":" mts-content-type | 5586 / "X400-Original-Encoded-Information-Types" ":" | 5587 encoded-info 5588 / "X400-Originator-and-DL-Expansion-History" ":" | 5589 dl-history 5590 / "X400-Reporting-DL-Name" ":" mailbox | 5591 / "X400-Content-Correlator" ":" content-correlator| 5592 / "X400-Recipient-Info" ":" recipient-info | 5593 / "X400-Subject-Intermediate-Trace-Information" ":"| 5594 x400-trace 5595 / dr-extensions | 5597 INTERNET DRAFT 5598 MIXER DRAFT Version 2.1 5600 dr-per-recipient-fields = | 5601 / "X400-Redirect-Recipient" ":" "x400" ";" std-or| 5602 / "X400-Mapped-Redirect-Recipient" ":" "rfc822" ";" mailbox| 5603 / "X400-Converted-EITs" ":" encoded-info ";" | 5604 / "X400-Delivery-Time" ":" date-time | 5605 / "X400-Type-of-MTS-User" ":" labelled-integer | 5606 / "X400-Last-Trace" ":" [ encoded-info ] date-time | 5607 / "X400-Supplementary-Info" ":" | 5608 <"> printablestring <"> ";" | 5609 / "X400-Redirection-History" ":" redirection-comment| 5610 / "X400-Physical-Forwarding-Address" ":" printablestring| 5611 / "X400-Originally-Specified-Recipient-Number" ":"| 5612 integer | 5613 / dr-extensions | 5615 dr-extensions = "X400-Discarded-DR-Extensions" ":" | 5616 1# (object-identifier / labelled-integer)| 5618 dl-history = 1#( mailbox "(" date-time ")") | 5620 / "X400-Diagnostic" ":" labelled-integer | 5621 / "X400-Reason" ":" labelled-integer | 5623 dr-diagnostic = "Reason" labelled-integer | 5624 [ ";" "Diagnostic" labelled-integer ] | 5626 A body part of type delivery status, as defined by NOTARY, is | 5627 generated. MIXER extends this delivery status notification (DSN) | 5628 specification, by defining additional per message fields in | 5629 EBNF.dr-per-message-fields and additional per recipient fields in | 5630 EBNF.dr-per-recipient-fields. These are used as extensions to | 5631 DSN.per-message-fields and DSN.per-recipient-fields. | 5633 The following DSN.per-message-fields are always generated: | 5635 DSN.reporting-mta-field | 5636 The DSN.mta-name-type is set to "x400", and this string is | 5637 reserved by MIXER. The DSN.mta-name has its syntax | 5638 specified by EBNF.report-point, with the information derived | 5639 from the first element of the DR's trace. | 5641 INTERNET DRAFT 5642 MIXER DRAFT Version 2.1 5644 DSN.arrival-date-field | 5645 This is derived from the date of the first element of trace | 5646 in the DR. 5648 The following two EBNF.per-message-fields are generated by | 5649 the MIXER gateway: | 5651 DSN.dsn-gateway-field | 5652 The type is set to "dns" and the domain set to the local | 5653 domain of the gateway. | 5655 X400-Conversion-Date: | 5656 The EBNF.date-time is set to the time of the MIXER | 5657 conversion. | 5659 The elements of MTS.ReportDeliveryEnvelope.per-report-fields 5660 are mapped as follows onto the DSN per message fields as follows: | 5662 subject-submission-identifier 5663 Mapped to DSN.original-envelope-id-field. The encoding of | 5664 this MTS Identifier follows the format EBNF.mts-msg-id. 5666 content-identifier 5667 Mapped to X400-Content-Identifier: | 5669 content-type 5670 Mapped to X400-Content-Type: | 5672 original-encoded-information-types 5673 Mapped to X400-Encoded-Info: | 5675 The extensions from 5676 MTS.ReportDeliveryEnvelope.per-report-fields.extensions are 5677 mapped as follows: 5679 originator-and-DL-expansion-history 5680 Mapped to X400-Originator-and-DL-Expansion-History: | 5682 reporting-DL-name 5683 Mapped to X400-Reporting-DL-Name: | 5685 content-correlator 5686 Mapped to X400-Content-Correlator:, provided that the | 5687 encoding is IA5String (this will always be the case). 5689 INTERNET DRAFT 5690 MIXER DRAFT Version 2.1 5692 message-security-label 5693 reporting-MTA-certificate 5694 report-origin-authentication-check 5696 These security parameters will not be present unless there 5697 is an error in a remote MTA. If they are present, they 5698 shall be discarded in preference to discarding the whole | 5699 report. They shall be listed in the X400-Discarded-DR- | 5700 Extensions: field. 5702 If there are any other DR extensions, they shall also be | 5703 discarded and listed in the X400-Discarded-DR-Extensions: field. | 5705 For each element of 5706 MTS.ReportDeliveryEnvelope.per-recipient-fields, a set of | 5707 DSN.per-recipient-fields is generated. The fields are filled in | 5708 as follows: 5710 actual-recipient-name 5711 If originally-intended-recipient-name is not present | 5712 Generate a DSN.final-recipient-field fields, with | 5713 DSN.address-type of "rfc822", and with an RFC 822 mailbox | 5714 generated from the address encoded as specified by NOTARY. | 5715 Also generate a DSN.original-recipient-field field, which | 5716 holds the X.400 representation of the same address. If the | 5717 directory name is present, it should be added as a trailing | 5718 comment in the X.400 form. | 5720 If originally-intended-recipient-name is present Generate an | 5721 "X400-Mapped-Redirect-Recipient:" field, with | 5722 DSN.address-type of "rfc822", and with an RFC 822 mailbox | 5723 generated from the address encoded as specified by NOTARY. | 5724 Also generate an X400-Redirect-Recipient:" field, which | 5725 holds the X.400 representation of the same address. If the | 5726 directory name is present, it should be added as a trailing | 5727 comment in the X.400 form. 5729 report 5730 If it is MTS.Report.delivery, then set DSN.action-field to | 5731 "delivered", and set "X400-Delivery-Time:" and | 5732 "X400-Type-of-MTS-User:" from the information in the report. | 5733 DSN.status field is set to "2.0.0". | 5735 If it is MTS.Report.non-delivery, then set DSN.action-field | 5737 INTERNET DRAFT 5738 MIXER DRAFT Version 2.1 5740 to "failure". DSN.diagnostic-code-field is encoded | 5741 according to the syntax EBNF.dr-diagnostic, with the | 5742 labelled integers set from the reason and diagnotic codes. | 5743 DSN.status-field is derived from the reason and diagnostic | 5744 codes, as described below. 5746 converted-encoded-information-types 5747 Set X400-Converted-EITs: | 5749 originally-intended-recipient 5750 Generate a DSN.final-recipient-field fields, with | 5751 DSN.address-type of "rfc822", and with an RFC 822 mailbox | 5752 generated from the address encoded as specified by NOTARY. | 5753 Also generate a DSN.original-recipient-field field, which | 5754 holds the X.400 representation of the same address. If the | 5755 directory name is present, it should be added as a trailing | 5756 comment in the X.400 form. 5758 supplementary-info 5759 Set X400-Supplementary-Info: | 5761 redirection-history 5762 Set X400-Redirection-History: | 5764 physical-forwarding-address 5765 Set X400-Physical-Forwarding-Address: | 5767 recipient-certificate 5768 Discard 5770 proof-of-delivery 5771 Discard 5773 Any unknown extensions shall be discarded, irrespective of | 5774 criticality. All discarded extensions shall be included in a | 5775 "X400-Discarded-DR-Extensions:" field. 5777 The number from the | 5778 MTA.PerRecipientReportTransferFields.originally-specified-recipient-number| 5779 shall be mapped to "X400-Originally-Specified-Recipient-Number:", | 5780 in order to facilitate reverse mapping of delivery reports. | 5782 The original message shall be included in the delivery | 5783 status notification if it is available. The original message will | 5785 INTERNET DRAFT 5786 MIXER DRAFT Version 2.1 5788 usually be available at the gateway, as discussed in Section 5.2. 5789 If the original message is available, but of erroneous format, a 5790 dump of the ASN.1 may be included, encoded as | 5791 application/octet-string. This is recommended, but not required. | 5793 Where the original message is included, it shall be encoded | 5794 according to the MIME specifications as content type | 5795 message/rfc822. 5797 5.3.8.2. Status Code Mappings | 5799 This section defines the mappings from X.400 diagnostic and | 5800 status codes to the NOTARY Status field. | 5802 C/D X400 meaning DSN code Means 5804 0/Any Transfer failure (may be temporary) 4.4.0 Other net/route 5805 1/Any Unable to transfer 5.0.0 Other, unknown 5806 2/Any Conversion not performed 5.6.3 Conv not supported 5807 3/Any Physical rendition not performed 5.6.0 Other media error 5808 4/Any Physical delivery not performed 5.1.0 Other address status 5809 5/Any Restricted delivery 5.7.1 5810 6/Any Directory operation unsuccessful 5.4.3 Routing server failure 5811 7/Any Deferred delivery not performed 5.3.3 Not capable 5813 INTERNET DRAFT 5814 MIXER DRAFT Version 2.1 5816 1/0 Unrecognized O/R name 5.1.1 5817 1/1 Ambiguous O/R name 5.1.4 5818 1/2 MTS congestion 4.3.1 5819 1/3 Loop detected 5.4.6 5820 1/4 Recipient unavailable 4.2.1 5821 1/5 Delivery time expired 4.4.7 5822 1/6 Encoded information types unsupported 5.6.1 Media unsupp. 5823 1/7 Content too long 5.2.3 5824 2/8 Conversion impractical 5.6.3 5825 2/9 Conversion prohibited 5.6.3 5826 1/10 Implicit conversion not subscribed 5.6.3 5827 1/11 Invalid arguments 5.5.2 5828 1/12 Content syntax error 5.5.2 5829 1/13 Size constraint violation 5.5.2 5830 1/14 Protocol violation 5.5.0 5831 1/15 Content type not supported 5.6.1 Media unsupp. 5832 1/16 Too many recipients 5.5.3 5833 1/17 No bilateral agreement 5.4.4 5834 1/18 Unsupported critical function 5.3.3 System not capable 5835 2/19 Conversion with loss prohibited 5.6.2 5836 2/20 Line too long 5.6.0 5837 2/21 Page split 5.6.0 5838 2/22 Pictorial symbol loss 5.6.2 5839 2/23 Punctuation symbol loss 5.6.2 5840 2/24 Alphabetic character loss 5.6.2 5841 2/25 Multiple information loss 5.6.2 5842 1/26 Recipient reassignment prohibited 5.4.0 Undefined net/route 5843 1/27 Redirection loop detected 5.4.6 5844 1/28 DL expansion prohibited 5.7.2 5845 1/29 No DL submit permission 5.7.1 Delivery not authorized 5846 1/30 DL expansion failure 4.2.4 5847 4/31 Physical rendition attrs not supported 5.6.0 Undefined media error 5848 4/32-45 Various physical mail stuff 5.1.0 Other address status 5849 1/46 Secure messaging error 5.7.0 Other security status 5850 2/47 Unable to downgrade 5.3.3 System not capable 5851 0/48 Unable to complete transfer 5.3.4 Message too big 5852 0/49 Transfer attempts limit reached 4.4.7 Delivery time expired 5854 5.3.8.3. MTA Mappings 5856 The single 822-MTS recipient is constructed from 5858 INTERNET DRAFT 5859 MIXER DRAFT Version 2.1 5861 MTA.ReportTransferEnvelope.report-destination-name, using the 5862 mappings of Chapter 4. Unlike with a user message, this 5863 information is not available at the MTS level. 5865 The following additional mappings are made, which results in | 5866 fields in the outer header of the DSN. 5868 MTA.ReportTransferEnvelope.report-destination-name 5869 This is used to generate the To: field. 5871 MTA.ReportTransferEnvelope.identifier 5872 Mapped to the extended RFC 822 field "X400-MTS-Identifier:". 5873 It may also be used to derive a "Message-Id:" field. 5875 MTA.ReportTransferEnvelope.trace-information 5876 and 5878 MTA.ReportTransferEnvelope.internal-trace-information 5879 Mapped onto the extended RFC 822 field "X400-Received:", as 5880 described in Section 5.3.7. | 5882 The following additional mappings are made, which result in per | 5883 message fields in the DSN body part: 5885 MTA.PerRecipientReportTransferFields.last-trace-information 5886 Mapped to X400-Last-Trace:". | 5888 MTA.PerReportTransferFields.subject-intermediate-trace- 5889 information Mapped to | 5890 X400-Subject-Intermediate-Trace-Information:". These fields 5891 are ordered so that the most recent trace element comes 5892 first. 5894 5.3.8.4. Example Delivery Reports 5896 This section contains sample delivery reports. These are the | 5897 same examples used in RFC 1327, and so they also illustrate the | 5898 changes between RFC 1327 and this document. Example Delivery 5899 Report 1: 5901 INTERNET DRAFT 5902 MIXER DRAFT Version 2.1 5904 Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk * 5905 via Delivery Reports Channel id <27699-0@bells.cs.ucl.ac.uk>; 5906 Thu, 7 Feb 1991 15:48:39 +0000 5907 From: UCL-CS MTA 5908 To: S.Kille@cs.ucl.ac.uk 5909 Subject: Delivery Report (failure) for H.Hildegard@bbn.com 5910 Message-Type: Delivery Report 5911 Date: Thu, 7 Feb 1991 15:48:39 +0000 5912 Message-ID: <"bells.cs.u.694:07.01.91.15.48.34"@cs.ucl.ac.uk> 5913 X400-Content-Identifier: Greetings. | 5914 MIME-Version: 1.0 | 5915 Content-Type: multipart/report; report-type=delivery-status; | 5916 boundary=boundary-1 | 5918 --boundary-1 | 5920 This report relates to your message: Greetings. * 5921 of Thu, 7 Feb 1991 15:48:20 +0000 5923 Your message was not delivered to 5924 H.Hildegard@bbn.com for the following reason: 5925 Bad Address 5926 MTA 'bbn.com' gives error message (USER) Unknown user name in 5927 "H.Hildegard@bbn.com" 5929 The Original Message follows: | 5931 --boundary-1 || 5932 content-type: message/delivery-status || 5934 INTERNET DRAFT 5935 MIXER DRAFT Version 2.1 5937 Reporting-MTA: x400; bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/|| 5938 Arrival-Date: Thu, 7 Feb 1991 15:48:34 +0000 || 5939 DSN-Gateway: dns; bells.cs.ucl.ac.uk || 5940 X400-Conversion-Date: Thu, 7 Feb 1991 15:48:40 +0000 || 5941 Original-Envelope-Id: || 5942 [/PRMD=uk.ac/ADMD=gold 400/C=gb/;<1803.665941698@UK.AC.UCL.CS>]|| 5943 X400-Content-Identifier: Greetings. || 5944 X400-Subject-Intermediate-Trace-Information: /PRMD=uk.ac/ADMD=gold 400/C=gb/;|| 5945 arrival Thu, 7 Feb 1991 15:48:20 +0000 action Relayed || 5946 X400-Subject-Intermediate-Trace-Information: /PRMD=uk.ac/ADMD=gold 400/C=gb/;|| 5947 arrival Thu, 7 Feb 1991 15:48:18 +0000 action Relayed || 5949 Original-Recipient: rfc822; H.Hildegard@bbn.com || 5950 Final-Recipient: x400; || 5951 /RFC-822=H.Hildegard(a)bbn.com/OU=cs/O=ucl/PRMD=uk.ac/ADMD=gold 400/C=gb/;|| 5952 Action: failure || 5953 Status: 5.1.1 || 5954 Diagnostic Code: x400; Reason Unable-To-Transfer (1); || 5955 Diagnostic Unrecognised-ORName (0) || 5956 X400-Last-Trace: (ia5) Thu, 7 Feb 1991 15:48:18 +0000; || 5957 X400-Originally-Specified-Recipient-Number: 1 || 5958 X400-Supplementary-Info: "MTA 'bbn.com' gives error message (USER)|| 5959 Unknown user name in "H.Hildegard@bbn.com""; || 5961 INTERNET DRAFT 5962 MIXER DRAFT Version 2.1 5964 --boundary-1 | 5965 Content-Type: message/rfc822 | 5967 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk 5968 with SMTP inbound id <27689-0@bells.cs.ucl.ac.uk>; 5969 Thu, 7 Feb 1991 15:48:21 +0000 5970 To: H.Hildegard@bbn.com 5971 Subject: Greetings. 5972 Phone: +44-71-380-7294 5973 Date: Thu, 07 Feb 91 15:48:18 +0000 5974 Message-ID: <1803.665941698@UK.AC.UCL.CS> 5975 From: Steve Kille 5977 Steve 5979 --boundary-1 | 5981 INTERNET DRAFT 5982 MIXER DRAFT Version 2.1 5984 Example Delivery Report 2: 5986 Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk * 5987 via Delivery Reports Channel id <27718-0@bells.cs.ucl.ac.uk>; 5988 Thu, 7 Feb 1991 15:49:11 +0000 5989 X400-Received: by mta bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/; 5990 Relayed; Thu, 7 Feb 1991 15:49:08 +0000 5991 X400-Received: by /PRMD=DGC/ADMD=GOLD 400/C=GB/; Relayed; 5992 Thu, 7 Feb 1991 15:48:40 +0000 5993 From: UCL-CS MTA 5994 To: S.Kille@cs.ucl.ac.uk 5995 Subject: Delivery Report (failure) for 5996 j.nosuchuser@dle.cambridge.DGC.gold-400.gb 5997 Message-Type: Delivery Report 5998 Date: Thu, 7 Feb 1991 15:46:11 +0000 | 5999 Message-ID: <"DLE/910207154840Z/000"@cs.ucl.ac.uk> 6000 X400-Content-Identifier: A useful mess... | 6001 MIME-Version: 1.0 | 6002 Content-Type: multipart/report; report-type=delivery-status; | 6003 boundary=boundary-1 | 6005 --boundary-1 | 6007 This report relates to your message: A useful mess... 6008 Your message was not delivered to 6009 j.nosuchuser@dle.cambridge.DGC.gold-400.gb 6010 for the following reason: 6011 Bad Address 6012 DG 21187: (CEO POA) Unknown addressee. 6014 The Original Message is not available | 6016 INTERNET DRAFT 6017 MIXER DRAFT Version 2.1 6019 --boundary-1 | 6020 content-type: message/delivery-status | 6022 Reporting-MTA: x400; /PRMD=DGC/ADMD=GOLD 400/C=GB/ | 6023 Arrival-Date: Thu, 7 Feb 1991 15:48:40 +0000 | 6024 DSN-Gateway: dns; bells.cs.ucl.ac.uk | 6025 X400-Conversion-Date: Thu, 7 Feb 1991 15:49:12 +0000 | 6026 Original-Envelope-Id: | 6027 [/PRMD=uk.ac/ADMD=gold 400/C=gb/;<1796.665941626@UK.AC.UCL.CS>] | 6028 X400-Content-Identifier: A useful mess... | 6030 Original-Recipient: rfc822; j.nosuchuser@dle.cambridge.DGC.gold-400.gb 6031 Final-Recipient: x400; 6032 /I=j/S=nosuchuser/OU=dle/O=cambridge/PRMD=DGC/ADMD=GOLD 400/C=GB/ 6033 Action: failure 6034 Status: 5.1.1 6035 Diagnostic Code: x400; Reason Unable-To-Transfer (1); 6036 Diagnostic Unrecognised-ORName (0) 6037 X400-Supplementary-Info: "DG 21187: (CEO POA) Unknown addressee." 6038 X400-Originally-Specified-Recipient-Number: 1 6040 --boundary-1 6042 5.3.9. Probe | 6044 This is an MTS internal issue. Any probe shall be serviced by 6045 the gateway, as there is no equivalent RFC 822 functionality. 6046 The value of the reply is dependent on whether the gateway could 6047 service an MTS Message with the values specified in the probe. 6048 The reply shall make use of MTS.SupplementaryInformation to 6049 indicate that the probe was serviced by the gateway. 6051 INTERNET DRAFT 6052 MIXER DRAFT Version 2.1 6054 Appendix A - Mappings Specific to SMTP 6056 This Appendix is specific to the Simple Mail Transfer Protocol 6057 (RFC 821). It describes specific changes in the context of this 6058 protocol. | 6060 6. Probes | 6062 When servicing a probe, as described in section 5.3.9, use may be 6063 made of the SMTP VRFY command to increase the accuracy of 6064 information contained in the delivery report. | 6066 7. Long Lines | 6068 SMTP is a text oriented protocol, and is required to support a | 6069 line length of at least 1000 characters. Some implementations | 6070 do not support line lengths greater than 1000 characters. This | 6071 can cause problems. Where body parts have long lines, it is | 6072 recommended to use a MIME encoding that folds lines (quoted | 6073 printable). | 6075 8. SMTP Extensions | 6077 There are several RFCs that specify extensions to SMTP. Most of | 6078 these are not relevant to MIXER. The NOTARY work to support | 6079 delivery report defines extensions which are relevant [34]. Use | 6080 of these extensions by a MIXER gateway is optional. If these | 6081 extensions are used, they shall be used in the manner described | 6082 below. | 6084 8.1. SMTP Extension mapping to X.400 | 6086 Mappings are defined for the following extensions: | 6088 NOTIFYThis is used to set the report and non-delivery bits of | 6089 MTS.MTS.PerRecipientMessageSubmissionFields.originator-report-request.| 6090 If the value is NEVER, both bits are zero. If SUCCESS is | 6091 present, the report bit is set. Otherwise, the non- | 6092 delivery-report bit is set. If the gateway uses the NOTIFY | 6093 command, it shall perform this mapping in all cases. | 6095 ORCPTThis may be used at the MTS level, to generate an element of | 6096 redirection history, with the redirection date being the | 6097 date of conversion. | 6099 INTERNET DRAFT 6100 MIXER DRAFT Version 2.1 6102 8.2. X.400 Mapping to SMTP Extensions | 6104 The following extensions may be used as a part of the MIXER | 6105 mapping: | 6107 NOTIFYThe report and non-delivery bits of | 6108 MTS.MTS.PerRecipientMessageSubmissionFields.originator-report-request| 6109 determine how this is used. If both bits are zero, the | 6110 parameter is NEVER. If the report bit is set, SUCCESS is | 6111 used. Otherwise, FAILURE is used. If this is done, the | 6112 gateway shall not generate a delivery report for this | 6113 recipient. | 6115 ORCPTIf the | 6116 MTS.perRecipientReportDeliveryFields.originally-intended-recipient-name| 6117 is present, the ORCPT command may be used to carry this | 6118 value. | 6120 ENVIDThis may be generated, with the value taken from the | 6121 MTS.MessgeDeliveryEnvelope.message-delivery-identifer, | 6122 encoded as EBNF.mts-msg-id. 6124 INTERNET DRAFT 6125 MIXER DRAFT Version 2.1 6127 Appendix B - Mapping with X.400(1984) | 6129 This appendix defines modification to the mapping for use with | 6130 X.400(1984). 6132 The X.400(1984) protocols are a proper subset of | 6133 X.400(1988). When mapping from X.400(1984) to RFC 822, no | 6134 changes to this specification are needed. 6136 When mapping from RFC 822 to X.400(1984), no use can be made | 6137 of 1988 specific features. No use of such features is made at | 6138 the MTS level. One feature is used at the IPMS level, and this | 6139 must be replaced by the RFC 987 approach. All header information | 6140 which would usually be mapped into the rfc-822-heading-list | 6141 extension, together with any Comments: field in the RFC 822 | 6142 header is mapped into a single IA5 body part, which is the first | 6143 body part in the message. This body part will start with the | 6144 string "RFC-822-Headers:" as the first line. The headers then | 6145 follow this line. This specification requires correct reverse | 6146 mapping of this format, either from 1988 or 1984. RFC 822 | 6147 extended headers which could be mapped into X.400(1988) elements, | 6148 are also mapped to the body part. 6150 In an environment where RFC 822 is of major importance, it | 6151 may be desirable for downgrading to consider the case where the | 6152 message was originated in an RFC 822 system, and mapped according | 6153 to this specification. The rfc-822-heading-list extension may be | 6154 mapped according to this appendix. | 6156 When parsing std-or, the following restrictions must be | 6157 observed: | 6159 - Only the 84/88 attributes identified in the table in | 6160 Section 4.2 are present. | 6162 - No teletex encoding is allowed. 6164 If an address violates this, it should be treated as an RFC 822 | 6165 address, which will usually lead to encoding as a DDA "RFC-822". | 6167 It is possible that null attributes may be present in an O/R | 6168 Address. This is not legal in 1988, except for ADMD where the | 6169 case is explicitly described in Section 4.3.5. Null attributes | 6171 INTERNET DRAFT 6172 MIXER DRAFT Version 2.1 6174 are deprecated (the attribute should be omitted), and should | 6175 therefore be unusual. However, some systems generate them and | 6176 rely on them. Therefore, any null attribute shall be enoded | 6177 using the std-or encoding (e.g., /O=/). | 6179 If a non-Teletex Common Name (CN) is present, it should be | 6180 mapped onto a Domain Defined Attribute "Common". This is in line | 6181 with RFC 1328 on X.400 1988 to 1984 downgrading . | 6183 This specification defines a mapping of the Internet message | 6184 framework to X.400. Body part mappings are defined in RFC 1494 | 6185 [12], which relies on X.400(88) features. Downgrading to | 6186 X.400(84) for body parts is defined in RFC 1496 (HARPOON), which | 6187 shall be followed in the context of this appendix [11]. 6189 INTERNET DRAFT 6190 MIXER DRAFT Version 2.1 6192 Appendix C - RFC 822 Extensions for X.400 access | 6194 This appendix defines a number of optional mappings which may be | 6195 provided to give access from RFC 822 to a number of X.400 | 6196 services. These mappings are beyond the basic scope of this | 6197 specification. There has been a definite demand to use extended | 6198 RFC 822 as a mechanism to access X.400, and these extensions | 6199 provide access to certain features. If this functionality is | 6200 provided, this appendix shall be followed. The following | 6201 headings are defined: | 6203 extended-heading = 6204 "Prevent-NonDelivery-Report" ":" 6205 / "Generate-Delivery-Report" ":" 6206 / "Alternate-Recipient" ":" prohibition 6207 / "Disclose-Recipients" ":" prohibition 6208 / "Content-Return" ":" prohibition 6210 Prevent-NonDelivery-Report and Generate-Delivery-Report allow | 6211 setting of | 6212 MTS.PerRecipientSubmissionFields.originator-report-request. The | 6213 setting will be the same for all recipients. | 6215 Alternate-Recipient, Disclose-Recipients, and Content-Return | 6216 allow for override of the default settings for | 6217 MTS.PerMessageIndicators. 6219 INTERNET DRAFT 6220 MIXER DRAFT Version 2.1 6222 Appendix D - Object Identifier Assignment 6224 The following Object Identifiers shall be used. | 6226 mixer OBJECT IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) | 6227 private(4) enterprises(1) isode-consortium (453) | 6228 mixer(15)} | 6230 id-rfc-822-field-list OBJECT IDENTIFIER ::= {mixer field(1)} | 6231 id-hex-multipart-message OBJECT IDENTIFIER ::= {mixer field(2)} | 6232 id-hex-partial-message OBJECT IDENTIFIER ::= {mixer field(3)} | 6233 id-dsn-header-list OBJECT IDENTIFIER ::= {mixer field(4)} | 6234 id-dsn-field-list OBJECT IDENTIFIER ::= {mixer field(5)} | 6235 id-mime-body-part OBJECT IDENTIFIER ::= {mixer field(6)} | 6236 id-mime-body-part-parameters OBJECT IDENTIFIER ::= {mixer field(7)}| 6238 This object identifier for id-rfc-822-field-list is different to | 6239 the one assigned in RFC 1327, which was erroneous. | 6241 Editor's | 6242 ISO has been asked for an Object Identifier root, which is | 6243 expected to replace this one. The above ID is a (valid) | 6244 place-holder, in case this assignment does not materialise. 6246 INTERNET DRAFT 6247 MIXER DRAFT Version 2.1 6249 Appendix E - BNF Summary 6251 boolean = "TRUE" / "FALSE" 6253 numericstring = *DIGIT 6255 printablestring = *( ps-char ) 6256 ps-restricted-char = 1DIGIT / 1ALPHA / " " / "'" / "+" 6257 / "," / "-" / "." / "/" / ":" / "=" / "?" 6258 ps-delim = "(" / ")" 6259 ps-char = ps-delim / ps-restricted-char 6261 ps-encoded = *( ps-restricted-char / ps-encoded-char ) 6262 ps-encoded-char = "(a)" ; (@) 6263 / "(p)" ; (%) 6264 / "(b)" ; (!) 6265 / "(q)" ; (") 6266 / "(u)" ; (_) 6267 / "(l)" ; "(" 6268 / "(r)" ; ")" 6269 / "(" 3DIGIT ")" 6271 teletex-string = *( ps-char / t61-encoded ) 6272 t61-encoded = "{" 1* t61-encoded-char "}" 6273 t61-encoded-char = 3DIGIT 6275 teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ] 6277 labelled-integer ::= [ key-string ] "(" numericstring ")" 6279 key-string = *key-char 6280 key-char = 6282 INTERNET DRAFT 6283 MIXER DRAFT Version 2.1 6285 object-identifier ::= oid-comp object-identifier 6286 | oid-comp 6288 oid-comp ::= [ key-string ] "(" numericstring ")" 6290 encoded-info = 1#encoded-type 6292 encoded-type = built-in-eit / object-identifier 6294 built-in-eit = "Undefined" ; undefined (0) 6295 / "Telex" ; tLX (1) 6296 / "IA5-Text" ; iA5Text (2) 6297 / "G3-Fax" ; g3Fax (3) 6298 / "TIF0" ; tIF0 (4) 6299 / "Teletex" ; tTX (5) 6300 / "Videotex" ; videotex (6) 6301 / "Voice" ; voice (7) 6302 / "SFD" ; sFD (8) 6303 / "TIF1" ; tIF1 (9) 6305 encoded-pn = [ given "." ] *( initial "." ) surname 6307 given = 2* 6309 initial = ALPHA 6311 surname = printablestring 6313 INTERNET DRAFT 6314 MIXER DRAFT Version 2.1 6316 std-or-address = 1*( "/" attribute "=" value ) "/" 6317 attribute = standard-type 6318 / "RFC-822" 6319 / registered-dd-type 6320 / dd-key "." std-printablestring 6321 standard-type = key-string 6323 registered-dd-type 6324 = key-string 6325 dd-key = key-string 6327 value = std-printablestring 6329 std-printablestring 6330 = *( std-char / std-pair ) 6331 std-char = <"{", "}", "*", and any ps-char 6332 except "/" and "="> 6333 std-pair = "$" ps-char 6335 global-id = std-or-address * 6337 mta-field = "X400-Received" ":" x400-trace 6338 / "Deferred-Delivery" ":" date-time 6339 / "Latest-Delivery-Time" ":" date-time 6341 x400-trace = "by" md-and-mta ";" 6342 [ "deferred until" date-time ";" ] 6343 [ "converted" "(" encoded-info ")" ";" ] 6344 [ "attempted" md-or-mta ";" ] 6345 action-list 6346 ";" arrival-time 6348 INTERNET DRAFT 6349 MIXER DRAFT Version 2.1 6351 md-and-mta = [ "mta" mta "in" ] global-id 6352 mta = word 6353 arrival-time = date-time 6355 md-or-mta = "MD" global-id 6356 / "MTA" mta 6358 Action-list = 1#action 6359 action = "Redirected" 6360 / "Expanded" 6361 / "Relayed" 6362 / "Rerouted" 6364 INTERNET DRAFT 6365 MIXER DRAFT Version 2.1 6367 dr-user-info = dr-summary | 6368 dr-recipients 6369 dr-content-return * 6371 dr-content-return = "The Original Message is not available" 6372 / "The Original Message follows:" 6374 dr-summary = "This report relates to your message:" 6375 content-correlator 6376 "of" date-time 6378 dr-recipients = *(dr-recipient ) 6380 dr-recipient = dr-recip-success / dr-recip-failure 6382 dr-recip-success = 6383 "Your message was successfully delivered to:" 6384 mailbox "at" date-time 6386 dr-recip-failure = "Your message was not delivered to:" 6387 mailbox 6388 "for the following reason:" *word 6390 report-point = [ "mta" word "in" ] global-id | 6391 content-correlator = *word | 6393 INTERNET DRAFT 6394 MIXER DRAFT Version 2.1 6396 dr-per-message-fields = | 6397 / "X400-Conversion-Date" ":" date-time | 6398 / "X400-Subject-Submision-Identifier" ":" | 6399 mts-msg-id 6400 / "X400-Content-Identifier" ":" printablestring | 6401 / "X400-Content-Type" ":" mts-content-type | 6402 / "X400-Original-Encoded-Information-Types" ":" | 6403 encoded-info 6404 / "X400-Originator-and-DL-Expansion-History" ":" | 6405 dl-history 6406 / "X400-Reporting-DL-Name" ":" mailbox | 6407 / "X400-Content-Correlator" ":" content-correlator| 6408 / "X400-Recipient-Info" ":" recipient-info | 6409 / "X400-Subject-Intermediate-Trace-Information" ":"| 6410 x400-trace 6411 / dr-extensions | 6413 INTERNET DRAFT 6414 MIXER DRAFT Version 2.1 6416 dr-per-recipient-fields = | 6417 / "X400-Redirect-Recipient" ":" "x400" ";" std-or| 6418 / "X400-Mapped-Redirect-Recipient" ":" "rfc822" ";" mailbox| 6419 / "X400-Converted-EITs" ":" encoded-info ";" | 6420 / "X400-Delivery-Time" ":" date-time | 6421 / "X400-Type-of-MTS-User" ":" labelled-integer | 6422 / "X400-Last-Trace" ":" [ encoded-info ] date-time | 6423 / "X400-Supplementary-Info" ":" | 6424 <"> printablestring <"> ";" | 6425 / "X400-Redirection-History" ":" redirection-comment| 6426 / "X400-Physical-Forwarding-Address" ":" printablestring| 6427 / "X400-Originally-Specified-Recipient-Number" ":"| 6428 integer | 6429 / dr-extensions | 6431 dr-extensions = "X400-Discarded-DR-Extensions" ":" | 6432 1# (object-identifier / labelled-integer)| 6434 dl-history = 1#( mailbox "(" date-time ")") | 6436 / "X400-Diagnostic" ":" labelled-integer | 6437 / "X400-Reason" ":" labelled-integer | 6439 dr-diagnostic = "Reason" labelled-integer | 6440 [ ";" "Diagnostic" labelled-integer ] | 6442 INTERNET DRAFT 6443 MIXER DRAFT Version 2.1 6445 mts-field = "X400-MTS-Identifier" ":" mts-msg-id 6446 / "X400-Originator" ":" mailbox 6447 / "X400-Recipients" ":" 1#mailbox 6448 / "Original-Encoded-Information-Types" ":" 6449 encoded-info 6450 / "X400-Content-Type" ":" mts-content-type 6451 / "Content-Identifier" ":" printablestring 6452 / "Priority" ":" priority 6453 / "Originator-Return-Address" ":" 1#mailbox 6454 / "DL-Expansion-History" ":" mailbox ";" date-time ";" 6455 / "Conversion" ":" prohibition 6456 / "Conversion-With-Loss" ":" prohibition 6457 / "Requested-Delivery-Method" ":" 6458 1*( labelled-integer ) 6459 / "Delivery-Date" ":" date-time 6460 / "Discarded-X400-MTS-Extensions" ":" 6461 1#( object-identifier / labelled-integer )| 6463 prohibition = "Prohibited" / "Allowed" 6465 mts-msg-id = "[" global-id ";" *text "]" 6467 mts-content-type = "P2" / labelled-integer 6468 / object-identifier | 6470 priority = "normal" / "non-urgent" / "urgent" 6472 INTERNET DRAFT 6473 MIXER DRAFT Version 2.1 6475 ipn-body-format = ipn-description * 6476 [ ipn-extra-information ] 6477 [ ipn-content-return ] 6479 ipn-description = ipn-receipt / ipn-non-receipt 6481 ipn-receipt = "Your message to:" preferred-recipient 6482 "was received at" receipt-time 6483 "This notification was generated" 6484 acknowledgement-mode 6485 "The following extra information was given:" 6486 ipn-suppl 6488 ipn-non-receipt "Your message to:" 6489 preferred-recipient 6490 ipn-reason 6492 ipn-reason = ipn-discarded / ipn-auto-forwarded 6494 ipn-discarded = "was discarded for the following reason:" 6495 discard-reason 6497 ipn-auto-forwarded = "was automatically forwarded." 6498 [ "The following comment was made:" 6499 auto-comment ] 6501 ipn-extra-information = 6502 "The following information types were converted:" 6503 encoded-info 6505 ipn-content-return = "The Original Message is not available" 6506 / "The Original Message follows:" 6508 preferred-recipient = mailbox 6509 receipt-time = date-time 6510 auto-comment = printablestring 6511 ipn-suppl = printablestring 6513 INTERNET DRAFT 6514 MIXER DRAFT Version 2.1 6516 discard-reason = "Expired" / "Obsoleted" / 6517 "User Subscription Terminated" 6519 acknowledgement-mode = "Manually" / "Automatically" 6521 ipms-field = "Obsoletes" ":" 1#msg-id 6522 / "Expiry-Date" ":" date-time 6523 / "Reply-By" ":" date-time 6524 / "Importance" ":" importance 6525 / "Sensitivity" ":" sensitivity 6526 / "Autoforwarded" ":" boolean 6527 / "Incomplete-Copy" ":" 6528 / "Language" ":" 1#language | 6529 / "Message-Type" ":" message-type 6530 / "Discarded-X400-IPMS-Extensions" ":" 1#object-identifier| 6531 / "Autosubmitted" ":" autosubmitted | 6533 importance = "low" / "normal" / "high" 6535 sensitivity = "Personal" / "Private" / 6536 "Company-Confidential" 6538 language = 2*ALPHA [ language-description ] 6539 language-description = printable-string 6541 message-type = "Delivery Report" | 6542 / "InterPersonal Notification" 6543 / "Multiple Part" 6545 autosubmitted = "not-auto-submitted" || 6546 / "auto-generated" || 6547 / "auto-replied" || 6548 / "auto-forwarded" || 6550 INTERNET DRAFT 6551 MIXER DRAFT Version 2.1 6553 redirect-comment = 6554 [ "Originally To:" ] mailbox "Redirected" 6555 [ "Again" ] "on" date-time 6556 "To:" redirection-reason 6558 redirection-reason = 6559 "Recipient Assigned Alternate Recipient" 6560 / "Originator Requested Alternate Recipient" 6561 / "Recipient MD Assigned Alternate Recipient" 6562 / "Recipient Directory Substitution Alternate Recipient"| 6564 subject-line = "Delivery-Report" "(" status ")" 6565 [ "for" destination ] 6567 status = "success" / "failure" / "success and failures" 6569 destination = mailbox / "MTA" word 6571 extended-heading = 6572 "Prevent-NonDelivery-Report" ":" 6573 / "Generate-Delivery-Report" ":" 6574 / "Alternate-Recipient" ":" prohibition 6575 / "Disclose-Recipients" ":" prohibition 6576 / "Content-Return" ":" prohibition 6578 ftbp-field = "FTBP-Pathname" ":" *text 6579 / "FTBP-Object-Size" ":" integer 6580 / "FTBP-Creation-Date" ":" date-time 6581 / "FTBP-Modification-Date" ":" date-time 6582 "FTBP-Read-Date" ":" date-time 6584 INTERNET DRAFT 6585 MIXER DRAFT Version 2.1 6587 Appendix F - Format of address mapping tables | 6589 1. Global Mapping Information 6591 The consistent operation of gateways which follow this 6592 specification relies of the existence of three globally defined 6593 mappings: 6595 1. Domain Name Space -> O/R Address Space 6597 2. O/R Address Space -> Domain Name Space 6599 3. Domain Name Space -> O/R Address of preferred gateway 6601 All gateways conforming to this specification shall have access 6602 to these mappings. The gateway may use standardised or private 6603 mechanisms to access this mapping information. 6605 One means of distributing this information is in three 6606 files. This appendix defines a format for these files. | 6608 2. Mechanisms to register and to distribute Mapping Rules | 6610 The global coordination of the mapping rules is a part of | 6611 the DANTE | 6612 MailFLOW Project. New mapping rules can be defined by the | 6613 authority | 6614 responsible for the relevant name space. The rules must be | 6615 registered | 6616 with a national mapping registration authority, which in | 6617 turn passes | 6618 them on to the central mapping registration authority. | 6619 All the collected mapping rules are merged together into the | 6620 globally | 6621 coordinated mapping tables by the MailFLOW Project Team. The | 6622 three | 6623 tables are available from the national mapping registration | 6624 authorities. | 6626 To get a contact address of the mapping registration | 6627 authority for the | 6628 respective country or more information about the MailFLOW | 6630 INTERNET DRAFT 6631 MIXER DRAFT Version 2.1 6633 Project | 6634 contact: | 6636 SWITCH | 6637 MailFLOW Project Team | 6638 Limmatquai 138 | 6639 8001 Zuerich | 6640 Switzerland | 6642 email: mailflow@mailflow.dante.net || 6643 S=MailFLOW;O=MailFLOW;P=DANTE;A=mailnet;C=fi; || 6645 fax: +41 1 268 15 68 || 6646 tel: +41 1 268 15 20 || 6648 3. Syntax Definitions 6650 An address syntax is defined, which is compatible with the syntax 6651 used for 822.domains. By representing the O/R addresses as 6652 domains, all lookups can be mechanically implemented as domain -> 6653 domain mappings. This syntax defined is initially for use in 6654 table format, but the syntax is defined in a manner which makes 6655 it suitable to be adapted for use with the Domain Name Service. 6656 This syntax allows for a general representation of O/R addresses, 6657 so that it can be used in other applications. Not all attributes 6658 are used in the table formats defined. 6660 To allow the mapping of null attributes to be represented, 6661 the pseudo-value "@" (not a printable string character) is used 6662 to indicate omission of a level in the hierarchy. This is 6663 distinct from the form including the element with no value, 6664 although a correct X.400 implementation will interpret both in 6665 the same manner. 6667 This syntax is not intended to be handled by users. 6669 INTERNET DRAFT 6670 MIXER DRAFT Version 2.1 6672 dmn-or-address = dmn-part *( "." dmn-part ) | 6673 mn-part = dmn-attribute "$" value | 6674 dmn-attribute = standard-type | 6675 / "~" dmn-printablestring | 6676 value = dmn-printablestring 6677 / "@" 6678 dmn-printablestring = 6679 = *( dmn-char / dmn-pair ) 6680 dmn-char = <"{", "}", "*", and any ps-char 6681 except "."> 6682 dmn-pair = "\." 6684 An example usage: 6686 ~ROLE$Big\.Chief.ADMD$ATT.C$US 6687 PRMD$DEC.ADMD$@.C$US 6689 The first example illustrates quoting of a "." and a domain | 6690 define attribute (ROLE). The second example illustrates | 6691 omission of the ADMD level. There must be a strict ordering of 6692 all components in this table, with the most significant 6693 components on the RHS. This allows the encoding to be treated 6694 as a domain. 6696 Various further restrictions are placed on the usage of 6697 dmn-or-address in the address space mapping tables. 6699 1. Only C, ADMD, PRMD, O, and up to four OUs may be used. 6701 2. No components shall be omitted from this hierarchy, although 6702 the hierarchy may terminate at any level. If the mapping is 6703 to an omitted component, the "@" syntax is used. 6705 4. Table Lookups 6707 When determining a match, there are aspects which apply to all 6708 lookups. Matches are always case independent. The key for all 6709 three tables is a domain. The longest possible match shall be 6710 obtained. Suppose the table has two entries with the following 6711 keys: 6713 INTERNET DRAFT 6714 MIXER DRAFT Version 2.1 6716 K.L 6717 J.K.L 6719 Domain "A.B.C" will not return any matches. Domain "I.J.K.L" 6720 will match the entry "J.K.L:. 6722 5. Domain -> O/R Address format 6724 The BNF is: 6726 domain-syntax "#" dmn-or-address "#" 6728 EBNF.domain-syntax is defined in Section 4.2. Note that the | 6729 trailing "#" is used for clarity, as the dmn-or-address syntax | 6730 might lead to values with trailing blanks. Lines starting with | 6731 "#" are comments. 6733 For example: 6734 AC.UK#PRMD$UK\.AC.ADMD$GOLD 400.C$GB# 6735 XEROX.COM#O$Xerox.ADMD$ATT.C$US# 6736 GMD.DE#O$@.PRMD$GMD.ADMD$DBP.C$DE# 6738 A domain is looked up to determine the top levels of an O/R 6739 Address. Components of the domain which are not matched are used 6740 to build the remainder of the O/R address, as described in 6741 Section 4.3.4. 6743 6. O/R Address -> Domain format 6745 The syntax of this table is: 6747 dmn-or-address "#" domain-syntax "#" 6749 For example: 6751 # 6752 # Mapping table 6753 # 6754 PRMD$UK\.AC.ADMD$GOLD 400.C$GB#AC.UK# 6756 The O/R Address is used to generate a domain key. It is 6757 important to order the components correctly, and to fill in 6759 INTERNET DRAFT 6760 MIXER DRAFT Version 2.1 6762 missing components in the hierarchy. Use of this mapping is 6763 described in Section 4.3.2. 6765 7. Domain -> O/R Address of Gateway table 6767 This uses the same format as the domain -> O/R address mapping. | 6768 In this case, the restriction to only use C/ADMD/PRMD/O/OU does | 6769 not apply. Use of this mapping is described in Section 4.3.4. A | 6770 domain cannot appear in this table and in the domain to O/R | 6771 Address table. 6773 INTERNET DRAFT 6774 MIXER DRAFT Version 2.1 6776 Appendix G - Conformance | 6778 This appendix defines a number of options, which a conforming * 6779 gateway should specify. Conformance to this specification shall 6780 not be claimed if any of the mandatory features are not | 6781 implemented. A specification of conformance may list the service | 6782 elements of Chapter 2, in order to be clear that full conformance | 6783 is provied. In particular: 6785 - Formats for all fields shall be followed. 6787 - The global mappings shall be supported. | 6789 - Formats for subject lines, delivery reports and IPNs shall 6790 be followed. A system which followed the syntax, but 6791 translated text into a language other than english would be 6792 conformant. 6794 - RFC 1137 shall not be followed when mapping to SMTP. | 6796 - All mappings of trace shall be implemented. 6798 - There must be a mechanism to access all three global 6799 mappings. | 6801 - RFC 1494 shall be followed for mapping body parts. | 6803 - When it is specified that a MIME format message is | 6804 generated, RFC 1521 shall be followed. 6806 A gateway should specify: 6808 - Which 822-MTS protocols are supported. If SMTP is | 6809 supported, Appendex A of MIXER shall be used. 6811 - Which X.400 versions are supported (84, 88, 92). | 6813 - The means by which it can access the global mappings. 6814 Currently, the tables of the formats define in Appendix F 6815 is the only means available. 6817 - The approach taken to return of contents (5.2) * 6819 INTERNET DRAFT 6820 MIXER DRAFT Version 2.1 6822 - The approach taken to multiple copies vs non-disclosure * 6823 (4.6.2.2) | 6825 - The mechanism or mechanisms by which the global mapping | 6826 information is accessed. 6828 The following are optional parts of this specification. A 6829 conforming implementation should specify which of these it 6830 supports. 6832 - Generation of extended RFC 822 fields is mandatory. 6833 Optionally, they may be parsed and mapped back to X.400. A 6834 gateway should should indicate if this is done, listing the | 6835 mappings performed according to each service element of | 6836 Chapter 2. 6838 - Support for the extension mappings of Appendix C. | 6840 - Support for returning illegal format content in a delivery 6841 report 6843 - Which address interpretation heuristics are supported 6844 (4.3.4.1) 6846 - If RFC 987 generated message ids are handled in a backwards 6847 compatible manner (4.7.3.6) | 6849 - Support for FTBP. 6851 INTERNET DRAFT 6852 MIXER DRAFT Version 2.1 6854 Appendix H - Change History: RFC 987, 1026, 1138, 1148 | 6856 RFC 987 was the original document, and contained the key elements 6857 of this specification. It was specific to X.400(1984). RFC 1026 6858 specified a small number of necessary changes to RFC 987. 6860 RFC 1138 was based on the RFC 987 work. It contained an 6861 editorial error, and was reissued a few months later as RFC 1148. 6862 RFC 1148 will be referred to here, as it is the document which is 6863 widely referred to elsewhere. The major goal of RFC 1148 was to 6864 upgrade RFC 987 to X.400(1988). It did this, but did not 6865 obsolete RFC 987, which was recommended for use with X.400(1984). 6866 This appendix summarises the changes made in going from RFC 987 6867 to RFC 1148. 6869 RFC 1148 noted the following about its upgrade from RFC 987: 6870 Unnecessary change is usually a bad idea. Changes on the RFC 822 6871 side are avoided as far as possible, so that RFC 822 users do 6872 not see arbitrary differences between systems conforming to this 6873 specification, and those following RFC 987. Changes on the X.400 6874 side are minimised, but are more acceptable, due to the mapping 6875 onto a new set of services and protocols. 6877 1. Introduction 6879 The model has shifted from a protocol based mapping to a service 6880 based mapping. This has increased the generality of the 6881 specification, and improved the model. This change affects the 6882 entire document. 6884 A restriction on scope has been added. 6886 2. Service Elements 6888 - The new service elements of X.400 are dealt with. 6890 - A clear distinction is made between origination and 6891 reception 6893 INTERNET DRAFT 6894 MIXER DRAFT Version 2.1 6896 3. Basic Mappings 6898 - Add teletex support 6900 - Add object identifier support 6902 - Add labelled integer support 6904 - Make PrintableString <-> ASCII mapping reversible 6906 - The printable string mapping is aligned to the NBS mapping 6907 derived from RFC 987. 6909 4. Addressing 6911 - Support for new addressing attributes 6913 - The message ID mapping is changed to not be table driven 6915 5. Detailed Mappings 6917 - Define extended IPM Header, and use instead of second body 6918 part for RFC 822 extensions 6920 - Realignment of element names 6922 - New syntax for reports, simplifying the header and 6923 introducing a mandatory body format (the RFC 987 header 6924 format was unusable) 6926 - Drop complex autoforwarded mapping 6928 - Add full mapping for IP Notifications, defining a body 6929 format 6931 - Adopt an MTS Identifier syntax in line with the O/R Address 6932 syntax 6934 - A new format for X400 Trace representation on the RFC 822 6935 side 6937 INTERNET DRAFT 6938 MIXER DRAFT Version 2.1 6940 6. Appendices 6942 - Move Appendix on restricted 822 mappings to a separate RFC 6944 - Delete Phonenet and SMTP Appendixes 6946 INTERNET DRAFT 6947 MIXER DRAFT Version 2.1 6949 Appendix I - Change History: RFC 1148 to RFC 1327 | 6951 1. General 6953 - The scope of the document was changed to cover X.400(1984), 6954 and so obsolete RFC 987. 6956 - Changes were made to allow usage to connect RFC 822 networks 6957 using X.400 6959 - Text was tightened to be clear about optional and mandatory 6960 aspects 6962 - A good deal of clarification 6964 - A number of minor EBNF errors 6966 - Better examples are given 6968 - Further X.400 upper bounds are handled correctly 6970 2. Basic Mappings 6972 - The encoding of object identifier is changed slightly 6974 3. Addressing 6976 - A global mapping of domain to preferred gateway is 6977 introduced. 6979 - An overflow mechanism is defined for RFC 822 addresses of 6980 greater than 128 bytes 6982 - Changes were made to improve compatibility with the PDAM on | 6983 writing O/R Addresses. 6985 + The PD and Terminal Type keywords were aligned to the 6986 PDAM. It is believed that minimal use has been made of 6987 the RFC 1148 keywords. 6989 INTERNET DRAFT 6990 MIXER DRAFT Version 2.1 6992 + P and A are allowed as alternate keys for PRMD and ADMD 6994 + Where keywords are different, the PDAM keywords are 6995 alternatives on input. This is mandatory. 6997 4. Detailed Mappings 6999 - The format of the Subject: lines is defined. 7001 - Illegal use (repetition) of the heading EXTENSION is 7002 corrected, and a new object identifier assigned. 7004 - The Delivery Report format is extensively revised in light 7005 of operational experience. 7007 - The handling of redirects is significantly changed, as the 7008 previous mechanism did not work. 7010 5. Appendices 7012 - An SMTP appendix is added, allowing optional use of the VRFY 7013 command to improve probe information. 7015 - Handling of JNT Mail Acknowledge-To is changed slightly. 7017 - A DDA JNT-MAIL is allowed on input. 7019 - The format definitions of Appendix F are explained further, 7020 and a third table definition added. 7022 - An appendix on use with X.400(1984) is added. 7024 - Optional extensions are defined to give RFC 822 access to 7025 further X.400 facilities. 7027 - An appendix on conformance is added. | 7029 INTERNET DRAFT 7030 MIXER DRAFT Version 2.1 7032 Appendix J - Change History: RFC 1327 to this Document | 7034 1. General | 7036 This update is primarily for stability, and to fold in | 7037 compatibility for MIME and to add support for the new NOTARY | 7038 delivery status notifications. Other general changes: | 7040 - Various editorial updates | 7042 - Minor EBNF errors | 7044 - Reference to mapping table support by DNS and X.500. | 7046 - Alignment to X.400(92) | 7048 - Assignment of a new object identifier | 7050 - Support for the EMA profile of the File Transfer Body Part. | 7052 2. Service Elements | 7054 - Support of Auto-Submitted service | 7056 3. Basic Mappings | 7058 - Comments may not be used in new headers, to remove parsing | 7059 ambiguity | 7061 - RFC 1522 encoding may be used as an alternative to X.408 | 7062 downgrade, where appropriate. | 7064 4. Addressing | 7066 - Restructure of text to emphasise the global mappings | 7068 - Add codes and add a heuristic to align to the standard X.400 | 7069 form of writing O/R Addresses. | 7071 INTERNET DRAFT 7072 MIXER DRAFT Version 2.1 7074 - Improved text on ordering heuristic | 7076 - Leading "/" heuristic added | 7078 - Make report request comments optional | 7080 5. Detailed Mappings | 7082 - Comments no loner maps to separate body part | 7084 - Allow Langauges to be multi-valued | 7086 - Change Content-Identifier to X400-Content-Identifier, in | 7087 order to avoid confusion with MIME. | 7089 6. Appendices | 7091 - Relaxation of restrictions on mapping 3 in Appendix F. | 7093 - Add linkage to HARPOON in Appendix B. | 7095 - RFC 1494 added to the conformance statement of Appendix G. | 7097 INTERNET DRAFT 7098 MIXER DRAFT Version 2.1 7100 SECURITY CONSIDERATIONS 7102 Security considerations are not discussed in this RFC. 7104 AUTHOR'S ADDRESS 7106 Steve Kille 7107 ISODE Consortium | 7108 The Dome | 7109 The Square | 7110 Richmond | 7111 TW9 1DT | 7112 England 7114 Phone: +44-181-332-9091 | 7116 Internet EMail: S.Kille@ISODE.COM | 7118 X.400 Email: I=S; S=Kille; O=ISODE Consortium; P=ISODE; A=Mailnet; C=FI;| 7120 UFN: S.Kille, ISODE Consortium, GB | 7122 INTERNET DRAFT 7123 MIXER DRAFT Version 2.1 7125 References 7127 1. 7129 2. 7131 3. 7133 4. 7135 5. 7137 6. 7139 7. 7141 8. C. Allocchio, "Mapping between X.400(1984/1988) and Mail-11 7142 (DECnet mail)," RFC 1405, jan 1993. 7144 9. C. Allocchio, B. Cole, S. Giordano, and R. Hagens, "Using 7145 the Internet DNS to Distribute RFC 1327 Mail Address Mapping 7146 Tables," RFC 1664, aug 1994. 7148 10. H.T. Alvestrand, S.E. Kille, R. Miles, M. Rose, and S. 7149 Thompson, "Mapping between X.400 and RFC-822 Message 7150 Bodies," RFC 1495, Aug 1993. 7152 11. H.T. Alvestrand, J. Romaguera, and K. Jordan, "Rules for 7153 Downgrading Messages for X.400(88) to X.400(84) When MIME 7154 Consent-Types are Present in the Messages (Harpoon)," RFC 7155 1496, Aug 1993. 7157 12. H.T. Alvestrand and S. Thompson, "Equivalences between X.400 7158 and RFC-822 Message Bodies," RFC 1494, Aug 1993. 7160 13. H.T. Alvestrand, "Tags for the Identification of Languages," 7161 RFC 17566, March 1995. 7163 14. N. Borenstein and N. Freed, "MIME (Multipurpose Internet 7164 Mail Extensions)," RFC 1521, Sep 1993. 7166 15. R.T. Braden, "Requirements for Internet Hosts -- Application 7167 and Support," RFC 1123, Oct 1989. 7169 INTERNET DRAFT 7170 MIXER DRAFT Version 2.1 7172 16. CCITT/ISO, "CCITT Recommendations X.420/ ISO IS 10021-7," 7173 Message Handling Systems: Interpersonal Messaging System, 7174 December 1988. 7176 17. CCITT/ISO, "CCITT Recommendations X.411/ ISO IS 10021-4," 7177 Message Handling Systems: Message Transfer System: Abstract 7178 Service Definition and Procedures, December 1988. 7180 18. CCITT/ISO, "Specification of Abstract Syntax Notation One 7181 (ASN.1)," CCITT Recommendation X.208 / ISO IS 8824, December 7182 1988. 7184 19. CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1," 7185 Message Handling: System and Service Overview , December 7186 1988. 7188 20. CCITT/ISO, "CCITT Recommendations X.400/ ISO IS 10021-1," 7189 Message Handling: System and Service Overview , December 7190 1992. 7192 21. D.H. Crocker, "Standard of the Format of ARPA Internet Text 7193 Messages," RFC 822, August 1982. 7195 22. S.E. Kille, "Mapping Between X.400 and RFC 822," UK Academic 7196 Community Report (MG.19) / RFC 987, June 1986. 7198 23. S.E. Kille, "Addendum to RFC 987," UK Academic Community 7199 Report (MG.23) / RFC 1026, August 1987. 7201 24. S.E. Kille, "Mapping between full RFC 822 and RFC 822 with 7202 restricted encoding," RFC 1137, October 1989. 7204 25. S.E. Kille, "Mapping Between X.400(1988) / ISO 10021 and RFC 7205 822," RFC 1138, October 1989. 7207 26. S.E. Kille, "Mapping Between X.400(1988) / ISO 10021 and RFC 7208 822," RFC 1148, March 1990. 7210 27. S.E. Kille, "Mapping Between X.400(1988) / ISO 10021 and RFC 7211 822," RFC 1327, May 1992. 7213 28. S.E. Kille, "X.400 1988 to 1984 downgrading," RFC 1328, May 7214 1992. 7216 INTERNET DRAFT 7217 MIXER DRAFT Version 2.1 7219 29. S.E. Kille, "A String Representation of Distinguished Name," 7220 RFC 1485, Jan 1992. 7222 30. S.E. Kille, "Using the OSI Directory to achieve User 7223 Friendly Naming," RFC 1484, Jan 1992. 7225 31. S.E. Kille, "Use of the X.500 Directory to support mapping 7226 between X.400 and RFC 822 Addresses," RFC in preparation, 7227 Sep 1994. 7229 32. N. Koorland, "Message Attachmment Work Group (MAWG): MAWG 7230 Feasibility Project Guide," EMA Report, Version 1.3, March 7231 1995. 7233 33. K. Moore and G. Vaudreuil, "An Extensible Message Format for 7234 Delivery Status Notifications," RFC Draft, May 1995. 7236 34. K. Moore, "SMTP Service Extensions for Delivery Status 7237 Notifications," RFC Draft, May 1995. 7239 35. J.B. Postel, "SIMPLE MAIL TRANSFER PROTOCOL," RFC 821, 7240 August 1982. 7242 36. CEN/CENELEC/Information Technology/Working Group on Private 7243 Message Handling Systems, "FUNCTIONAL STANDARD A/3222," 7244 CEN/CLC/IT/WG/PMHS N 17, October 1985. 7246 2 - Basic Mappings ................................ 166 7247 3 - Addressing .................................... 166 7248 4 - Detailed Mappings ............................. 167 7249 5 - Appendices .................................... 167 7250 Appendix J - Change History: RFC 1327 to this Document | 7251 168......................................................... | 7252 1 - General 168.................................... | 7253 2 - Service Elements 168........................... | 7254 3 - Basic Mappings 168............................. | 7255 4 - Addressing 168................................. | 7256 5 - Detailed Mappings 169.......................... | 7257 6 - Appendices 169................................. | 7259 INTERNET DRAFT 7260 MIXER DRAFT Version 2.1