RFC 2305 Simple Mode:
Interworking Configuration Matrix

Feature Set

Requirement Level

Condition

(Y, N, N/A)

Interworking
Tested

Relay (2.1.1)

MAY

1. Data transfer MAY be achieved using standard Internet mail transfer mechanisms.

MUST

2. The format of addresses MUST conform to the RFC 821 <addr-spec> and RFC 822 <mailbox> Internet mail standards.

Mailbox protocols (2.1.3)

SHOULD

3. An offramp gateway that operates as an MTA serving multiple users SHOULD use SMTP;

MAY

4. A gateway that operates as a UA serving a single mail recipient MAY use a mailbox access protocol such as POP or IMAP.

Headers (2.2.1)

MUST

5. IFax devices MUST be compliant with RFC 822 and RFC1123, which define the format of mail headers.

SHOULD or MUST

6. The header of an IFax message SHOULD include Message-ID and MUST include all fields required by [2, 3], such as DATE and FROM.

MIME (2.2.2)

MUST(*)

7. IFax devices MUST be compliant with MIME [4], except as noted in Appendix A (see 7.1-7.3 below):

NOT REQ or REQUIRED

7.1 IFax senders are NOT REQUIRED to be able to send text/plain messages (RFC 2049 requirement 4), although Ifax recipients are required to accept such messages, and to process them.

NOT REQ

7.2 IFax recipients are NOT REQUIRED to offer to put results in a file.

MAY

7.3 IFax recipients MAY directly print/fax the received message rather than "display" it, as indicated in RFC 2049.

Content (2.2.3)

8. The data format of the facsimile image is based on the minimum set of TIFF for Facsimile[6], also known as the S profile. Such facsimile data are included in a MIME object by use of the image/TIFF sub-type.

Multipart (2.2.4)

SHOULD

9. A single multi-page document SHOULD be sent as a single multi-page TIFF file.

MUST

10. (even though) Recipients MUST process multipart/mixed containing multiple TIFF files.

11. If multipart content is present and processing of any part fails, then processing for the entire message is treated as failing, per [Processing failure] below.

Delivery failure (2.3.1)

MUST or SHOULD

12. In the event of relay failure, the sending relay MUST generate a failure message, which SHOULD be in the format of a DSN.

MUST

13. Internet mail transported via SMTP MUST contain a MAIL FROM address appropriate for delivery of return notices.

Processing failure (2.3.2)

MAY

14. IFax devices with limited capabilities might be unable to process the content of a message. If this occurs it is important to ensure that the message is not lost without any notice. Notice MAY be provided in any appropriate fashion...

Section 3: Addressing

Classic Email Destinations (3.1)

MUST

15. Messages being sent to normal Internet mail recipients will use standard Internet mail addresses, without additional constraints.

Address Formats Used by Offramps (3.3)

MUST

16. When a G3Fax device is identified by a telephone number, the entire address used for the G3fax device, including the number and offramp host reference MUST be contained within standard Internet mail transport fields, such as RCPT TO and MAIL FROM [1, 3].

MAY

17. The address MAY be contained within message content fields, such as <authentic> and <destination> [2, 3], as appropriate.

18. As for all Internet mail addresses, the left-hand-side (local- part)of an address is not to be interpreted except by the MTA that is named on the right-hand-side (domain).

SHOULD

19. The telephone number format SHOULD conform to [11, 12].

MUST

20. Other formats MUST be syntactically distinct from [11, 12].

Section 4: Image File Format

MUST

21. Sending IFax devices MUST be able to write minimum set TIFF files,per the rules for creating minimum set TIFF files defined in TIFF for Facsimile (the S profile)...

MUST

22. Receiving IFax devices MUST be able to read minimum set TIFF files.

SHOULD NOT

23. 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.

Section 5: Security Considerations

Resources consumed by dialout (5.2.2)

SHOULD

24. Offramp gateways SHOULD provide the ability to authorize senders in some manner to prevent unauthorized use of the offramp.

GSTN authorization information (5.2.3

SHOULD

25. Confidential information about the sender necessary to dial a G3Fax recipient might be disclosed to the G3Fax recipient (on the cover page). Senders SHOULD be provided with a method of preventing such disclosure.

Sender accountability (5.2.4)

SHOULD

26. Offramps SHOULD ensure that the recipient is provided contact information about the offramp, in the event of problems.

SHOULD

27. The G3Fax recipient SHOULD be provided with sufficient information which permits tracing the originator of the IFax message.

Message disclosure (5.2.5)

SHOULD

28. Users of G3Fax devices have an expectation of a level of message privacy which is higher than the level provided by Internet mail without security enhancements. This expectation of privacy by G3Fax users SHOULD be preserved as much as possible.

Channel security (5.3.1)

29. Virtual Private Networks (VPN) which make use of encrypted tunnels, such as via IPSec technology [18] or transport layer security, can be used to prevent eavesdropping of a message as it traverses such networks.

Object security (5.3.2)

30. Message encryption, such as PGP-MIME [13] and S/MIME, can be used to provide end-to-end encryption.