Extended Facsimile Using Internet Mail
Extracted elements (28)
Capabilities returned in MDN or DSN (method 3) is the preferred way for senders to learn recipient capabilities because it requires no additional directory infrastructure and the information is acquired automatically during normal message exchange.
Delivery and processing confirmation are handled by two separate mechanisms (DSN and MDN) because in Internet Mail, delivery to the mailbox and rendering/printing may be separated in both time and location, unlike synchronous GSTN fax where T.30 provides a single per-page acknowledgment.
MTA-level message rejection (with RFC 1893 status 5.6.1) is preferred over MDN-based processing failure notification because MTA rejection can occur without sender request and cannot be circumvented by the receiver, unlike MDNs which can be silently ignored.
The enhancements deliberately reuse existing messaging infrastructure (DSN, MDN, MIME multipart/alternative) rather than creating fax-specific features, because fax-specific mechanisms are unlikely to be implemented in non-fax messaging software.
A sender MAY transmit both the minimum TIFF-for-Facsimile subset (per RFC 2305) and a higher-quality TIFF version in the same message using multipart/alternative, ensuring compatibility with basic-mode recipients.
A sender SHOULD be able to recognize and process feature tags per RFC 2531 when reviewing capabilities presented by a potential recipient; the capability matching rules from RFC 2533 allow introduction of new features unrecognized by older implementations.
If the submit mailer does not support DSN, the sender implementation may itself perform RFC 974 mail routing and additional submission server functions per RFC 2476 to bypass the limitation.
A mechanism SHOULD be provided to allow the sender to override a locally-stored cache of recipient capabilities, to recover from stale or inaccurate cached data.
A recipient MUST NOT generate an unsolicited MDN to indicate successful processing. It MAY generate an unsolicited MDN to indicate processing failure, subject to the RFC 2298 requirement that MDN generation must always be disableable.
A recipient SHOULD indicate the profiles and features it supports (per RFC 2531) in DSN or MDN responses, even if it supports only the minimum TIFF Profile S, so senders can confirm extended-fax compliance.
A recipient using POP3 or IMAP4 to retrieve mail MUST NOT generate a Delivery Status Notification message, because the MTA would have already issued one upon delivery to the message store.
A sender MUST NOT send a message with no processable content (such as a blank or capability-request-only message) in order to elicit an MDN/DSN capability response, as this will confuse non-aware recipients.
DSN support MUST be provided by the external (Internet-accessible) mailer, by each mailer between the external mailer and the recipient, and by a recipient implemented as an SMTP server.
If the sender desires delivery confirmation, the sender MUST request Delivery Status Notification by including the ESMTP keyword NOTIFY with value SUCCESS (per RFC 1891 section 5.1).
If the sender desires processing confirmation, the sender MUST request Message Disposition Notification per RFC 2298. MDNs MUST NOT be used for delivery confirmation — they are only useful for disposition notification.
Recipients MUST be configurable to silently ignore a request for an MDN. Automated systems MAY be configured to always respond to MDN requests but MUST be configurable to never generate MDNs.
Recipients SHOULD implement Message Disposition Notifications per RFC 2298 and SHOULD indicate supported media features in DSN and MDN messages per RFC 2530.
Support for DSN per RFC 1891 MUST be provided by the mail submission server used by the sender, and MUST be provided up to the mailer responsible for communicating with external (Internet) mailers.
The Disposition-Notification-To address MUST be able to receive MDN messages and SHOULD be able to receive non-RFC2298-compliant responses. This address and the envelope-from SHOULD match to allow automated MDN responses.
The envelope-from address supplied by the sender MUST be able to properly handle delivery failure messages, since delivery failures may be sent there.
The recipient MUST NOT use RFC 822 To:, Cc:, Bcc:, or other header recipient fields to determine the ultimate destination mailbox or addressee.
The sender MUST NOT assume the recipient will respond to an MDN request in a subsequent message, even if the recipient has previously done so.
Delivery confirmation uses Delivery Status Notifications (DSN) per RFC 1891/1894, requested via the ESMTP NOTIFY=SUCCESS keyword on SMTP RCPT TO. The DSN is returned by the MTA.
GSTN fax gateways (onramp: GSTN-to-SMTP; offramp: SMTP-to-GSTN) SHOULD behave as senders and recipients respectively, implementing the DSN/MDN and capability requirements of this document.
Processing (disposition) confirmation uses Message Disposition Notifications (MDN) per RFC 2298, requested by the sender via the Disposition-Notification-To header field. The MDN is generated by the recipient MUA.
Recipient capabilities (supported TIFF profiles and media features) are conveyed back to the sender within DSN or MDN responses, using the extensions defined in RFC 2530, enabling the sender to use enhanced profiles on subsequent transmissions.
Forged DSNs or MDNs can provide incorrect delivery or processing status information to the sender, potentially deceiving it about whether a message was successfully delivered or processed.
Inaccurate capability information — due to a compromised directory server, improper manual configuration, compromised DNS, or spoofed MDN — could cause a denial of service. Implementations SHOULD provide a mechanism to override cached capability data.