RFC 2305 Simple Mode:
Interworking Configuration Matrix


Configuration and Testing Results - Fax Connect II


Company : __________________________





Feature Set

Requirement Level



(Y, N, N/A)


Relay (2.1.1)


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




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)


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




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)


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




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)


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




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.




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




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)


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




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)


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




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



Processing failure (2.3.2)


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)


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)


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




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




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




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



Section 4: Image File Format



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





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





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)


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


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)


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




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



Message disclosure (5.2.5)


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.