RFC 2532

RFC 2532: Extended Facsimile Using Internet Mail 📠✨

Okay bestie, the title block first! 🎀 This one is from the Network Working Group (request number 2532). The authors are L. Masinter of Xerox Corporation and D. Wing of Cisco Systems. It's on the Standards Track and was dated March 1999. The title block doesn't list any documents it obsoletes or updates, so there's nothing to report there 💅

---

Status of this Memo 🧚

This one is an Internet standards track protocol for the whole Internet community, and it's basically asking for discussion and suggestions to make it better 💖 If you want to know where it stands officially, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share away 🦋

Copyright Notice 🌸

Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract ✨

So this doc describes extensions to "Simple Mode of Facsimile Using Internet Mail" [RFC2305] and adds some new features 🔥 The big ones are sending enhanced document characteristics (higher resolution, color) and confirming that delivery and processing actually happened 👑

The whole vibe here is maximum interoperability with the email infrastructure and mail user agents that already exist (and future ones too!), while still giving you a level of service that's close to what fax users already get 💅

The IETF has been told about intellectual property rights claimed for some or all of the specification in this document. For more info, check the online list of claimed rights at <http://www.ietf.org/ipr.html> 🙈

1. Introduction 🌈

This document lists a bunch of enhancements to the "Simple Mode of Facsimile Using Internet Mail" [RFC2305]. You can mix and match them to create an extended mode of facsimile over Internet mail 💜

The new features are built to play nice with the existing base of mail transfer agents (MTAs) and mail user agents (MUAs). They also reuse existing standards for fancy stuff like positive delivery confirmation and disposition notification. The whole point is to use the messaging infrastructure wherever possible, instead of inventing fax-only features that non-fax mail software would never bother to implement 🙄 Literally no one wants that.

This document standardizes the following two features:

• Delivery confirmation (Section 2) (required)
• Additional document features (Section 3) (optional)

Both features are fully described in another document, "Terminology and Goals for Internet Fax" [RFC2542] 📚

1.1. Definition of Terms 🍓

"Processing" means rendering or transmitting the contents of the message to a printer, display device, or fax machine 🖨️

"Processing confirmation" is the recipient's way of saying "yep, I can process the contents of that message" ✨

"Recipient" means the device that does the processing. A recipient could be a traditional Mail User Agent on a PC, a standalone device that pulls mail using POP3 or IMAP, or an SMTP server that prints incoming messages (kind of like an LPR server) 🖨️💕

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 [RFC2119] 🎀

1.2. GSTN Fax Gateways ("onramp"/"offramp") 🦋

This document doesn't describe the behavior of gateways going from GSTN fax to SMTP ("onramps") or from SMTP to GSTN fax ("offramps"). Still, those gateways SHOULD have the behavior characteristics of senders and recipients described in this document 🫶

2. Delivery and Processing Confirmation 📬

In traditional GSTN-based realtime fax, the receiving terminal acknowledges successful receipt and processing of every page [T.30] 📠

With Internet Mail, Delivery (getting into the mailbox) and Disposition (getting onto paper or a screen) can be separated in time, since messages get stored and forwarded. They can also be separated in location, since the delivery agent (MTA) and the user agent (MUA) are different things. So the two confirmations come from two different standards-track mechanisms: Delivery Status Notifications (DSN) [RFC1891, RFC1894] and Message Disposition Notifications (MDN) [RFC2298], respectively 🧠✨

This section defines the requirements for devices or services that want to be considered compliant with this document 💅

2.1. Sender Requirements 💌

