From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2304.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc2304.txt (limited to 'doc/rfc/rfc2304.txt') diff --git a/doc/rfc/rfc2304.txt b/doc/rfc/rfc2304.txt new file mode 100644 index 0000000..d0d2f0b --- /dev/null +++ b/doc/rfc/rfc2304.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group C. Allocchio +Request for Comments: 2304 GARR-Italy +Category: Standards Track March 1998 + + + + + Minimal FAX address format in Internet Mail + + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +IESG NOTE + + This memo describes a simple method of encoding PSTN addresses of + facsimile devices in the local-part of Internet email addresses. + + As with all Internet mail addresses, the left-hand-side (local- part) + of an address generated according to this specification, is not to be + interpreted except by the MTA that is named on the right-hand-side + (domain). + +1. Introduction + + Since the very first e-mail to fax gateway objects appeared, a number + of different methods to specify a fax address as 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. + + + + + + +Allocchio Standards Track [Page 1] + +RFC 2304 Minimal FAX address format March 1998 + + + This memo describes the MINIMAL addressing method and standard + extensions to encode FAX addresses in e-mail addresses, as required + in reference [13]. The opposite problem, i.e. to allow a traditional + numeric-only fax device user to access the e-mail transport service, + is not discussed here. + + All implementations supporting this FAX over e-mail address format + MUST support as a minimum the specification described in this + document. The generic complex case of converting the whole PSTN + addressing in e-mail is out of scope in this minimal specification: + there is some work in progress in the field, where also a number of + standard optional extensions are being defined. + + In this document the formal definitions are described using ABNF + syntax, as defined into [7]. We will also use some of the "CORE + DEFINITIONS" defined in "APPENDIX A - CORE" of that document. The + exact meaning of the capitalised words + + "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" + + is defined in reference [6]. + +2. Minimal Fax address + + The "service-selector" defined in section 2 of reference [13] for the + fax service is: + + service-selector = "FAX" + + The minimal addressing for the fax service also requires support for + a "qualif-type1" element (see section 2 of reference [13]). This + element is an OPTIONAL element of the fax address, but its support, + when present, is REQUIRED: + + qualif-type1 = "/" t33-sep "=" sub-addr + + where + + t33-sep = "T33S" + + sub-addr = 1*( DIGIT ) + + Thus, the minimal specification of a fax in e-mail address is: + + fax-address = fax-mbox [ "/T33S=" sub-addr ] + + fax-mbox = "FAX=" global-phone + + + +Allocchio Standards Track [Page 2] + +RFC 2304 Minimal FAX address format March 1998 + + + Note: + See section 4.1 in case multiple sub-addr per fax-mbox need to be + specified. + + The Minimal supported syntax for global-phone (as described in + section reference [13]) is: + + + global-phone = "+" 1*( DIGIT , written-sep ) + + written-sep = ( "-" / "." ) + + The use of other dialling schemas for PSTN numbers (like private + numbering plans or local dialling conventions) is also allowed. + However, this does not preclude nor remove the minimal compulsory + requirement to support the "global-phone" syntax as defined above. + + Any non "global-phone" dialling schema MUST NOT use the leading "+" + between the "=" sign and the dialling string. The "+" sign is + strictly reserved for the standard "global-phone" syntax. + + Note: + The specification of these different dialling schemas is out of + scope for this minimal specification. + + User specification of PSTN e-mail addresses will be facilitated if + they can insert these separators between dial elements like digits + etc. For this reason we allow them in the syntax the written-sep + element. + + Implementors' note: + Use of the written-sep elements is allowed, but not recommended. + Any occurences of written-sep elements in a pstn-mbox MUST be + ignored by all conformant implementations. User Agents SHOULD + remove written-sep elements before submitting messages to the + Message Transport System. + +2.2 Some examples of a minimal "fax-address" + + FAX=+3940226338 + + FAX=+12027653000/T33S=1387 + + FAX=+33-1-88335215 + + + + + + + +Allocchio Standards Track [Page 3] + +RFC 2304 Minimal FAX address format March 1998 + + +3. The e-mail address of the I-fax device: mta-I-fax + + An "I-fax device" has 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 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-fax + + mta-I-fax = domain + + For "domain" strings used in SMTP transmissions, the string MUST + conform to the requirements of that standard's + specifications [1], [3]. For "domain" strings used in message + content headers, the string MUST conform to the requirements of the + relevant standards [2], [3]. + + Note: in both cases, the standards permit use of "domain names" or + "domain literals" in addresses. + + +4. The fax-email + + The complete structure used to transfer a minimal FAX address over + the Internet e-mail transport system is called "fax-email". This + object is an e-mail address which conforms to RFC822 [2] and RFC1123 + [3] "addr-spec" syntax, with some extra structure which allows the + FAX number to be identified. + + fax-email = ["/"] fax-address ["/"] "@" mta-I-fax + + Implementors' note: + The optional "/" characters can result from other mail transport + services gateways, where it is also an optional element. + Implementations MUST accept the optional slashes but SHOULD NOT + generate them. Gateways are allowed to strip them off when + converting to Internet mail addressing. + + It is essential to remind that "fax-address" element MUST strictly + follow the "quoting rules" spcified in the relevant standards [2], + [3] + +4.1 Multiple subaddresses + + In case a particular service requires multiple T.33 subaddresses, and + these subaddresses need to be given on the same "fax-mbox", multiple + "fax-email" elements will be used. + + + +Allocchio Standards Track [Page 4] + +RFC 2304 Minimal FAX address format March 1998 + + + Implementors' note: + The UA could accept multiple subaddress elements for the same + global-phone, but it must generate multiple "fax-mbox" elements + when passing the message to the MTA. + +4.2 Some examples of minimal "fax-email" + + FAX=+3940226338@faxworld.org + + FAX=+12027653000/T33S=1387@faxworld.org + + /FAX=+33-1-88335215/@faxworld.org + +5. Conclusion + + This proposal creates a minimal standard encoding for FAX addresses + within the global e-mail transport system. The proposal requires no + changes to existing e-mail software. + +6. Security Considerations + + This document specifies a means by which FAX addresses can be encoded + into e-mail addresses. As routing of e-mail messages is determined by + Domain Name System (DNS) information, a successful 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 is based only on authoritative answers. Once DNS + Security mechanisms [5] become more widely deployed, clients SHOULD + employ those mechanisms to verify the authenticity and integrity of + mail routing records. + + 7. Author's Address + + Claudio Allocchio + Sincrotrone Trieste + SS 14 Km 163.5 Basovizza + I 34012 Trieste + Italy + + + + + + +Allocchio Standards Track [Page 5] + +RFC 2304 Minimal FAX address format March 1998 + + + 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 + +8. References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + August 1982. + + [2] Crocker, D., " Standard for the format of ARPA Internet text + messages", STD 11, RFC 822, August 1982. + + [3] Braden, R., "Requirements for Internet hosts - application and + support", RFC 1123, October 1989. + + [4] Malamud, C. and M. Rose, "Principles of Operation for the + TPC.INT Subdomain: Remote Printing -- Technical Procedures", RFC + 1528, October 1993. + + [5] Eastlake, D. and C. Kaufman, "Domain Name System Security + Extensions", RFC 2065, January 1997. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + + [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications", RFC 2234, November 1997. + + [8] ITU F.401 - Message Handling Services: Naming and Addressing for + Public Message Handling Service; recommendation F.401 (August + 1992) + + [9] ITU F.423 - Message Handling Services: Intercommunication + Between the Interpersonal Messaging Service and the Telefax + Service; recommendation F.423 (August 1992) + + [10] ITU E.164 - Numbering plan for the ISDN era; recommendation + E.164/I.331 (August 1991) + + [11] ITU T.33 - Facsimile routing utilizing the subaddress; + recommendation T.33 (July, 1996) + + [12] 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) + + + +Allocchio Standards Track [Page 6] + +RFC 2304 Minimal FAX address format March 1998 + + + [13] Allocchio, C., " Minimal FAX address format in Internet Mail", + RFC 2303, March 1998. + + [14] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping + between X.400 and RFC 822/MIME", RFC 2156, January 1998. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Allocchio Standards Track [Page 7] + +RFC 2304 Minimal FAX address format March 1998 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Allocchio Standards Track [Page 8] + -- cgit v1.2.3