RFC 2305

A Simple Mode of Facsimile Using Internet Mail

📅 published March 1998, from ietf

RFC 2305 🎀 A Simple Mode of Facsimile Using Internet Mail

okay bestie, this one is a Standards Track doc from March 1998 💅 written by K. Toyoda, H. Ohno, and J. Murai from the WIDE Project, plus D. Wing from Cisco 🌸. It's the spec for sending faxes as regular emails, and it's giving interop queen energy ✨. The title block doesn't say it obsoletes or updates anything, so this is a fresh start 🦋. This is part 1 of 3, so stay tuned 💜.

Status of this Memo 🌈

okay so this bit says it's an Internet standards track protocol for the community 🫶, and it wants discussion and suggestions for improvements 💬. If you want the current standardization state, go check the "Internet Official Protocol Standards" (STD 1) doc 📚. And distribution is unlimited, so share away 🍓.

The Internet Society owns the copyright here (1998), and all rights are reserved 💖.

SUMMARY ✨

okay so this section is the vibe check 💅. It's about "simple mode" carriage of fax data over the Internet 📠. Extensions are coming later 🔮. It uses stuff you already know and love: TCP/IP, Internet mail protocols [1, 2, 3], MIME [4, 16, 17], and TIFF for Facsimile [5,6,19] 🧚. It can send images to Internet-aware fax machines 🖨️, but also to Internet-native systems like PCs with email readers that handle MIME mail and TIFF for Facsimile data 💻. Basically it helps fax devices, mail agents, and the gateways between them all get along 🫶 iconic.

The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [7] 📖. That's the BCP 14 rule book, bestie 🔥.

1. SCOPE 🦋

This spec defines fax communication that's message-based over the Internet 📨. It sets a minimum set of capabilities, keeping typical fax devices and PCs that can make fax data in mind 🖥️✨.

A G3Fax device has real restrictions from the standards, like timers ⏱️. So this spec doesn't make some new "fax over the Internet" service. It defines a profile for Internet mail instead 💌. The semantics are built to match fax over the regular telephone network (GSTN), so gateways between fax and email can run with very high fidelity 🎯 no cap.

Why email? So fax users and email users can talk to each other 💬. Existing email users should be able to send normal messages to lists that include fax recipients 📋, and other email people should be able to reply and keep fax recipients in the loop 🔁. Existing email software should work without changes and shouldn't have to handle new or different data structures beyond what normal Internet mail users already handle 🙌. The spec uses existing email service standards instead of making new mechanisms tailored to fax, so that compatibility with email stays solid 💜.

1.1. Services 🌸

A facsimile-capable device that uses T.4 [8] and the GSTN is called a "G3Fax device" here 📠. An "IFax device" is an Internet-accessible device that can send, receive, or forward Internet faxes 🌐. You can send a message to an IFax device using an Internet mail address 💌. You can also send a message to a G3Fax device using an Internet mail address, and the message MAY be forwarded via an IFax offramp gateway 🚪.

1.2. Cases 🎀

This spec covers communication between each of these combos:

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

2. COMMUNICATION PROTOCOLS 💖

The conventions needed for fax-compatible service cover basic data transport, document data formats, message (document) addressing, delivery confirmation, and message security 🔐. This section covers the first four 🙌. The rest show up in later sections, along with more addressing and format details 📚.

2.1. Transport 🚗

This section is about the transport mechanisms between IFAX devices 🛣️.

2.1.1. Relay 🔁

Data transfer MAY use standard Internet mail transfer mechanisms [1, 3] ✉️. Address formats MUST conform to the RFC 821 <addr-spec> and RFC 822 <mailbox> Internet mail standards [1, 2, 3] 📜. No skipping this one, bestie 🫡.

2.1.2. Gateway 🌉

A gateway translates between dissimilar environments 🔀. For IFax, a gateway connects Internet mail and T.4/GSTN fax 📠↔️📧. A gateway can serve multiple T.4/GSTN fax users or just one. When it serves many, it acts like a classic "mail transfer agent" (MTA) 🏢. When it serves one, it acts like a classic "mail user agent" (UA) 🙋‍♀️.

An onramp is a gateway that connects from T.4/GSTN fax to Internet mail 🛬. An offramp is a gateway that connects from Internet mail to T.4/GSTN fax 🛫. Onramp behavior is out of scope for this spec 🙅‍♀️.

This spec describes the Internet mail service part of offramp addressing, confirmation, and failure notification 📬. The details come in later sections 🔜.

2.1.3. Mailbox protocols 📮

An offramp gateway that works as an MTA serving multiple users SHOULD use SMTP 🙌. A gateway that works as a UA serving a single mail recipient MAY use a mailbox access protocol such as POP or IMAP [9, 10] 📥.

