A Simple Mode of Facsimile Using Internet Mail
obsoleted by
- rfc-3965 — A Simple Mode of Facsimile Using Internet Mail
Extracted elements (23)
Any security provided for IFax should be part of the existing Internet security infrastructure rather than a new or separate mechanism. This design choice maintains interoperability with Internet mail while leveraging established security solutions.
The specification defines an Internet mail profile for facsimile rather than creating a distinct 'facsimile over the Internet' service. This approach ensures interoperability with existing email users and software without requiring modification, so facsimile recipients can be included in ordinary email address lists and existing email clients need not process new data structures.
An offramp gateway that relays mail based on addressing information must use addresses supplied in the MTA envelope (RCPT TO / MAIL FROM), rather than from message content headers such as To: or CC:, to avoid misdirected delivery.
IFax devices with limited capabilities might be unable to process message content. The message must not be silently lost; notice MAY be provided in any appropriate fashion and the exact handling is a local matter.
IFax senders are NOT REQUIRED to send text/plain messages (relaxing RFC 2049 requirement 4), though IFax recipients are required to accept and process such messages. IFax recipients are also NOT REQUIRED to offer to save results to a file, and MAY directly print or fax a received message rather than displaying it.
A single multi-page document SHOULD be sent as a single multi-page TIFF file. However, recipients MUST be able to process multipart/mixed messages containing multiple TIFF files. If processing of any part of a multipart message fails, the entire message is treated as a processing failure.
An offramp gateway operating as an MTA serving multiple users SHOULD use SMTP; a gateway operating as a UA serving a single mail recipient MAY use a mailbox access protocol such as POP or IMAP.
Data transfer MAY be achieved using standard Internet mail transfer mechanisms. The format of addresses MUST conform to the RFC 821 addr-spec and RFC 822 mailbox standards.
IFax devices MUST be compliant with MIME, except as noted in Appendix A, which relaxes certain RFC 2049 requirements for IFax senders and recipients.
IFax devices MUST be compliant with RFC 822 and RFC 1123 for mail header format. The message header SHOULD include Message-ID and MUST include all fields required by those standards, such as DATE and FROM.
In the event of relay failure, the sending relay MUST generate a failure message, which SHOULD be in the format of a Delivery Status Notification (DSN) per RFC 1894/1891. Internet mail transported via SMTP MUST contain a MAIL FROM address appropriate for delivery of return notices.
Sending IFax devices MUST be able to write minimum set TIFF files per the S profile (RFC 2301). Receiving IFax devices MUST be able to read minimum set TIFF files. Senders SHOULD NOT use TIFF fields and values beyond the minimum subset unless they have prior knowledge of the recipient's capabilities.
When a G3Fax device is identified by a telephone number, the entire address including number and offramp host reference MUST be contained within standard Internet mail transport fields such as RCPT TO and MAIL FROM. The telephone number format SHOULD conform to RFC 2303/2304; other formats MUST be syntactically distinct from those.
G3Fax users have an expectation of message privacy higher than that provided by unenhanced Internet mail. This expectation SHOULD be preserved as much as possible, typically via encryption for data confidentiality.
The facsimile image data format is based on the minimum set of TIFF for Facsimile (the S profile, RFC 2301), carried in a MIME object using the image/TIFF sub-type (RFC 2302). This is the mandatory content type for IFax simple mode.
Channel security via VPNs using encrypted tunnels (e.g., IPSec or TLS) can prevent eavesdropping of IFax messages as they traverse networks and provides some protection against traffic analysis.
Confidential authorization information needed to dial a G3Fax recipient (e.g., calling card numbers encoded in the To: address) might be disclosed to the recipient. Senders SHOULD be provided a method to prevent such disclosure; authorization must be bound to specific senders and messages to prevent replay attacks.
Eavesdropping of senders and recipients is easier on the Internet than on the GSTN. Message object encryption does not prevent traffic analysis; channel security such as VPNs using IPSec or transport layer security can help frustrate traffic analysis.
Many countries legally require sender disclosure on facsimile messages, but email From addresses are trivial to fake. Offramps SHOULD ensure the G3Fax recipient receives sufficient tracing information, including MAIL FROM, From, Sender, Reply-To, Message-Id, and Received headers.
Object-level security via message encryption such as PGP-MIME (RFC 2015) and S/MIME can provide end-to-end encryption for IFax messages, protecting them while at rest on or in transit through intermediate Mail Transfer Agents.
Offramp facsimile causes an outdial that imposes significant resource consumption including financial cost, making unauthorized use and unsolicited bulk email serious threats. Offramp gateways SHOULD provide the ability to authorize senders, typically through originator authentication (cleartext keywords or encryption-based signing) and/or source filtering.
The actual sender of an IFax message might not be the same as specified in the Sender, From, or MAIL FROM fields. SMTP does not provide inherent sender authentication; end-to-end solutions such as S/MIME and PGP/MIME are recommended for authentication where required.
Unlike traditional facsimile, IFax bounce messages (delivery failures) may be sent to publicly accessible accounts or printers rather than only back to the sender, potentially exposing message metadata to unintended parties.