RFC 3965

RFC 3965: A Simple Mode of Facsimile Using Internet Mail 📠✨

okay bestie, the basics first 💅 This is RFC 3965, A Simple Mode of Facsimile Using Internet Mail, from the Network Working Group. It was written by K. Toyoda, H. Ohno, and J. Murai of the WIDE Project, plus D. Wing from Cisco 🎀. It's a Standards Track doc dated December 2004, and it obsoletes RFC 2305 🦋

Status of this Memo 📜

this doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 for the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited 🌈

Copyright Notice ©️

Copyright (C) The Internet Society (2004).

Abstract 🌸

this spec is all about "simple mode" carriage of facsimile data over Internet mail 💌 extensions to this document will follow. it uses standard stuff like TCP/IP, Internet mail protocols, Multipurpose Internet Mail Extensions (MIME), and Tagged Image File Format (TIFF) for Facsimile 🧚 it can send images to other Internet-aware fax devices, and also to Internet-native systems like PCs with common email readers that can handle MIME mail and TIFF for Facsimile data. the whole point is helping existing fax devices, Internet mail agents, and the gateways that connect them all get along 💖

this document is a revision of RFC 2305. there have been no technical changes ✨

1. Introduction 🎀

this spec defines message-based facsimile communication over the Internet 💜 it describes a minimum set of capabilities, taking into account what typical fax devices and PCs that can generate facsimile data are able to do 💅

okay so, a G3Fax device has some serious restrictions because of the standards, like the ones for timers 😭 this spec defines a profile for Internet mail instead of making a separate "facsimile over the Internet" service 🦋 the semantics that come out of the profile are designed to be compatible with facsimile operation over the general switched telephone network, so gateways between facsimile and Internet mail can work with very high fidelity 🌟

the reason for building this as an email profile is to let facsimile and email users interwork 🫶 for example, existing email users should be able to send normal messages to lists of users, including fax-based recipients, and other email recipients should be able to reply to the original and keep the fax recipients in the loop 💌 existing email software should also work without modification, and it shouldn't have to process new or different data structures beyond what normal Internet mail users already deal with 🌸 existing email service standards get used instead of copying mechanisms that are more tailored to existing facsimile standards, so this stays compatible with existing email service 🔥

1.1. Services 🧚

a facsimile-capable device that uses T.4 [15] and the general switched telephone network (GSTN) is called a "G3Fax device" in this spec 📠 an "IFax device" is an Internet-accessible device that can send, receive, or forward 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 too, and the message MAY be forwarded via an IFax offramp gateway 🦋

1.2. Cases 💅

this spec provides for communication between each of these 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

1.3. Key Words 🔑

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]. 🌈

2. Communication Protocols 🌷

the set of conventions needed for facsimile-compatible service covers basic data transport, document data formats, message (document) addressing, delivery confirmation, and message security 👑 this section covers the first 4 of those. the rest get covered in later sections, along with extra details on addressing and formats 💜

2.1. Transport 🚚

this section describes the mechanisms involved in transport between IFAX devices 📬

2.1.1. Relay 🔁

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] 💌

2.1.2. Gateway 🌉

a gateway translates between dissimilar environments 🧚 for IFax, a gateway connects Internet mail and T.4/GSTN facsimile. gateways can serve multiple T.4/GSTN facsimile users, or they can serve only one. when they serve multiple users they act like a classic "mail transfer agent" (MTA), and when they serve just one they act like a classic "mail user agent" (UA) 🎀 an onramp is a gateway that connects from T.4/GSTN facsimile to Internet mail. an offramp is a gateway that connects from Internet mail to T.4/GSTN facsimile 🦋 behavior of onramps is out of scope for this spec 🙈

this spec describes the Internet mail service portion of offramp addressing, confirmation, and failure notification 💖 the details are in later sections 💅

2.1.3. Mailbox protocols 📮

an offramp gateway that operates 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. 🚨

2.2. Formats 🎨

2.2.1. 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 🫶

2.2.2. MIME 🧁

IFax devices MUST be compliant with MIME [4], except as noted in Appendix A 🌈

2.2.3. Content 🖼️

the data format of the facsimile image is based on the minimum set of TIFF for Facsimile [5], also known as the S profile 📠 this facsimile data gets included in a MIME object by using the image/TIFF sub-type [12]. additional rules for using TIFF for Facsimile in the message-based Internet facsimile application are defined later 🦋

2.2.4. Multipart 🧩

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 😭

2.3. Error Handling 🚨

2.3.1. Delivery failure 📬

this section describes existing requirements for Internet mail, rather than special requirements for IFax devices 💅

in the event of relay failure, the sending relay MUST generate a failure message, which SHOULD be in the format of a DSN [9] 💌

NOTE: Internet mail transported via SMTP MUST contain a MAIL FROM address appropriate for delivery of return notices. (See section 5.2.6.) 🙈

2.3.2. Processing Failure 🫣

