home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- 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 <domain>
- 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 2304, 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]
-
-