NOTE: An offramp gateway that relays mail based on addressing information needs to make sure it uses addresses supplied in the MTA envelope, rather than addresses from elsewhere, like addresses listed in the message content headers 👀. Don't let the headers gaslight your routing 💀.

2.2. Formats 🎨

2.2.1. Headers 📝

IFax devices MUST be compliant with RFC 822 and RFC1123, 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 fax image is based on the minimum set of TIFF for Facsimile [6], also known as the S profile 🌟. This fax data goes into a MIME object using the image/TIFF sub-type [19] 🎁. Extra rules for using TIFF for Facsimile in this message-based internet fax 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, not 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 [14,15] 🚩.

NOTE: Internet mail transported via SMTP MUST contain a MAIL FROM address appropriate for delivery of return notices [Also see section 5.2.6] 📬.

2.3.2. Processing failure ⚠️

IFax devices with limited capabilities might not be able to process a message's content 🥺. If that happens, it's important that the message isn't lost without any notice 😱. Notice MAY be provided in any appropriate fashion, and the exact handling is a local matter 🏠. (Also see Appendix A, second bullet.) 🎀

3. ADDRESSING 📍

3.1. Classic Email Destinations 💌

Messages sent to normal Internet mail recipients use standard Internet mail addresses, with no extra constraints 💖.

3.2. G3Fax Devices 📠

G3Fax devices are accessed through 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 named on the right-hand side (domain) 👑. Don't go poking at someone else's local-part, that's rude 🙅‍♀️.

The telephone number format SHOULD conform to [11, 12]. Other formats MUST be syntactically distinct from [11, 12] 🔢.

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) [6], which is also compatible with the specification for the minimum subset of TIFF-F in [5] 🎯. 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 🚫. How a sender figures out what a recipient can handle is beyond the scope of this document 🤷‍♀️.

5. SECURITY CONSIDERATIONS 🔐

5.1. General Directive 🛡️

This spec is based on existing Internet mail 📧. To keep things interoperable with Internet mail, any security should be part of the Internet security infrastructure, not a new mechanism or some other mechanism outside the Internet infrastructure 💀🔥. This is serious, bestie, don't freelance your security 🙅‍♀️🔒.

To be continued in part 2 💜🎀

5.2 Threats and Problems 🚨

Okay so both Internet mail and G3Fax have their own threats and their own countermeasures, and they're honestly both giving drama. This section only covers the extra threats that show up when you smoosh the two services together 🫶 It also looks at the Internet mail concerns that matter for IFax environments, plus the problems that can pop up when you plug the existing G3Fax service into Internet mail 🦋

5.2.1 Spoofed sender 🎭

The person who actually sent the message might not match the sender in the Sender or From fields of the message content headers, or the MAIL FROM address from the SMTP envelope. Not me being shady about it, but this is a real issue 💀

In a tightly constrained environment, enough physical and software controls may be able to stop this from happening 🔒 The usual fix is encryption-based authentication, either for the channel or tied to the object, which we'll get into below.

Also, SMTP implementations don't give you inherent authentication of who sent a message, and sites aren't obligated to provide it either 🙈 The end-to-end approaches S/MIME and PGP/MIME are currently being developed within the IETF, and these technologies can provide that authentication ✨

5.2.2 Resources consumed by dialout 📞

Email already eats up resources like CPU cycles and disk space, but offramp facsimile adds an outdial, and that can cost a lot of resources, including actual money 💸 Techniques for establishing authorization of the sender are essential for offramp fax services that need to manage that consumption 👑

Because dialout burns through those resources, unsolicited bulk email that causes an outdial is undesirable 😤

Offramp gateways SHOULD provide a way to authorize senders, so unauthorized folks can't use the offramp 🛡️ Honest truth though: there are no standard authorization techniques for Internet protocols yet 😭

Typical solutions use simple authentication of the originator to establish and verify their identity, and then check that identity against a private authorization table 📋

Originator authentication uses either weak or strong mechanisms, like cleartext keywords or encryption-based data-signing, to figure out and validate who the sender is and then decide their permissions accordingly 🔑

Other common controls include source filtering and originator authentication. Source filtering means the offramp gateway checks the host or network that sent the message, and then permits or prohibits relaying based on that 🚦

5.2.3 GSTN authorization information 🤫

Confidential info about the sender that's needed to dial a G3Fax recipient, like the sender's calling card authorization number, might get disclosed to the G3Fax recipient on the cover page 😳 This could happen through parameters encoded in the G3Fax recipient's address in the To: or CC: fields.

Senders SHOULD be given a way to prevent that disclosure 🦋 Just like with handling unsolicited faxes, there aren't yet standard mechanisms for protecting this info 😔 The available non-standard techniques are out-of-band communication of authorization information, or using encrypted data in special fields.

Authorization usually needs to be tied to specific senders and specific messages, so that a "replay" attack can't happen 🔁 A replay attack is when an earlier authorization enables a later dial-out by a different, unauthorized sender. A non-malicious example is when 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 get sent 📨

