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).
Abstract
This 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.
This specification defines message-based facsimile communication over the Internet. It describes a minimum set of capabilities, taking into account those of typical facsimile devices and PCs that can generate facsimile data.
Toyoda, et al. Standards Track [Page 1]
RFC 3965 A Simple Mode of Facsimile December 2004
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.
A facsimile-capable device that uses T.4 [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 provides for communication between each of the following combinations:
Internet mail => Network printer Internet mail => Offramp gateway (forward to G3Fax) Network scanner => Network printer Network scanner => Offramp gateway (forward to G3Fax) Network scanner => Internet mail
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [13].
The set of conventions necessary to achieve facsimile-compatible service covers basic data transport, document data formats, message (document) addressing, delivery confirmation, and message security. In this section, the first 4 are covered. The remainder are covered in following sections, along with additional details for addressing and formats.
Data transfer MAY be achieved using standard Internet mail transfer mechanisms [1, 3]. The format of addresses MUST conform to the RFC 821 <addr-spec> and RFC 822 <mailbox> Internet mail standards [1, 2, 3].
A gateway translates between dissimilar environments. For IFax, a gateway connects between Internet mail and the T.4/GSTN facsimile. Gateways can service multiple T.4/GSTN facsimile users or can service only one. In the former case, they serve as a classic "mail transfer agent" (MTA) and in the latter as a classic "mail user agent" (UA). An onramp is a gateway which connects from T.4/GSTN facsimile to Internet mail. An offramp is a gateway which connects from Internet mail to T.4/GSTN facsimile. Behavior of onramps is out of scope for this specification.
Toyoda, et al. Standards Track [Page 3]
RFC 3965 A Simple Mode of Facsimile December 2004
This specification describes the Internet mail service portion of offramp addressing, confirmation and failure notification. Details are provided in later sections.
An offramp gateway that operate as an MTA serving multiple users SHOULD use SMTP; a gateway that operates as a UA serving a single mail recipient MAY use a mailbox access protocol such as POP [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.
IFax devices MUST be compliant with 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.
The data format of the facsimile image is based on the minimum set of TIFF for Facsimile [5], also known as the S profile. Such facsimile data are included in a MIME object by use of the image/TIFF sub-type [12]. Additional rules for the use of TIFF for Facsimile, for the message-based Internet facsimile application, are defined later.
A single multi-page document SHOULD be sent as a single multi- page TIFF file, even though recipients MUST process multipart/mixed containing multiple TIFF files. If multipart content is present and processing of any part fails, then processing for the entire message is treated as failing, per [Processing failure] below.
IFax devices with limited capabilities might be unable to process the content of a message. If this occurs it is important to ensure that the message is not lost without any notice. Notice MAY be provided in any appropriate fashion, and the exact handling is a local matter. (See Appendix A, second bullet.)
When a G3Fax device is identified by a telephone number, the entire address used for the G3fax device, including the number and offramp host reference MUST be contained within standard Internet mail transport fields, such as RCPT TO and MAIL FROM [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).
Toyoda, et al. Standards Track [Page 5]
RFC 3965 A Simple Mode of Facsimile December 2004
The telephone number format SHOULD conform to [7, 8]. Other formats MUST be syntactically distinct from [7, 8].
Sending IFax devices MUST be able to write minimum set TIFF files, per the rules for creating minimum set TIFF files defined in TIFF for Facsimile (the S profile) [5], which is also compatible with the specification for the minimum subset of TIFF-F in [14]. 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.
This specification is based on use of existing Internet mail. To maintain interoperability with Internet mail, any security to be provided should be part of the of the Internet security infrastructure, rather than a new mechanism or some other mechanism outside of the Internet infrastructure.
Both Internet mail and G3Fax standards and operational services have their own set of threats and countermeasures. This section attends only to the set of additional threats which ensue from integrating the two services. This section reviews relevant concerns about Internet mail for IFax environments, as well as considering the potential problems which can result of integrating the existing G3Fax service with Internet mail.
The actual sender of the message might not be the same as that specified in the Sender or From fields of the message content headers or the MAIL FROM address from the SMTP envelope.
In a tightly constrained environment, sufficient physical and software controls may be able to ensure prevention of this problem. The usual solution is through encryption-based authentication, either for the channel or associated with the object, as discussed below.
Toyoda, et al. Standards Track [Page 6]
RFC 3965 A Simple Mode of Facsimile December 2004
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.
In addition to the resources normally consumed for email (CPU cycles and disk), offramp facsimile causes an outdial which often imposes significant resource consumption, such as financial cost. Techniques for establishing authorization of the sender are essential to those offramp facsimile services that need to manage such consumption.
Due to the consumption of these resources by dialout, unsolicited bulk email which causes an outdial is undesirable.
Offramp gateways SHOULD provide the ability to authorize senders in some manner to prevent unauthorized use of the offramp. There are no standard techniques for authorization using Internet protocols.
Typical solutions use simple authentication of the originator to establish and verify their identity and then check the identity against a private authorization table.
Originator authentication entails the use of weak or strong mechanisms, such as cleartext keywords or encryption-based data-signing, respectively, to determine and validate the identify of the sender and assess permissions accordingly.
Other control mechanisms which are common include source filtering and originator authentication. Source filtering entails offramp gateway verification of the host or network originating the message and permitting or prohibiting relaying accordingly.
Confidential information about the sender necessary to dial a G3Fax recipient, such as sender's calling card authorization number, might be disclosed to the G3Fax recipient (on the cover page), such as through parameters encoded in the G3Fax recipients address in the To: or CC: fields.
Senders SHOULD be provided with a method of preventing such disclosure. As with mechanisms for handling unsolicited faxes, there are not yet standard mechanisms for protecting such information.
Toyoda, et al. Standards Track [Page 7]
RFC 3965 A Simple Mode of Facsimile December 2004
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.
In many countries, there is a legal requirement that the "sender" be disclosed on a facsimile message. Email From addresses are trivial to fake, so that using only the MAIL FROM [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.
Users of G3Fax devices have an expectation of a level of message privacy which is higher than the level provided by Internet mail without security enhancements.
This expectation of privacy by G3Fax users SHOULD be preserved as much as possible.
Sufficient physical and software control may be acceptable in constrained environments. The usual mechanism for ensuring data confidentially entail encryption, as discussed below.
With email, bounces (delivery failures) are typically returned to the sender and not to a publicly-accessible email account or printer. With facsimile, bounces do not typically occur. However, with IFax, a bounce could be sent elsewhere (see section [Delivery Failure]), such as a local system administrator's account, publicly-accessible account, or an IFax printer (see also [Traffic Analysis]).
Eavesdropping of senders and recipients is easier on the Internet than GSTN. Note that message object encryption does not prevent traffic analysis, but channel security can help to frustrate attempts at traffic analysis.
As with all email, an IFax message can be viewed as it traverses internal networks or the Internet itself.
Virtual Private Networks (VPN), encrypted tunnels, or transport layer security can be used to prevent eavesdropping of a message as it traverses such networks. It also provides some protection against traffic analysis, as described above.
At the current time various protocols exist for performing the above functions, and are only mentioned here for information. Such protocols are IPSec [17] and TLS [18].
As with all email, an IFax message can be viewed while it resides on, or while it is relayed through, an intermediate Mail Transfer Agent.
Message encryption can be used to provide end-to-end encryption.
At the current time two protocols are commonly used for message encryption and are only mentioned here for information. The two protocols are PGP-MIME [16] and S/MIME [19].
This specification was produced by the Internet Engineering Task Force Fax Working Group, over the course of more than one year's online and face-to-face discussions. As with all IETF efforts, many people contributed to the final product.
Active for this document were: Steve Huston, Jeffrey Perry, Greg Vaudreuil, Richard Shockey, Charles Wu, Graham Klyne, Robert A. Rosenberg, Larry Masinter, Dave Crocker, Herman Silbiger, James Rafferty.
* IFax senders are not required to be able to send text/plain messages (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.
Hiroyuki Ohno National Institute of Information and Communications Technology 4-2-1, Nukui-Kitamachi, Koganei, Tokyo, 184-8795, Japan
Fax: +81 42 327 7941 EMail: hohno@ohnolab.org
Jun Murai Keio University 5322 Endo, Fujisawa Kanagawa 252 Japan
Fax: +81 466 49 1101 EMail: jun@wide.ad.jp
Dan Wing 170 W. Tasman Drive San Jose, CA 95134 USA
Phone: +1 408 525 5314 EMail: dwing@cisco.com
Toyoda, et al. Standards Track [Page 13]
RFC 3965 A Simple Mode of Facsimile December 2004
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- ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.