Full-mode Fax Profile for Internet Mail (FFPIM)
Extracted elements (17)
Classic facsimile is interactive allowing real-time capability discovery, while Internet mail is store-and-forward with long latency; content negotiation mechanisms are therefore needed to allow senders to transfer richer document forms than the safe-but-universal default.
FFPIM enhances Internet mail to approximate classic T.30 facsimile service by adding capability negotiation and reliability features, while deliberately leveraging existing email infrastructure rather than creating fax-specific features unlikely to be implemented in non-fax software.
To achieve direct-mode facsimile-like interaction over email, the originating MTA must contact the receiver's MTA directly (not via outbound intermediaries), and the target MTAs must have DNS A records without MX records, enabling ESMTP CONNEG-based capability exchange before transmission.
ESMTP CONNEG-based content negotiation requires support for the mechanism along the entire email transfer path; when any intermediary MTA lacks support, the negotiation cannot function end-to-end.
FFPIM participants must ensure their use of UA-based and ESMTP-based content negotiation mechanisms is compatible, as the two mechanisms may consult different capability repositories that could contain inconsistent information.
FFPIM implementations MUST support content negotiation as specified in RFC 2534 and RFC 2879, which define the capabilities that can be negotiated.
FFPIM implementations MUST support UA-based content negotiation as specified in RFC 3297, which permits an originator to send the best supported version and a better version if the recipient requests it.
FFPIM participants MAY support ESMTP-based content negotiation as specified in RFC 4141, which allows receiving ESMTP servers to report mailbox capabilities and sending clients to signal conversion permissions and constraints.
Implementations conformant to FFPIM SHOULD support the TIFF enhancements defined in RFC 3949; support for TIFF represents a functional minimum for FFPIM.
Implementations conforming to FFPIM MUST also conform to RFC 3965 (Simple Mode Facsimile Using Internet Mail) and RFC 2532 (Extended Facsimile Using Internet Mail).
Permission to convert message content via ESMTP CONNEG SHOULD NOT normally be used with signed or sealed messages, because conversion will invalidate signatures and cannot be performed on encrypted content.
ESMTP-based content negotiation uses the CONNEG option (RFC 4141), requiring support along the entire email path; receiving ESMTP servers report capabilities and sending clients signal conversion permissions and constraints.
FFPIM content format is based on enhanced TIFF data as defined in RFC 3949, extending the TIFF capabilities of RFC 3965 and RFC 2532.
UA-based content negotiation uses a post-hoc technique (RFC 3297) allowing an originator to send the best version known to be supported, then send a better version if the recipient requests it.
Negotiation can be exploited as a denial-of-service attack, may lead to use of an unsafe data format, and discloses capability information raising privacy concerns.
The Security Considerations of RFC 3965 and RFC 2532 apply to FFPIM, including use of PGP and S/MIME for authentication and privacy.
Use of the ESMTP CONNEG option permits content transformation by intermediaries along the mail transfer path; encrypted content cannot be transformed by intermediaries lacking keying material, while conversion of signed-but-not-encrypted content will invalidate the signature.