As per Relevance of the word recipient, we have this rfc below:
Network Working Group K.
Request for Comments: 2305 H.
Category: Standards Track J.
WIDE
D.
March 1998
A Simple Mode of Facsimile Using Internet
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This specification provides for "simple mode" carriage of
data over the Internet. Extensions to this document will follow
The current specification employs standard protocols and file
such as TCP/IP, Internet mail protocols [1, 2, 3], MIME [4, 16, 17],
and TIFF for Facsimile [5,6,19]. It can send images not only
other Internet-aware facsimile devices but also to Internet-
systems, such as PCs with common email readers which can handle
mail and TIFF for Facsimile data. The specification
communication among existing facsimile devices, Internet mail agents
and the gateways which connect them
The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in
document are to be interpreted as described in [7].
1
This specification defines a message-based facsimile
over the Internet. It describes a minimum set of capabilities
taking into account those of typical facsimile devices and PCs
can generate facsimile data
Toyoda, et. al. Standards Track [Page 1]
RFC 2305 Simple Mode of Facsimile March 1998
A G3Fax device has substantial restrictions due to specifications
the standards, such as for timers. This specification defines
profile for Internet mail, rather than creating a distinct "
over the Internet" service. The semantics resulting from the
are designed to be compatible with facsimile operation over
general switched telephone network, so that gateways
facsimile and Internet mail can operate with very high fidelity
The reason for developing this capability as an email profile is
permit interworking amongst facsimile and email users. For
it is intended that existing email users be able to send
messages to lists of users, including facsimile-based recipients,
that other email recipients shall be able to reply to the
and continue to include facsimile recipients. Similarly it
intended that existing email software work without modification
not be required to process new, or different data structures,
what is normal for Internet mail users. Existing email
standards are used, rather than replicating mechanisms which are
tailored to existing facsimile standards, to ensure
compatibility with existing email service
1.1
A facsimile-capable device that uses T.4 [8] and the general
telephone network (GSTN) is called a "G3Fax device" in
specification. An "IFax device" is an Internet- accessible
capable of sending, receiving or forwarding Internet faxes.
message can be sent to an IFax device using an Internet
address. A message can be sent to a G3Fax device using an
mail address; the message MAY be forwarded via an IFax
gateway
1.2
This specification provides for communication between each of
following combinations
Internet mail => Network
Internet mail => Offramp gateway (forward
G3Fax
Network scanner => Network
Network scanner => Offramp gateway (forward
G3Fax
Network scanner => Internet
Toyoda, et. al. Standards Track [Page 2]
RFC 2305 Simple Mode of Facsimile March 1998
2 COMMUNICATION
The set of conventions necessary to achieve facsimile-
service covers basic data transport, document data formats,
(document) addressing, delivery confirmation, and message security
In this section, the first 4 are covered. The remainder are
in following sections, along with additional details for
and formats
2.1
This section describes mechanisms involved in the transport
IFAX devices
2.1.1
Data transfer MAY be achieved using standard Internet mail
mechanisms[1, 3]. The format of addresses MUST conform to the
821 and RFC 822 Internet mail standards [1, 2,
3].
2.1.2
A gateway translates between dissimilar environments. For IFax,
gateway connects between Internet mail and the T.4/GSTN facsimile
Gateways can service multiple T.4/GSTN facsimile users or can
only one. In the former case, they serve as a classic "mail
agent" (MTA) and in the latter as a classic "mail user agent" (UA).
An onramp is a gateway which connects from T.4/GSTN facsimile
Internet mail. An offramp is a gateway which connects from
mail to T.4/GSTN facsimile. Behavior of onramps is out of scope
this specification
This specification describes the Internet mail service portion
offramp addressing, confirmation and failure notification.
are provided in later sections
2.1.3 Mailbox
An offramp gateway that operate as an MTA serving multiple
SHOULD use SMTP; a gateway that operates as a UA serving a
mail recipient MAY use a mailbox access protocol such as POP or
[9, 10].
Toyoda, et. al. Standards Track [Page 3]
RFC 2305 Simple Mode of Facsimile March 1998
NOTE: An offramp gateway that relays mail based on
information needs to ensure that it uses addresses supplied in
MTA envelope, rather than from elsewhere, such as addresses listed
the message content headers
2.2
2.2.1
IFax devices MUST be compliant with RFC 822 and RFC1123, which
the format of mail headers. The header of an IFax message
include Message-ID and MUST include all fields required by [2, 3],
such as DATE and FROM
2.2.2
IFax devices MUST be compliant with MIME [4], except as noted
Appendix A
2.2.3
The data format of the facsimile image is based on the minimum set
TIFF for Facsimile[6], also known as the S profile. Such
data are included in a MIME object by use of the image/TIFF sub-
[19]. Additional rules for the use of TIFF for Facsimile, for
message-based Internet facsimile application, are defined later
2.2.4
A single multi-page document SHOULD be sent as a single multi-
TIFF file, even though recipients MUST process multipart/
containing multiple TIFF files. If multipart content is present
processing of any part fails, then processing for the entire
is treated as failing, per [Processing failure] below
2.3 Error
2.3.1 Delivery
This section describes existing requirements for Internet mail
rather than indicating special requirements for IFax devices
In the event of relay failure, the sending relay MUST generate
failure message, which SHOULD be in the format of a DSN. [14,15]
NOTE: Internet mail transported via SMTP MUST contain a
FROM address appropriate for delivery of return notices [
see section 5.2.6]
Toyoda, et. al. Standards Track [Page 4]
RFC 2305 Simple Mode of Facsimile March 1998
2.3.2 Processing
IFax devices with limited capabilities might be unable to process
content of a message. If this occurs it is important to ensure
the message is not lost without any notice. Notice MAY be provided
any appropriate fashion, and the exact handling is a local matter
(Also see Appendix A, second bullet.)
3
3.1 Classic Email
Messages being sent to normal Internet mail recipients will
standard Internet mail addresses, without additional constraints
3.2 G3Fax
G3Fax devices are accessed via an IFAX offramp gateway,
performs any authorized telephone dial-up
3.3 Address Formats Used by
When a G3Fax device is identified by a telephone number, the
address used for the G3fax device, including the number and
host reference MUST be contained within standard Internet
transport fields, such as RCPT TO and MAIL FROM [1, 3]. The
MAY be contained within message content fields, such as <authentic
and <destination> [2, 3], as appropriate
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
named on the right-hand-side (domain).
The telephone number format SHOULD conform to [11, 12].
formats MUST be syntactically distinct from [11, 12].
4 IMAGE FILE
Sending IFax devices MUST be able to write minimum set TIFF files
per the rules for creating minimum set TIFF files defined in TIFF
Facsimile (the S profile) [6], which is also compatible with
specification for the minimum subset of TIFF-F in [5].
IFax devices MUST be able to read minimum set TIFF files
Toyoda, et. al. Standards Track [Page 5]
RFC 2305 Simple Mode of Facsimile March 1998
A sender SHOULD NOT use TIFF fields and values beyond the
subset of TIFF for Facsimile unless the sender has prior knowledge
other TIFF fields or values supported by the recipient.
mechanism for determining capabilities of recipients is beyond
scope of this document
5 SECURITY
5.1 General
This specification is based on use of existing Internet mail.
maintain interoperability with Internet mail, any security to
provided should be part of the of the Internet
infrastructure, rather than a new mechanism or some other
outside of the Internet infrastructure
5.2 Threats and
Both Internet mail and G3Fax standards and operational services
their own set of threats and countermeasures. This section
only to the set of additional threats which ensue from
the two services. This section reviews relevant concerns
Internet mail for IFax environments, as well as considering
potential problems which can result of integrating the existing G3
service with Internet mail
5.2.1 Spoofed
The actual sender of the message might not be the same as
specified in the Sender or From fields of the message content
or the MAIL FROM address from the SMTP envelope
In a tightly constrained environment, sufficient physical
software controls may be able to ensure prevention of this problem
The usual solution is through encryption-based authentication,
for the channel or associated with the object, as discussed below
It should be recognized that SMTP implementations do not
inherent authentication of the senders of messages, nor are
under obligation to provide such authentication. End-to-
approaches such as S/MIME and PGP/MIME are currently being
within the IETF. These technologies can provide such authentication
5.2.2 Resources consumed by
In addition to the resources normally consumed for email (CPU
and disk), offramp facsimile causes an outdial which often
significant resource consumption, such as financial cost.
Toyoda, et. al. Standards Track [Page 6]
RFC 2305 Simple Mode of Facsimile March 1998
for establishing authorization of the sender are essential to
offramp facsimile services that need to manage such consumption
Due to the consumption of these resources by dialout,
bulk email which causes an outdial is undesirable
Offramp gateways SHOULD provide the ability to authorize senders
some manner to prevent unauthorized use of the offramp. There are
standard techniques for authorization using Internet protocols
Typical solutions use simple authentication of the originator
establish and verify their identity and then check the
against a private authorization table
Originator authentication entails the use of weak or
mechanisms, such as cleartext keywords or encryption-based data
signing, respectively, to determine and validate the identify of
sender and assess permissions accordingly
Other control mechanisms which are common include source
and originator authentication. Source filtering entails
gateway verification of the host or network originating the
and permitting or prohibiting relaying accordingly
5.2.3 GSTN authorization
Confidential information about the sender necessary to dial a G3
recipient, such as sender's calling card authorization number,
be disclosed to the G3Fax recipient (on the cover page), such
through parameters encoded in the G3Fax recipients address in the To
or CC: fields
Senders SHOULD be provided with a method of preventing
disclosure. As with mechanisms for handling unsolicited faxes,
are not yet standard mechanisms for protecting such information
Out-of-band communication of authorization information or use
encrypted data in special fields are the available non-
techniques
Typically authorization needs to be associated to specific
and specific messages, in order to prevent a "replay" attack
causes and earlier authorization to enable a later dial-out by
different (and unauthorized) sender. A non-malicious example of
a replay would be to have an email recipient reply to all
recipients -- including an offramp IFax recipient -- and have
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
In many countries, there is a legal requirement that the "sender"
disclosed on a facsimile message. Email From addresses are
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
information about the offramp, in the event of problems
The G3Fax recipient SHOULD be provided with sufficient
which permits tracing the originator of the IFax message.
information might include the contents of the MAIL FROM, From,
and Reply-To headers, as well as Message-Id and Received headers
5.2.5 Message
Users of G3Fax devices have an expectation of a level of
privacy which is higher than the level provided by Internet
without security enhancements
This expectation of privacy by G3Fax users SHOULD be preserved
much as possible
Sufficient physical and software control may be acceptable
constrained environments. The usual mechanism for ensuring
confidentially entail encryption, as discussed below
5.2.6 Non private
With email, bounces (delivery failures) are typically returned to
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-
account, or an IFax printer (see also [Traffic Analysis]).
5.2.7 Traffic
Eavesdropping of senders and recipients is easier on the
than GSTN. Note that message object encryption does not
traffic analysis, but channel security can help to frustrate
at traffic analysis
5.3 Security
There are two, basic approaches to encryption-based security
support authentication and privacy
Toyoda, et. al. Standards Track [Page 8]
RFC 2305 Simple Mode of Facsimile March 1998
5.3.1 Channel
As with all email, an IFax message can be viewed as it
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
used to prevent eavesdropping of a message as it traverses
networks. It also provides some protection against
analysis, as described above
5.3.2 Object
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
provide end-to-end encryption
6
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10,
821, August 1982.
[2] Crocker, D., "Standard for the Format of ARPA
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
Mail Extensions (MIME) Part Five: Conformance Criteria
Examples ", RFC 2049, November 1996.
[5] Parsons, G., and J. Rafferty, "Tag Image File
(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
Requirement Levels", RFC 2119, March 1997.
[8] ITU-T (CCITT), "Standardization of Group 3
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 -
3", STD 53, RFC 1939, May 1996.
[10] Crispin, M., "Internet Message Access Protocol -
4Rev1", RFC 2060, December 1996.
[11] Allocchio, C., "Minimal PSTN address format for
mail", RFC 2303, March 1998.
[12] Allocchio, C., "Minimal fax address format for
mail", RFC 2304, March 1998.
[13] Elkins, M., "MIME Security with Pretty Good
(PGP)", RFC 2015, October 1996.
[14] Moore, K., and G. Vaudreuil, "An Extensible
Format for Delivery Status Notifications", RFC 1894,
1996.
[15] Moore, K., "SMTP Service Extension for Delivery
Notifications", RFC 1891, January 1996.
[16] Freed, N., and N. Borenstein, "Multipurpose
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
Protocol", RFC 1825, Naval Research Laboratory, August 1995.
[19] Parsons, G. and Rafferty, J. "Tag Image File
(TIFF) -- image/TIFF: MIME Sub-type Registration", RFC 2302,
March 1998.
7
This specification was produced by the Internet Engineering
Force Fax Working Group, over the course of more than one year'
online and face-to-face discussions. As with all IETF efforts,
people contributed to the final product
Active for this document were: Steve Huston, Jeffrey Perry,
Vaudreuil, Richard Shockey, Charles Wu, Graham Klyne, Robert A
Rosenberg, Larry Masinter, Dave Crocker, Herman Silbiger,
Rafferty
Toyoda, et. al. Standards Track [Page 10]
RFC 2305 Simple Mode of Facsimile March 1998
8 AUTHORS'
Kiyoshi
Matsushita Graphic Communication Systems, Inc
2-3-8 Shimomeguro, Meguro-
Tokyo 153
Fax: +81 3 5434 7166
Email: ktoyoda@rdmg.mgcs.mei.co.
Hiroyuki
Tokyo Institute of
2-12-1 O-okayama, Meguro-
Tokyo 152
FAX: +81 3 5734 2754
Email: hohno@is.titech.ac.
Jun
Keio
5322 Endo,
Kanagawa 252
Fax: +81 466 49 1101
Email: jun@wide.ad.
Dan
Cisco Systems, Inc
101 Cooper
Santa Cruz, CA 95060
Phone: +1 408 457 5200
Fax: +1 408 457 5208
Email: dwing@cisco.
Toyoda, et. al. Standards Track [Page 11]
RFC 2305 Simple Mode of Facsimile March 1998
9 APPENDIX A: Exceptions to
* IFax senders are NOT REQUIRED to be able to
text/plain messages (RFC 2049 requirement 4), although
recipients are required to accept such messages, and to
them
* IFax recipients are NOT REQUIRED to offer to put
in a file. (Also see 2.3.2.)
* IFax recipients MAY directly print/fax the
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
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Toyoda, et. al. Standards Track [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
