A Simple Mode of Facsimile Using Internet Mail
obsoletes
- rfc-2305 — A Simple Mode of Facsimile Using Internet Mail
Extracted elements (28)
Any security provided should be part of the existing Internet security infrastructure rather than a new or separate mechanism, in order to maintain interoperability with Internet mail.
The specification defines a profile for Internet mail rather than creating a distinct 'facsimile over the Internet' service. This ensures interoperability with existing email users and software without requiring new data structures or mechanisms beyond standard Internet mail.
IFax senders are not required to send text/plain messages (relaxing RFC 2049 requirement 4), but IFax recipients are required to accept and process text/plain. Recipients are also not required to offer to save results to a file, and MAY directly print/fax received messages rather than display them.
This document obsoletes RFC 2305 with no technical changes; it updates normative references (e.g., DSN to RFC 3464, TIFF for Facsimile to RFC 3949) and separates normative from informative references.
A sender SHOULD NOT use TIFF fields and values beyond the minimum subset of TIFF for Facsimile unless the sender has prior knowledge of other TIFF fields or values supported by the recipient.
A single multi-page document SHOULD be sent as a single multi-page TIFF file, though recipients MUST process multipart/mixed containing multiple TIFF files. If processing of any part fails, the entire message is treated as failing.
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.
IFax devices MUST be compliant with MIME (RFC 2049), except as noted in Appendix A.
IFax devices MUST be compliant with RFC 2822 and RFC 1123, which define the format of mail headers. The header of an IFax message 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 DSN (RFC 3464).
Offramp gateways SHOULD provide the ability to authorize senders in some manner to prevent unauthorized use of the offramp and the resource consumption (financial cost) of outdials.
Offramps SHOULD ensure that the G3Fax recipient is provided with contact information about the offramp and sufficient information (MAIL FROM, From, Sender, Reply-To, Message-Id, Received headers) to trace the originator of the IFax message.
Senders SHOULD be provided with a method of preventing disclosure of confidential GSTN authorization information (e.g., calling card numbers) encoded in G3Fax recipient addresses.
Sending IFax devices MUST be able to write minimum set TIFF files per the S profile (RFC 3949). Receiving IFax devices MUST be able to read minimum set TIFF files.
The entire address used for a G3Fax device, including the telephone number and offramp host reference, MUST be contained within standard Internet mail transport fields such as RCPT TO and MAIL FROM.
The expectation of privacy by G3Fax users SHOULD be preserved as much as possible when integrating with Internet mail, using encryption where necessary.
The format of addresses MUST conform to the RFC 821 <addr-spec> and RFC 822 <mailbox> Internet mail standards.
The telephone number format in IFax addresses SHOULD conform to RFC 3191 and RFC 3192. Other formats MUST be syntactically distinct from those RFCs.
An IFax device is an Internet-accessible device capable of sending, receiving, or forwarding Internet faxes using an Internet mail address. A G3Fax device uses T.4 and the general switched telephone network (GSTN).
An offramp gateway connects from Internet mail to T.4/GSTN facsimile. An onramp connects from T.4/GSTN facsimile to Internet mail. Onramp behavior is out of scope; only offramp addressing, confirmation, and failure notification are specified.
An offramp gateway relaying mail based on address information must use addresses from the MTA envelope (RCPT TO / MAIL FROM), not from message content headers such as To: or CC:.
Facsimile image data is encoded using the minimum set of TIFF for Facsimile (S profile, RFC 3949) and included in a MIME object using the image/tiff sub-type (RFC 3302).
Confidential GSTN authorization information (e.g., calling card numbers) encoded in recipient addresses may be disclosed to the G3Fax recipient. Replay attacks using earlier authorizations to trigger later unauthorized dialouts are a concern.
Eavesdropping on sender/recipient identities is easier on the Internet than on GSTN. Message encryption does not prevent traffic analysis; channel security (VPN, TLS, IPSec) helps frustrate traffic analysis.
Email From addresses are trivial to fake. IFax offramps should ensure recipients can trace the originator; in many countries there is a legal requirement to disclose the sender on a facsimile message.
IFax delivery failure bounces may be sent to publicly-accessible accounts or printers rather than the sender, potentially exposing message content. Channel security (VPN, TLS/IPSec) and message encryption (S/MIME, PGP/MIME) are recommended countermeasures.
Offramp facsimile causes an outdial that imposes significant resource consumption including financial cost. Unsolicited bulk email triggering outdials is undesirable; offramps should implement sender authorization using source filtering or originator authentication.
The actual sender of an IFax message might not be the same as specified in 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.