idnits 2.17.1 draft-kille-mixer-rfc1327bis-04.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-23) 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 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 56 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 137 instances of too long lines in the document, the longest one being 12 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 37 has weird spacing: '...ch will enabl...' == Line 38 has weird spacing: '...working betwe...' == Line 42 has weird spacing: '...2 mail proto...' == Line 44 has weird spacing: '...systems which...' == Line 45 has weird spacing: '...ervices offer...' == (51 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 (February 1997) is 9929 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? '1' on line 41 looks like a reference -- Missing reference section? '13' on line 1600 looks like a reference -- Missing reference section? '15' on line 41 looks like a reference -- Missing reference section? '16' on line 2551 looks like a reference -- Missing reference section? '9' on line 1605 looks like a reference -- Missing reference section? '17-21' on line 49 looks like a reference -- Missing reference section? '4' on line 51 looks like a reference -- Missing reference section? '30' on line 197 looks like a reference -- Missing reference section? '10' on line 2698 looks like a reference -- Missing reference section? '11' on line 265 looks like a reference -- Missing reference section? '12' on line 301 looks like a reference -- Missing reference section? '28' on line 5237 looks like a reference -- Missing reference section? '22' on line 6039 looks like a reference -- Missing reference section? '5' on line 6045 looks like a reference -- Missing reference section? '8' on line 475 looks like a reference -- Missing reference section? '6' on line 6043 looks like a reference -- Missing reference section? '21' on line 545 looks like a reference -- Missing reference section? '2' on line 617 looks like a reference -- Missing reference section? '27' on line 1530 looks like a reference -- Missing reference section? '0' on line 1547 looks like a reference -- Missing reference section? '14' on line 1557 looks like a reference -- Missing reference section? '23' on line 1994 looks like a reference -- Missing reference section? '3' on line 2325 looks like a reference -- Missing reference section? '26' on line 2328 looks like a reference -- Missing reference section? '24' on line 3200 looks like a reference -- Missing reference section? '25' on line 3201 looks like a reference -- Missing reference section? '7' on line 4684 looks like a reference -- Missing reference section? '29' on line 5900 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 7 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 Ltd. 3 INTERNET-DRAFT February 1997 4 Expires: August 1997 5 File: draft-kille-mixer-rfc1327bis-04.txt 7 MIXER (Mime Internet X.400 Enhanced Relay): 9 Mapping between X.400 and RFC 822/MIME 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. Internet Drafts are draft 17 documents valid for a maximum of six months. Internet Drafts may be 18 updated, replaced, or obsoleted by other documents at any time. It is 19 not appropriate to use Internet Drafts as reference material or to 20 cite them other than as a ``working draft'' or ``work in progress.'' 21 Please check the I-D abstract listing contained in each Internet Draft 22 directory to learn the current status of this or any other Internet 23 Draft. 25 Network Working Group S.E. Kille 26 Internet Draft Isode Ltd. 27 RFC 1327bis February 1997 28 Obsoletes: RFCs 987, 1026, 1138, 1148, 1327, 1495 29 Updates: RFC 822 31 MIXER (Mime Internet X.400 Enhanced Relay): 33 Mapping between X.400 and RFC 822/MIME 35 Status of this Memo: 37 This document describes a set of mappings which will enable 38 interworking between systems operating the CCITT X.400 39 Recommendations on Message Handling Systems (1984, 1988 and 40 1992 versions) / ISO IEC 10021 Message Oriented Text 41 Interchange Systems (MOTIS) [1,13,15], and systems using the 42 RFC 822 mail protocol [16] or protocols derived from RFC 43 822, supplemented by the MIME specifications [9]. Older 44 systems which do not use MIME are still supported. The 45 approach aims to maximise the services offered across the 46 boundary, whilst not requiring unduly complex mappings. The 47 mappings should not require any changes to end systems. This 48 document is a revision based on the evolving sequence of 49 RFCs 987, 1026, 1138, 1148 and 1327 [17-21], which it 50 obsoletes. It incorporates changes specified in RFC 1495 51 [4], which it also obsoletes. 53 This document specifies a mapping between two families of 54 protocols, which includes both protocol/service mappings and 55 use of a mandatory global mappings. This specification 56 should be used when this mapping is performed. 58 This draft document will be submitted to the RFC editor as 59 a protocol specification. Distribution of this memo is 60 unlimited. Please send comments to the WG mailing list 61 . 63 RFC 1327bis 64 MIXER DRAFT Version 2.6 66 Table of Contents 68 1 - Overview ...................................... 6 69 1.1 - X.400 ......................................... 6 70 1.2 - RFC 822 and MIME .............................. 6 71 1.3 - The need for conversion ....................... 7 72 1.4 - General approach .............................. 7 73 1.5 - Gatewaying Model .............................. 8 74 1.6 - Support of X.400 (1984) ....................... 11 75 1.7 - X.400 (1992) .................................. 12 76 1.8 - MIME .......................................... 12 77 1.9 - Body Parts .................................... 12 78 1.10 - Local and Global Scenarios ................... 13 79 1.11 - Compatibility with previous versions ......... 14 80 1.12 - Aspects not covered .......................... 14 81 1.13 - Subsetting ................................... 14 82 1.14 - Specification Language ....................... 15 83 1.15 - Related Specifications ....................... 15 84 1.16 - Document Structure ........................... 15 85 1.17 - Acknowledgements ............................. 16 86 2 - Service Elements .............................. 18 87 2.1 - The Notion of Service Across a Gateway ........ 18 88 2.2 - RFC 822 ....................................... 19 89 2.3 - X.400 ......................................... 23 90 3 - Basic Mappings ................................ 34 91 3.1 - Notation ...................................... 34 92 3.2 - ASCII and IA5 ................................. 36 93 3.3 - Standard Types ................................ 36 94 3.4 - Encoding ASCII in Printable String ............ 40 95 3.5 - RFC 1522 ...................................... 41 96 4 - Addressing and Message IDs .................... 43 97 4.1 - A textual representation of MTS.ORAddress ..... 44 98 4.2 - Global Address Mapping ........................ 52 99 4.3 - EBNF.822-address <-> MTS.ORAddress ............ 56 100 4.4 - Repeated Mappings ............................. 69 101 4.5 - Directory Names ............................... 72 102 4.6 - MTS Mappings .................................. 72 103 4.7 - IPMS Mappings ................................. 77 105 RFC 1327bis 106 MIXER DRAFT Version 2.6 108 5 - Detailed Mappings ............................. 83 109 5.1 - RFC 822 -> X.400: Detailed Mappings ........... 83 110 5.2 - Return of Contents ............................ 100 111 5.3 - X.400 -> RFC 822: Detailed Mappings ........... 100 112 Appendix A - Mappings Specific to SMTP ..................... 135 113 1 - Probes ........................................ 135 114 2 - Long Lines .................................... 135 115 3 - SMTP Extensions ............................... 135 116 3.1 - SMTP Extension mapping to X.400 ............... 135 117 3.2 - X.400 Mapping to SMTP Extensions .............. 136 118 Appendix B - Mapping with X.400(1984) ................. 138 119 Appendix C - RFC 822 Extensions for X.400 access ........... 140 120 Appendix D - Object Identifier Assignment .................. 141 121 Appendix E - BNF Summary ................................... 142 122 Appendix F - Text format for MCGAM distribution ............ 152 123 1 - Text Formats .................................. 152 124 2 - Mechanisms to register and to distribute 125 MCGAMs ..................................................... 152 126 3 - Syntax Definitions ............................ 153 127 4 - Table Lookups ................................. 154 128 5 - Domain -> OR Address MCGAM format ............. 155 129 6 - OR Address -> Domain MCGAM format ............. 155 130 7 - Domain -> OR Address of Preferred Gateway 131 table ...................................................... 156 132 8 - OR Addresss -> domain of Preferred Gateway 133 table ...................................................... 156 134 Appendix G - Conformance ................................... 157 135 Appendix H - Change History: RFC 987, 1026, 1138, 1148 136 ............................................................ 159 137 1 - Introduction .................................. 159 138 2 - Service Elements .............................. 159 139 3 - Basic Mappings ................................ 160 140 4 - Addressing .................................... 160 141 5 - Detailed Mappings ............................. 160 142 6 - Appendices .................................... 161 143 Appendix I - Change History: RFC 1148 to RFC 1327 .......... 162 144 1 - General ....................................... 162 145 2 - Basic Mappings ................................ 162 146 3 - Addressing .................................... 162 147 4 - Detailed Mappings ............................. 163 148 5 - Appendices .................................... 163 149 Appendix J - Change History: RFC 1327 to this Document 150 ............................................................ 164 151 1 - General ....................................... 164 153 RFC 1327bis 154 MIXER DRAFT Version 2.6 156 2 - Service Elements .............................. 164 157 3 - Basic Mappings ................................ 164 158 4 - Addressing .................................... 164 159 5 - Detailed Mappings ............................. 165 160 6 - Appendices .................................... 165 161 Appendix L - ASN.1 Summary ............................ 167 163 Chapter 1 -- Overview 165 1.1. X.400 167 This document relates primarily to the ITU-T 1988 and 1992 X.400 168 Series Recommendations / ISO IEC 10021 International Standard. 169 This ISO/ITU-T standard is referred to in this document as 170 "X.400", which is a convenient shorthand. Any reference to the 171 1984 Recommendations will be explicit. Any mappings relating to 172 elements which are in the 1992 version and not in the 1988 173 version will be noted explicitly. X.400 defines an Interpersonal 174 Messaging System (IPMS), making use of a store and forward 175 Message Transfer System. This document relates to the IPMS, and 176 not to wider application of X.400, such as EDI as defined in 177 X.435. 179 1.2. RFC 822 and MIME 181 RFC 822 evolved as a messaging standard on the DARPA (the US 182 Defense Advanced Research Projects Agency) Internet. RFC 822 183 specifies an end to end message format, consisting of a header 184 and an unstructured text body. MIME (Multipurpose Internet Mail 185 Extensions) specifies a structured message body format for use 186 with RFC 822. The term "RFC 822" is used in this document to 187 refer to the combination of MIME and RFC 822. RFC 822 and MIME 188 are used in conjunction with a number of different message 189 transfer protocol environments. The core of the MIXER 190 specification is designed to work with any supporting message 191 transfer protocol. 193 One transfer protocol, SMTP, is of particular importance and 194 is covered in MIXER. On the Internet and other TCP/IP networks, 195 RFC 822 is used in conjunction with 196 RFC 821, also known as Simple Mail Transfer Protocol (SMTP) 197 [30], in a manner conformant with the host requirements 198 specification [10]. Use of MIXER with SMTP is defined in 199 Appendix A. 201 RFC 1327bis 202 MIXER DRAFT Version 2.6 204 1.3. The need for conversion 206 There is a large community using RFC 822 based protocols for mail 207 services, who will wish to communicate with users of the IPMS 208 provided by X.400 systems. This will also be a requirement in 209 cases where communities intend to make a transition between the 210 different technologies, as conversion will be needed to ensure a 211 smooth service transition. It is expected that there will be 212 more than one gateway, and this specification will enable them to 213 behave in a consistent manner. Note that the term gateway is 214 used to describe a component performing the mapping between RFC 215 822 and X.400. This is standard usage amongst mail implementors, 216 but differs from that used by transport and network service 217 implementors. 219 Consistency between gateways is desirable to provide: 221 1. Consistent service to users. 223 2. The best service in cases where a message passes through 224 multiple gateways. 226 1.4. General approach 228 There are a number of basic principles underlying the details of 229 the specification. These principles are goals, and are not 230 achieved in all aspects of the specification. 232 1. The specification should be pragmatic. There should not be 233 a requirement for complex mappings for "Academic" reasons. 234 Complex mappings should not be required to support trivial 235 additional functionality. 237 2. Subject to 1), functionality across a gateway should be as 238 high as possible. 240 3. It is always a bad idea to lose information as a result of 241 any transformation. Hence, it is a bad idea for a gateway 242 to discard information in the objects it processes. This 243 includes requested services which cannot be fully mapped. 245 4. Mail gateways operate at a level above the layer on which 246 they perform mappings. This implies that the gateway shall 247 not only be cognisant of the semantics of objects at the 249 RFC 1327bis 250 MIXER DRAFT Version 2.6 252 gateway level, but also be cognisant of higher level 253 semantics. If meaningful transformation of the objects that 254 the gateway operates on is to occur, then the gateway needs 255 to understand more than the objects themselves. 257 5. Subject to 1), the mapping should be reversible. That is, a 258 double transformation should bring you back to where you 259 started. 261 1.5. Gatewaying Model 263 1.5.1. X.400 265 X.400 defines the IPMS Abstract Service in X.420 , [11] which 266 comprises of three basic services: 268 1. Origination 270 2. Reception 272 3. Management 274 Management is a local interaction between the user and the IPMS, 275 and is therefore not relevant to gatewaying. The first two 276 services consist of operations to originate and receive the 277 following two objects: 279 1. IPM (Interpersonal Message). This has two components: a 280 heading, and a body. The body is structured as a sequence 281 of body parts, which may be basic components (e.g., IA5 282 text, or G3 fax), or forwarded Interpersonal Messages. The 283 heading consists of fields containing end to end user 284 information, such as subject, primary recipients (To:), and 285 importance. 287 2. IPN (Inter Personal Notification). A notification about 288 receipt of a given IPM at the UA level. 290 The Origination service also allows for origination of a probe, 291 which is an object to test whether a given IPM could be correctly 292 received. 294 The Reception service also allows for receipt of Delivery Reports 295 (DR), which indicate delivery success or failure. 297 RFC 1327bis 298 MIXER DRAFT Version 2.6 300 These IPMS Services utilise the Message Transfer System 301 (MTS) Abstract Service [12]. The MTS Abstract Service provides 302 the following three basic services: 304 1. Submission (used by IPMS Origination) 306 2. Delivery (used by IPMS Reception) 308 3. Administration (used by IPMS Management) 310 Administration is a local issue, and so does not affect this 311 standard. Submission and delivery relate primarily to the MTS 312 Message (comprising Envelope and Content), which carries an IPM 313 or IPN (or other uninterpreted contents). The Envelope includes 314 a message identifier, an originator, and a list of recipients. 315 Submission also includes the probe service, which supports the 316 MTS Probe. Delivery also includes Reports, which indicate whether 317 a given MTS Message has been delivered or not (or for a probe if 318 delivery would have happened). 320 The MTS is provided by MTAs which interact using the MTA 321 (Message Transfer Agent) Service, which defines the interaction 322 between MTAs, along with the procedures for distributed 323 operation. This service provides for transfer of MTS Messages, 324 Probes, and Reports. 326 1.5.2. RFC 822 328 RFC 822 is based on the assumption that there is an underlying 329 service, which is here called the 822-MTS service. The 822-MTS 330 service provides three basic functions: 332 1. Identification of a list of recipients. 334 2. Identification of an error return address. 336 3. Transfer of an RFC 822 message. 338 It is possible to achieve 2) within the RFC 822 header. 340 This specification will be used most commonly with SMTP as 341 the 822-MTS service. The core MIXER specification is written so 342 that it does not rely on non-basic 822-MTS services. Use of 343 non-basic SMTP services is described in Appendix A. The core of 345 RFC 1327bis 346 MIXER DRAFT Version 2.6 348 this document is written using SMTP terminology for 822-MTS 349 services. 351 An RFC 822 message consists of a header, and content which 352 is uninterpreted ASCII text. The header is divided into fields, 353 which are the protocol elements. Most of these fields are 354 analogous to IPM heading fields, although some are analogous to 355 MTS Service Elements or MTA Service Elements. 357 RFC 822 supports delivery status notifications by use of the 358 NOTARY mechanisms [28]. 360 1.5.3. The Gateway 362 Given this functional description of the two services, the 363 functional nature of a gateway can now be considered. It would 364 be elegant to consider the SMTP (822-MTS) service mapping onto 365 the MTS Service Elements and RFC 822 mapping onto an IPM, but 366 there is a not a clear match between these services. Another 367 elegant approach would be to treat this document as the 368 definition of an X.400 Access Unit (AU). In this case, the 369 abstraction level is too high, and some necessary mapping 370 function is lost. It is necessary to consider that the IPM 371 format definition, the IPMS Service Elements, the MTS Service 372 Elements, and MTA Service Elements on one side are mapped into 373 RFC 822 + SMTP on the other in a slightly tangled manner. The 374 details of the tangle will be made clear in Chapter 5. Access to 375 the MTA Service Elements is minimised. 377 The following basic mappings are thus defined. When going 378 from RFC 822 to X.400, an RFC 822 message and the associated SMTP 379 information is always mapped into an IPM (MTA, MTS, and IPMS 380 Services) and a Delivery Status Notification is mapped onto a 381 Report. Going from X.400 to RFC 822, an RFC 822 message and the 382 associated SMTP information may be derived from: 384 1. An IPN (MTA, MTS, and IPMS services) 386 2. An IPM (MTA, MTS, and IPMS services) 388 A Report (MTA, and MTS Services) is mapped onto a delivery status 389 notification. 391 Probes (MTA Service) shall be processed by the gateway, as 393 RFC 1327bis 394 MIXER DRAFT Version 2.6 396 discussed in Chapter 5. MTS Messages containing Content Types 397 other than those defined by the IPMS are not mapped by the 398 gateway, and shall be rejected at the gateway if no other 399 gatewaying procedure is defined. 401 This specification is concerned with X.400 IPMS. Future 402 specifications may defined mappings for other X.400 content 403 types. 405 1.5.4. Repeated Mappings 407 The primary goal of this specification is to support single 408 mappings, so that X.400 and RFC 822 users can communicate with 409 maximum functionality. 411 The mappings specified here are designed to work where a 412 message traverses multiple times between X.400 and RFC 822. This 413 is often essential, particularly in the case of distribution 414 lists. However, in general, this will lead to a level of service 415 which is the lowest common denominator (approximately the 416 services offered by RFC 822). 418 Some RFC 822 networks may wish to use X.400 as an 419 interconnection mechanism (typically for policy reasons), and 420 this is fully supported. 422 Where an X.400 message transfers to RFC 822 and then back to 423 X.400, there is no expectation of X.400 services which do not 424 have an equivalent service in standard RFC 822 being preserved - 425 although this may be possible in some cases. 427 1.6. Support of X.400 (1984) 429 The MIXER definition is based on the initial specification of RFC 430 987 and in its addendum RFC 1026, which defined a mapping between 431 X.400(1984) and RFC 822. The core MIXER mapping is defined using 432 the full 1988 version of X.400, and not to a 1984 compatible 433 subset. New features of X.400(1988) can be used to provide a much 434 cleaner mapping than that defined in RFC 987. To interwork with 435 1984 systems, Appendix B shall be followed. 437 If a message is being transferred to an X.400(1984) system 438 by way of X.400(1988) MTA it will give a slightly better service 439 to follow the rules of Appendix B, than to downgrade without this 441 RFC 1327bis 442 MIXER DRAFT Version 2.6 444 knowledge. Downgrading specifications which supplement those 445 specified in X.400 (X.419) are given in RFC 1328[22] and RFC 1496 446 (HARPOON) [5]. 448 1.7. X.400 (1992) 450 X.400 (1992) features are not used by the core of this mapping, 451 and so there is not an equivalent downgrade problem. 453 1.8. MIME 455 MIME format messages are generated by this mapping. As MIME 456 messages are fully RFC 822 compliant, this will not cause 457 problems with systems which are not MIME capable. 459 1.9. Body Parts 461 MIME and X.400 IPMS can both carry arbitrary body parts. MIME 462 defines a mechanism for adding new body parts, and new body parts 463 are registered with the IANA. X.400 defines a mechanism adding 464 new body parts, usually referred to as Body Part 15. Extensions 465 are defined by Object Identifiers, so there is no requirement for 466 a central body part registration authority. The Electronic 467 Messaging Association (EMA) maintains a list of some commonly 468 used body parts. The EMA has specified a mechanism to use the 469 File Transfer Body Part (FTBP) as a more generic means to support 470 message attachments. This approach is gaining widespread 471 commercial support. 473 The mapping between X.400 and MIME body parts is defined in 474 the companion MIXER specification, referenced here as RFC 1494bis 475 [8]. This document is an update of RFC 1494 [6]. 477 Editor's Note: 478 References to 1494bis will be resolved as these two 479 documents are expected to progress in parallel. 481 These two specifications together form the complete MIXER 483 RFC 1327bis 484 MIXER DRAFT Version 2.6 486 Mapping. 488 1.10. Local and Global Scenarios 490 There are two basic scenarios for X.400/MIME interworking: 492 Global Scenario 493 There are two global mail networks (Internet/MIME and 494 X.400), interconnected by multiple gateways. Objects may 495 be transferred over multiple gateways, and so it is 496 important that gateways behave in a coherent fashion. 497 MIXER is critical to support this scenario. 499 Local Scenario 500 A gateway is used to connect a closed community to a global 501 mail network (this could be enforced by connectivity or 502 gateway authorisation policy). This is a common commercial 503 scenario. MIXER is useful to support this scenario, as it 504 allows an industry standard provision of service, but this 505 could be supported by something which was MIXER-like. 507 A solution for the global scenario will work for the local 508 scenario. However, there are aspects of MIXER which have 509 significant implementation or deployment effort (the global 510 mapping is the major one, but there are other details too) which 511 and are needed to support the global scenario, but are not needed 512 in the local scenario. 514 Note that the local scenario may be the driving force for 515 most deployments, and support of the global scenario may be an 516 important secondary goal. 518 There is also a transition effect. Gateways which are 519 initially deployed in a strict local scenario situation start to 520 find themselves in a global scenario. A common case is ADMD 521 provided gateways, which are targeted strictly at the local 522 scenario. In practice they soon start to operate in the global 523 scenario, because of distribution lists and messages exchanged 524 with X.400 users that are not customers of the ADMD. At this 525 point, users are hurt by the restrictions of a local scenario 526 gateway. 528 Note that conformance to MIXER applies to an instantiation 529 of a gateway, not just an implementation (although clearly it is 531 RFC 1327bis 532 MIXER DRAFT Version 2.6 534 critical that the implementation is capable of being operated in 535 a conformant manner). 537 MIXER's conformance target is the global scenario, and the 538 specification of MIXER defines operation in this way. 540 1.11. Compatibility with previous versions 542 The changes between this and older versions of the document are 543 given in Appendices H, I and J. These are RFCs 987, 1026, 544 1138, 1148 and 1327. This document is a revision of RFC 1327 545 [21]. As far as possible, changes have been made in a compatible 546 fashion. 548 1.12. Aspects not covered 550 There have been a number of cases where previous versions of this 551 document were used in a manner which was not intended. This 552 section is to make clear some limitations of scope. In 553 particular, this specification does not specify: 555 - Extensions of RFC 822 to provide access to all X.400 556 services 558 - X.400 user interface definition 560 These are really coupled. To map the X.400 services, this 561 specification defines a number of extensions to RFC 822. As a 562 side effect, these give the 822 user access to SOME X.400 563 services. However, the aim on the RFC 822 side is to preserve 564 current service, and it is intentional that access is not given 565 to all X.400 services. Thus, it will be a poor choice for X.400 566 implementors to use MIXER as an interface - there are too many 567 aspects of X.400 which cannot be accessed through it. If a text 568 interface is desired, a specification targeted at X.400, without 569 RFC 822 restrictions, would be more appropriate. Some optional 570 and limited extensions in this area have proved useful, and are 571 defined in Appendix C. 573 1.13. Subsetting 575 This proposal specifies a mapping which is appropriate to 576 preserve services in existing RFC 822 communities. 577 Implementations and specifications which subset this 579 RFC 1327bis 580 MIXER DRAFT Version 2.6 582 specification are non-conformant and strongly discouraged. 584 1.14. Specification Language 586 ISO and Internet standards have clear definitions as to the style 587 of language used. This specification maps between ISO/ITU-T 588 protocol and Internet protocols. This document uses ISO 589 terminology for the following reasons: 591 1. This was done in previous versions. 593 2. ISO language may be mechanically converted to Internet 594 language, but not vice versa. 596 The key elements of the ISO rules are: 598 1. All mandatory features shall clearly be indicated by 599 imperative statements or the word "shall" or "shall not". 601 2. Optional features shall be indicated by the word "may". 603 3. The word "should" and the phrase "may not" shall not be 604 used. 606 In some cases the specification issues guidance on use of 607 optional features, by use of the the phrase word "recommended" or 608 "not recommended". 610 To interpet this document according to Internet rules, replace 611 every occurrence of "shall" with "must". 613 1.15. Related Specifications 615 Mappings between Mail-11 and X.400 and Mail-11 and rfc822 are 616 described in RFC1405, using mappings related to those defined 617 here [2]. 619 1.16. Document Structure 621 This document has five chapters: 623 1. Overview - this chapter. 625 2. Service Elements - This describes the (end user) services 627 RFC 1327bis 628 MIXER DRAFT Version 2.6 630 mapped by a gateway. 632 3. Basic mappings - This describes some basic notation used in 633 Chapters 3-5, the mappings between character sets, and some 634 fundamental protocol elements. 636 4. Addressing - This considers the mapping between X.400 OR 637 names and RFC 822 addresses, which is a fundamental gateway 638 component. 640 5. Detailed Mappings - This describes the details of all other 641 mappings. 643 There are also ten appendices. 645 WARNING: 646 THE REMAINDER OF THIS SPECIFICATION IS TECHNICALLY DETAILED. 647 IT WILL NOT MAKE SENSE, EXCEPT IN THE CONTEXT OF RFC 822 AND 648 X.400 (1988). DO NOT ATTEMPT TO READ THIS DOCUMENT UNLESS 649 YOU ARE FAMILIAR WITH THESE SPECIFICATIONS. 651 1.17. Acknowledgements 653 The work in this specification was substantially based on RFC 987 654 and RFC 1148, which had input from many people, who are credited 655 in the respective documents. 657 A number of comments from people on RFC 1148 lead to RFC 658 1327. In particular, there were comments and suggestions from: 659 Maurice Abraham (HP); Harald Alvestrand (Sintef); Peter Cowen 660 (X-Tel); Jim Craigie (JNT); Ella Gardner (MITRE); Christian 661 Huitema (Inria); Erik Huizer (SURFnet); Neil Jones (DEC); Ignacio 662 Martinez (IRIS); Julian Onions (X-Tel); Simon Poole (SWITCH); 663 Clive Roberts (Data General); Pete Vanderbilt (SUN); Alan Young 664 (Concurrent). 666 RFC 1327 has been widely adopted, and a review team was 667 formed. This comprised of: Urs Eppenberger (SWITCH)(Chair); 668 Claudio Allocchio (INFN); Harald Alvestrand (UNINETT); Dave 669 Crocker (Brandenburg); Ned Freed (Innosoft); Erik Huizer 670 (SURFnet); Steve Kille (Isode); Peter Sylvester (GC Tech) 672 RFC 1327bis 673 MIXER DRAFT Version 2.6 675 Harald Alvestrand also supplied the tables mapping DSN 676 status codes with X.400 codes. Ned Freed defined parts of the 677 File Transfer Body Part mapping. 679 Comment and input has also been received from: Bengt 680 Ackzell (Generic Systems); Samir Albadine (Transpac); Mark Boyes 681 (DEC); Larry Campbell (Boston Software Works); Jacqui Caren 682 (Cray); Allan Cargille (MCI); Kevin Carrosso (Innosoft); Charlie 683 Combs (OIW); Jim Craigie (Net-Tel); Eamon Doyle (Isocor); Efifion 684 Edem (SITA); Jyrki Heikkinen (ICL); Edward Hibbert (DCL); Jeroun 685 Houttin (Terena); Kevin Jordan (CDS); Paul Kingsnorth (DEC); 686 Carl-Uno Manros (Manros Consulting); Suzan Mendes (Telis); Robert 687 Miles (Softswitch); Roger Mizumorri (Enterprise Solutions Ltd); 688 Keith Moore (University of Tennessee); Ruth Moulton (Net-Tel) 689 Michel Musy (Bull); Kenji Nonaka (NTT): The OIW MHSIG; Tom 690 Oliphant (SWITCH); Julian Onions (NEXOR); Jacob Palme (KTH); 691 Olivier Paridaens (ULB); Mary la Roche (Citicorp); John Setsaas 692 (Maxware); Russell Sharpe (DCL); Patrick Soulier (CCETT); 693 Eftimios Tsigros (Universite Libre de Bruxelles); Sean Turner 694 (IECA); Mark Wahl (Isode); David Wilson (Isode); Bill Wohler 695 (Worldtalk); Alan Young (Isode); Alain Zahm (Telis). 697 RFC 1327bis 698 MIXER DRAFT Version 2.6 700 Chapter 2 - Service Elements 702 This chapter considers the services offered across a gateway 703 built according to this specification. It gives a view of the 704 functionality provided by such a gateway for communication with 705 users in the opposite domain. This chapter considers service 706 mappings in the context of SINGLE transfers only, and not 707 repeated mappings through multiple gateways. 709 2.1. The Notion of Service Across a Gateway 711 RFC 822 and X.400 provide a number of services to the end user. 712 This chapter describes the extent to which each service can be 713 supported across an X.400 <-> RFC 822 gateway. The cases 714 considered are single transfers across such a gateway, although 715 the problems of multiple crossings are noted where appropriate. 717 2.1.1. Origination of Messages 719 When a user originates a message, a number of services are 720 available. Some of these imply actions (e.g., delivery to a 721 recipient), and some are insertion of known data (e.g., 722 specification of a subject field). This chapter describes, for 723 each offered service, to what extent it is supported for a 724 recipient accessed through a gateway. There are three levels of 725 support: 727 Supported 728 The corresponding protocol elements map well, and so the 729 service can be fully provided. 731 Not Supported 732 The service cannot be provided, as there is a complete 733 mismatch. 735 Partial Support 736 The service can be partially fulfilled. 738 In the first two cases, the service is simply marked as 739 "Supported" or "Not Supported". Some explanation may be given if 740 there are additional implications, or the (non) support is not 741 intuitive. For partial support, the level of partial support is 743 RFC 1327bis 744 MIXER DRAFT Version 2.6 746 summarised. Where partial support is good, this will be 747 described by a phrase such as "Supported by use of.....". A 748 common case of this is where the service is mapped onto a non- 749 standard service on the other side of the gateway, and this would 750 have lead to support if it had been a standard service. In many 751 cases, this is equivalent to support. For partial support, an 752 indication of the mechanism is given, in order to give a feel for 753 the level of support provided. Note that this is not a 754 replacement for Chapter 5, where the mapping is fully specified. 756 If a service is described as supported, this implies: 758 - Semantic correspondence. 760 - No (significant) loss of information. 762 - Any actions required by the service element. 764 An example of a service gaining full support: If an RFC 822 765 originator specifies a Subject: field, this is considered to be 766 supported, as an X.400 recipient will get a subject indication. 768 In many cases, the required action will simply be to make the 769 information available to the end user. In other cases, actions 770 may imply generating a delivery report. 772 All RFC 822 services are supported or partially supported 773 for origination. The implications of non-supported X.400 774 services is described under X.400. 776 2.1.2. Reception of Messages 778 For reception, the list of service elements required to support 779 this mapping is specified. This is really an indication of what 780 a recipient might expect to see in a message which has been 781 remotely originated. 783 2.2. RFC 822 785 RFC 822 does not explicitly define service elements, as distinct 786 from protocol elements. However, all of the RFC 822 header 787 fields, with the exception of trace, can be regarded as 788 corresponding to implicit RFC 822 service elements. 790 RFC 1327bis 791 MIXER DRAFT Version 2.6 793 2.2.1. Origination in RFC 822 795 A mechanism of mapping, used in several cases, is to map the RFC 796 822 header into a heading extension in the IPM (InterPersonal 797 Message). This can be regarded as partial support, as it makes 798 the information available to any X.400 implementations which are 799 interested in these services. Communities which require 800 significant RFC 822 interworking are recommended to require that 801 their X.400 User Agents are able to display these heading 802 extensions. Support for the various service elements (headers) 803 is now listed. 805 Date: 806 Supported. 808 From: 809 Supported. For messages where there is also a sender field, 810 the mapping is to "Authorising Users Indication", which has 811 subtly different semantics to the general RFC 822 usage of 812 From:. 814 Sender: 815 Supported. 817 Reply-To: 818 Supported. 820 To: Supported. 822 Cc: Supported. 824 Bcc: Supported. 826 Message-Id: 827 Supported. 829 In-Reply-To: 830 Supported, for a single reference. Where multiple 831 references are given, partial support is given by mapping to 832 "Cross Referencing Indication". This gives similar 833 semantics. 835 References: 836 Supported. 838 RFC 1327bis 839 MIXER DRAFT Version 2.6 841 Keywords: 842 Supported by use of a heading extension. 844 Subject: 845 Supported. 847 Comments: 848 Supported by use of a heading extension. 850 Encrypted: 851 Supported by use of a heading extension. 853 Content-Language: 854 Supported. 856 Resent-* 857 Supported by use of a heading extension. Note that 858 addresses in these fields are mapped onto text, and so are 859 not accessible to the X.400 user as addresses. In 860 principle, fuller support would be possible by mapping onto 861 a forwarded IP Message, but this is not suggested. 863 Other Fields 864 In particular X-* fields, and "illegal" fields in common 865 usage (e.g., "Fruit-of-the-day:") are supported by use of 866 heading extensions. 868 MIME introduces a number of headings. Support is defined in RFC 869 1494bis. 871 2.2.2. Reception by RFC 822 873 This considers reception by an RFC 822 User Agent of a message 874 originated in an X.400 system and transferred across a gateway. 875 The following standard services (headers) may be present in such 876 a message: 878 Date: 880 From: 882 Sender: 884 Reply-To: 886 RFC 1327bis 887 MIXER DRAFT Version 2.6 889 To: 891 Cc: 893 Bcc: 895 Message-Id: 897 In-Reply-To: 899 References: 901 Subject: 903 Content-Type: (See RFC 1494bis) 905 Content-Transfer-Encoding: (See RFC 1494bis) 907 MIME-Version: (See RFC 1494bis) 909 The following services (headers) may be present in the header of 910 a message. These are defined in more detail in Chapter 5 (5.3.4, 911 5.3.6, 5.3.7): 913 Autoforwarded: 915 Autosubmitted: 917 X400-Content-Identifier: 919 Content-Language: 921 Conversion: 923 Conversion-With-Loss: 925 Delivery-Date: 927 Discarded-X400-IPMS-Extensions: 929 Discarded-X400-MTS-Extensions: 931 DL-Expansion-History: 933 RFC 1327bis 934 MIXER DRAFT Version 2.6 936 Deferred-Delivery: 938 Expires: 940 Importance: 942 Incomplete-Copy: 944 Latest-Delivery-Time: 946 Message-Type: 948 Original-Encoded-Information-Types: 950 Originator-Return-Address: 952 Priority: 954 Reply-By: 956 Sensitivity: 958 Supersedes: 960 X400-Content-Type: 962 X400-MTS-Identifier: 964 X400-Originator: 966 X400-Received: 968 X400-Recipients: 970 2.3. X.400 972 2.3.1. Origination in X.400 974 When mapping services from X.400 to RFC 822 which are not 975 supported by RFC 822, new RFC 822 headers are defined, and 976 registered by publication in this standard. It is intended that 977 co-operating RFC 822 systems may also use them. Where these new 978 fields are used, and no system action is implied, the service can 979 be regarded as being partially supported. Chapter 5 describes 981 RFC 1327bis 982 MIXER DRAFT Version 2.6 984 how to map X.400 services onto these new headers. Other elements 985 are provided, in part, by the gateway as they cannot be provided 986 by RFC 822. 988 Some service elements are marked N/A (not applicable). 989 There are five cases, which are marked with different comments: 991 N/A (local) 992 These elements are only applicable to User Agent / Message 993 Transfer Agent interaction and so they cannot apply to RFC 994 822 recipients. 996 N/A (PDAU) 997 These service elements are only applicable where the 998 recipient is reached by use of a Physical Delivery Access 999 Unit (PDAU), and so do not need to be mapped by the gateway. 1001 N/A (reception) 1002 These services are only applicable for reception. 1004 N/A (prior) 1005 If requested, this service shall be performed prior to the 1006 gateway. 1008 N/A (MS) 1009 These services are only applicable to Message Store (i.e., a 1010 local service). 1012 Finally, some service elements are not supported. In 1013 particular, the new security services are not mapped onto RFC 1014 822. Unless otherwise indicated, the behaviour of service 1015 elements marked as not supported will depend on the criticality 1016 marking supplied by the user. If the element is marked as 1017 critical for transfer or delivery, a non-delivery notification 1018 will be generated. Otherwise, the service request will be 1019 ignored. 1021 2.3.1.1. Basic Interpersonal Messaging Service 1023 These are the mandatory IPM services as listed in Section 19.8 of 1024 X.400 / ISO/IEC 10021-1, listed here in the order given. Section 1025 19.8 has cross references to short definitions of each service. 1027 Access management 1029 RFC 1327bis 1030 MIXER DRAFT Version 2.6 1032 N/A (local). 1034 Content Type Indication 1035 Supported by a new RFC 822 header (X400-Content-Type:). 1037 Converted Indication 1038 Supported by a new RFC 822 header (X400-Received:). 1040 Delivery Time Stamp Indication 1041 N/A (reception). 1043 IP Message Identification 1044 Supported. 1046 Message Identification 1047 Supported, by use of a new RFC 822 header 1048 (X400-MTS-Identifier). This new header is required, as 1049 X.400 has two message-ids whereas RFC 822 has only one (see 1050 IP Message Identification 1052 Non-delivery Notification 1053 Not supported in all cases. Supported where the recipient 1054 system supports NOTARY DSNs. In general all RFC 822 systems 1055 will return error reports by use of IP messages. In other 1056 service elements, this pragmatic result can be treated as 1057 effective support of this service element. 1059 Original Encoded Information Types Indication 1060 Supported as a new RFC 822 header 1061 (Original-Encoded-Information-Types:). 1063 Submission Time Stamp Indication 1064 Supported. 1066 Typed Body 1067 Support is defined in RFC 1494bis. 1069 User Capabilities Registration 1070 N/A (local). 1072 2.3.1.2. IPM Service Optional User Facilities 1074 This section describes support for the optional (user selectable) 1075 IPM services as listed in Section 19.9 of X.400 / ISO/IEC 10021- 1077 RFC 1327bis 1078 MIXER DRAFT Version 2.6 1080 1, listed here in the order given. Section 19.9 has cross 1081 references to short definitions of each service. 1083 Additional Physical Rendition 1084 N/A (PDAU). 1086 Alternate Recipient Allowed 1087 Not supported. There is no RFC 822 service equivalent to 1088 prohibition of alternate recipient assignment (e.g., an RFC 1089 822 system may freely send an undeliverable message to a 1090 local postmaster). A MIXER gateway has two conformant 1091 options. The first is not to gateway a message requesting 1092 prohibition of alternate recipient, as this control cannot 1093 be guaranteed. This option supports the service, but may 1094 cause unacceptable level of message rejections. The second 1095 is to gateway the message on the basis that there is no 1096 alternate recipient service in RFC 822. RFC 1327 allowed 1097 only the second option. If the first option is shown to be 1098 operationally effective, it may be the only option in future 1099 versions of MIXER. 1101 Authorising User's Indication 1102 Supported. 1104 Auto-forwarded Indication 1105 Supported as new RFC 822 header (Auto-Forwarded:). 1107 Basic Physical Rendition 1108 N/A (PDAU). 1110 Blind Copy Recipient Indication 1111 Supported. 1113 Body Part Encryption Indication 1114 Supported by use of a new RFC 822 header 1115 (Original-Encoded-Information-Types:), although in most 1116 cases it will not be possible to map the body part in 1117 question. 1119 Content Confidentiality 1120 Not supported. 1122 Content Integrity 1123 Not supported. 1125 RFC 1327bis 1126 MIXER DRAFT Version 2.6 1128 Conversion Prohibition 1129 Supported. Operation defined in RFC 1494bis. 1131 Conversion Prohibition in Case of Loss of Information 1132 Supported. Operation defined in RFC 1494bis. 1134 Counter Collection 1135 N/A (PDAU). 1137 Counter Collection with Advice 1138 N/A (PDAU). 1140 Cross Referencing Indication 1141 Supported. 1143 Deferred Delivery 1144 N/A (prior). This service shall always be provided by the 1145 MTS prior to the gateway. A new RFC 822 header 1146 (Deferred-Delivery:) is provided to transfer information on 1147 this service to the recipient. 1149 Deferred Delivery Cancellation 1150 N/A (local). 1152 Delivery Notification 1153 Supported. This is performed at the gateway, but may be 1154 performed at the end system if the end system supports 1155 NOTARY. Thus, a notification is sent by the gateway to the 1156 originator. 1158 Delivery via Bureaufax Service 1159 N/A (PDAU). 1161 Designation of Recipient by Directory Name 1162 N/A (local). 1164 Disclosure of Other Recipients 1165 Supported by use of a new RFC 822 header (X400-Recipients:). 1166 This is descriptive information for the RFC 822 recipient, 1167 and is not reverse mappable. 1169 DL Expansion History Indication 1170 Supported by use of a new RFC 822 header 1171 (DL-Expansion-History:). 1173 RFC 1327bis 1174 MIXER DRAFT Version 2.6 1176 DL Expansion Prohibited 1177 Distribution List means MTS supported distribution list, in 1178 the manner of X.400. This service does not exist in the RFC 1179 822 world, although RFC 822 supports distribution list 1180 functionality. There is no SMTP leve control to prohibit 1181 distribution list expansion. A MIXER gateway has two 1182 conformant options. The first is not to gateway a message 1183 requesting DL expansion prohibition, as this control cannot 1184 be guaranteed. This option supports the service, but may 1185 cause unacceptable level of message rejections. The second 1186 is to gateway the message on the basis that there is no 1187 distribution list service in RFC 822. RFC 1327 allowed only 1188 the second option. If the first option is shown to be 1189 operationally effective, it may be the only option in future 1190 versions of MIXER. 1192 Express Mail Service 1193 N/A (PDAU). 1195 Expiry Date Indication 1196 Supported as new RFC 822 header (Expires:). In general, no 1197 automatic action can be expected. 1199 Explicit Conversion 1200 N/A (prior). 1202 Forwarded IP Message Indication 1203 Supported. 1205 Grade of Delivery Selection 1206 Not Supported. There is no equivalent service in RFC 822. 1208 Importance Indication 1209 Supported as new RFC 822 header (Importance:). 1211 Incomplete Copy Indication 1212 Supported as new RFC 822 header (Incomplete-Copy:). 1214 Language Indication 1215 Supported as new RFC 822 header (Content-Language:). 1217 Latest Delivery Designation 1218 Not supported. A new RFC 822 header (Latest-Delivery-Time:) 1219 is provided, which may be used by the recipient for general 1221 RFC 1327bis 1222 MIXER DRAFT Version 2.6 1224 information, but will not be acted on by the SMTP 1225 infrastrucuture. 1227 Message Flow Confidentiality 1228 Not supported. 1230 Message Origin Authentication 1231 N/A (reception). 1233 Message Security Labelling 1234 Not supported. 1236 Message Sequence Integrity 1237 Not supported. 1239 Multi-Destination Delivery 1240 Supported. 1242 Multi-part Body 1243 Supported. 1245 Non Receipt Notification Request 1246 Not supported. 1248 Non Repudiation of Delivery 1249 Not supported. 1251 Non Repudiation of Origin 1252 N/A (reception). 1254 Non Repudiation of Submission 1255 N/A (local). 1257 Obsoleting Indication 1258 Supported as new RFC 822 header (Supersedes:). 1260 Ordinary Mail 1261 N/A (PDAU). 1263 Originator Indication 1264 Supported. 1266 Originator Requested Alternate Recipient 1267 Not supported, but is placed as comment next to address 1269 RFC 1327bis 1270 MIXER DRAFT Version 2.6 1272 (X400-Recipients:). 1274 Physical Delivery Notification by MHS 1275 N/A (PDAU). 1277 Physical Delivery Notification by PDS 1278 N/A (PDAU). 1280 Physical Forwarding Allowed 1281 Supported by use of a comment in a new RFC 822 header 1282 (X400-Recipients:), associated with the recipient in 1283 question. 1285 Physical Forwarding Prohibited 1286 Supported by use of a comment in a new RFC 822 header 1287 (X400-Recipients:), associated with the recipient in 1288 question. 1290 Prevention of Non-delivery notification 1291 Supported where SMTP and NOTARY are available. In other 1292 cases formally supported, as delivery notifications cannot 1293 be generated by RFC 822. In practice, errors will be 1294 returned as IP Messages, and so this service may appear not 1295 to be supported (see Non-delivery Notification). 1297 Primary and Copy Recipients Indication 1298 Supported 1300 Probe 1301 Supported at the gateway (i.e., the gateway services the 1302 probe). 1304 Probe Origin Authentication 1305 N/A (reception). 1307 Proof of Delivery 1308 Not supported. 1310 Proof of Submission 1311 N/A (local). 1313 Receipt Notification Request Indication 1314 Not supported. 1316 RFC 1327bis 1317 MIXER DRAFT Version 2.6 1319 Redirection Disallowed by Originator 1320 Redirection means MTS supported redirection, in the manner 1321 of X.400. This service does not exist in the RFC 822 world. 1322 RFC 822 redirection (e.g., aliasing) is regarded as an 1323 informal redirection mechanism, beyond the scope of this 1324 control. Messages will be sent to RFC 822, irrespective of 1325 whether this service is requested. In practice, control of 1326 this service is not supported. 1328 Registered Mail 1329 N/A (PDAU). 1331 Registered Mail to Addressee in Person 1332 N/A (PDAU). 1334 Reply Request Indication 1335 Supported as comment next to address. 1337 Replying IP Message Indication 1338 Supported. 1340 Report Origin Authentication 1341 N/A (reception). 1343 Request for Forwarding Address 1344 N/A (PDAU). 1346 Requested Delivery Method 1347 N/A (local). The service request is dealt with at 1348 submission time. Any such request is made available through 1349 the gateway by use of a comment associated with the 1350 recipient in question. 1352 Return of Content 1353 Supported where SMTP and NOTARY are used. In principle for 1354 other situations, this is N/A, as non-delivery notifications 1355 are not supported. In practice, most RFC 822 systems will 1356 return part or all of the content along with the IP Message 1357 indicating an error (see Non-delivery Notification). 1359 Sensitivity Indication 1360 Supported as new RFC 822 header (Sensitivity:). 1362 Special Delivery 1364 RFC 1327bis 1365 MIXER DRAFT Version 2.6 1367 N/A (PDAU). 1369 Stored Message Deletion 1370 N/A (MS). 1372 Stored Message Fetching 1373 N/A (MS). 1375 Stored Message Listing 1376 N/A (MS). 1378 Stored Message Summary 1379 N/A (MS). 1381 Subject Indication 1382 Supported. 1384 Undeliverable Mail with Return of Physical Message 1385 N/A (PDAU). 1387 Use of Distribution List 1388 In principle this applies only to X.400 supported 1389 distribution lists (see DL Expansion Prohibited). 1390 Theoretically, this service is N/A (prior). In practice, 1391 because of informal RFC 822 lists, this service can be 1392 regarded as supported. 1394 Auto-Submitted Indication 1395 Supported 1397 2.3.2. Reception by X.400 1399 2.3.2.1. Standard Mandatory Services 1401 The following standard IPM mandatory user facilities are 1402 required for reception of RFC 822 originated mail by an X.400 UA. 1404 Content Type Indication 1406 Delivery Time Stamp Indication 1408 IP Message Identification 1410 RFC 1327bis 1411 MIXER DRAFT Version 2.6 1413 Message Identification 1415 Non-delivery Notification 1417 Original Encoded Information Types Indication 1419 Submission Time Stamp Indication 1421 Typed Body 1423 2.3.2.2. Standard Optional Services 1425 The following standard IPM optional user facilities are required 1426 for reception of RFC 822 originated mail by an X.400 UA. 1428 Authorising User's Indication 1430 Blind Copy Recipient Indication 1432 Cross Referencing Indication 1434 Originator Indication 1436 Primary and Copy Recipients Indication 1438 Replying IP Message Indication 1440 Subject Indication 1442 2.3.2.3. New Services 1444 A new X.400 service "RFC 822 Header Field" is defined using the 1445 extension facilities. This allows for any RFC 822 header field 1446 to be represented. It may be present in RFC 822 originated 1447 messages which are received by an X.400 UA. 1449 RFC 1327bis 1450 MIXER DRAFT Version 2.6 1452 Chapter 3 Basic Mappings 1454 3.1. Notation 1456 The X.400 protocols are encoded in a structured manner according 1457 to ASN.1, whereas RFC 822 is text encoded. To define a detailed 1458 mapping, it is necessary to refer to detailed protocol elements 1459 in each format. A notation to achieve this is described in this 1460 section. 1462 3.1.1. RFC 822 1464 Structured text is defined according to the Extended Backus Naur 1465 Form (EBNF) defined in Section 2 of RFC 822 [16]. In the EBNF 1466 definitions used in this specification, the syntax rules given in 1467 Appendix D of RFC 822 are assumed. When these EBNF tokens are 1468 referred to outside an EBNF definition, they are identified by 1469 the string "822." appended to the beginning of the string (e.g., 1470 822.addr-spec). Additional syntax rules, to be used throughout 1471 this specification, are defined in this chapter. 1473 The EBNF is used in two ways. 1475 1. To describe components of RFC 822 messages (or of SMTP 1476 components). When these new EBNF tokens are referred to 1477 outside an EBNF definition, they are identified by the 1478 string "EBNF." appended to the beginning of the string 1479 (e.g., EBNF.importance). 1481 2. To describe the structure of IA5 or ASCII information not in 1482 an RFC 822 message. 1484 For all new EBNF, tokens will either be self delimiting, or be 1485 delimited by self delimiting tokens. Comments and LWSP are not 1486 used as delimiters, except for the following cases, where LWSP 1487 may be inserted according to RFC 822 rules. 1489 - Around the ":" in all headers 1491 - EBNF.labelled-integer 1493 RFC 1327bis 1494 MIXER DRAFT Version 2.6 1496 - EBNF.object-identifier 1498 - EBNF.encoded-info 1500 RFC 822 folding rules are applied to all headers. Comments are 1501 never used in these new headers. 1503 This notation is used in a modified form to refer to NOTARY 1504 EBNF [28]. For this EBNF, the keyword EBNF it replaces with DSN, 1505 for example DSN.final-recipient-field fields. 1507 3.1.2. ASN.1 1509 An element is referred to with the following syntax, defined in 1510 EBNF: 1512 element = service "." definition *( "." definition ) 1513 service = "IPMS" / "MTS" / "MTA" 1514 definition = identifier / context 1515 identifier = ALPHA *< ALPHA or DIGIT or "-" > 1516 context = "[" 1*DIGIT "]" 1518 The EBNF.service keys are shorthand for the following service 1519 specifications: 1521 IPMS IPMSInformationObjects defined in Annex E of X.420 / ISO 1522 10021-7. 1524 MTS MTSAbstractService defined in Section 9 of X.411 / ISO 1525 10021-4. 1527 MTA MTAAbstractService defined in Section 13 of X.411 / ISO 1528 10021-4. 1530 FTBP File Transfer Body Part, as defined in [27]. 1532 The first EBNF.identifier identifies a type or value key in the 1533 context of the defined service specification. Subsequent 1534 EBNF.identifiers identify a value label or type in the context of 1535 the first identifier (SET or SEQUENCE). EBNF.context indicates a 1536 context tag, and is used where there is no label or type to 1537 uniquely identify a component. The special EBNF.identifier 1538 keyword "value" is used to denote an element of a sequence. 1540 RFC 1327bis 1541 MIXER DRAFT Version 2.6 1543 For example, IPMS.Heading.subject defines the subject element of 1544 the IPMS heading. The same syntax is also used to refer to 1545 element values. For example, 1546 MTS.EncodedInformationTypes.[0].g3Fax refers to a value of 1547 MTS.EncodedInformationTypes.[0] . 1549 3.2. ASCII and IA5 1551 A gateway will interpret all IA5 as ASCII. Thus, mapping between 1552 these forms is conceptual. 1554 3.3. Standard Types 1556 There is a need to convert between ASCII text and some of the 1557 types defined in ASN.1 [14]. For each case, an EBNF syntax 1558 definition is given, for use in all of this specification, which 1559 leads to a mapping between ASN.1, and an EBNF construct. All 1560 EBNF syntax definitions of ASN.1 types are in lower case, whereas 1561 ASN.1 types are referred to with the first letter in upper case. 1562 Except as noted, all mappings are symmetrical. 1564 3.3.1. Boolean 1566 Boolean is encoded as: 1568 boolean = "TRUE" / "FALSE" 1570 3.3.2. NumericString 1572 NumericString is encoded as: 1574 numericstring = *(DIGIT / " ") 1576 3.3.3. PrintableString 1578 PrintableString is a restricted IA5String defined as: 1580 printablestring = *( ps-char ) 1581 ps-restricted-char = 1DIGIT / 1ALPHA / " " / "'" / "+" 1582 / "," / "-" / "." / "/" / ":" / "=" / "?" 1583 ps-delim = "(" / ")" 1584 ps-char = ps-delim / ps-restricted-char 1586 RFC 1327bis 1587 MIXER DRAFT Version 2.6 1589 This can be used to represent real printable strings in EBNF. 1591 3.3.4. T.61String 1593 In cases where T.61 strings are only used for conveying human 1594 interpreted information, the aim of a mapping is to render the 1595 characters appropriately in the remote character set, rather than 1596 to maximise reversibility. For these cases, there are two 1597 options, both of which are conformant to this specification: 1599 1. The mappings to IA5 defined in ITU-T Recommendation X.408 1600 (1988) may be used [13]. These will then be encoded in 1601 ASCII. This is the approach mandated in RFC 1327. 1603 2. This mapping may be used if the characters are not contained 1604 within ASCII repertoire, but are all in an IANA-registered 1605 character set. Use the encoding defined in RFC 1522 [9] to 1606 generate appropriate encoded-words. If this mapping is 1607 used, the character set ISO-8859-1 shall be used if all of 1608 the characters needed are available in this repertoire. In 1609 other cases, the character set TELETEX shall be used. The 1610 details of this character set is defined in the Appendix C 1611 of RFC1494bis. 1613 There is also a need to represent Teletex Strings in ASCII, 1614 for some aspects of OR Address. For these, the following 1615 encoding is used: 1617 teletex-string = *( ps-char / t61-encoded ) 1618 t61-encoded = "{" 1* t61-encoded-char "}" 1619 t61-encoded-char = 3DIGIT 1621 Characters in EBNF.ps-char are mapped simply. Other octets, 1622 including control characters, are mapped using a quoting 1623 mechanism similar to the printable string mechanism. Each octet 1624 is represented as 3 decimal digits. For example, the Yen 1625 character (hex A5) is represented as {165}. As the three 1626 character string, a, yen character, b, would be represented as 1627 either "a{165}b". 1629 The use of escape sequences follows that set down for ASN1. 1630 in ISO 8825-1, with the additional specifiction that the default 1631 G1 page is ISO Latin 1. The page settings may be changed by 1632 escape sequences. Changes of the settings hold within a pair of 1634 RFC 1327bis 1635 MIXER DRAFT Version 2.6 1637 curly brackets ({}), and the settings revert to the default after 1638 the right bracket (}) (i.e., they do not carry forward to 1639 subsequent T.61 encoding). 1641 There are a number of places where a string may have a Teletex 1642 and/or Printable String representation. The following EBNF is 1643 used to represent this. 1645 teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ] 1647 The natural mapping is restricted to EBNF.ps-char, in order to 1648 make the full BNF easier to parse. An example is: 1650 "yen*{165}" 1652 3.3.5. UTCTime 1654 Both UTCTime and the RFC 822 822.date-time syntax contain: Year, 1655 Month, Day of Month, hour, minute, second (optional), and 1656 Timezone (technically a time differential in UTCTime). 1657 822.date-time also contains an optional day of the week, but this 1658 is redundant. With the exception of Year, a symmetrical mapping 1659 can be made between these constructs. 1661 Note: 1662 In practice, a gateway will need to parse various illegal 1663 variants on 822.date-time. In cases where 822.date-time 1664 cannot be parsed, it is recommended that the derived UTCTime 1665 is set to the value at the time of translation. Such errors 1666 may be noted in an RFC 822 comment, to aid detection and 1667 correction. 1669 When mapping to X.400, the UTCTime format which specifies the 1670 timezone offset shall be used. 1672 When mapping to RFC 822, the 822.date-time format shall include a 1673 numeric timezone offset (e.g., -0500). 1675 When mapping time values, the timezone shall be preserved as 1676 specified. The date shall not be normalised to any other 1677 timezone. 1679 RFC 822, as modified by RFC 1123, requires use of a four digit 1681 RFC 1327bis 1682 MIXER DRAFT Version 2.6 1684 year. Note that the original RFC 822 uses a two digit date, 1685 which is no longer legal. UTCTime uses a two digit date. To map 1686 a year from RFC 822 to X.400, simply use the last two digits. 1687 To map a year from X.400 to RFC 822, assume that the two digit 1688 year refers to a year in the 10 year epoch 1980-2079. 1690 3.3.6. Integer 1692 A basic ASN.1 Integer will be mapped onto EBNF.numericstring. In 1693 many cases ASN.1 will enumerate Integer values or use ENUMERATED. 1694 An EBNF encoding labelled-integer is provided. When mapping from 1695 EBNF to ASN.1, only the integer value is mapped, and the 1696 associated text is discarded. When mapping from ASN.1 to EBNF, a 1697 text label may be added. It is recommended that this is done 1698 wherever possible and that clear text labels are chosen. 1700 A second encoding labelled-integer-2 is provided. This is 1701 used in DSNs, where the parsing rules will treat the text as a 1702 comment. This definition was not present in RFC 1327. 1704 labelled-integer ::= [ key-string ] "(" numericstring ")" 1706 labelled-integer-2 ::= [ numericstring ] "(" key-string ")" 1708 key-string = *key-char 1709 key-char = 1711 3.3.7. Object Identifier 1713 Object identifiers are represented in a form similar to that 1714 given in ASN.1. The order is the same as for ASN.1 (big-endian). 1715 The numbers are mandatory, and used when mapping from the ASCII 1716 to ASN.1. The key-strings are optional. It is recommended that 1717 as many strings as possible are generated when mapping from ASN.1 1718 to ASCII, to facilitate user recognition. 1720 object-identifier ::= oid-comp object-identifier 1721 | oid-comp 1723 oid-comp ::= [ key-string ] "(" numericstring ")" 1725 An example representation of an object identifier is: 1727 RFC 1327bis 1728 MIXER DRAFT Version 2.6 1730 joint-iso-ccitt(2) mhs (6) ipms (1) ep (11) ia5-text (0) 1732 or 1734 (2) (6) (1)(11)(0) 1736 Because of the use of brackets and the conflict with the RFC 822 1737 comment convention, MIXER is defines so that the EBNFobject- 1738 identifier definition is not used in structured fields. 1740 3.4. Encoding ASCII in Printable String 1742 Some information in RFC 822 is represented in ASCII, and needs to 1743 be mapped into X.400 elements encoded as printable string. For 1744 this reason, a mechanism to represent ASCII encoded as 1745 PrintableString is needed. 1747 A structured subset of EBNF.printablestring is now defined. 1748 This shall be used to encode ASCII in the PrintableString 1749 character set. 1751 ps-encoded = *( ps-restricted-char / ps-encoded-char ) 1752 ps-encoded-char = "(a)" ; (@) 1753 / "(p)" ; (%) 1754 / "(b)" ; (!) 1755 / "(q)" ; (") 1756 / "(u)" ; (_) 1757 / "(l)" ; "(" 1758 / "(r)" ; ")" 1759 / "(" 3DIGIT ")" 1761 The 822.3DIGIT in EBNF.ps-encoded-char shall have range 0-127, 1762 and is interpreted in decimal as the corresponding ASCII 1763 character. Special encodings are given for: at sign (@), percent 1764 (%), exclamation mark/bang (!), double quote ("), underscore (_), 1765 left bracket ((), and right bracket ()). These characters, with 1766 the exception of round brackets, are not included in 1767 PrintableString, but are common in RFC 822 addresses. The 1768 abbreviations will ease specification of RFC 822 addresses from 1769 an X.400 system. These special encodings shall be interpreted in 1770 a case insensitive manner, but always generated in lower case. 1772 A reversible mapping between PrintableString and ASCII can 1774 RFC 1327bis 1775 MIXER DRAFT Version 2.6 1777 now be defined. The reversibility means that some values of 1778 printable string (containing round braces) cannot be generated 1779 from ASCII. Therefore, this mapping shall only be used in cases 1780 where the printable strings have been derived from ASCII (and 1781 will therefore have a restricted domain). For example, in this 1782 specification, it is only applied to a Domain Defined Attribute 1783 which will have been generated by use of this specification and a 1784 value such as "(" would not be possible. 1786 To encode ASCII as PrintableString, the EBNF.ps-encoded 1787 syntax is used, with all EBNF.ps-restricted-char mapped directly. 1788 All other 822.CHAR are encoded as EBNF.ps-encoded-char. 1790 To encode PrintableString as ASCII, parse PrintableString as 1791 EBNF.ps-encoded, and then reverse the previous mapping. If the 1792 PrintableString cannot be parsed, then the mapping is being 1793 applied in to an inappropriate value, and an error shall be given 1794 to the procedure doing the mapping. In some cases, it may be 1795 preferable to pass the printable string through unaltered. 1797 Some examples are now given. Note the arrows which indicate 1798 asymmetrical mappings: 1800 PrintableString ASCII 1802 'a demo.' <-> 'a demo.' 1803 foo(a)bar <-> foo@bar 1804 (q)(u)(p)(q) <-> "_%" 1805 (a) <-> @ 1806 (A) -> @ 1807 (l)a(r) <-> (a) 1808 (126) <-> ~ 1809 ( -> ( 1810 (l) <-> ( 1812 3.5. RFC 1522 1814 RFC 1522 defines a mechanism for encoding other character set 1815 information into elements of RFC 822 Headers. A gateway may 1816 ignore this encoding and treat the elements as ASCII. 1818 A preferred approach is for the gateway to interpret the RFC 1819 1522 encoding. This will not always be straightforward, because: 1821 RFC 1327bis 1822 MIXER DRAFT Version 2.6 1824 1. RFC 1522 permits an openly extensible character set choice, 1825 which may be broader than T.61. 1827 2. It is not always possible to map all characters into the 1828 equivalent X.400 field. 1830 RFC 1522 is only applied to fields which are "for information 1831 only". A gateway which interprets header elements according to 1832 RFC 1522 may apply reasonable heuristics to minimise information 1833 loss. 1835 RFC 1327bis 1836 MIXER DRAFT Version 2.6 1838 Chapter 4 - Addressing and Message IDs 1840 Addressing is the most complex aspect of X.400 <-> RFC 822 1841 gateway and is therefore given a separate chapter. This chapter 1842 also discusses message identifiers, as they are closely linked to 1843 addresses. This chapter, as a side effect, also defines a 1844 textual representation of an X.400 OR Address. This 1845 specification has much similarity to the X.400(92) representation 1846 of addresses. This was because early versions of this 1847 specification were a major input to this work. This 1848 specification retains compatibility with earlier versions. The 1849 X.400 specification of address representation can be parsed but 1850 is not generated. 1852 Initially we consider an address in the (human) mail user 1853 sense of "what is typed at the mailsystem to reference a mail 1854 user". A basic RFC 822 address is defined by the EBNF 1855 EBNF.822-address: 1857 822-address = [ route ] addr-spec 1859 These definitions are taken from RFC 822. In SMTP (or another 1860 822-MTS protocol), the originator and each recipient are 1861 considered to be defined by such a construct. In an RFC 822 1862 header, the EBNF.822-address is encapsulated in the 822-address 1863 syntax rule, and there may also be associated comments. None of 1864 this extra information has any semantics, other than to the end 1865 user. 1867 The basic X.400 OR Address, used by the MTS for routing, is 1868 defined by MTS.ORAddress. In IPMS, the MTS.ORAddress is 1869 encapsulated within IPMS.ORDescriptor. 1871 The RFC 822 822.address is mapped with IPMS.ORDescriptor, 1872 and that RFC 822 EBNF.822-address is mapped with MTS.ORAddress. 1874 Section 4.1 defines a textual representation of an OR 1875 Address, which is used throughout the rest of this specification. 1876 This text representation is designed to represent an X.400 1877 address in the LHS (left hand side) or local part of an RFC 822 1878 address, and so this representation gives a mechanism to 1879 represent X.400 addresses within RFC 822 addresses. 1881 RFC 1327bis 1882 MIXER DRAFT Version 2.6 1884 Section 4.2 describes global equivalence mapping between 1885 parts of the X.400 and RFC 822 name spaces, and defines the 1886 concept of a MIXER Conformant Global Address Mapping (MCGAM). 1887 Gateways conforming to this specification shall support MCGAMs. 1889 Section 4.3 is the core part of this chapter, and defines 1890 the mapping mechanism. 1892 4.1. A textual representation of MTS.ORAddress 1894 MTS.ORAddress is structured as an ordered set of attributes 1895 (type/value pairs). It is clearly necessary to be able to encode 1896 this in ASCII for gatewaying purposes. All components shall be 1897 encoded, in order to guarantee return of error messages, and to 1898 optimise third party replies. 1900 4.1.1. Basic OR Address Representation 1902 An OR Address has a number of structured and unstructured 1903 attributes. For each unstructured attribute, a key and an 1904 encoding is specified. For structured attributes, the X.400 1905 attribute is mapped onto one or more attribute value pairs. For 1906 domain defined attributes, each element of the sequence will be 1907 mapped onto a triple (key and two values), with each value having 1908 the same encoding. The attributes are as follows, with 1984 1909 attributes given in the first part of the attribute key table. 1910 For each attribute, a reference is given, consisting of the 1911 relevant sections in X.402 / ISO 10021-2, and the extension 1912 identifier for 88 only attributes. The attribute key table 1913 follows: 1915 Attribute (Component) Key Enc Ref Id 1917 84/88 Attributes 1919 MTS.CountryName C P 18.3.3 1920 MTS.AdministrationDomainName ADMD P 18.3.1 1921 MTS.PrivateDomainName PRMD P 18.3.21 1922 MTS.NetworkAddress X121 N 18.3.7 1923 MTS.TerminalIdentifier T-ID P 18.3.23 1924 MTS.OrganizationName O P/T 18.3.9 1925 MTS.OrganizationalUnitNames.value OU P/T 18.3.10 1926 MTS.NumericUserIdentifier UA-ID N 18.3.8 1927 RFC 1327bis 1928 MIXER DRAFT Version 2.6 1930 MTS.PersonalName PN P/T 18.3.12 1931 MTS.PersonalName.surname S P/T 18.3.12 1932 MTS.PersonalName.given-name G P/T 18.3.12 1933 MTS.PersonalName.initials I P/T 18.3.12 1934 MTS.PersonalName 1935 .generation-qualifier GQ P/T 18.3.12 1936 MTS.DomainDefinedAttribute.value DD P/T 18.1 1938 88 Attributes 1940 MTS.CommonName CN P/T 18.3.2 1 1941 MTS.TeletexCommonName CN P/T 18.3.2 2 1942 MTS.TeletexOrganizationName O P/T 18.3.9 3 1943 MTS.TeletexPersonalName PN P/T 18.3.12 4 1944 MTS.TeletexPersonalName.surname S P/T 18.3.12 4 1945 MTS.TeletexPersonalName.given-name G P/T 18.3.12 4 1946 MTS.TeletexPersonalName.initials I P/T 18.3.12 4 1947 MTS.TeletexPersonalName 1948 .generation-qualifier GQ P/T 18.3.12 4 1949 MTS.TeletexOrganizationalUnitNames 1950 .value OU P/T 18.3.10 5 1951 MTS.TeletexDomainDefinedAttribute 1952 .value DD P/T 18.1 6 1953 MTS.PDSName PD-SERVICE P 18.3.11 7 1954 MTS.PhysicalDeliveryCountryName PD-C P 18.3.13 8 1955 MTS.PostalCode PD-CODE P 18.3.19 9 1956 MTS.PhysicalDeliveryOfficeName PD-OFFICE P/T 18.3.14 10 1957 MTS.PhysicalDeliveryOfficeNumber PD-OFFICE-NUM P/T 18.3.15 11 1958 MTS.ExtensionORAddressComponents PD-EXT-ADDRESS P/T 18.3.4 12 1959 MTS.PhysicalDeliveryPersonName PD-PN P/T 18.3.17 13 1960 MTS.PhysicalDeliveryOrganizationName PD-O P/T 18.3.16 14 1961 MTS.ExtensionPhysicalDelivery 1962 AddressComponents PD-EXT-DELIVERY P/T 18.3.5 15 1963 MTS.UnformattedPostalAddress PD-ADDRESS UPA 18.3.25 16 1964 MTS.StreetAddress PD-STREET P/T 18.3.22 17 1965 MTS.PostOfficeBoxAddress PD-BOX P/T 18.3.18 18 1966 MTS.PosteRestanteAddress PD-RESTANTE P/T 18.3.20 19 1967 MTS.UniquePostalName PD-UNIQUE P/T 18.3.26 20 1968 MTS.LocalPostalAttributes PD-LOCAL P/T 18.3.6 21 1969 RFC 1327bis 1970 MIXER DRAFT Version 2.6 1972 MTS.ExtendedNetworkAddress 1973 .e163-4-address.number NET-NUM N 18.3.7 22 1974 MTS.ExtendedNetworkAddress 1975 .e163-4-address.sub-address NET-SUB N 18.3.7 22 1976 MTS.ExtendedNetworkAddress 1977 .psap-address NET-PSAP X 18.3.7 22 1978 MTS.TerminalType T-TY I 18.3.24 23 1980 The following keys identify different EBNF encodings, which are 1981 associated with the ASCII representation of MTS.ORAddress. 1983 Key Encoding 1985 P printablestring 1986 N numericstring 1987 T teletex-string 1988 P/T teletex-and-or-ps 1989 UPA upa-string 1990 I labelled-integer 1991 X presentation-address 1993 The EBNF for presentation-address is taken from the specification 1994 RFC 1278 "A String Encoding of Presentation Address" [23]. 1996 In most cases, the EBNF encoding maps directly to the ASN.1 1997 encoding of the attribute. There are a few exceptions. In cases 1998 where an attribute can be encoded as either a PrintableString or 1999 NumericString (Country, ADMD, PRMD), either form is mapped into 2000 the EBNF. When generating ASN.1, the NumericString encoding 2001 shall be used if the string contains digits and only digits. 2003 There are a number of cases where the P/T (teletex-and-or-ps) 2004 representation is used. Where the key maps to a single 2005 attribute, this choice is reflected in the encoding of the 2006 attribute (attributes 10-21). For example: 2008 /CN=yen*{165}/ 2010 For most of the 1984 attributes and common name, there is a 2011 printablestring and a teletex variant. This pair of attributes 2012 is mapped onto the single component here. This will give a clean 2013 mapping for the common cases where only one form of the name is 2014 used. If there is teletex attribute or teletex component only, 2016 RFC 1327bis 2017 MIXER DRAFT Version 2.6 2019 and it contains only characters in the printable string character 2020 set, it shall be represented in the EBNF as if it had been 2021 encoded as printable string. A single printable string 2022 representation shall also be done when both forms are present and 2023 they have the same printable string representation. 2025 The Unformatted Postal Address has a slightly more complex 2026 mapping onto a variant of (teletex-and-or-ps), defined as: 2028 upa-string = [ printable-upa ] [ "*" teletex-string ] 2029 printable-upa = printablestring *( "|" printablestring ) 2031 The optional teletex part is straightforward. There is an 2032 (optional) sequence of printable strings which are mapped in 2033 order. For example: 2035 /PD-ADDRESS=The Dome|The Square|Richmond|England/ 2037 X.400 (1992) has introduced a string representation of OR 2038 Addresses (see F.401, Annex B). This has specified a number of 2039 string keywords for attributes. As earlier versions of this 2040 specification were an input to this work, many of the keywords 2041 are the same. To increase compatibility, the following 2042 alternative values shall be recognised when mapping from RFC 822 2043 to X.400. These shall not be generated when mapping from X.400 2044 to RFC 822. The following keyword alternative table and the 2045 subsequent paragraph lists alternative keywords. 2047 Keyword Alternative 2049 ADMD A 2050 PRMD P 2051 GQ Q 2052 X121 X.121 2053 UA-ID N-ID 2054 PD-OFFICE-NUM PD-OFFICE NUMBER 2055 PD-OFFICE-NUM PD-OFN 2056 PD-EXT-ADDRESS PD-EA 2057 PD-EXT-DELIVERY PD-ED 2058 PD-OFFICE PD-OF 2059 PD-STREET PD-S 2060 PD-UNIQUE PD-U 2061 PD-LOCAL PD-L 2063 RFC 1327bis 2064 MIXER DRAFT Version 2.6 2066 PD-RESTANTE PD-R 2067 PD-BOX PD-B 2068 PD-CODE PD-PC 2069 PD-SERVICE PD-SN 2070 DD DDA 2071 NET-NUM E.164 2072 NET-PSAP PSAP 2073 PD-ADDRESS PD-A 2075 When mapping from RFC 822 to X.400, the keywords defined in this 2076 paragraph shall be recognized. The ordered keywords: OU1, OU2, 2077 OU3, and OU4, shall be recognised. If these are present, no 2078 keyword OU shall be present. These will be treated as ordered 2079 values of OU. PD-A1, PD-A2, PD-A3, PD-A4, PD-A5, PD-A6 shall be 2080 treated as ordered lines. If present, these will be assembled 2081 with separating line feeds to form a single physical address. In 2082 this case PD-ADDRESS (or PD-A) shall not be present. Similarly, 2083 there are ordered keywords for domain defined attributes: DD1, 2084 DD2, DD3, DD4, 2086 If ISDN is present, it may be interpreted as an E.163/164 2087 address, using local heuristics to parse the string. X.400 2088 defines the key, but does not give an interpretation of the 2089 value. 2091 For T-TY (Terminal Type), the X.400 recommended values are 2092 preferred, but other values are allowed. These values are: tlx 2093 (3); ttx (4); g3fax (5); g4fax (6); ia5 (7); and vtx (8). 2095 4.1.2. Encoding of Personal Name 2097 Handling of Personal Name and Teletex Personal Name is a common 2098 requirement. Therefore MIXER defines an alternative to the 2099 EBNF.standard-type syntax, which utilises the "human" conventions 2100 for encoding these components. A syntax is defined, which is 2101 designed to provide a clean encoding for the common cases of OR 2102 Address specification where: 2104 1. There is no generational qualifier 2106 2. Initials, if present, contain only letters 2108 3. Given Name, if present, does not contain full stop ("."), 2109 and is at least two characters long. 2111 RFC 1327bis 2112 MIXER DRAFT Version 2.6 2114 4. Surname does not contain full stop in the first two 2115 characters. 2117 5 If Surname is the only component, it does not contain full 2118 stop. 2120 The following EBNF is defined: 2122 encoded-pn = [ given "." ] *( initial "." ) surname 2124 given = 2* 2126 initial = ALPHA 2128 surname = printablestring 2130 This is used to map from any string containing only printable 2131 string characters to an OR address personal name. To map from a 2132 string to OR Address components, parse the string according to 2133 the EBNF. The given name and surname are assigned directly. All 2134 EBNF.initial tokens are concatenated without intervening full 2135 stops to generate the initials component. 2137 For an OR address which follows the above restrictions, a 2138 string is derived in the natural manner. In this case, the 2139 mapping will be reversible. 2141 For example: 2143 GivenName = "Marshall" 2144 Surname = "Rose" 2146 Maps with "Marshall.Rose" 2148 Initials = "MT" 2149 Surname = "Rose" 2151 Maps with "M.T.Rose" 2153 GivenName = "Marshall" 2154 Initials = "MT" 2155 Surname = "Rose" 2157 Maps with "Marshall.M.T.Rose" 2159 RFC 1327bis 2160 MIXER DRAFT Version 2.6 2162 Note that X.400 suggests that Initials is used to encode all 2163 initials except the surname (X.402 section 18.3.12). Therefore, 2164 the defined encoding is "natural" when either GivenName or 2165 Initials, but not both, are present. The case where both are 2166 present can be encoded. 2168 4.1.3. Standard Encoding of MTS.ORAddress 2170 Given this structure, we can specify an EBNF representation of an 2171 OR Address. The output format of addresses is defined by 2172 EBNF.std-or-address. The more flexible input format is defined 2173 by EBNF.std-or-address-input. The input EBNF has been added 2174 subsequent to RFC 1327, to reflect the formal incorporation of a 2175 number of heuristics. The address element separator on input may 2176 be "/", ";", or a mixture of these. The output format is used in 2177 all examples. 2179 std-or-address = 1*( "/" attribute "=" value ) "/" 2180 attribute = standard-type 2181 / "RFC-822" 2182 / dd-key "." std-printablestring 2184 std-or-address-input = [ sep pair ] sep pair *( sep pair ) 2185 sep [ pair sep ] 2187 sep = "/" / ";" 2188 pair = input-attribute "=" value 2189 input-attribute = attribute 2190 / dd-key ":" std-printablestring 2192 RFC 1327bis 2193 MIXER DRAFT Version 2.6 2195 standard-type = key-string 2197 dd-key = key-string 2199 value = std-printablestring 2201 std-printablestring 2202 = *( std-char / std-pair ) 2204 std-char = <"{", "}", "*", and any ps-char 2205 except "/" and "=" > 2206 std-pair = "$" ps-char 2208 For address generation, the standard-type is any key defined in 2209 the key table in Section 4.1, except PN, and DD. For address 2210 parsing, other key values from Section 4.1 are also valid. The 2211 EBNF leads to a set of attribute/value pairs. The value is 2212 interpreted according to the EBNF encoding defined in the table. 2214 If the standard-type is PN, the value is interpreted 2215 according to EBNF.encoded-pn, and the components of 2216 MTS.PersonalName and/or MTS.TeletexPersonalName derived 2217 accordingly. 2219 If dd-key is the recognised Domain Defined string (DD) or 2220 one of the alternatives defined in Section 4.1, then the type and 2221 value are interpreted according to the syntax implied from the 2222 encoding, and aligned to either the teletex or printable string 2223 form. Key and value shall have the same encoding. 2225 If value is "RFC-822", then the (printable string) Domain 2226 Defined Type of "RFC-822" is assumed. This is an optimised 2227 encoding of the domain defined type defined by this 2228 specification. 2230 The matching of all keywords shall be done in a case- 2231 independent manner. 2233 EBNF.std-or-address uses the characters "/" and "=" as 2234 delimiters. Domain Defined Attributes and any value may contain 2235 these characters. A quoting mechanism, using the non-printable 2236 string "$" is used to allow these characters to be represented. 2238 RFC 1327bis 2239 MIXER DRAFT Version 2.6 2241 If an address of this syntax is parsed, and a country value 2242 is present, but no ADMD, the string shall be interpreted as if an 2243 ADMD value of single space had been specified. 2245 4.2. Global Address Mapping 2247 From a user perspective, the ideal mapping would be entirely 2248 symmetrical and global, to enable addresses to be referred to 2249 transparently in the remote system, with the choice of gateway 2250 being left to the Message Transfer Service. There are two 2251 fundamental reasons why this is not possible: 2253 1. The syntaxes are sufficiently different to make this 2254 impossible. 2256 2 There is insufficient administrative co-operation between 2257 the X.400 and RFC 822 name registration authorities for this 2258 to work. 2260 Another way to view this situation is to see that there is not a 2261 full global equivalence between X.400 and RFC 822 addressing. To 2262 meet user needs to the extent possible, this specification 2263 provides for equivalence where there is sufficient co-operation. 2264 To be useful, this equivalence shall be recognised and 2265 interpreted in the same way by all gateways. Therefore, an 2266 asymmetrical mapping is defined, which can be symmetrical where 2267 there is appropriate administrative co-operation. Section 4.3 2268 describes the asymetrical aspects. This section describes a 2269 mechanism to enable the administrative co-ordination for 2270 symmetrical mappings. 2272 In order to achieve a symmetrical mapping there is a need to 2273 define an administrative equivalence between parts of the OR 2274 Address and Domain namespaces. Previous version of this 2275 specification did this by definition of a global set of mappings. 2276 MIXER defines the concept of a MIXER Conformant Global Address 2277 Mapping (MCGAM). This acronym is defined so that it is very 2278 clear what is being referenced. 2280 The X.400 and Internet Mail address spaces are hierarchical. 2281 It is possible to define an equivalence between two points in the 2282 hierarchies, such that addresses below that point can be derived 2283 in an algorithmic manner. An MCGAM is a mapping from a point in 2284 one hierarchy to a point in the other hierarchy. An "MGGAM pair" 2286 RFC 1327bis 2287 MIXER DRAFT Version 2.6 2289 is a pair of symmetrical mappings between two points. To define 2290 an MCGAM, the following shall apply: 2292 1. The authority defining the MCGAM shall have responsibility 2293 for BOTH of the namespaces between which the MCGAM is 2294 defined. 2296 2. The authority defining the MCGAM is responsible to ensure 2297 that addresses allocated below the two equivalence points 2298 conform to the rules set out below. 2300 3. The authority defining the MCGAM is responsible to ensure 2301 that addresses which are generated according to the MCGAM 2302 are routed correctly. 2304 In general, MCGAMs will be independent. In some cases, a set of 2305 MCGAMs may be related (e.g., where one MCGAM defines a mapping 2306 for an organization and a second MCGAM defines an excpetion for a 2307 subtree within the organization). In this case, the related set 2308 of MCGAMs shall be treated as a single MCGAM for distribution 2309 purposes. 2311 The existence of an MCGAM does not imply routability and 2312 access for all users. 2314 The authority defining an MCGAM may simply use this mapping 2315 locally. This will often be the case in a "local scenario" 2316 gateway. Because of third party addressing, a MIXER gateway 2317 will work best with the maximum number of MCGAMs. Therefore, 2318 three mechanisms are defined to enable publication and exchange 2319 of MCGAMs: 2321 1. Distribution of text tables. This is described in Appendix 2322 F of this specification. 2324 2. Distribution by Domain Name Service. This is described in 2325 RFC 1664bis [3]. 2327 3. Distribution by X.500 Directory Service. This is defined 2328 in RFC 1838 [26]. 2330 The following sections define how the MCGAM namespace 2331 equivalence is modelled. The Internet Domain Namespace defines a 2332 simple hierarchy. For the purposes of this mapping, only parts 2334 RFC 1327bis 2335 MIXER DRAFT Version 2.6 2337 of the namespace where domains conform to the EBNF domain-syntax 2338 are allowed. 2340 domain-syntax = alphanum [ *alphanumhyphen alphanum ] 2341 alphanum = 2342 alphanumhyphen = 2344 Although RFC 822 allows for a more general syntax, this 2345 restricted syntax is used in MIXER as it is the one chosen by the 2346 various domain service administrations. In practice, it reflects 2347 all RFC 822 usage. 2349 The following OR Address attributes are considered as a 2350 hierarchy, and may be specified by the domain. They are (in 2351 order of the hierarchy defined by MIXER): 2353 Country, ADMD, PRMD, Organization, Organizational Units 2355 There may be up to four ordered Organizational Units. This 2356 hierarchy reflects most usage of X.400, although X.400 may be 2357 used in other ways. In particular, it covers the Mnemonic OR 2358 Address using a 1984 compatible encoding. This is seen as the 2359 dominant form of OR Address. MCGAMs may only be used when this 2360 hierarchy applies. 2362 An equivalence mapping is defined between two nodes in the 2363 respective hierarchies. For example: 2365 => "AC.UK" might be mapped with 2366 PRMD="UK.AC", ADMD="GOLD 400", C="GB" 2368 The mapping identifies that the management of these points in the 2369 respective hierarchies is the same (or co-operate very closely). 2370 The equivalence means that the namespaces below this equivalence 2371 point map 1:1, except where the mapping is overridden by further 2372 equivalence mappings lower down the hierarchy. This equivalence 2373 may be achieved in three ways: 2375 1. All of the nodes below this point are RFC 822, and the MIXER 2376 mapping defines the X.400 addresses for these nodes. 2378 2. All of the nodes below this point are X.400, and the MIXER 2379 mapping defines the RFC 822 addresses for these nodes. 2381 RFC 1327bis 2382 MIXER DRAFT Version 2.6 2384 3. There are X.400 and RFC 822 nodes below this point, and 2385 addressing is managed in a manner which ensures the 2386 equivalence. The rules to achieve this are defined by 2387 MIXER. 2389 Each of these ways gives a framework for MCGAM definition. 2391 When an MCGAM is defined, a systematic mapping for the 2392 inferior nodes in the two hierarchies follows. This is a 1:1 2393 mapping between the nodes in the subtrees. For example, given 2394 the MCGAM pair defined above: 2396 the domain "R-D.Salford.AC.UK" algorithmically maps with 2397 OU="R-D", O="Salford", PRMD="UK.AC", ADMD="GOLD 400", C="GB" 2399 Note that when an equivalence is defined, that this can be re- 2400 defined for lower points in the hierarchy. However, it is not 2401 possible to declare contained subtrees to be un-mappable. 2403 The equivalence mapping also provides a mechanism to deal 2404 with missing elements in the X.400 hierarchy (most commonly the 2405 PRMD, which is the only element that may be ommitted when 2406 conforming to recent versions of X.400). A domain may be 2407 associated with an omitted attribute in conjunction with several 2408 present ones. When performing the algorithmic insertion of 2409 components lower in the hierarchy, the omitted value shall be 2410 skipped. For example: 2412 If there is an MCGAM pair between domain HNE.EGM" and 2413 "O=HNE", "ADMD=ECQ", "C=TC", and omitted PRMD 2415 then 2417 "ZI.HNE.EGM" is algorithmically mapped with 2418 "OU=ZI", "O=HNE", "ADMD=ECQ", "C=TC" 2420 Attributes may have null values, and this is treated separately 2421 from omitted attributes (while it is not ideal 2422 to make this distinction, it is useful in practice). 2424 4.2.1. Directory and Nameserver Mappings 2426 When a set of MCGAMs are supported by X.500 or DNS, there is the 2428 RFC 1327bis 2429 MIXER DRAFT Version 2.6 2431 possibility that results will be indeterminate due to timeout. 2432 Lookup shall be repeated until a value is determined, in order to 2433 maintain consistent gateway operation. 2435 Where the mapping relates to an envelope address, the 2436 gateway shall non-deliver messages according to the associated 2437 MTA's normal timeout policy. Where the mapping relates to 2438 addresses in the message header, there shall be a timeout in the 2439 range of 1-4 hours or shorter if this is required to maintain 2440 quality of service constraints. If a mapping cannot be done in 2441 this time, address encapsulation shall be used. 2443 4.3. EBNF.822-address <-> MTS.ORAddress 2445 This section defines the basic address mapping. 2447 4.3.1. X.400 encoded in RFC 822 2449 This section defines how X.400 addresses are represented in RFC 2450 822 addresses. 2452 The std-or-address syntax is used to encode OR Address 2453 information in the 822.local-part of EBNF.822-address. Where 2454 there is an applicable equivalence mapping, further OR Address 2455 information is associated with the 822.domain component. This 2456 cannot be used in the general case, due to character set 2457 problems, and to the variants of X.400 OR Addresses which use 2458 different attribute types. The only way to encode the full 2459 PrintableString character set in a domain is by use of the 2460 822.domain-ref syntax (i.e. 822.atom). This is likely to cause 2461 problems on many systems. The effective character set of domains 2462 is in practice reduced from the RFC 822 set, by restrictions 2463 imposed by domain conventions and policy [10], and by the EBNF 2464 definition in SMTP. 2466 A generic 822.address consists of a 822.local-part and a 2467 sequence of 822.domains (e.g., <@domain1,@domain2:user@domain3>). 2468 All except the 822.domain associated with the 822.local-part 2469 (domain3 in this case) are considered to specify routing within 2470 the RFC 822 world, and will not be interpreted by the gateway 2471 (although they may have identified the gateway from within the 2472 RFC 822 world). 2474 The 822.domain associated with the 822.local-part 2476 RFC 1327bis 2477 MIXER DRAFT Version 2.6 2479 identifies the gateway from within the RFC 822 world. This final 2480 822.domain may be used to determine some number of OR Address 2481 attributes, where this does not conflict with the first role. 2482 RFC 822 routing to gateways will usually be set up to facilitate 2483 the 822.domain being used for both purposes. 2485 In the case that there is no applicable equivalence mapping, 2486 all of the X.400 address is encoded in the 822.local-part and the 2487 822.domain identifies the gateway to which the message is being 2488 sent. This technique may be used by the RFC 822 user for any 2489 X.400 address where the equivalence mapping is not known. 2491 In the case that there is an applicable MCGAM, the maximum 2492 number of attributes are encoded in the 822.domain. The 2493 remaining attributes are encoded on the LHS, using the 2494 EBNF.std-or-address syntax. For example: 2496 /I=J/S=Linnimouth/GQ=5/@Marketing.Widget.COM 2498 encodes the MTS.ORAddress consisting of: 2500 MTS.CountryName = "TC" 2501 MTS.AdministrationDomainName = "BTT" 2502 MTS.OrganizationName = "Widget" 2503 MTS.OrganizationalUnitNames.value = "Marketing" 2504 MTS.PersonalName.surname = "Linnimouth" 2505 MTS.PersonalName.initials = "J" 2506 MTS.PersonalName.generation-qualifier = "5" 2508 on the basis of an MCGAM pair between: 2510 Domain: Widget.COM 2511 OR Address: O="Widget", ADMD="BTT", C="TC" 2513 Given the OR address, the domain Widget.COM is determined from 2514 the equivalence mapping and the next component is determined 2515 algorithmically to give Marketing.Widget.COM. The remaining 2516 attributes are encoded on the LHS in 822.local-part. 2518 There is a further mechanism to simplify the encoding of 2519 common cases, where the only attributes to be encoded on the LHS 2520 are (non-Teletex) Personal Name attributes which comply with the 2521 restrictions of 4.1.2. To achieve this, the 822.local-part shall 2522 be encoded as EBNF.encoded-pn. In the previous example, if the 2524 RFC 1327bis 2525 MIXER DRAFT Version 2.6 2527 GenerationQualifier was not present in the OR Address, it would 2528 map with the RFC 822 address: J.Linnimouth@Marketing.Widget.COM. 2530 From the standpoint of the RFC 822 Message Transfer System, 2531 the domain specification is used to route the message in the 2532 standard manner. The standard domain mechanisms are used to 2533 select appropriate gateways for the corresponding OR Address 2534 space. It is the responsibility of the management that defines 2535 the equivalence mapping to define routing in the manner which 2536 will enable the message to be delivered. 2538 4.3.2. RFC 822 encoded in X.400 2540 The previous section showed a mapping from X.400 to RFC 822. In 2541 the case where the mapping was symmetrical and based on the 2542 equivalence mapping, this has also shown how RFC 822 is encoded 2543 in the X.400. This equivalence cannot be used for all RFC 822 2544 addresses. 2546 The general case is mapped by use of domain defined 2547 attributes. A (Printable String) Domain defined type "RFC-822" 2548 is defined. The associated attribute value is an ASCII string 2549 encoded according to Section 3.3.3 of this specification. The 2550 interpretation of the ASCII string follows RFC 822, and RFC 1123 2551 [10,16]. Domains shall always be fully qualified. 2553 Other OR Address attributes will be used to identify a 2554 context in which the OR Address will be interpreted. This might 2555 be a Management Domain, or some part of a Management Domain which 2556 identifies a gateway MTA. For example: 2558 C = "GB" 2559 ADMD = "GOLD 400" 2560 PRMD = "UK.AC" 2561 O = "UCL" 2562 OU = "CS" 2563 "RFC-822" = "Jimmy(a)WIDGET-LABS.CO.UK" 2565 OR 2567 C = "TC" 2568 ADMD = "Wizz.mail" 2569 PRMD = "42" 2570 "rfc-822" = "postel(a)venera.isi.edu" 2572 RFC 1327bis 2573 MIXER DRAFT Version 2.6 2575 Note in each case the PrintableString encoding of "@" as "(a)". 2576 In the second example, the "RFC-822" domain defined attribute is 2577 interpreted everywhere within the (Private) Management Domain. 2578 In the first example, further attributes are needed within the 2579 Management Domain to identify a gateway. Thus, this scheme can 2580 be used with varying levels of Management Domain co-operation. 2582 There is a limit of 128 characters in the length of value of 2583 a domain defined attribute, and an OR Address can have a maxmimum 2584 of four domain defined attributes. Where the printable string 2585 generated from the RFC 822 address exceeds 128 characters, 2586 additional domain defined attributes are used to enable up to 512 2587 characters to be encoded. These attributes shall be filled 2588 completely before the next one is started. The (Printable 2589 String) DDA keywords are: RFC822C1; RFC822C2; RFC822C3. Longer 2590 addresses cannot be encoded. 2592 MIXER defines a representation of RFC 822 addresses in 2593 printable string domain defined attributes. Teletex domain 2594 defined attributes with a key of RFC-822, RFC822C1; RFC822C2; 2595 RFC822C3 shall not be generated. This is for backwards 2596 compatibility reasons. 2598 Reception of these attributes in the manner defined below is 2599 mandatory. This is to allow the possibility for future versions 2600 of MIXER to allow generation of teletex domain defined 2601 attributes. Where the values of all of these teletex domain 2602 defined attributes are printable string characters, they shall be 2603 interpreted in the same way as the printable string domain 2604 defined attributes. If this is not the case, the printable 2605 string encoding translation shall be omitted. If both teletex 2606 and printable string attributes are present, this is valid if and 2607 only if they represent exactly the same RFC 822 address. 2609 4.3.3. Component Ordering 2611 In most cases, ordering of OR Address components is not 2612 significant for the mappings specified. However, Organizational 2613 Units (printable string and teletex forms) and Domain Defined 2614 Attributes are specified as SEQUENCE in MTS.ORAddress, and so 2615 their order may be significant. This specification needs to take 2616 account of this: 2618 1. To allow consistent mapping into the domain hierarchy 2620 RFC 1327bis 2621 MIXER DRAFT Version 2.6 2623 2. To ensure preservation of order over multiple mappings. 2625 There are three places where an order is specified: 2627 1. The text encoding (std-or-address) of MTS.ORAddress as used 2628 in the local-part of an RFC 822 address. An order is needed 2629 for those components which may have multiple values 2630 (Organizational Unit, and Domain Defined Attributes). When 2631 generating an 822.std-or-address, components of a given type 2632 shall be in hierarchical order with the most significant 2633 component on the RHS (right hand side or domain part). If 2634 there is an Organization Attribute, it shall be to the right 2635 of any Organizational Unit attributes. These requirements 2636 are for the following reasons: 2638 - Alignment to the hierarchy of other components in RFC 2639 822 addresses (thus, Organizational Units will appear 2640 in the same order, whether encoded on the RHS or LHS). 2642 - Backwards compatibility with RFC 987/1026. 2644 - To ensure that gateways generate consistent addresses. 2645 This is both to help end users, and to generate 2646 identical message ids. 2648 Further, it is recommended that all other attributes are 2649 generated according to this ordering, so that all attributes 2650 so encoded follow a consistent hierarchy. When generating 2651 822.msg-id, this order shall be followed. 2653 2. For the Organizational Units (OU) in MTS.ORAddress, the 2654 first OU in the SEQUENCE is the most significant, as 2655 specified in X.400. 2657 3. For the Domain Defined Attributes in MTS.ORAddress, the 2658 First Domain Defined Attribute in the SEQUENCE is the most 2659 significant. 2661 Note that although this ordering is mandatory for this 2662 mapping, MIXER does not give additional implications on the 2663 ordering significance within X.400. 2665 RFC 1327bis 2666 MIXER DRAFT Version 2.6 2668 4.3.4. RFC 822 -> X.400 Basic Address Mapping 2670 There are two basic cases: 2672 1. X.400 addresses encoded in RFC 822. This will also include 2673 RFC 822 addresses which are given reversible encodings. 2675 2. "Genuine" RFC 822 addresses. 2677 The mapping shall proceed as follows, by first assuming case 1). 2679 STAGE I. 2681 1. If the 822-address is not of the form: 2683 local-part "@" domain 2685 take the domain which will be routed on and apply step 2 of 2686 stage 1 to derive (a possibly null) set of attributes. Then 2687 go to stage II. 2689 The gateway may reduce a source route address to this form 2690 by removal of all but the last domain. In terms of the 2691 design intentions of RFC 822, this would be an incorrect 2692 action. (Note that an address of the form local%part@domain 2693 is not a source route). However, in most cases, it will 2694 provide a better service to the end user, and is in line 2695 with the Internet Host Requirements. This is a reflection 2696 on the common inappropriate use of source routing in RFC 822 2697 based systems, despite the discussion in the Host 2698 Requirements [10]. Either approach, or the intermediate 2699 approach of stripping only domain references which reference 2700 the local gateway are conformant to this specification. 2702 2. If the 822.local-part uses the 822.quoted-string encoding, 2703 remove this quoting. If the resulting unquoted 2704 822.local-part has leading space, trailing space, or two 2705 adjacent spaces go to stage II. 2707 3. If the unquoted 822.local-part contains any characters not 2708 in PrintableString, "{", "}", "*", and "$", go to stage II. 2710 4. Parse the (unquoted) 822.local-part according to the EBNF 2711 EBNF.std-or-address-input. Checking of upper bounds shall 2713 RFC 1327bis 2714 MIXER DRAFT Version 2.6 2716 not be done at this point. If this parse fails, parse the 2717 local-part according to the EBNF EBNF.encoded-pn. If this 2718 parse fails, go to stage II. The result is a set of 2719 type/value pairs. 2721 5. Associate the EBNF.attribute-value syntax (determined from 2722 the identified type) with each value, and check that it 2723 conforms. If not, go to stage II. 2725 6. If the set of attributes forms a valid X.400 address, 2726 according to X.402, then go to step 9. All forms of X.400 2727 address are allowed at this stage. Steps 7-8 default 2728 attributes for certain types of OR Address. 2730 7. If the set of attributes cannot form a mnemonic form of 2731 X.400 address after addition of attributes which may be 2732 derived from the EBNF.domain (C, ADMD, PRMD, O, OU), go to 2733 stage II. 2735 8. Attempt to parse EBNF.domain as: 2737 *( domain-syntax "." ) known-domain 2739 Where EBNF.known-domain is the longest possible match in the 2740 set of MCGAMs being used by the gateway (described in 2741 Section 4.2). EBNF.domain-syntax is the restricted domain 2742 syntax defined in Section 4.2, to which all of the domain 2743 components shall conform for the parse to be successful. If 2744 this fails, go to stage II. 2746 For each component, systematically allocate the attribute 2747 implied by each EBNF.domain-syntax component in the order: 2748 C, ADMD, PRMD, O, OU. Note that if the MCGAM used 2749 identifies an "omitted attribute", then this attribute shall 2750 be omitted in the systematic allocation. If this new 2751 component exceed an upper bound (ADMD: 16; PRMD: 16; O: 64; 2752 OU: 32) or it would lead to more than four OUs, then go to 2753 stage II with the attributes derived. 2755 The attributes derived in this step (referred to as RHS 2756 attributes) 2757 are merged with the ones derived from the LHS (step 6). 2758 In some cases, not all of the RHF attributes are used. LHS 2759 attributes are all used. C will not be in the LHS 2761 RFC 1327bis 2762 MIXER DRAFT Version 2.6 2764 attributes. If ADMD is in the LHS attributes, only C is 2765 taken from the RHS attributes. If PRMD is in the LHS 2766 attributes, C and ADMD are taken from the RHS attributes. 2767 If O is on the LHS, C, ADMD and PRMD (if present) are taken 2768 from the RHS attributes. In other cases all RHS attributes 2769 are taken. 2771 9. Ensure that the set of attributes conforms both to the 2772 MTS.ORAddress specification and to the restrictions on this 2773 set given in X.400, and that no upper bounds are exceeded 2774 for any attribute. If not go to stage II. 2776 10. Build the OR Address from this information. 2778 STAGE II. 2780 This will only be reached if the RFC 822 EBNF.822-address is not 2781 a valid X.400 encoding. This implies that the address refers to 2782 a recipient on an RFC 822 system or that the encoding of the 2783 address is invalid. Such addresses shall be encoded in an X.400 2784 OR Address using a domain defined attribute. 2786 1. Convert the EBNF.822-address to PrintableString, as 2787 specified in Chapter 3. 2789 2. Generate the "RFC-822" domain defined attribute from this 2790 string. 2792 3. Build the rest of the OR Address in the manner described 2793 below. 2795 It is not always possible to encode the domain defined attribute 2796 due to length restrictions. If the limit is exceeded by a 2797 mapping at the MTS level, then the gateway shall reject the 2798 message in question. If this occurs at the IPMS level, then the 2799 action will depend on the policy being taken for IPMS encoding, 2800 which is discussed in Section 5.1.3. 2802 Use Stage I, step 8, to generate a set of attributes to build the 2803 remainder of the address. The administrative equivalence of the 2804 mappings will ensure correct routing through X.400 to a gateway 2805 back to RFC 822. 2807 RFC 1327bis 2808 MIXER DRAFT Version 2.6 2810 If Stage I, step 8 does not generate a set of attributes or 2811 the address generated is unroutable, the remained of the OR 2812 address is generated as follows. The remainder of the OR address 2813 effectively identifies a source route to a gateway from the X.400 2814 side. There are three cases, which are handled differently: 2816 SMTP Return Address 2817 This shall be set up so that errors are returned through the 2818 same gateway. Therefore, the OR Address of the local 2819 gateway shall be used. 2821 IPMS Addresses 2822 These are optimised for replying. In general, the message 2823 may end up anywhere within the X.400 world, and so this 2824 optimisation identifies a gateway appropriate for the RFC 2825 822 address being converted. The 822.domain to which the 2826 address would be routed is used to select an appropriate 2827 gateway. 2829 In this case, it may be useful to use a non-local gateway, 2830 which will optimise the reply address. This information 2831 may be looked up in gateway tables in a manner equivalent to 2832 the MCGAM lookup. Because of the similarity of lookup, the 2833 three MCGAM lookup mechansims (table, X.500, DNS) are also 2834 available to look up this information. This information is 2835 local, and a gateway may insert any appropriate (gateway) 2836 OR Address. The longest possible match on the 822.domain 2837 defines which gateway to use. This mechanism is used for 2838 any part of the X.400 namespace for which it is desirable to 2839 identify a preferred X.400 gateway in order to optimise 2840 routing. 2842 If no mapping is found for the 822.domain, a default value 2843 (typically that of the local gateway) is used. It is never 2844 appropriate to ignore the locally used MCGAMs. 2846 SMTP Recipient 2847 As the RFC 822 and X.400 worlds are in principle fully 2848 connected, there is no technical reason for this situation 2849 to occur. In practice, this is not the case. In some cases, 2850 routing may be configured to use X.400 to connect an RFC 822 2851 island to the Internet. The information that this part of 2852 the domain space is to be routed by X.400 rather than 2853 remaining within the RFC 822 world shall be configured 2855 RFC 1327bis 2856 MIXER DRAFT Version 2.6 2858 privately into the gateway in question. X.400 routing shall 2859 not make use of the presence of the RFC-822 DDA to perform 2860 X.400 routing. The OR address shall then be generated in 2861 the same manner as for an IPMS address, using the locally 2862 available MCGAMs. It is to support this case that the 2863 definition of the global domain to gateway mapping is 2864 important, as the use of this mapping will lead to a remote 2865 X.400 address, which can be routed by X.400 routing 2866 procedures. The information in this mapping shall not be 2867 used as a basis for deciding to convert a message from RFC 2868 822 to X.400. 2870 Three examples are given, neither of which has applicable MCGAMs. 2872 Example 1: (Address not in "localpart" "@" "domainpart") 2874 @relay.co.uk:userb@host2 2875 maps to 2876 c=gb; a= ; p=uk.ac; o=mr; dd.rfc-822=(a)relay.co.uk:userb(a)host2; 2878 Example 2: (Address with non printablestring characters) 2880 Tom_Harris@cs.widget.com 2881 maps to 2882 c=us; a=MCI; P=relay; dd.rfc-822=Tom(u)Harris(a)cs.widget.com; 2884 Example 3: (Address with an entry for alter.net into the OR Address 2885 of Preferred Gateway table, pointing to c=gb; A=BTglobal; P=relay) 2887 postmaster@UK.alter.net 2888 maps to 2889 c=gb; a=BTglobal; P=relay; dd.rfc-822=postmaster(a)UK.alter.net; 2891 4.3.4.1. Heuristic for mapping RFC 822 to X.400 2893 The following heuristic, which relates to ordering of address 2894 components, may be used when mapping from RFC 822 to X.400. The 2895 ordering of attributes may be inverted or mixed, and so the 2896 following heuristics may be applied: 2898 If there is an Organization attribute to the left of any Org 2899 Unit attribute, assume that the hierarchy is inverted. This 2901 RFC 1327bis 2902 MIXER DRAFT Version 2.6 2904 is to facilitate the situation where a user has input the 2905 attributes in reverse hierarchical order. To do this the 2906 gateway shall first map according to the order defined in 2907 4.3.3. If this mapping generates an address which X.400 2908 address verification shows to be invalid, this heuristic may 2909 be applied as an alternative to immediate rejection of the 2910 address. 2912 4.3.5. X.400 -> RFC 822 Basic Address Mapping 2914 There are two basic cases: 2916 1. RFC 822 addresses encoded in X.400. 2918 2. "Genuine" X.400 addresses. This may include symmetrically 2919 encoded RFC 822 addresses. 2921 When an MTS Recipient OR Address is interpreted, gatewaying will 2922 be selected if there is a single "RFC-822" domain defined 2923 attribute present. In this case, use mapping A and in other 2924 cases, use mapping B. 2926 RFC 1327 specified that this shall only be done when the 2927 gateway identfied is local or otherwise known, and identified the 2928 approach specified here as a pragmatic option. Experience has 2929 shown that this is effective in practice, despite theoretical 2930 problems. 2932 If a gateway wishes to make a mapping in a manner similar to 2933 RFC 1327, but does not wish for this global interpretation (e.g., 2934 to support an RFC 822 local system, which does not use global 2935 addressing), then it may choose a private domain defined 2936 attribute, different to "RFC-822". An RFC 1327 gateway might be 2937 configurable to operate in this manner. 2939 Mapping A 2941 1. Map the domain defined attribute value to ASCII, as defined 2942 in Chapter 3, and drop all other attributes. 2944 Mapping B. 2946 This is used for X.400 addresses which do not use the explicit 2948 RFC 1327bis 2949 MIXER DRAFT Version 2.6 2951 RFC 822 encoding. 2953 1. For all string encoded attributes, remove any leading or 2954 trailing spaces, and replace adjacent spaces with a single 2955 space. 2957 The only attribute which is permitted to have zero length is 2958 the ADMD. This shall be mapped onto a single space. 2960 These transformations are for lookup only. If an 2961 EBNF.std-or-address mapping is used as in 4), then the 2962 original values shall be used. 2964 2. The numeric country codes may be mapped to the two letter 2965 values (as defined in ISO 3166). Global mappings are 2966 usually only defined in terms of the ISO 3166 codes. 2968 3. Noting the hierarchy specified in 4.3.1 and including 2969 omitted attributes, determine the maximum set of attributes 2970 which have an associated domain specification in the local 2971 set of MCGAMs. If no match is found, allocate the domain as 2972 described below, and go to step 5. The default domain to be 2973 used is the specification of the local gateway. A gateway 2974 may use other domains according to private mapping tables or 2975 heuristics. For example, it may choose a domain which it 2976 knows to provide a free gateway service to the mapped 2977 address. 2979 In cases where the address refers to an X.400 UA, it is 2980 important that the generated domain will correctly route to 2981 a gateway. In general, this is achieved by carefully co- 2982 ordinating RFC 822 routing with the definition of the 2983 MCGAMs, as there is no easy way for the gateway to make this 2984 check. One rule that shall be used is that domains with 2985 only one component will not route to a gateway. If the 2986 generated domain does not route correctly, the address is 2987 treated as if no match is found. 2989 The gateway may also make use of a mapping equivalent to the 2990 MCGAM mapping to determine the domain to use. This mapping 2991 is done from the OR Address hierarchy. This is not a 2992 global mapping, but is a routing style mapping from the OR 2993 Address space, to enable a best choice domain to be 2994 inserted. This mapping is supported by the three MCGAM 2996 RFC 1327bis 2997 MIXER DRAFT Version 2.6 2999 lookup mechanisms. 3001 4. The mapping identified in 3) gives a domain, and an OR 3002 address prefix. Follow the hierarchy: C, ADMD, PRMD, O, OU. 3003 For each successive component below the OR address prefix, 3004 which conforms to the syntax EBNF.domain-syntax (as defined 3005 in 4.3.1), allocate the next subdomain. At least one 3006 attribute of the X.400 address shall not be mapped onto 3007 subdomain, as 822.local-part cannot be null. If there are 3008 omitted attributes in the OR address prefix, these will have 3009 correctly and uniquely mapped to a domain component. Where 3010 there is an attribute omitted below the prefix, all 3011 attributes remaining in the OR address shall be encoded on 3012 the LHS. This is to ensure a reversible mapping. For 3013 example, if there is an address /S=XX/O=YY/ADMD=A/C=NN/ and 3014 a mapping for /ADMD=A/C=NN/ is used, then /S=XX/O=YY/ is 3015 encoded on the LHS. 3017 5. If the address contains any attribute not used in mnemonic 3018 form, then all of the attributes in the address shall be 3019 encoded on the LHS in EBNF.std-or-address syntax, as 3020 described below. 3022 For addresses of mnemonic form, if the remaining components 3023 are personal-name components, conforming to the restrictions 3024 of 4.2.1, then EBNF.encoded-pn is derived to form 3025 822.local-part. In other cases the remaining components are 3026 simply encoded as 822.local-part using the 3027 EBNF.std-or-address syntax. If necessary, the 3028 822.quoted-string encoding is used. The following are 3029 examples of legal quoting: "a b".c@x; "a b.c"@x. Either 3030 form may be generated. Generation of the latter style is 3031 strongly recommended. 3033 Four examples are given. 3035 Example 1: (Address with missing X.400 elements and no specific 3036 mapping rule for "o=sales; a=Master400; C=it", where a mapping 3037 exists for a=master400; C-it;) 3039 S=Support; O=sales; A=Master400; C=it; 3040 maps to 3041 /S=Support/o=sales/@Master400.it 3043 RFC 1327bis 3044 MIXER DRAFT Version 2.6 3046 Example 2: (Address with illegal characters in RFC822 generated 3047 domain if default hierarchical translation (specific mapping rule 3048 is existing for c=fr; a=atlas; p=autoroutes) is used) 3050 S=renseignements; O=Region Parisienne; P=autoroutes; A=atlas; C=fr; 3051 maps to 3052 "/S=renseignements/o=Region Parisienne/"@autoroutes.fr 3054 Example 3: (Address containing elements not mappable into RFC822 3055 local part) 3057 S=Rossi; DD.cap=20100; DD.ph1=Via Larga 11; 3058 DDA.city=Milano; A=PtPostel; C=it; 3060 maps to 3062 "/DD.cap=20100/DD.ph1=Via Larga 11/DD.city=Milano/S=Rossi/"@ptpostel.it 3064 Example 4: (Address with an entry for A=ATT; C=us; into the domain 3065 of Preferred Gateway table, pointing to attmail.com) 3067 G=Andy; S=Wharol; O=MMNY; A=ATT; C=us; 3069 maps to 3071 /G=Andy/S=Wharol/O=MMNY 3073 4.4. Repeated Mappings 3075 There are two types of repeated mapping: 3077 1. A recursive mapping, where the repeat is within one gateway 3079 2 A source route, where the repetition occurs across multiple 3080 gateways 3082 4.4.1. Recursive Mappings 3084 It is possible to supply an address which is recursive at a 3085 single gateway. For example: 3087 RFC 1327bis 3088 MIXER DRAFT Version 2.6 3090 C = "XX" 3091 ADMD = "YY" 3092 O = "ZZ" 3093 "RFC-822" = "Smith(a)ZZ.YY.XX" 3095 This is mapped first to an RFC 822 address, and then back to the 3096 X.400 address: 3098 C = "XX" 3099 ADMD = "YY" 3100 O = "ZZ" 3101 Surname = "Smith" 3103 In some situations this type of recursion may be frequent. It is 3104 important where this occurs, that no unnecessary protocol 3105 conversion occurs. This will minimise loss of service. 3107 4.4.2. Source Routes 3109 The mappings defined are symmetrical and reversible across a 3110 single gateway. The symmetry is particularly useful in cases of 3111 (mail exploder type) distribution list expansion. For example, 3112 an X.400 user sends to a list on an RFC 822 system which he 3113 belongs to. The received message will have the originator and 3114 any 3rd party X.400 OR Addresses in correct format (rather than 3115 doubly encoded). In cases (X.400 or RFC 822) where there is 3116 common agreement on gateway identification, then this will apply 3117 to multiple gateways. 3119 When a message traverses multiple gateways, the mapping will 3120 always be reversible, in that a reply can be generated which will 3121 correctly reverse the path. In many cases, the mapping will also 3122 be symmetrical, which will appear clean to the end user. For 3123 example, if countries "AB" and "XY" have RFC 822 networks, but 3124 are interconnected by X.400, the following may happen: The 3125 originator specifies: 3127 Joe.Soap@Widget.PTT.XY 3129 This is routed to a gateway, which generates: 3131 RFC 1327bis 3132 MIXER DRAFT Version 2.6 3134 C = "XY" 3135 ADMD = "PTT" 3136 PRMD = "Griddle MHS Providers" 3137 Organization = "Widget Corporation" 3138 Surname = "Soap" 3139 Given Name = "Joe" 3141 This is then routed to another gateway where the mapping is 3142 reversed to give: 3144 Joe.Soap@Widget.PTT.XY 3146 Here, use of the gateway is transparent. 3148 Mappings will only be symmetrical where mapping equivalences 3149 are defined. In other cases, the reversibility is more important, 3150 due to the (far too frequent) cases where RFC 822 and X.400 3151 services are partitioned. 3153 The syntax may be used to source route. THIS IS STRONGLY 3154 DISCOURAGED. For example: 3156 X.400 -> RFC 822 -> X.400 3158 C = "UK" 3159 ADMD = "Gold 400" 3160 PRMD = "UK.AC" 3161 "RFC-822" = "/PN=Duval/DD.Title=Manager/(a)Inria.ATLAS.FR" 3163 This will be sent to an arbitrary UK Academic Community gateway 3164 by X.400. Then it will be sent by JNT Mail to another gateway 3165 determined by the domain Inria.ATLAS.FR (FR.ATLAS.Inria). This 3166 will then derive the X.400 OR Address: 3168 C = "FR" 3169 ADMD = "ATLAS" 3170 PRMD = "Inria" 3171 PN.S = "Duval" 3172 "Title" = "Manager" 3174 RFC 1327bis 3175 MIXER DRAFT Version 2.6 3177 Similarly: 3178 RFC 822 -> X.400 -> RFC 822 3180 "/RFC-822=jj(a)seismo.css.gov/PRMD=AC/ADMD=BT/C=GB/"@monet.berkeley.edu 3182 This will be sent to monet.berkeley.edu by RFC 822, then to the 3183 AC PRMD by X.400, and then to jj@seismo.css.gov by RFC 822. 3185 4.5. Directory Names 3187 Directory Names are an optional part of OR Name, along with OR 3188 Address. The RFC 822 addresses are mapped onto the OR Address 3189 component. As there is no functional mapping for the Directory 3190 Name on the RFC 822 side, a textual mapping is used. There is no 3191 requirement for reversibility in terms of the goals of this 3192 specification. There may be some loss of functionality in terms 3193 of third party recipients where only a directory name is given, 3194 but this seems preferable to the significant extra complexity of 3195 adding a full mapping for Directory Names. 3197 The Directory Name shall be represented within an RFC 822 3198 comment using the comaptible formats of RFC 1484 or RFC 1485. It 3199 is recommended that the directory string format of RFC 1485 is 3200 used [24]. The User Friendly Name form of RFC 1484 may be used 3201 [25]. 3203 4.6. MTS Mappings 3205 The basic mappings at the MTS level are: 3207 1) SMTP originator -> 3208 MTS.PerMessageSubmissionFields.originator-name 3209 MTS.OtherMessageDeliveryFields.originator-name -> 3210 SMTP originator 3212 2) SMTP recipient -> 3213 MTS.PerRecipientMessageSubmissionFields 3214 MTS.OtherMessageDeliveryFields.this-recipient-name -> 3215 SMTP recipient 3217 SMTP recipients and return addresses are encoded as 3218 EBNF.822-address. 3220 The MTS Originator is always encoded as MTS.OriginatorName, 3222 RFC 1327bis 3223 MIXER DRAFT Version 2.6 3225 which maps onto MTS.ORAddressAndOptionalDirectoryName, which in 3226 turn maps onto MTS.ORName. 3228 4.6.1. RFC 822 -> X.400 MTS Mappings 3230 From the SMTP Originator, use the basic ORAddress mapping, to 3231 generate MTS.PerMessageSubmissionFields.originator-name 3232 (MTS.ORName), without a DirectoryName. 3234 For recipients, the following settings are made for each 3235 component of MTS.PerRecipientMessageSubmissionFields. 3237 recipient-name 3238 This is derived from the SMTP recipient by the basic 3239 ORAddress mapping. 3241 originator-report-request 3242 This may either be set to "delivery-report", or set 3243 according to SMTP extensions as set out in Appendix A. 3245 explicit-conversion 3246 This optional component is omitted, as this service is not 3247 needed 3249 extensions 3250 The default value (no extensions) is used 3252 4.6.2. X.400 -> RFC 822 MTS Mappings 3254 The basic functionality is to generate the SMTP originator and 3255 recipients. There is information present on the X.400 side, 3256 which cannot be mapped into analogous SMTP services. For this 3257 reason, new RFC 822 fields are added for the MTS Originator and 3258 Recipients. The information discarded at the SMTP level will be 3259 present in these fields. In some cases a (positive) delivery 3260 report will be generated. 3262 4.6.2.1. SMTP Mappings 3264 Use the basic ORAddress mapping, to generate the SMTP originator 3265 (return address) from 3266 MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName). If 3267 MTS.ORName.directory-name is present, it is discarded. (Note 3268 that it will be presented to the user, as described in 4.6.2.2). 3270 RFC 1327bis 3271 MIXER DRAFT Version 2.6 3273 The mapping uses the MTA level information, and maps each 3274 value of MTA.PerRecipientMessageTransferFields.recipient-name, 3275 where the responsibility bit is set, onto an SMTP recipient. 3277 Note:The SMTP recipient is conceptually generated from 3278 MTS.OtherMessageDeliveryFields.this-recipient-name. This is 3279 done by taking 3280 MTS.OtherMessageDeliveryFields.this-recipient-name, and 3281 generating an SMTP recipient according to the basic 3282 ORAddress mapping, discarding MTS.ORName.directory-name if 3283 present. However, if this model was followed exactly, there 3284 would be no possibility to have multiple SMTP recipients on 3285 a single message. This is unacceptable, and so layering is 3286 violated. 3288 4.6.2.2. Generation of RFC 822 Headers 3290 Not all per-recipient information can be passed at the SMTP 3291 level. For this reason, two new RFC 822 headers are created, in 3292 order to carry this information to the RFC 822 recipient. These 3293 fields are "X400-Originator:" and "X400-Recipients:". 3295 The "X400-Originator:" field is set to the same value as the 3296 SMTP originator. In addition, if 3297 MTS.OtherMessageDeliveryFields.originator-name (MTS.ORName) 3298 contains MTS.ORName.directory-name then this Directory Name shall 3299 be represented in an 822.comment. 3301 Recipient names, taken from each value of 3302 MTS.OtherMessageDeliveryFields.this-recipient-name and 3303 MTS.OtherMessageDeliveryFields.other-recipient-names are made 3304 available to the RFC 822 user by use of the "X400-Recipients:" 3305 field. By taking the recipients at the MTS level, disclosure of 3306 recipients will be dealt with correctly. However, this conflicts 3307 with a desire to optimise mail transfer. There is no problem 3308 when disclosure of recipients is allowed. Similarly, there is no 3309 problem if there is only one RFC 822 recipient, as the 3310 "X400-Recipients" field is only given one address. 3312 There is a problem if there are multiple RFC 822 recipients, 3313 and disclosure of recipients is prohibited. In this case, 3314 discard the per-recipient information. 3316 If any MTS.ORName.directory-name is present, it shall be 3318 RFC 1327bis 3319 MIXER DRAFT Version 2.6 3321 represented in an 822.comment. 3323 If 3324 MTS.OtherMessageDeliveryFields.orignally-intended-recipient-name 3325 is present, then there has been redirection, or there has been 3326 distribution list expansion. Distribution list expansion is a 3327 per-message option, and the information associated with this is 3328 represented by the "DL-Expansion-History:" field described in 3329 Section 5.3.6. Other information is represented in an 3330 822.comment associated with 3331 MTS.OtherMessageDeliveryFields.this-recipient-name, The message 3332 may be delivered to different RFC 822 recipients, and so several 3333 addresses in the "X400-Recipients:" field may have such comments. 3334 The non-commented recipient is the RFC 822 recipient. The EBNF of 3335 the comment is defined by redirect-comment. 3337 redirect-comment = redirect-first *( redirect-subsequent ) 3339 redirect-first = "Originally To:" mailbox "Redirected on" 3340 date-time "To:" redirection-reason 3342 redirect-subsequent = mailbox "Redirected Again on" 3343 date-time "To:" redirection-reason 3345 redirection-history-item = "intended recipient" mailbox 3346 "redirected to" redirection-reason 3347 "on" date-time 3349 redirection-reason = 3350 "Recipient Assigned Alternate Recipient" 3351 / "Originator Requested Alternate Recipient" 3352 / "Recipient MD Assigned Alternate Recipient" 3353 / "Directory Look Up" 3354 / "Alias" 3356 It is derived from 3357 MTA.PerRecipientMessageTransferFields.extension.redirection-history. 3358 The values are taken from the X.400(92) Implementor's guide 3359 (Version 13, July 1995). The first three values are in 3360 X.400(88). The fourth value is in X.400(92), but has the name 3361 "recipient-directory-substitution-alternate-recipient". An 3362 example of this with two redirects is: 3364 RFC 1327bis 3365 MIXER DRAFT Version 2.6 3367 X400-Recipients: postmaster@widget.com (Originally To: 3368 sales-manager@sales.widget.com 3369 Redirected on Thu, 30 May 91 14:39:40 +0100 3370 To: Originator Requested Alternate Recipient 3371 postmaster@sales.widget.com 3372 Redirected Again on Thu, 30 May 91 14:41:20 +0100 3373 To: Recipient MD Assigned Alternate Recipient) 3375 In addition the following per-recipient services from 3376 MTS.OtherMessageDeliveryFields.extensions are represented in 3377 comments if they are used. None of these services can be 3378 provided on RFC 822 networks, and so in general these will be 3379 informative strings associated with other MTS recipients. In some 3380 cases, string values are defined. For the remainder, the string 3381 value shall be chosen by the implementor. If the parameter has 3382 a default value, then no comment shall be inserted when the 3383 parameter has that default value. 3385 requested-delivery-method 3387 physical-forwarding-prohibited 3388 "(Physical Forwarding Prohibited)". 3390 physical-forwarding-address-request 3391 "(Physical Forwarding Address Requested)". 3393 physical-delivery-modes 3395 registered-mail-type 3397 recipient-number-for-advice 3399 physical-rendition-attributes 3401 physical-delivery-report-request 3402 "(Physical Delivery Report Requested)". 3404 proof-of-delivery-request 3405 "(Proof of Delivery Requested)". 3407 RFC 1327bis 3408 MIXER DRAFT Version 2.6 3410 4.6.2.3. Delivery Report Generation 3412 If SMTP is used, the behaviour is specified in Appendix A. In 3413 other cases, if 3414 MTA.PerRecipientMessageTransferFields.per-recipient-indicators 3415 requires a positive delivery notification, this shall be 3416 generated by the gateway. Supplementary Information shall be set 3417 to indicate that the report is gateway generated. This 3418 information shall include the name of the gateway generating the 3419 report. 3421 4.6.3. Message IDs (MTS) 3423 A mapping from 822.msg-id to MTS.MTSIdentifier is defined. The 3424 reverse mapping is not needed, as MTS.MTSIdentifier is always 3425 mapped onto new RFC 822 fields. The value of 3426 MTS.MTSIdentifier.local-part will facilitate correlation of 3427 gateway errors. 3429 To map from 822.msg-id, apply the standard mapping to 3430 822.msg-id, in order to generate an MTS.ORAddress. The Country, 3431 ADMD, and PRMD components of this are used to generate 3432 MTS.MTSIdentifier.global-domain-identifier. 3433 MTS.MTSIdentifier.local-identifier is set to the 822.msg-id, 3434 including the braces "<" and ">". If this string is longer than 3435 MTS.ub-local-id-length (32), then it is truncated to this length. 3437 The reverse mapping is not used in this specification. It 3438 would be applicable where MTS.MTSIdentifier.local-identifier is 3439 of syntax 822.msg-id, and it algorithmically identifies 3440 MTS.MTSIdentifier. 3442 4.7. IPMS Mappings 3444 All RFC 822 addresses are assumed to use the 822.mailbox syntax. 3445 This includes all 822.comments associated with the lexical tokens 3446 of the 822.mailbox. In the IPMS OR Names are encoded as 3447 MTS.ORName. This is used within the IPMS.ORDescriptor, 3448 IPMS.RecipientSpecifier, and IPMS.IPMIdentifier. An asymmetrical 3449 mapping is defined between these components. 3451 4.7.1. RFC 822 -> X.400 3453 To derive IPMS.ORDescriptor from an RFC 822 address. 3455 RFC 1327bis 3456 MIXER DRAFT Version 2.6 3458 1. Take the address, and extract an EBNF.822-address. Any 3459 source routing shall be removed. This can be derived 3460 trivially from either the 822.addr-spec or 822.route-addr 3461 syntax. This is mapped to MTS.ORName as described above, 3462 and used as IMPS.ORDescriptor.formal-name. 3464 2. A string shall be built consisting of (if present): 3466 - The 822.phrase component if the 822.address is an 3467 822.phrase 822.route-addr construct. 3469 - Any 822.comments, in order, retaining the parentheses. 3471 This string is then encoded into T.61 using a human oriented 3472 mapping (as described in Section 3.5). If the string is not 3473 null, it is assigned to IPMS.ORDescriptor.free-form-name. 3475 3. IPMS.ORDescriptor.telephone-number is omitted. 3477 If IPMS.ORDescriptor is being used in IPMS.RecipientSpecifier, 3478 IPMS.RecipientSpecifier.reply-request and 3479 IPMS.RecipientSpecifier.notification-requests are set to default 3480 values (false and none). 3482 If the 822.group construct is present, any included 3483 822.mailbox is encoded as above to generate a separate 3484 IPMS.ORDescriptor. The 822.group is mapped to T.61 (as 3485 described in Section 3.5), and a IPMS.ORDescriptor with only an 3486 free-form-name component built from it. 3488 4.7.2. X.400 -> RFC 822 3490 Mapping from IPMS.ORDescriptor to RFC 822 address. In the basic 3491 case, where IPMS.ORDescriptor.formal-name is present, proceed as 3492 follows. 3494 1. Encode IPMS.ORDescriptor.formal-name (MTS.ORName) as 3495 EBNF.822-address. 3497 2a. If IPMS.ORDescriptor.free-form-name is present, convert it 3498 to ASCII or T.61 (Section 3.5), and use this as the 3499 822.phrase component of 822.mailbox using the 822.phrase 3500 822.route-addr construct. 3502 RFC 1327bis 3503 MIXER DRAFT Version 2.6 3505 2b. If IPMS.ORDescriptor.free-form-name is absent. If 3506 EBNF.822-address is parsed as 822.addr-spec use this as the 3507 encoding of 822.mailbox. If EBNF.822-address is parsed as 3508 822.route 822.addr-spec, then an 822.phrase taken from 3509 822.local-part is added. 3511 3 If IPMS.ORDescriptor.telephone-number is present, this is 3512 placed in an 822.comment, with the string "Tel ". The 3513 normal international form of number is used. For example: 3515 (Tel +44-181-333-7777) 3517 4. If IPMS.ORDescriptor.formal-name.directory-name is present, 3518 then a text representation is placed in a trailing 3519 822.comment. 3521 5. If IPMS.RecipientSpecifier.report-request has any non- 3522 default values, then an 822.comment "(Receipt Notification 3523 Requested)", and/or "(Non Receipt Notification Requested)", 3524 and/or "(IPM Return Requested)" may be appended to the 3525 address. "(Receipt Notification Requested)" may be used to 3526 infer "(Non Receipt Notification Requested)". The effort of 3527 correlating P1 and P2 information is too great to justify 3528 the gateway sending Receipt Notifications. 3530 In RFC 1327, inclusion of these comments was mandatory. 3531 Experience has shown that the clutter and confusion caused 3532 to RFC 822 users does not justify the information conveyed. 3533 Implementors are recommended to not include these comments. 3534 Unless an application is found where retention of these 3535 comments is desirable, they will be dropped from the next 3536 version. 3538 6. If IPMS.RecipientSpecifier.reply-request is True, an 3539 822.comment "(Reply requested)" is appended to the address. 3541 If IPMS.ORDescriptor.formal-name is absent, 3542 IPMS.ORDescriptor.free-form-name is converted to ASCII (see 3543 section 3.5), and used as 822.phrase within the RFC 822 822.group 3544 syntax. For example: 3546 Free Form Name ":" ";" 3548 RFC 1327bis 3549 MIXER DRAFT Version 2.6 3551 Steps 3-6 are then followed. 3553 4.7.3. IP Message IDs 3555 There is a need to map both ways between 822.msg-id and 3556 IPMS.IPMIdentifier. This allows for X.400 Receipt Notifications, 3557 Replies, and Cross References to reference an RFC 822 Message ID, 3558 which is preferable to a gateway generated ID. A reversible and 3559 symmetrical mapping is defined. This provides fully reversible 3560 mappings when messages pass multiple times across the X.400/RFC 3561 822 boundary. 3563 An important issue with messages identifiers is mapping to 3564 the exact form, as many systems use these ids as uninterpreted 3565 keys. The use of table driven mappings is not always 3566 symmetrical, particularly in the light of alternative domain 3567 names, and alternative management domains. For this reason, a 3568 purely algorithmic mapping is used. A mapping which is simpler 3569 than that for addresses can be used for two reasons: 3571 - There is no major requirement to make message IDs "natural" 3573 - There is no issue about being able to reply to message IDs. 3574 (For addresses, creating a return path which works is more 3575 important than being symmetrical). 3577 The mapping works by defining a way in which message IDs 3578 generated on one side of the gateway can be represented on the 3579 other side in a systematic manner. The mapping is defined so 3580 that the possibility of clashes is low enough to be treated as 3581 impossible. 3583 4.7.3.1. 822.msg-id represented in X.400 3585 IPMS.IPMIdentifier.user is omitted. The 3586 IPMS.IPMIdentifier.user-relative-identifier is set to a printable 3587 string encoding of the 822.msg-id with the angle braces ("<" and 3588 ">") removed. The upper bound on this component is 64. The 3589 options for handling this are discussed in Section 5.1.3. 3591 4.7.3.2. IPMS.IPMIdentifier represented in RFC 822 3593 The 822.domain of 822.msg-id is set to the value "MHS". The 3594 822.local-part of 822.msg-id is constructed by building a string 3596 RFC 1327bis 3597 MIXER DRAFT Version 2.6 3599 of syntax EBNF.id-loc from IPMS.IPMIdentifier. 3601 id-loc ::= [ printablestring ] "*" [ std-or-address ] 3603 EBNF.printablestring is the 3604 IPMS.IPMIdentifier.user-relative-identifier, and EBNF.std-or- 3605 address being an encoding of the IPMS.IPMIdentifier.user derived 3606 according to this specification. 822.local-part is derived from 3607 EBNF.id-loc, if necessary using the 822.quoted-string encoding. 3608 For example: 3610 <"147*/S=Dietrich/O=Siemens/ADMD=DBP/C=DE/"@MHS> 3612 4.7.3.3. 822.msg-id -> IPMS.IPMIdentifier 3614 If the 822.local-part can be parsed as: 3616 [ printablestring ] "*" [ std-or-address ] 3618 and the 822.domain is "MHS", then this ID was X.400 generated. 3619 If EBNF.printablestring is present, the value is assigned to 3620 IPMS.IPMIdentifier.user-relative-identifier. If 3621 EBNF.std-or-address is present, the OR Address components derived 3622 from it are used to set IPMS.IPMIdentifier.user. 3624 Otherwise, this is an RFC 822 generated ID. In this case, 3625 set IPMS.IPMIdentifier.user-relative-identifier to a printable 3626 string encoding of the 822.msg-id without the angle braces and 3627 omit IPMS.IPMID.user. 3629 4.7.3.4. IPMS.IPMIdentifier -> 822.msg-id 3631 If IPMS.IPMIdentifier.user is absent, and 3632 IPMS.IPMIdentifier.user-relative-identifier mapped to ASCII and 3633 angle braces added parses as 822.msg-id, then this is an RFC 822 3634 generated ID. 3636 Otherwise, the ID is X.400 generated. Use the 3637 IPMS.IPMIdentifier.user to generate an EBNF.std-or-address form 3638 string. Build the 822.local-part of the 822.msg-id with the 3639 syntax: 3641 [ printablestring ] "*" [ std-or-address ] 3643 RFC 1327bis 3644 MIXER DRAFT Version 2.6 3646 The printablestring is taken from 3647 IPMS.IPMIdentifier.user-relative-identifier. Use 3648 822.quoted-string if necessary. The 822.msg-id is generated with 3649 this 822.local-part, and "MHS" as the 822.domain. 3651 4.7.3.5. Phrase form 3653 In "In-Reply-To:" and "References:", the encoding 822.phrase may 3654 be used as an alternative to 822.msg-id. To map from 822.phrase 3655 to IPMS.IPMIdentifier, assign 3656 IPMS.IPMIdentifier.user-relative-identifier to the phrase. When 3657 mapping from IPMS.IPMIdentifier for "In-Reply-To:" and 3658 "References:", if IPMS.IPMIdentifier.user is absent and 3659 IPMS.IPMIdentifier.user-relative-identifier does not parse as 3660 822.msg-id, generate an 822.phrase rather than adding the domain 3661 MHS. 3663 4.7.3.6. RFC 987 backwards compatibility 3665 The mapping defined here is different to that used in RFC 987, as 3666 the RFC 987 mapping lead to changed message IDs in many cases. 3667 Fixing the problems is preferable to retaining backwards 3668 compatibility. An implementation of this standard may recognise 3669 message IDs generated by RFC 987. This is not recommended. 3671 RFC 987 generated encodings may be recognised as follows. 3672 When mapping from X.400 to RFC 822, if the 3673 IPMS.IPMIdentifier.user-relative-identifier is "RFC-822" the id 3674 is RFC 987 generated. When mapping from RFC 822 to X.400, if the 3675 822.domain is not "MHS", and the 822.local-part can be parsed as 3677 [ printablestring ] "*" [ std-or-address ] 3679 then it is RFC 987 generated. In each of these cases, it is 3680 recommended to follow the RFC 987 rules. 3682 RFC 1327bis 3683 MIXER DRAFT Version 2.6 3685 Chapter 5 - Detailed Mappings 3687 This chapter specifies detailed mappings for the functions 3688 outlined in Chapters 1 and 2. It makes extensive use of the 3689 notations and mappings defined in Chapters 3 and 4. 3691 5.1. RFC 822 -> X.400: Detailed Mappings 3693 The mapping of RFC 822/MIME messages to X.400 InterPersonal 3694 Messages is described in Sections 5.1.1 to 5.1.7. Mapping of 3695 NOTARY format delivery status notifications, which are all 3696 messages of type multipart/report and subtype 3697 delivery-status-notifications to X.400 delivery reports is 3698 covered in Section 5.1.8. 3700 5.1.1. Basic Approach 3702 A single IP Message is generated from an RFC 822 message. The 3703 RFC 822 headers are used to generate the IPMS.Heading. 3705 Some RFC 822 fields cannot be mapped onto a standard IPM 3706 Heading field, and so an extended field is defined in Section 3707 5.1.2. This is then used for fields which cannot be mapped onto 3708 existing services. 3710 The message is submitted to the MTS, and the services 3711 required can be defined by specifying 3712 MTS.MessageSubmissionEnvelope. A few parameters of the MTA 3713 Abstract service are also specified, which are not in principle 3714 available to the MTS User. Use of these services allows RFC 822 3715 MTA level parameters to be carried in the analogous X.400 service 3716 elements. The advantages of this mapping far outweigh the 3717 layering violation. 3719 5.1.2. X.400 Extension Field 3721 An IPMS Extension is defined: 3723 RFC 1327bis 3724 MIXER DRAFT Version 2.6 3726 rfc-822-field HEADING-EXTENSION 3727 VALUE RFC822FieldList 3728 ::= id-rfc-822-field-list 3730 RFC822FieldList ::= SEQUENCE OF RFC822Field 3732 RFC822Field ::= IA5String 3734 The Object Identifier id-rfc-822-field-list is defined in 3735 Appendix D. 3737 To encode any RFC 822 Header using this extension, an 3738 RFC822Field element is built using the 822.field omitting the 3739 trailing CRLF (e.g., "Fruit-Of-The-Day: Kiwi Fruit"). All fields 3740 shall be unfolded. There shall be no space before the ":". The 3741 reverse mapping builds the RFC 822 field in a straightforward 3742 manner. This RFC822Field is appended to the RFC822FieldList, 3743 which is added to the IPM Heading as an extension field. 3745 5.1.3. Generating the IPM 3747 The IPM (IPMS Service Request) is generated according to the 3748 rules of this section. The IPMS.IPM.body is generated from the 3749 RFC 822 message body in the manner described in Section 5.1.5. 3751 If no specific 1988 features are used, the IPM generated is 3752 encoded as content type 2. Otherwise, it is encoded as content 3753 type 22. The latter will always be the case if extension heading 3754 fields are generated. 3756 When generating the IPM, the issue of upper bounds are 3757 handled as follows. Truncate fields to the upper bounds specified 3758 in X.400. This will prevent problems with UAs which enforce 3759 upper bounds, but will sometimes discard useful information. 3760 This approach will cause more problems for some fields than 3761 others (e.g., truncating an OR Address component that would be 3762 used to route a reply would be a more severe problem than 3763 truncating a Free Form Name). If the Free Form name is 3764 truncated, it shall be done so that it does not break RFC 822 3765 comments and RFC 1522 encoding. 3767 RFC 1327bis 3768 MIXER DRAFT Version 2.6 3770 Note:This approach removes a choice of options given in RFC 1327, 3771 based on operational experience. 3773 The rest of this section concerns IPMS.IPM.heading 3774 (IPMS.Heading). The only mandatory component of IPMS.Heading is 3775 the IPMS.Heading.this-IPM (IPMS.IPMIdentifier). A default is 3776 generated by the gateway. With the exception of "Received:", the 3777 values of multiple fields are merged (e.g., If there are two 3778 "To:" fields, then the mailboxes of both are merged to generate a 3779 single list which is used in the IPMS.Heading.primary-recipients. 3780 Information shall be generated from the standard RFC 822 Headers 3781 as follows: 3783 Date: 3784 Ignore (Handled at MTS level) 3786 Received: 3787 Ignore (Handled at MTA level) 3789 Message-Id: 3790 Mapped to IPMS.Heading.this-IPM. For these, and all other 3791 fields containing 822.msg-id the mappings of Chapter 4 are 3792 used for each 822.msg-id. 3794 From: 3795 If Sender: is present, this is mapped to 3796 IPMS.Heading.authorizing-users. If not, it is mapped to 3797 IPMS.Heading.originator. For this, and other components 3798 containing addresses, the mappings of Chapter 4 are used for 3799 each address. 3801 Sender: 3802 Mapped to IPMS.Heading.originator. Because X.400 does not 3803 have the same From/Sender distinction as RFC 822, this 3804 mapping is not always natural and may lead to unexpected 3805 results in some cases. 3807 Reply-To: 3808 Mapped to IPMS.Heading.reply-recipients. 3810 To: Mapped to IPMS.Heading.primary-recipients 3812 Cc: Mapped to IPMS.Heading.copy-recipients. 3814 RFC 1327bis 3815 MIXER DRAFT Version 2.6 3817 Bcc: Mapped to IPMS.Heading.blind-copy-recipients if there is at 3818 least one BCC: recipient. If there are no recipients in 3819 this field, it shall either be mapped to a zero length 3820 sequence or mapped to a single recipient that has a free 3821 from name "BCC" and no other addressing information. This 3822 alternate treatment is allowed because some X.400 systems 3823 cannot handle a zero lenght sequence of addresses. 3825 In-Reply-To: 3826 If there is one value, it is mapped to 3827 IPMS.Heading.replied-to-IPM, using the 822.phrase or 3828 822.msg-id mapping as appropriate. If there are multiple 3829 values, this cannot be done as the X.400 heading is single 3830 valued. In this case no IPMS.Heading.replied-to-IPM is 3831 generated and the values are mapped to 3832 IPMS.Heading.related-IPMs, along with any values from a 3833 "References:" field. 3835 References: 3836 Mapped to IPMS.Heading.related-IPMs. 3838 Keywords: 3839 Mapped onto a heading extension. 3841 Subject: 3842 Mapped to IPMS.Heading.subject. The field-body uses the 3843 human oriented mapping referenced in Section 3.3.4. 3845 Comments: 3846 Mapped onto a heading extension. 3848 This is a change from 1327, which specified to generate an 3849 IPMS.BodyPart of type IPMS.IA5TextBodyPart with 3850 IPMS.IA5TextBodyPart.parameters.repertoire set to the 3851 default (ia5), containing the value of the fields, preceded 3852 by the string "Comments: " and that this body part shall 3853 precede the other one. Experience has shown that this 3854 complexity is not justified. This text is retained to 3855 facilitate backwards compatibility. 3857 Encrypted: 3858 Mapped onto a heading extension. 3860 Resent-* 3862 RFC 1327bis 3863 MIXER DRAFT Version 2.6 3865 Mapped onto a heading extension. 3867 Note that it would be possible to use a ForwardedIPMessage 3868 for these fields, but the semantics are (arguably) slightly 3869 different, and it is probably not worth the effort. 3871 Content-Language: 3872 This field is defined in RFC 1766 [7]. Map the first two 3873 characters of each value given onto the IPM Languages 3874 extension. If any comments or values longer than two 3875 characters occur, a header extension shall also be 3876 generated. 3878 Other Fields 3879 In particular X-* fields, and "illegal" fields in common 3880 usage (e.g., "Fruit-of-the-day:") are mapped onto a heading 3881 extension, unless covered by another section or appendix of 3882 this specification. The same treatment is applied to RFC 3883 822 fields where the content of the field does not conform 3884 to RFC 822 (e.g., a Date: field with unparseable syntax). 3886 The mapping of the following headings is defined in RFC1494bis. 3888 MIME-Version: 5 3889 Content-Transfer-Encoding: 3890 Content-Type 3891 Content-ID 3892 Content-Description 3894 5.1.4. Generating the IPM Body 3896 Generation of the IPM Body is defined in RFC1494bis. 3898 5.1.5. Mappings to the MTS Abstract Service 3900 The MTS.MessageSubmissionEnvelope comprises 3901 MTS.PerMessageSubmissionFields, and 3902 MTS.PerRecipientMessageSubmissionFields. The mandatory 3903 parameters are defaulted as follows. 3905 MTS.PerMessageSubmissionFields.originator-name 3906 This is always generated from SMTP, as defined in Chapter 4. 3908 MTS.PerMessageSubmissionFields.content-type 3910 RFC 1327bis 3911 MIXER DRAFT Version 2.6 3913 Set to the value implied by the encoding of the IPM (2 or 3914 22). 3916 MTS.PerRecipientMessageSubmissionFields.recipient-name 3917 These will always be supplied from SMTP, as defined in 3918 Chapter 4. 3920 Optional components are omitted, and default components 3921 defaulted. This means that disclosure of recipients is 3922 prohibited and conversion is allowed. There are two exceptions 3923 to the defaulting. For 3924 MTS.PerMessageSubmissionFields.per-message-indicators, the 3925 following settings are made: 3927 - Alternate recipient is allowed, as it seems desirable to 3928 maximise the opportunity for (reliable) delivery. 3930 If SMTP is used, Appendix A shall be followed in setting these 3931 parameters. 3933 The trace is set to indicate conversion (described below) 3934 and the encoded information types in the trace is derived from 3935 the message generated by the gateway, and shall reflect all body 3936 parts (including those in enclosed messages). In addition it 3937 shall include the Encoded Information Type "eit-mixer", which is 3938 defined in Appendix D. The presence of the EIT will indicate to 3939 the X.400 recipient that a MIXER conversion has occurred. 3940 MTS.PerMessageSubmissionFields.original-encoded-information-types 3941 will include all of the values used in the trace, unless 3942 specified otherwise in RFC1494bis. 3944 This type of conversion will prevent the normal loop 3945 detection from working in certain circumstances, and introduces 3946 the possiblity of gateway loops. MIXER gateways shall therefore 3947 count the number of MIXER conversions made. If this count 3948 exceeds five in one direction, the message shall be treated as if 3949 a loop has been detected. 3951 The MTS.PerMessageSubmissionFields.content-correlator is 3952 encoded as IA5String, and contains the Subject:, Message-ID:, 3953 Date:, and To: fields (if present) in this order. This 3954 includes the strings "Subject:", "Date:", "To:", "Message-ID:", 3955 and appropriate folding to make the field appear readable. This 3956 shall be truncated to MTS.ub-content-correlator-length (512) 3958 RFC 1327bis 3959 MIXER DRAFT Version 2.6 3961 characters. In addition, if there is a "Subject:" field, the 3962 MTS.PerMessageSubmissionFields.content-identifier, is set to a 3963 printable string representation of the contents of it. If the 3964 length of this string is greater than MTS.ub-content-id-length 3965 (16), it shall be truncated to 13 characters and the string "..." 3966 appended. Both are used, due to the much larger upper bound of 3967 the content correlator, and that the content id is available in 3968 X.400(1984). 3970 5.1.6. Mappings to the MTA Abstract Service 3972 There is a need to map directly onto some aspects of the MTA 3973 Abstract service, for the following reasons: 3975 - So the MTS Message Identifier can be generated from the RFC 3976 822 Message-ID:. 3978 - So that the submission date can be generated from the 3979 822.Date. 3981 - To prevent loss of trace information 3983 - To prevent RFC 822/X.400 looping caused by distribution 3984 lists or redirects 3986 The following mappings are defined. 3988 Message-Id: 3989 If this is present and no Resent: fields are present, the 3990 MTA.PerMessageTransferFields.message-identifier may be 3991 generated from it, using the mappings described in 3992 Chapter 4. 3994 This mapping arguably generates messages which do not 3995 conform to US GOSIP (1984 version only), which states: 3997 6.7.e MPDU Identifier Validation 3999 (1) Validation of the GlobalDomainIdentifier component of 4000 the MPDU Identifier is performed on reception of a message 4001 (i.e. the result of a TRANSFER.Indication). 4003 (2) The country name should be known to the validating 4004 domain, and depending on the country name, validation of the 4006 RFC 1327bis 4007 MIXER DRAFT Version 2.6 4009 ADMD name may also be possible. 4011 (3) Additional validation of the GlobalDomainIdentifier is 4012 performed against the corresponding first entry in the 4013 TraceInformation. If inconsistencies are found during the 4014 comparison, a non-delivery notice with the above defined 4015 reason and diagnostic code is generated. 4017 (4) A request will be generated to the CCITT for a more 4018 meaningful diagnostic code (such as 4019 "InconsistentMPUTIdentifier"). 4021 This applies to ADMDs only, and is specified in the 1984 4022 version and not the 1988 version. Conformance depends on the 4023 interpretation of "inconsistency". The specification makes the 4024 most sensible choice, and so is not being changed in the update 4025 from RFC 1327. 4027 Date: (and Resent-Date:) 4028 If one or more Resent-Date: fields is present, the most 4029 recent Resent-Date: field shall be used instead of the Date: 4030 field in the following description. 4032 The Date: field is used to set the first component of 4033 MTA.PerMessageTransferFields.trace-information 4034 (MTA.TraceInformationElement). The SMTP originator is 4035 mapped into an MTS.ORAddress, and used to derive 4036 MTA.TraceInformationElement.global-domain-identifier. The 4037 optional components of 4038 MTA.TraceInformationElement.domain-supplied-information are 4039 omitted, and the mandatory components are set as follows: 4041 MTA.DomainSuppliedInformation.arrival-time 4042 This is set to the date derived from Date: 4044 MTA.DomainSuppliedInformation.routing-action 4045 Set to relayed. 4047 The first element of 4048 MTA.PerMessageTransferFields.internal-trace-information is 4049 generated in an analogous manner, although this can be 4050 dropped later in certain circumstances (see the procedures 4051 for "Received:"). The 4052 MTA.InternalTraceInformationElement.mta-name is derived from 4054 RFC 1327bis 4055 MIXER DRAFT Version 2.6 4057 the 822.domain in the 822 MTS Originator address. 4059 Received: 4060 All RFC 822 trace is used to derive 4061 MTA.PerMessageTransferFields.trace-information and 4062 MTA.PerMessageTransferFields.internal-trace-information. 4063 Processing of Received: lines follows processing of Date:, 4064 and is done from the bottom to the top of the RFC 822 header 4065 (i.e., in chronological order). When other trace elements 4066 (in particular X400-Received:) are processed the relative 4067 ordering (top to bottom of the header) shall be retained 4068 correctly. 4070 The initial element of 4071 MTA.PerMessageTransferFields.trace-information shall be 4072 generated from Date: as described above, unless the message 4073 has previously been in X.400, when it will be derived from 4074 the X.400 trace information. 4076 For each Received: field, the following processing shall be 4077 done. If the "by" part of the received is present and 4078 there is an available MCGAM which can map this domain, use 4079 it to derive an MTS.GlobalDomainIdentifier. Otherwise 4080 MTS.GlobalDomainIdentifier is set from local information. 4081 If this is different from the one in the last element of 4082 MTA.PerMessageTransferFields.trace-information 4083 (MTA.TraceInformationElement.global-domain-identifier) 4084 create a new MTA.TraceInformationElement, and optionally 4085 remove 4086 MTA.PerMessageTransferFields.internal-trace-information. 4087 Requirements on trace stripping are discussed below. 4089 Then add a new element (MTA.InternalTraceInformationElement) 4090 to MTA.PerMessageTransferFields.internal-trace-information, 4091 creating this if needed. This shall be done, even if 4092 inter-MD trace is created. The 4093 MTA.InternalTraceInformationElement.global-domain-identifier 4094 is set to the value derived. The 4095 MTA.InternalTraceInformationElement.mta-supplied-information 4096 (MTA.MTASuppliedInformation) is set as follows: 4098 MTA.MTASuppliedInformation.arrival-time 4099 Derived from the date of the Received: line 4101 RFC 1327bis 4102 MIXER DRAFT Version 2.6 4104 MTA.MTASuppliedInformation.routing-action 4105 Set to relayed 4107 The MTA.InternalTraceInformationElement.mta-name is taken 4108 from the "by" component of the "Received:" field, truncated 4109 to MTS.ub-mta-name-length (32). For example: 4111 Received: from computer-science.nottingham.ac.uk by 4112 vs6.Cs.Ucl.AC.UK via Janet with NIFTP id aa03794; 4113 28 Mar 89 16:38 GMT 4115 Generates the string 4117 vs6.Cs.Ucl.AC.UK 4119 The gateway shall add in a single element of trace information, 4120 reflecting the gateway's local information and the time of 4121 conversion. The 4122 MTA.InternalTraceInformationElement.mta-supplied-information 4123 (MTA.MTASuppliedInformation) is set as follows: 4125 MTA.DomainSuppliedInformation.arrival-time 4126 Set to the time of conversion 4128 MTA.DomainSuppliedInformation.routing-action 4129 Set to relayed 4131 MTA.AdditionalAcctions.converted-encoded-information-types 4132 Set to correct set of EITs for the message that is generated 4133 by the gateway. This trace element will thus reflect 4134 gateway operation as a conversion. 4136 This trace generation will often lead to generation of 4137 substantial amounts of trace information, which does not reflect 4138 X.400 transfers. Stripping of some of this trace may be 4139 necessary in some operational environments. This stripping 4140 shall be considered a function of the associated X.400 MTA, and 4141 not of the MIXER gateway. 4143 5.1.7. Mapping New Fields 4145 This specification defines a number of new fields for Reports, 4147 RFC 1327bis 4148 MIXER DRAFT Version 2.6 4150 Notifications and IP Messages. A gateway conforming to this 4151 specification shall map all of these fields to X.400, except as 4152 defined below. 4154 The mapping of two extended fields is particularly 4155 important, in order to prevent looping. "DL-Expansion-History:" 4156 is mapped to 4157 MTA.PerMessageTransferFields.extensions.dl-expansion-history 4158 X400-Received: shall be mapped to 4159 MTA.PerMessageTransferFields.trace-information and 4160 MTA.PerMessageTransferFields.internal-trace-information. In 4161 cases where X400-Received: is present, the usual mapping of Date: 4162 to generate the first element of trace shall not be done. This 4163 is because the message has come from X.400, and so the first 4164 element of trace can be taken from the first X400-Received:. 4166 The following fields shall not be mapped, and shall be 4167 discarded: 4169 - Discarded-X400-MTS-Extensions: 4171 - Message-Type: 4173 - Discarded-X400-IPMS-Extensions: 4175 - X400-Content-Type: 4177 - X400-Originator: 4179 - X400-Recipients: 4181 - X400-MTS-Identifier: Mapping this field would be useful in 4182 some circumstances, but very dangerous in others (e.g., 4183 following an internet list expansion). Therefore it is not 4184 mapped. 4186 5.1.8. Mapping Delivery Status Notifications to X.400 4188 5.1.8.1. Basic Model 4190 Internet Mail delivery status notifications (DSN) are mapped to 4191 X.400 delivery reports. With message mapping, information 4192 without a mapping is carried by an IPM Extension. This cannot 4194 RFC 1327bis 4195 MIXER DRAFT Version 2.6 4197 be done for delivery reports. Two mechanisms are used for 4198 information where there is not a direct mapping. 4200 The first mechanism is to define extensions, which allow all 4201 of the DSN information to be carried in the delivery report. 4202 This is not completely satisfactory for two reasons: 4204 1. User defined extensions are supported by the ISO version of 4205 the standard, but not the CCITT one. Therefore, 4206 implementation support for these extensions will not be 4207 universal. 4209 2 X.400 User Agent implementations will not in general 4210 recognise these extensions. Therefore, although the 4211 information will be present, it will often not be available 4212 to the user. This may be very problematic, as this 4213 information may be critical to diagnosing the reason for a 4214 failure. 4216 Therefore a second mechanism is defined. This shall always 4217 be used when the DSN contains non-delivery information, and may 4218 be used in other cases. This mechanism is to map the whole DSN 4219 (as if it were an ordinary multipart) into the return of content. 4220 This will make the DSN information available as a text body part 4221 in the outer message, with the real returned content as an 4222 enclosed message. This mechanism will ensure that information is 4223 not lost at the gateway. 4225 5.1.8.2. DSN Extensions 4227 Two X.400 MTS extensions are defined as follows: 4229 dsn-header-list EXTENSION 4230 RFC822FieldList 4231 ::= id-dsn-header-list 4233 dsn-field-list EXTENSION 4234 RFC822FieldList 4235 ::= id-dsn-field-list 4237 The Object Identifiers id-dsn-header-list and id-dsn-field-list 4238 are defined in Appendix D. Theses extensions are used in the 4239 same way as the IPM extension rfc-822-field, described in Section 4240 5.1.2. These extensions may only be used with ISO-10021, and 4242 RFC 1327bis 4243 MIXER DRAFT Version 2.6 4245 not X.400 (which does not allow user extensions at the MTS 4246 level). 4248 5.1.8.3. DSN to Delivery Report Mapping 4250 Some DSNs are mapped to Delivery Reports and some to IPMs, 4251 according to the value of the action field. The mapping to an 4252 IPM is exactly as for a normal IPM mapping. The choice of IPM 4253 and Delivery report is made for each reported recipient. If 4254 this choice is different for different reported recipients both a 4255 Delivery Report and an IPM shall be generated. 4257 Reports are not be submitted in the X.400 model, and so the 4258 report submission is considered in terms of the MTA Abstract 4259 Service. An MTA.Report is constructed. The 4260 MTA.ReportTransferEnvelope.report-identifier is generated from 4261 the Message-Id of the DSN (if present) and otherwise generated as 4262 the MTA would generate one for a submitted message. 4264 The DSN has an RFC 822 header. Trace is mapped in the same 4265 manner as for a message to 4266 MTA.ReportTransferEnvelope.trace-information. All other headers 4267 are used to create a dsn-header-list extension, which is added to 4268 MTA.PerReportTransferFields.extensions. 4270 The DSN will have a single SMTP recipient. This is mapped 4271 to the MTA.ReportTransferEnvelope.report-destination-name. 4273 The DSN is then treated as a normal MIME message, and an 4274 X.400 IPM is generated. This IPM is used as 4275 MTA.PerReportTransferFields.returned-content, and its type is 4276 used to set MTA.PerReportTransferFields.content-type. The DSN 4277 body part is mapped as if it was IA5 text/plain. 4279 The mandatory MTA.PerReportTransferFields.subject-identifier 4280 shall be generated from the DSN.per-message-field 4281 original-envelope-id, if this starts with the string 4282 "X400-MTS-Identifier: ", and derived from the rest of the field, 4283 which is encoded as EBNF.mts-msg-id. In other cases, this field 4284 shall be generated by the MIXER Gateway. 4286 All other mappings are made from the DSN body part. A dsn- 4287 field-list extension is created and added to 4288 MTA.ReportTransferFields.extensions. This is referred to as the 4290 RFC 1327bis 4291 MIXER DRAFT Version 2.6 4293 per report extension list. The DSN.per-message-fields are mapped 4294 as follows: 4296 original-envelope-id-field 4297 reporting-mta-field 4298 dsn-gateway-field 4299 received-from-mta-field 4300 arrival-date-field 4301 extension-field 4302 other 4304 All of these fields are added to the per report extension 4305 list. Currently there are no other mappings defined. 4307 Each reported recipient is considered in turn, and a 4308 MTA.PerRecipientReportTransferFields created for each. The 4309 parameters of this are defaulted as follows: 4311 originally-specified-recipient-number 4312 In general, these are not available, and so are assigned 4313 incrementally. 4315 last-trace-information 4316 The arrival-time is generated from DSN.arrival-date if 4317 present, and if not from the Date: of the DSN. This is a 4318 strucutred field, and the Report element contains the key 4319 information on the recipient. For a DeliveryReport, the 4320 type-ofMTS-user is defaulted to public and the 4321 message-deliery-time is set to the same as the arrival-time. 4322 For a NonDeliveryReport, the code mappings are define in 4323 Section 5.1.8.4. 4325 A dsn-field-list extension is created and added to 4326 MTA.PerRecipientTransferFields.extensions. This is referred to 4327 as the per recipient extension list. The 4328 DSN.per-recipient-fields are mapped as follows 4330 original-recipient-field 4331 Mapped to 4332 MTA.PerRecipientReportTransferFields.originally-intended-recipient-name. 4334 final-recipient-field 4335 Mapped to 4337 RFC 1327bis 4338 MIXER DRAFT Version 2.6 4340 MTA.PerRecipientReportTransferFields.actual-recipient-name. 4342 action-field 4343 If this is set to "failed", a non-delivery report is 4344 generated. If this is set to "delivered" a delivery report 4345 is generated. Bit one or two of 4346 MTA.PerRecipientTransferFields.per-recipient-indicators is 4347 set accordingly. This also controls the encoding of 4348 MTA.PerRecipientTransferFields.last-trace-information, and 4349 the selection of the report type. 4351 For other values of the action-field ("delayed", "relayed", 4352 "expanded"), an IPM is generated. This enables the status 4353 information to be communicated to the X.400 user, without 4354 the confusion of multiple delivery reports. 4356 status-field 4357 This is added to the per report extension list. For non- 4358 delivery, it is also used to generate the reason and 4359 diagnostic codes contained within 4360 MTA.PerRecipientReportTransferFields.last-trace. The 4361 mappings are defined below. 4363 remote-mta-field 4365 diagnostic-code-field 4367 last-attempt-date-field 4369 will-retry-until-field 4371 extension-field 4373 other 4374 All of these fields are added to the per recipient extension 4375 list. 4377 5.1.8.4. Status Value Mappings 4379 Status values are mapped to X.400 reason and diagnostic codes as 4380 follows. 4382 If a status value is found that is not in this table, the 4383 gateway may use the same mapping as for "X.n.0" (1/None or 4385 RFC 1327bis 4386 MIXER DRAFT Version 2.6 4388 0/None), or it may map to another, configurable code. 4389 Implementors are requested to forward new codes to the mixer list 4390 for inclusion in future versions of this standard. So for 4391 instance. "5.2.37", currently undefined, would map onto the same 4392 as "5.2.0", namely 1/None. 4394 DSN code Meaning X400 code Meaning 4396 X.0.0 Other status 1/None 4398 X.1.0 Other Address Status 1/None 4399 X.1.1 Bad mailbox address 1/0 Unrecognized 4400 X.1.2 Bad system address 1/0 Unrecognized 4401 X.1.3 Bad mailbox address syntax 1/0 Unrecognized 4402 X.1.4 Mailbox address ambiguous 1/1 4403 X.1.5 Only used for positive reports, not applicable 4404 X.1.6 Destination mailbox has moved 1/43 New address unknown 4405 X.1.7 Bad sender's mailbox address syntax 1/11 Invalid arguments 4406 X.1.8 Bad sender's system address 1/11 Invalid arguments 4408 X.2.0 Other or undefined mailbox status 1/None 4409 X.2.1 Mailbox disabled, not accepting 1/4 Recipient unavailable 4410 X.2.2 Mailbox full 1/4 4411 X.2.3 Message length exceeds admin limit. 1/7 Content too long 4412 X.2.4 Mailing list expansion problem 1/30 DL expansion failure 4414 X.3.0 Other or undefined system status 0/None 4415 X.3.1 System full 1/2 MTS congestion 4416 X.3.2 System not accepting network messages 1/2 MTS congestion 4417 X.3.3 System not capable of selected feat 1/18 Unsupp. crit. func 4418 X.3.4 Message too big for system 1/7 4419 X.3.5 System incorrectly configured 1/None 4421 RFC 1327bis 4422 MIXER DRAFT Version 2.6 4424 X.4.0 Other or undefined network or routing 0/None 4425 X.4.1 No answer from host 0/None 4426 X.4.2 Bad connection 0/None 4427 X.4.3 Routing server failure 6/None Directory op unsucc. 4428 X.4.4. Unable to route 0/None 4429 X.4.5 Network congestion 1/2 MTS congest. 4430 X.4.6 Routing loop detected 1/3 4431 X.4.7 Delivery time expired 1/5 4433 X.5.0 Other or undefined protocol status 1/None 4435 X.5.1 Invalid command 1/14 Protocol viol. 4436 X.5.2 Syntax error 1/14 4437 X.5.3 Too many recipients 1/16 4438 X.5.4 Invalid command arguments 1/14 4439 X.5.5 Wrong protocol version 1/18 Unsupp.crit.func 4441 X.6.0 Other or undefined media error 2/None Conv. not perf 4442 X.6.1 Media not supported 1/6 EIT unsupp. 4443 X.6.2 Conversion required and prohibited 1/9 4444 X.6.3 Conversion required but not supported 2/8 4445 X.6.4 Conversion with loss performed POSITIVE only 4446 X.6.5 Conversion failed 2/47 Unable to downgrade 4448 X.7.0 Other or undefined security status 1/46 4449 X.7.1 Delivery not authorized, message ref 1/29 No DL submit perm 4450 X.7.2 Mailing list expansion prohibited 1/28 4451 X.7.3 Security conversion req but not poss 1/46 Secure mess. error 4452 X.7.4 Security features not supported 1/46 4453 X.7.5 Cryptographic failure 1/46 4454 X.7.6 Cryptographic algorithm not supported 1/46 4455 X.7.7 Message integrity failure 1/46 4457 5.1.8.5. DSNs that originated in X.400 4459 The mapping of X.400 delivery reports to DSNs will in general 4460 provide sufficient information to make a useful reverse mapping. 4461 Messages will often be mapped multiple times, commonly due to 4462 forwarding messages and to distribution lists. Multiple 4463 mappings for delivery reports will be a good deal less common. 4464 For this reason, the reverse mapping of the X.400 DSN extensions 4466 RFC 1327bis 4467 MIXER DRAFT Version 2.6 4469 defined in MIXER is optional. 4471 5.2. Return of Contents 4473 RFC 1327 offered two approaches for return of content, as this 4474 service is optional in X.400 and expected in RFC 822. MIXER 4475 simply requires that a gateway requests the return of content 4476 service from X.400. 4478 5.3. X.400 -> RFC 822: Detailed Mappings 4480 5.3.1. Basic Approach 4482 A single RFC 822 message is generated from the incoming IP 4483 Message, Report, or IP Notification. All IPMS.BodyParts are 4484 mapped onto a single RFC 822 body. Other services are mapped 4485 onto RFC 822 header fields. Where there is no appropriate 4486 existing field, new fields are defined for IPMS, MTS and MTA 4487 services. 4489 The gateway mechanisms will correspond to MTS Delivery. As 4490 with submission, there are aspects where the MTA (transfer) 4491 services are also used. In particular, there is an optimisation 4492 to allow for multiple SMTP recipients. 4494 5.3.2. RFC 822 Settings 4496 An RFC 822 Message has a number of mandatory fields in the RFC 4497 822 Header. Some SMTP services mandate specification of an SMTP 4498 Originator. Even in cases where this is optional, it is usually 4499 desirable to specify a value. The following defaults are 4500 defined, which shall be used if the mappings specified do not 4501 derive a value: 4503 SMTP Originator 4504 If this is not generated by the mapping (e.g., for a 4505 Delivery Report), a value pointing at a gateway 4506 administrator shall be assigned. 4508 Date: 4509 A value will always be generated 4511 From: 4512 If this is not generated by the mapping, it is assigned 4514 RFC 1327bis 4515 MIXER DRAFT Version 2.6 4517 equal to the SMTP Originator. If this is gateway generated, 4518 an appropriate 822.phrase shall be added. 4520 At least one recipient field 4521 If no recipient fields are generated, a field "To: list:;", 4522 shall be added. 4524 This will ensure minimal RFC 822 compliance. When generating RFC 4525 822 headers, folding may be used. It is recommended to do this, 4526 following the guidelines of RFC 822. 4528 5.3.3. Basic Mappings 4530 5.3.3.1. Encoded Information Types 4532 This mapping from MTS.EncodedInformationTypes is needed in 4533 several disconnected places. EBNF is defined as follows: 4535 encoded-info = 1#encoded-type 4537 encoded-type = built-in-eit / object-identifier 4539 built-in-eit = "Undefined" ; undefined (0) 4540 / "Telex" ; tLX (1) 4541 / "IA5-Text" ; iA5Text (2) 4542 / "G3-Fax" ; g3Fax (3) 4543 / "TIF0" ; tIF0 (4) 4544 / "Teletex" ; tTX (5) 4545 / "Videotex" ; videotex (6) 4546 / "Voice" ; voice (7) 4547 / "SFD" ; sFD (8) 4548 / "TIF1" ; tIF1 (9) 4550 MTS.EncodedInformationTypes is mapped onto EBNF.encoded-info. 4551 MTS.EncodedInformationTypes.non-basic-parameters is ignored. 4552 Built in types are mapped onto fixed strings (compatible with 4553 X.400(1984) and RFC 987), and other types are mapped onto 4554 EBNF.object-identifier. 4556 5.3.3.2. Global Domain Identifier 4558 The following simple EBNF is used to represent 4559 MTS.GlobalDomainIdentifier: 4561 RFC 1327bis 4562 MIXER DRAFT Version 2.6 4564 global-id = std-or-address 4566 This is encoded using the std-or-address syntax, for the 4567 attributes within the Global Domain Identifier. 4569 5.3.4. Mappings from the IP Message 4571 Consider that an IPM has to be mapped to RFC 822. The IPMS.IPM 4572 comprises an IPMS.IPM.heading and IPMS.IPM.body. The heading is 4573 considered first. Some EBNF for new fields is defined: 4575 ipms-field = "Supersedes" ":" 1*msg-id 4576 / "Expires" ":" date-time 4577 / "Reply-By" ":" date-time 4578 / "Importance" ":" importance 4579 / "Sensitivity" ":" sensitivity 4580 / "Autoforwarded" ":" boolean 4581 / "Incomplete-Copy" ":" 4582 / "Content-Language" ":" 1#language 4583 / "Message-Type" ":" message-type 4584 / "Discarded-X400-IPMS-Extensions" ":" 1#object-identifier 4585 / "Autosubmitted" ":" autosubmitted 4587 importance = "low" / "normal" / "high" 4589 sensitivity = "Personal" / "Private" / 4590 "Company-Confidential" 4592 language = 2*ALPHA [ "(" language-description ")" ] 4593 language-description = printable-string 4595 message-type = "Delivery Report" 4596 / "InterPersonal Notification" 4597 / "Multiple Part" 4599 RFC 1327bis 4600 MIXER DRAFT Version 2.6 4602 autosubmitted = "not-auto-submitted" 4603 / "auto-generated" 4604 / "auto-replied" 4605 / "auto-forwarded" 4607 The mappings and actions for the IPMS.Heading are now specified 4608 for each element. Addresses and Message Identifiers are mapped 4609 according to Chapter 4. 4610 Other mappings are explained, or are straightforward 4611 (algorithmic). If a field with addresses contains zero elements, 4612 it shall be discarded, except for 4613 IPMS.Heading.blind-copy-recipients, which can be mapped onto BCC: 4614 (the only RFC 822 field which allows zero recipients). 4616 IPMS.Heading.this-IPM 4617 Mapped to "Message-ID:". 4619 IPMS.Heading.originator 4620 If IPMS.Heading.authorizing-users is present this is mapped 4621 to Sender:, if not to "From:". 4623 IPMS.Heading.authorizing-users 4624 Mapped to "From:". 4626 IPMS.Heading.primary-recipients 4627 Mapped to "To:". 4629 IPMS.Heading.copy-recipients 4630 Mapped to "Cc:". 4632 IPMS.Heading.blind-copy-recipients 4633 Mapped to "Bcc:". 4635 IPMS.Heading.replied-to-ipm 4636 Mapped to "In-Reply-To:". 4638 IPMS.Heading.obsoleted-IPMs 4639 Mapped to the extended RFC 822 field "Supersedes:". The 4640 replaces the RFC 1327 field "Obsoletes:". Reverse mapping 4641 of the RFC 1327 field may be supported. 4643 IPMS.Heading.related-IPMs 4644 Mapped to "References:". 4646 RFC 1327bis 4647 MIXER DRAFT Version 2.6 4649 IPMS.Heading.subject 4650 Mapped to "Subject:". The contents are converted to ASCII 4651 or T.61 (as defined in Section 3.5). CRLF will not be 4652 present in a valid X.400 field. Any CRLF present are not 4653 mapped, but are used as points at which the subject field 4654 shall be folded, unless an RFC 1522 encoding is used. 4656 IPMS.Heading.expiry-time 4657 Mapped to the extended RFC 822 field "Expires:". The 4658 replaces the RFC 1327 field "Expiry-Date:". Reverse 4659 mapping of the RFC 1327 field may be supported. 4661 IPMS.Heading.reply-time 4662 Mapped to the extended RFC 822 field "Reply-By:". 4664 IPMS.Heading.reply-recipients 4665 Mapped to "Reply-To:". 4667 IPMS.Heading.importance 4668 Mapped to the extended RFC 822 field "Importance:". 4670 IPMS.Heading.sensitivity 4671 Mapped to the extended RFC 822 field "Sensitivity:". 4673 IPMS.Heading.autoforwarded 4674 Mapped to the extended RFC 822 field "Autoforwarded:". 4676 The standard extensions (Annex H of X.420 / ISO 10021-7) are 4677 mapped as follows: 4679 incomplete-copy 4680 Mapped to the extended RFC 822 field "Incomplete-Copy:". 4682 language 4683 Mapped to the RFC 822 field "Content-Language:", defined in 4684 RFC 1766 [7]. This mapping may be made without loss of 4685 information. 4687 auto-submitted 4688 Map to the extended RFC 822 field "Autosubmitted:". 4690 If the RFC 822 extended header is found, this shall be 4691 mapped onto an RFC 822 header, as described in Section 5.1.2. 4693 RFC 1327bis 4694 MIXER DRAFT Version 2.6 4696 If a non-standard extension is found, it shall be discarded, 4697 unless the gateway understands the extension and can perform an 4698 appropriate mapping onto an RFC 822 header field. If extensions 4699 are discarded, the list is indicated in the extended RFC 822 4700 field "Discarded-X400-IPMS-Extensions:". 4702 5.3.4.1. Mapping the IPMS Body 4704 The mapping of the IPMS Body is defined in RFC 1494bis. 4706 5.3.4.2. Example Message 4708 An example message, illustrating a number of aspects is given 4709 below. 4711 RFC 1327bis 4712 MIXER DRAFT Version 2.6 4714 Received: from mhs-relay.ac.uk by bells.cs.ucl.ac.uk via JANET with NIFTP 4715 id <7906-0@bells.cs.ucl.ac.uk>; Thu, 30 May 1991 18:24:55 +0100 4716 X400-Received: by mta "mhs-relay.ac.uk" in /PRMD=uk.ac/ADMD= /C=gb/; Relayed; 4717 Thu, 30 May 1991 18:23:26 +0100 4718 X400-Received: by /PRMD=HMG/ADMD=GOLD 400/C=GB/; Relayed; 4719 Thu, 30 May 1991 18:20:27 +0100 4720 Message-Type: Multiple Part 4721 Date: Thu, 30 May 1991 18:20:27 +0100 4722 X400-Originator: Stephen.Harrison@gosip-uk.hmg.gold-400.gb 4723 X400-MTS-Identifier: 4724 [/PRMD=HMG/ADMD=GOLD 400/C=GB/;PC1000-910530172027-57D8] 4725 Original-Encoded-Information-Types: ia5 4726 X400-Content-Type: P2-1984 (2) 4727 X400-Content-Identifier: Email Problems 4728 From: Stephen.Harrison@gosip-uk.hmg.gold-400.gb (Tel +44 71 217 3487) 4729 Message-ID: 4730 To: Jim Craigie , 4731 Tony Bates , 4732 Steve Kille 4733 Subject: Email Problems 4734 Sender: Stephen.Harrison@gosip-uk.hmg.gold-400.gb 4735 MIME-Version: 1.0 4736 Content-Type: multipart/mixed; boundary=boundary-1 4738 --boundary-1 4739 Content-Type: text/plain; charset=US-ASCII 4741 Hope you gentlemen....... 4743 Regards, 4745 Stephen Harrison 4746 UK GOSIP Project 4748 ..... continued on next page 4750 RFC 1327bis 4751 MIXER DRAFT Version 2.6 4753 --boundary-1 4754 Content-Type: message/rfc822 4756 From: Urs Eppenberger 4757 Message-ID: 4758 <562*/S=Eppenberger/OU=verw/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS> 4759 To: "Stephen.Harrison" 4760 Cc: kimura@bsdarc.bsd.fc.nec.co.jp 4761 Subject: Response to Email link 4762 Content-Type: multipart/mixed; boundary=boundary-2 4764 --boundary-2 4766 Dear Mr Harrison...... 4768 --boundary-2-- 4770 --boundary-1-- 4772 5.3.5. Mappings from an IP Notification 4774 Because of the service setting, IP Notifications will not usually 4775 need to be mapped by a MIXER gateway. A message is generated, 4776 with the following fields: 4778 From: 4779 Set to the IPMS.IPN.ipn-originator. 4781 To: Set to the recipient from MTS.MessageSubmissionEnvelope. 4782 If there have been redirects, the original address shall be 4783 used. 4785 Subject: 4786 Set to the string "X.400 Inter-Personal Notification" for a 4787 receipt notification and to "X.400 Inter-Personal 4788 Notification (failure)" for a non-receipt notification. 4790 Message-Type: 4792 RFC 1327bis 4793 MIXER DRAFT Version 2.6 4795 Set to "InterPersonal Notification" 4797 References: 4798 Set to IPMS.IPN.subject-ipm 4800 Discarded-X400-IPMS-Extensions: 4801 Used for any discarded IPN extensions. 4803 The following EBNF is defined for the body of the Message. This 4804 format is defined to ensure that all information from an 4805 interpersonal notification is available to the end user in a 4806 uniform manner. 4808 RFC 1327bis 4809 MIXER DRAFT Version 2.6 4811 ipn-body-format = ipn-description 4812 [ ipn-extra-information ] 4813 [ ipn-content-return ] 4815 ipn-description = ipn-receipt / ipn-non-receipt 4817 ipn-receipt = "Your message to:" preferred-recipient 4818 "was received at" receipt-time 4819 "This notification was generated" 4820 acknowledgement-mode 4821 "The following extra information was given:" 4822 ipn-suppl 4824 ipn-non-receipt = "Your message to:" 4825 preferred-recipient 4826 ipn-reason 4828 ipn-reason = ipn-discarded / ipn-auto-forwarded 4830 ipn-discarded = "was discarded for the following reason:" 4831 discard-reason 4833 ipn-auto-forwarded = "was automatically forwarded." 4834 [ "The following comment was made:" 4835 auto-comment ] 4837 ipn-extra-information = 4838 "The following information types were converted:" 4839 encoded-info 4841 ipn-content-return = "The Original Message is not available" 4842 / "The Original Message follows:" 4844 preferred-recipient = mailbox 4845 receipt-time = date-time 4846 auto-comment = printablestring 4847 ipn-suppl = printablestring 4849 RFC 1327bis 4850 MIXER DRAFT Version 2.6 4852 discard-reason = "Expired" / "Obsoleted" / 4853 "User Subscription Terminated" / "IPM Deleted" 4855 acknowledgement-mode = "Manually" / "Automatically" 4857 The mappings for elements of the common fields of IPMS.IPN 4858 (IPMS.CommonFields) onto this structure and the message header 4859 are: 4861 subject-ipm 4862 Mapped to "References:" 4864 ipn-originator 4865 Mapped to "From:". 4867 ipn-preferred-recipient 4868 Mapped to EBNF.preferred-recipient 4870 conversion-eits 4871 Mapped to EBNF.encoded-info in EBNF.ipn-extra-information 4873 The mappings for elements of IPMS.IPN.non-receipt-fields 4874 (IPMS.NonReceiptFields) are: 4876 non-receipt-reason 4877 Used to select between EBNF.ipn-discarded and 4878 EBNF.ipn-auto-forwarded 4880 discard-reason 4881 Mapped to EBNF.discard-reason 4883 auto-forward-comment 4884 Mapped to EBNF.auto-comment 4886 returned-ipm 4887 This applies only to non-receipt notifications. 4888 EBNF.ipn-content-return shall always be omitted for receipt 4889 notifications, and always be present in non-receipt 4890 notifications. If present, the second option of 4891 EBNF.ipn-content-return is chosen, and the message is 4892 included. In this case, the message is formatted as 4893 multipart/mixed, and the returned message included as 4894 message/rfc822 after the text body part. Otherwise the first 4896 RFC 1327bis 4897 MIXER DRAFT Version 2.6 4899 option is chosen. 4901 The mappings for elements of IPMS.IPN.receipt-fields 4902 (IPMS.ReceiptFields) are: 4904 receipt-time 4905 Mapped to EBNF.receipt-time 4907 acknowledgement-mode 4908 Mapped to EBNF.acknowledgement-mode 4910 suppl-receipt-info 4911 Mapped to EBNF.ipn-suppl 4913 An example notification is: 4915 From: Steve Kille 4916 To: Julian Onions 4917 Subject: X.400 Inter-personal Notification 4918 Message-Type: InterPersonal Notification 4919 References: <1229.614418325@UK.AC.NOTT.CS> 4920 Date: Wed, 21 Jun 89 08:45:25 +0100 4922 Your message to: Steve Kille 4923 was automatically forwarded. 4924 The following comment was made: 4925 Sent on to a random destination 4927 The following information types were converted: g3fax 4929 5.3.6. Mappings from the MTS Abstract Service 4931 This section describes the MTS mappings for User Messages (IPM 4932 and IPN). This mapping is defined by specifying the mapping of 4933 MTS.MessageDeliveryEnvelope. The following extensions to RFC 822 4934 are defined to support this mapping: 4936 RFC 1327bis 4937 MIXER DRAFT Version 2.6 4939 mts-field = "X400-MTS-Identifier" ":" mts-msg-id 4940 / "X400-Originator" ":" mailbox 4941 / "X400-Recipients" ":" 1#mailbox 4942 / "Original-Encoded-Information-Types" ":" 4943 encoded-info 4944 / "X400-Content-Type" ":" mts-content-type 4945 / "X400-Content-Identifier" ":" printablestring 4946 / "Priority" ":" priority 4947 / "Originator-Return-Address" ":" 1#mailbox 4948 / "DL-Expansion-History" ":" mailbox ";" date-time ";" 4949 / "Conversion" ":" prohibition 4950 / "Conversion-With-Loss" ":" prohibition 4951 / "Delivery-Date" ":" date-time 4952 / "Discarded-X400-MTS-Extensions" ":" 4953 1#( object-identifier / labelled-integer ) 4955 prohibition = "Prohibited" / "Allowed" 4957 mts-msg-id = "[" global-id ";" *text "]" 4959 mts-content-type = "P2" / labelled-integer 4960 / object-identifier 4962 priority = "normal" / "non-urgent" / "urgent" 4964 The mappings for each element of MTS.MessageDeliveryEnvelope can 4965 now be considered. Where the specified action does not result in 4966 an extended element being mapped, the criticality associated with 4967 this element shall be considered. If the element is marked as 4968 critical for transfer or for delivery, the message shall be non 4969 delivered by the gateway because a critical extension cannot be 4970 correctly handled. 4972 MTS.MessageDeliveryEnvelope.message-delivery-identifier 4973 Mapped to the extended RFC 822 field "X400-MTS-Identifier:". 4975 MTS.MessageDeliveryEnvelope.message-delivery-time 4976 Discarded, as this time will be represented in an 4977 appropriate trace element. 4979 The mappings for elements of 4981 RFC 1327bis 4982 MIXER DRAFT Version 2.6 4984 MTS.MessageDeliveryEnvelope.other-fields 4985 (MTS.OtherMessageDeliveryFields) are: 4987 content-type 4988 Mapped to the extended RFC 822 field "X400-Content-Type:". 4989 The string "P2" is retained for backwards compatibility with 4990 RFC 987. This shall not be generated, and either the 4991 EBNF.labelled-integer or EBNF.object-identifier encoding 4992 used. 4994 originator-name 4995 Mapped to the SMTP originator, and to the extended RFC 822 4996 field "X400-Originator:". This is described in 4997 Section 4.6.2. 4999 original-encoded-information-types 5000 Mapped to the extended RFC 822 field 5001 "Original-Encoded-Information-Types:". 5003 priority 5004 Mapped to the extended RFC 822 field "Priority:". 5006 delivery-flags 5007 If the conversion-prohibited bit is set, add an extended RFC 5008 822 field "Conversion:". 5010 this-recipient-name and other-recipient-names 5011 The handling of these elements is described in 5012 Section 4.6.2. 5014 originally-intended-recipient-name 5015 The handling of this element is described in Section 4.6.2. 5017 converted-encoded-information-types 5018 Discarded. This information will be mapped in the trace. 5020 message-submission-time 5021 Mapped to Date:. 5023 content-identifier 5024 Mapped to the extended RFC 822 field 5025 "X400-Content-Identifier:". In RFC 1327, this was 5026 "Content-Identifier:". This has been changed to avoid 5027 confusion with MIME defined fields. Gateways which reverse 5029 RFC 1327bis 5030 MIXER DRAFT Version 2.6 5032 map, may support the old field. 5034 If any extensions 5035 (MTS.MessageDeliveryEnvelope.other-fields.extensions) are 5036 present, and they are marked as critical for transfer or 5037 delivery, then the message shall be rejected. The extensions 5038 (MTS.MessageDeliveryEnvelope.other-fields.extensions) are mapped 5039 as follows. 5041 conversion-with-loss-prohibited 5042 If set to 5043 MTS.ConversionWithLossProhibited.conversion-with-loss-prohibited, 5044 then add the extended RFC 822 field "Conversion-With-Loss:". 5046 requested-delivery-method 5047 Mapped to a comment, as described in Section 4.6.2.2. 5049 originator-return-address 5050 Mapped to the extended RFC 822 field 5051 "Originator-Return-Address:". 5053 physical-forwarding-address-request 5054 physical-delivery-modes 5055 registered-mail-type 5056 recipient-number-for-advice 5057 physical-rendition-attributes 5058 physical-delivery-report-request 5059 physical-forwarding-prohibited 5061 These elements are only appropriate for physical delivery. 5062 They are represented as comments in the "X400-Recipients:" 5063 field, as described in Section 4.6.2.2. 5065 originator-certificate 5066 message-token 5067 content-confidentiality-algorithm-identifier 5068 content-integrity-check 5069 message-origin-authentication-check 5070 message-security-label 5071 proof-of-delivery-request 5073 These elements imply use of security services not available 5074 in the RFC 822 environment. If they are marked as critical 5076 RFC 1327bis 5077 MIXER DRAFT Version 2.6 5079 for transfer or delivery, then the message shall be 5080 rejected. Otherwise they are discarded. 5082 redirection-history 5083 This is described in Section 4.6.2. 5085 dl-expansion-history 5086 Each element is mapped to an extended RFC 822 field 5087 "DL-Expansion-History:". These fileds shall be ordered in 5088 the message header, so that the most recent expansion comes 5089 first (same order as trace). 5091 If any MTS (or MTA) Extensions not specified in X.400 are 5092 present, and they are marked as critical for transfer or 5093 delivery, then the message shall be rejected. If they are not so 5094 marked, they can safely be discarded. The list of discarded 5095 fields shall be indicated in the extended header 5096 "Discarded-X400-MTS-Extensions:". 5098 5.3.7. Mappings from the MTA Abstract Service 5100 There are some mappings at the MTA Abstract Service level which 5101 are done for IPM and IPN. These can be derived from 5102 MTA.MessageTransferEnvelope. The reasons for the mappings at 5103 this level, and the violation of layering are: 5105 - Allowing for multiple recipients to share a single RFC 822 5106 message 5108 - Making the X.400 trace information available on the RFC 822 5109 side 5111 - Making any information on deferred delivery available 5113 The SMTP recipients are calculated from the full list of X.400 5114 recipients. This is all of the members of 5115 MTA.MessageTransferEnvelope.per-recipient-fields being passed 5116 through the gateway, where the responsibility bit is set. In 5117 some cases, a different RFC 822 message would be calculated for 5118 each recipient, due to differing service requests for each 5119 recipient. As discussed in 4.6.2.2, this specification allows 5120 either for multiple messages to be generated, or for the per- 5121 recipient information to be discarded. 5123 RFC 1327bis 5124 MIXER DRAFT Version 2.6 5126 The following EBNF is defined for extended RFC 822 headers: 5128 mta-field = "X400-Received" ":" x400-trace 5129 / "Deferred-Delivery" ":" date-time 5130 / "Latest-Delivery-Time" ":" date-time 5132 x400-trace = "by" md-and-mta ";" 5133 [ "deferred until" date-time ";" ] 5134 [ "converted" "(" encoded-info ")" ";" ] 5135 [ "attempted" md-or-mta ";" ] 5136 action-list 5137 ";" arrival-time 5139 md-and-mta = [ "mta" mta "in" ] global-id 5140 mta = word 5141 arrival-time = date-time 5143 md-or-mta = "MD" global-id 5144 / "MTA" mta 5146 Action-list = 1#action 5147 action = "Redirected" 5148 / "Expanded" 5149 / "Relayed" 5150 / "Rerouted" 5152 Note the EBNF.mta is encoded as 822.word. If the character 5153 set does not allow encoding as 822.atom, the 822.quoted-string 5154 encoding is used. 5156 If MTA.PerMessageTransferFields.deferred-delivery-time is 5157 present, it is used to generate a Deferred-Delivery: field. 5158 X.400 does not make this information available at the MTS level 5159 on delivery, because it requires that this service is provided by 5160 the first MTA. In the event that the first MTA does not provide 5161 this service, the function may optionally be implemented by the 5162 gateway: that is, the gateway may hold the message until the time 5164 RFC 1327bis 5165 MIXER DRAFT Version 2.6 5167 specified in the protocol element. Thus, the value of this 5168 element will usually be in the past. For this reason, the 5169 extended RFC 822 field is primarily for information. 5171 If MTA.PerMessageTransferFields.extensions.dl-expansion- 5172 prohibited is present and set to dl-expansion-probited, the 5173 gateway may reject that message on the basis that it is unable to 5174 control distribution list expansion beyond the gateway. The 5175 service relating to this is described in Section 2.3.1.2. This 5176 approach was not specified in RFC 1327. If it is found to be 5177 useful, it may be made mandatory in future versions of MIXER. 5179 If MTA.PerMessageTransferFields.extensions.recipient- 5180 reassignment-prohibited is present and set to 5181 recipeint-reassignment-probited, the gateway may reject that 5182 message on the basis that it is unable to control distribution 5183 list expansion beyond the gateway. The service relating to this 5184 is described in Section 2.3.1.2. This approach was not 5185 specified in RFC 1327. If it is found to be useful, it may be 5186 made mandatory in future versions of MIXER. 5188 Merge MTA.PerMessageTransferFields.trace-information, and 5189 MTA.PerMessageTransferFields.internal-trace-information to 5190 produce a single ordered trace list. If Internal trace from 5191 other management domains has not been stripped, this may require 5192 complex interleaving. Where an element of internal trace and 5193 external trace are identical, except for the MTA in the internal 5194 trace, only the internal trace element shall be presented. Use 5195 this to generate a sequence of "X400-Received:" fields. The only 5196 difference between external trace and internal trace will be the 5197 extra MTA information in internal trace elements. 5199 When generating an RFC 822 message all trace fields (X400- 5200 Received and Received) shall be at the beginning of the header, 5201 before any other fields. Trace shall be in chronological order, 5202 with the most recent element at the front of the message. This 5203 ordering is determined from the order of the fields, not from 5204 timestamps in the trace, as there is no guarantee of clock 5205 synchronisation. A simple example trace (external) is: 5207 X400-Received: by /PRMD=UK.AC/ADMD=Gold 400/C=GB/ ; Relayed ; 5208 Tue, 20 Jun 89 19:25:11 +0100 5210 A more complex example (internal): 5212 RFC 1327bis 5213 MIXER DRAFT Version 2.6 5215 X400-Received: by mta "UK.AC.UCL.CS" in /PRMD=UK.AC/ADMD=Gold 400/C=GB/ ; 5216 deferred until Tue, 20 Jun 89 14:24:22 +0100 ; 5217 converted (undefined, g3fax) ; attempted MD /ADMD=Foo/C=GB/ ; 5218 Relayed, Expanded, Redirected ; Tue, 20 Jun 89 19:25:11 +0100 5220 The gateway itself shall add a single line of trace 5221 information, indicating MIXER conversion by use of a comment. 5222 For example: 5224 Received: from isode.com by isode.com 5225 (MIXER Conversion following RFC 1327); 5226 Thu, 2 Jan 1997 14:46:03 +0000 5228 If SMTP is being used, Appendix A shall also be followed, 5229 which includes optional mappings to extension parameters. 5231 5.3.8. Mappings from Report Delivery 5233 Delivery reports are mapped at the MTS service level. This means 5234 that only reports destined for the MTS user will be mapped. Some 5235 additional services are also taken from the MTA service. X.400 5236 Delivery Reports are Mapped onto Delivery Status Notifications, 5237 as defined by NOTARY [28]. 5239 5.3.8.1. MTS Mappings 5241 A Delivery Report service will be represented as 5242 MTS.ReportDeliveryEnvelope, which comprises of per-report-fields 5243 (MTS.PerReportDeliveryFields) and per-recipient-fields. 5245 The enclosing message is a MIME message of content type 5246 multipart/report, with report-type=delivery-status, which is 5247 generated with the following fields: 5249 From: 5250 An administrator at the gateway system. 5252 To: A mapping of the 5253 MTA.ReportTransferEnvelope.report-destination-name. This is 5254 also the SMTP recipient. 5256 RFC 1327bis 5257 MIXER DRAFT Version 2.6 5259 Message-Type: 5260 Set to "Delivery Report". This is strictly redundant, but 5261 retained for backwards compatibility with RFC 1327. 5263 Subject: 5264 The EBNF for the subject line is: 5266 subject-line = "Delivery-Report" "(" status ")" 5267 [ "for" destination ] 5269 status = "success" / "failure" / "success and failures" 5271 destination = mailbox / "MTA" word 5273 The subject is intended to give a clear indication as to the 5274 nature of the message, and summarise its contents. EBNF.status is 5275 set according to whether the recipients reported on are all 5276 successes, all failures, or a mixture. It is common for a report 5277 to reference a single recipient, in which case a subject line 5278 giving using all of the options of EBNF.status can be used. This 5279 gives useful information to the recipient. Where information 5280 varies between reported recpients, the options cannot be used. 5281 The EBNF.destination is used to indicate the addresses in the 5282 reports. If the report is for a single address, EBNF.mailbox is 5283 used to give the RFC 822 representation of the address. If all 5284 of the reported recpients reference the same MTA this is included 5285 in EBNF.word. The MTA is determined from the delivery report's 5286 trace. 5288 The format of the body of the message follows the NOTARY 5289 delivery status notification format, and is defined to ensure 5290 that all information is conveyed to the RFC 822 user in a 5291 consistent manner. The format is structured as if it was a 5292 message coming from the gateway, with three body parts. The first 5293 body part is ASCII text structured as follows: 5295 1. A few lines giving keywords to indicate the original 5296 message. 5298 2. A human summary of the status of each recipient being 5299 reported on. 5301 RFC 1327bis 5302 MIXER DRAFT Version 2.6 5304 The second (mandatory) body part is the NOTARY delivery 5305 status notification, which contains detailed information 5306 extracted from the report. This information may be critical to 5307 diagnosing an obscure problem. 5309 The third (optional) body part contains the returned message 5310 (return of content). This structure is useful to the RFC 822 5311 recipient, as it enables the original message to be extracted. 5312 For negative reports it shall be included if the original message 5313 is available. For positive reports headers from the message 5314 shall be included if the original message is available. 5316 The first body part containing the user oriented description 5317 is of type text/plain. The format of this body part is defined 5318 below as EBNF.dr-user-info. 5320 RFC 1327bis 5321 MIXER DRAFT Version 2.6 5323 dr-user-info = dr-summary 5324 dr-recipients 5325 dr-content-return 5327 dr-content-return = "The Original Message is not available" 5328 / "The Original Message follows:" 5330 dr-summary = "This report relates to your message:" 5331 content-correlator 5332 "of" date-time 5334 dr-recipients = *(dr-recipient ) 5336 dr-recipient = dr-recip-success / dr-recip-failure 5338 dr-recip-success = 5339 "Your message was successfully delivered to:" 5340 mailbox "at" date-time 5342 dr-recip-failure = "Your message was not delivered to:" 5343 mailbox 5344 "for the following reason:" *word 5346 report-point = [ "mta" mta-name "in" ] global-id 5347 content-correlator = *word 5348 mta-name = word 5350 EBNF.dr-summary 5351 The EBNF.content-correlator is taken from the content 5352 correlator (or content identifier if there is no content 5353 correlator) and the EBNF.date-time from the trace, as 5354 described in Section 5.3.8.3. LWSP may be added to improve 5355 the layout of the body part. 5357 EBNF.dr-recipients 5358 There is an element for each recipient in the delivery 5359 report. In each case, EBNF.mailbox is taken from the RFC 5360 822 form of the originally specified recipient, which is 5361 taken from the originally specified recipient element if 5363 RFC 1327bis 5364 MIXER DRAFT Version 2.6 5366 present or from the actual recipient. When reporting 5367 success, the message delivery time is used to derive 5368 EBNF.date-time. When reporting failure, the information 5369 includes a human readable interpretation of the X.400 5370 diagnostic and reason codes, and the supplementary 5371 information. 5373 EBNF.dr-content-return 5374 This is set according to whether or not the content is being 5375 returned. 5377 The EBNF of this body part is designed for english-speaking 5378 users. The language of the strings in the EBNF may be altered. 5380 The EBNF used in the delivery status notification is: 5382 dr-per-message-fields = 5383 / "X400-Conversion-Date" ":" date-time 5384 / "X400-Subject-Submision-Identifier" ":" 5385 mts-msg-id 5386 / "X400-Content-Identifier" ":" printablestring 5387 / "X400-Content-Type" ":" mts-content-type 5388 / "X400-Original-Encoded-Information-Types" ":" 5389 encoded-info 5390 / "X400-Originator-and-DL-Expansion-History" ":" 5391 mailbox ";" date-time ";" 5392 / "X400-Reporting-DL-Name" ":" mailbox 5393 / "X400-Content-Correlator" ":" content-correlator 5394 / "X400-Recipient-Info" ":" recipient-info 5395 / "X400-Subject-Intermediate-Trace-Information" ":" 5396 x400-trace 5397 / dr-extensions 5399 RFC 1327bis 5400 MIXER DRAFT Version 2.6 5402 dr-per-recipient-fields = 5403 / "X400-Redirect-Recipient" ":" "x400" ";" std-or 5404 / "X400-Mapped-Redirect-Recipient" ":" "rfc822" ";" mailbox 5405 / "X400-Converted-EITs" ":" encoded-info ";" 5406 / "X400-Delivery-Time" ":" date-time 5407 / "X400-Type-of-MTS-User" ":" labelled-integer 5408 / "X400-Last-Trace" ":" [ encoded-info ] date-time 5409 / "X400-Supplementary-Info" ":" 5410 <"> printablestring <"> ";" 5411 / "X400-Redirection-History" ":" redirect-history-item 5412 / "X400-Physical-Forwarding-Address" ":" mailbox 5413 / "X400-Originally-Specified-Recipient-Number" ":" 5414 integer 5415 / dr-extensions 5417 dr-extensions = "X400-Discarded-DR-Extensions" ":" 5418 1# (object-identifier / labelled-integer) 5420 dr-diagnostic = "Reason" labelled-integer-2 5421 [ ";" "Diagnostic" labelled-integer-2 ] 5423 A body part of type delivery status, as defined by NOTARY, is 5424 generated. MIXER extends this delivery status notification (DSN) 5425 specification, by defining additional per message fields in 5426 EBNF.dr-per-message-fields and additional per recipient fields in 5427 EBNF.dr-per-recipient-fields. These are used as extensions to 5428 DSN.per-message-fields and DSN.per-recipient-fields. MIXER also 5429 defines a new NOTARY address type "x400", with encoding of 5430 EBNF.std-or. A directory name may be inluded as an RFC 822 5431 comment. 5433 The following DSN.per-message-fields are always generated: 5435 DSN.reporting-mta-field 5436 The DSN.mta-name-type is set to "x400", and this string is 5437 reserved by MIXER. The DSN.mta-name has its syntax 5438 specified by EBNF.report-point, with the information derived 5439 from the first element of the DR's trace. 5441 DSN.arrival-date-field 5442 This is derived from the date of the 5444 RFC 1327bis 5445 MIXER DRAFT Version 2.6 5447 MTA.PerRecipientReportTransferFields.last-trace-info.arrival-time 5448 of the first recipient in the report. 5450 The following two EBNF.per-message-fields are generated by 5451 the MIXER gateway: 5453 DSN.dsn-gateway-field 5454 The type is set to "dns" and the domain set to the local 5455 domain of the gateway. 5457 X400-Conversion-Date: 5458 The EBNF.date-time is set to the time of the MIXER 5459 conversion. 5461 The elements of MTS.ReportDeliveryEnvelope.per-report-fields 5462 are mapped as follows onto the DSN per message fields as follows: 5464 subject-submission-identifier 5465 Mapped to DSN.original-envelope-id-field. The encoding of 5466 this MTS Identifier follows the format EBNF.mts-msg-id. 5468 content-identifier 5469 Mapped to X400-Content-Identifier: 5471 content-type 5472 Mapped to X400-Content-Type: 5474 original-encoded-information-types 5475 Mapped to X400-Encoded-Info: 5477 The extensions from 5478 MTS.ReportDeliveryEnvelope.per-report-fields.extensions are 5479 mapped as follows: 5481 originator-and-DL-expansion-history 5482 Each element is mapped to an 5483 "X400-Originator-and-DL-Expansion-History:" They shall be 5484 ordered so that the most recent expansion comes first in the 5485 header (same order as trace). 5487 reporting-DL-name 5488 Mapped to X400-Reporting-DL-Name: 5490 content-correlator 5492 RFC 1327bis 5493 MIXER DRAFT Version 2.6 5495 If the content correlator starts with the string 5496 "SMTP/NOTARY ENVID: ", then the remainder of the content 5497 correlator is mapped to the DSN original-envelope-id field. 5498 If this is not the case, the content correlator is mapped to 5499 X400-Content-Correlator:, provided that the encoding is 5500 IA5String (this will always be the case). 5502 message-security-label 5503 reporting-MTA-certificate 5504 report-origin-authentication-check 5506 These security parameters will not be present unless there 5507 is an error in a remote MTA. If they are present, they 5508 shall be discarded in preference to discarding the whole 5509 report. They shall be listed in the X400-Discarded-DR- 5510 Extensions: field. 5512 If there are any other DR extensions, they shall also be 5513 discarded and listed in the X400-Discarded-DR-Extensions: field. 5515 For each element of 5516 MTS.ReportDeliveryEnvelope.per-recipient-fields, a set of 5517 DSN.per-recipient-fields is generated. The fields are filled in 5518 as follows: 5520 actual-recipient-name 5521 If originally-intended-recipient-name is not present, 5522 generate a DSN.original-recipient-field fields, with 5523 DSN.address-type of "rfc822", and with an RFC 822 mailbox 5524 generated from the address encoded as specified by NOTARY. 5525 Also generate a DSN.final-recipient-field field, which holds 5526 the X.400 representation of the same address. If the 5527 directory name is present, it shall be added as a trailing 5528 comment in the X.400 form. 5530 If originally-intended-recipient-name is present, generate 5531 an "X400-Mapped-Redirect-Recipient:" field, with 5532 DSN.address-type of "rfc822", and with an RFC 822 mailbox 5533 generated from the address encoded as specified by NOTARY. 5534 Also generate an "X400-Redirect-Recipient:" field, which 5535 holds the X.400 representation of the same address. If the 5536 directory name is present, it shall be added as a trailing 5537 comment in the X.400 form. 5539 RFC 1327bis 5540 MIXER DRAFT Version 2.6 5542 report 5543 If it is MTS.Report.delivery, then set DSN.action-field to 5544 "delivered", and set "X400-Delivery-Time:" and 5545 "X400-Type-of-MTS-User:" from the information in the report. 5546 DSN.status field is set to "2.0.0". 5548 If it is MTS.Report.non-delivery, then set DSN.action-field 5549 to "failed". DSN.diagnostic-code-field is encoded 5550 according to the syntax EBNF.dr-diagnostic, with the 5551 labelled integers set from the reason and diagnostic codes. 5552 DSN.status-field is derived from the reason and diagnostic 5553 codes, as described below. 5555 converted-encoded-information-types 5556 Set X400-Converted-EITs: 5558 originally-intended-recipient 5559 Generate a DSN.final-recipient-field field, with 5560 DSN.address-type of "rfc822", and with an RFC 822 mailbox 5561 generated from the address encoded as specified by NOTARY. 5562 Also generate a DSN.original-recipient-field field, which 5563 holds the X.400 representation of the same address. If the 5564 directory name is present, it shall be added as a trailing 5565 comment in the X.400 form. 5567 supplementary-info 5568 Set X400-Supplementary-Info: 5570 redirection-history 5571 Generate an "X400-Redirection-History:" field for each 5572 redirect history element. The fields are ordered with the 5573 earliest redirect first. 5575 physical-forwarding-address 5576 Set X400-Physical-Forwarding-Address as a mailbox, with 5577 directory name in comment if present. 5579 recipient-certificate 5580 Discard 5582 proof-of-delivery 5583 Discard 5585 Any unknown extensions shall be discarded, irrespective of 5587 RFC 1327bis 5588 MIXER DRAFT Version 2.6 5590 criticality. All discarded extensions shall be included in a 5591 "X400-Discarded-DR-Extensions:" field. 5593 The number from the 5594 MTA.PerRecipientReportTransferFields.originally-specified-recipient-number 5595 shall be mapped to "X400-Originally-Specified-Recipient-Number:", 5596 in order to facilitate reverse mapping of delivery reports. 5598 The original message shall be included in the delivery 5599 status notification if it is available. The original message will 5600 usually be available at the gateway, as discussed in Section 5.2. 5601 If the original message is available, but is not a legal message 5602 format, a dump of the ASN.1 may be included, encoded as 5603 application/octet-string. This is recommended, but not required. 5605 Where the original message is included, it shall be encoded 5606 according to the MIME specifications as content type 5607 message/rfc822. 5609 5.3.8.2. Status Code Mappings 5611 This section defines the mappings from X.400 diagnostic and 5612 status codes to the NOTARY Status field. 5614 C/D X400 meaning DSN code Means 5616 0/Any Transfer failure (may be temporary) 4.4.0 Other net/route 5617 1/Any Unable to transfer 5.0.0 Other, unknown 5618 2/Any Conversion not performed 5.6.3 Conv not supported 5619 3/Any Physical rendition not performed 5.6.0 Other media error 5620 4/Any Physical delivery not performed 5.1.0 Other address status 5621 5/Any Restricted delivery 5.7.1 5622 6/Any Directory operation unsuccessful 5.4.3 Routing server failure 5623 7/Any Deferred delivery not performed 5.3.3 Not capable 5625 RFC 1327bis 5626 MIXER DRAFT Version 2.6 5628 1/0 Unrecognized OR name 5.1.1 5629 1/1 Ambiguous OR name 5.1.4 5630 1/2 MTS congestion 4.3.1 5631 1/3 Loop detected 5.4.6 5632 1/4 Recipient unavailable 4.2.1 5633 1/5 Delivery time expired 4.4.7 5634 1/6 Encoded information types unsupported 5.6.1 Media unsupp. 5635 1/7 Content too long 5.2.3 5636 2/8 Conversion impractical 5.6.3 5637 2/9 Conversion prohibited 5.6.3 5638 1/10 Implicit conversion not subscribed 5.6.3 5639 1/11 Invalid arguments 5.5.2 5640 1/12 Content syntax error 5.5.2 5641 1/13 Size constraint violation 5.5.2 5642 1/14 Protocol violation 5.5.0 5643 1/15 Content type not supported 5.6.1 Media unsupp. 5644 1/16 Too many recipients 5.5.3 5645 1/17 No bilateral agreement 5.4.4 5646 1/18 Unsupported critical function 5.3.3 System not capable 5647 2/19 Conversion with loss prohibited 5.6.2 5648 2/20 Line too long 5.6.0 5649 2/21 Page split 5.6.0 5650 2/22 Pictorial symbol loss 5.6.2 5651 2/23 Punctuation symbol loss 5.6.2 5652 2/24 Alphabetic character loss 5.6.2 5653 2/25 Multiple information loss 5.6.2 5654 1/26 Recipient reassignment prohibited 5.4.0 Undefined net/route 5655 1/27 Redirection loop detected 5.4.6 5656 1/28 DL expansion prohibited 5.7.2 5657 1/29 No DL submit permission 5.7.1 Delivery not authorized 5658 1/30 DL expansion failure 4.2.4 5659 4/31 Physical rendition attrs not supported 5.6.0 Undefined media error 5660 4/32-45 Various physical mail stuff 5.1.0 Other address status 5661 1/43 New address unknown 5.1.6 Destination mbox moved 5662 1/46 Secure messaging error 5.7.0 Other security status 5663 2/47 Unable to downgrade 5.3.3 System not capable 5664 0/48 Unable to complete transfer 5.3.4 Message too big 5665 0/49 Transfer attempts limit reached 4.4.7 Delivery time expired 5667 5.3.8.3. MTA Mappings 5669 The single SMTP recipient is constructed from 5671 RFC 1327bis 5672 MIXER DRAFT Version 2.6 5674 MTA.ReportTransferEnvelope.report-destination-name, using the 5675 mappings of Chapter 4. Unlike with a user message, this 5676 information is not available at the MTS level. 5678 The following additional mappings are made, which results in 5679 fields in the outer header of the DSN. 5681 MTA.ReportTransferEnvelope.report-destination-name 5682 This is used to generate the To: field. 5684 MTA.ReportTransferEnvelope.identifier 5685 Mapped to the extended RFC 822 field "X400-MTS-Identifier:". 5686 It may also be used to derive a "Message-Id:" field. 5688 MTA.ReportTransferEnvelope.trace-information 5689 and 5690 MTA.ReportTransferEnvelope.internal-trace-information 5692 Mapped onto the extended RFC 822 field "X400-Received:", as 5693 described in Section 5.3.7. Date: is generated from the 5694 first element of trace. 5696 The following additional mappings are made, which result in per 5697 message fields in the DSN body part: 5699 MTA.PerRecipientReportTransferFields.last-trace-information 5700 Mapped to X400-Last-Trace:". 5702 MTA.PerReportTransferFields.subject-intermediate-trace- 5703 information Mapped to 5704 "X400-Subject-Intermediate-Trace-Information:". These fields 5705 are ordered so that the most recent trace element comes 5706 first. 5708 5.3.8.4. Example Delivery Reports 5710 This section contains sample delivery reports. These are the 5711 same examples used in RFC 1327, and so they also illustrate the 5712 changes between RFC 1327 and this document. Example Delivery 5713 Report 1: 5715 RFC 1327bis 5716 MIXER DRAFT Version 2.6 5718 Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk 5719 via Delivery Reports Channel id <27699-0@bells.cs.ucl.ac.uk>; 5720 Thu, 7 Feb 1991 15:48:39 +0000 5721 From: UCL-CS MTA 5722 To: S.Kille@cs.ucl.ac.uk 5723 Subject: Delivery Report (failure) for H.Hildegard@bbn.com 5724 Message-Type: Delivery Report 5725 Date: Thu, 7 Feb 1991 15:48:39 +0000 5726 Message-ID: <"bells.cs.u.694:07.01.91.15.48.34"@cs.ucl.ac.uk> 5727 X400-Content-Identifier: Greetings. 5728 MIME-Version: 1.0 5729 Content-Type: multipart/report; report-type=delivery-status; 5730 boundary=boundary-1 5732 --boundary-1 5734 This report relates to your message: 5735 Greetings. 5737 of Thu, 7 Feb 1991 15:48:20 +0000 5739 Your message was not delivered to 5740 H.Hildegard@bbn.com for the following reason: 5741 Bad Address 5742 MTA 'bbn.com' gives error message (USER) Unknown user name in 5743 "H.Hildegard@bbn.com" 5745 The Original Message follows: 5747 --boundary-1 5748 content-type: message/delivery-status 5750 RFC 1327bis 5751 MIXER DRAFT Version 2.6 5753 Reporting-MTA: x400; bells.cs.ucl.ac.uk in /PRMD=uk.ac/ADMD=gold 400/C=gb/ 5754 Arrival-Date: Thu, 7 Feb 1991 15:48:34 +0000 5755 DSN-Gateway: dns; bells.cs.ucl.ac.uk 5756 X400-Conversion-Date: Thu, 7 Feb 1991 15:48:40 +0000 5757 Original-Envelope-Id: 5758 [/PRMD=uk.ac/ADMD=gold 400/C=gb/;<1803.665941698@UK.AC.UCL.CS>] 5759 X400-Content-Identifier: Greetings. 5760 X400-Subject-Intermediate-Trace-Information: /PRMD=uk.ac/ADMD=gold 400/C=gb/; 5761 arrival Thu, 7 Feb 1991 15:48:20 +0000 action Relayed 5762 X400-Subject-Intermediate-Trace-Information: /PRMD=uk.ac/ADMD=gold 400/C=gb/; 5763 arrival Thu, 7 Feb 1991 15:48:18 +0000 action Relayed 5765 Original-Recipient: rfc822; H.Hildegard@bbn.com 5766 Final-Recipient: x400; 5767 /RFC-822=H.Hildegard(a)bbn.com/OU=cs/O=ucl/PRMD=uk.ac/ADMD=gold 400/C=gb/; 5768 Action: failure 5769 Status: 5.1.1 5770 Diagnostic-Code: x400; Reason 1 (Unable-To-Transfer); 5771 Diagnostic 0 (Unrecognised-ORName) 5772 X400-Last-Trace: (ia5) Thu, 7 Feb 1991 15:48:18 +0000; 5773 X400-Originally-Specified-Recipient-Number: 1 5774 X400-Supplementary-Info: "MTA 'bbn.com' gives error message (USER) 5775 Unknown user name in "H.Hildegard@bbn.com""; 5777 RFC 1327bis 5778 MIXER DRAFT Version 2.6 5780 --boundary-1 5781 Content-Type: message/rfc822 5783 Received: from glenlivet.cs.ucl.ac.uk by bells.cs.ucl.ac.uk 5784 with SMTP inbound id <27689-0@bells.cs.ucl.ac.uk>; 5785 Thu, 7 Feb 1991 15:48:21 +0000 5786 To: H.Hildegard@bbn.com 5787 Subject: Greetings. 5788 Phone: +44-71-380-7294 5789 Date: Thu, 07 Feb 91 15:48:18 +0000 5790 Message-ID: <1803.665941698@UK.AC.UCL.CS> 5791 From: Steve Kille 5793 Steve 5795 --boundary-1-- 5797 RFC 1327bis 5798 MIXER DRAFT Version 2.6 5800 Example Delivery Report 2: 5802 Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk 5803 via Delivery Reports Channel id <27718-0@bells.cs.ucl.ac.uk>; 5804 Thu, 7 Feb 1991 15:49:11 +0000 5805 X400-Received: by mta "bells.cs.ucl.ac.uk" in /PRMD=uk.ac/ADMD=gold 400/C=gb/; 5806 Relayed; Thu, 7 Feb 1991 15:49:08 +0000 5807 X400-Received: by /PRMD=DGC/ADMD=GOLD 400/C=GB/; Relayed; 5808 Thu, 7 Feb 1991 15:48:40 +0000 5809 From: UCL-CS MTA 5810 To: S.Kille@cs.ucl.ac.uk 5811 Subject: Delivery Report (failure) for 5812 j.nosuchuser@dle.cambridge.DGC.gold-400.gb 5813 Message-Type: Delivery Report 5814 Date: Thu, 7 Feb 1991 15:46:11 +0000 5815 Message-ID: <"DLE/910207154840Z/000"@cs.ucl.ac.uk> 5816 X400-Content-Identifier: A useful mess... 5817 MIME-Version: 1.0 5818 Content-Type: multipart/report; report-type=delivery-status; 5819 boundary=boundary-1 5821 --boundary-1 5823 This report relates to your message: 5824 A useful mess... 5826 of Thu, 7 Feb 1991 15:43:20 +0000 5828 Your message was not delivered to 5829 j.nosuchuser@dle.cambridge.DGC.gold-400.gb 5830 for the following reason: 5831 Bad Address 5832 DG 21187: (CEO POA) Unknown addressee. 5834 The Original Message is not available 5836 RFC 1327bis 5837 MIXER DRAFT Version 2.6 5839 --boundary-1 5840 content-type: message/delivery-status 5842 Reporting-MTA: x400; /PRMD=DGC/ADMD=GOLD 400/C=GB/ 5843 Arrival-Date: Thu, 7 Feb 1991 15:48:40 +0000 5844 DSN-Gateway: dns; bells.cs.ucl.ac.uk 5845 X400-Conversion-Date: Thu, 7 Feb 1991 15:49:12 +0000 5846 Original-Envelope-Id: 5847 [/PRMD=uk.ac/ADMD=gold 400/C=gb/;<1796.665941626@UK.AC.UCL.CS>] 5848 X400-Content-Identifier: A useful mess... 5850 Original-Recipient: rfc822; j.nosuchuser@dle.cambridge.DGC.gold-400.gb 5851 Final-Recipient: x400; 5852 /I=j/S=nosuchuser/OU=dle/O=cambridge/PRMD=DGC/ADMD=GOLD 400/C=GB/ 5853 Action: failure 5854 Status: 5.1.1 5855 Diagnostic-Code: x400; Reason 1 (Unable-To-Transfer); 5856 Diagnostic 0 (Unrecognised-ORName) 5857 X400-Supplementary-Info: "DG 21187: (CEO POA) Unknown addressee." 5858 X400-Originally-Specified-Recipient-Number: 1 5860 --boundary-1-- 5862 5.3.9. Probe 5864 This is an MTS internal issue. Any probe shall be serviced by 5865 the gateway, as there is no equivalent RFC 822 functionality. 5866 The value of the reply is dependent on whether the gateway could 5867 service an MTS Message with the values specified in the probe. 5868 The reply shall make use of MTS.SupplementaryInformation to 5869 indicate that the probe was serviced by the gateway. 5871 RFC 1327bis 5872 MIXER DRAFT Version 2.6 5874 Appendix A - Mappings Specific to SMTP 5876 This Appendix is specific to the Simple Mail Transfer Protocol 5877 (RFC 821). It describes specific changes in the context of this 5878 protocol. When MIXER is used with SMTP, conformance to this 5879 appendix is mandatory. 5881 1. Probes 5883 When servicing a probe, as described in section 5.3.9, use may be 5884 made of the SMTP VRFY command to increase the accuracy of 5885 information contained in the delivery report. 5887 2. Long Lines 5889 SMTP is a text oriented protocol, and is required to support a 5890 line length of at least 1000 characters. Some implementations 5891 do not support line lengths greater than 1000 characters. This 5892 can cause problems. Where body parts have long lines, it is 5893 recommended to use a MIME encoding that folds lines (quoted 5894 printable). 5896 3. SMTP Extensions 5898 There are several RFCs that specify extensions to SMTP. Most of 5899 these are not relevant to MIXER. The NOTARY work to support 5900 delivery report defines extensions which are relevant [29]. Use 5901 of these extensions by a MIXER gateway is optional. If these 5902 extensions are used, they shall be used in the manner described 5903 below. 5905 3.1. SMTP Extension mapping to X.400 5907 Mappings are defined for the following extensions: 5909 NOTIFY 5910 This is used to set the report and non-delivery bits of 5911 MTA.PerRecipientMessageTransferFields.per-recipient-indicators. 5912 If the value is NEVER, both bits are zero. If SUCCESS is 5913 present, the report bit is set. Otherwise, the non- 5914 delivery-report bit is set. If the gateway uses the NOTIFY 5915 command, it shall perform this mapping in all cases. 5917 RFC 1327bis 5918 MIXER DRAFT Version 2.6 5920 ORCPT 5921 If the address type of the original recipient is "x400" or 5922 "rfc822", this may be used at the MTS level, to generate an 5923 element of redirection history, with the redirection date 5924 being the date of conversion and the reason set to "alias". 5926 ENVID 5927 If present, this may be used to generate a content 5928 correlator. This is used rather than the MTS Identifier, 5929 as the ENVID is unique for the UA only and is likely to be 5930 too large to map to an MTS identifier. The content 5931 correlator is encoded as an IA5 String containing the ENVID 5932 and prefixed by the string: 5934 "SMTP/NOTARY ENVID: " 5936 If the ENVID starts with the string "X400-MTS-Identifier: ", 5937 then this ENVID was generated from an X.400 MTS Identifier. 5938 The reverse mapping defined in Section 3.2 of Appendix A 5939 shall not be used, as this may cause problems in certain 5940 situations (e.g., where the message was expanded by an 5941 Internet mailing list). 5943 3.2. X.400 Mapping to SMTP Extensions 5945 The following extensions may be used as a part of the MIXER 5946 mapping: 5948 NOTIFY 5949 The originator-report and originator-non-delivery-report 5950 bits of 5951 MTA.PerRecipientMessageTransferFields.per-recipient-indicators 5952 determine how this is used. If both bits are zero, the 5953 parameter is NEVER. If the report bit is set, SUCCESS is 5954 used. Otherwise, FAILURE is used. If this is done, the 5955 gateway shall not generate a delivery report for this 5956 recipient, unless this is needed in the case where the 5957 originating MTA service report requirements differ from the 5958 user requirements. Additional originating MTA 5959 requrirements are satisfied by the gateway. 5961 ORCPT 5962 If the 5963 MTS.perRecipientDeliveryFields.originally-intended-recipient-name 5965 RFC 1327bis 5966 MIXER DRAFT Version 2.6 5968 is present, the ORCPT command may be used to carry this 5969 value, using the "x400" syntax. 5971 ENVID 5972 This may be generated, with the value taken from the 5973 MTS.MessageDeliveryEnvelope.message-delivery-identifer. If 5974 this is done, it shall be encoded as EBNF.mts-msg-id, 5975 preceded by the string "X400-MTS-Identifier: ". 5977 RET 5978 If 5979 MTA.PerMessageTransferFields.per-message-indicators.content-return-request 5980 is set to FALSE, the parameter RET may be set to HDRS, to 5981 specify return of headers only. 5983 RFC 1327bis 5984 MIXER DRAFT Version 2.6 5986 Appendix B - Mapping with X.400(1984) 5988 This appendix defines modifications to the mapping for use with 5989 X.400(1984). 5991 The X.400(1984) protocols are a proper subset of 5992 X.400(1988). When mapping from X.400(1984) to RFC 822, no 5993 changes to this specification are needed. 5995 When mapping from RFC 822 to X.400(1984), no use can be made 5996 of 1988 specific features. No use of such features is made at 5997 the MTS level. The heading extension feature is used at the IPMS 5998 level, and this shall be replaced by the RFC 987 approach. All 5999 header information which would usually be mapped into the 6000 rfc-822-heading-list extension is mapped into a single IA5 body 6001 part, which is the first body part in the message. This body 6002 part will start with the string "RFC-822-Headers:" as the first 6003 line. The headers then follow this line. This specification 6004 requires correct reverse mapping of this format, either from 1988 6005 or 1984. RFC 822 extended headers which could be mapped into 6006 X.400(1988) elements, are also mapped to the body part. 6008 In an environment where RFC 822 is of major importance, it 6009 may be desirable for downgrading to consider the case where the 6010 message was originated in an RFC 822 system, and mapped according 6011 to this specification. The rfc-822-heading-list extension may be 6012 mapped according to this appendix. 6014 When parsing std-or, the following restrictions shall be 6015 observed: 6017 - Only the 84/88 attributes identified in the table in 6018 Section 4.2 are present. 6020 - No teletex encoding is allowed. 6022 If an address violates this, it shall be treated as an RFC 822 6023 address, which will usually lead to encoding as a DDA "RFC-822". 6025 It is possible that attributes of zero length may be present 6026 in an OR Address. This is not legal in 1988, except for ADMD 6027 where the case is explicitly described in Section 4.3.5. 6028 Attributes of zero length are deprecated (the attribute shall be 6030 RFC 1327bis 6031 MIXER DRAFT Version 2.6 6033 omitted), and will therefore be unusual. However, some systems 6034 generate them and rely on them. Therefore, any null attribute 6035 shall be enoded using the std-or encoding (e.g., /O=/). 6037 If a non-Teletex Common Name (CN) is present, it shall be 6038 mapped onto a Domain Defined Attribute "Common". This is in line 6039 with RFC 1328 on X.400 1988 to 1984 downgrading [22]. 6041 This specification defines a mapping of the Internet message 6042 framework to X.400. Body part mappings are defined in RFC 6043 1494bis [6], which relies on X.400(88) features. Downgrading to 6044 X.400(84) for body parts is defined in RFC 1496 (HARPOON), which 6045 shall be followed in the context of this appendix [5]. 6047 RFC 1327bis 6048 MIXER DRAFT Version 2.6 6050 Appendix C - RFC 822 Extensions for X.400 access 6052 This appendix defines a number of optional mappings which may be 6053 provided to give access from RFC 822 to a number of X.400 6054 services. These mappings are beyond the basic scope of this 6055 specification. There has been a definite demand to use extended 6056 RFC 822 as a mechanism to access X.400, and these extensions 6057 provide access to certain features. If this functionality is 6058 provided, this appendix shall be followed. The following 6059 headings are defined: 6061 extended-heading = 6062 "Prevent-NonDelivery-Report" ":" 6063 / "Generate-Delivery-Report" ":" 6064 / "Alternate-Recipient" ":" prohibition 6065 / "Disclose-Recipients" ":" prohibition 6066 / "X400-Content-Return" ":" prohibition 6068 Prevent-NonDelivery-Report and Generate-Delivery-Report allow 6069 setting of 6070 MTS.PerRecipientSubmissionFields.originator-report-request. The 6071 setting will be the same for all recipients. 6073 Alternate-Recipient, Disclose-Recipients, and X400-Content- 6074 Return allow for override of the default settings for 6075 MTS.PerMessageIndicators. 6077 Use of NOTARY mechanisms is a preferred meachanism for 6078 controlling these parameters. 6080 RFC 1327bis 6081 MIXER DRAFT Version 2.6 6083 Appendix D - Object Identifier Assignment 6085 The following Object Identifiers shall be used. 6087 internet ::= OBJECT IDENTIFIER { iso org(3) dod(6) 1 } -- from RFC 1155 6089 mail OBJECT IDENTIFIER ::= { internet 7 } -- IANA assigned 6091 mixer OBJECT IDENTIFIER ::= { mail mixer(1) } -- inherited from RFC 1495 6092 mixer-core OBJECT IDENTIFIER ::= { mixer core(3) } 6094 id-rfc-822-field-list OBJECT IDENTIFIER ::= {mixer-core 2} 6095 id-dsn-header-list OBJECT IDENTIFIER ::= {mixer-core 3} 6096 id-dsn-field-list OBJECT IDENTIFIER ::= {mixer-core 4} 6098 eit-mixer OBJECT IDENTIFIER ::= {mixer-core 5} 6099 -- the MIXER pseudo-EIT 6101 This object identifier for id-rfc-822-field-list is different to 6102 the one assigned in RFC 1327, which was erroneous. 6104 RFC 1327bis 6105 MIXER DRAFT Version 2.6 6107 Appendix E - BNF Summary 6109 boolean = "TRUE" / "FALSE" 6111 numericstring = *(DIGIT / " ") 6113 printablestring = *( ps-char ) 6114 ps-restricted-char = 1DIGIT / 1ALPHA / " " / "'" / "+" 6115 / "," / "-" / "." / "/" / ":" / "=" / "?" 6116 ps-delim = "(" / ")" 6117 ps-char = ps-delim / ps-restricted-char 6119 ps-encoded = *( ps-restricted-char / ps-encoded-char ) 6120 ps-encoded-char = "(a)" ; (@) 6121 / "(p)" ; (%) 6122 / "(b)" ; (!) 6123 / "(q)" ; (") 6124 / "(u)" ; (_) 6125 / "(l)" ; "(" 6126 / "(r)" ; ")" 6127 / "(" 3DIGIT ")" 6129 teletex-string = *( ps-char / t61-encoded ) 6130 t61-encoded = "{" 1* t61-encoded-char "}" 6131 t61-encoded-char = 3DIGIT 6133 teletex-and-or-ps = [ printablestring ] [ "*" teletex-string ] 6135 labelled-integer ::= [ key-string ] "(" numericstring ")" 6137 labelled-integer-2 ::= [ numericstring ] "(" key-string ")" 6139 key-string = *key-char 6140 key-char = 6142 RFC 1327bis 6143 MIXER DRAFT Version 2.6 6145 object-identifier ::= oid-comp object-identifier 6146 | oid-comp 6148 oid-comp ::= [ key-string ] "(" numericstring ")" 6150 encoded-info = 1#encoded-type 6152 encoded-type = built-in-eit / object-identifier 6154 built-in-eit = "Undefined" ; undefined (0) 6155 / "Telex" ; tLX (1) 6156 / "IA5-Text" ; iA5Text (2) 6157 / "G3-Fax" ; g3Fax (3) 6158 / "TIF0" ; tIF0 (4) 6159 / "Teletex" ; tTX (5) 6160 / "Videotex" ; videotex (6) 6161 / "Voice" ; voice (7) 6162 / "SFD" ; sFD (8) 6163 / "TIF1" ; tIF1 (9) 6165 encoded-pn = [ given "." ] *( initial "." ) surname 6167 given = 2* 6169 initial = ALPHA 6171 surname = printablestring 6173 std-or-address = 1*( "/" attribute "=" value ) "/" 6174 attribute = standard-type 6175 / "RFC-822" 6176 / dd-key "." std-printablestring 6178 RFC 1327bis 6179 MIXER DRAFT Version 2.6 6181 std-or-address-input = [ sep pair ] sep pair *( sep pair ) 6182 sep [ pair sep ] 6184 sep = "/" / ";" 6185 pair = input-attribute "=" value 6186 input-attribute = attribute 6187 / dd-key ":" std-printablestring 6189 standard-type = key-string 6191 dd-key = key-string 6193 value = std-printablestring 6195 std-printablestring 6196 = *( std-char / std-pair ) 6198 std-char = <"{", "}", "*", and any ps-char 6199 except "/" and "=" > 6200 std-pair = "$" ps-char 6202 global-id = std-or-address 6204 mta-field = "X400-Received" ":" x400-trace 6205 / "Deferred-Delivery" ":" date-time 6206 / "Latest-Delivery-Time" ":" date-time 6208 x400-trace = "by" md-and-mta ";" 6209 [ "deferred until" date-time ";" ] 6210 [ "converted" "(" encoded-info ")" ";" ] 6211 [ "attempted" md-or-mta ";" ] 6212 action-list 6213 ";" arrival-time 6215 RFC 1327bis 6216 MIXER DRAFT Version 2.6 6218 md-and-mta = [ "mta" mta "in" ] global-id 6219 mta = word 6220 arrival-time = date-time 6222 md-or-mta = "MD" global-id 6223 / "MTA" mta 6225 Action-list = 1#action 6226 action = "Redirected" 6227 / "Expanded" 6228 / "Relayed" 6229 / "Rerouted" 6231 RFC 1327bis 6232 MIXER DRAFT Version 2.6 6234 dr-user-info = dr-summary 6235 dr-recipients 6236 dr-content-return 6238 dr-content-return = "The Original Message is not available" 6239 / "The Original Message follows:" 6241 dr-summary = "This report relates to your message:" 6242 content-correlator 6243 "of" date-time 6245 dr-recipients = *(dr-recipient ) 6247 dr-recipient = dr-recip-success / dr-recip-failure 6249 dr-recip-success = 6250 "Your message was successfully delivered to:" 6251 mailbox "at" date-time 6253 dr-recip-failure = "Your message was not delivered to:" 6254 mailbox 6255 "for the following reason:" *word 6257 report-point = [ "mta" mta-name "in" ] global-id 6258 content-correlator = *word 6259 mta-name = word 6261 RFC 1327bis 6262 MIXER DRAFT Version 2.6 6264 dr-per-message-fields = 6265 / "X400-Conversion-Date" ":" date-time 6266 / "X400-Subject-Submision-Identifier" ":" 6267 mts-msg-id 6268 / "X400-Content-Identifier" ":" printablestring 6269 / "X400-Content-Type" ":" mts-content-type 6270 / "X400-Original-Encoded-Information-Types" ":" 6271 encoded-info 6272 / "X400-Originator-and-DL-Expansion-History" ":" 6273 mailbox ";" date-time ";" 6274 / "X400-Reporting-DL-Name" ":" mailbox 6275 / "X400-Content-Correlator" ":" content-correlator 6276 / "X400-Recipient-Info" ":" recipient-info 6277 / "X400-Subject-Intermediate-Trace-Information" ":" 6278 x400-trace 6279 / dr-extensions 6281 dr-per-recipient-fields = 6282 / "X400-Redirect-Recipient" ":" "x400" ";" std-or 6283 / "X400-Mapped-Redirect-Recipient" ":" "rfc822" ";" mailbox 6284 / "X400-Converted-EITs" ":" encoded-info ";" 6285 / "X400-Delivery-Time" ":" date-time 6286 / "X400-Type-of-MTS-User" ":" labelled-integer 6287 / "X400-Last-Trace" ":" [ encoded-info ] date-time 6288 / "X400-Supplementary-Info" ":" 6289 <"> printablestring <"> ";" 6290 / "X400-Redirection-History" ":" redirect-history-item 6291 / "X400-Physical-Forwarding-Address" ":" mailbox 6292 / "X400-Originally-Specified-Recipient-Number" ":" 6293 integer 6294 / dr-extensions 6296 dr-extensions = "X400-Discarded-DR-Extensions" ":" 6297 1# (object-identifier / labelled-integer) 6299 dr-diagnostic = "Reason" labelled-integer-2 6300 [ ";" "Diagnostic" labelled-integer-2 ] 6302 RFC 1327bis 6303 MIXER DRAFT Version 2.6 6305 mts-field = "X400-MTS-Identifier" ":" mts-msg-id 6306 / "X400-Originator" ":" mailbox 6307 / "X400-Recipients" ":" 1#mailbox 6308 / "Original-Encoded-Information-Types" ":" 6309 encoded-info 6310 / "X400-Content-Type" ":" mts-content-type 6311 / "X400-Content-Identifier" ":" printablestring 6312 / "Priority" ":" priority 6313 / "Originator-Return-Address" ":" 1#mailbox 6314 / "DL-Expansion-History" ":" mailbox ";" date-time ";" 6315 / "Conversion" ":" prohibition 6316 / "Conversion-With-Loss" ":" prohibition 6317 / "Delivery-Date" ":" date-time 6318 / "Discarded-X400-MTS-Extensions" ":" 6319 1#( object-identifier / labelled-integer ) 6321 prohibition = "Prohibited" / "Allowed" 6323 mts-msg-id = "[" global-id ";" *text "]" 6325 mts-content-type = "P2" / labelled-integer 6326 / object-identifier 6328 priority = "normal" / "non-urgent" / "urgent" 6330 RFC 1327bis 6331 MIXER DRAFT Version 2.6 6333 ipn-body-format = ipn-description 6334 [ ipn-extra-information ] 6335 [ ipn-content-return ] 6337 ipn-description = ipn-receipt / ipn-non-receipt 6339 ipn-receipt = "Your message to:" preferred-recipient 6340 "was received at" receipt-time 6341 "This notification was generated" 6342 acknowledgement-mode 6343 "The following extra information was given:" 6344 ipn-suppl 6346 ipn-non-receipt = "Your message to:" 6347 preferred-recipient 6348 ipn-reason 6350 ipn-reason = ipn-discarded / ipn-auto-forwarded 6352 ipn-discarded = "was discarded for the following reason:" 6353 discard-reason 6355 ipn-auto-forwarded = "was automatically forwarded." 6356 [ "The following comment was made:" 6357 auto-comment ] 6359 ipn-extra-information = 6360 "The following information types were converted:" 6361 encoded-info 6363 ipn-content-return = "The Original Message is not available" 6364 / "The Original Message follows:" 6366 preferred-recipient = mailbox 6367 receipt-time = date-time 6368 auto-comment = printablestring 6369 ipn-suppl = printablestring 6371 RFC 1327bis 6372 MIXER DRAFT Version 2.6 6374 discard-reason = "Expired" / "Obsoleted" / 6375 "User Subscription Terminated" / "IPM Deleted" 6377 acknowledgement-mode = "Manually" / "Automatically" 6379 ipms-field = "Supersedes" ":" 1*msg-id 6380 / "Expires" ":" date-time 6381 / "Reply-By" ":" date-time 6382 / "Importance" ":" importance 6383 / "Sensitivity" ":" sensitivity 6384 / "Autoforwarded" ":" boolean 6385 / "Incomplete-Copy" ":" 6386 / "Content-Language" ":" 1#language 6387 / "Message-Type" ":" message-type 6388 / "Discarded-X400-IPMS-Extensions" ":" 1#object-identifier 6389 / "Autosubmitted" ":" autosubmitted 6391 importance = "low" / "normal" / "high" 6393 sensitivity = "Personal" / "Private" / 6394 "Company-Confidential" 6396 language = 2*ALPHA [ "(" language-description ")" ] 6397 language-description = printable-string 6399 message-type = "Delivery Report" 6400 / "InterPersonal Notification" 6401 / "Multiple Part" 6403 autosubmitted = "not-auto-submitted" 6404 / "auto-generated" 6405 / "auto-replied" 6406 / "auto-forwarded" 6408 RFC 1327bis 6409 MIXER DRAFT Version 2.6 6411 redirect-comment = redirect-first *( redirect-subsequent ) 6413 redirect-first = "Originally To:" mailbox "Redirected on" 6414 date-time "To:" redirection-reason 6416 redirect-subsequent = mailbox "Redirected Again on" 6417 date-time "To:" redirection-reason 6419 redirection-history-item = "intended recipient" mailbox 6420 "redirected to" redirection-reason 6421 "on" date-time 6423 redirection-reason = 6424 "Recipient Assigned Alternate Recipient" 6425 / "Originator Requested Alternate Recipient" 6426 / "Recipient MD Assigned Alternate Recipient" 6427 / "Directory Look Up" 6428 / "Alias" 6430 subject-line = "Delivery-Report" "(" status ")" 6431 [ "for" destination ] 6433 status = "success" / "failure" / "success and failures" 6435 destination = mailbox / "MTA" word 6437 extended-heading = 6438 "Prevent-NonDelivery-Report" ":" 6439 / "Generate-Delivery-Report" ":" 6440 / "Alternate-Recipient" ":" prohibition 6441 / "Disclose-Recipients" ":" prohibition 6442 / "X400-Content-Return" ":" prohibition 6444 RFC 1327bis 6445 MIXER DRAFT Version 2.6 6447 Appendix F - Text format for MCGAM distribution 6449 1. Text Formats 6451 This appendix defines text formats for exchange of four types of 6452 mapping. 6454 1. Domain Name Space -> OR Address Space MCGAM 6456 2. OR Address Space -> Domain Name Space MCGAM 6458 3. Domain Name Space -> OR Address of preferred gateway 6460 4. OR Address Space -> Domain Name of preferred gateway 6462 2. Mechanisms to register and to distribute MCGAMs 6464 There is a well known set of MCGAM tables. 6466 The global coordination of the mapping rules is a part of the 6467 DANTE MailFLOW Project. New mapping rules may be defined by the 6468 authority responsible for the relevant name space. The rules need 6469 to be registered with a national mapping registration authority, 6470 which in turn passes them on to the central mapping registration 6471 authority. All the collected mapping rules are merged together 6472 into the globally coordinated mapping tables by the MailFLOW 6473 Project Team. The tables are available from the national mapping 6474 registration authorities. 6476 To get a contact address of the mapping registration authority 6477 for the respective country or more information about the MailFLOW 6478 Project contact: 6480 RFC 1327bis 6481 MIXER DRAFT Version 2.6 6483 SWITCH 6484 MailFLOW Project Team 6485 Limmatquai 138 6486 8001 Zuerich 6487 Switzerland 6489 email: mailflow@mailflow.dante.net 6490 S=MailFLOW;O=MailFLOW;P=DANTE;A=mailnet;C=fi; 6492 fax: +41 1 268 15 68 6493 tel: +41 1 268 15 20 6495 3. Syntax Definitions 6497 An address syntax is defined, which is compatible with the syntax 6498 used for 822.domains. By representing the OR addresses as 6499 domains, all lookups can be mechanically implemented as domain -> 6500 domain mappings. This syntax defined is initially for use in 6501 table format, but the syntax is defined in a manner which makes 6502 it suitable to be adapted for use with the Domain Name Service. 6503 This syntax allows for a general representation of OR addresses, 6504 so that it can be used in other applications. Not all attributes 6505 are used in the table formats defined. 6507 To allow the mapping where a level of the hierarchy is 6508 omitted, the pseudo-value "@" (not a printable string character) 6509 is used to indicate omission of a level in the hierarchy. This 6510 is distinct from the form including the element with no value, 6511 although a correct X.400 implementation will interpret both in 6512 the same manner. 6514 This syntax is not intended to be handled by users. 6516 RFC 1327bis 6517 MIXER DRAFT Version 2.6 6519 dmn-or-address = dmn-part *( "." dmn-part ) 6520 mn-part = dmn-attribute "$" value 6521 dmn-attribute = standard-type 6522 / "~" dmn-printablestring 6523 value = dmn-printablestring 6524 / "@" 6525 dmn-printablestring = 6526 = *( dmn-char / dmn-pair ) 6527 dmn-char = <"{", "}", "*", and any ps-char 6528 except "."> 6529 dmn-pair = "\." 6531 An example usage: 6533 ~ROLE$Big\.Chief.ADMD$ATT.C$US 6534 PRMD$DEC.ADMD$@.C$US 6536 The first example illustrates quoting of a "." and a domain 6537 define attribute (ROLE). The second example illustrates 6538 omission of the ADMD level. There shall be a strict ordering of 6539 all components in this table, with the most significant 6540 components on the RHS. This allows the encoding to be treated 6541 as a domain. 6543 Various further restrictions are placed on the usage of 6544 dmn-or-address in the address space mapping tables. 6546 a. Only C, ADMD, PRMD, O, and up to four OUs may be used. 6548 b. No components shall be omitted from this hierarchy, although 6549 the hierarchy may terminate at any level. If the mapping is 6550 to an omitted component, the "@" syntax is used. 6552 4. Table Lookups 6554 When determining a match, there are aspects which apply to all 6555 lookups. Matches are always case independent. The key for all 6556 three tables is a domain. The longest possible match shall be 6557 obtained. Suppose the table has two entries with the following 6558 keys: 6560 K.L 6561 J.K.L 6563 RFC 1327bis 6564 MIXER DRAFT Version 2.6 6566 Domain "A.B.C" will not return any matches. Domain "I.J.K.L" 6567 will match the entry "J.K.L:. 6569 5. Domain -> OR Address MCGAM format 6571 The BNF is: 6573 domain-syntax "#" dmn-or-address "#" 6575 EBNF.domain-syntax is defined in Section 4.2. Note that the 6576 trailing "#" is used for clarity, as the dmn-or-address syntax 6577 might lead to values with trailing blanks. Lines starting with 6578 "#" are comments. 6580 For example: 6581 AC.UK#PRMD$UK\.AC.ADMD$GOLD 400.C$GB# 6582 XEROX.COM#O$Xerox.ADMD$ATT.C$US# 6583 GMD.DE#O$@.PRMD$GMD.ADMD$DBP.C$DE# 6585 A domain is looked up to determine the top levels of an OR 6586 Address. Components of the domain which are not matched are used 6587 to build the remainder of the OR address, as described in Section 6588 4.3.4. 6590 6. OR Address -> Domain MCGAM format 6592 The syntax of this table is: 6594 dmn-or-address "#" domain-syntax "#" 6596 For example: 6598 # 6599 # Mapping table 6600 # 6601 PRMD$UK\.AC.ADMD$GOLD 400.C$GB#AC.UK# 6603 The OR Address is used to generate a domain key. It is important 6604 to order the components correctly, and to fill in missing 6605 components in the hierarchy. Use of this mapping is described in 6606 Section 4.3.2. 6608 RFC 1327bis 6609 MIXER DRAFT Version 2.6 6611 7. Domain -> OR Address of Preferred Gateway table 6613 This uses the same format as the domain -> OR address MCGAM 6614 table. In this case, the restriction to only use 6615 C/ADMD/PRMD/O/OU does not apply. Use of this mapping is 6616 described in Section 4.3.4. A domain cannot appear in this table 6617 and in the domain to OR Address table. 6619 8. OR Addresss -> domain of Preferred Gateway table 6621 This uses the same format as the OR Address -> domain MCGAM 6622 table. Use of this mapping is described in Section 4.3.5. An OR 6623 Address cannot appear in this table and in the OR Address to 6624 domain table. 6626 RFC 1327bis 6627 MIXER DRAFT Version 2.6 6629 Appendix G - Conformance 6631 This appendix defines a number of options, which a conforming 6632 gateway shall specify. Conformance to this specification shall 6633 not be claimed if any of the mandatory features are not 6634 implemented. A specification of conformance may list the service 6635 elements of Chapter 2, in order to be clear that full conformance 6636 is provied. In particular: 6638 - Formats for all fields shall be followed. 6640 - The gateway shall enable MCGAMs to be used. 6642 - Formats for subject lines, delivery reports and IPNs shall 6643 be followed. A system which followed the syntax, but 6644 translated text into a language other than english would be 6645 conformant. 6647 - RFC 1137 shall not be followed when mapping to SMTP. 6649 - All mappings of trace shall be implemented. 6651 - There shall be a mechanism to access all three global 6652 mappings. 6654 - RFC 1494bis shall be followed for mapping body parts. 6656 - When it is specified that a MIME format message is 6657 generated, RFC 1521 shall be followed. 6659 A gateway shall specify: 6661 - Which Interent Message Transport (822-MTS) protocols are 6662 supported. If SMTP is supported, Appendex A of MIXER shall 6663 be used. 6665 - Which X.400 versions are supported (84, 88, 92). 6667 - Which mechanisms (table, X.500, DNS) are supported to access 6668 MCGAMs. 6670 - The mechanism or mechanisms by which the global mapping 6671 information is accessed. 6673 RFC 1327bis 6674 MIXER DRAFT Version 2.6 6676 The following are optional parts of this specification. A 6677 conforming implementation shall specify which of these it 6678 supports. 6680 - Support for the extension mappings of Appendix C. 6682 - Support for returning illegal format content in a delivery 6683 report 6685 - Which address interpretation heuristics are supported 6686 (4.3.4.1) 6688 - If RFC 987 generated message ids are handled in a backwards 6689 compatible manner (4.7.3.6) 6691 RFC 1327bis 6692 MIXER DRAFT Version 2.6 6694 Appendix H - Change History: RFC 987, 1026, 1138, 1148 6696 RFC 987 was the original document, and contained the key elements 6697 of this specification. It was specific to X.400(1984). RFC 1026 6698 specified a small number of necessary changes to RFC 987. 6700 RFC 1138 was based on the RFC 987 work. It contained an 6701 editorial error, and was reissued a few months later as RFC 1148. 6702 RFC 1148 will be referred to here, as it is the document which is 6703 widely referred to elsewhere. The major goal of RFC 1148 was to 6704 upgrade RFC 987 to X.400(1988). It did this, but did not 6705 obsolete RFC 987, which was recommended for use with X.400(1984). 6706 This appendix summarises the changes made in going from RFC 987 6707 to RFC 1148. 6709 RFC 1148 noted the following about its upgrade from RFC 987: 6710 Unnecessary change is usually a bad idea. Changes on the RFC 822 6711 side are avoided as far as possible, so that RFC 822 users do 6712 not see arbitrary differences between systems conforming to this 6713 specification, and those following RFC 987. Changes on the X.400 6714 side are minimised, but are more acceptable, due to the mapping 6715 onto a new set of services and protocols. 6717 1. Introduction 6719 The model has shifted from a protocol based mapping to a service 6720 based mapping. This has increased the generality of the 6721 specification, and improved the model. This change affects the 6722 entire document. 6724 A restriction on scope has been added. 6726 2. Service Elements 6728 - The new service elements of X.400 are dealt with. 6730 - A clear distinction is made between origination and 6731 reception 6733 RFC 1327bis 6734 MIXER DRAFT Version 2.6 6736 3. Basic Mappings 6738 - Add teletex support 6740 - Add object identifier support 6742 - Add labelled integer support 6744 - Make PrintableString <-> ASCII mapping reversible 6746 - The printable string mapping is aligned to the NBS mapping 6747 derived from RFC 987. 6749 4. Addressing 6751 - Support for new addressing attributes 6753 - The message ID mapping is changed to not be table driven 6755 5. Detailed Mappings 6757 - Define extended IPM Header, and use instead of second body 6758 part for RFC 822 extensions 6760 - Realignment of element names 6762 - New syntax for reports, simplifying the header and 6763 introducing a mandatory body format (the RFC 987 header 6764 format was unusable) 6766 - Drop complex autoforwarded mapping 6768 - Add full mapping for IP Notifications, defining a body 6769 format 6771 - Adopt an MTS Identifier syntax in line with the OR Address 6772 syntax 6774 - A new format for X400 Trace representation on the RFC 822 6775 side 6777 RFC 1327bis 6778 MIXER DRAFT Version 2.6 6780 6. Appendices 6782 - Move Appendix on restricted 822 mappings to a separate RFC 6784 - Delete Phonenet and SMTP Appendixes 6786 RFC 1327bis 6787 MIXER DRAFT Version 2.6 6789 Appendix I - Change History: RFC 1148 to RFC 1327 6791 1. General 6793 - The scope of the document was changed to cover X.400(1984), 6794 and so obsolete RFC 987. 6796 - Changes were made to allow usage to connect RFC 822 networks 6797 using X.400 6799 - Text was tightened to be clear about optional and mandatory 6800 aspects 6802 - A good deal of clarification 6804 - A number of minor EBNF errors 6806 - Better examples are given 6808 - Further X.400 upper bounds are handled correctly 6810 2. Basic Mappings 6812 - The encoding of object identifier is changed slightly 6814 3. Addressing 6816 - A global mapping of domain to preferred gateway is 6817 introduced. 6819 - An overflow mechanism is defined for RFC 822 addresses of 6820 greater than 128 bytes 6822 - Changes were made to improve compatibility with the PDAM on 6823 writing OR Addresses. 6825 + The PD and Terminal Type keywords were aligned to the 6826 PDAM. It is believed that minimal use has been made of 6827 the RFC 1148 keywords. 6829 RFC 1327bis 6830 MIXER DRAFT Version 2.6 6832 + P and A are allowed as alternate keys for PRMD and ADMD 6834 + Where keywords are different, the PDAM keywords are 6835 alternatives on input. This is mandatory. 6837 4. Detailed Mappings 6839 - The format of the Subject: lines is defined. 6841 - Illegal use (repetition) of the heading EXTENSION is 6842 corrected, and a new object identifier assigned. 6844 - The Delivery Report format is extensively revised in light 6845 of operational experience. 6847 - The handling of redirects is significantly changed, as the 6848 previous mechanism did not work. 6850 5. Appendices 6852 - An SMTP appendix is added, allowing optional use of the VRFY 6853 command to improve probe information. 6855 - Handling of JNT Mail Acknowledge-To is changed slightly. 6857 - A DDA JNT-MAIL is allowed on input. 6859 - The format definitions of Appendix F are explained further, 6860 and a third table definition added. 6862 - An appendix on use with X.400(1984) is added. 6864 - Optional extensions are defined to give RFC 822 access to 6865 further X.400 facilities. 6867 - An appendix on conformance is added. 6869 RFC 1327bis 6870 MIXER DRAFT Version 2.6 6872 Appendix J - Change History: RFC 1327 to this Document 6874 1. General 6876 This update is primarily for stability, and to fold in 6877 compatibility for MIME and to add support for the new NOTARY 6878 delivery status notifications. Other general changes: 6880 - Various editorial updates 6882 - Minor EBNF errors 6884 - Reference to mapping table support by DNS and X.500. 6886 - Alignment to X.400(92) 6888 - Assignment of a new object identifier 6890 - Removal of specification relating to body mapping, which is 6891 now defined in RFC 1494bis. 6893 2. Service Elements 6895 - Support of Auto-Submitted service 6897 3. Basic Mappings 6899 - Comments shall not be used in new headers, to remove parsing 6900 ambiguity 6902 - RFC 1522 encoding may be used as an alternative to X.408 6903 downgrade, where appropriate. 6905 - Correct handling of RFC 822 four year dates. 6907 4. Addressing 6909 - Replaced the mandatory global address mapping with MCGAMs. 6911 RFC 1327bis 6912 MIXER DRAFT Version 2.6 6914 - Add codes and add a heuristic to align to the standard X.400 6915 form of writing OR Addresses. 6917 - Improved text on ordering heuristic 6919 - Leading "/" interpretation added 6921 - All bar one of the address mapping heuristics made 6922 mandatory. 6924 - Interpretation of domain defined attribute "RFC-822" made 6925 mandatory in all cases 6927 - Make report request comments optional 6929 5. Detailed Mappings 6931 - Comments no longer maps to separate body part 6933 - Allow Languages to be multi-valued 6935 - Change Content-Identifier to X400-Content-Identifier, in 6936 order to avoid confusion with MIME. 6938 - Reverse mapping of MIXER defined fields made mandatory 6940 - "Expiry-Date:" changed to "Expires:". 6942 - "Obsoletes:" changed to "Supersedes:". 6944 - Define correct handling when "Resent-Date:" is present. 6946 6. Appendices 6948 - Change "Content-Return" to "X400-Content-Return" in Appendix 6949 C. 6951 - Relaxation of restrictions on mapping 3 in Appendix F. 6953 - Add linkage to HARPOON in Appendix B. 6955 - RFC 1494bis added to the conformance statement of Appendix 6957 RFC 1327bis 6958 MIXER DRAFT Version 2.6 6960 G. 6962 - Added Appendix L, with ASN. Summary. 6964 RFC 1327bis 6965 MIXER DRAFT Version 2.6 6967 Appendix L - ASN.1 Summary 6969 MIXER Definitions { iso org(3) dod(6) internet(1) mail(7) 6970 mixer(1) mixer-core(3) definitions(1) } 6972 DEFINITIONS IMPLICIT TAGS ::= 6974 BEGIN 6976 -- exports everything 6978 IMPORTS 6980 EXTENSION FROM 6981 MTSAbstractService {join-iso-ccit mhs-motis(6) mts(3) 6982 modules(0) mts-abstract-service(1) } 6984 HEADING-EXTENSION FROM 6985 IPMSAbstractService {join-iso-ccit mhs-motis(6) ipms(1) 6986 modules(0) abstract-service(3) } 6988 rfc-822-field HEADING-EXTENSION 6989 VALUE RFC822FieldList 6990 ::= id-rfc-822-field-list 6992 RFC822FieldList ::= SEQUENCE OF RFC822Field 6994 RFC822Field ::= IA5String 6996 dsn-header-list EXTENSION 6997 RFC822FieldList 6998 ::= id-dsn-header-list 7000 dsn-field-list EXTENSION 7001 RFC822FieldList 7002 ::= id-dsn-field-list 7004 RFC 1327bis 7005 MIXER DRAFT Version 2.6 7007 internet ::= OBJECT IDENTIFIER { iso org(3) dod(6) 1 } -- from RFC 1155 7009 mail OBJECT IDENTIFIER ::= { internet 7 } -- IANA assigned 7011 mixer OBJECT IDENTIFIER ::= { mail mixer(1) } -- inherited from RFC 1495 7012 mixer-core OBJECT IDENTIFIER ::= { mixer core(3) } 7014 id-rfc-822-field-list OBJECT IDENTIFIER ::= {mixer-core 2} 7015 id-dsn-header-list OBJECT IDENTIFIER ::= {mixer-core 3} 7016 id-dsn-field-list OBJECT IDENTIFIER ::= {mixer-core 4} 7018 eit-mixer OBJECT IDENTIFIER ::= {mixer-core 5} 7019 -- the MIXER pseudo-EIT 7021 END -- MIXER ASN.1 7023 RFC 1327bis 7024 MIXER DRAFT Version 2.6 7026 SECURITY CONSIDERATIONS 7028 Security considerations are not discussed in this RFC. 7030 AUTHOR'S ADDRESS 7032 Steve Kille 7033 Isode Ltd 7034 The Dome 7035 The Square 7036 Richmond 7037 TW9 1DT 7038 England 7040 Phone: +44-181-332-9091 7042 Internet EMail: S.Kille@ISODE.COM 7044 X.400 Email: I=S; S=Kille; P=Isode; A=Mailnet; C=FI; 7046 UFN: S.Kille, Isode, GB 7048 RFC 1327bis 7049 MIXER DRAFT Version 2.6 7051 References 7053 1. CCITT , "Recommendations X.400," Message Handling Systems: 7054 System Model - Service Elements, Oct 1984. 7056 2. C. Allocchio, "MaXIM11 - Mapping between X.400 / Internet 7057 Mail and Mail-11 mail," RFC 1405bis, Jan 1997. 7059 3. C. Allocchio, "Using the Internet DNS to Distribute MIXER 7060 Conformant Global Address Mapping (MCGAM)," RFC 1664bis, Jan 7061 1997. 7063 4. H.T. Alvestrand, S.E. Kille, R. Miles, M. Rose, and S. 7064 Thompson, "Mapping between X.400 and RFC-822 Message 7065 Bodies," RFC 1495, Aug 1993. 7067 5. H.T. Alvestrand, J. Romaguera, and K. Jordan, "Rules for 7068 Downgrading Messages for X.400(88) to X.400(84) When MIME 7069 Content-Types are Present in the Messages (Harpoon)," RFC 7070 1496, Aug 1993. 7072 6. H.T. Alvestrand and S. Thompson, "Equivalences between X.400 7073 and RFC-822 Message Bodies," RFC 1494, Aug 1993. 7075 7. H.T. Alvestrand, "Tags for the Identification of Languages," 7076 RFC 1756, Mar 1995. 7078 8. H.T. Alvestrand, "Mapping between X.400 and RFC-822/MIME 7079 Message Bodies," RFC Draft, Aug 1996. 7081 9. N. Borenstein and N. Freed, "MIME (Multipurpose Internet 7082 Mail Extensions)," RFC 1521, Sep 1993. 7084 10. R.T. Braden, "Requirements for Internet Hosts -- Application 7085 and Support," RFC 1123, Oct 1989. 7087 11. CCITT/ISO, "CCITT Recommendations X.420/ ISO/IEC 10021-7," 7088 Message Handling Systems: Interpersonal Messaging System, 7089 Dec 1988. 7091 12. CCITT/ISO, "CCITT Recommendations X.411/ ISO/IEC 10021-4," 7092 Message Handling Systems: Message Transfer System: Abstract 7093 Service Definition and Procedures, Dec 1988. 7095 RFC 1327bis 7096 MIXER DRAFT Version 2.6 7098 13. CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1," 7099 Message Handling: System and Service Overview , Dec 1988. 7101 14. CCITT/ISO, "Specification of Abstract Syntax Notation One 7102 (ASN.1)," CCITT Recommendation X.208 / ISO/IEC 8824, Dec 7103 1988. 7105 15. CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1," 7106 Message Handling: System and Service Overview , Dec 1992. 7108 16. D.H. Crocker, "Standard of the Format of ARPA Internet Text 7109 Messages," RFC 822, Aug 1982. 7111 17. S.E. Kille, "Mapping Between X.400 and RFC 822," UK Academic 7112 Community Report (MG.19) / RFC 987, Jun 1986. 7114 18. S.E. Kille, "Addendum to RFC 987," UK Academic Community 7115 Report (MG.23) / RFC 1026, Aug 1987. 7117 19. S.E. Kille, "Mapping Between X.400(1988) / ISO 10021 and RFC 7118 822," RFC 1138, Oct 1989. 7120 20. S.E. Kille, "Mapping Between X.400(1988) / ISO 10021 and RFC 7121 822," RFC 1148, Mar 1990. 7123 21. S.E. Kille, "Mapping Between X.400(1988) / ISO 10021 and RFC 7124 822," RFC 1327, May 1992. 7126 22. S.E. Kille, "X.400 1988 to 1984 downgrading," RFC 1328, May 7127 1992. 7129 23. S.E. Kille, "A String Encoding of Presentation Address," RFC 7130 1278, Nov 1992. 7132 24. S.E. Kille, "A String Representation of Distinguished Name," 7133 RFC 1485, Jan 1992. 7135 25. S.E. Kille, "Using the OSI Directory to achieve User 7136 Friendly Naming," RFC 1484, Jan 1992. 7138 26. S.E. Kille, "Use of an X.500/LDAP directory to support MIXER 7139 address mapping," RFC 1838bis, Feb 1997. 7141 27. N. Koorland, "Message Attachmment Work Group (MAWG): MAWG 7143 RFC 1327bis 7144 MIXER DRAFT Version 2.6 7146 Feasibility Project Guide," EMA Report, Version 1.5, Nov 7147 1995. 7149 28. K. Moore and G. Vaudreuil, "An Extensible Message Format for 7150 Delivery Status Notifications," RFC 1894, Jan 1996. 7152 29. K. Moore, "SMTP Service Extensions for Delivery Status 7153 Notifications," RFC 1891, Jan 1996. 7155 30. J.B. Postel, "SIMPLE MAIL TRANSFER PROTOCOL," RFC 821, Aug 7156 1982.