rfc2305.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 732 行 · 第 1/2 页

5.2.3     GSTN authorization information

   Confidential information about the sender necessary to dial a G3Fax
   recipient, such as sender's calling card authorization number, might
   be disclosed to the G3Fax recipient (on the cover page), such as
   through parameters encoded in the G3Fax recipients address in the To:
   or CC: fields.

   Senders SHOULD be provided with a method of preventing such
   disclosure.  As with mechanisms for handling unsolicited faxes, there
   are not yet standard mechanisms for protecting such information.
   Out-of-band communication of authorization information or use of
   encrypted data in special fields are the available non-standard
   techniques.

   Typically authorization needs to be associated to specific senders
   and specific messages, in order to prevent a "replay" attack which
   causes and earlier authorization to enable a later dial-out by a
   different (and unauthorized) sender.  A non-malicious example of such
   a replay would be to have an email recipient reply to all original
   recipients -- including an offramp IFax recipient -- and have the
   original sender's authorization cause the reply to be sent.





Toyoda, et. al.             Standards Track                     [Page 7]

RFC 2305                Simple Mode of Facsimile              March 1998


5.2.4     Sender accountability

   In many countries, there is a legal requirement that the "sender" be
   disclosed on a facsimile message.  Email From addresses are trivial
   to fake, so that using only the MAIL FROM [1, 3]  or From [2, 3]
   header is not sufficient.

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

   The G3Fax recipient SHOULD be provided with sufficient information
   which permits tracing the originator of the IFax message.  Such
   information might include the contents of the MAIL FROM, From, Sender
   and Reply-To headers, as well as Message-Id and Received headers.

5.2.5     Message disclosure

   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.

   Sufficient physical and software control may be acceptable in
   constrained environments.  The usual mechanism for ensuring data
   confidentially entail encryption, as discussed below.

5.2.6     Non private mailboxes

   With email, bounces (delivery failures) are typically returned to the
   sender and not to a publicly-accessible email account or printer.
   With facsimile, bounces do not typically occur.  However, with IFax,
   a bounce could be sent elsewhere (see section [Delivery Failure]),
   such as a local system administrator's account, publicly-accessible
   account, or an IFax printer (see also [Traffic Analysis]).

5.2.7     Traffic analysis

   Eavesdropping of senders and recipients is easier on the Internet
   than GSTN.  Note that message object encryption does not prevent
   traffic analysis, but channel security can help to frustrate attempts
   at traffic analysis.

5.3 Security Techniques

   There are two, basic approaches to encryption-based security which
   support authentication and privacy:



Toyoda, et. al.             Standards Track                     [Page 8]

RFC 2305                Simple Mode of Facsimile              March 1998


5.3.1     Channel security

   As with all email, an IFax message can be viewed as it traverses
   internal networks or the Internet itself.

   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.   It also provides some protection against traffic
   analysis, as described above.

5.3.2     Object security

   As with all email, an IFax message can be viewed while it resides on,
   or while it is relayed through, an intermediate Mail Transfer Agent.

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

6  REFERENCES

   [1]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
        821, August 1982.

   [2]  Crocker, D., "Standard for the Format of ARPA Internet
        Text Messages", STD 11, RFC 822, August l982.

   [3]  Braden, R., 1123 "Requirements for Internet hosts -
        application and support", RFC 1123, October 1989.

   [4]  Borenstein, N., and N. Freed, " Multipurpose Internet
        Mail Extensions (MIME) Part Five:  Conformance Criteria and
        Examples ", RFC 2049, November 1996.

   [5]  Parsons, G., and J. Rafferty, "Tag Image File Format
        (TIFF) -- F Profile for Facsimile", RFC 2306, March 1998.

   [6]  McIntyre, L., Zilles, S., Buckley, R., Venable, D.,
        Parsons, G., and J. Rafferty, "File Format for Internet Fax",
        RFC 2301, March 1998.

   [7]  Bradner, S., "Key words for use in RFCs to Indicate
        Requirement Levels", RFC 2119, March 1997.

   [8]  ITU-T (CCITT), "Standardization of Group 3 facsimile
        apparatus for document transmission", ITU-T (CCITT),
        Recommendation T.4.