Delivery can fail (over disk quota, user doesn't exist anymore, malconfigured mailer, the usual drama). When that happens, a delivery failure message (in the format described by [RFC1894] or otherwise) may be sent to the envelope-from address the sender gave. So the envelope-from address the sender supplies MUST be able to properly handle those delivery failure messages 😭 Non-negotiable!

2.1.1. Delivery Confirmation 📦

If the sender wants delivery confirmation, the sender MUST request a Delivery Status Notification by including the esmtp-keyword NOTIFY with the esmtp-value SUCCESS (section 5.1 of [RFC1891]) 💖

2.1.2. Processing Confirmation 🔍

If the sender wants processing confirmation, the sender MUST request a Message Disposition Notification ([RFC2298] section 2) when sending the message itself 🌟

Here's the tea ☕ A recipient can silently ignore a request for an MDN at any time (section 2.1 of [RFC2298]), so:

• MDNs MUST NOT be used for delivery confirmation. They're only useful for disposition ("processing") notification 🙈
• The sender MUST NOT assume the recipient will respond to an MDN request in a later message, even if the recipient did it in the past 🫠

The address the sender puts in the Disposition-Notification-To field MUST be able to receive Message Disposition Notifications messages [RFC2298]. It SHOULD also be able to receive messages that aren't in the MDN format, because some legacy systems send non-RFC2298-compliant responses to the Disposition-Notification-To field 💀 The Disposition-Notification-To address and the envelope-from address SHOULD match so that automated responses to MDN requests work (section 2.1 of [RFC2298]) 🎀

2.2. Recipient Requirements 👑

Recipients SHOULD implement Message Disposition Notifications [RFC2298], and they SHOULD indicate supported media features in DSN and MDN messages per [RFC2530] ✨

If the recipient is an SMTP server, it acts as part of the receiver infrastructure, so it's subject to the "Receiver Infrastructure" requirements in this document 🧚

Also see "Recipient Recommendations" in section 5 🦋

2.2.1. MDN Recipient Requirements 🙋‍♀️

Recipients MUST be configurable to silently ignore a request for an MDN (section 2.1 of [RFC2298]) 🤫

If the recipient is an automated message processing system that isn't tied to a person, the device MAY be configurable to always respond to MDN requests. But in every case it MUST be configurable to never generate MDNs 🤖

A recipient MUST NOT generate an unsolicited MDN to indicate successful processing. A recipient MAY generate an unsolicited MDN (sent to the envelope-from (Return-Path:) address) to indicate processing failure. That's subject to the [RFC2298] requirement that it MUST always be possible for an operator to disable unsolicited MDN generation 🔥 Operators have the final say, periodt!

2.2.2. Recipients Using Mailbox Access Protocols 📥

A recipient that uses POP3 [RFC1939] or IMAP4 [RFC2060] to retrieve its mail MUST NOT generate a Delivery Status Notification message [RFC1894]. Why? Because if one was requested, the MTA already sent it when the message landed in the POP3 or IMAP4 message store 🫶

The recipient MUST NOT use the RFC822 "To:" fields, "Cc:" fields, "Bcc:" fields, or any other fields containing header recipient information to figure out the ultimate destination mailbox or addressee. It SHOULD NOT use other RFC822 or MIME fields for making those determinations either 🙅‍♀️

2.3. Messaging Infrastructure Requirements 🏗️

This section covers the requirements for the SMTP messaging infrastructure that the sender and receiver use. It's usually provided by the ISP or a company's internal mailers, but another organization can provide it too, as long as there are appropriate service contracts 💼

2.3.1. Sender Infrastructure 📤

Support for DSN [RFC1891] MUST be provided by the mail submission server [RFC2476] that the sender uses. It MUST also be provided all the way up to the mailer responsible for talking to external (Internet) mailers 💅

Also see section 5.1 of this document 🌸

2.3.2. Receiver Infrastructure 📥

Support for DSN [RFC1891] MUST be provided by the external (Internet-accessible) mailer, and MUST be provided by each mailer between the external mailer and the recipient. If the recipient is implemented as an SMTP server, it MUST also support DSN [RFC1891] 🙌

3. Additional Document Capabilities 🌟

Section 4 of "A Simple Mode of Facsimile Using Internet Mail" [RFC2305] lets a sender transmit only the minimum subset of TIFF for Facsimile "unless the sender has prior knowledge of other TIFF fields or values supported by the recipient." 📄

A recipient MAY support any or all (or any combination) of the TIFF profiles defined in RFC 2301, in addition to profile S. A recipient that supports additional profiles SHOULD indicate that support as per section 3.2 or 3.3 of this document. Because of that, a sender MAY use those additional TIFF profiles when sending to a recipient with the matching capabilities 🎀

A sender SHOULD be able to recognize and process the feature tags defined in [RFC2531] when reviewing the capabilities a potential recipient presents. The capability matching rules there (by reference to [RFC2533]) allow new features to be introduced even if older implementations don't recognize them 🦋

A sender MAY send a message containing both the minimum subset of TIFF for Facsimile (as specified in [RFC2305]) and a higher quality TIFF using multipart/alternative 🖼️✨

There are three ways for the sender to find out those capabilities:

1. Sender manual configuration
2. Capabilities in Directory
3. Capabilities returned in MDN or DSN

Method (3) SHOULD be used 💖

An implementation may cache capabilities locally, and then the cache can fall out of sync with the recipient's actual capabilities 😬 A mechanism SHOULD be provided that lets the sender override the locally stored cache of capabilities. Also note section 4.1 of this document 🫶

3.1. Sender Manual Configuration ⚙️

One way a sender can send a document bigger than the minimum subset allowed by [RFC2305] is for the user controlling the sender to manually override the default settings, usually on a per-recipient basis. For example, during transmission a user could indicate that the recipient can handle high resolution or color images 🌈

Is it awkward and not automatic? Yes, bestie. But this is where extended capabilities for ordinary Internet email users currently are in terms of deployment, so it's the reality for now 🥹

3.2. Capabilities in Directory

okay so this is the dream 🧚✨ a future direction is a directory of recipient capabilities, deployed through something like LDAP or DNS. A sender could look up what a recipient can handle before building or sending a message 👀 That's not defined in this document though, so no spec here 🙈

BUT the IETF is actively working on a solution right now, and it would fix a whole bunch of store-and-forward messaging problems 🫶 main character energy for the whole ecosystem 💅

3.3. Capabilities Returned in MDN or DSN

okay bestie, so a sender can request a positive DSN or an MDN (see section 2 🎀).

If the recipient implements [RFC2530], the DSN or MDN that comes back can include info about the recipient's capabilities 🦋 and the sender can use that info for future messages to that recipient. Iconic 🙌

The advantage? No extra infrastructure needed (unlike section 3.2) and the info shows up automatically (unlike section 3.1). It's giving efficiency 💖

3.3.1. Restrictions and Recommendations

A sender MUST NOT send a message with no processable content just to try to get an MDN/DSN capability response 🙅‍♀️ Like, a message that's only a request for capabilities, or a blank message, will confuse any recipient that isn't built to understand that kind of message 💀

A recipient SHOULD indicate the profiles and features it supports, even if it only supports Tiff Profile S (the minimum set for fax as defined by [RFC2305]) [RFC2531]. This lets a sender confirm that the recipient is compliant with this Extended Facsimile Using Internet Mail specification 🍓 no guessing, just vibes backed by facts ✨

---

4. Security Considerations 🔐

okay so this document extends [RFC2305], which means the Security Considerations section of [RFC2305] applies here too 🫶 read it, it's not optional 😭

These new features come with their own security considerations, so let's get into them 💜

4.1. Inaccurate Capabilities Information

Inaccurate capability information (section 3) could cause a denial of service 💀 Dramatic, I know, but it's real 😭

It could be inaccurate for lots of reasons: a compromised or improperly configured directory server, improper manual configuration of the sender, a compromised DNS, or a spoofed MDN 🙈 If a sender is using cached capability information, there SHOULD be a mechanism that lets the cached info be ignored or overridden when needed 🛡️ Rule of thumb: never let stale info run the show 👑

4.2. Forged MDNs or DSNs

Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298], can feed incorrect information to a sender 😬 Not it 🙅‍♀️

