Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard
Keith Moore <moore@cs.utk.edu> Tue, 02 July 2002 05:53 UTC
Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g625rBP04222 for ietf-smtp-bks; Mon, 1 Jul 2002 22:53:11 -0700 (PDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g625r9w04215; Mon, 1 Jul 2002 22:53:09 -0700 (PDT)
Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g625rC228738; Tue, 2 Jul 2002 01:53:12 -0400 (EDT)
Message-Id: <200207020553.g625rC228738@astro.cs.utk.edu>
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: iesg@ietf.org
cc: ietf-fax@imc.org, ietf-smtp@imc.org
Subject: Re: Last Call: SMTP Service Extension for Content Negotiation to Proposed Standard
In-reply-to: (Your message of "Mon, 01 Jul 2002 17:34:24 EDT.") <200207012134.RAA04928@ietf.org>
Date: Tue, 02 Jul 2002 01:53:12 -0400
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>
[referencing draft-ietf-fax-esmtp-conneg-02.txt] executive summary: I recommend against approval of this document withut extensive changes. It's not well thought-out (except for the rather narrow application of SMTP to a one-recipient fax gateway) and it seems likely to degrade SMTP interoperabliity if widely adopted. I do suggest some changes which would make it less harmful, but it still needs considerable work to be of general applicability. 1. layering problems this functionality is a poor fit for SMTP because SMTP is the mail *transport* protocol, and as such should not be dealing with content at all, which is a user agent function. I admit that (by design) there is no opportunity for e2e interaction at the user agent level in the current protocols, and also that any mechanism that might be used to advertise user agent capabliities (e.g. rescap) introduces the opportunity for that mechanism to get out-of-sync with the actual capabilities/preferences of the recipient. but what's to stop this mechanism from getting out-of-sync also? it seems like this extension has very limited applicability - it will only work reliably when the SMTP server and user agent or gateway are very closely tied and when the recipient always uses the same UA or UAs of very similar capabilities. (certainly not true of me!) one can argue that extending SMTP to allow it to perform negotiation on behalf of the user agent is no worse than putting that negotiation in a separate protocol. but if we're going to extend SMTP to perform functions on behalf of the user agent, it needs to be made very explicit that this negotiation is being done on behalf of the user agent - and in particular that the negotiation being requested represents the preferences of the *user* (i.e. the sender and/or recipient) rather than some third party. IIRC, this is the same thing that was insisted on for the OPES stuff - the negotiation/transformation needs to have explicit consent from, and be under control of, at least one of the ultimate endpoints (sender or receiver) and it seems to me that it's appropriate to apply the same policy for email. 2. protocol design problem for transformations that should be under control of specific recipients, the protocol is poorly designed. in particular there seems to be no ability to apply content-transformation on a per-recipient basis, to handle the case where different transformations are acceptable to differnet recipients. again, this drastically limits the applicability of the protocol (it won't work well unless all recipients at that SMTP server have the same capability set, which is very unlikely for most conventional SMTP servers) of course it's not easy to get SMTP to handle different client-side transformations for different recipients, since SMTP is designed to transfer the exact same message body (modulo received fields) to each of a set of recipients. this is a different model than used by phone-based facsimile protocols which expect there to be only one recipient of any given transmission, so it's not surprising that the fax-style negotiation doesn't fit well into SMTP. in order to make client-side negotiation a clean fit into SMTP, it is necessary for the client to first query the server for the capabilities of each intended recipient, then to deduce how many total transformations are necessary, then to send one or more transformed versions of the message. for instance, if recipients A, B, E, and F could accept one transformation of the message and recipients B, C, and D could could accept a higher quality transformation of the message, the client might attempt to send the high-quality version to B, C, and D and then send the lower quality version to A, E, and F. but as currently designed the proposed extension doesn't have the necessary protocol hooks to permit this - at least not without a considerable amount of ugliness. overloading the RCPT command to return capabilities breaks the RCPT command and forces the client to do RSET in order to send different versions to different recipients. 3. timing this proposal could not have come at a worse time. putting content negotiation in the transport protocol is likely to result in a significant increase in anomolous behaviors from the mail system which are difficult to diagnose and fix - and the proposal is being introduced at a time when the mail system is already suffering from serious reliabliity problems (often due to ill-conceived measures for blocking spam). at this time, *any* proposal for adding new functionality to SMTP should be viewed with strong reservations, unless it somehow offers an improvement in reliability. a proposal that significantly increases the complexity of SMTP error handling seems unlikely to do that. 4. naming and applicability the protocol claims to be a general-purpose content-negotiation scheme but actually has "fax" assumptions embedded very deeply. first of all, it assumes that there is a linear ordering relationship for document suitability to the recipient. while this might be arguable for facsimile images (even this is debatable given orthogonal attributes like resolution and color), it's certainly not the case for MIME email in general. 5. recommendations a. I strongly recommend that you redesign this extension so that, instead of overloading the RCPT command, you define a separate command to request a recipient's capabilities. e.g. RCAP <recipient-addr> would return the conneg capability associated with that recipient, if available. there would need to be separate indications for permanent error (perhaps if the recipient addr were invalid), temporary error (e.g. can't do the database lookup), no capabliities available (perhaps not an error, just no information), and a return of capabilities. one nice side-benefit is that it doesn't change the error handling model, because the proposal mentioned above doesn't affect the actual message handling commands at all. (however it does add a few round trip delays) b. the idea that the sender should send the "best" or "highest quality" version needs to be relaxed or generalized, since there's currently no clear notion of what this means. (and thus no way to know whether an implementation conforms to these criteria). c. this extension needs to be made less fax-specific. it needs to be examined with some realistic non-fax-specific test cases, and it needs non-fax conneg examples also. d. there needs to be a good way for the recipient to specify capabilities to the SMTP server, at least for any SMTP server that can serve arbitrary UA recipients. probably this means another extension along with SMTP AUTH. still, this is a big can of worms, because there's never been any ability of a UA to specify something to its inbound SMTP servers before - there's presently not even a good way for a UA to know which server(s?) should be given this information... e. make it absolutely clear that such transformations are only to be made with explicit authorization by the sender and/or recipient. (a dedicated smtp-to-printer hardware device would be considered to have explicit authorization simply because it was purchased for such a purpose, but a SMTP server acting on behalf of a user using a general-purpose MUA would need such authorization) f. the document needs to consider the effect of message forwarding on the returned string - if a recipient has his mail forwarded elsewhere it's not clear what conneg string should be returned. g. the document alludes to the ability to work through intermediaries but this isn't explained anywhere, and it needs to be explained. 6. specific problems > 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. this incorrectly assumes that (a) there is only one target when the client can easily specify multiple RCPT commands, and (b) there is a clear notion of "highest level of capability" for the target. also why is the term "target" used rather than the more traditional "recipient" or "mailbox"? > If the server rejects the RCPT-TO command with a 404 reply, the > client may later reissue the RCPT-TO with the CONNEG parameter. presumably in the context of a different SMTP session? it's not clear... > 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. here there is a potential conflict between various extensions. a RCPT command may fail for any number of reasons. if any of those reasons is a permanent fatal error it should be sufficient for the server to report any one of those errors. it's not reasonable for this extension to pre-empt other error notificaitons. (it may be that other extensions have similar wording, in which case they're similarly flawed) > 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. similarly: if any permanent failure is detected in the RCPT command, the appropriate 5xx response SHOULD probably be returned in preference to any 4xx response. for instance if the recipient's mailbox has been administratively disabled then a 5xx response should be returned rather than a 404 response which would mean "ask me later what kind of media types this recipient can accept"... whereupon the client would do so only to (eventually) find out that it couldn't deliver the message to the recipient anyway. > 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 doesn't seem to make sense as written. is "CONNEG = OPTIONAL" really supposed to be interpreted the same as omission of the CONNEG parameter? also, I don't think there should be spaces around the = sign - I don't think this is legal syntax for SMTP extensions. > Regardless of the value of the parameter, if the target does > support the CONNEG parameter, then it MUST issue a 250 reply, again, there could be other reasons for permanent or temporary failure of the RCPT command, and the assertion of a CONNEG parameter should not pre-empt the reporting of such failures. > 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". I wonder here - assuming that this can of worms does not get closed back up, and there might later be demand for other mechanisms to request recipient capabilities (e.g. since this one is not very general), might there be multiple kinds of strings emitted in the RCPT response? e.g. CONNEG and CONNEG2 and FINAL_SOLUTION_CONNEG? and if so should this document insist that CONNEG be last? > 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". are these codes already defined in 1893? (I didn't look) I don't think it's appropriate to dictate extended status codes since their entire purpose is to provide more precision than the SMTP reply codes. there are various sources of permanent failure and various sources of temporary failure and the set of status codes is extensible independently of SMTP reply codes. > 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. CONNEG *what* lines? command lines? response lines? both? > 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 the space doesn't belong after CONNEG, and OPTIONAL is misspelled. > > 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) / it's not appropriate to put literal response codes in the grammar, particularly the extended status codes which might actually need to vary more than is indicated here. much better to have something like: reply: initial-reply *(conneg-reply/other-reply) final-reply initial-reply: reply-code "-" [ status-code ] CRLF conneg-reply: reply-code "-" [ status-code " " ] "CONNEG" capability CRLF other-reply: reply-code "-" [ status-code ] *char CRLF final-reply: reply-code " " [ status-code ] 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:<May@ifax2.jp> > > S: 250 <May@ifax2.jp> sender ok > > C: RCPT TO:<June@ifax1.jp> CONNEG = REQUIRED > > S: 250-<June@ifax1.jp> 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) ) this needs clarification - it looks like the sender is sending multiple lines without a 250 or CONNEG on each line. it would probably be better to break up this example into several SMTP lines and also to explain that any of those lines can be longer (up to XXX bytes) than shown in the example. > > 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 > ) > >> this is confusing - it makes it appear that TIFF-FX is the only content-type acceptable. also TIFF-FX is not the name of the content-type, presumably it's application/tiff-fx or some such. > > 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<June@ifax1.jp> 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<June@ifax1.jp> 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) ) again, this response is confusing because it's line wrapped > > > 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:<May@ifax2.jp> > > S: 250 <May@ifax2.jp> sender ok > > C: RCPT TO:<June@ifax1.jp> CONNEG = REQUIRED > > S: 504 <June@ifax1.jp> 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:<May@ifax2.jp> > > S: 250 <May@ifax2.jp> sender ok > > C: RCPT TO:<June@ifax1.jp> CONNEG = REQUIRED > > S: 404 <June@ifax1.jp> 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:<May@ifax2.jp> > > S: 250 <May@ifax2.jp> sender ok > > C: RCPT TO:<June@ifax1.jp> CONNEG = OPTIONAL > > S: 250 <June@ifax1.jp> 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. seems like you should at least mention SMTP AUTH. > 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. the STARTTLS command could be useful in providing integrity assurance. > 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.
- Re: Last Call: SMTP Service Extension for Content… ned.freed
- Re: Last Call: SMTP Service Extension for Content… Arnt Gulbrandsen
- Re: Last Call: SMTP Service Extension for Content… Keith Moore
- Re: Last Call: SMTP Service Extension for Content… Valdis.Kletnieks
- Re: Last Call: SMTP Service Extension for Content… ned.freed
- Re: Last Call: SMTP Service Extension for Content… Arnt Gulbrandsen
- Re: Last Call: SMTP Service Extension for Content… Keith Moore
- Re: Last Call: SMTP Service Extension for Content… Dave Crocker
- Re: Last Call: SMTP Service Extension for Content… Keith Moore
- Re: Last Call: SMTP Service Extension for Content… Dave Crocker
- Re: Last Call: SMTP Service Extension for Content… Keith Moore
- Re: Last Call: SMTP Service Extension for Content… Dave Crocker
- Re: Last Call: SMTP Service Extension for Content… Keith Moore
- Re: Last Call: SMTP Service Extension for Content… Robert A. Rosenberg
- Re: Last Call: SMTP Service Extension for Content… Keith Moore
- Re: Last Call: SMTP Service Extension for Content… Robert A. Rosenberg
- Re: Last Call: SMTP Service Extension for Content… Dave Crocker
- Re: Last Call: SMTP Service Extension for Content… Dave Crocker
- Re: Last Call: SMTP Service Extension for Content… Dave Crocker
- Re: Last Call: SMTP Service Extension for Content… Robert A. Rosenberg
- Re: Last Call: SMTP Service Extension for Content… Valdis.Kletnieks
- Re: Last Call: SMTP Service Extension for Content… Keith Moore
- Re: Last Call: SMTP Service Extension for Content… Dave Crocker
- Re: Last Call: SMTP Service Extension for Content… Keith Moore
- Re: Last Call: SMTP Service Extension for Content… John C Klensin
- Re: Last Call: SMTP Service Extension for Content… Keith Moore
- Re: Last Call: SMTP Service Extension for Content… Dave Crocker
- Re: Last Call: SMTP Service Extension for Content… Keith Moore