5.2.4 Sender accountability 🕵️‍♀️

In many countries there's a legal requirement that the "sender" be disclosed on a facsimile message ⚖️ Email From addresses are trivial to fake, so using only the MAIL FROM [1, 3] or From [2, 3] header is not sufficient 🙅‍♀️

Offramps SHOULD make sure the recipient gets contact info for the offramp, just in case something goes wrong 📞

The G3Fax recipient SHOULD be given enough info to trace who originated the IFax message 🔍 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 🔐

G3Fax users expect a higher level of message privacy than what Internet mail gives you without security enhancements 🌸

That G3Fax privacy expectation SHOULD be kept as much as possible 💜

Sufficient physical and software controls may be acceptable in constrained environments. The usual way to protect data confidentiality is encryption, which we'll cover below 🔒

5.2.6 Non private mailboxes 📭

With email, bounces (delivery failures) normally go back to the sender, not to some publicly-accessible email account or printer ✉️ With facsimile, bounces don't typically happen at all 🙃 With IFax though, a bounce could get sent somewhere else (see section [Delivery Failure]), like a local system administrator's account, a publicly-accessible account, or an IFax printer (see also [Traffic Analysis]) 👀

5.2.7 Traffic analysis 🦇

Eavesdropping on senders and recipients is 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 viewed as it travels through internal networks or the Internet itself 👀

Virtual Private Networks (VPN) that use encrypted tunnels, like via IPSec technology [18] or transport layer security, can stop eavesdropping on a message while it's traveling across those networks ✨ They also give some protection against traffic analysis, as covered above 🦋

5.3.2 Object security 📦

Just like all email, an IFax message can be viewed while it sits on an intermediate Mail Transfer Agent, or while it's relayed through one 🧚

Message encryption, like PGP-MIME [13] and S/MIME, can provide end-to-end encryption 🎀

6 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 l982.

[3] Braden, R., 1123 "Requirements for Internet hosts - application and support", 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] Parsons, G., and J. Rafferty, "Tag Image File Format (TIFF) -- F Profile for Facsimile", RFC 2306, March 1998.

[6] McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G., and J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998.

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

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

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

[10] Crispin, M., "Internet Message Access Protocol - Version 4Rev1", RFC 2060, December 1996.

[11] Allocchio, C., "Minimal PSTN address format for Internet mail", RFC 2303, March 1998.

[12] Allocchio, C., "Minimal fax address format for Internet mail", RFC 2304, March 1998.

[13] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.

[14] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.

[15] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.

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

[17] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Three: Representation of Non-ASCII Text in Internet ge Headers", RFC 2047, November 1996.

[18] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, Naval Research Laboratory, August 1995.

[19] Parsons, G. and Rafferty, J. "Tag Image File Format (TIFF) -- image/TIFF: MIME Sub-type Registration", RFC 2302, March 1998.

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. 👑

8 AUTHORS' ADDRESSES 💌

Kiyoshi Toyoda
Matsushita Graphic Communication Systems, Inc.
2-3-8 Shimomeguro, Meguro-ku
Tokyo 153 Japan
Fax: +81 3 5434 7166
Email: ktoyoda@rdmg.mgcs.mei.co.jp
Hiroyuki Ohno
Tokyo Institute of Technology
2-12-1 O-okayama, Meguro-ku
Tokyo 152 Japan
FAX: +81 3 5734 2754
Email: hohno@is.titech.ac.jp
Jun Murai
Keio University
5322 Endo, Fujisawa
Kanagawa 252 Japan
Fax: +81 466 49 1101
Email: jun@wide.ad.jp
Dan Wing
Cisco Systems, Inc.
101 Cooper Street
Santa Cruz, CA 95060 USA
Phone: +1 408 457 5200
Fax: +1 408 457 5208
Email: dwing@cisco.com

9 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. 🖨️✨

Copyright (C) The Internet Society (1998). All Rights Reserved. 💖

okay bestie, here's the legal part 💅 You can copy this document and share it with others, including translations. You can also write derivative works that comment on it, explain it, or help people implement it, and you can publish and distribute those too, in whole or in part, with zero restrictions, as long as the above copyright notice and this paragraph are included on every copy and derivative work 🦋 BUT the document itself may not be modified in any way. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations. The only exceptions are (a) when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process must be followed, or (b) when it's required to translate it into languages other than English 🌈

The permissions above are perpetual, meaning the Internet Society and its successors or assigns will never revoke them 🫶

Now the serious bit 😭 This document and the information in it is provided "AS IS", and the Internet Society and the Internet Engineering Task Force totally disclaim all warranties, express or implied. That includes (but isn't limited to) any warranty that using the information here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose 💀

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.
📦 where this page comes from