Toyoda, et. al.             Standards Track                     [Page 9]

RFC 2305                Simple Mode of Facsimile              March 1998


   [9]  Myers, J., and M. Rose, "Post Office Protocol - Version
        3", STD 53, RFC 1939, May 1996.

   [10] Crispin, M., "Internet Message Access Protocol - Version
        4Rev1", RFC 2060, December 1996.

   [11] Allocchio, C., "Minimal PSTN address format for Internet
        mail", RFC 2303, March 1998.

   [12] Allocchio, C., "Minimal fax address format for Internet
        mail", RFC 2304, March 1998.

   [13] Elkins, M., "MIME Security with Pretty Good Privacy
        (PGP)", RFC 2015, October 1996.

   [14] Moore, K., and G. Vaudreuil, "An Extensible Message
        Format for Delivery Status Notifications", RFC 1894, January
        1996.

   [15] Moore, K., "SMTP Service Extension for Delivery Status
        Notifications", RFC 1891, January 1996.

   [16] Freed, N., and N. Borenstein, "Multipurpose Internet
        Mail Extensions (MIME) Part Two: Media Types", RFC 2046,
        November 1996.

   [17] Moore, K., "Multipurpose Internet Mail Extensions (MIME)
        Three: Representation of Non-ASCII Text in Internet ge Headers",
        RFC 2047, November 1996.

   [18] Atkinson, R., "Security Architecture for the Internet
        Protocol", RFC 1825, Naval Research Laboratory, August 1995.

   [19] Parsons, G. and Rafferty, J. "Tag Image File Format
        (TIFF) -- image/TIFF: MIME Sub-type Registration", RFC 2302,
        March 1998.

7  ACKNOWLEDGEMENTS

   This specification was produced by the Internet Engineering Task
   Force Fax Working Group, over the course of more than one year's
   online and face-to-face discussions.  As with all IETF efforts, many
   people contributed to the final product.

   Active for this document were: Steve Huston, Jeffrey Perry, Greg
   Vaudreuil, Richard Shockey, Charles Wu, Graham Klyne, Robert A.
   Rosenberg, Larry Masinter, Dave Crocker, Herman Silbiger, James
   Rafferty.



Toyoda, et. al.             Standards Track                    [Page 10]

RFC 2305                Simple Mode of Facsimile              March 1998


8  AUTHORS' ADDRESSES

   Kiyoshi Toyoda
   Matsushita Graphic Communication Systems, Inc.
   2-3-8 Shimomeguro, Meguro-ku
   Tokyo 153 Japan
   Fax: [phone]
   Email: [e-mail]

   Hiroyuki Ohno
   Tokyo Institute of Technology
   2-12-1 O-okayama, Meguro-ku
   Tokyo 152 Japan
   FAX: [phone]
   Email: [e-mail]

   Jun Murai
   Keio University
   5322 Endo, Fujisawa
   Kanagawa 252 Japan
   Fax: [phone]
   Email: [e-mail]

   Dan Wing
   Cisco Systems, Inc.
   101 Cooper Street
   Santa Cruz, CA 95060 USA
   Phone: [phone]
   Fax: [phone]
   Email: [e-mail]





















Toyoda, et. al.             Standards Track                    [Page 11]

RFC 2305                Simple Mode of Facsimile              March 1998


9 APPENDIX A:  Exceptions to MIME

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

   *    IFax recipients are NOT REQUIRED to offer to put results
        in  a file. (Also see 2.3.2.)

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







































Toyoda, et. al.             Standards Track                    [Page 12]

RFC 2305                Simple Mode of Facsimile              March 1998


10  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Toyoda, et. al.             Standards Track                    [Page 13]