draft-ietf-fax-esmtp-conneg-02.txt
"Toyoda, Kiyoshi" <[email protected]>
| Newsgroups | gmane.ietf.fax |
|---|---|
| Message-ID | <[email protected]> |
Freed-san, I found that I made a mistake about draft in the e-mail which I sent on 14th June. I attached a premature draft in that e-mail. So, my comments below "--Original Message--" was inconsistent with the attached draft. I am sorry to bother you. Please review the draft which I attached in this e-mail with my comments below. It is the correct one. -----Original Message----- From: "Toyoda, Kiyoshi" <[email protected]> To: [email protected] Cc: [email protected], [email protected], [email protected] Subject: Revised draft -02 according to AD review comments on draft-ietf-fax-esmtp-conneg-01.txt Date: Fri, 14 Jun 2002 17:10:18 +0900 Freed-san, Dave-san and I revised a ESMTP-CONNEG draft according to your suggestion. I comment in the following text and attach the revised draft. Would you comment and suggest us? [email protected] wrote: >Let's start with an obvious document issue, easily fixed: The IANA >considerations section. It currently says "This memo is not intended to create >any new issues for IANA." However, the document's primary goal is to define an >ESMTP extension, and registration of ESMTP extensions is an IANA activity. As >such, I suggest this section be changed to read "On publicatioj of this >document by the RFC Editor the IANA shall register the Content_Negotiation >ESMTP extension defined in section 2." We changed this section according to the suggestion above . > >Another minor document issue is that the RFC Editor has a new policy that >references must be separated into normative and informative groups. In this >case I think there is effectively no separation: All three of the references >here appear normative to me. So the thing to do is change the title of section >9 to "NORMATIVE REFERENCES". We changed the title of this section according to the suggestion above . > >Another document issue is that this document begins with a SUMMARY but has no >ABSTRACT or INTRODUCTION. The RFC Editor wants to see a separate ABSTRACT and >INTRODUCTION section in all new RFCs. I would suggest keeping the current >SUMMARY as the ABSTRACT and writing a new INTRODUCTION, reiterating the >ABSTRACT but adding some additional background information if possible. We kept SUMMARY as the ABSTRACT and wrote a new INTRODUCTION. > >On to security considerations. What's there seems entirely appropriate. >However, there's are two other security considerations I believe deserve >mention: The possibility that a vulnerability will be disclosed by the >mechanism and the possibility of tampering with the result the mechanism >returns. > >The first specific case that concerns me is that of a capability that is >typically handled by, say, a plugin that has been found to contain a security >vulnerability. Disclosure of support for this capability becomes tantamount to >disclosing a vulnerability. We added some text for this section. > >The second case is one where a man in the middle changes the capabilities >associated with a given recipient. Here's a somewhat fanciful example: Suppose >the sender knows the recipient has the ability to view color documents so they >mark some things in red in what is otherwise a black and white document. But >someone interferes with the returned capabilities, making them say the >recipient only supports black and white. The document is duly downgraded, with >the result that the recipient doesn't see what the sender marked. (Of course >the man in the middle could have tampered with the document itself, but >modifying a document on the fly is a much more difficult proposition.) We added the paragraph above into the security considerations section. > >I'm not suggesting that this facility be changed to address these issues, >merely that they be mentioned in the security considerations section. > >Next up is failure modes. The model defined here seems simple enough: Client >asks server for capabilities for a given recipient and the server either >returns those capabilities or fails with a CONNEG-specific error code. > >I wonder, however, if this isn't too simple. A server may have no trouble >delivering mail to a given recipient but might be unable to return that >recipient's capabilities. And this could be either a temporary or permanent >failure: The directory containing this information could be offline, or it >could be the case that this information simply isn't available for this >particular recipient. > >Of course a client that receives a 504 can always retry the recipient without >the CONNEG parameter if it is willing to operate in the absence of capability >information. But it may want to take different actions depending on whether the >failure is temporary or permanent: I could easily see sending some sort of >default for a permanent failure while waiting to retry in the even of a >temporary failure. > >I therefore suggest that an additional 404 status code be defined that can be >returned when the server experiences a temporary failure getting capability >information. We defined 404 status code in the first paragraph of chapter 4.3. > >The unconditional use of a failure code when capabilities aren't available also >concerns me. While it is true the client can simply reissue the RCPT TO without >the CONNEG parameter, handling this case effectively stalls the SMTP dialogue. >(That is, the client has to wait for the response to the RCPT TO before it >knows how to proceed.) And dialogue stalls are a significant operational issue >in practice. I therefore suggest that the mechanism be changed to allow a >CONNEG parameter value. The value would be, say, either REQUIRED or OPTIONAL. >The REQUIRED value would result in the same behavior currently described in the >document. The OPTIONAL case, however, would instruct the server to proceed >normally and return a _success_ status when the capabilities aren't available. >A corresponding 2xx code would need to be defined for this case. We defined "REQUIRED" and "OPTIONAL" as the parameter value in chapter 4.1. In the case of "OPTIONAL", I defined the target action as below. This is the third paragraph in chapter 4.3. If the client specifies "CONNEG = OPTIONAL" in the RCPT-TO, the target MUST process the address and message as if the requested CONNEG capabilities had not been specified. > >This document also fails to specify what enhanced status code should be >returned in the event the server is unable to return capabilities information. >Looking at the list in RFC 1893 I'd say one possibility is x.3.3, system not >capable of selected feature. I also note in passing that there are no examples >of CONNEG failures in the examples section. Some examples of this sort need to >be added. We defined enhanced status code in the case of false return to RCPT-TO CONNEG. The paragrapg below is the fifth one in chapter 4.3. If the SMTP server supports ENHANCEDSTATUSCODES, the response strings for a success are "250-2.1.5 CONNEG" and "250 2.1.5 CONNEG". The response strings for indicating a permanent failure are "504-5.3.3 CONNEG" and "504 5.3.3 CONNEG". The response strings for a temporary failure are "404-4.3.3 CONNEG" and "404 5.3.3 CONNEG". And some examples of CONNEG failure are added to chapter 6. > >Another interesting case that could arise in practice is where a server is >configured to require authentication, integrity, or privacy services before >capability information can be returned. I think the document needs to discuss >this case, saying that if such requirements have not been met the CONNEG >extension should not be offered in the EHLO response. (Note that successful >security negotiation already involves repeating EHLO.) We added the paragraph above into the security considerations section. > >Although several examples of returned capabilities are shown, the document >isn't very specific about how capabilities have to be formatted. In particular, >I'd expect to see capabilities often stored as a single string without any line >breaks. Some advice on how to take such a string and format it for inclusion in >the reponse seems warranted. We defined how capabilities have to be formatted in the sixth paragraph of chapter 4.3. Line breaks should not been inserted if CONNEGFAX lines is less than 512. I changed the sample according this rule. > >According to this document the only capabilities that can be returned are those >defined in RFC 2879, which is FAX-specific. I realize this document is a >product of the FAX WG, but is this really appropriate? Should more general >capabilites return be allowed? And if not, shouldn't this extension be called >FAXCONNEG or something similar? We believe that the mechanisms is quite general and that we should encourage its use for more than facscimile over the Internet. So we changed the requirement in section 4 for more general use of SMTP CONNEG as below. The contents of the capability listing MUST conform to [RFC2506], [RFC2533] and [RFC2534], and MAY be used to emulate services, such as the facsimile start-of-session capabilities negotiation as described in "Content Feature Schema for Internet Fax". [RFC2879] > >Finally, this document makes passing reference to "use in relay scenarios". I >think some elaboration of this might be in order. In particular, I see at least >two scenarios that involve relaying: One where a server knows it will >subsequently relay the message but offers up capability information by proxy, >and another where the client is an intermediary service with message >downgrading capabilities. We've added a small amount of text to the last sentence in the abstract and the last sentence in section 1. The text describes "direct" use. This should make the idea of relaying work as an extension to direct exchange. We believe that the document does not need more about "use in relay scenarios". Best regards, Kiyoshi Toyoda
draft-ietf-fax-esmtp-conneg-02.txt
(application/octet-stream, 18.1 KB)
Network Working Group K. Toyoda, MGCS
Internet Draft D. Crocker, Brandenburg
DRAFT-IETF-FAX-ESMTP-CONNEG-02.TXT June 2002
Expires: December 2002
SMTP Service Extension
for Content Negotiation
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full
conformance with all provisions of Section 10 of
RFC2026. Internet-Drafts are working documents of the
Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum
of six months and may be updated, replaced, or
obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be
accessed at
http://www.ietf.org/shadow.html.
COPYRIGHT NOTICE
Copyright (C) The Internet Society (2001). All Rights
Reserved.
ABSTRACT
This document defines a content negotiation service
extension for SMTP [ESMTP1, ESMTP2] whereby an SMTP
client may request information about content
capabilities of the target device or system that is
serviced by an SMTP server. The SMTP server may report
the target's content capabilities back to the client.
This process emulates a classic facsimile start-of-
session capabilities negotiation, although it can be used
for a broad range of email-based scenarios. This service
extension is primarily intended for "direct", one-hop,
originator/recipient SMTP transfers, although relayed
scenarios through multiple SMTP servers are permitted.
1. INTRODUCTION
When a data source and a receiver have interactive access to
each other, the receiver often informs the source of its
capabilities, to permit optimized performance or functionality for
the interaction. Classic telephone-based facsimile is an example,
as are voice over IP and ESMTP among Internet applications. The
store-and-forward nature of Internet mail is usually assumed to
preclude such capabilities exchanges. However direct email-based
interactions are possible with proper configuration of the email
originator and recipient servers, such as over an intranet.
This document defines an SMTP-based service extension [ESMTP1,
ESMTP2] for content negotiation, whereby an SMTP client may
request information about content capabilities of the target
device or system that is serviced by an SMTP server. The SMTP
server may report the target's content capabilities back to the
client. This process emulates a classic facsimile start-of-session
capabilities negotiation, although it may be used for any email-
based service. This extension is primarily intended for "direct"
SMTP transfers, although relayed scenarios are permitted through a
series of SMTP servers.
2. CONVENTIONS
In examples, "C:" and "S:" indicate lines sent by the
client and server respectively.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" in this document are to be interpreted
as defined in "Key words for use in RFCs to Indicate
Requirement Levels" [KEYWORDS].
3. CONTENT NEGOTIATION SERVICE EXTENSION
(1) The name of the SMTP service extension is
"Content_Negotiation"
(2) The EHLO keyword value associated with this extension
is "CONNEG"
(3) A parameter using the keyword "CONNEG" is added to the
RCPT-TO command
(4) The server responds with a report of the content
capabilities of the device or system that embodies the
target RCPT-TO address.
4. CONNEG PARAMETER TO RCPT-TO
4.1 Parameter
Keyword:
CONNEG
Argument:
REQUIRED
The client requires support for the capability. If the
target does not support the CONNEG parameter, the target
MUST reject the RCPT-TO command with a 504 reply.
If the target can not support the capability due to a
temporary problem, it MUST reject the RCPT-TO command with
a 404 reply.
OPTIONAL
The client requests the target to use the capability. If
the target can not support the capability at this time, the
target MUST process the address and message as if the
requested CONNEG capabilities had not been specified.
If the argument does not exist, the default is "REQUIRED".
When a capability is REQUIRED by the client but can not
currently be supported by the target, an error response will
have significant performance impact to overall SMTP
processing. Use of the OPTIONAL parameter will ensure high
SMTP performance.
4.2 Client Action:
If the server issued a 250-CONNEG, as part of its
EHLO response for the current session, the client MAY
issue the CONNEG parameter with RCPT-TO.
If the client issues the CONNEG parameter with
RCPT-TO, then it MUST honor the capabilities specified
in the CONNEG RCPT-TO reply, and transform data that is
sent, so that the target can accept the data. The
client SHOULD transform the data to the "highest" level
of capability of the target.
If the server rejects the RCPT-TO command with a 404 reply, the
client may later reissue the RCPT-TO with the CONNEG parameter.
If the server returns an EHLO 250 code without CONNEG
capabilities, the client MUST work as "a Simple Mode of Facsimile
Using Internet Mail" [RFC2305].
4.3 Server Action:
If the client specifies "CONNEG = REQUIRED" in the RCPT-TO,
but the target does not support the CONNEG parameter, the target
MUST reject the RCPT-TO command with a 504 reply.
If the target support the CONNEG parameter, but it can not return
the recepient's capability temporarily, the target MUST reject the
RCPT-TO command with a 404 reply. For example, if the target get
the capability information from a directory, but its connection is
offline, the target MUST reject the RCPT-TO command with a 404
reply.
If the client specifies "CONNEG = OPTIONAL" in the RCPT-TO, the
target MUST process the address and message as if the requested
CONNEG capabilities had not been specified.
Regardless of the value of the parameter, if the target does
support the CONNEG parameter, then it MUST issue a 250 reply,
followed by the capabilities of the target that is specified by
the RCPT-TO address. Successful responses to CONNEG RCPT-TO
requests will always be multiple SMTP lines. The first line
is the normal RCPT-TO response, and subsequent lines beginning
with the exact string "250-CONNEG " and "250 CONNEG " are
the CONNEG responses. The last line begins with "250
CONNEG".
If the SMTP server supports ENHANCEDSTATUSCODES, the response
strings for a success are "250-2.1.5 CONNEG" and "250 2.1.5
CONNEG". The response strings for indicating a permanent
failure are "504-5.3.3 CONNEG" and "504 5.3.3 CONNEG".
The response strings for a temporary failure are "404-4.3.3
CONNEG" and "404 5.3.3 CONNEG".
All CONNEG-capable clients and CONNEG-capable servers MUST
be able to successfully process CONNEG lines that are up to 512
characters long, as required by RFC2821. If the length of CONNEG
lines is greater than 512 characters, the server MUST insert
line breaks and make next CONNEG line.
The contents of the capability listing MUST conform to
[RFC2506], [RFC2533] and [RFC2534], and MAY be used to emulate
services, such as the facsimile start-of-session capabilities
negotiation as described in "Content Feature Schema for
Internet Fax". [RFC2879]
5. SYNTAX
Command with "CONNEG":
"RCPT TO:" ("<Postmaster@" domain ">" / "<Postmaster>"
/ Forward-Path) (SP "CONNEG =" ("REQUIRED" /
"OPTIOANL") CRLF
Reply:
( ("250-" CRLF) *("250-CONNEG" capability CRLF)
("250 CONNEG" capability CRLF) )/
( ("250-2.1.5" CRLF)
*("250-2.1.5 CONNEG" capability CRLF)
("250 2.1.5 CONNEG" capability CRLF) )/
("504" CRLF) /
("504 5.3.3" CRLF) /
("404" CRLF) /
("404 4.3.3" CRLF) /
capability = <<as per [RFC2506], [RFC2533], [RFC2534]
and [RFC2879] >>
6. EXAMPLE
An example of ESMTP sequence with successful RCPT-TO response
S: 220 ifax1.jp IFAX
C: EHLO ifax1.jp
S: 250-ifax1.jp
S: 250-DSN
S: 250 CONNEG
C: MAIL FROM:<[email protected]>
S: 250 <[email protected]> sender ok
C: RCPT TO:<[email protected]> CONNEG = REQUIRED
S: 250-<[email protected]> recipient ok
S: 250 CONNEG (&(image-file-structure=TIFF-minimal)
S: (MRC-mode=0)(color=Binary)(|(&(dpi=204)
S: (dpi-xyratio=[204/98,204/196]) )(&(dpi=200)
S: (dpi-xyratio=[200/100,1]) )(&(dpi=400)
S: (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR])
S: (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85)
S: (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4])
S: (ua-media=stationery) )
C: DATA
S: 354 okay, send data
C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
Per:
( image-file-structure=TIFF-minimal
dpi=400
image-coding=JBIG
size-x=2150
)
>>
S: 250 message accepted
C: QUIT
S: 221 goodbye
An example of successful RCPT-TO response when the length of
capability is greater than 512 characters.
S: 250-2.1.5<[email protected]> recipient ok
S: 250-2.1.5 CONNEG (&(image-file-structure=TIFF-minimal) ...
S: 250-2.1.5 CONNEG .....
S: 250 2.1.5 CONNEG (color=Binary)
An example of succssful RCPT-TO response when CONNEG-capable
server supports ENHANCEDSTATUSCODES.
S: 250-2.1.5<[email protected]> recipient ok
S: 250 2.1.5 CONNEG (&(image-file-structure=TIFF-minimal)
S: (MRC-mode=0)(color=Binary)(|(&(dpi=204)
S: (dpi-xyratio=[204/98,204/196]) )(&(dpi=200)
S: (dpi-xyratio=[200/100,1]) )(&(dpi=400)
S: (dpi-xyratio=1) ) )(|(image-coding=[MH,MR,MMR])
S: (&(image-coding=JBIG)(image-coding-constraint=JBIG-T85)
S: (JBIG-stripe-size=128) ) )(paper-size=[letter,A4,B4])
S: (ua-media=stationery) )
An example of ESMTP sequence with parmanent failure RCPT-TO
response.
S: 220 ifax1.jp IFAX
C: EHLO ifax1.jp
S: 250-ifax1.jp
S: 250-DSN
C: MAIL FROM:<[email protected]>
S: 250 <[email protected]> sender ok
C: RCPT TO:<[email protected]> CONNEG = REQUIRED
S: 504 <[email protected]> recipient ok
C: QUIT
S: 221 goodbye
An example of an ESMTP sequence with temporary failure RCPT-TO
response when the value of parameter is "REQUIRED":
S: 220 ifax1.jp IFAX
C: EHLO ifax1.jp
S: 250-ifax1.jp
S: 250-DSN
S: 250 CONNEG
C: MAIL FROM:<[email protected]>
S: 250 <[email protected]> sender ok
C: RCPT TO:<[email protected]> CONNEG = REQUIRED
S: 404 <[email protected]> recipient ok
C: QUIT
S: 221 goodbye
.
.
.
retry according to implementation
An example of an ESMTP sequence with temporary failure RCPT-TO
response when the value of parameter is "OPTIONAL":
S: 220 ifax1.jp IFAX
C: EHLO ifax1.jp
S: 250-ifax1.jp
S: 250-DSN
S: 250 CONNEG
C: MAIL FROM:<[email protected]>
S: 250 <[email protected]> sender ok
C: RCPT TO:<[email protected]> CONNEG = OPTIONAL
S: 250 <[email protected]> recipient ok
C: DATA
S: 354 okay, send data
C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
Per "A Simple Mode of Facsimile Using Internet Mail"
RFC2305
>>
S: 250 message accepted
C: QUIT
S: 221 goodbye
7. IANA CONSIDERATIONS
On publicatiom of this document by the RFC Editor, the IANA
shall register the Content_Negotiation ESMTP extension defined
in section 3.
8. SECURITY CONSIDERATIONS
This ESMTP option calls for a respondent to disclose
its capabilities. Mechanisms for determining the
requestor's authenticated identity are outside the
scope of this specification. It is intended that this
mechanism permit disclosure of public information;
hence there is no particular need for security
measures.
However there is nothing to prevent disclosure of
sensitive information that should receive restricted
distribution. It is, therefore, the responsibility of
the disclosing ESMTP server to determine whether
additional security measures should be applied to the
use of this ESMTP option.
A man-in-the-middle attack might change the capabilities reported
for a given recipient. For example: Suppose the sender knows the
recipient has the ability to view color documents so they mark
some things in red in what is otherwise a black and white
document. But someone interferes with the returned capabilities,
indicating that the recipient only supports black and white. The
document is duly downgraded, with the result that the recipient
doesn't see what the sender marked.
An indirect exposure can occur when the report of a capability
implies use of specific software. If that software is known to
have security weaknesses, the capabilities report effectively
advertises the associated opportunity to exploit the security
weakness.
For target SMTP servers that require security mechanisms to be in
force at the start of the session, the target SHOULD refrain from
including the CONNEG parameter in an EHLO response until the
requisite security mechanisms are in force.
9. ACKNOWLEDGEMENTS
Graham Klyne provided useful suggestions to an earlier
draft.
10. NORMATIVE REFERENCES
[ESMTP1] Klensin, J., Freed, N., Rose, M., Stefferud,
E. and D. Crocker, "SMTP Service Extensions",
RFC 1869, November 1995
[ESMTP2] Klensin, J., "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC2879] McIntyre, L. and G. Klyne, "Content Feature
Schema for Internet Fax", RFC 2531, August
2000
[RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing,
"A Simple Mode of Facsimile Using Internet Mail",
RFC 2305, March 1998.
[RFC2506] Holtman, K., Mutz, A. and T. Hardie, "Media Feature
Tag Registration Procedure", RFC 2506, March 1999.
[RFC2533] Klyne, G., "A syntax for describing media feature
sets", RFC 2533, March 1999.
[RFC2534] Masinter, L., Holtman, K., Mutz, A. and D. Wing, "
Media Features for Display, Print, and Fax",
RFC 2534, March 1999.
11. AUTHORS' ADDRESSES
Kiyoshi Toyoda
Matsushita Graphic Communication Systems,Inc
2-3-8 Shimomeguro, Meguro-Ku
Tokyo 153 JAPAN
+81.3.5434.7161
[email protected]
Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086 USA
+1.408.246.8253
[email protected]
12. FULL COPYRIGHT STATEMENT
Copyright (C) The Internet Society (2001). 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.