Network Working Group K. Toyoda Request for Comments: 3965 H. Ohno Obsoletes: 2305 J. Murai Category: Standards Track WIDE Project D. Wing Cisco December 2004 A Simple Mode of Facsimile Using 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 (2004).
AbstractThis specification provides for "simple mode" carriage of facsimile data using Internet mail. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, Multipurpose Internet Mail Extensions (MIME), and Tagged Image File Format (TIFF) for Facsimile. It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them. This document is a revision of RFC 2305. There have been no technical changes.
A G3Fax device has substantial restrictions due to specifications in the standards, such as for timers. This specification defines a profile for Internet mail, rather than creating a distinct "facsimile over the Internet" service. The semantics resulting from the profile are designed to be compatible with facsimile operation over the general switched telephone network, so that gateways between facsimile and Internet mail can operate with very high fidelity. The reason for developing this capability as an email profile is to permit interworking amongst facsimile and email users. For example, it is intended that existing email users be able to send normal messages to lists of users, including facsimile-based recipients, and that other email recipients shall be able to reply to the original and continue to include facsimile recipients. Similarly, it is intended that existing email software work without modification and not be required to process new, or different data structures, beyond what is normal for Internet mail users. Existing email service standards are used, rather than replicating mechanisms which are more tailored to existing facsimile standards, to ensure this compatibility with existing email service. 15] and the general switched telephone network (GSTN) is called a "G3Fax device" in this specification. An "IFax device" is an Internet-accessible device capable of sending, receiving or forwarding Internet faxes. A message can be sent to an IFax device using an Internet mail address. A message can be sent to a G3Fax device using an Internet mail address; the message MAY be forwarded via an IFax offramp gateway.
This specification describes the Internet mail service portion of offramp addressing, confirmation and failure notification. Details are provided in later sections. 6] or similar mailbox access protocols. NOTE: An offramp gateway that relays mail based on addressing information needs to ensure that it uses addresses supplied in the MTA envelope, rather than from elsewhere, such as addresses listed in the message content headers. RFC 2822 and RFC 1123, which define the format of mail headers. The header of an IFax message SHOULD include Message-ID and MUST include all fields required by [2, 3], such as DATE and FROM. 4], except as noted in Appendix A. 5], also known as the S profile. Such facsimile data are included in a MIME object by use of the image/TIFF sub-type . Additional rules for the use of TIFF for Facsimile, for the message-based Internet facsimile application, are defined later.
9]. NOTE: Internet mail transported via SMTP MUST contain a MAIL FROM address appropriate for delivery of return notices. (See section 5.2.6.) Appendix A, second bullet.) 1, 3]. The address MAY be contained within message content fields, such as <authentic> and <destination> [2, 3], as appropriate. As for all Internet mail addresses, the left-hand-side (local-part) of an address is not to be interpreted except by the MTA that is named on the right-hand-side (domain).
The telephone number format SHOULD conform to [7, 8]. Other formats MUST be syntactically distinct from [7, 8]. 5], which is also compatible with the specification for the minimum subset of TIFF-F in . Receiving IFax devices MUST be able to read minimum set TIFF files. A sender SHOULD NOT use TIFF fields and values beyond the minimum subset of TIFF for Facsimile unless the sender has prior knowledge of other TIFF fields or values supported by the recipient. The mechanism for determining capabilities of recipients is beyond the scope of this document.
It should be recognized that SMTP implementations do not provide inherent authentication of the senders of messages, nor are sites under obligation to provide such authentication. End-to-end approaches such as S/MIME and PGP/MIME are currently being developed within the IETF. These technologies can provide such authentication.
Out-of-band communication of authorization information or use of encrypted data in special fields are the available non-standard techniques. Typically authorization needs to be associated to specific senders and specific messages, in order to prevent a "replay" attack which causes and earlier authorization to enable a later dial-out by a different (and unauthorized) sender. A non-malicious example of such a replay would be to have an email recipient reply to all original recipients -- including an offramp IFax recipient -- and have the original sender's authorization cause the reply to be sent. 1, 3] or From [2, 3] header is not sufficient. Offramps SHOULD ensure that the recipient is provided contact information about the offramp, in the event of problems. The G3Fax recipient SHOULD be provided with sufficient information which permits tracing the originator of the IFax message. Such information might include the contents of the MAIL FROM, From, Sender and Reply-To headers, as well as Message-Id and Received headers. Delivery Failure]), such as a local system administrator's account, publicly-accessible account, or an IFax printer (see also [Traffic Analysis]).
 Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.  Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.  Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J. Rafferty, "File Format for Internet Fax", RFC 3949, November 2004.  Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.  Allocchio, C., "Minimal GSTN address format for Internet mail", RFC 3191, October 2001.  Allocchio, C., "Minimal fax address format for Internet mail", RFC 3192, October 2001.  Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.  Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.  Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.  Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration", RFC 3302, September 2002.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) -- F Profile for Facsimile", RFC 2306, March 1998.  ITU-T (CCITT), "Standardization of Group 3 facsimile apparatus for document transmission", ITU-T (CCITT), Recommendation T.4.
 Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.  Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.  Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.  Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
RFC 2049 requirement 4), although IFax recipients are required to accept such messages, and to process them. * IFax recipients are not required to offer to put results in a file. (Also see 2.3.2.) * IFax recipients MAY directly print/fax the received message rather than "display" it, as indicated in RFC 2049. RFC 2440 | | | | "Security Architecture for the IP", RFC 2401 | | | | "SMTP Service Extensions for Secure SMTP over | | | | TLS", RFC 2487 | | | | "S/MIME Version 2 Message Specification", | | | | RFC 2311 | +----+----------+-------------------------------------------------+ | 4. |REFERENCES| Removed the following references because they | | | | are non-normative | | | | "SMTP Service Extensions for Delivery Status | | | | Notifications", RFC 1891 | | | | "Internet Message Access Protocol", RFC 2060 | +----+----------+-------------------------------------------------+ | 5. |REFERENCES| Separated REFERENCES to the normative and | | | | non-normative | +----+----------+-------------------------------------------------+ | 6. |Appendix | Changed the phrase from "NOT REQUIRED" to | | | A | "not required" | +----+----------+-------------------------------------------------+ | 7. |Appendix | Added "Appendix B List of edits to RFC 2305" | +----+----------+-------------------------------------------------+
Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.