IFax devices with limited capabilities might be unable to process the content of a message 😭 if this happens, it's important to make sure the message isn't 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.) ✨

3. Addressing 📍

3.1. Classic Email Destinations 💌

messages being sent to normal Internet mail recipients will use standard Internet mail addresses, without additional constraints 🎀

3.2. G3Fax Devices 📠

G3Fax devices are accessed via an IFAX offramp gateway, which performs any authorized telephone dial-up 🧚

3.3. Address Formats Used by Offramps 🔢

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) 🙈

the telephone number format SHOULD conform to [7, 8]. other formats MUST be syntactically distinct from [7, 8] 🌈

4. Image File Format 🖼️

sending IFax devices MUST be able to write minimum set TIFF files, following the rules for creating minimum set TIFF files defined in TIFF for Facsimile (the S profile) [5]. that's 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 the capabilities of recipients is beyond the scope of this document 🫶

5. Security Considerations 🔐

5.1. General Directive 🛡️

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 🔥

5.2. Threats and Problems 💀

both Internet mail and G3Fax standards and operational services have their own set of threats and countermeasures 😭 this section only covers the additional threats that come from integrating the two services. it reviews relevant concerns about Internet mail for IFax environments, and it considers the potential problems that can result from integrating the existing G3Fax service with Internet mail 🚨

5.2.1. Spoofed Sender 🎭

the actual sender of the message might not be the same as the one 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 prevent this problem. the usual solution is encryption-based authentication, either for the channel or associated with the object, as discussed below 🔐

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 🌟

5.2.2. Resources Consumed by Dialout

okay so besties, email alone already eats CPU cycles and disk space 💅, but offramp fax is next level because it has to actually dial out 📞. That outdial can cost real money, so authorization for the sender is essential for any offramp fax service that needs to manage that spending 💸.

Because dialing out burns those resources, unsolicited bulk email that triggers an outdial is a big no from me 🙅‍♀️.

Offramp gateways SHOULD provide a way to authorize senders so random people can't use the offramp 🚪✨. Honestly there are no standard authorization techniques for Internet protocols yet, so it's a bit of a wild west 🤠.

The usual move is simple authentication: you establish and verify who the sender is, then check them against a private authorization table 📋.

Originator authentication can use weak mechanisms, like cleartext keywords, or strong mechanisms, like encryption-based data-signing 🔐. Either way, the goal is to work out who the sender is and set their permissions to match 🫶.

Other common control mechanisms include source filtering and originator authentication 🧱. Source filtering means the offramp gateway checks which host or network the message came from, then allows or blocks relaying based on that 🌐.

5.2.3. GSTN Authorization Information

ngl this one is a little scary 😭. Confidential info about the sender that's needed to dial a G3Fax recipient, like the sender's calling card authorization number, could end up disclosed to the G3Fax recipient on the cover page 📄. It could sneak in through parameters encoded in the G3Fax recipient's address in the To: or CC: fields 👀.

Senders SHOULD be given a way to prevent that kind of disclosure 🙅‍♀️. Same deal as with unsolicited faxes: there aren't yet standard mechanisms for protecting this info 😤.

The non-standard options that exist are out-of-band communication of authorization information, or using encrypted data in special fields 🗝️.

Authorization typically needs to be tied to specific senders and specific messages. Otherwise you get a "replay" attack, where an earlier authorization enables a later dial-out by a different, unauthorized sender 🚨. A totally non-malicious example of this: an email recipient replies to all the original recipients, including an offramp IFax recipient, and the original sender's authorization ends up making that reply go out 📨. Chaos, but innocent chaos 🌀.

5.2.4. Sender Accountability

In many countries there's a legal requirement that the "sender" be disclosed on a facsimile message ⚖️. Here's the tea: email From addresses are trivial to fake 🫠, so relying only on the MAIL FROM [1, 3] or From [2, 3] header is not enough 🙅‍♀️.

Offramps SHOULD make sure the recipient gets contact information about the offramp in case something goes wrong 📞💖.

The G3Fax recipient SHOULD get enough info to trace where the IFax message came from 🕵️‍♀️. That info might include the contents of the MAIL FROM, From, Sender and Reply-To headers, plus the Message-Id and Received headers 📬.

5.2.5. Message Disclosure

Okay, G3Fax users expect a higher level of message privacy than you get with Internet mail without security enhancements 🔒. They're counting on it 🥺.

That privacy expectation SHOULD be preserved as much as possible 🛡️.

In constrained environments, sufficient physical and software control may be acceptable 🏰. Otherwise the usual way to keep data confidential is encryption, which we'll get to below 🔐✨.

5.2.6. Non Private Mailboxes

With email, bounces (delivery failures) normally go back to the sender, not to a publicly accessible email account or printer 📭. With facsimile, bounces usually don't happen at all 🤷‍♀️. But with IFax, a bounce could be sent somewhere else (see section [Delivery Failure]) 😬, like a local system administrator's account, a publicly accessible account, or an IFax printer 🖨️. Also see [Traffic Analysis] 👀.