5. Implementation Notes 🛠️

okay implementors, these are your notes 🫶 read them, bestie 🎀

5.1. Submit Mailer Does Not Support DSN

In some installations, the generally available submit server may not support DSNs 🙃 When that happens, it may be useful for the sender to implement [RFC974] mail routing as well as additional submission server functions [RFC2476], so the installation isn't stuck with the limits of the incumbent submission server 💅 no more being held hostage 🦋

5.2. Recipient Recommendations

okay so to be really reliable, it's desirable for the sender to know when a recipient could not process a message 🎯 The recipient's MTA or MUA may be able to detect that it couldn't process the message 👀

If the recipient's MTA determines the message cannot be processed, the MTA is strongly encouraged to reject the message with the [RFC1893] status code 5.6.1 🙌 That code can come back in response to the end-of-mail-data indicator if the MTA supports reporting enhanced error codes [RFC2034], or after the message is received, by generating a delivery failure DSN ("bounce") 🍓

Note: Doing this in the MTA, using either of the two mechanisms above, is superior to doing it with MDNs. Why? MDNs generally have to be requested by the sender, and the receiver can ignore that request at any time 🙃 Rejection performed by the MTA can always happen without the sender asking for it, and without the receiver getting around it 👑 Literally unbeatable 💅

If the message contains an MDN request and the recipient's MUA determines the message cannot be processed, the MUA is strongly encouraged to respond to the MDN request and indicate that processing failed, using the disposition-type processed or displayed and the disposition-modifier error or warning [RFC2298] 🫶 telling the truth about the failure is so iconic 🌈

6. Acknowledgements 🫶

The authors want to give a huge shoutout to the members of the IETF Internet Fax working group, and especially these contributors who helped out with input during the development of this document 💖

Vivian Cancio, Richard Coles, David Crocker, Ned Freed, Graham Klyne, MAEDA Toru, Geoff Marshall, Lloyd McIntyre, Keith Moore, George Pajari, James Rafferty, Mike Ruhl, Richard Shockey, Brian Stafford, and Greg Vaudreuil ✨👑

7. References 📚

• [RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
• [RFC2531] McIntyre, L. and G. Klyne, "Content Feature Schema for Internet Fax", RFC 2531, March 1999.
• [RFC2530] Wing, D., "Indicating Supported Media Features Using Extensions to DSN and MDN", RFC 2530, March 1999.
• [RFC1891] Moore, K. "SMTP Service Extensions for Delivery Status Notifications", RFC 1891, January 1996.
• [RFC1893] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
• [RFC1894] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
• [RFC2034] Freed, N, "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC2298] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
• [RFC2301] McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G. and J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998.
• [RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998.
• [RFC974] Partridge. C., "Mail routing and the domain system", STD 14, RFC 974, January 1986.
• [RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
• [RFC2542] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
• [T.30] "Procedures for Document Facsimile Transmission in the General Switched Telephone Network", ITU-T (CCITT), Recommendation T.30, July, 1996.
• [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
• [RFC2060] Crispin, M., "Internet Message Access Protocol - Version 4Rev1", RFC 2060, December 1996.

8. Authors' Addresses 🏡

Here's where to find the authors 💌

Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304  USA

Fax:    +1 650 812 4333
EMail:  masinter@parc.xerox.com

Dan Wing
Cisco Systems, Inc.
101 Cooper Street
Santa Cruz, CA 95060  USA

Phone:  +1 831 457 5200
Fax:    +1 831 457 5208
EMail:  dwing@cisco.com

9. Full Copyright Statement ⚖️

Copyright (C) The Internet Society (1999). 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.