Network Working C. Allocchio Group GARR-Italy INTERNET-DRAFT November 1997 Expires: May 1998 File: draft-ietf-fax-addressing-01.txt PSTN and fax address format in e-mail services v3.4 Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. 1. Introduction Since the very first e-mail to fax gateway objects appeared, a number of different methods to specify a fax address into an e-mail address have been used by implementors. Two major objectives for this were - enable an e-mail user to send faxes from his/her e-mail interface; - enable some kind of "fax over e-mail service" transport, to reduce the costs of fax transmissions, and use the existing e-mail infrastructure. The definition of other services wich somehow interact with the Public Switched Telephone Network (PSTN), like voice mail service or GSM Short Messages Service (SMS), added other fields where a PSTN address needs to be integrated into an e-mail address. This memo describes a method to encode generic PSTN addresses (including thus fax addresses) into e-mail addresses. The opposite problem, i.e. to allow a traditional numeric-only telephone or fax device user to access the e-mail transport service is not discussed here. This memo focuses on a generic e-mail service, being mainly composed by the two major standard interconnected e-mail services, Internet Mail and X.400, surrounded by a variety of non standard (mainly LAN-based) e-mail serivces with their gateways to one or both of the standard services. The TPC.INT experiment already proposes a method to encode into the Internet DNS the fax PSTN addresses. However TPC.INT approach is more oriented towards a "fax routing strategy", i.e. to create a public fax routing service that uses the Internet e-mail service, where the Internet DNS service provides embedded fax routing information. Such an approach, however, does not scale to closed users' group, or to LAN-based fax services. TPC.INT approach is not in competition with this proposal, though. In fact the TPC.INT addressing schema is one of the many possible methods to address a so called "I-fax device" in the Internet. Even if in this memo we focus on e-mail addresses, a number of elements defined in this specification can also be used for other specifications dealing with PSTN addresses: for example URLs specification could adopt similar definitions, with slight changes in the global syntax due to specific URL format. Finally, in this proposal we try to obtain maximum compatibility with existing e-mail gateway services and standard specifications. In particular it allows tunneling of the Internet e-mail fax and other PSTN related messages across X.400 services (via MIXER gateways), and also facilitate access to existing fax gateway services over different e-mail transport systems with minimal or null modifications to existing installed base. In this document the formal definitions are described using ABNF sintax, as defined into [referenceABNF]. We will also use some of the "CORE DEFINITIONS" defined in "APPENDIX A - CORE" of that document. 2. PSTN address and Fax address In order to create a flexible and extensible set of definitions, we need to define uniquely the meaning of the diffrerent tokens composing what is commonly called "PSTN address". Then we will also define a specific subset of "PSTN addresses", i.e. the so called "fax address". A pstn-address is composed of two main parts: - a global or local PSTN telephone number (possibly supplemented by a subaddress), called pstn-mbox - an optional set of additional items, useful to add information about the recipient or the message, called pstn-recipient. If the message being transported is a fax message over e-mail service, then the pstn-mbox telephone number should in common cases point to a "fax aware" device, i.e. a fax machine, a fax gateway or any equivalent one which is able to correctly process a fax message received via the PSTN service. The pstn-mbox element is sometimes not enough to specify additional details, like intended recipient name, physical address, etc. The optional pstn-recipient element provides information which can also be used by the offramp gateway to specify exactly the recipient: in case an offramp fax gateway is involved, the pstn-recipient element can be used to compose a fax cover page. NOTE: The pstn-address is the "local" (also known as "Left Hand Side" or LHS) section of an e-mail address, i.e. the element on the left of the "@" sign. We define: pstn-address = pstn-mbox [ pstn-recipient ] pstn-mbox = service-selector "=" ( global-phone / local-phone ) [ sub-sep sub-addr ] [post-sep post-dial] NOTE: see section 4 in case multiple sub-addr need to be specified. service-selector = 1*( DIGIT / ALPHA / "-" ) ; note that SP (space) is not allowed in ; service-selector. ; service-selector MUST be handled as a case ; INSENSITIVE string by implementations. Specifications adopting the pstn-address definition must define a unique case insensitive service-selector element to identify the specific messaging service involved. For the fax over e-mail service the service-selector element is predefined as fax-service-selector = "FAX" The resultant fax-address and fax-mbox are fax-address = fax-mbox [ pstn-recipient ] fax-mbox = "FAX=" ( global-phone / local-phone ) [ sub-sep sub-addr ] [post-sep post-dial] We define now in details the global-phone and local-phone elements: global-phone = "+" int-country-code [ area-code ] local-number ; This is in agreement with ITU E.164 specification. ; area-code can be omitted only for countries ; which do not use an area-code system. ; This is a globally unique identifier on the PSTN ; and it must be reachable from anywhere. NOTE: the pause character is not allowed in global-phone. If the User Agent (UA) allow insertion of the pause character also into the global-phone object, then this must be removed before submission to the MTA. local-phone = ( local-type1 / local-type2 / local-type3 ) NOTE: a local-phone specification is a sequence of digits and pauses which should be dialled by the MTA specified by mta-I-pstn (see section 3) to reach the destination device. Other MTAs should only transfer the message around without modification until then given destination MTA is reached. However the implementation scenario is complex and its full discussion is out of scope in this document. local-type1 = [ exit-code ] int-access-code int-country-code [ [ pause ] area-code ] [ pause ] local-number ; this is the usual number dialed on traditional ; PSTN devices for an international call. ; area-code can be omitted only for countries ; which do not use an area-code system. local-type2 = [ exit-code ] long-distance-access area-code [ pause ] local-number ; this is the usual number dialed on traditional ; PSTN devices for a national long distance call. local-type3 = [ exit-code ] [ local-number ] ; this is the usual number dialed on traditional ; PSTN devices for a local call or in countries ; where the area-code is not in use. ; Note that it could also be totally missing for ; cases where the local dialling device rely on ; local post-dial sequences only. In common practice PSTN numbers are often written, for users readability, using separators like SP, ".", "-" and others. There elements do not actually belong to the number itself and cannot be dialled on the PSTN services. However user specifying a PSTN e-mail address will be facilitated if they can insert these separators between dial elements like digits etc. For this reason we allow in the syntax the write-sep element as defined below. The write-sep element MUST be ignored by all involved e-mail to external service devices. The MTAs are also allowed to remove the write-sep elements from pstn-mbox addresses. The use of the write-sep is allowed, but not reccommended. write-sep = ( "-" / "." ) int-country-code = 1*( DIGIT / write-sep ) ; without the local international access ; prefix int-access-code = 1*( DIGIT / write-sep ) ; examples: "00", "010", "19" long-distance-access = 1*( DIGIT / write-sep ) ; in many countries this code is "0" or "1" exit-code = phone-string ; this include anything needed to enable dialling, like ; the digit to access outside line, the long distance ; carrier access code, the access password to the service ; and also allows special DTMF "#", "*", "A", "B", "C" ; and "D" codes area-code = 1*( DIGIT / write-sep ) ; without the eventual leading long-distance-access code. ; NOTE: some countries do not use an internal area-code ; structure local-number = 1*( DIGIT / pause / write-sep ) ; this is the usual number dialed on traditional ; devices for a local call IMPORTANT NOTE: the description of local-phone is complex due to a large number of possible variants in the existing phone systems. However its own structure can also be described as a 'sequence of DIGIT, pause, tonewait, "#" and "*" appropriate to the local dialling environment in order to reach the final destination device'. phone-string = 1*( DIGIT / pause / tonewait / "#" / "*" / "A" / "B" / "C" / "D" / write-sep ) ; this includes also special DTMF codes like "*", ; "#", "A", "B", "C", "D" defined in [reference ETSI] ; Important Note: this is NOT the alpha to digit ; convention in use in some countries. In PSTN service there are cases where a sub-addr is required to specify the final destination. In particular there are ISDN subaddresses, which are common to all possible services, including fax service, and T.33 subaddresses which are limited to the fax service only. We must thus be able to distinguish the two possible cases, remembering that using a T.33 subaddress outside the fax service makes absolutely no sense. As a consequence, for all possible services we define: sub-sep = isdn-sep while for the fax over e-mail service only we allow the alternate choice of: sub-sep = ( isdn-sep / t33-sep ) In details: isdn-sep = "/ISUB=" ; note that "/ISUB=" is case INSENSITIVE t33-sep = "/TSUB=" ; note that "/TSUB=" is case INSENSITIVE and can be used ; within fax service only. sub-addr = 1*( DIGIT / write-sep ) pause = ( "p" / "P" ) tonewait = ( "w" / "W" ) NOTE: "pause" and "tonewait" character interpretation in local-phone numbers depends on the specific MTA implementation. Thus its exact meaning need not to be defined here. post-sep = "/POSTD=" ; note that "/POSTD=" is case INSENSITIVE post-dial = phone-string ; this include anything needed to access the final device ; on the PSTN, like further dialing sequenes ; and also allows special DTMF "#", "*", "A", "B", "C" ; and "D" codes A number of pstn-mbox examples are listed in section 5.1 We define now the optional and extensible pstn-recipient item: pstn-recipient = [ recipient-name ] [ 1*( recipient-qualifier ) ] recipient-name = ( personal-type1 / personal-type2 ) personal-type1 = "/PN=" [ givenname [ "." ] ] [ initials [ "." ] ] surname ; this is compatible with ITU F.401 personal-type2 = [ "/G=" givenname ] [ "/I=" initials ] "/S=" surname ; this is compatible with ITU F.401 The following definitions come directly from MIXER specification: surname = printablestring givenname = 1*( DIGIT / ALPHA / SP / "'" / "+" / "," / "-" / "/" / ":" / "=" / "?" ) initials = 1*ALPHA NOTE: the two possible formats of recipient-name are both in common use. Implementations should accept both, but generate personal-type1 only. And also the extensible recipient-qualifier: recipient-qualifier :== ( qualif-type1 / qualif-type2 ) qualif-type1 = "/" keyword "=" string keyword = 1*( DIGIT / ALPHA / "-" ) ; note that SP (space) is not allowed in keyword qualif-type2 = "/" x400-label "=" printablestring x400-label = ( "GQ" / "O" / "OU1" / "OU2" / "OU3" / "OU4" / "P" / "A" / "C" / "PD-PN" / "PD-EA" / "PD-ED" / "PD-OFN" / "PD-OF" / "PD-O" / "PD-S" / "PD-A" / "PD-U" / "PD-L" / "PD-R" / "PD-B" / "PD-PC" / "PD-SN" / "PD-C" / "X121" / "E164" / "PSAP" / "N-ID" / "T-ID" / "T-TY" / "DD." dd-key ) ; this is the full list of existing text labels ; according to ITU F.401. "PD-x" labels provide ; a set of predefined attributes for physical ; delivery which can be also useful for message ; recipient identification. dd-key = 1*( DIGIT / ALPHA / "-" ) ; note that SP (space) is not allowed in dd-key string = PCHAR ; note that printable characters are %x20-7E printablestring = 1*( DIGIT / ALPHA / SP / "'" / "(" / ")" / "+" / "," / "-" / "." / "/" / ":" / "=" / "?" ) ; this definition comes from ITU F.401 and ; [MIXER]. NOTE: if we use WSP and other specials in string, the obtained pstn-address will result in quoted-string; this could create problems to some existing broken MTA and UA implementations. WSP and specials are defined in [rfc822bis]. The specific use of extension keywords, and the eventual registration of extension keyword is out of the scope of this specification. Specific qualif-type1 and qualif-type2 use is an implementation issue. The pstn-recipient object is intended to specify per-recipient elements to be used to identify the exact recipient. In the specific case of fax over e-mail service, the pstn-recipient object is intended to be used to identify the fax recipient on the fax cover page generated by the MTA given in mta-I-pstn. For specific fax cover generation issues see also appendix A. See section 5.2 for pstn-recipient examples. 3. The e-mail address of the I-pstn device: mta-I-pstn An "I-pstn device" owns an e-mail address, or to be more exact, a name which enables a mail system to identify it on the e-mail global system. In the specific case of the fax service, the I-pstn device is known as "I-fax device". In Internet mail, this is the Right Hand Side (RHS) part of the address, i.e. the part on the right of the "@" sign. We will call this mta-I-pstn. mta-I-pstn = domain where domain SHALL be a fully-qualified canonical domain name as defined in RFC 1035 and the SMTP specification syntax production for as defined in RFC 821. 4. The pstn-email The complete structure used to transfer a PSTN address over the Internet e-mail transport system is called pstn-email. This object is a an e-mail address which conforms to RFC822 addr-spec syntax, with extra structure which allows the PSTN number to be identified. pstn-email = ["/"] pstn-address ["/"] "@" mta-I-pstn NOTE: the optional "/" characters can result from other mail transport services gateways, where it is also an optional element. Implementations should accept it, but should not generate such element. Gateways are allowed to strip them off when converting to Internet mail addressing. In case there are multiple sub-addr to be given on the same pstn-mbox then multiple pstn-email elements will be used. The UA could accept multiple sub-addr elements for the same global-phone / local-phone, but it must generate multiple pstn-mbox, when passing the message to the MTA. 4.1 The fax-email The fax-email element is just a specific version of pstn-email for the fax over the Internet e-mail transport system, where the distinction element is just the fixed "FAX" service-selector. fax-email = ["/"] fax-address ["/"] "@" mta-I-pstn In this case the mta-I-pstn will usually point to an "I-fax" device where the fax message is handled properly. 5. Examples In order to clarify the specification we present here a limited set of examples. Many of the examples refer to the fax service, but also additional possible services are included. 5.1 pstn-mbox examples A pstn-mbox address in Italy for the fax service, using global-phone, without sub-addr and without write-sep: FAX=+3940226338 A pstn-mbox address in Germany for an hypotetical XYZ service, using global-phone, with ISDN sub-addr 1234 and write-sep ".": XYZ=+49.81.7856345/ISUB=1234 A pstn-mbox address in U.S.A. for fax service, using global-phone, with T.33 sub-addr 8745, with write-sep "-" and post-dial sequence p1w7005393w373 FAX=+1-202-455-7622/TSUB=8745/PostD=p1w7005393w373 A pstn-mbox address in Italy for fax service, using local-phone, dialed from an MTA in Germany, with int-access-code "00", with T.33 subaddress "4312" and without pause or write-sep: FAX=003940226338/Tsub=4312 The same pstn-mbox address in Italy, using local-phone dialed from an MTA in Italy (long distance call), with long-distant-access "0", with exit-code "9", T.33 subaddress "4312", pause "p" and write-sep ".": FAX=9p040p22.63.38/tsub=4312 A pstn-mbox address in North America for hypotetical service XYZ, using global-phone, without sub-addr and write-sep "-" and ".": XYZ=+1.202.344-5723 A pstn-mbox address for fax service in France, using local-phone dialed from an MTA in France (long distance call), with exit-code "0", T.33 subaddress "3345" and pause "p": FAX=0p0134782289/TSUB=3345 A pstn-mbox address for fax service in North America, using local-phone, without sub-addr, without local-number, using only post-dial sequences to reach numbers stored in a locally defined short-dial numbers database, where 6743 is an access password, and 99p51 is the sequence to access the local short-dial number: FAX=/postd=w6743w99p51 5.2 pstn-recipient examples Here are a number of pstn-recipient examples. Please note that pstn-recipient is just an optional element, and thus a pstn-mbox element also is required in a pstn-address. A pstn-recipient using only recipient-name of personal-type1, with givenname initials and surname: /PN=Tom.J.Smiths A pstn-recipient using only recipient-name of personal-type1, with givenname and surname: /PN=Mark.Collins A pstn-recipient using only recipient-name of personal-type2, with surname only: /S=Smiths A pstn-recipient using recipient-name of personal-type1, and one recipient-qualifier extension: /PN=J.Smiths/dept=Quaility-control A pstn-recipient using two recipient-qualifier extension, only: /office=T2-33A/dept=Q-C A fax-reciepint using some recipient-quelifier extension derived from ITU F.401 physical delivery label set: /PD-S=Main.Street/PD-SN=45/PD-OF=Sales.dept 5.3 pstn-address examples Some pstn-address examples, obtained combining elements from previous examples. There are complete addresses which can be used as "local part" (LHS) element of an e-mail address. Without optional pstn-recipient (fax service): FAX=+12023445723 With pstn-recipient of personal-type1 (XYZ service): XYZ=+3940226338/PN=Mark.Collins With pstn-recipient made of two recipient-qualifier extensions (fax service): FAX=9p040p22.63.38/tsub=4312/office=T2-33A/dept=Q-C 5.4 pstn-email examples Here are the same addresses as before, where "faxgw" is the mta-I-pstn field for the fax service. FAX=+12023445723@faxgw FAX=+39-40-226338/PN=Mark.Collins@faxgw FAX=9p040p226338/TSUB=4312/office=T2-33A/dept=Q-C@faxgw FAX=+3940226338/PN=Mark.Collins/@faxgw NOTE: the optional "/" in front for the "@" sign can be generated by gateways to other services, like MIXER. 5.5 A complete SMTP transaction example: Here is an example of complete SMTP transaction. S: C: S: 220 foo.mailfax.com ESMTP service ready C: EHLO pc.mailfax.com S: 250 foo.mailfax.com says hello C: MAIL FROM: S: 250 Sender ok C: RCPT TO: S: 250 recipient ok C: DATA S: 354 Enter your data C: From: Thomas Blake C: To: C: Subject: Hello there C: MIME-version: 1.0 C: Date: Mon, 01 Sep 1997 18:14:23 -0700 C: Content-Type: multipart/mixed; boundary=16820115-1435684603#2306 C: C: This is a MIME message. It contains a C: TIFF-F fax bodypart C: C: --16820115-1435684603#2306 C: Content-Type: image/TIFF-F C: Content-Tranfer-Encoding: BASE64 C: Content-Description: FAX C: C: ABAA745HDKLSW932ALSDL3ANCVSASDFLALSDFA C: 87AASS2999499ASDANASDF0000ASDFASDFNANN C: 87BBHDXBADS00288SADFNAZBZNNDNNSNNA11A0 C: H8V73KS0C8JS6BFJEH78CDWWDUJEDF7JKES8== C: --16820115-1435684603#2306-- C: . S: 250 Okay C: QUIT S: 221 Goodbye 6. Conclusion With this proposal we try to create a standard encoding for PSTN addresses within global e-mail transport system. The proposal requires no changes to existing e-mail software. An update to existing MIXER gateways specification is envisaged, to extend accessibility also to X.400 fax gateway services in a transparent way. 7. Security Considerations This document specifies a means by which PSTN addresses can be encoded into e-mail addresses. As routing of e-mail messages is determined by Domain Name System (DNS) information, a succesful attack on this service could force the mail path via some particular gateway or message transfer agent where mail security can be affected by compromised software. There are several means by which an attacker might be able to deliver incorrect mail routing information to a client. These include: (a) compromise of a DNS server, (b) generating a counterfeit response to a client's DNS query, (c) returning incorrect "additional information" in response to an unrelated query. Clients SHOULD ensure that mail routing are based only on authoritative answers. Once DNS Security mechanisms [RFC 2065] become more widely deployed, clients SHOULD employ those mechanisms to verify the authenticity and integrity of mail routing records. Some PSTN service require dialing of private codes, like Personal Identification Numbers, to access special services. As e-mail addresses are transmitted without encoding over the MTAs transport service, this could allow unauthorized people to gain access to these codes when used inside local-phone. Use of double key encryption techniques for local-phone can solve these security problem. 8. Author's Address Claudio Allocchio Sincrotrone Trieste SS 14 Km 163.5 Basovizza I 34012 Trieste Italy RFC822: Claudio.Allocchio@elettra.trieste.it X.400: C=it;A=garr;P=Trieste;O=Elettra; S=Allocchio;G=Claudio; Phone: +39 40 3758523 Fax: +39 40 3758565 A. Fax cover generation issues In electronic mail world, messages contain an header which gives information about different items: some of them are intended for message identification, while others contain information usable by the recipient. The equivalent of the message headers for faxes is the fax cover, as it also conveys similar information. Moreover for faxes there are sometimes legal and official requirements which makes compulsory the generation of certain information of the fax cover. The fax cover generation is a complex topic and needs a detailed study. In this appendix we only define some methods and equivalences for fax cover generation starting from RFC822 message headers and we suggest some examples on how pstn-recipient optional fields can be used on the fax cover. For the complete description of fax cover generation methods, please refer to [document in preparation]. A.1 Use of message header fields for cover generation In this section we define a set of message headers which should be included in fax message cover. These headers will be included for all recipients of the fax message. The following header fields, when present, must be included into the generated fax cover page: Date Message-Id Reply-To Sensitivity From Importance Subject To Cc Bcc NOTE: if fax message is generated from a Bcc destination address, "blind carbon copy" rules apply, i.e. other recipients must not be present on fax cover. Any other header field may be included, when present, into the generated fax cover page. A.2 Cover page elements generated from pstn-recipient information Using the optional pstn-recipient information, the sender can specify further detailed information to be used (also for) fax cover generation. This information will be included only on the fax cover page being generated for the specific pstn-mbox. A.2.1 recipient-name The recipient-name field, if present, must be included on the fax cover page. The field must be used to specify the name of the intended fax recipient. A.2.2 recipient-qualifier The recipient-qualifier field, if present, should be included on the fax cover page. Due to its "label" = "value" format, it is suggested to generate fax cover fields in a consistent syntax, for example: label: value A set of "label" human readable descriptions for x400-label is given in ITU F.401, tables B-1/F.401, B-2/F.401, B-3/F.401; they could suggest a consistent method for some fax cover fields representation. B. Recipient identification for non fax services. The same set of suggestions given in the above appendix A can also be easily applied to other services which could use this addressing specification. In particular the pstn-recipient information could be used by voice-related service to identify the real recipient of the voice message, or to specify the recipient of a GSM SMS memo. As specific cases are strictly related to specific services, we cannot define here additional details. However the guidelines of appendix A should be adopted as a basis. C. References RFC821 Simple Mail Transfer Protocol. J. Postel. (August 1982) RFC822 Standard for the format of ARPA Internet text messages. D. Crocker. (August 1982) RFCxxxx (DRAFT-IETF-DRUMS-MSG-FMT-xx.TXT) Message Format Standard. P. Resnick. (xxxx 199x) RFCxxxx (DRAFT-IETF-DRUMS-SMTPUPD-xx.TXT) Simple Mail Transfer Protocol. J. C. Klensin, D. P. Mann. (xxxx 199x) RFCxxxx (DRAFT-KILLE-MIXER-RFC1327BIS-xx.TXT) MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME. S.E. Kille. (xxxx 199x) RFC1035 Domain names - implementation and specification. P.V. Mockapetris. (November 1987) RFC2065 Domain Name System Security Extensions. D. Eastlake, 3rd, C. Kaufman. (January 1997) RFCxxxx (DRAFT-IETF-DRUMS-ABNF-xx.TXT) Augmented BNF for Syntax Specifications: ABNF. D.Crocker, P. Overell (xxxx 199x) RFC1528 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures. C. Malamud & M. Rose. (October 1993) ITU F.401 - Message Handling Services: Naming and Addressing for Public Massage Handling Service; reccommendation F.401 (August 1992) ITU F.423 - Message Handling Services: Intercommunication Between the Interpersonal Messaging Service and the Telefax Service; reccommendation F.423 (August 1992) ITU E.164 - Numbering plan for the ISDN era; recommendation E.164/I.331 (August 1991) ETSI I-ETS 300,380 - Universal Personal Telecommunication (UPT): Access Devices Dual Tone Multi Frequency (DTMF) sender for acoustical coupling to the microphone of a handset telephone (March 1995)