5.2.7. Traffic Analysis

Eavesdropping on senders and recipients is way easier on the Internet than on the GSTN 👂. Message object encryption doesn't stop traffic analysis, but channel security can help frustrate those attempts 🛡️✨.

5.3. Security Techniques

There are two basic approaches to encryption-based security that support authentication and privacy 🔐💜:

5.3.1. Channel Security

Just like all email, an IFax message can be seen while it travels through internal networks or the Internet itself 👁️.

VPNs, encrypted tunnels, or transport layer security can stop eavesdropping while the message is in transit 🚇. They also give some protection against traffic analysis, as described above 🦋.

Right now there are various protocols that do these jobs, and they're only mentioned here for information 📚. Those protocols are IPSec [17] and TLS [18] 🌸.

5.3.2. Object Security

Same as before, an IFax message can be viewed while it sits on, or gets relayed through, an intermediate Mail Transfer Agent 📮.

Message encryption can give you end-to-end encryption 🫶🔐.

Two protocols are commonly used for message encryption right now, and again they're just mentioned for information 💅. Those two are PGP-MIME [16] and S/MIME [19] ✨.

6. References

6.1. Normative References

[1] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC 2821, April 2001.

[2] Resnick, P., Editor, "Internet Message Format", RFC 2822, April 2001.

[3] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.

[4] Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.

[5] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J. Rafferty, "File Format for Internet Fax", RFC 3949, November 2004.

[6] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.

[7] Allocchio, C., "Minimal GSTN address format for Internet mail", RFC 3191, October 2001.

[8] Allocchio, C., "Minimal fax address format for Internet mail", RFC 3192, October 2001.

[9] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.

[10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

[11] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.

[12] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration", RFC 3302, September 2002.

[13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

6.2. Informative References

[14] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) -- F Profile for Facsimile", RFC 2306, March 1998.

[15] ITU-T (CCITT), "Standardization of Group 3 facsimile apparatus for document transmission", ITU-T (CCITT), Recommendation T.4.

[16] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.

[17] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.

[18] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.

[19] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.

7. Acknowledgements

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 🌟💖.

Appendix A: Exceptions to MIME ✨

• 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 🖨️💜.

Appendix B: List of edits to RFC 2305 🎀

+----+----------+-------------------------------------------------+
| No.| Section  |             Edit  July 27, 2001                 |
+----+----------+-------------------------------------------------+
| 1. |Copyright | Updated copyright from "1998" to "1999,2000"    |
|    |Notice    |                                                 |
+----+----------+-------------------------------------------------+
| 2. |SUMMARY   | Changed the phrase "over the Internet" to       |
|    |          |               "using Internet mail"             |
+----+----------+-------------------------------------------------+
| 3. |5         | Changed the paragraphs regarding to the         |
|    |          | following references to make them very          |
|    |          | non-normative.                                  |
|    |          |  "OpenPGP Message Format", 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"   |
+----+----------+-------------------------------------------------+

Authors' Addresses ✨

okay bestie, these are the four humans who wrote this RFC, and yes, you can literally email them 💌🫶

Kiyoshi Toyoda 🌸

Kiyoshi Toyoda
Panasonic Communications Co., Ltd.
4-1-62 Minoshima Hakata-ku
Fukuoka 812-8531 Japan

Fax:   +81 92 477 1389
EMail: toyoda.kiyoshi@jp.panasonic.com

Hiroyuki Ohno 🦋

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 🧚

Jun Murai
Keio University
5322 Endo, Fujisawa
Kanagawa 252 Japan

Fax:   +81 466 49 1101
EMail: jun@wide.ad.jp

Dan Wing 💜

Dan Wing
170 W. Tasman Drive
San Jose, CA 95134 USA

Phone: +1 408 525 5314
EMail: dwing@cisco.com

---

Full Copyright Statement 💅

so the legal bit. the copyright is held by 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 next part is the important disclaimer, so read it carefully 🙈 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 doesn't take a side on whether any IPR (patents, copyrights, that kind of thing) covers the tech in here, or whether you can get a license for it. it also hasn't done any independent digging to find out what rights might exist, so no promises there 🤷‍♀️ info on how the IETF handles rights in its documents lives in BCP 78 and BCP 79.

If you want IPR disclosures that were filed with the IETF Secretariat, or any licenses that have been promised, or the results of someone trying to get a general license or permission for implementers or users, you can check the IETF's online IPR repository at http://www.ietf.org/ipr 🌈

the IETF also invites anyone to flag any copyrights, patents or patent applications, or other proprietary rights that might cover tech needed to implement this standard. send that to ietf-ipr@ietf.org 💌

---

Acknowledgement ⭐

last one, and it's a sweet one 🥹 funding for the RFC Editor function is currently coming from the Internet Society. thank you, Internet Society 🫶