Difference between revisions of "RFC2532"
Line 12: | Line 12: | ||
Internet community, and requests discussion and suggestions for | Internet community, and requests discussion and suggestions for | ||
improvements. Please refer to the current edition of the "Internet | improvements. Please refer to the current edition of the "Internet | ||
− | Official Protocol Standards" (STD 1) for the standardization state | + | Official Protocol Standards" ([[STD1|STD 1]]) for the standardization state |
and status of this protocol. Distribution of this memo is unlimited. | and status of this protocol. Distribution of this memo is unlimited. | ||
Line 22: | Line 22: | ||
This document describes extensions to "Simple Mode of Facsimile Using | This document describes extensions to "Simple Mode of Facsimile Using | ||
− | Internet Mail" | + | Internet Mail" [[RFC2305]] and describes additional features, including |
transmission of enhanced document characteristics (higher resolution, | transmission of enhanced document characteristics (higher resolution, | ||
color) and confirmation of delivery and processing. | color) and confirmation of delivery and processing. | ||
Line 39: | Line 39: | ||
This document notes a number of enhancements to the "Simple Mode of | This document notes a number of enhancements to the "Simple Mode of | ||
− | Facsimile Using Internet Mail" | + | Facsimile Using Internet Mail" [[RFC2305]] that may be combined to |
create an extended mode of facsimile using Internet mail. | create an extended mode of facsimile using Internet mail. | ||
Line 58: | Line 58: | ||
These features are fully described in another document titled | These features are fully described in another document titled | ||
− | "Terminology and Goals for Internet Fax" | + | "Terminology and Goals for Internet Fax" [[RFC2542]]. |
=== Definition of Terms === | === Definition of Terms === | ||
Line 77: | Line 77: | ||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||
"SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||
− | document are to be interpreted as described in | + | document are to be interpreted as described in [[RFC2119]]. |
=== GSTN Fax Gateways ("onramp"/"offramp") === | === GSTN Fax Gateways ("onramp"/"offramp") === | ||
Line 98: | Line 98: | ||
these two operations are supplied by two different standards-track | these two operations are supplied by two different standards-track | ||
mechanisms: Delivery Status Notifications (DSN) [RFC1891, RFC1894] | mechanisms: Delivery Status Notifications (DSN) [RFC1891, RFC1894] | ||
− | and Message Disposition Notifications (MDN) | + | and Message Disposition Notifications (MDN) [[RFC2298]], respectively. |
This section defines requirements for devices or services that are to | This section defines requirements for devices or services that are to | ||
Line 107: | Line 107: | ||
Because delivery failure may occur (over disk quota, user no longer | Because delivery failure may occur (over disk quota, user no longer | ||
exists, malconfigured mailer), a delivery failure message (in the | exists, malconfigured mailer), a delivery failure message (in the | ||
− | format described by | + | format described by [[RFC1894]] or otherwise) may be sent to the |
envelope-from address specified by the sender. Thus, the envelope- | envelope-from address specified by the sender. Thus, the envelope- | ||
from address supplied by the sender MUST be able to properly handle | from address supplied by the sender MUST be able to properly handle | ||
Line 116: | Line 116: | ||
If the sender desires delivery confirmation, the sender MUST request | If the sender desires delivery confirmation, the sender MUST request | ||
Delivery Status Notification by including the the esmtp-keyword | Delivery Status Notification by including the the esmtp-keyword | ||
− | NOTIFY with the esmtp-value SUCCESS (section 5.1 of | + | NOTIFY with the esmtp-value SUCCESS (section 5.1 of [[RFC1891]]). |
==== Processing Confirmation ==== | ==== Processing Confirmation ==== | ||
If the sender desires processing confirmation, the sender MUST | If the sender desires processing confirmation, the sender MUST | ||
− | request Message Disposition Notification ( | + | request Message Disposition Notification ([[RFC2298]] section 2) when |
sending the message itself. | sending the message itself. | ||
Because a recipient may silently ignore a request for an MDN (section | Because a recipient may silently ignore a request for an MDN (section | ||
− | 2.1 of | + | 2.1 of [[RFC2298]]) at any time: |
* MDNs MUST NOT be used for delivery confirmation, but are only | * MDNs MUST NOT be used for delivery confirmation, but are only | ||
Line 136: | Line 136: | ||
The address provided by the sender on the Disposition-Notification-To | The address provided by the sender on the Disposition-Notification-To | ||
field MUST be able to receive Message Disposition Notifications | field MUST be able to receive Message Disposition Notifications | ||
− | messages | + | messages [[RFC2298]] and SHOULD be able to receive messages that are |
not in the Message Disposition Notification format (due to the | not in the Message Disposition Notification format (due to the | ||
existence of legacy systems that generate non-RFC2298-compliant | existence of legacy systems that generate non-RFC2298-compliant | ||
Line 142: | Line 142: | ||
Disposition-Notification-To address and the envelope-from address | Disposition-Notification-To address and the envelope-from address | ||
SHOULD match to allow automated responses to MDN requests (section | SHOULD match to allow automated responses to MDN requests (section | ||
− | 2.1 of | + | 2.1 of [[RFC2298]]). |
=== Recipient Requirements === | === Recipient Requirements === | ||
Recipients SHOULD implement Message Disposition Notifications | Recipients SHOULD implement Message Disposition Notifications | ||
− | + | [[RFC2298]] and SHOULD indicate supported media features in DSN and MDN | |
− | messages per | + | messages per [[RFC2530]]. |
If the recipient is an SMTP server, it behaves as part of the | If the recipient is an SMTP server, it behaves as part of the | ||
Line 159: | Line 159: | ||
Recipients MUST be configurable to silently ignore a request for an | Recipients MUST be configurable to silently ignore a request for an | ||
− | MDN (section 2.1 of | + | MDN (section 2.1 of [[RFC2298]]). |
If the recipient is an automated message processing system which is | If the recipient is an automated message processing system which is | ||
Line 169: | Line 169: | ||
successful processing. A recipient MAY generate an unsolicited MDN | successful processing. A recipient MAY generate an unsolicited MDN | ||
(sent to the envelope-from (Return-Path:) address) to indicate | (sent to the envelope-from (Return-Path:) address) to indicate | ||
− | processing failure, but subject to the | + | processing failure, but subject to the [[RFC2298]] requirement that it |
MUST always be possible for an operator to disable unsolicited MDN | MUST always be possible for an operator to disable unsolicited MDN | ||
generation. | generation. | ||
Line 175: | Line 175: | ||
==== Recipients Using Mailbox Access Protocols ==== | ==== Recipients Using Mailbox Access Protocols ==== | ||
− | A recipient using POP3 | + | A recipient using POP3 [[RFC1939]] or IMAP4 [[RFC2060]] to retrieve its |
mail MUST NOT generate a Delivery Status Notification message | mail MUST NOT generate a Delivery Status Notification message | ||
− | + | [[RFC1894]] because such a notification, if it was requested, would | |
have already been issued by the MTA on delivery to the POP3 or IMAP4 | have already been issued by the MTA on delivery to the POP3 or IMAP4 | ||
message store. | message store. | ||
Line 197: | Line 197: | ||
==== Sender Infrastructure ==== | ==== Sender Infrastructure ==== | ||
− | Support for DSN | + | Support for DSN [[RFC1891]] MUST be provided by the mail submission |
− | server | + | server [[RFC2476]] used by the sender and MUST be provided up to the |
mailer responsible for communicating with external (Internet) | mailer responsible for communicating with external (Internet) | ||
mailers. | mailers. | ||
Line 206: | Line 206: | ||
==== Receiver Infrastructure ==== | ==== Receiver Infrastructure ==== | ||
− | Support for DSN | + | Support for DSN [[RFC1891]] MUST be provided by the external |
(Internet-accessible) mailer, and MUST be provided by each mailer | (Internet-accessible) mailer, and MUST be provided by each mailer | ||
between the external mailer and the recipient. If the recipient is | between the external mailer and the recipient. If the recipient is | ||
− | implemented as an SMTP server it MUST also support DSN | + | implemented as an SMTP server it MUST also support DSN [[RFC1891]]. |
== Additional Document Capabilities == | == Additional Document Capabilities == | ||
Section 4 of "A Simple Mode of Facsimile Using Internet Mail" | Section 4 of "A Simple Mode of Facsimile Using Internet Mail" | ||
− | + | [[RFC2305]] allows sending only the minimum subset of TIFF for | |
Facsimile "unless the sender has prior knowledge of other TIFF fields | Facsimile "unless the sender has prior knowledge of other TIFF fields | ||
or values supported by the recipient." | or values supported by the recipient." | ||
A recipient MAY support any or all (or any combination) of the TIFF | 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 | + | profiles defined in [[RFC2301|RFC 2301]], in addition to profile S. A recipient |
which supports additional profiles SHOULD indicate this support as | which supports additional profiles SHOULD indicate this support as | ||
per section 3.2 or 3.3 of this document. As a consequence, a sender | per section 3.2 or 3.3 of this document. As a consequence, a sender | ||
Line 226: | Line 226: | ||
A sender SHOULD be able to recognize and process the feature tags as | A sender SHOULD be able to recognize and process the feature tags as | ||
− | defined in | + | defined in [[RFC2531]] when reviewing the capabilities presented by a |
potential recipient. The capability matching rules indicated there | potential recipient. The capability matching rules indicated there | ||
− | (by reference to | + | (by reference to [[RFC2533]]) allow for the introduction of new |
features that may be unrecognized by older implementations. | features that may be unrecognized by older implementations. | ||
A sender MAY send a message containing both the minimum subset of | A sender MAY send a message containing both the minimum subset of | ||
− | TIFF for Facsimile (as specified in | + | TIFF for Facsimile (as specified in [[RFC2305]]) and a higher quality |
TIFF using multipart/alternative. | TIFF using multipart/alternative. | ||
Line 252: | Line 252: | ||
One way a sender can send a document which exceeds the minimum subset | One way a sender can send a document which exceeds the minimum subset | ||
− | allowed by | + | allowed by [[RFC2305]] is for the user controlling the sender to |
manually override the default settings, usually on a per-recipient | manually override the default settings, usually on a per-recipient | ||
basis. For example, during transmission a user could indicate the | basis. For example, during transmission a user could indicate the | ||
Line 280: | Line 280: | ||
positive DSN or an MDN. | positive DSN or an MDN. | ||
− | If the recipient implements | + | If the recipient implements [[RFC2530]], the DSN or MDN that is |
returned can contain information describing the recipient's | returned can contain information describing the recipient's | ||
capabilities. The sender can use this information for subsequent | capabilities. The sender can use this information for subsequent | ||
Line 300: | Line 300: | ||
A recipient SHOULD indicate the profiles and features supported, even | A recipient SHOULD indicate the profiles and features supported, even | ||
if the recipient supports only Tiff Profile S (the minimum set for | if the recipient supports only Tiff Profile S (the minimum set for | ||
− | fax as defined by | + | fax as defined by [[RFC2305]]) [[RFC2531]]. This allows a sender to |
determine that the recipient is compliant with this Extended | determine that the recipient is compliant with this Extended | ||
Facsimile Using Internet Mail specification. | Facsimile Using Internet Mail specification. | ||
Line 306: | Line 306: | ||
== Security Considerations == | == Security Considerations == | ||
− | As this document is an extension of | + | As this document is an extension of [[RFC2305]], the Security |
− | Considerations section of | + | Considerations section of [[RFC2305]] applies to this document. |
The following additional security considerations are introduced by | The following additional security considerations are introduced by | ||
Line 335: | Line 335: | ||
In some installations the generally available submit server may not | In some installations the generally available submit server may not | ||
support DSNs. In such circumstances, it may be useful for the sender | support DSNs. In such circumstances, it may be useful for the sender | ||
− | to implement | + | to implement [[RFC974]] mail routing as well as additional submission |
− | server functions | + | server functions [[RFC2476]] so that the installation is not |
constrained by limitations of the incumbent submission server. | constrained by limitations of the incumbent submission server. | ||
Line 348: | Line 348: | ||
If the recipient's MTA determines the message cannot be processed, | If the recipient's MTA determines the message cannot be processed, | ||
the recipient's MTA is strongly encouraged to reject the message with | the recipient's MTA is strongly encouraged to reject the message with | ||
− | a | + | a [[RFC1893]] status code of 5.6.1. This status code may be returned |
in response to the end-of-mail-data indicator if the MTA supports | in response to the end-of-mail-data indicator if the MTA supports | ||
− | reporting of enhanced error codes | + | reporting of enhanced error codes [[RFC2034]], or after message |
reception by generating a delivery failure DSN ("bounce"). | reception by generating a delivery failure DSN ("bounce"). | ||
Line 365: | Line 365: | ||
strongly encouraged to repond to an MDN request and indicate that | strongly encouraged to repond to an MDN request and indicate that | ||
processing failed with the disposition-type "processed" or | processing failed with the disposition-type "processed" or | ||
− | "displayed" and disposition-modifier "error" or "warning" | + | "displayed" and disposition-modifier "error" or "warning" [[RFC2298]]. |
== Acknowledgements == | == Acknowledgements == | ||
Line 381: | Line 381: | ||
== References == | == References == | ||
− | + | [[RFC2533]] Klyne, G., "A Syntax for Describing Media Feature Sets", | |
− | RFC 2533, March 1999. | + | [[RFC2533|RFC 2533]], March 1999. |
− | + | [[RFC2531]] McIntyre, L. and G. Klyne, "Content Feature Schema for | |
− | Internet Fax", RFC 2531, March 1999. | + | Internet Fax", [[RFC2531|RFC 2531]], March 1999. |
− | + | [[RFC2530]] Wing, D., "Indicating Supported Media Features Using | |
− | Extensions to DSN and MDN", RFC 2530, March 1999. | + | Extensions to DSN and MDN", [[RFC2530|RFC 2530]], March 1999. |
− | + | [[RFC1891]] Moore, K. "SMTP Service Extensions for Delivery Status | |
− | Notifications", RFC 1891, January 1996. | + | Notifications", [[RFC1891|RFC 1891]], January 1996. |
− | + | [[RFC1893]] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC | |
1893, January 1996. | 1893, January 1996. | ||
− | + | [[RFC1894]] Moore, K. and G. Vaudreuil, "An Extensible Message Format | |
− | for Delivery Status Notifications", RFC 1894, January 1996. | + | for Delivery Status Notifications", [[RFC1894|RFC 1894]], January 1996. |
− | + | [[RFC2034]] Freed, N, "SMTP Service Extension for Returning Enhanced | |
− | Error Codes", RFC 2034, October 1996. | + | Error Codes", [[RFC2034|RFC 2034]], October 1996. |
− | + | [[RFC2119]] Bradner, S., "Key words for use in RFCs to Indicate | |
− | Requirement Levels", BCP 14, RFC 2119, March 1997. | + | Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997. |
− | + | [[RFC2298]] Fajman, R., "An Extensible Message Format for Message | |
− | Disposition Notifications", RFC 2298, March 1998. | + | Disposition Notifications", [[RFC2298|RFC 2298]], March 1998. |
− | + | [[RFC2301]] McIntyre, L., Zilles, S., Buckley, R., Venable, D., | |
Parsons, G. and J. Rafferty, "File Format for Internet | Parsons, G. and J. Rafferty, "File Format for Internet | ||
− | Fax", RFC 2301, March 1998. | + | Fax", [[RFC2301|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 | + | Mode of Facsimile Using Internet Mail", [[RFC2305|RFC 2305]], March |
1998. | 1998. | ||
− | + | [[RFC974]] Partridge. C., "Mail routing and the domain system", STD | |
− | 14, RFC 974, January 1986. | + | 14, [[RFC974|RFC 974]], January 1986. |
− | + | [[RFC2476]] Gellens, R. and J. Klensin, "Message Submission", [[RFC2476|RFC 2476]], | |
December 1998. | December 1998. | ||
− | + | [[RFC2542]] Masinter, L., "Terminology and Goals for Internet Fax", RFC | |
2542, March 1999. | 2542, March 1999. | ||
Line 429: | Line 429: | ||
Recommendation T.30, July, 1996. | Recommendation T.30, July, 1996. | ||
− | + | [[RFC1939]] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | |
− | STD 53, RFC 1939, May 1996. | + | [[STD53|STD 53]], [[RFC1939|RFC 1939]], May 1996. |
− | + | [[RFC2060]] Crispin, M., "Internet Message Access Protocol - Version | |
− | 4Rev1", RFC 2060, December 1996. | + | 4Rev1", [[RFC2060|RFC 2060]], December 1996. |
== Authors' Addresses == | == Authors' Addresses == |
Latest revision as of 23:23, 19 October 2020
Network Working Group L. Masinter Request for Comments: 2532 Xerox Corporation Category: Standards Track D. Wing
Cisco Systems March 1999
Extended 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 (1999). All Rights Reserved.
Abstract
This document describes extensions to "Simple Mode of Facsimile Using Internet Mail" RFC2305 and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing.
These additional features are designed to provide the highest level of interoperability with the existing and future standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates the level currently enjoyed by fax users.
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights in <http://www.ietf.org/ipr.html>.
Contents
Introduction
This document notes a number of enhancements to the "Simple Mode of Facsimile Using Internet Mail" RFC2305 that may be combined to create an extended mode of facsimile using Internet mail.
The new features are designed to be interoperable with the existing base of mail transfer agents (MTAs) and mail user agents (MUAs), and take advantage of existing standards for advanced functionality such as positive delivery confirmation and disposition notification. The
enhancements described in this document utilize the messaging infrastructure, where possible, instead of creating fax-specific features which are unlikely to be implemented in non-fax messaging software.
This document standardizes the following two features.
* Delivery confirmation (Section 2) (required) * Additional document features (Section 3) (optional)
These features are fully described in another document titled "Terminology and Goals for Internet Fax" RFC2542.
Definition of Terms
The term "processing" indicates the action of rendering or transmitting the contents of the message to a printer, display device, or fax machine.
The term "processing confirmation" is an indication by the recipient of a message that it is able to process the contents of that message.
The term "recipient" indicates the device which performs the processing function. For example, a recipient could be implemented as a traditional Mail User Agent on a PC, a standalone device which retrieves mail using POP3 or IMAP, an SMTP server which prints incoming messages (similar to 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.
GSTN Fax Gateways ("onramp"/"offramp")
The behavior of gateways from GSTN fax to SMTP ("onramps") and from SMTP to GSTN fax ("offramps") are not described in this document. However, such gateways SHOULD have the behavior characteristics of senders and recipients as described in this document.
Delivery and Processing Confirmation
In traditional GSTN-based realtime facsimile, the receiving terminal acknowledges successful receipt and processing of every page [T.30].
In Internet Mail, the operations of Delivery (to the mailbox) and Disposition (to paper or a screen) may be separated in time (due to store and forwarding of messages) and location (due to separation of delivery agent (MTA) and user agent (MUA)). The confirmation of
these two operations are supplied by two different standards-track mechanisms: Delivery Status Notifications (DSN) [RFC1891, RFC1894] and Message Disposition Notifications (MDN) RFC2298, respectively.
This section defines requirements for devices or services that are to be considered compliant with this document.
Sender Requirements
Because delivery failure may occur (over disk quota, user no longer exists, malconfigured mailer), a delivery failure message (in the format described by RFC1894 or otherwise) may be sent to the envelope-from address specified by the sender. Thus, the envelope- from address supplied by the sender MUST be able to properly handle such delivery failure messages.
Delivery Confirmation
If the sender desires delivery confirmation, the sender MUST request Delivery Status Notification by including the the esmtp-keyword NOTIFY with the esmtp-value SUCCESS (section 5.1 of RFC1891).
Processing Confirmation
If the sender desires processing confirmation, the sender MUST request Message Disposition Notification (RFC2298 section 2) when sending the message itself.
Because a recipient may silently ignore a request for an MDN (section 2.1 of RFC2298) at any time:
* MDNs MUST NOT be used for delivery confirmation, but are only useful for disposition ("processing") notification.
* the sender MUST NOT assume the recipient will respond to an MDN request in a subsequent message, even if the recipient has done so in the past.
The address provided by the sender on the Disposition-Notification-To field MUST be able to receive Message Disposition Notifications messages RFC2298 and SHOULD be able to receive messages that are not in the Message Disposition Notification format (due to the existence of legacy systems that generate non-RFC2298-compliant responses to the Disposition-Notification-To field). The Disposition-Notification-To address and the envelope-from address SHOULD match to allow automated responses to MDN requests (section 2.1 of RFC2298).
Recipient Requirements
Recipients SHOULD implement Message Disposition Notifications RFC2298 and SHOULD indicate supported media features in DSN and MDN messages per RFC2530.
If the recipient is an SMTP server, it behaves as part of the receiver infrastructure and is therefore subject to the "Receiver Infrastructure" requirements of this document.
See also "Recipient Recommendations" in section 5.
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 which is not associated with a person, the device MAY be configurable to always respond to MDN requests, but in all cases 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, but subject to the RFC2298 requirement that it MUST always be possible for an operator to disable unsolicited MDN generation.
Recipients Using Mailbox Access Protocols
A recipient using POP3 RFC1939 or IMAP4 RFC2060 to retrieve its mail MUST NOT generate a Delivery Status Notification message RFC1894 because such a notification, if it was requested, would have already been issued by the MTA on delivery to 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 determine the ultimate destination mailbox or addressee, and SHOULD NOT use other RFC822 or MIME fields for making such determinations.
Messaging Infrastructure Requirements
This section explains the requirements of the SMTP messaging infrastructure used by the sender and receiver. This infrastructure is commonly provided by the ISP or a company's internal mailers but can actually be provided by another organization with appropriate service contracts.
Sender Infrastructure
Support for DSN RFC1891 MUST be provided by the mail submission server RFC2476 used by the sender and MUST be provided up to the mailer responsible for communicating with external (Internet) mailers.
Also see section 5.1 of this document.
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.
Additional Document Capabilities
Section 4 of "A Simple Mode of Facsimile Using Internet Mail" RFC2305 allows sending 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 which supports additional profiles SHOULD indicate this support as per section 3.2 or 3.3 of this document. As a consequence, a sender MAY use those additional TIFF profiles when sending to a recipient with the corresponding capabilities.
A sender SHOULD be able to recognize and process the feature tags as defined in RFC2531 when reviewing the capabilities presented by a potential recipient. The capability matching rules indicated there (by reference to RFC2533) allow for the introduction of new features that may be unrecognized by older implementations.
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.
Three methods for the sender to acquire such knowledge are described:
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 lose synchronization with the recipient's actual capabilities. A mechanism SHOULD be provided to allow the sender to override the locally-stored cache of capabilities. Also note section 4.1 of this document.
Sender Manual Configuration
One way a sender can send a document which exceeds 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 the recipient is capable of receiving high resolution images or color images.
While awkward and not automatic, this mechanism reflects the current state of deployment of configuration for extended capabilities to ordinary Internet email users.
Capabilities in Directory
A future direction for enhanced document features is to create a directory structure of recipient capabilities, deployed, for example, through LDAP or DNS. The directory would provide a mechanism by which a sender could determine a recipient's capabilities before message construction or transmission, using a directory lookup. Such mechanisms are not defined in this document.
There is active investigation within the IETF to develop a solution to this problem, which would resolve a wide range of issues with store-and-forward messaging.
Capabilities Returned in MDN or DSN
As outlined in section 2 of this document, a sender may request a positive DSN or an MDN.
If the recipient implements RFC2530, the DSN or MDN that is returned can contain information describing the recipient's capabilities. The sender can use this information for subsequent communications with that recipient.
The advantage of this approach is that additional infrastructure is not required (unlike section 3.2), and the information is acquired automatically (unlike section 3.1).
Restrictions and Recommendations
A sender MUST NOT send a message with no processable content to attempt to elicit an MDN/DSN capability response. Doing so with a message with no processable content (such as a message containing only a request for capabilities or a blank message) will confuse a recipient not already designed to understand the semantics of such a message.
A recipient SHOULD indicate the profiles and features supported, even if the recipient supports only Tiff Profile S (the minimum set for fax as defined by RFC2305) RFC2531. This allows a sender to determine that the recipient is compliant with this Extended Facsimile Using Internet Mail specification.
Security Considerations
As this document is an extension of RFC2305, the Security Considerations section of RFC2305 applies to this document.
The following additional security considerations are introduced by the new features described in this document.
Inaccurate Capabilities Information
Inaccurate capability information (section 3) could cause a denial of service. The capability information could be inaccurate due to many reasons, including compromised or improperly configured directory server, improper manual configuration of sender, compromised DNS, or spoofed MDN. If a sender is using cached capability information, there SHOULD be a mechanism to allow the cached information to be ignored or overridden if necessary.
Forged MDNs or DSNs
Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298] can provide incorrect information to a sender.
Implementation Notes
This section contains notes to implementors.
Submit Mailer Does Not Support DSN
In some installations the generally available submit server may not support DSNs. In such circumstances, it may be useful for the sender to implement RFC974 mail routing as well as additional submission server functions RFC2476 so that the installation is not constrained by limitations of the incumbent submission server.
Recipient Recommendations
To provide a high degree of reliability, it is desirable for the sender to know that a recipient could not process a message. The inability to successfully process a message may be detectable by the recipient's MTA or MUA.
If the recipient's MTA determines the message cannot be processed, the recipient's MTA is strongly encouraged to reject the message with a RFC1893 status code of 5.6.1. This status code may be returned in response to the end-of-mail-data indicator if the MTA supports reporting of enhanced error codes RFC2034, or after message reception by generating a delivery failure DSN ("bounce").
Note: Providing this functionality in the MTA, via either of the
two mechanisms described above, is superior to providing the function using MDNs because MDNs must generally be requested by the sender (and the request may, at any time, be ignored by the receiver). Message rejection performed by the MTA can always occur without the sender requesting such behavior and without the receiver circumventing the behavior.
If the message contains an MDN request and the recipient's MUA determines the message cannot be processed, the recipient's MUA is strongly encouraged to repond to an MDN request and indicate that processing failed with the disposition-type "processed" or "displayed" and disposition-modifier "error" or "warning" RFC2298.
Acknowledgements
The authors would like to acknowledge the members of the IETF Internet Fax working group, and especially the following contributors who provided assistance and 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.
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.
Authors' Addresses
Larry Masinter Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 USA
Fax: +1 650 812 4333 EMail: [email protected]
Dan Wing Cisco Systems, Inc. 101 Cooper Street Santa Cruz, CA 95060 USA
Phone: +1 831 457 5200 Fax: +1 831 457 5208 EMail: [email protected]
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.