From owner-drums@cs.utk.edu Fri Jul 7 17:32:46 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13714 for ; Fri, 7 Jul 2000 17:32:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA03564; Fri, 7 Jul 2000 17:32:17 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 7 Jul 2000 17:32:07 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA03472; Fri, 7 Jul 2000 17:32:06 -0400 (EDT) Received: from A4.JCK.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA03415; Fri, 7 Jul 2000 17:32:02 -0400 (EDT) Received: from A4.JCK.COM (209.187.148.211 -> ns.jck.com) by cs.utk.edu (smtpshim v1.0); Fri, 7 Jul 2000 17:32:03 -0400 Received: from P2 ("port 1146"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #40360) with ESMTP id <0FXC00E0OJVBCH@a4.jck.com> for drums@cs.utk.edu; Fri, 07 Jul 2000 17:33:11 -0400 (EDT) Date: Fri, 07 Jul 2000 17:14:00 -0400 From: John C Klensin Subject: The 551/251 question To: drums@cs.utk.edu Message-id: <917366236.962990040@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit The consensus seems to be to deprecate both of these. Proposed text (last part of the 2nd (i.e., former last) paragraph of section 3.4 and a new paragraph) follows. Again, please speak up only if you cannot live with this (and do so soon). described in section 3.2 of RFC 821, and especially the 251 (corrected destination) reply code from RCPT are deprecated: While servers MAY quietly forward messages when they are aware of an address change, they SHOULD NOT provide address-updating information via a 251 code. Similar considerations apply to 551. While an SMTP client that handles it only as a permanent failure message will presumably do the correct thing and route the message back to the user as undeliverable, the use of the code implies belief on the server's part that automatic address book updating will occur. That expectation is unreasonable, since no, or virtually no, client SMTP systems in the contemporary Internet provide that service (it made much more sense when messages were sent directly from user processes to receiving SMTP systems). Consequently, servers SHOULD NOT attempt to provide address-updating information via a 551 code. From owner-drums@cs.utk.edu Fri Jul 7 17:32:49 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13731 for ; Fri, 7 Jul 2000 17:32:49 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA03558; Fri, 7 Jul 2000 17:32:17 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 7 Jul 2000 17:32:04 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA03444; Fri, 7 Jul 2000 17:32:04 -0400 (EDT) Received: from A4.JCK.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA03401; Fri, 7 Jul 2000 17:32:00 -0400 (EDT) Received: from A4.JCK.COM (209.187.148.211 -> ns.jck.com) by cs.utk.edu (smtpshim v1.0); Fri, 7 Jul 2000 17:32:01 -0400 Received: from P2 ("port 1146"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #40360) with ESMTP id <0FXC00E0OJVBCH@a4.jck.com> for drums@cs.utk.edu; Fri, 07 Jul 2000 17:33:11 -0400 (EDT) Date: Fri, 07 Jul 2000 17:09:27 -0400 From: John C Klensin Subject: The "Postmaster" text To: drums@cs.utk.edu Message-id: <917093036.962989767@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit I've tried to synthesize something from the various suggestions that seemed to reach agreement among portions of the WG. Please consider this a "can you live with this" last call on the paragraph below. SMTP systems are expected to make every reasonable effort to accept mail directed to Postmaster from any other system on the Internet. In extreme cases --such as to contain a denial of service attack or other breach of security-- an SMTP server may block mail directed to Postmaster. However, such arrangements SHOULD be narrowly tailored so as to avoid blocking messages which are not part of such attacks. This seems to capture the core of Chris's original proposal, gets rid of the objectionable "mechanism" statement, and adds Keith's "narrowly tailored" language, which I (and apparently several others) rather like. john From owner-drums@cs.utk.edu Fri Jul 7 17:32:50 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13742 for ; Fri, 7 Jul 2000 17:32:50 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA03562; Fri, 7 Jul 2000 17:32:17 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 7 Jul 2000 17:32:07 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA03484; Fri, 7 Jul 2000 17:32:06 -0400 (EDT) Received: from A4.JCK.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA03417; Fri, 7 Jul 2000 17:32:02 -0400 (EDT) Received: from A4.JCK.COM (209.187.148.211 -> ns.jck.com) by cs.utk.edu (smtpshim v1.0); Fri, 7 Jul 2000 17:32:03 -0400 Received: from P2 ("port 1146"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #40360) with ESMTP id <0FXC00E0OJVBCH@a4.jck.com> for drums@cs.utk.edu; Fri, 07 Jul 2000 17:33:12 -0400 (EDT) Date: Fri, 07 Jul 2000 17:25:45 -0400 From: John C Klensin Subject: Bare CR and LF To: drums@cs.utk.edu Message-id: <918071096.962990745@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit Consensus appears to be to prohibit this. The planned relevant paragraph, to go at the end of 2.3.7, is below. Anyone objecting should speak up very quickly. In addition, the appearance of "bare" "CR" or "LF" characters in text (i.e., either without the other) has a long history of causing problems in mail implementations and applications that use the mail system as a tool. SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a sequence. john From owner-drums@cs.utk.edu Fri Jul 7 17:39:59 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13713 for ; Fri, 7 Jul 2000 17:32:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA03551; Fri, 7 Jul 2000 17:32:17 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 7 Jul 2000 17:32:07 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA03483; Fri, 7 Jul 2000 17:32:06 -0400 (EDT) Received: from A4.JCK.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA03416; Fri, 7 Jul 2000 17:32:02 -0400 (EDT) Received: from A4.JCK.COM (209.187.148.211 -> ns.jck.com) by cs.utk.edu (smtpshim v1.0); Fri, 7 Jul 2000 17:32:03 -0400 Received: from P2 ("port 1146"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #40360) with ESMTP id <0FXC00E0OJVBCH@a4.jck.com> for drums@cs.utk.edu; Fri, 07 Jul 2000 17:33:12 -0400 (EDT) Date: Fri, 07 Jul 2000 17:18:32 -0400 From: John C Klensin Subject: ASCII Null To: drums@cs.utk.edu Message-id: <917637896.962990312@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit It appears that no one wanted to make a case for retention of the ASCII Null character (position 0/0). So, per previous note, I've taken it out; SMTP now accepts only 127 ASCII characters. Anyone objecting to this decision had best speak up very soon (and be prepared to indicate why you didn't do so sooner :-( ). john From owner-drums@cs.utk.edu Fri Jul 7 20:19:41 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15962 for ; Fri, 7 Jul 2000 20:19:41 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA14900; Fri, 7 Jul 2000 20:19:26 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 7 Jul 2000 20:19:23 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA14876; Fri, 7 Jul 2000 20:19:23 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA14863; Fri, 7 Jul 2000 20:19:21 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> muncher.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Fri, 7 Jul 2000 20:19:22 -0400 Received: (qmail 12694 invoked by uid 1001); 8 Jul 2000 00:22:34 -0000 Date: 8 Jul 2000 00:22:34 -0000 Message-ID: <20000708002234.26317.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: ASCII Null References: <917637896.962990312@P2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: John C Klensin writes: > It appears that no one wanted to make a case for retention of > the ASCII Null character (position 0/0). False. According to John Noerenberg's meeting notes, DRUMS decided at the 39th IETF meeting that it was a ``Bad Idea'' for 821bis to prohibit NUL, even if 822bis prohibited NUL. > Anyone objecting to this decision had best speak up very soon > (and be prepared to indicate why you didn't do so sooner :-( ). We _did_ object sooner. In fact, the people who disagree with you are in the majority. You are acting against the established consensus of the working group. Your editorial procedures are inherently biased. When you want to make changes, you make them. When we want to stop you, we have to object again and again and again. Sometimes---as in the case of VRFY---that still isn't enough. ---Dan From owner-drums@cs.utk.edu Fri Jul 7 21:13:57 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16395 for ; Fri, 7 Jul 2000 21:13:57 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA17295; Fri, 7 Jul 2000 21:13:44 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 7 Jul 2000 21:13:43 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA17278; Fri, 7 Jul 2000 21:13:43 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA17262; Fri, 7 Jul 2000 21:13:41 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Fri, 7 Jul 2000 21:13:41 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id VAA23497; Fri, 7 Jul 2000 21:13:37 -0400 (EDT) Message-Id: <200007080113.VAA23497@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: John C Klensin cc: drums@cs.utk.edu Subject: Re: The "Postmaster" text In-reply-to: Your message of "Fri, 07 Jul 2000 17:09:27 EDT." <917093036.962989767@P2> Date: Fri, 07 Jul 2000 21:13:37 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: looks good to me. -Keith From owner-drums@cs.utk.edu Fri Jul 7 21:23:21 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16463 for ; Fri, 7 Jul 2000 21:23:21 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA17992; Fri, 7 Jul 2000 21:23:08 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 7 Jul 2000 21:23:07 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA17975; Fri, 7 Jul 2000 21:23:07 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA17959; Fri, 7 Jul 2000 21:23:06 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Fri, 7 Jul 2000 21:23:06 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id VAA23693; Fri, 7 Jul 2000 21:23:03 -0400 (EDT) Message-Id: <200007080123.VAA23693@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: John C Klensin cc: drums@cs.utk.edu Subject: Re: The 551/251 question In-reply-to: Your message of "Fri, 07 Jul 2000 17:14:00 EDT." <917366236.962990040@P2> Date: Fri, 07 Jul 2000 21:23:03 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: I don't think the deprecation of 551/251 is justified. The fact that the service isn't widely implemented by servers today doesn't mean that it's not a useful feature; rather, it might mean that we don't have a good way to communicate this to user agents that might make use of it. DSNs could easily provide such a mechanism to communicate changes of address to senders. Then you have the problem that DSNs containing such responses could easily be forged. But SMTP also provides a means of verification - just try to send a dummy message to the recipient (directly to the recipient's MX) and you'll get back the same 551 code in response to RCPT. This seems so simple to do and so potentially useful that I really hate to see 551 deprecated - it makes it that much harder to finish the job. Keith From owner-drums@cs.utk.edu Fri Jul 7 23:41:31 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19697 for ; Fri, 7 Jul 2000 23:41:31 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id XAA23872; Fri, 7 Jul 2000 23:40:46 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 7 Jul 2000 23:40:44 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id XAA23854; Fri, 7 Jul 2000 23:40:44 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id XAA23840; Fri, 7 Jul 2000 23:40:42 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Fri, 7 Jul 2000 23:40:43 -0400 Received: from kobe-ppp-210-172-164-71.interq.or.jp (kobe-ppp-210-172-164-71.interq.or.jp [210.172.164.71]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id UAA18324 for ; Fri, 7 Jul 2000 20:40:39 -0700 X-Authentication-Warning: joy.songbird.com: kobe-ppp-210-172-164-71.interq.or.jp [210.172.164.71] didn't use HELO protocol Message-Id: <4.3.2.20000707184050.00b85de0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sat, 08 Jul 2000 03:19:59 +0100 To: drums@cs.utk.edu From: Dave Crocker Subject: ABNF sets and sequences Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: Folks, Some issues just won't go away. The fact that some parameter lists are ordered and others are not is problematic for ABNF-based specifications. We end up relying on obscure text in the prose and/or on community memory. We hassled this within Drums quite a bit but I want to raise it again. Simply put, the goal is to permit "concatenation" -- ie, lists -- to be labeled as unordered sets or ordered sequences. The default would be ordered, as it is now. The modification to ABNF would be from: group = "(" *c-wsp alternation *c-wsp ")" option = "[" *c-wsp alternation *c-wsp "]" to: group = order "(" *c-wsp alternation *c-wsp ")" option = order "[" *c-wsp alternation *c-wsp "]" order = "SET" / "SEQ" ; unordered vs. ordered, default SEQ It would be interpreted somewhat like construct, in that it only affects the specification rule it is defined in. OK? Start shooting... d/ group = "(" *c-wsp alternation *c-wsp ")" option = "[" *c-wsp alternation *c-wsp "]" =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Sat Jul 8 00:17:20 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19973 for ; Sat, 8 Jul 2000 00:17:20 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA25792; Sat, 8 Jul 2000 00:17:05 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 8 Jul 2000 00:17:05 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA25775; Sat, 8 Jul 2000 00:17:04 -0400 (EDT) Received: from munnari.OZ.AU (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA25562; Sat, 8 Jul 2000 00:13:13 -0400 (EDT) Received: from munnari.OZ.AU (128.250.1.21 -> munnari.OZ.AU) by cs.utk.edu (smtpshim v1.0); Sat, 8 Jul 2000 00:13:15 -0400 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id EA03853; Sat, 8 Jul 2000 14:13:05 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Dave Crocker Cc: drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-Reply-To: Your message of "Sat, 08 Jul 2000 03:19:59 +0100." <4.3.2.20000707184050.00b85de0@mail.bayarea.net> Date: Sat, 08 Jul 2000 14:13:04 +1000 Message-Id: <23425.963029584@mundamutti.cs.mu.OZ.AU> List-Unsubscribe: Date: Sat, 08 Jul 2000 03:19:59 +0100 From: Dave Crocker Message-ID: <4.3.2.20000707184050.00b85de0@mail.bayarea.net> Just on the trivial parts of this for now, I need to go back and re-remember what difficulties with this were last time (as I reall there were some specification problems that got real hard). But... | order = "SET" / "SEQ" | ; unordered vs. ordered, default SEQ The "default SEQ" there makes no sense unless you change it to order = "SET" / "SEQ" / ; | group = order "(" *c-wsp alternation *c-wsp ")" | option = order "[" *c-wsp alternation *c-wsp "]" These mean stuff = SET( a / b / c ) is legal, but stuff = SET ( a / b / c ) is not? Was that the intent, or should there be *c-wsp added somewhere? | It would be interpreted somewhat like construct, in that it only | affects the specification rule it is defined in. That I think was one of the problems with the earlier attempt, I'm not sure it was the only one, was it? With this, there is still no way to (using the stuff above) to say that any of a b c b c a c a b are legal, but a b is not (ie: to require all the elements at least once) and a a b c is not (ie: no repeated elements), etc. If all that is to continue to require text, then I'm not sure that adding this adds enough to be worth the bother. And OK, now I remember the real problem with this. That was, if we augment stuff with a = SET( x / y ) then we now allow x y b c y x b c b x y c (etc, but not) x b y c which is, in practical applications, what is needed. That is, for rfc822bis you want to have a selection of header types, each of which contains a selection of headers, but without imposing any constraints upon the ordering at all. The header-types are needed as sometimes constraints need to be applied to those, and in any case it is just convenient to be able to refer to them as a group. Solving that one was what was so hard it made the whole idea not worth the effort - it was certainly never the syntax by which the notions were written, which is all that seems to have changed here. kre From owner-drums@cs.utk.edu Sat Jul 8 00:35:08 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20331 for ; Sat, 8 Jul 2000 00:35:07 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA27172; Sat, 8 Jul 2000 00:34:53 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 8 Jul 2000 00:34:53 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA27155; Sat, 8 Jul 2000 00:34:53 -0400 (EDT) Received: from munnari.OZ.AU (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA26965; Sat, 8 Jul 2000 00:31:01 -0400 (EDT) Received: from munnari.OZ.AU (128.250.1.21 -> munnari.OZ.AU) by cs.utk.edu (smtpshim v1.0); Sat, 8 Jul 2000 00:31:02 -0400 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id EA04000; Sat, 8 Jul 2000 14:30:48 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: John C Klensin Cc: drums@cs.utk.edu Subject: Re: The 551/251 question In-Reply-To: Your message of "Fri, 07 Jul 2000 17:14:00 -0400." <917366236.962990040@P2> Date: Sat, 08 Jul 2000 14:30:48 +1000 Message-Id: <23518.963030648@mundamutti.cs.mu.OZ.AU> List-Unsubscribe: Date: Fri, 07 Jul 2000 17:14:00 -0400 From: John C Klensin Message-ID: <917366236.962990040@P2> | The consensus seems to be to deprecate both of these. Really? | Similar considerations apply to 551. While an SMTP | client that handles it only as a permanent failure | message will presumably do the correct thing and route "Presumably"? Are there any known instances at all of a SMTP client not treating 551 as a bounce? | the message back to the user as undeliverable, the use | of the code implies belief on the server's part that | automatic address book updating will occur. Says who? It allows it to occur, it no-where assumes that it will occur. | Consequently, servers SHOULD NOT attempt to | provide address-updating information via a 551 code. Even allowing all the assumptions, I don't see how that follows. There's no indication of any reason at all for a server to not send that reply code, the best you have done is provided a justification for a server not sending it (ie: I don't need to bother with this, it isn't really useful), not against it being sent (ie: I could easily send a 551, but it might harm someone, so I won't). To me that is exactly a "MAY send" state. 551 is used today - and even understood by clients, not to do address book updating, but just to give a more comprehensible error message to the user. Rather than "user unknown" or "mailbox does not exist" or something like that, "551" allows clients to say "The user's e-mail address has changed, the new address might be <...>", which is much nicer. Please just leave 551. Even 251 is harmless. If we can't justify these, then we should probably just drop the 2nd and 3rd digits completely (still require them for compatability but define them as 100% meaningless). That is, mandate that clients must not use anything but the first digit of the reply code. I don't think that would be the right solution - being able to gain some extra insight into the cause of a problem is useful. kre From owner-drums@cs.utk.edu Sat Jul 8 05:05:39 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04286 for ; Sat, 8 Jul 2000 05:05:38 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA06822; Sat, 8 Jul 2000 05:05:25 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 8 Jul 2000 05:05:23 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id FAA06805; Sat, 8 Jul 2000 05:05:22 -0400 (EDT) Received: from ss3000e.cselt.it (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id FAA06785; Sat, 8 Jul 2000 05:05:16 -0400 (EDT) Received: from ss3000e.cselt.it (163.162.41.5 -> ss3000e.cselt.it) by cs.utk.edu (smtpshim v1.0); Sat, 8 Jul 2000 05:05:17 -0400 Received: from beatles.cselt.it (beatles.cselt.it [163.162.29.125]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0FXD00K2HFN24R@ss3000e.cselt.it> for drums@cs.utk.edu; Sat, 8 Jul 2000 10:59:26 +0200 (MET DST) Received: from beatles.cselt.it (beatles.cselt.it [163.162.29.125]) by beatles.cselt.it (8.9.3/8.9.3) with SMTP id LAA09268 for ; Sat, 08 Jul 2000 11:04:39 +0200 (MET DST) Date: Sat, 08 Jul 2000 11:04:39 +0200 (MET DST) From: Maurizio Codogno Subject: Re: The "Postmaster" text To: drums@cs.utk.edu Reply-to: Maurizio Codogno Message-id: <200007080904.LAA09268@beatles.cselt.it> MIME-version: 1.0 X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-MD5: o0fh3k4An1RO5iLOjYLPsg== List-Unsubscribe: > SMTP systems are expected to make every reasonable > effort to accept mail directed to Postmaster from any > other system on the Internet. In extreme cases --such > as to contain a denial of service attack or other breach > of security-- an SMTP server may block mail directed to ^^^ lowercase? > Postmaster. However, such arrangements SHOULD be > narrowly tailored so as to avoid blocking messages which > are not part of such attacks. for me it's fine, even if I understand that this could lend to people claming that they are just blocking DoS attacks :-( For the other points, no problem for me (even if DJB disagrees on NULs and Keith on x51) ciao, .mau. From owner-drums@cs.utk.edu Sat Jul 8 09:02:13 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05584 for ; Sat, 8 Jul 2000 09:02:12 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA16324; Sat, 8 Jul 2000 09:01:58 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 8 Jul 2000 09:01:56 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA16307; Sat, 8 Jul 2000 09:01:56 -0400 (EDT) Received: from gemma.TechFak.Uni-Bielefeld.DE (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA16294; Sat, 8 Jul 2000 09:01:53 -0400 (EDT) Received: from gemma.TechFak.Uni-Bielefeld.DE (129.70.136.103 -> gemma.TechFak.Uni-Bielefeld.DE) by cs.utk.edu (smtpshim v1.0); Sat, 8 Jul 2000 09:01:53 -0400 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.136.13]) by gemma.TechFak.Uni-Bielefeld.DE (8.9.1/8.9.1/TechFak/pk+ro20000427) with SMTP id PAA09369; Sat, 8 Jul 2000 15:01:50 +0200 (MET DST) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id PAA16681; Sat, 8 Jul 2000 15:01:50 +0200 Message-Id: <200007081301.PAA16681@grimsvotn.TechFak.Uni-Bielefeld.DE> To: John C Klensin Cc: drums@cs.utk.edu Subject: Re: The "Postmaster" text In-reply-to: Your message of "Fri, 07 Jul 2000 17:09:27 EDT." <917093036.962989767@P2> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Sat, 08 Jul 2000 15:01:50 +0200 From: Peter Koch List-Unsubscribe: > other system on the Internet. In extreme cases --such > as to contain a denial of service attack or other breach > of security-- an SMTP server may block mail directed to > Postmaster. However, such arrangements SHOULD be > narrowly tailored so as to avoid blocking messages which > are not part of such attacks. The term ``to block mail'' is not defined in the document. It could mean to silently discard the message or to refuse delivery with an error indication. In 2.4 the term ``bounce'' is defined ``en passant'', so how about substituting this word for ``blocking'' here? -Peter From owner-drums@cs.utk.edu Sat Jul 8 09:02:37 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05595 for ; Sat, 8 Jul 2000 09:02:37 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA16397; Sat, 8 Jul 2000 09:02:25 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 8 Jul 2000 09:02:25 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA16380; Sat, 8 Jul 2000 09:02:25 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA16364; Sat, 8 Jul 2000 09:02:23 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Sat, 8 Jul 2000 09:02:23 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA27719; Sat, 8 Jul 2000 09:02:21 -0400 (EDT) Message-Id: <200007081302.JAA27719@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-reply-to: Your message of "Sat, 08 Jul 2000 03:19:59 BST." <4.3.2.20000707184050.00b85de0@mail.bayarea.net> Date: Sat, 08 Jul 2000 09:02:21 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > OK? uh, no. a) it's too late in the DRUMS process to consider changing the ABNF, at least for this version of DRUMS. if this is really important then it might be good to revise the ABNF document, but this should not delay the other work that DRUMS is doing. my guess is that the ADs want to close DRUMS down ASAP, so any changes to ABNF would be a post-DRUMS activity. b) there's more than one kind of ordering. I'm not sure which you're talking about: - things are required to appear in some order if they do appear this can already be represented in ABNF, e.g.: [ thing1 ] [ thing2 ] [ thing3 ] - things can appear in any order but the order of things is significant. this is not a matter of syntax, but of interpretation of the syntax - so it doesn't belong in ABNF. Keith From owner-drums@cs.utk.edu Sat Jul 8 11:48:55 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06747 for ; Sat, 8 Jul 2000 11:48:55 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA25660; Sat, 8 Jul 2000 11:48:36 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 8 Jul 2000 11:48:31 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA25643; Sat, 8 Jul 2000 11:48:31 -0400 (EDT) Received: from A4.JCK.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA25630; Sat, 8 Jul 2000 11:48:27 -0400 (EDT) Received: from A4.JCK.COM (209.187.148.211 -> ns.jck.com) by cs.utk.edu (smtpshim v1.0); Sat, 8 Jul 2000 11:48:28 -0400 Received: from P2 ("port 1178"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #40360) with ESMTP id <0FXD00E1YYMUQY@a4.jck.com> for drums@cs.utk.edu; Sat, 08 Jul 2000 11:49:42 -0400 (EDT) Date: Sat, 08 Jul 2000 11:48:24 -0400 From: John C Klensin Subject: Re: The "Postmaster" text In-reply-to: <200007081301.PAA16681@grimsvotn.TechFak.Uni-Bielefeld.DE> To: Peter Koch Cc: drums@cs.utk.edu Message-id: <984230446.963056904@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit Peter, Based on earlier discussions in the WG about some related issues, my intent was precisely to leave "bounce or discard" vague. There is already a prohibition on discarding mail (in the "take responsibility once one sends the 250 in response to DATA ... CRLF.CRLF" section. But most of us know situations in which that prohibition needs to be ignored, e.g., when one is under a sufficiently aggressive spammer attack against non-existent addresses that bouncing each message individually only increases system loads and provides potentially-enabling information to an attacker. The situation with Postmaster is, arguably, even worse: we want Postmaster-addressed messages to be delivered in the overwhelming number of cases; in those that justify not delivering them, providing information about non-delivery may be unattractive. Moreover, in addition to the "bounce" and "discard" cases, "block" could include "divert, log, and file for possible subsequent review". We could, of course, define "block" and include some of the above discussion, but that would appear to run counter to the WG's sense that we should not get any further into mechanisms in that area than needed. What would you, and others, suggest? john ------------- --On Saturday, 08 July, 2000 15:01 +0200 Peter Koch wrote: > >> other system on the Internet. In extreme cases --such >> as to contain a denial of service attack or other breach >> of security-- an SMTP server may block mail directed to >> Postmaster. However, such arrangements SHOULD be >> narrowly tailored so as to avoid blocking messages which >> are not part of such attacks. > > The term ``to block mail'' is not defined in the document. It > could mean to silently discard the message or to refuse > delivery with an error indication. In 2.4 the term ``bounce'' > is defined ``en passant'', so how about substituting this word > for ``blocking'' here? > > -Peter From owner-drums@cs.utk.edu Sat Jul 8 12:37:23 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07206 for ; Sat, 8 Jul 2000 12:37:23 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA28808; Sat, 8 Jul 2000 12:37:09 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 8 Jul 2000 12:37:05 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA28791; Sat, 8 Jul 2000 12:37:05 -0400 (EDT) Received: from episteme-software.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA28774; Sat, 8 Jul 2000 12:37:02 -0400 (EDT) Received: from episteme-software.com (216.43.25.66 -> mtdsl-25.mcleodusa.net) by cs.utk.edu (smtpshim v1.0); Sat, 8 Jul 2000 12:37:03 -0400 Received: from mtdsl-25.mcleodusa.net (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.1b2); Sat, 8 Jul 2000 11:36:02 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <200007081302.JAA27719@astro.cs.utk.edu> References: <200007081302.JAA27719@astro.cs.utk.edu> X-Mailer: Eudora [Macintosh version 4.3.1b20-05.00] Date: Sat, 8 Jul 2000 11:36:00 -0500 To: Keith Moore From: Pete Resnick Subject: Re: ABNF sets and sequences Cc: Dave Crocker , drums@cs.utk.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: On 7/8/00 at 9:02 AM -0400, Keith Moore wrote: >a) it's too late in the DRUMS process to consider changing the ABNF This I agree with, but there's no harm discussing it on this list. >b) there's more than one kind of ordering. I'm not sure which >you're talking about: > >- things are required to appear in some order if they do appear >[...] >- things can appear in any order but the order of things is significant. It's neither of those. It's: - things can appear in any order and the order of things is not significant. However, addressing the issues in Robert's message is really the big problem. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 From owner-drums@cs.utk.edu Sat Jul 8 13:02:48 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07385 for ; Sat, 8 Jul 2000 13:02:48 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA01135; Sat, 8 Jul 2000 13:02:33 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 8 Jul 2000 13:02:31 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA01118; Sat, 8 Jul 2000 13:02:31 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA01098; Sat, 8 Jul 2000 13:02:29 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Sat, 8 Jul 2000 13:02:29 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA02698; Sat, 8 Jul 2000 13:02:27 -0400 (EDT) Message-Id: <200007081702.NAA02698@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pete Resnick cc: Keith Moore , Dave Crocker , drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-reply-to: Your message of "Sat, 08 Jul 2000 11:36:00 CDT." Date: Sat, 08 Jul 2000 13:02:27 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > - things can appear in any order and the order of things is not significant. but no more than one of those things can appear at any time? otherwise you just say *( thing1 / thing2 / thing3 ) why would this be needed? From owner-drums@cs.utk.edu Sat Jul 8 13:19:03 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07507 for ; Sat, 8 Jul 2000 13:19:02 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA03961; Sat, 8 Jul 2000 13:18:48 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 8 Jul 2000 13:18:47 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA03944; Sat, 8 Jul 2000 13:18:47 -0400 (EDT) Received: from episteme-software.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA03927; Sat, 8 Jul 2000 13:18:44 -0400 (EDT) Received: from episteme-software.com (63.250.90.98 -> resnick1.qualcomm.com) by cs.utk.edu (smtpshim v1.0); Sat, 8 Jul 2000 13:18:45 -0400 Received: from mtdsl-25.mcleodusa.net (63.250.90.99) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.0.1b2); Sat, 8 Jul 2000 12:18:38 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com (Unverified) Message-Id: In-Reply-To: <200007081702.NAA02698@astro.cs.utk.edu> References: <200007081702.NAA02698@astro.cs.utk.edu> X-Mailer: Eudora [Macintosh version 4.3.1b20-05.00] Date: Sat, 8 Jul 2000 12:18:36 -0500 To: Keith Moore From: Pete Resnick Subject: Re: ABNF sets and sequences Cc: Keith Moore , Dave Crocker , drums@cs.utk.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: On 7/8/00 at 1:02 PM -0400, Keith Moore wrote: > > - things can appear in any order and the order of things is not >significant. > >but no more than one of those things can appear at any time? Right. >why would this be needed? From: presnick@qualcomm.com To: moore@cs.utk.edu or even the items in: Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA02698; Sat, 8 Jul 2000 13:02:27 -0400 (EDT) We don't care if "by" comes before or after "with", but we do care how many of them there are. pr -- Pete Resnick Eudora Engineering - QUALCOMM Incorporated Ph: (217)337-6377 or (858)651-4478, Fax: (858)651-1102 From owner-drums@cs.utk.edu Sat Jul 8 13:21:43 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07535 for ; Sat, 8 Jul 2000 13:21:42 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA04174; Sat, 8 Jul 2000 13:21:31 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 8 Jul 2000 13:21:30 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA04157; Sat, 8 Jul 2000 13:21:30 -0400 (EDT) Received: from A4.JCK.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA04144; Sat, 8 Jul 2000 13:21:26 -0400 (EDT) Received: from A4.JCK.COM (209.187.148.211 -> ns.jck.com) by cs.utk.edu (smtpshim v1.0); Sat, 8 Jul 2000 13:21:27 -0400 Received: from P2 ("port 1183"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #40360) with ESMTP id <0FXE00E3J2XRQY@a4.jck.com> for drums@cs.utk.edu; Sat, 08 Jul 2000 13:22:41 -0400 (EDT) Date: Sat, 08 Jul 2000 13:21:22 -0400 From: John C Klensin Subject: Re: The 551/251 question In-reply-to: <23518.963030648@mundamutti.cs.mu.OZ.AU> To: Robert Elz Cc: drums@cs.utk.edu Message-id: <989808016.963062482@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: multipart/mixed; boundary="==========989813775==========" List-Unsubscribe: --==========989813775========== Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit --On Saturday, 08 July, 2000 14:30 +1000 Robert Elz wrote: > Date: Fri, 07 Jul 2000 17:14:00 -0400 > From: John C Klensin > Message-ID: <917366236.962990040@P2> > > | The consensus seems to be to deprecate both of these. > > Really? >... Ok. I'm not sure I believe that either, and can argue this either way (although probably not as persuasively as you have). Where there does seem to be clear agreement is that automated client-side address book updating is rarely implemented, especially in a consistent fashion, these days. It seems to me (I may be wrong) that the strongest objection to leaving these codes in the spec are associated with the server making the assumption that updating service will occur when the codes are returned. If so, an alternate possibility is to leave the codes in the spec, make it clear that returning them is optional, caution about inadvertent information disclosure, and make it clear that address book updating can't be counted on. I am attaching a draft replacement for section 3.4, a modification for the Security Considerations section, and updating notes for a few other pieces. If the WG (and the Chair and ADs) like this better and all can live with it, I'll substitute it before sending the draft off to the I-D process tomorrow evening. john --==========989813775========== Content-Type: text/plain; charset=iso-8859-1; name="smtpupd12bx.txt" Content-Disposition: attachment; filename="smtpupd12bx.txt"; size=2674 Content-Transfer-Encoding: quoted-printable 251/551 alternate model... ----- 3.4 Forwarding for Address Correction or Updating Forwarding support is most often required to consolidate and = simplify addresses within, or relative to, some enterprise and less = frequently to establish addresses to link a person's prior address with = current one. Silent forwarding of messages (without server notification to = the sender), for security or non-disclosure purposes, is common in the = contemporary Internet. In both the enterprise and the "new address" cases, information = hiding (and sometimes security) considerations argue against exposure of the = "final" address through the SMTP protocol as a side-effect of the = forwarding activity. This may be especially important when the final = address may not even be reachable by the sender. Consequently, the "forwarding" = mechanisms described in section 3.2 of RFC 821, and especially the 251 = (corrected destination) and 551 reply codes from RCPT must be evaluated = carefully by implementers and, when they are available, by those configuring = systems. In particular: * Servers MAY forward messages when they are aware of an address = change. When they do so, they MAY either provide address-updating = information with a 251 code, or may forward "silently" and return a 250 = code. But, if a 251 code is used, they MUST NOT assume that the client = will actually update address information or even return that information to = the user. Alternately, * Servers MAY reject or bounce messages when they are not = deliverable when addressed. When they do so, they MAY either provide = address-updating information with a 551 code, or may reject the message as = undeliverable with a 550 code and no address-specific information. But, if = a 251 code is used, they MUST NOT assume that the client will actually = update address information or even return that information to the = user. SMTP server implementations that support the 251 and/or 551 = reply codes are strongly encouraged to provide configuration mechanisms so that = sites which conclude that they would undesirably disclose information can = disable or restrict their use. ---- Add new section 7.6 and renumber existing one to 7.7: 7.6 Information Disclosure in Message Forwarding As discussed in section 3.4, use of the 251 or 551 reply codes = to identify the replacement address associated with a mailbox may = inadvertently disclose sensitive information. Sites that are concerned about = those issues should ensure that they select and configure servers = appropriately. ---- Remove "deprecated" reference to 251 and 551 in section 4.2. Remove new section F.7. --==========989813775==========-- From owner-drums@cs.utk.edu Sat Jul 8 13:42:51 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07755 for ; Sat, 8 Jul 2000 13:42:50 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA06002; Sat, 8 Jul 2000 13:42:37 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 8 Jul 2000 13:42:36 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA05985; Sat, 8 Jul 2000 13:42:36 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA05965; Sat, 8 Jul 2000 13:42:34 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Sat, 8 Jul 2000 13:42:34 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA03527; Sat, 8 Jul 2000 13:42:32 -0400 (EDT) Message-Id: <200007081742.NAA03527@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pete Resnick cc: Keith Moore , Dave Crocker , drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-reply-to: Your message of "Sat, 08 Jul 2000 12:18:36 CDT." Date: Sat, 08 Jul 2000 13:42:32 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: I don't think it's reasonable to try to represent the rules for header fields fully in ABNF. reasons: 1. there are a lot more cases than "no more than once" - there are fields that must occur once, other fields that may occur at most once, and still other fields that may occur any number of times. so the syntax to represent this gets a lot more moby. 2. unlike the rest of ABNF, such a syntax would not easily be translated into something that a parser generator could understand. in other words, changing ABNF in this way impairs its ability to be read by machines. 3. notation that isn't used very often actually hinders readability to humans also - it is like using too many levels of function/subroutine/method/abstraction when writing code. 4. if you're writing a parser for mail and you encounter multiple use of the same "at most once" header field (or whatever), chances are that you *don't* want the parser to handle this error by itself - you want to look at the field that is duplicated and see whether it makes more sense to flag the error, ignore it, whatever. e.g. for some reason a lot of mail that I receive has multiple content-transfer-encoding fields, but it's not a problem as long as the fields have the same value. this isn't the sort of thing you can encode into syntax. so to me it makes more sense to specify these rules outside of the ABNF ideally, the implementor can translate the ABNF into the parser and the prose rules into additional error checking code. if the implementor has to rewrite the ABNF significantly in order to build a parser from it, and has to extract out error checking rules in the process, this is a pessimal result. Keith From owner-drums@cs.utk.edu Sat Jul 8 22:38:10 2000 Received: from cs.utk.edu ([128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12776 for ; Sat, 8 Jul 2000 22:38:10 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA10016; Sat, 8 Jul 2000 22:37:48 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 8 Jul 2000 22:37:35 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA09998; Sat, 8 Jul 2000 22:37:35 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA09980; Sat, 8 Jul 2000 22:37:33 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Sat, 8 Jul 2000 22:37:33 -0400 Received: from kobe-ppp-210-172-176-70.interq.or.jp (kobe-ppp-210-172-176-70.interq.or.jp [210.172.176.70]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id TAA26824 for ; Sat, 8 Jul 2000 19:37:29 -0700 X-Authentication-Warning: joy.songbird.com: kobe-ppp-210-172-176-70.interq.or.jp [210.172.176.70] didn't use HELO protocol Message-Id: <4.3.2.20000708224002.00c14e30@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sat, 08 Jul 2000 22:55:47 +0900 To: drums@cs.utk.edu From: Dave Crocker Subject: Re: ABNF sets and sequences In-Reply-To: <23425.963029584@mundamutti.cs.mu.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 02:13 PM 7/8/00 +1000, Robert Elz wrote: >These mean > stuff = SET( a / b / c ) >is legal, but > > stuff = SET ( a / b / c ) >is not? > >Was that the intent, or should there be *c-wsp added somewhere? probably both sides of , never meant to prohibit typical use of white space. I'll be ecstatic if that is the level of problem the proposal has... > | It would be interpreted somewhat like construct, in that it > only > | affects the specification rule it is defined in. > >That I think was one of the problems with the earlier attempt, I'm >not sure it was the only one, was it? I think we all got seduced into looking at a horribly complicated effect of apply the (non)ordering to subordinate rules. The interpretation needs to be exactly the way we apply the repetition construct. >With this, there is still no way to (using the stuff above) to say >that any of > > a b c > b c a > c a b > >are legal, but perhaps. I am frankly worried only about having labeled parameter lists (e.g., a=b, or c:d) specified in ABNF in a way that makes explicit IN THE SYNTAX that the paramaters may occur in any order > a b > >is not (ie: to require all the elements at least once) and Hmm. What is wrong with: rule = SET ( a b c ) >If all that is to continue to require text, then I'm not sure >that adding this adds enough to be worth the bother. Just fixing the problem for labeled parameter lists (like RFC822-derived header lists...) would be enough for me. Nothing wrong with also handling the extra scenarios you suggest. >And OK, now I remember the real problem with this. That was, if >we augment stuff with > > a = SET( x / y ) (x / y) means x or y (but not both.) That is a single-element result. Set constructs are not meaningful for it. Need to produce at least two elements. At 09:02 AM 7/8/00 -0400, Keith Moore wrote: >a) it's too late in the DRUMS process to consider changing the ABNF, Procedurally, I'd suggest issuing the enhancement as a new Proposed Draft and then merging it when the whole thing can go to Draft. Alternately, ABNF has been at Proposed long enough to make it minimal impact to recycle the whole thing, with the revision. >at least for this version of DRUMS. if this is really important then >it might be good to revise the ABNF document, but this should not delay >the other work that DRUMS is doing. my guess is that the ADs want to Ahh. Status dependency. Sigh, yes. In that case, advancing the current spec to Draft and issuing the enhancement separately, merging it as possible. >b) there's more than one kind of ordering. I'm not sure which >you're talking about: > >- things are required to appear in some order if they do appear > this can already be represented in ABNF, e.g.: > > [ thing1 ] [ thing2 ] [ thing3 ] > >- things can appear in any order but the order of things is significant. I don't know exactly what that means, but it is not what I was thinking or suggest. SEQ is what we have now. SET just takes away the ordering requirement of the CURRENT, implied seq. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Sat Jul 8 23:51:43 2000 Received: from cs.utk.edu ([128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13549 for ; Sat, 8 Jul 2000 23:51:43 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id XAA14390; Sat, 8 Jul 2000 23:51:29 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 8 Jul 2000 23:51:28 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id XAA14370; Sat, 8 Jul 2000 23:51:27 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id XAA14349; Sat, 8 Jul 2000 23:51:23 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Sat, 8 Jul 2000 23:51:23 -0400 Received: from kobe-ppp-210-172-176-97.interq.or.jp (kobe-ppp-210-172-176-97.interq.or.jp [210.172.176.97]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id UAA27375; Sat, 8 Jul 2000 20:51:16 -0700 X-Authentication-Warning: joy.songbird.com: kobe-ppp-210-172-176-97.interq.or.jp [210.172.176.97] didn't use HELO protocol Message-Id: <4.3.2.20000709114939.00b462f0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sun, 09 Jul 2000 11:58:24 +0900 To: Keith Moore From: Dave Crocker Subject: Re: ABNF sets and sequences Cc: Pete Resnick , Keith Moore , drums@cs.utk.edu In-Reply-To: <200007081742.NAA03527@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 01:42 PM 7/8/00 -0400, Keith Moore wrote: >1. there are a lot more cases than "no more than once" - there handling every possible case is rarely a goal. handling the important and popular cases is. that's what the proposal attempts. >2. unlike the rest of ABNF, such a syntax would not easily be >translated into something that a parser generator could ASN.1 parsers handle it just fine. >3. notation that isn't used very often actually hinders readability The motivation for this is that it IS needed with regularity, namely for every list of labeled parameters. Such lists are ALWAYS unordered. That's the reason for the labels. >4. if you're writing a parser for mail and you encounter multiple >use of the same "at most once" header field (or whatever), >chances are that you *don't* want the parser to handle this >error by itself - you want to look at the field that is duplicated >and see whether it makes more sense to flag the error, ignore it, Email has a history of very poor conformance. The more that things are caught up-front, the better. d/ ps. For everyone: The goal of my original posting was to re-raise an issue and explore pursuing it. The note was not attempting to provide a complete proposal, but rather an exemplar of the type of solution that seemed close to the right answer. Frankly I do not care how the details are achieved, including use of an entirely different approach. Solving the requirement -- for being able to specify unordered lists -- is the concern. =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Sun Jul 9 00:57:18 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14266 for ; Sun, 9 Jul 2000 00:57:18 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA17581; Sun, 9 Jul 2000 00:57:03 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 9 Jul 2000 00:57:00 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA17564; Sun, 9 Jul 2000 00:57:00 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA17539; Sun, 9 Jul 2000 00:56:58 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Sun, 9 Jul 2000 00:56:58 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id AAA16683; Sun, 9 Jul 2000 00:56:56 -0400 (EDT) Message-Id: <200007090456.AAA16683@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Keith Moore , Pete Resnick , drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-reply-to: Your message of "Sun, 09 Jul 2000 11:58:24 +0900." <4.3.2.20000709114939.00b462f0@mail.bayarea.net> Date: Sun, 09 Jul 2000 00:56:56 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > >1. there are a lot more cases than "no more than once" - there > > handling every possible case is rarely a goal. handling the important and > popular cases is. that's what the proposal attempts. okay, maybe I should reword my statement more specifically. having this notation will not significantly simplify or clarify the specification for Internet mail. now it may be that there is some other justification for this notation. I just don't know what it is.. > >2. unlike the rest of ABNF, such a syntax would not easily be > >translated into something that a parser generator could > > ASN.1 parsers handle it just fine. I fail to see how this is relevant. ASN.1 is a language for describing the structure of data (BER maps that structure onto a presentation), but ASN.1 is not a language for writing a parser for some already-defined presentation of data. You can write an RFC 822 parser in yacc, but you can't write one in ASN.1 and even though ASN.1 has a construct similar to what you are describing, this is hardly an argument for providing it. ASN.1 is not widely regarded as a particularly good notation for describing protocols. one of ASN.1's many mistakes is trying to do too much verification at the presentation layer. another is having too rich a notation- too many constructs of dubious utility. > >3. notation that isn't used very often actually hinders readability > > The motivation for this is that it IS needed with regularity, namely for > every list of labeled parameters. Such lists are ALWAYS unordered. That's > the reason for the labels. in many of these cases (e.g. any time the list of labels is extensible) it's a bad idea to specify the parameter labels as literals anyway. in other words, it's bad style to write list = *( "thing1" / "thing2" / "thing3" / extension-thing ) when you could instead write list = *elem elem = token ; the same token MUST NOT be generated twice in a list ; initially defined elems are "thing1", "thing2", and "thing3". because if you write the former then the programer has to recode the grammar into the latter format anyway. you've just made his job harder. and you really do want to separate parsing of the list elements from semantic processing of the list elements, and handling of duplicate elements (even if this is a protocol violation) tends to involve semantic interpretation. and even if you had the list-of-items-no-more-than-once notation, it doesn't extend well to handle new items. consider the case above - if a list is allowed to include 'extension-thing' in addition to "thing1" "thing2" and "thing3" then it can contain at most one 'extension-thing' rather than an arbitrary number of them. > >4. if you're writing a parser for mail and you encounter multiple > >use of the same "at most once" header field (or whatever), > >chances are that you *don't* want the parser to handle this > >error by itself - you want to look at the field that is duplicated > >and see whether it makes more sense to flag the error, ignore it, > > Email has a history of very poor conformance. The more that things are > caught up-front, the better. if we could catch things before they are sent, I'd agree with you. but I don't know of any incentive that is likely to get mailers to be very conservative about messages that they send (and do rigid syntax checks on them beforehand), while on the other hand there appear to be plenty of incentives for receivers to make sense of whatever garbage they receive. Keith From owner-drums@cs.utk.edu Sun Jul 9 01:04:06 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14367 for ; Sun, 9 Jul 2000 01:04:05 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id BAA19674; Sun, 9 Jul 2000 01:03:51 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 9 Jul 2000 01:03:51 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id BAA19657; Sun, 9 Jul 2000 01:03:50 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id BAA19640; Sun, 9 Jul 2000 01:03:49 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Sun, 9 Jul 2000 01:03:49 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id BAA16811; Sun, 9 Jul 2000 01:01:06 -0400 (EDT) Message-Id: <200007090501.BAA16811@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: John C Klensin cc: Robert Elz , drums@cs.utk.edu Subject: Re: The 551/251 question In-reply-to: Your message of "Sat, 08 Jul 2000 13:21:22 EDT." <989808016.963062482@P2> Date: Sun, 09 Jul 2000 01:01:06 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: the new 552/251 text looks good to me. thanks, Keith From owner-drums@cs.utk.edu Sun Jul 9 21:31:58 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12754 for ; Sun, 9 Jul 2000 21:31:58 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA11578; Sun, 9 Jul 2000 21:31:05 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 9 Jul 2000 21:31:01 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA11547; Sun, 9 Jul 2000 21:31:00 -0400 (EDT) Received: from khms.westfalen.de (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA11519; Sun, 9 Jul 2000 21:30:55 -0400 (EDT) Received: from khms.westfalen.de (62.158.128.83 -> p3E9E8053.dip.t-dialin.net) by cs.utk.edu (smtpshim v1.0); Sun, 9 Jul 2000 21:30:56 -0400 Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.12 #1) id 13BSPD-0004N8-00 (Debian); Mon, 10 Jul 2000 03:30:43 +0200 Received: by khms.westfalen.de (CrossPoint v3.12d.kh5 R/C435); 10 Jul 2000 03:25:48 +0200 Date: 09 Jul 2000 22:21:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: drums@cs.utk.edu Message-ID: <7hYfLiRmw-B@khms.westfalen.de> In-Reply-To: <984230446.963056904@P2> Subject: Re: The "Postmaster" text X-Mailer: CrossPoint v3.12d.kh5 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <200007081301.PAA16681@grimsvotn.TechFak.Uni-Bielefeld.DE> <984230446.963056904@P2> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 List-Unsubscribe: klensin@jck.com (John C Klensin) wrote on 08.07.00 in <984230446.963056904@P2>: > What would you, and others, suggest? Current proposed text looks just fine to me. MfG Kai From owner-drums@cs.utk.edu Sun Jul 9 21:31:59 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12765 for ; Sun, 9 Jul 2000 21:31:59 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA11582; Sun, 9 Jul 2000 21:31:05 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 9 Jul 2000 21:31:01 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA11546; Sun, 9 Jul 2000 21:31:00 -0400 (EDT) Received: from khms.westfalen.de (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA11520; Sun, 9 Jul 2000 21:30:55 -0400 (EDT) Received: from khms.westfalen.de (62.158.128.83 -> p3E9E8053.dip.t-dialin.net) by cs.utk.edu (smtpshim v1.0); Sun, 9 Jul 2000 21:30:56 -0400 Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.12 #1) id 13BSPD-0004N8-01 (Debian); Mon, 10 Jul 2000 03:30:43 +0200 Received: by khms.westfalen.de (CrossPoint v3.12d.kh5 R/C435); 10 Jul 2000 03:25:48 +0200 Date: 09 Jul 2000 22:29:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: drums@cs.utk.edu Message-ID: <7hYfLlGXw-B@khms.westfalen.de> In-Reply-To: <989808016.963062482@P2> Subject: Re: The 551/251 question X-Mailer: CrossPoint v3.12d.kh5 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <23518.963030648@mundamutti.cs.mu.OZ.AU> <989808016.963062482@P2> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 List-Unsubscribe: klensin@jck.com (John C Klensin) wrote on 08.07.00 in <989808016.963062482@P2>: > Alternately, > > * Servers MAY reject or bounce messages when they are not deliverable when > addressed. When they do so, they MAY either provide address-updating > information with a 551 code, or may reject the message as undeliverable > with a 550 code and no address-specific information. But, if a 251 code > is used, they MUST NOT assume that the client will actually update > address information or even return that information to the user. s/251/551/ here. MfG Kai From owner-drums@cs.utk.edu Sun Jul 9 22:46:11 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15075 for ; Sun, 9 Jul 2000 22:46:10 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA15248; Sun, 9 Jul 2000 22:45:51 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 9 Jul 2000 22:45:42 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA15230; Sun, 9 Jul 2000 22:45:41 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA15211; Sun, 9 Jul 2000 22:45:39 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Sun, 9 Jul 2000 22:45:39 -0400 Received: from kobe-ppp-210-172-164-106.interq.or.jp (kobe-ppp-210-172-164-106.interq.or.jp [210.172.164.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id TAA03702; Sun, 9 Jul 2000 19:45:28 -0700 X-Authentication-Warning: joy.songbird.com: kobe-ppp-210-172-164-106.interq.or.jp [210.172.164.106] didn't use HELO protocol Message-Id: <4.3.2.20000709223011.00bfebf0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 10 Jul 2000 11:42:21 +0900 To: Keith Moore From: Dave Crocker Subject: Re: ABNF sets and sequences Cc: drums@cs.utk.edu In-Reply-To: <200007090456.AAA16683@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 12:56 AM 7/9/00 -0400, Keith Moore wrote: >having this notation will not significantly simplify or clarify >the specification for Internet mail. 1. The construct that is at issue cannot reasonably be specified in current ABNF. 2. The construct occurs regularly, such as for 822-like headers, labeled parameters in Received headers, etc. This is not a small or occasional issue. 3. Putting the qualifier in the prose is a good way a) to get missed, or b) not to get specified. Absence of this, for in RFC 1894, is what re-triggered my interest in this topic. One might argue that misunderstanding this relaxation of the apparent syntactic requirement for ordering is "merely" a matter of acculturation -- one must be fully plugged in to the protocol development community. That is a requirement that has scaling problems. While few implementation errors can be documented by this unfair requirement, growth of the Internet should encourage us to make common constructs easier to specify and harder to miss. >Now it may be that there is some other justification for this notation. I >just don't know what it is.. The working group felt it was worth adding earlier. We just couldn't figure out how. I now believe that was because we tied it to alternation (a / b) rather than concatenation (a b) and repetition, where it belongs. In any event, the point you raise reduces to whether the community thinks it is useful to have the construct in ABNF. I do; you don't. Others will decide. > > >2. unlike the rest of ABNF, such a syntax would not easily be > > >translated into something that a parser generator could > > > > ASN.1 parsers handle it just fine. > >I fail to see how this is relevant. See below. >ASN.1 is a language for describing the structure of data as is ABNF. >(BER maps that structure onto a presentation), but ASN.1 >is not a language for writing a parser for some already-defined >presentation of data. You can write an RFC 822 parser in yacc, yacc is the programming language, not ASN.1. >but you can't write one in ASN.1 asymmetric comparison: <822 headers, or whatever> : abnf : yacc should be compared with: <822> : asn.1 : >ASN.1 is not widely regarded as a particularly good notation for >describing protocols. one of ASN.1's many mistakes is trying It is used. It works. Some like it; some don't. That's all fine, but entirely irrelevant. You made a specific claim of non-implementability. I cited an existence proof to contradict your specific claim. I was not making a wholesale statement of support for ASN.1 and a wholesale attack on it is not relevant. Nor are other issues about ASN.1 relevant. > > >3. notation that isn't used very often actually hinders readability > > > > The motivation for this is that it IS needed with regularity, namely for > > every list of labeled parameters. Such lists are ALWAYS > unordered. That's > > the reason for the labels. > >in many of these cases (e.g. any time the list of labels is extensible) >it's a bad idea to specify the parameter labels as literals anyway. > >in other words, it's bad style to write > > list = *( "thing1" / "thing2" / "thing3" / extension-thing ) You keep using the alternation construct. Let's get specific about how the construct probably should be used: RFC 1894: >2.2 Per-Message DSN Fields > > Some fields of a DSN apply to all of the delivery attempts described > by that DSN. These fields may appear at most once in any DSN. These > fields are used to correlate the DSN with the original message > transaction and to provide additional information which may be useful > to gateways. > > per-message-fields = SET ( > [ original-envelope-id-field CRLF ] > reporting-mta-field CRLF > [ dsn-gateway-field CRLF ] > [ received-from-mta-field CRLF ] > [ arrival-date-field CRLF ] > *( extension-field CRLF ) ) and in draft-ietf-drums-msg-fmt-07.txt: >name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)] becomes >name-val-list = [CFWS] SET [name-val-pair *(CFWS name-val-pair)] and >fields = *(trace > *(resent-date / > resent-from / > resent-sender / > resent-to / > resent-cc / > resent-bcc / > resent-id)) > *(orig-date / > from / > sender / > reply-to / > to / > cc / > bcc / > message-id / > in-reply-to / > references / > subject / > comments / > keywords / > optional-field) becomes something like: >fields = SET ( > *(trace > *(resent-date / > resent-from / > resent-sender / > resent-to / > resent-cc / > resent-bcc / > resent-id)) ) SET ( > *(orig-date / > from / > sender / > reply-to / > to / > cc / > bcc / > message-id / > in-reply-to / > references / > subject / > comments / > keywords / > optional-field) ) (small point of curiosity, for Pete or whoever: the current syntax for seems to mean that message headers are either fields or obs-fields, but not a combination?) Anyhow, folks, I would appreciate some technical feedback on this. The philosophical line of debate is probably played out. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Sun Jul 9 22:54:07 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15076 for ; Sun, 9 Jul 2000 22:46:10 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA15281; Sun, 9 Jul 2000 22:45:54 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 9 Jul 2000 22:45:54 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA15264; Sun, 9 Jul 2000 22:45:54 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA15251; Sun, 9 Jul 2000 22:45:52 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Sun, 9 Jul 2000 22:45:52 -0400 Received: from kobe-ppp-210-172-164-106.interq.or.jp (kobe-ppp-210-172-164-106.interq.or.jp [210.172.164.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id TAA03705; Sun, 9 Jul 2000 19:45:39 -0700 X-Authentication-Warning: joy.songbird.com: kobe-ppp-210-172-164-106.interq.or.jp [210.172.164.106] didn't use HELO protocol Message-Id: <4.3.2.20000709232404.00de34d0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sun, 09 Jul 2000 23:24:29 +0900 To: John C Klensin From: Dave Crocker Subject: Re: The "Postmaster" text Cc: drums@cs.utk.edu In-Reply-To: <917093036.962989767@P2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 05:09 PM 7/7/00 -0400, John C Klensin wrote: >I've tried to synthesize something from the various suggestions proposed text looks good. I like the semantic vagueness of 'block' in this case. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Sun Jul 9 23:44:36 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15865 for ; Sun, 9 Jul 2000 23:44:35 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id XAA18811; Sun, 9 Jul 2000 23:44:23 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 9 Jul 2000 23:44:17 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id XAA18786; Sun, 9 Jul 2000 23:44:16 -0400 (EDT) Received: from callisto.gac.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id XAA18766; Sun, 9 Jul 2000 23:44:15 -0400 (EDT) Received: from callisto.gac.edu (138.236.128.19 -> callisto.gac.edu) by cs.utk.edu (smtpshim v1.0); Sun, 9 Jul 2000 23:44:15 -0400 Received: from solen.gac.edu (solen.gac.edu [138.236.128.18]) by callisto.gac.edu (8.10.1/8.10.0/1.0) with ESMTP id e6A3iD431865; Sun, 9 Jul 2000 22:44:13 -0500 Received: from aragorn.it.gac.edu (aragorn.it.gac.edu [138.236.68.41]) by solen.gac.edu (8.9.3/8.9.3/GAC-HUB-2.43) with ESMTP id WAA07467; Sun, 9 Jul 2000 22:44:13 -0500 (CDT) Message-Id: <200007100344.WAA07467@solen.gac.edu> To: Dave Crocker Cc: drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-reply-to: <4.3.2.20000709223011.00bfebf0@mail.bayarea.net> References: <4.3.2.20000709223011.00bfebf0@mail.bayarea.net> Date: Sun, 09 Jul 2000 22:43:52 -0500 From: Philip Guenther List-Unsubscribe: Dave Crocker writes: ... >Let's get specific about how the construct probably should be used: > >RFC 1894: > >>2.2 Per-Message DSN Fields >> >> Some fields of a DSN apply to all of the delivery attempts described >> by that DSN. These fields may appear at most once in any DSN. These >> fields are used to correlate the DSN with the original message >> transaction and to provide additional information which may be useful >> to gateways. >> >> per-message-fields = > > SET ( > >> [ original-envelope-id-field CRLF ] >> reporting-mta-field CRLF >> [ dsn-gateway-field CRLF ] >> [ received-from-mta-field CRLF ] >> [ arrival-date-field CRLF ] >> *( extension-field CRLF ) > > ) > > >and in draft-ietf-drums-msg-fmt-07.txt: > >>name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)] > >becomes > >>name-val-list = [CFWS] SET [name-val-pair *(CFWS name-val-pair)] That syntax makes no separation between the 'tag' that cannot be repeated and what is being repeated. That is, it would appear to ban the following: To: joe.blow@some.where.com To: joe.blow@some.where.com But not this: To: joe.blow@some.where.com To: jane.blow@some.where.com Or even: To: joe.blow@some.where.com To: joe.blow@some.where.com Such an ABNF operator would have to explicitly specify what part of the repeated content is required to be unique. The uniqueness constraint also has be made on the semantic value of the token, no? To: joe.blow@some.where.com tO: joe.blow@some.where.com How about obsolete syntax: To: joe.blow@some.where.com To : joe.blow@some.where.com Philip Guenther ---------------------------------------------------------------------- guenther@gac.edu UNIX Systems and Network Administrator Gustavus Adolphus College St. Peter, MN 56082-1498 Source code never lies: it just misleads (Programming by Purloined Letter?) From owner-drums@cs.utk.edu Mon Jul 10 00:39:55 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16259 for ; Mon, 10 Jul 2000 00:39:55 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA22146; Mon, 10 Jul 2000 00:39:36 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 10 Jul 2000 00:39:34 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA22121; Mon, 10 Jul 2000 00:39:33 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA22101; Mon, 10 Jul 2000 00:39:32 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Mon, 10 Jul 2000 00:39:32 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id AAA05463; Mon, 10 Jul 2000 00:39:30 -0400 (EDT) Message-Id: <200007100439.AAA05463@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Keith Moore , drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-reply-to: Your message of "Mon, 10 Jul 2000 11:42:21 +0900." <4.3.2.20000709223011.00bfebf0@mail.bayarea.net> Date: Mon, 10 Jul 2000 00:39:30 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > At 12:56 AM 7/9/00 -0400, Keith Moore wrote: > >having this notation will not significantly simplify or clarify > >the specification for Internet mail. > > 1. The construct that is at issue cannot reasonably be specified in > current ABNF. correct. languages like ABNF have limitations. they don't specify semantics either, but that doesn't prevent them from being useful. > 2. The construct occurs regularly, such as for 822-like headers, labeled > parameters in Received headers, etc. This is not a small or occasional issue. the construct you suggest will not allow ABNF to specify the rules for 822 headers with any greater deal of precision. you're trying to make a grammar do a job that it cannot do well. language specialists have understood for years that replacement grammars have inherent limitations - they cannot fully describe arbitrary languages. such limitations are well documented in the literature. this doesn't prevent grammars from being useful as part of specification languages, but it's a mistake to try to get them to do things that they cannot do well. for instance -and this is a fairly classic example - most programming languages require that a variable be declared before it can be used. it turns out that (if there are arbitrary number of possible variable names) it is impossible to write a replacement grammar that enforces this rule. the problem you are trying to solve with ABNF is essentialy the same problem if the list of valid tokens that can appear "at most once" is extensible. now, can you design a notation that says "you can specify each of these tokens at most once"? of course you can. but it's not a simple change to ABNF - it doesn't mesh well with ABNF-style notation. > 3. Putting the qualifier in the prose is a good way a) to get missed, or > b) not to get specified. understood. but trying to do it in ABNF is an even worse fit. > Absence of this, for in RFC 1894, is what re-triggered my interest in this > topic. One might argue that misunderstanding this relaxation of the > apparent syntactic requirement for ordering is "merely" a matter of > acculturation -- one must be fully plugged in to the protocol development > community. That is a requirement that has scaling problems. in hindsight, 822 should have used * ( thing ) thing = (thing1 / thing2 / thing3 ) rather than [ thing1 ] [ thing2 ][ thing3 ] 822 tried to specify things with ABNF that ABNF (and any replacement grammar) really cannot specify well. > While few implementation errors can be documented by this unfair > requirement, growth of the Internet should encourage us to make common > constructs easier to specify and harder to miss. I'm all for trying to reduce the number of misunderstandings in a specification, but we cannot do this if we misunderstand the limitations of our specification language. > >Now it may be that there is some other justification for this notation. I > >just don't know what it is.. > > The working group felt it was worth adding earlier. We just couldn't > figure out how. I now believe that was because we tied it to alternation > (a / b) rather than concatenation (a b) and repetition, where it belongs. I now believe that it's because you are trying to do something with ABNF that it cannot do well. if you really want to specify this more formally than in prose, you need a different kind of notation than a replacement grammar. > In any event, the point you raise reduces to whether the community thinks > it is useful to have the construct in ABNF. I do; you don't. Others will > decide. what seems useful may still not be feasible. a perpetual motion machine would presumably be useful also. > > > >2. unlike the rest of ABNF, such a syntax would not easily be > > > >translated into something that a parser generator could > > > > > > ASN.1 parsers handle it just fine. > > > >I fail to see how this is relevant. > > See below. > > > >ASN.1 is a language for describing the structure of data > > as is ABNF. yes, but you were responding to my comment that the ABNF extension you proposed would not be easily translated to a parser generator. so your comment about ASN.1 in that context was a red herring. > >(BER maps that structure onto a presentation), but ASN.1 > >is not a language for writing a parser for some already-defined > >presentation of data. You can write an RFC 822 parser in yacc, > > yacc is the programming language, not ASN.1. yacc is a programming language for writing parsers. you can more-or-less translate ABNF into yacc, or similar languages. you cannot translate ABNF into ASN.1 > >but you can't write one in ASN.1 > > asymmetric comparison: > > <822 headers, or whatever> : abnf : yacc > > should be compared with: > > <822> : asn.1 : doesn't make sense. you can't describe 822 with asn.1 > >ASN.1 is not widely regarded as a particularly good notation for > >describing protocols. one of ASN.1's many mistakes is trying > > It is used. It works. Some like it; some don't. That's all fine, but > entirely irrelevant. > > You made a specific claim of non-implementability. I cited an existence > proof to contradict your specific claim. uh, no. you cited a red herring. > > > >3. notation that isn't used very often actually hinders readability > > > > > > The motivation for this is that it IS needed with regularity, namely for > > > every list of labeled parameters. Such lists are ALWAYS > > unordered. That's > > > the reason for the labels. > > > >in many of these cases (e.g. any time the list of labels is extensible) > >it's a bad idea to specify the parameter labels as literals anyway. > > > >in other words, it's bad style to write > > > > list = *( "thing1" / "thing2" / "thing3" / extension-thing ) > > You keep using the alternation construct. yes, because that's the best way to describe this in a grammar. > > Let's get specific about how the construct probably should be used: > > RFC 1894: > > >2.2 Per-Message DSN Fields > > > > Some fields of a DSN apply to all of the delivery attempts described > > by that DSN. These fields may appear at most once in any DSN. These > > fields are used to correlate the DSN with the original message > > transaction and to provide additional information which may be useful > > to gateways. > > > > per-message-fields = > > SET ( > > > [ original-envelope-id-field CRLF ] > > reporting-mta-field CRLF > > [ dsn-gateway-field CRLF ] > > [ received-from-mta-field CRLF ] > > [ arrival-date-field CRLF ] > > *( extension-field CRLF ) > > ) no, this doesn't work, because you want to be able to have more than one extension-field, and you want to be able to freely mix these fields in any order with the other fields. you're notation tries to change the meaning of * and [ ] within the SET construct. this is a lot more confusing than just writing "can occur at most once" in prose. > and in draft-ietf-drums-msg-fmt-07.txt: > > >name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)] > > becomes > > >name-val-list = [CFWS] SET [name-val-pair *(CFWS name-val-pair)] > > > and > > >fields = *(trace > > *(resent-date / > > resent-from / > > resent-sender / > > resent-to / > > resent-cc / > > resent-bcc / > > resent-id)) > > *(orig-date / > > from / > > sender / > > reply-to / > > to / > > cc / > > bcc / > > message-id / > > in-reply-to / > > references / > > subject / > > comments / > > keywords / > > optional-field) > > becomes something like: > > >fields = > > SET ( > > *(trace > > *(resent-date / > > resent-from / > > resent-sender / > > resent-to / > > resent-cc / > > resent-bcc / > > resent-id)) > ) > SET ( > > *(orig-date / > > from / > > sender / > > reply-to / > > to / > > cc / > > bcc / > > message-id / > > in-reply-to / > > references / > > subject / > > comments / > > keywords / > > optional-field) > ) > you're still enforcing ordering here that shouldn't be there; you're insisting that trace and resent fields occur before other fields. (or did you intend this? it's not consistent with current usage) and the above notation would still allow arbitrary numbers of each field to appear - because SET ( *(foo) ) means that *(foo) can occur at most once - but *(foo) means that foo can occur zero or more times. so SET ( *(foo) ) is equivalent to *(foo). so no, in addition to this notation being incompatible with rewrite grammars, it doesn't do what you think it does either. > > (small point of curiosity, for Pete or whoever: the current syntax for > seems to mean that message headers are either fields or > obs-fields, but not a combination?) > > Anyhow, folks, I would appreciate some technical feedback on this. you've gotten some. Keith From owner-drums@cs.utk.edu Mon Jul 10 00:42:56 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16283 for ; Mon, 10 Jul 2000 00:42:56 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA22568; Mon, 10 Jul 2000 00:42:43 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 10 Jul 2000 00:42:43 -0400 Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA22553; Mon, 10 Jul 2000 00:42:42 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Mon, 10 Jul 2000 00:42:42 -0400 Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id AAA05606 for dist-drums@cs.utk.edu; Mon, 10 Jul 2000 00:42:42 -0400 (EDT) Received: from munnari.OZ.AU (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id XAA17434; Sun, 9 Jul 2000 23:22:17 -0400 (EDT) Received: from munnari.OZ.AU (128.250.1.21 -> munnari.OZ.AU) by cs.utk.edu (smtpshim v1.0); Sun, 9 Jul 2000 23:22:18 -0400 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id DA26527; Mon, 10 Jul 2000 13:22:10 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: drums@cs.utk.edu Subject: Re: The 551/251 question In-Reply-To: Your message of "Sun, 09 Jul 2000 01:01:06 -0400." <200007090501.BAA16811@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jul 2000 13:22:10 +1000 Message-Id: <11598.963199330@mundamutti.cs.mu.OZ.AU> List-Unsubscribe: Date: Sun, 09 Jul 2000 01:01:06 -0400 From: Keith Moore Message-ID: <200007090501.BAA16811@astro.cs.utk.edu> | the new 552/251 text looks good to me. Yes, it would be fine. I'm not sure that it really needs say anything about what assumptions the server ought not be making about "address book" updating, as I don't think it has ever made any sense (or could possibly) for the server to assume anything of the kind. But leaving it there as positive reinforcement can't hurt. kre From owner-drums@cs.utk.edu Mon Jul 10 00:43:35 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16294 for ; Mon, 10 Jul 2000 00:43:35 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA22681; Mon, 10 Jul 2000 00:43:21 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 10 Jul 2000 00:43:21 -0400 Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA22666; Mon, 10 Jul 2000 00:43:20 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Mon, 10 Jul 2000 00:43:20 -0400 Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id AAA05631 for dist-drums@cs.utk.edu; Mon, 10 Jul 2000 00:43:20 -0400 (EDT) Received: from munnari.OZ.AU (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id XAA17349; Sun, 9 Jul 2000 23:19:22 -0400 (EDT) Received: from munnari.OZ.AU (128.250.1.21 -> munnari.OZ.AU) by cs.utk.edu (smtpshim v1.0); Sun, 9 Jul 2000 23:19:24 -0400 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id DA26361; Mon, 10 Jul 2000 13:19:10 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Dave Crocker Cc: drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-Reply-To: Your message of "Sat, 08 Jul 2000 22:55:47 +0900." <4.3.2.20000708224002.00c14e30@mail.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jul 2000 13:19:09 +1000 Message-Id: <11587.963199149@mundamutti.cs.mu.OZ.AU> List-Unsubscribe: Date: Sat, 08 Jul 2000 22:55:47 +0900 From: Dave Crocker Message-ID: <4.3.2.20000708224002.00c14e30@mail.bayarea.net> | Hmm. What is wrong with: | | rule = SET ( a b c ) OK, if that is what it is to mean (your original message was rather slim on semantic detail). So it is possible to require each of N elements once, in any order. But how does one allow any of the elements to occur more than once, and still be in any order. rule = SET ( *a *b *c ) cannot be it, as that would allow *a *b *c or *b *a *c or *c *b *a (etc) but then when the *a is expanded, all the a's need to occur next to each other, and a b a c cannot be generated. | Just fixing the problem for labeled parameter lists (like RFC822-derived | header lists...) would be enough for me. Does this really fix that - would you care to actually send in the grammar for something this would actually properly solve in 822? | (x / y) means x or y (but not both.) That is a single-element | result. | | Set constructs are not meaningful for it. Need to produce at | least two elements. Ah, I see, I was confused by ... group = "(" *c-wsp alternation *c-wsp ")" in your original message. "alternation" is a / b But now I also see that in the accompanying text, you said concatenation rather than alternation, so I guess some revision went on during the composition of that message, but didn't get applied everywhere... I still don't think this does enough to actually be useful. And making it do more, starts making things get horribly complex - there was a reason we started down towards that "horribly complicated effect of apply the (non)ordering to subordinate rules" ... kre From owner-drums@cs.utk.edu Mon Jul 10 00:44:11 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16305 for ; Mon, 10 Jul 2000 00:44:11 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA22740; Mon, 10 Jul 2000 00:43:58 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 10 Jul 2000 00:43:57 -0400 Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA22725; Mon, 10 Jul 2000 00:43:57 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Mon, 10 Jul 2000 00:43:57 -0400 Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id AAA05659 for dist-drums@cs.utk.edu; Mon, 10 Jul 2000 00:43:56 -0400 (EDT) Received: from munnari.OZ.AU (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id XAA19035; Sun, 9 Jul 2000 23:47:19 -0400 (EDT) Received: from munnari.OZ.AU (128.250.1.21 -> munnari.OZ.AU) by cs.utk.edu (smtpshim v1.0); Sun, 9 Jul 2000 23:47:20 -0400 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id DA26734; Mon, 10 Jul 2000 13:47:03 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Dave Crocker Cc: drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-Reply-To: Your message of "Mon, 10 Jul 2000 11:42:21 +0900." <4.3.2.20000709223011.00bfebf0@mail.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jul 2000 13:47:03 +1000 Message-Id: <11773.963200823@mundamutti.cs.mu.OZ.AU> List-Unsubscribe: Date: Mon, 10 Jul 2000 11:42:21 +0900 From: Dave Crocker Message-ID: <4.3.2.20000709223011.00bfebf0@mail.bayarea.net> | The working group felt it was worth adding earlier. We just couldn't | figure out how. I now believe that was because we tied it to alternation | (a / b) rather than concatenation (a b) and repetition, where it belongs. I'm not sure that makes much of a difference, ABNF is recursive, everything includes everything else. One possibility for an alternation is a single concatenation, and a concatenation can be a single repetition, which can be just an unadorned element, which can be a group, which is just an alternation inside parentheses. | In any event, the point you raise reduces to whether the community thinks | it is useful to have the construct in ABNF. I do; you don't. Others will | decide. I think it might be useful if it can be fully defined, and demonstrated. | Let's get specific about how the construct probably should be used: | > per-message-fields = | | SET ( | | > [ original-envelope-id-field CRLF ] | > reporting-mta-field CRLF | > [ dsn-gateway-field CRLF ] | > [ received-from-mta-field CRLF ] | > [ arrival-date-field CRLF ] | > *( extension-field CRLF ) | | ) Which looks fine, until someone reads it and says "see, all the extension fields included need to be adjacent to each other" as the SET construct only affects the objects directly in the group, not those one level further down. To avoid this, a more complex operator definition is needed for SET, or text is needed to explain that no, it is after all legal to have an extension field, then one of the defined fields, and then another extension field. | and in draft-ietf-drums-msg-fmt-07.txt: | | >name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)] | | becomes | | >name-val-list = [CFWS] SET [name-val-pair *(CFWS name-val-pair)] Which makes exactly what difference??? I think Keith's point was that as written, name-val-list already allows the name-val-pairs to occur in any order (because which particular name-val-pair is the first, and which is the second, isn't defined. | and | becomes something like: | | >fields = | | SET ( | > *(trace | > *(resent-date / | > resent-from / | > resent-sender / | > resent-to / | > resent-cc / | > resent-bcc / | > resent-id)) | ) This isn't achieving what you'd hope - it as it was without the SET will generate exactly the same as it does with the SET. There is no SET covering the resent-* headers included, they're just one element in the included concatenation. On the other hand, the *( / / /) allows the elements included to appear any number of times in any order. | SET ( | > *(orig-date / | > from / | > sender / | > reply-to / | > to / | > cc / | > bcc / | > message-id / | > in-reply-to / | > references / | > subject / | > comments / | > keywords / | > optional-field) | ) Again there, the SET adds nothing, the fields can already occur any number of times in any order. The problem that Pete's current grammar has, if it has one, is that it doesn't include "Only one From:" header, it allows any number of the things (and all those other headers as well). If you remove the *() from that, and include [ ] around all the elements that are optional, yu get closer to what you intended, but even that doesn't correctly allow the relationship between From and Sender to be included, nor the "must have one destination field" (though I forget if we decided to keep that rule - but for ABNF purposes, assume we did). And since "optional-field" would need to become *optional-field rather than [optional-field] you get back to the same problem that all the optional-fields that are included would have to be adjacent. | Anyhow, folks, I would appreciate some technical feedback on this. The | philosophical line of debate is probably played out. If you want a proper technical debate I think we'd need a proper technical specification to review. As it is now, philosophy is about all that can be debated, there aren't enough details for anything else. kre From owner-drums@cs.utk.edu Mon Jul 10 03:19:33 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29909 for ; Mon, 10 Jul 2000 03:19:33 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id DAA00373; Mon, 10 Jul 2000 03:19:07 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 10 Jul 2000 03:19:06 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id DAA00352; Mon, 10 Jul 2000 03:19:05 -0400 (EDT) Received: from A4.JCK.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id DAA00338; Mon, 10 Jul 2000 03:19:02 -0400 (EDT) Received: from A4.JCK.COM (209.187.148.211 -> ns.jck.com) by cs.utk.edu (smtpshim v1.0); Mon, 10 Jul 2000 03:19:02 -0400 Received: from P2 ("port 1348"@[209.187.148.217]) by a4.jck.com (PMDF V6.0-23 #40360) with ESMTP id <0FXH00F540DTYT@a4.jck.com> for drums@cs.utk.edu; Mon, 10 Jul 2000 03:20:17 -0400 (EDT) Date: Mon, 10 Jul 2000 03:18:59 -0400 From: John C Klensin Subject: smtpupd, draft 12 To: drums@cs.utk.edu Message-id: <1126464956.963199139@P2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit Ok, it just went into the I-D queue. The -12 version contains the alternate (second posted) version of the 251/551 text. Also the deprecation of the ASCII Null character has been removed. Dan, thanks for spotting this and providing a reference: I got some strongly-worded late input asking that I take it out, didn't recall the earlier WG discussions, and personally prefer to not see this changed. Bad memory rather than conspiracy; we are back to 128 ASCII characters. Anyone who dislikes either decision should plan to do some arm-wrestling during the Last Call period. john From owner-drums@cs.utk.edu Mon Jul 10 04:30:22 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00597 for ; Mon, 10 Jul 2000 04:30:22 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id EAA04772; Mon, 10 Jul 2000 04:30:05 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 10 Jul 2000 04:30:04 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id EAA04755; Mon, 10 Jul 2000 04:30:04 -0400 (EDT) Received: from arista.iris.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id EAA04702; Mon, 10 Jul 2000 04:29:41 -0400 (EDT) From: Received: from arista.iris.com (198.112.211.42 -> arista.iris.com) by cs.utk.edu (smtpshim v1.0); Mon, 10 Jul 2000 04:29:41 -0400 Subject: Re: ABNF sets and sequences To: dcrocker@brandenburg.com, kre@munnari.OZ.AU, moore@cs.utk.edu Cc: drums@cs.utk.edu X-Mailer: Lotus Notes Build V505_06222000 June 22, 2000 Message-ID: Date: Mon, 10 Jul 2000 09:23:42 +0100 X-MIMETrack: Serialize by Router on Arista/Iris(Build V504_05242000 |May 24, 2000) at 07/10/2000 04:33:15 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii List-Unsubscribe: Dave, Robert, Keith, I think that two things are getting badly confused in this discussion. ABNF, today, serves two purposes. 1. It is a notation that unambiguously (hopefully) allows a human being to distinguish whether an arbitrary string is legal or not. This in turn allows (again, hopefully) a human being to write a computer program that only generates legal strings, and that if combined with sufficient semantic information will correctly consume and process legal strings, and reject illegal strings. 2. It can be used to specify a control string that can be fed into a automatic parser (originally called a compiler compiler) which will then automatically distinguish legal from illegal strings. This in turn leads to two questions. 1. Do Dave's two new proposed constructs (if defined with enough rigor) allow a human being to more easily distinguish whether an arbitrary string is legal or not? My gut feeling is that they do, though clearly there are some nasty problems to be solved. For example, under Dave's proposed notation, are the two grammars foo = SET ( "a" "b" *("c")) and foo = SET ( "a" "b" c) c = *("c") equivalent? Everything I know about BNF would imply they are. My sense of what Dave is saying is that they are not, and that "cabc" is legal under the former, but not under the latter. Specifying this sufficiently and intuitively may be very problematic. For example, will a naive reader of RFC xxxx understand the meaning of SET ( blah blah blah) with sufficient precision to not generate illegal strings? This clearly needs discussion! 2. It may well be possible to build an automatic parser that correctly handles SET and SEQ constructs, then again, it may not. If it is not, it is not clear that we should reject Dave's proposed constructs out of hand. There are many unambiguous grammars that are incompatible with automatic parsers! Nick Nick Shelness, IBM Fellow Chief Technology Officer Lotus Development Corp Tel: (617) 693-7484 Assistant: Mary McGurran Tel: (617) 693-4321 From owner-drums@cs.utk.edu Mon Jul 10 09:10:27 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07495 for ; Mon, 10 Jul 2000 09:10:27 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA19749; Mon, 10 Jul 2000 09:10:04 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 10 Jul 2000 09:10:02 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA19715; Mon, 10 Jul 2000 09:09:59 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA19695; Mon, 10 Jul 2000 09:09:56 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Mon, 10 Jul 2000 09:09:56 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA05610; Mon, 10 Jul 2000 09:07:17 -0400 (EDT) Message-Id: <200007101307.JAA05610@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: shelness@lotus.com cc: dcrocker@brandenburg.com, kre@munnari.OZ.AU, moore@cs.utk.edu, drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-reply-to: Your message of "Mon, 10 Jul 2000 09:29:09 BST." Date: Mon, 10 Jul 2000 09:07:17 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: Nick, I agree with your clarifications; you've stated the points more clearly than I did. Keith From owner-drums@cs.utk.edu Mon Jul 10 12:41:21 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16508 for ; Mon, 10 Jul 2000 12:41:21 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA06143; Mon, 10 Jul 2000 12:40:55 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 10 Jul 2000 12:40:42 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA06085; Mon, 10 Jul 2000 12:40:40 -0400 (EDT) Received: from msw.mimesweeper.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA06071; Mon, 10 Jul 2000 12:40:37 -0400 (EDT) Received: from msw.mimesweeper.com (194.168.90.18 -> msw.mimesweeper.com) by cs.utk.edu (smtpshim v1.0); Mon, 10 Jul 2000 12:40:37 -0400 Received: from BELL.mimesweeper.com (unverified) by msw.mimesweeper.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 10 Jul 2000 17:40:56 +0100 Received: from GK-VAIO.Dial.pipex.com (gk-vaio.mimesweeper.com [194.168.90.137]) by BELL.mimesweeper.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 32D9GZ95; Mon, 10 Jul 2000 17:40:21 +0100 Message-Id: <4.3.2.7.2.20000710163458.00c10100@pop.dial.pipex.com> X-Sender: maiw03@pop.dial.pipex.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 10 Jul 2000 17:31:49 +0100 To: Dave Crocker From: Graham Klyne Subject: Re: ABNF sets and sequences Cc: drums@cs.utk.edu In-Reply-To: <4.3.2.20000707184050.00b85de0@mail.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 03:19 AM 7/8/00 +0100, Dave Crocker wrote: >Folks, > >Some issues just won't go away. > >The fact that some parameter lists are ordered and others are not is >problematic for ABNF-based specifications. We end up relying on obscure >text in the prose and/or on community memory. It's a long time since I studied this stuff formally, but in the murky recesses of my memory I think there are some fundamental reasons why "these constructs in any order" is a tricky issue to tackle at the level of "grammar definition by syntax productions". Most work on syntax definition in this way is focused on "context free" languages, in which it is possible to define the parse structure of a language in a way that has certain well-defined properties -- I think the general class of such languages is sometimes known as "Chomsky type 2". ABNF is one of many variants of this basic framework for syntax description. The problem with introducing a definition of "allow in any order" is that, in its more general cases, it breaks the "context free" language form, and the attendant well-understood properties. It is quite possible to introduce a limited form of "allow in any order", but these limited forms can be expressed anyway; e.g. sentence = a b | b a sentence = a b c | a c b | b a c | b c a | c a b | a b a Clearly, as the number of options increases, this approach becomes unwieldy. (For n options, n! alternatives are needed.) When the number of options to "allow in any order" are not known in advance, then the result cannot be described within the constraints of a context free language description. (This happens when arbitrary re-occurrences are allowed.) Of course, one is not forced to stick to the "context free approach". The Algol 68 language specification attempted to overcome the limitations of context free grammars, and introduced a two-level definition structure that allowed some of the context dependencies to be captured in the formalism used. That scheme was, IIRC, quite difficult to understand and I don't believe it has been attempted since. My point is this: while I have great sympathy for your goal, I think the pain of capturing "allow in any order" in the syntax formalism may end up exceeding the gain. In his response, I think Nick Shelness touches an important point: >1. Do Dave's two new proposed constructs (if defined with enough rigor) >allow a human being to more easily distinguish whether an arbitrary string >is legal or not? My gut feeling is that they do, though clearly there are >some nasty problems to be solved. For example, under Dave's proposed >notation, are the two grammars > > foo = SET ( "a" "b" *("c")) > >and > > foo = SET ( "a" "b" c) > c = *("c") > >equivalent? I could easily define an "allow in any order" structure that does not interact with repetition. But it wouldn't meet your goals. e.g. foo = BAG ( "a", "b", *("c") ) or foo = BAG ( "a", "b", c ) c = *("c") Here, the commas are used to make it clear what is "in scope" of the BAG construct, and what is internal to the set members. But but still doesn't allow me to express that c b a c is a valid sentence. According to the formalism, the repeated "c"s must be contiguous. To meet (my understanding of) your goal, a construct is needed that combines the SET and repetition options. I could imagine such a construct; e.g. BAG ( ("a") ("b") *("c") ) where the parentheses surrounding "a", "b", "c", and any applied repetition, are part of the SET construct. One might find a more comfortable syntax, but great care would be needed to ensure that it is clear whether any repetition of part of the BAG or part of a contained element. Compare the above with: BAG ( ("a") ("b") (*("c")) ) SO: I think what you propose is possible, but is it really helpful? Programming languages have long lived with the idea that formal syntax is a useful tool for describing the structure of a program, but that it is not possible to define _exactly_ what constitutes a valid program with formal syntax alone. Normally, we have the requirement that any valid program MUST satisfy the formal syntax, and in addition must satisfy additional semantic constraints (variables must be declared, a variable appears only once in a lexical scope, etc.). One problem with the current approach to using ABNF in the e-mail documents is that a valid sentence is not required to conform to the formal syntax. The formal syntax is stated, and then, in the text, is a "semantic escape clause" that says that the ordering of headers is relaxed. Maybe this is the real source of the confusion or oversight you sense. To define a syntax that is valid for all email messages, in a fashion more consistent with typical programming language definitions, the concatenation could be replaced by a global repeat construct containing alternatives, and semantic statements in the text used to indicate whether or not any given header may be repeated: headers = *header header = from-header / to-header / cc-header / bcc-header / : etc. I would also assert that this leads to a structure that is much closer to how many programmers would actually implement message format validation. #g ------------ Graham Klyne (GK@ACM.ORG) From owner-drums@cs.utk.edu Mon Jul 10 17:23:13 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29062 for ; Mon, 10 Jul 2000 17:23:12 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA28873; Mon, 10 Jul 2000 17:22:55 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 10 Jul 2000 17:22:50 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA28854; Mon, 10 Jul 2000 17:22:50 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA28832; Mon, 10 Jul 2000 17:22:43 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Mon, 10 Jul 2000 17:22:43 -0400 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22804 for ; Mon, 10 Jul 2000 14:22:37 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA03371 for ; Mon, 10 Jul 2000 14:22:28 -0700 (PDT) Date: Mon, 10 Jul 2000 14:18:44 -0700 From: Chris Newman To: drums@cs.utk.edu Subject: Re: ABNF sets and sequences Message-ID: <7683695.3172227524@nifty-jr.west.sun.com> In-Reply-To: <4.3.2.20000709223011.00bfebf0@mail.bayarea.net> X-Mailer: Mulberry/2.0.0 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit The underlying problem with 822, DSN and similar drafts was that the formal syntax was incorrect -- it gave a specific order for the headers. Then obscure prose retroactively changed the rules for the incorrect formal syntax. 822bis has fixed the problem by specifying correct formal syntax and then adding a table for additional restrictions on the correct syntax. This uses the existing syntax ABNF supports for unordered lists: *(a / b / c). Furthermore, when I wrote my message lint utility: which strictly validates 822 content, the structure that made sense for the code was to have formal syntax for generic headers in the code and a table of headers and the various restrictions on those headers (including header-specific formal syntax) in a separate (extensible) table. So from a programmer viewpoint 822bis is heading in exactly the right direction -- combine the *(a / b / c) unordered-list syntax with a table of additional restrictions. I'd actually be inclined to consider moving more into the table (including which headers are mandatory and header-specific syntax). I'm also unclear what the proposed addition to ABNF is. Options include: (1) Syntax for unordered lists. But since we already have *(a / b / c), we don't need to add anything. (2) Syntax for a list of attribute-value pairs where each attribute can occur only once. This isn't useful in the message format case since the rules are far more complex. Furthermore, I don't believe it's possible for a formal syntax to express this clearly since it implies the formal syntax has explicit knowledge of the attribute-value concept, and since attribute-value lists can be represented by many different syntaxes, I suspect this would have problems similar to the # construct, only much worse. (3) Syntax to generally support complex restrictions on attributes within an attribute-value construct. Similar to (2), but will be both more useful and vastly more complex and unintuitive. - Chris From owner-drums@cs.utk.edu Mon Jul 10 21:37:59 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04036 for ; Mon, 10 Jul 2000 21:37:59 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA16363; Mon, 10 Jul 2000 21:37:43 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 10 Jul 2000 21:37:39 -0400 Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA16348; Mon, 10 Jul 2000 21:37:39 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Mon, 10 Jul 2000 21:37:39 -0400 Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id VAA20455 for dist-drums@cs.utk.edu; Mon, 10 Jul 2000 21:37:39 -0400 (EDT) Received: from munnari.OZ.AU (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id BAA26380; Mon, 10 Jul 2000 01:07:34 -0400 (EDT) Received: from munnari.OZ.AU (128.250.1.21 -> munnari.OZ.AU) by cs.utk.edu (smtpshim v1.0); Mon, 10 Jul 2000 01:07:39 -0400 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id FA27492; Mon, 10 Jul 2000 15:07:15 +1000 (from kre@munnari.OZ.AU) From: Robert Elz Cc: Dave Crocker , drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-Reply-To: Your message of "Mon, 10 Jul 2000 13:19:09 +1000." <11587.963199149@mundamutti.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 10 Jul 2000 15:07:14 +1000 Message-Id: <12255.963205634@mundamutti.cs.mu.OZ.AU> List-Unsubscribe: Date: Mon, 10 Jul 2000 13:19:09 +1000 From: Robert Elz Message-ID: <11587.963199149@mundamutti.cs.mu.OZ.AU> | Ah, I see, I was confused by ... | | group = "(" *c-wsp alternation *c-wsp ")" | | in your original message. "alternation" is a / b And I cut/pasted the wrong line, that was the "used to be", I should have included the "would become" line, which was ... group = order "(" *c-wsp alternation *c-wsp ")" but the point doesn't change. kre From owner-drums@cs.utk.edu Tue Jul 11 05:27:25 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22709 for ; Tue, 11 Jul 2000 05:27:25 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA08113; Tue, 11 Jul 2000 05:27:02 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 11 Jul 2000 05:26:53 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id FAA08087; Tue, 11 Jul 2000 05:26:53 -0400 (EDT) Received: from gemma.TechFak.Uni-Bielefeld.DE (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id FAA08074; Tue, 11 Jul 2000 05:26:50 -0400 (EDT) Received: from gemma.TechFak.Uni-Bielefeld.DE (129.70.136.103 -> gemma.TechFak.Uni-Bielefeld.DE) by cs.utk.edu (smtpshim v1.0); Tue, 11 Jul 2000 05:26:50 -0400 Received: from grimsvotn.TechFak.Uni-Bielefeld.DE (grimsvotn.TechFak.Uni-Bielefeld.DE [129.70.136.13]) by gemma.TechFak.Uni-Bielefeld.DE (8.9.1/8.9.1/TechFak/pk+ro20000427) with SMTP id LAA11111; Tue, 11 Jul 2000 11:26:48 +0200 (MET DST) Received: from localhost by grimsvotn.TechFak.Uni-Bielefeld.DE (SMI-8.6/pk19971205) id LAA23545; Tue, 11 Jul 2000 11:26:33 +0200 Message-Id: <200007110926.LAA23545@grimsvotn.TechFak.Uni-Bielefeld.DE> To: John C Klensin Cc: drums@cs.utk.edu Subject: Re: The "Postmaster" text In-reply-to: Your message of "Sat, 08 Jul 2000 11:48:24 EDT." <984230446.963056904@P2> X-Organization: Uni Bielefeld, Technische Fakultaet X-Phone: +49 521 106 2902 Date: Tue, 11 Jul 2000 11:26:31 +0200 From: Peter Koch List-Unsubscribe: > We could, of course, define "block" and include some of the > above discussion, but that would appear to run counter to the > WG's sense that we should not get any further into mechanisms in > that area than needed. I understand that the text for the exceptional case of ``blocking'' postmaster mail is aimed at the faction which sometimes confuses protocol documents for wordings of a law (cf. wild accusations of ``RFC violation'' in Usenet newsgroups). So keeping out of this is really a good idea, but the current text is already in. Thanks for the background info. -Peter From owner-drums@cs.utk.edu Tue Jul 11 05:28:33 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22721 for ; Tue, 11 Jul 2000 05:28:33 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA08186; Tue, 11 Jul 2000 05:28:11 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 11 Jul 2000 05:28:10 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id FAA08169; Tue, 11 Jul 2000 05:28:10 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id FAA08156; Tue, 11 Jul 2000 05:28:08 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Tue, 11 Jul 2000 05:28:08 -0400 Received: from kobe-ppp-210-172-164-173.interq.or.jp (kobe-ppp-210-172-164-173.interq.or.jp [210.172.164.173]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id CAA16307 for ; Tue, 11 Jul 2000 02:28:05 -0700 X-Authentication-Warning: joy.songbird.com: kobe-ppp-210-172-164-173.interq.or.jp [210.172.164.173] didn't use HELO protocol Message-Id: <4.3.2.20000711173432.00c043e0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 11 Jul 2000 18:26:27 +0900 To: drums@cs.utk.edu From: Dave Crocker Subject: Re: ABNF sets and sequences In-Reply-To: <7683695.3172227524@nifty-jr.west.sun.com> References: <4.3.2.20000709223011.00bfebf0@mail.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: PRIMARY COMMENT: At 02:18 PM 7/10/00 -0700, Chris Newman wrote: >(1) Syntax for unordered lists. But since we already have *(a / b / c), >we don't need to add anything. While I would like to explore my original concerns and proposal further, I frankly will consider this thread adequately productive for having surfaced the above sentence sufficiently to give me guidance for some additional text in the ABNF specification, so IT can give guidance to users of ABNF. FURTHER DISCUSSION The thin edge of the wedge I will use to keep the door open is RFC 1894, as an example of the above insight not making it into a specification -- and please note the use of the word "example", which means that there is no criticism of 1894 itself, just interest in it as representative of ABNF writing style. Also there is the question of *( a / b / c )'s adequacy. RFC1894 was written in 1996. Perhaps the insight is more recent? Will adding advisory "usage" text to the ABNF specification be sufficient to help future writers use the *(a / b / c) construct? Is the *(a/b/c) construct sufficient for 1894? My effort at re-formulation produces: per-message-fields = *( ( original-envelope-id-field CRLF ) / ( reporting-mta-field CRLF ) / ( dsn-gateway-field CRLF ) / (received-from-mta-field CRLF ) / ( arrival-date-field CRLF ) / ( extension-field CRLF ) ) The main point is that the distinction between optional and required is entirely removed from the syntax, as well as multiple occurrences, for extension-field. DRUMS EXEMPLAR With respect to draft-ietf-drums-msg-fmt-07.txt , there seems to be a problem: >message = (fields / obs-fields) [CRLF body] > >fields = *(trace > *(resent-date / > resent-from / > resent-sender / > resent-to / > resent-cc / > resent-bcc / > resent-id)) > *(orig-date / > from / > sender / > reply-to / > to / > cc / > bcc / > message-id / > in-reply-to / > references / > subject / > comments / > keywords / > optional-field) does NOT fully show the non-ordering that is cited in: >.... So from a programmer viewpoint 822bis is heading in exactly the >right direction -- combine the *(a / b / c) unordered-list syntax with a >table of additional restrictions. or did I miss something? It looks as if, for example, the syntax requires trace information to precede the From field. PRECISE NUMBER OF OCCURRENCES >(2) Syntax for a list of attribute-value pairs where each attribute can >occur only once. This isn't useful in the message format case since the >rules are far more complex. 0. "only once"... or any specified number of times. 1. In fact, the *( a/b/c ) construct guarantees loss of all syntactic control over the number of times. *** Specification of number of permitted/required occurrences *** must be placed into the prose. 2. Can we get some elaboration on the "far more complex" assessment? The formal rules in RFC822 permit zero or one header in most cases, requiring only a few. With respect to generic multiple occurrences of the same header RFC822 states > 4.1. SYNTAX >... > This specification permits multiple occurrences of most > fields. Except as noted, their interpretation is not > specified here, and their use is discouraged. However most implementations treat them as a concatenation of a single header. My own feeling is that the rules pertaining to number of occurrences of list members tend to be pretty simple, along the lines of: 1. Exactly once 2. At most once 3. Zero or more 4. 1 or more and that other rules are very rare indeed. >Furthermore, I don't believe it's possible for a formal syntax to express >this clearly since it implies the formal syntax has explicit knowledge of >the attribute-value concept, and since attribute-value lists can be >represented by many different syntaxes, I suspect this would have problems >similar to the # construct, only much worse. Not clear to me that explicit knowledge of the attribute-value concept is at all required. I believe the focus on "number of occurrences" fits the issue adequately. The fact that the occurrences are of things that are attribute/value does not seem relevant. >(3) Syntax to generally support complex restrictions on attributes within >an attribute-value construct. Similar to (2), but will be both more >useful and vastly more complex and unintuitive. I agree entirely. At 09:29 AM 7/10/00 +0100, shelness@lotus.com wrote: >1. Do Dave's two new proposed constructs (if defined with enough rigor) >allow a human being to more easily distinguish whether an arbitrary string >is legal or not? My gut feeling is that they do, though clearly there are >some nasty problems to be solved. For example, under Dave's proposed >notation, are the two grammars > > foo = SET ( "a" "b" *("c")) > >and > > foo = SET ( "a" "b" c) > c = *("c") > >equivalent? Everything I know about BNF would imply they are. My sense of >what Dave is saying is that they are not, and that "cabc" is legal under Classic BNF is strictly ordered, so, yes, the two forms yield the same result. And, yes, I am suggesting something that does not. And, yes, that's a problem if only for clarity of understanding. However, like defining the difference between URLs that are part of a web page set, versus URLs that are just external references, there needs to be a boundary on the un-ordering. I'd be perfectly happy exploring a variation on *(a/b/c) for unordering, if it results in something more clear. At base, focus on concatenation seemed better than alternation because unordering is messing with the combinatorials of items, rather than with what items are 'selected'. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Tue Jul 11 06:29:48 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23238 for ; Tue, 11 Jul 2000 06:29:47 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA11124; Tue, 11 Jul 2000 06:29:33 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 11 Jul 2000 06:29:31 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA11107; Tue, 11 Jul 2000 06:29:31 -0400 (EDT) Received: from ietf.org (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA11093; Tue, 11 Jul 2000 06:29:29 -0400 (EDT) Received: from ietf.org (132.151.1.176 -> odin.ietf.org) by cs.utk.edu (smtpshim v1.0); Tue, 11 Jul 2000 06:29:29 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23185; Tue, 11 Jul 2000 06:29:28 -0400 (EDT) Message-Id: <200007111029.GAA23185@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: drums@cs.utk.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-drums-smtpupd-12.txt Date: Tue, 11 Jul 2000 06:29:28 -0400 Sender: nsyracus@cnri.reston.va.us List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Detailed Revision/Update of Message Standards Working Group of the IETF. Title : Simple Mail Transfer Protocol Author(s) : J. Klensin Filename : draft-ietf-drums-smtpupd-12.txt Pages : 58 Date : 10-Jul-00 This document is a self-contained specification of the basic protocol for the Internet electronic mail transport, consolidating and updating: - the original SMTP specification of RFC 821 [RFC-821], - domain name system requirements and implications for mail transport from RFC 1035 [RFC-DNS] and RFC 974 [RFC-974], - the clarifications and applicability statements in RFC 1123 [RFC-1123], and - material drawn from the SMTP Extension mechanisms [SMTPEXT]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-drums-smtpupd-12.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-drums-smtpupd-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-drums-smtpupd-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000710151017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-drums-smtpupd-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-drums-smtpupd-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000710151017.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-drums@cs.utk.edu Tue Jul 11 06:58:09 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24927 for ; Tue, 11 Jul 2000 06:58:08 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA13256; Tue, 11 Jul 2000 06:57:54 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 11 Jul 2000 06:57:52 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA13237; Tue, 11 Jul 2000 06:57:52 -0400 (EDT) Received: from lotus2.lotus.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA13224; Tue, 11 Jul 2000 06:57:50 -0400 (EDT) From: Received: from lotus2.lotus.com (192.233.136.8 -> lotus2.lotus.com) by cs.utk.edu (smtpshim v1.0); Tue, 11 Jul 2000 06:57:50 -0400 Received: from internet1.lotus.com (internet1.lotus.com [9.95.4.235]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id GAA01922 for ; Tue, 11 Jul 2000 06:58:44 -0400 (EDT) Received: from motorcity2.lotus.com (motorcity2.lotus.com [9.95.19.177]) by internet1.lotus.com (8.9.3/8.9.3) with SMTP id GAA24819 for ; Tue, 11 Jul 2000 06:57:48 -0400 (EDT) Received: by motorcity2.lotus.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256919.003C2993 ; Tue, 11 Jul 2000 06:57:08 -0400 X-Lotus-FromDomain: NOTES@ALPHABETA Sender: Nick_Shelness@motorcity2.lotus.com To: drums@cs.utk.edu Message-ID: <85256919.003C295F.00@motorcity2.lotus.com> Date: Tue, 11 Jul 2000 06:57:39 -0400 Subject: Re: ABNF sets and sequences Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: OK! So initially I was won over by Chis' proposal that we use the *( a / b / c) syntactic construct accompanied by a standardized table to specify occurrence and other constraints for unordered sets. BUT! Dave makes that the point that *( a / b / c) is syntactically weaker than it could (or should) be, because it lacks any occurrence information. I think that we can all agree that there is no problem with a SET construct that specifies mandatory "xxx" or optional [ "xxx" ] inclusion of a single string, the problem occurs with possible multiple occurrences m*n( "xxx") of a string. One simple way around this would be to require the components of a SET construct to be non-terminals. In this case, it is the strings that correspond to each non-terminal that may appear in any order. If this were done then we would have a notation which follows BNF conventions, and which would allow the specification of occurrence constraints in a very transparent and easily understood way. This seems like a good idea. We shouldn't get hung up here about whether a grammar containing a SET construct can be treated as a control string to an automatic parser. It may well be the case that the processing of a SET ( [a] b *c 1*d ) construct is best implemented by treating it syntactically as a *( a / b / c /d) construct with a table that specifies that a may occur 0-1 times, b must occur 1 time, c may occur 0-n times and d may occur 1-n times. Certainly, I think that it is hard to argue against the expressive notational power of SET ( [a] b *c 1*d ), and I at least am beginning to convince myself that we should pursue this idea further. Nick Nick Shelness, IBM Fellow Chief Technology Officer Lotus Development Corp Tel: (617) 693-7484 Assistant: Mary McGurran Tel: (617) 693-4321 From owner-drums@cs.utk.edu Tue Jul 11 15:06:47 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16226 for ; Tue, 11 Jul 2000 15:06:47 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA22336; Tue, 11 Jul 2000 15:06:23 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 11 Jul 2000 15:06:21 -0400 Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA22317; Tue, 11 Jul 2000 15:06:20 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Tue, 11 Jul 2000 15:06:20 -0400 Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id PAA02338 for dist-drums@cs.utk.edu; Tue, 11 Jul 2000 15:06:21 -0400 (EDT) Received: from munnari.OZ.AU (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA04717; Tue, 11 Jul 2000 12:16:48 -0400 (EDT) Received: from munnari.OZ.AU (128.250.1.21 -> munnari.OZ.AU) by cs.utk.edu (smtpshim v1.0); Tue, 11 Jul 2000 12:16:49 -0400 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id QA18733; Wed, 12 Jul 2000 02:16:26 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Nick_Shelness@motorcity2.lotus.com Cc: drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-Reply-To: Your message of "Tue, 11 Jul 2000 06:57:39 -0400." <85256919.003C295F.00@motorcity2.lotus.com> Date: Wed, 12 Jul 2000 02:16:25 +1000 Message-Id: <18201.963332185@mundamutti.cs.mu.OZ.AU> List-Unsubscribe: Date: Tue, 11 Jul 2000 06:57:39 -0400 From: Message-ID: <85256919.003C295F.00@motorcity2.lotus.com> | One simple way around this would be to require | the components of a SET construct to be non-terminals. In this case, it is | the strings that correspond to each non-terminal that may appear in any | order. That isn't defined well enough to be useful. Eg: consider rule = SET ( a b c ) a = x y or even rule = SET ( (x y) b c ) are you then going to allow b x c y ? What exactly are the "strings that correspond to a non-terminal"? This is the kind of complication that Dave was attempting to avoid by limiting the ordering to apply only into the top level, and not descend. Just maybe one way around this might be to add to ABNF a rule set = "{" 2*( *c-wsp repetition ) *c-wsp "}" and make set one of the alternatives for element. (I prefer to use "{" "}" over "SET (" ")" but that's just syntax drivel, what counts here is the semantics). The "2*" is the only thing that makes logical sense, but 1* or even 0* (ie: just *) wouldn't hurt. The semantic would be that the elements generated directly by each repetition (considered all together) could appear in any order, but that the expansion of each element itself would not be subject to reordering. The effect would be that rule = { a b c } a = *x and rule = { *x b c } would not define the same language, as in the first case 'a' is a repetition with the optional repeat omitted, hence leading to a single element, that element (which happens to be generated by *x) could come anywhere with respect to b and c, but couldn't be split. On the other hand, in the second case, the *x contains the indefinite repetition of the element 'x' and so the various x's could be ordered anywhere wrt the b and c. I haven't thought about this for long enough to see the difficulties that it exposes, though I think it quite unlikely that there are none. kre ps: draft dependencies can be a non-issue here - the way to avoid that problem would be to not republish an amended ABNF, but to publish an ammendment to ABNF. Anything that is using 2234 just continues to do so, and gets to advance as that does. Anything that wants to use sets would necessarily post-date the new RFC, and so need not be restricted by it (unless of course, there's just one use of sets, in which case the new one may never get past proposed). That is, apart from explanation, boilerplate, and noise, the new RFC would be just element =/ set set = "{" 2*( *c-wsp repitition ) *c-wsp "}" From owner-drums@cs.utk.edu Tue Jul 11 15:55:36 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18040 for ; Tue, 11 Jul 2000 15:55:35 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA27064; Tue, 11 Jul 2000 15:55:20 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 11 Jul 2000 15:55:19 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA27044; Tue, 11 Jul 2000 15:55:18 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA27028; Tue, 11 Jul 2000 15:55:15 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Tue, 11 Jul 2000 15:55:15 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA03629; Tue, 11 Jul 2000 15:55:13 -0400 (EDT) Message-Id: <200007111955.PAA03629@astro.cs.utk.edu> To: Dave Crocker cc: drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-Reply-To: Message from Dave Crocker of "Tue, 11 Jul 2000 18:26:27 +0900." <4.3.2.20000711173432.00c043e0@mail.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Jul 2000 15:55:13 -0400 From: Keith Moore List-Unsubscribe: Dave, what makes you think that RFC 1894 intended to allow the per-message or per-recipient fields to be in any order? granted, the interpretation of the fields is obvious if they are presented in a different order than that specified in the document, but I don't recall putting anything in RFC 1894 which allows senders to relax the ordering... and I can't find it now. Keith From owner-drums@cs.utk.edu Tue Jul 11 17:56:26 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21620 for ; Tue, 11 Jul 2000 17:56:26 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA07049; Tue, 11 Jul 2000 17:56:02 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 11 Jul 2000 17:56:00 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA07015; Tue, 11 Jul 2000 17:55:59 -0400 (EDT) Received: from lotus2.lotus.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA06989; Tue, 11 Jul 2000 17:55:53 -0400 (EDT) From: Received: from lotus2.lotus.com (192.233.136.8 -> lotus2.lotus.com) by cs.utk.edu (smtpshim v1.0); Tue, 11 Jul 2000 17:55:54 -0400 Received: from internet1.lotus.com (internet1.lotus.com [9.95.4.235]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id RAA24438; Tue, 11 Jul 2000 17:56:50 -0400 (EDT) Received: from motorcity2.lotus.com (motorcity2.lotus.com [9.95.19.177]) by internet1.lotus.com (8.9.3/8.9.3) with SMTP id RAA14826; Tue, 11 Jul 2000 17:55:53 -0400 (EDT) Received: by motorcity2.lotus.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256919.00786780 ; Tue, 11 Jul 2000 17:55:08 -0400 X-Lotus-FromDomain: NOTES@ALPHABETA Sender: Nick_Shelness@motorcity2.lotus.com To: Robert Elz cc: drums@cs.utk.edu Message-ID: <85256919.00786751.00@motorcity2.lotus.com> Date: Tue, 11 Jul 2000 17:55:29 -0400 Subject: Re: ABNF sets and sequences Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: Robert, I think that we are in heated agreement, just approaching it along different paths. > | One simple way around this would be to > | the components of a SET construct to be non-terminals. In this case, it is > | the strings that correspond to each non-terminal that may appear in any > | order. > > That isn't defined well enough to be useful. > > Eg: consider > > rule = SET ( a b c ) > a = x y OK > or even > rule = SET ( (x y) b c ) Having thought about this a bit more, I would view this as ill formed. I now think that a member of a set should only be one of repeat rulename / rulename / "[" rulename "]" where rulename and "[" rulename "]" are notationaly cleaner but otherwise syntactically identical to "1*1" rulename and "0*1" rulename. No other forms would be allowed. Note, that in my earlier note I used the generic term non-terminal to mean the ABNF construct rulename. > are you then going to allow b x c y ? Under your first set of rules - No. Given rule = SET ( a b c ) a = "x" "y" b = "u" c = "v" then "xyuv", "xyvu", "uxyv", "uvxy", "vxyu", and "vuxy" would be legal strings. Any other combinations of u v x and y would not. > What exactly are the "strings that correspond to a non-terminal"? Those produced by the rule with the rulename specified as a member of the SET construct. > This is the kind of complication that Dave was attempting to avoid > by limiting the ordering to apply only into the top level, and not > descend. That's also what I'm trying to achieve. What I hadn't attempted to do, and which I now think is needed, and which you are now doing, is to rigorously define the syntax of a set and by extension an element. > ... > set = "{" 2*( *c-wsp repitition ) *c-wsp "}" If I stick with your {} conventions, then I guess I'm proposing set = "{" 2*( *c-wsp member ) *c-wsp "}" member = ( rulename / "[" rulename "]" / [repeat] rulename which is more restrictive, but I think notationaly cleaner. What do you think? Nick Nick Shelness, IBM Fellow Chief Technology Officer Lotus Development Corp Tel: (617) 693-7484 Assistant: Mary McGurran Tel: (617) 693-4321 From owner-drums@cs.utk.edu Tue Jul 11 22:05:45 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26203 for ; Tue, 11 Jul 2000 22:05:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA20078; Tue, 11 Jul 2000 22:05:07 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 11 Jul 2000 22:05:03 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA20052; Tue, 11 Jul 2000 22:05:03 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA20021; Tue, 11 Jul 2000 22:05:00 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Tue, 11 Jul 2000 22:05:00 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id WAA06452; Tue, 11 Jul 2000 22:02:20 -0400 (EDT) Message-Id: <200007120202.WAA06452@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Nick_Shelness@motorcity2.lotus.com cc: Robert Elz , drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-reply-to: Your message of "Tue, 11 Jul 2000 17:55:29 EDT." <85256919.00786751.00@motorcity2.lotus.com> Date: Tue, 11 Jul 2000 22:02:20 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: I think this is all somewhat misplaced. if we want a way to be able to specify that elements in a list may occur in any order, we can easily specify the syntax of the list, e.g.: list = name "=" value *( ; name "=" value ) name = atom value = string what we then want to do is to formally specify that no symbol (or sequence of symbols?) that matches one 'name' is the same as the symbol (or sequence) that matches any other occurance of 'name'. that's easy to specify: just invent some syntax to say "it is an error if this lexical symbol matches the same sequence of input symbols more than once within a single application of this rule" so if we used '$' to denote such symbols, then: list = $name "=" value *( ; $name "=" value ) name = atom value = string would suffice to express that no input symbol or sequence of input symbols could match 'name' more than once during the appliation of the rule. note that this error is NOT a parse error - if the parser sees the string a="1";b="2";a="3";d="4" it does not stop matching 'list' when it sees the second occurance of "a=" - rather 'list' still matches the entire string above but then the recognizer signals an error that the name 'a' occurrred more than once. also this doesn't say anything at all about what the values might correspond to 'name' - but that's not a big problem, as these are not really something you want to wire into a parser anyway. note that for a parser to implement a rule like this it would have to keep track of all sequences of symbols which had matched 'name' within that rule, until the rule no longer matched new input symbols....which requires an arbitrary amount of state.. now if you also wanted to impose other constraints, such as "the name "X" occurs exactly once, or the name "Y" never occurs, it's really hard to do this with grammar rules - but you could add a set of formally-specified conditions. instead of a rule looking like nonterminal "=" *symbol you could instead have nonterminal "=" *symbol [ ":" condition ] where you have a separate language to describe conditions. a condition might look like a Boolean expression, say, using a subset of C syntax. imagine a notation where #name would mean the number of times the symbol 'name' was matchined within a rule and #(name:"string") would mean the number of times the nonterminal 'name' matched the sequence of input symbols "string" within that rule. then we could describe message headers more-or-less like this (leaving out gory details of white space and folding) header = *( $return-path ":" return-path-body / $recipient ":" recipient-body / $from ":" from-body / "received" ":" received-body / $field-name ":" *text ) : #return-path == 1 && #(recipient:"to") == 1 && #(recipient:"cc") <= 1 && #(recipient:"reply-to") <= 1 && #from == 1 && #(field-name:"subject") <= 1 return-path = "return-path" recipient = "to" / "cc" / "reply-to" from = "from" field-name = atom and in fact we could leave out the $ syntax altogether. e.g. header = *( return-path ":" return-path-body / recipient ":" recipient-body / from ":" from-body / "received" ":" received-body / field-name ":" *text ) : #return-path == 1 && #(recipient:"to") == 1 && #(recipient:"cc") <= 1 && #(recipient:"reply-to") <= 1 && #from == 1 && #(field-name:"subject") <= 1 return-path = "return-path" recipient = "to" / "cc" / "reply-to" from = "from" field-name = atom the point is that while it really might be useful to specify the "at least once" or "at most once" conditions formally, rather than in prose - these aren't an issue for parsing - and ABNF is designed to specify parsing. you want to parse these strings normally only then then signal an error if the conditions are violated. so it make sense to specify the conditions separately from the grammar. OTOH I don't immediately see why ABNF couldn't be extended in this way to allow the writer to define a set of conditions to be checked after every rule. it is a pain to implement in a general fashion- it forces the recognizer to keep track of an arbitrary amount of state. but another nice thing about this notation is that it cleanly separates the things that can easily be parsed from the conditions that typically have to be implemented in some other way. Keith From owner-drums@cs.utk.edu Wed Jul 12 03:47:07 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13347 for ; Wed, 12 Jul 2000 03:47:07 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id DAA03921; Wed, 12 Jul 2000 03:46:45 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 12 Jul 2000 03:46:42 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id DAA03904; Wed, 12 Jul 2000 03:46:42 -0400 (EDT) Received: from lotus2.lotus.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id DAA03887; Wed, 12 Jul 2000 03:46:40 -0400 (EDT) From: Received: from lotus2.lotus.com (192.233.136.8 -> lotus2.lotus.com) by cs.utk.edu (smtpshim v1.0); Wed, 12 Jul 2000 03:46:40 -0400 Received: from internet1.lotus.com (internet1.lotus.com [9.95.4.235]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id DAA14149; Wed, 12 Jul 2000 03:47:38 -0400 (EDT) Received: from motorcity2.lotus.com (motorcity2.lotus.com [9.95.19.177]) by internet1.lotus.com (8.9.3/8.9.3) with SMTP id DAA22966; Wed, 12 Jul 2000 03:46:40 -0400 (EDT) Received: by motorcity2.lotus.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8525691A.002AA73A ; Wed, 12 Jul 2000 03:45:53 -0400 X-Lotus-FromDomain: NOTES@ALPHABETA Sender: Nick_Shelness@motorcity2.lotus.com To: Keith Moore cc: drums@cs.utk.edu Message-ID: <8525691A.002AA70A.00@motorcity2.lotus.com> Date: Wed, 12 Jul 2000 08:46:25 +0100 Subject: Re: ABNF sets and sequences Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: Keith, As I tried to make clear in my first foray into this subject, ABNF defines the syntax of a notation that serves two distinct purposes: 1. it allows a human to determine whether a string is legal or illegal, and 2. it can be fed as a control string into a limited context automatic parser that will then report whether a string is legal or illegal. Though he didn't state this explicitly, Dave pointed out that there syntactic constructs for which these purposes are in conflict. To whit, in order to satisfy the second purpose, ABNF requires an unordered set of sub-strings to be notationaly expressed as: set = *( a / b / c ) which allows a, b, or c to appear in any order and any number of times from 0 to N. Syntactic (no semantics to be seen here) constraints on the number of occurrences of a, b, and c cannot be expressed. What a number of us have been attempting to do since Dave's initial note is to see if we can introduce an (extended) ABNF notation that will allow syntactic constraints on the number of occurrences of a, b, or c to be specified in a way that allows a human can easily determine whether a string formed from 0 or more occurrences of a, b, and c is legal or illegal. My feeling is that a notation (previously described) of the form: set = "{" 2*( *c-wsp member ) *c-wsp "}" member = ( rulename / "[" rulename "]" / [repeat] rulename satisfies these requirements. I.e., a human being can easily determine whether a set of strings satisfy the syntactic constraints of, for example: valid = { [ a ] b *c } a = "x" "y" b = "u" c = "v" What cannot be done, for reasons you stated most eloquently > note that for a parser to implement a rule like this it would > have to keep track of all sequences of symbols which had > matched 'name' within that rule, until the rule no longer > matched new input symbols....which requires an arbitrary > amount of state.. is to feed the above into an automatic limited context parser which would determine whether any presented string was legal or illegal. What almost certainly (without running code, who knows for sure) could be done in an (extended) ABNF syntax checker is to treat valid = { [ a ] b *c } as valid = * ( a / b / c ) for limited context parsing purposes, and then build an internal occurrences table that allowed the syntax checker to determine whether an input string satisfied or violated the occurrences constraints expressed in by the (extended) ABNF notation. So in conclusion, in order to proceed, we need to answer two questions with rough consensus. 1. Can we and have we come up with an (extended) ABNF notation that allows us to express occurrences constraints on an unordered set of sub-strings, such that the vast majority of human readers is easily able to determine whether a string formed from a sequence of sub-strings is legal or illegal? 2. Are we willing to relax the constraint that all valid ABNF grammars can be fed as a control string into a limited context automatic parser for the purpose of determining whether a presented string is legal or not? My answer is yes and yes. Nick Nick Shelness, IBM Fellow Chief Technology Officer Lotus Development Corp Tel: (617) 693-7484 Assistant: Mary McGurran Tel: (617) 693-4321 From owner-drums@cs.utk.edu Wed Jul 12 07:36:46 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17046 for ; Wed, 12 Jul 2000 07:36:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA16142; Wed, 12 Jul 2000 07:36:11 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 12 Jul 2000 07:36:03 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id HAA16116; Wed, 12 Jul 2000 07:36:03 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id HAA16092; Wed, 12 Jul 2000 07:36:01 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 12 Jul 2000 07:36:01 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id HAA08035; Wed, 12 Jul 2000 07:35:07 -0400 (EDT) Message-Id: <200007121135.HAA08035@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Nick_Shelness@motorcity2.lotus.com cc: Keith Moore , drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-reply-to: Your message of "Wed, 12 Jul 2000 08:46:25 BST." <8525691A.002AA70A.00@motorcity2.lotus.com> Date: Wed, 12 Jul 2000 07:35:06 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: Nick, one problem I have with the valid = { [ a ] b *c } notation is the use of [ ] and * to mean things that are actually quite different from the use of these symbols outside the { and }. while it's true that human languages often change the meaning of words or symbols based on subtle differences in context, a language like ABNF, intended for use in writing technical specifications, needs to be less ambiguous than that. especially when in practice it seems likely that there will be a need to use both kinds of * or [ ] in close proximity to one another. that, and I can't see any way, using the notation above, to say something like "you can define your own names for addiional parameters but none of these may appear more than once". as would presumably be the case for content-disposition parameters, content-type parameters, RFC 1894 per-recipient or per-message indicators, etc. now, we could pick different characters to mean "it's an error if this symbol is matched more than once within this rule" (say %) or "it is an error if this symbol does not match at least once within this rule" (say &). so we would then have header = *( %&to_field / %from_field / %sender_field / %subject_field / received_field ) but offhand I still don't see a way to specify "sender_field must be present if from_field is missing" with a notation like this. and I still find it both clearer, and more useful from an implementor's point-of-view, to separate "parsing" from other kinds of syntax checking. Keith From owner-drums@cs.utk.edu Wed Jul 12 08:57:38 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20286 for ; Wed, 12 Jul 2000 08:57:38 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id IAA21061; Wed, 12 Jul 2000 08:57:01 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 12 Jul 2000 08:57:00 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id IAA21042; Wed, 12 Jul 2000 08:56:59 -0400 (EDT) Received: from lotus2.lotus.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id IAA21026; Wed, 12 Jul 2000 08:56:57 -0400 (EDT) From: Received: from lotus2.lotus.com (192.233.136.8 -> lotus2.lotus.com) by cs.utk.edu (smtpshim v1.0); Wed, 12 Jul 2000 08:56:57 -0400 Received: from internet1.lotus.com (internet1.lotus.com [9.95.4.235]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id IAA14886 for ; Wed, 12 Jul 2000 08:57:56 -0400 (EDT) Received: from motorcity2.lotus.com (motorcity2.lotus.com [9.95.19.177]) by internet1.lotus.com (8.9.3/8.9.3) with SMTP id IAA02864 for ; Wed, 12 Jul 2000 08:56:58 -0400 (EDT) Received: by motorcity2.lotus.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8525691A.00470E61 ; Wed, 12 Jul 2000 08:56:07 -0400 X-Lotus-FromDomain: NOTES@ALPHABETA Sender: Nick_Shelness@motorcity2.lotus.com To: Keith Moore cc: drums@cs.utk.edu Message-ID: <8525691A.00470E34.00@motorcity2.lotus.com> Date: Wed, 12 Jul 2000 13:56:35 +0100 Subject: Re: ABNF sets and sequences Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA20286 Keith, > one problem I have with the > > valid = { [ a ] b *c } > > notation is the use of [ ] and * to mean things that are actually > quite different from the use of these symbols outside the { and }. > > while it's true that human languages often change the meaning of > words or symbols based on subtle differences in context, a language > like ABNF, intended for use in writing technical specifications, needs > to be less ambiguous than that. especially when in practice it seems > likely that there will be a need to use both kinds of * or > [ ] in close proximity to one another. OK. I'm quite happy to replace "*" with let's say "+" within a set and drop square brackets in favor of angle brackets giving us a set defined as follows: set = "{" 2*( *c-wsp member ) *c-wsp "}" member = [repeatm] rulename / "<" rulename ">" repeatm = (*DIGIT "+" *DIGIT) > that, and I can't see any way, using the notation above, to say > something like "you can define your own names for additional parameters > but none of these may appear more than once". as would presumably > be the case for content-disposition parameters, content-type parameters, > RFC 1894 per-recipient or per-message indicators, etc. I agree that the above notation can't handle this. > now, we could pick different characters to mean "it's an error if > this symbol is matched more than once within this rule" (say %) or > "it is an error if this symbol does not match at least once within > this rule" (say &). so we would then have > > header = *( > %&to_field / > %from_field / > %sender_field / > %subject_field / > received_field > ) > > but offhand I still don't see a way to specify "sender_field must be > present if from_field is missing" with a notation like this. If we introduce a new type of alteration operator (say, "!") between rulenames within parens within a set to mean non-exclusive OR, then using my modified notation we could specify header = { to_field ( from_field ! sender_field ) < subject_field > +received_field } or using your notation header = *( %&to_field / %£( from_field ! %sender_field ) / %subject_field / received_field ) > and I still find it both clearer, and more useful from an implementor's > point-of-view, to separate "parsing" from other kinds of syntax checking. I don't disagree with you here. In my mind the issue has always been notational clarity to the reader, and I'm not sure despite the examples above, using "!", or to a lesser extent "+" in place of "*", "<" in place of "[" and ">" in place of "]" helps achieve this! At the same time, if we could find a clean or even elegant way of dealing with unordered sets notationaly, I think it would be a plus. Nick Nick Shelness, IBM Fellow Chief Technology Officer Lotus Development Corp Tel: (617) 693-7484 Assistant: Mary McGurran Tel: (617) 693-4321 From owner-drums@cs.utk.edu Wed Jul 12 09:33:44 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21754 for ; Wed, 12 Jul 2000 09:33:43 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA23178; Wed, 12 Jul 2000 09:33:17 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 12 Jul 2000 09:33:16 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA23161; Wed, 12 Jul 2000 09:33:16 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA23140; Wed, 12 Jul 2000 09:33:14 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 12 Jul 2000 09:33:14 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA10470; Wed, 12 Jul 2000 09:33:14 -0400 (EDT) Message-Id: <200007121333.JAA10470@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Nick Shelness/SSW/Lotus" cc: "Keith Moore , drums@cs.utk.edu Subject: Re: ABNF sets and sequences In-reply-to: Your message of "Wed, 12 Jul 2000 13:56:35 BST." Date: Wed, 12 Jul 2000 09:33:14 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: interesting ideas for notation. I'm all for increasing clarity to the reader, as long as we don't lose precision in doing so. There is a point (probably different points for different readers) at which additional notation does more harm than good. We may have already reached this with the current version of ABNF. If we do extend ABNF we need to find a very 'clean' notation for doing so if we hope to increase the clarity. I also think that there is a (somewhat surprising) tension between writing a spec so that the reader can understand what is intended and writing a spec so that different readers can accurately translate it into code that interoperates. each is surely important, but an optimization for one case may be detrimental to the other. Keith From owner-drums@cs.utk.edu Wed Jul 12 10:03:35 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23297 for ; Wed, 12 Jul 2000 10:03:34 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id KAA25529; Wed, 12 Jul 2000 10:03:05 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 12 Jul 2000 10:03:04 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id KAA25511; Wed, 12 Jul 2000 10:03:03 -0400 (EDT) Received: from lotus2.lotus.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id KAA25489; Wed, 12 Jul 2000 10:03:00 -0400 (EDT) From: Received: from lotus2.lotus.com (192.233.136.8 -> lotus2.lotus.com) by cs.utk.edu (smtpshim v1.0); Wed, 12 Jul 2000 10:03:00 -0400 Received: from internet1.lotus.com (internet1.lotus.com [9.95.4.235]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id KAA25149; Wed, 12 Jul 2000 10:03:57 -0400 (EDT) Received: from motorcity2.lotus.com (motorcity2.lotus.com [9.95.19.177]) by internet1.lotus.com (8.9.3/8.9.3) with SMTP id KAA17138; Wed, 12 Jul 2000 10:03:00 -0400 (EDT) Received: by motorcity2.lotus.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 8525691A.004D1AA1 ; Wed, 12 Jul 2000 10:02:10 -0400 X-Lotus-FromDomain: NOTES@ALPHABETA Sender: Nick_Shelness@motorcity2.lotus.com To: Keith Moore cc: drums@cs.utk.edu Message-ID: <8525691A.004D1A73.00@motorcity2.lotus.com> Date: Wed, 12 Jul 2000 15:02:55 +0100 Subject: Re: ABNF sets and sequences Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: Keith, I think that we are in almost total agreement > I'm all for increasing clarity to the reader, as long as we don't > lose precision in doing so. We absolutely cannot lose precision in this process. The only reason I am devoting the effort to it that I am is that I believe that we are in need of more rather than less syntactic precision, but this cannot be achieved if the cost involves a loss of clarity. > There is a point (probably different points for different readers) > at which additional notation does more harm than good. Agreed. > We may have already reached this with the current version of ABNF. I'm a bad judge of this as I'm very comfortable with ABNF's notational style. > If we do extend ABNF we need to find a very 'clean' notation for > doing so if we hope to increase the clarity. Agreed. > I also think that there is a (somewhat surprising) tension between > writing a spec so that the reader can understand what is intended > and writing a spec so that different readers can accurately translate > it into code that interoperates. In a previous life I was a production compiler implementor. My experience in this space is that while most experimental compilers employ automated parsers, almost all production compilers employ recursive descent. My gut feeling is that the same is true in this space. Translating set notation of the sort Dave, Robert and I are proposing into iterative case statements with associated booleans (checked on iteration exit) and counters checked on each case invocation is a pretty straight forward process! Heck, it can even be automated. > each is surely important, but an optimization for one case may be > detrimental to the other. Again, agreed. Nick Nick Shelness, IBM Fellow Chief Technology Officer Lotus Development Corp Tel: (617) 693-7484 Assistant: Mary McGurran Tel: (617) 693-4321 From owner-drums@cs.utk.edu Wed Jul 12 14:33:15 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07651 for ; Wed, 12 Jul 2000 14:33:14 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA18890; Wed, 12 Jul 2000 14:32:43 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 12 Jul 2000 14:32:41 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA18853; Wed, 12 Jul 2000 14:32:41 -0400 (EDT) Received: from khms.westfalen.de (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA18810; Wed, 12 Jul 2000 14:32:28 -0400 (EDT) Received: from khms.westfalen.de (62.158.129.68 -> p3E9E8144.dip.t-dialin.net) by cs.utk.edu (smtpshim v1.0); Wed, 12 Jul 2000 14:32:37 -0400 Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.12 #1) id 13CRJ1-0007jz-02 (Debian); Wed, 12 Jul 2000 20:32:23 +0200 Received: by khms.westfalen.de (CrossPoint v3.12d.kh5 R/C435); 12 Jul 2000 20:30:33 +0200 Date: 12 Jul 2000 19:39:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: drums@cs.utk.edu Message-ID: <7hiBWiPXw-B@khms.westfalen.de> In-Reply-To: <4.3.2.20000711173432.00c043e0@mail.bayarea.net> Subject: Re: ABNF sets and sequences X-Mailer: CrossPoint v3.12d.kh5 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <4.3.2.20000711173432.00c043e0@mail.bayarea.net> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 List-Unsubscribe: dcrocker@brandenburg.com (Dave Crocker) wrote on 11.07.00 in <4.3.2.20000711173432.00c043e0@mail.bayarea.net>: > With respect to draft-ietf-drums-msg-fmt-07.txt , there seems to be a > problem: > > >message = (fields / obs-fields) [CRLF body] > > > >fields = *(trace > > *(resent-date / > > resent-from / > > resent-sender / > > resent-to / > > resent-cc / > > resent-bcc / > > resent-id)) > > *(orig-date / > > from / > > sender / > > reply-to / > > to / > > cc / > > bcc / > > message-id / > > in-reply-to / > > references / > > subject / > > comments / > > keywords / > > optional-field) > > does NOT fully show the non-ordering that is cited in: > > >.... So from a programmer viewpoint 822bis is heading in exactly the > >right direction -- combine the *(a / b / c) unordered-list syntax with a > >table of additional restrictions. > > or did I miss something? Yes. You missed the enclosing *( ), or at least the implications thereof. > It looks as if, for example, the syntax requires trace information to > precede the From field. No. MfG Kai From owner-drums@cs.utk.edu Wed Jul 12 14:39:30 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07652 for ; Wed, 12 Jul 2000 14:33:14 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA18886; Wed, 12 Jul 2000 14:32:43 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 12 Jul 2000 14:32:41 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA18846; Wed, 12 Jul 2000 14:32:41 -0400 (EDT) Received: from khms.westfalen.de (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA18807; Wed, 12 Jul 2000 14:32:27 -0400 (EDT) Received: from khms.westfalen.de (62.158.129.68 -> p3E9E8144.dip.t-dialin.net) by cs.utk.edu (smtpshim v1.0); Wed, 12 Jul 2000 14:32:37 -0400 Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.12 #1) id 13CRJ1-0007jz-01 (Debian); Wed, 12 Jul 2000 20:32:23 +0200 Received: by khms.westfalen.de (CrossPoint v3.12d.kh5 R/C435); 12 Jul 2000 20:30:33 +0200 Date: 12 Jul 2000 19:33:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: drums@cs.utk.edu Message-ID: <7hiBWNaXw-B@khms.westfalen.de> In-Reply-To: <200007100439.AAA05463@astro.cs.utk.edu> Subject: Re: ABNF sets and sequences X-Mailer: CrossPoint v3.12d.kh5 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <4.3.2.20000709223011.00bfebf0@mail.bayarea.net> <200007100439.AAA05463@astro.cs.utk.edu> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 List-Unsubscribe: moore@cs.utk.edu (Keith Moore) wrote on 10.07.00 in <200007100439.AAA05463@astro.cs.utk.edu>: > you're trying to make a grammar do a job that it cannot do well. If you want to see what you have to do to the grammar concept to get stuff like that to work, have a look at the Algol68 report. I liked it, but it's not for the average reader, and it's hard to convert into a parser. And it is *a lot* more involved than the current proposal. OTOH, it can describe ordering constraints, uniqueness constraints, necessity of definition before reference, and so on. There's probably a reason why, to my knowledge, no language since has taken this approach. > for instance -and this is a fairly classic example - most programming > languages require that a variable be declared before it can be used. > it turns out that (if there are arbitrary number of possible variable > names) it is impossible to write a replacement grammar that enforces > this rule. That's not quite true, because the above did exactly that. It is however true if you mention the usual assumption that this is an 1:n replacement grammar, not an n:m replacement grammar. The latter is a much larger class. (And the above example goes against another implicit assumption, too - that the number of grammar rules is finite. In essence, A68 contains a grammar for constructing a grammar.) > doesn't make sense. you can't describe 822 with asn.1 You might try that with X.400, of course. MfG Kai From owner-drums@cs.utk.edu Thu Jul 13 07:59:30 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14398 for ; Thu, 13 Jul 2000 07:59:30 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA17812; Thu, 13 Jul 2000 07:58:55 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 13 Jul 2000 07:58:47 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id HAA17791; Thu, 13 Jul 2000 07:58:46 -0400 (EDT) Received: from sws5.ctd.ornl.gov (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA17778; Thu, 13 Jul 2000 07:58:46 -0400 (EDT) Received: from sws5.ctd.ornl.gov (160.91.68.105 -> sws5.ctd.ornl.gov) by cs.utk.edu (smtpshim v1.0); Thu, 13 Jul 2000 07:58:46 -0400 Received: (qmail 696029 invoked by uid 3995); 13 Jul 2000 11:58:50 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14701.44793.880695.414478@sws5.ctd.ornl.gov> Date: Thu, 13 Jul 2000 07:58:49 -0400 (EDT) From: Dave Sill To: drums@cs.utk.edu Subject: Message munging? X-Mailer: VM 6.75 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Organization: Oak Ridge National Lab, Oak Ridge, Tenn., USA X-Face: "p~Q]mg{;e*}YR|)&Q/&Q\*~5UWfZX34;5M Content-Transfer-Encoding: 7bit Is there anything in 821 or its proposed sucessor that prevents MTA's from arbitrarily munging messages? I couldn't find anything. This came up on the list-managers list when it was reported that AOL was replacing "<" in subjects with "<." to disable some potentially dangerous HTML-like extensions their mailer supports. This breaks a list subscription confirmation scheme that encloses magic cookies in angle brackets. -Dave From owner-drums@cs.utk.edu Fri Jul 14 07:39:14 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24017 for ; Fri, 14 Jul 2000 07:39:13 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA22670; Fri, 14 Jul 2000 07:38:25 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 14 Jul 2000 07:38:17 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id HAA22652; Fri, 14 Jul 2000 07:38:17 -0400 (EDT) Received: from sws5.ctd.ornl.gov (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA22639; Fri, 14 Jul 2000 07:38:16 -0400 (EDT) Received: from sws5.ctd.ornl.gov (160.91.68.105 -> sws5.ctd.ornl.gov) by cs.utk.edu (smtpshim v1.0); Fri, 14 Jul 2000 07:38:16 -0400 Received: (qmail 724814 invoked by uid 3995); 14 Jul 2000 11:38:21 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14702.64429.581693.268652@sws5.ctd.ornl.gov> Date: Fri, 14 Jul 2000 07:38:21 -0400 (EDT) From: Dave Sill To: drums@cs.utk.edu Subject: Re: Message munging? In-Reply-To: <14701.44793.880695.414478@sws5.ctd.ornl.gov> References: <14701.44793.880695.414478@sws5.ctd.ornl.gov> X-Mailer: VM 6.75 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Organization: Oak Ridge National Lab, Oak Ridge, Tenn., USA X-Face: "p~Q]mg{;e*}YR|)&Q/&Q\*~5UWfZX34;5M Content-Transfer-Encoding: 7bit I wrote: >Is there anything in 821 or its proposed sucessor that prevents MTA's >from arbitrarily munging messages? I couldn't find anything. > >This came up on the list-managers list when it was reported that AOL >was replacing "<" in subjects with "<." to disable some potentially >dangerous HTML-like extensions their mailer supports. This breaks a >list subscription confirmation scheme that encloses magic cookies in >angle brackets. I've received no responses. If this is stupid question, please enlighten me. -Dave From owner-drums@cs.utk.edu Fri Jul 14 09:12:53 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20647 for ; Fri, 14 Jul 2000 09:12:53 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA27819; Fri, 14 Jul 2000 09:12:15 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 14 Jul 2000 09:12:07 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA27741; Fri, 14 Jul 2000 09:12:06 -0400 (EDT) Received: from draco.cus.cam.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA27728; Fri, 14 Jul 2000 09:12:04 -0400 (EDT) Received: from draco.cus.cam.ac.uk (131.111.8.18 -> draco.cus.cam.ac.uk) by cs.utk.edu (smtpshim v1.0); Fri, 14 Jul 2000 09:12:04 -0400 Received: from ph10 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 3.15 #3) id 13D5GB-0000ee-00; Fri, 14 Jul 2000 14:12:07 +0100 Date: Fri, 14 Jul 2000 14:12:07 +0100 (BST) From: Philip Hazel To: Dave Sill cc: drums@cs.utk.edu Subject: Re: Message munging? In-Reply-To: <14702.64429.581693.268652@sws5.ctd.ornl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: On Fri, 14 Jul 2000, Dave Sill wrote: > >Is there anything in 821 or its proposed sucessor that prevents MTA's > >from arbitrarily munging messages? I couldn't find anything. > > > >This came up on the list-managers list when it was reported that AOL > >was replacing "<" in subjects with "<." to disable some potentially > >dangerous HTML-like extensions their mailer supports. This breaks a > >list subscription confirmation scheme that encloses magic cookies in > >angle brackets. > > I've received no responses. If this is stupid question, please > enlighten me. The RFCs are all about interworking, that is, how to transfer a message over the Internet. They don't say anything about what an MTA may or may not do in the privacy of its own host. -- Philip Hazel University of Cambridge Computing Service, ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. From owner-drums@cs.utk.edu Fri Jul 14 09:34:24 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25455 for ; Fri, 14 Jul 2000 09:34:24 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA29878; Fri, 14 Jul 2000 09:34:03 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 14 Jul 2000 09:34:02 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA29859; Fri, 14 Jul 2000 09:34:01 -0400 (EDT) Received: from sws5.ctd.ornl.gov (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA29842; Fri, 14 Jul 2000 09:34:00 -0400 (EDT) Received: from sws5.ctd.ornl.gov (160.91.68.105 -> sws5.ctd.ornl.gov) by cs.utk.edu (smtpshim v1.0); Fri, 14 Jul 2000 09:34:00 -0400 Received: (qmail 727807 invoked by uid 3995); 14 Jul 2000 13:34:05 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14703.5836.586133.146450@sws5.ctd.ornl.gov> Date: Fri, 14 Jul 2000 09:34:04 -0400 (EDT) From: Dave Sill To: drums@cs.utk.edu Subject: Re: Message munging? In-Reply-To: References: <14702.64429.581693.268652@sws5.ctd.ornl.gov> X-Mailer: VM 6.75 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Organization: Oak Ridge National Lab, Oak Ridge, Tenn., USA X-Face: "p~Q]mg{;e*}YR|)&Q/&Q\*~5UWfZX34;5M Content-Transfer-Encoding: 7bit Philip Hazel wrote: > >The RFCs are all about interworking, that is, how to transfer a message >over the Internet. They don't say anything about what an MTA may or may >not do in the privacy of its own host. I understand that 821 only covers message transfer between hosts, and that hosts can do what they want once the message is received, but does it not provide any guarantee that a message leaving one host bears a resemblence to the message received by another? So if Microsoft Exchange replaced all occurrences of the string "Winblows" with "Windows"--even for messages it's only relaying--that wouldn't violate any RFC's? Strange. Outside of the question of RFC-legality, what do people think of AOL's Subject rewriting ("<" replaced with "<.") as a solution to their problem? -Dave From owner-drums@cs.utk.edu Fri Jul 14 10:00:21 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03463 for ; Fri, 14 Jul 2000 10:00:21 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA02067; Fri, 14 Jul 2000 09:59:50 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 14 Jul 2000 09:59:49 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA02048; Fri, 14 Jul 2000 09:59:48 -0400 (EDT) Received: from draco.cus.cam.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA02030; Fri, 14 Jul 2000 09:59:46 -0400 (EDT) Received: from draco.cus.cam.ac.uk (131.111.8.18 -> draco.cus.cam.ac.uk) by cs.utk.edu (smtpshim v1.0); Fri, 14 Jul 2000 09:59:46 -0400 Received: from ph10 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 3.15 #3) id 13D60M-0001yC-00; Fri, 14 Jul 2000 14:59:50 +0100 Date: Fri, 14 Jul 2000 14:59:50 +0100 (BST) From: Philip Hazel To: Dave Sill cc: drums@cs.utk.edu Subject: Re: Message munging? In-Reply-To: <14703.5836.586133.146450@sws5.ctd.ornl.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: On Fri, 14 Jul 2000, Dave Sill wrote: > I understand that 821 only covers message transfer between hosts, and > that hosts can do what they want once the message is received, but > does it not provide any guarantee that a message leaving one host > bears a resemblence to the message received by another? So if > Microsoft Exchange replaced all occurrences of the string "Winblows" > with "Windows"--even for messages it's only relaying--that wouldn't > violate any RFC's? Strange. Ah well, that depends on what you mean by "relaying". The new draft for 821bis says: 2.3.8 Originator, Delivery, Relay, and Gateway Systems This specification makes a distinction among four types of SMTP systems, based on the role those systems play in transmitting electronic mail. An "originating" system (sometimes called an SMTP originator) introduces mail into the Internet or, more generally, into a transport service environment. A "delivery" SMTP system is one that receives mail from a transport service environment and passes it to a mail user agent or deposits it in a message store which a mail user agent is expected to subsequently access. A "relay" SMTP system (usually referred to just as a "relay") receives mail from an SMTP client and transmits it, without modification to the message data other than adding trace information, to another SMTP server for further relaying or for delivery. A "gateway" SMTP system (usually referred to just as a "gateway") receives mail from a client system in one transport environment and transmits it to a server system in another transport environment. Differences in protocols or message semantics between the transport environments on either side of a gateway may require that the gateway system perform transformations to the message that are not permitted to SMTP relay systems. For the purposes of this specification, firewalls that rewrite addresses should be considered as gateways, even if SMTP is used on both sides of them. That is, if a system is "relaying", it must not modify the message. But who declares that a particular host is a "relay"? I think this is a post hoc thing: IF a host receives messages AND transmits them without modification THEN it is a relay. Otherwise it's a gateway. Sounds like AOL is a gateway in this terminology. > Outside of the question of RFC-legality, what do people think of AOL's > Subject rewriting ("<" replaced with "<.") as a solution to their > problem? It's crap, of course. -- Philip Hazel University of Cambridge Computing Service, ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. From owner-drums@cs.utk.edu Fri Jul 14 10:02:16 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04175 for ; Fri, 14 Jul 2000 10:02:15 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id KAA02394; Fri, 14 Jul 2000 10:01:51 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 14 Jul 2000 10:01:51 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id KAA02377; Fri, 14 Jul 2000 10:01:50 -0400 (EDT) Received: from styx.viaginterkom.de (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id KAA02363; Fri, 14 Jul 2000 10:01:47 -0400 (EDT) From: Received: from styx.viaginterkom.de (62.180.31.12 -> styx.viaginterkom.de) by cs.utk.edu (smtpshim v1.0); Fri, 14 Jul 2000 10:01:48 -0400 Received: (qmail 17800 invoked by uid 0); 14 Jul 2000 14:01:52 -0000 Received: from unknown (HELO muc8lx01.viaginterkom.de) (unknown) by unknown with SMTP; 14 Jul 2000 14:01:52 -0000 Received: by muc8lx01.viaginterkom.de(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id C125691C.004D10D8 ; Fri, 14 Jul 2000 16:01:45 +0200 X-Lotus-FromDomain: VIAGINTERKOM To: Dave Sill cc: drums@cs.utk.edu Message-ID: Date: Fri, 14 Jul 2000 16:01:32 +0200 Subject: Antwort: Re: Message munging? Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=9iNonzmOPL75BNIt6bOiTZmVW4Rcxh6LhFUkimyTbamcdrFrscbh8WdO" Content-Disposition: inline List-Unsubscribe: --0__=9iNonzmOPL75BNIt6bOiTZmVW4Rcxh6LhFUkimyTbamcdrFrscbh8WdO Content-type: text/plain; charset=us-ascii Content-Disposition: inline It is some time ago, that I have read RFC 821, but the data transfer mechanism specifies, that the 'message received OK' response (in reality it has a different name and some number code), may only be send by the receiving side, when it has successfully recieved the whole message. Due to the store and forward nature of the SMTP protocol, data (messages) can only get lost, unrecognized by the ultimate message sink/source, on intermediate mailers (MTAs), that crash and loose data. Bernhard Garmann Dave Sill am 14.07.2000 15:34:04 An: drums@cs.utk.edu Kopie: (Blindkopie: Bernhard Garmann/EXTERN/VIAGInterkom) Thema: Re: Message munging? Philip Hazel wrote: > >The RFCs are all about interworking, that is, how to transfer a message >over the Internet. They don't say anything about what an MTA may or may >not do in the privacy of its own host. I understand that 821 only covers message transfer between hosts, and that hosts can do what they want once the message is received, but does it not provide any guarantee that a message leaving one host bears a resemblence to the message received by another? So if Microsoft Exchange replaced all occurrences of the string "Winblows" with "Windows"--even for messages it's only relaying--that wouldn't violate any RFC's? Strange. Outside of the question of RFC-legality, what do people think of AOL's Subject rewriting ("<" replaced with "<.") as a solution to their problem? -Dave --0__=9iNonzmOPL75BNIt6bOiTZmVW4Rcxh6LhFUkimyTbamcdrFrscbh8WdO Content-type: application/octet-stream; name="att1.eml" Content-Disposition: attachment; filename="att1.eml" Content-Transfer-Encoding: base64 UmVjZWl2ZWQ6IGZyb20gbWFpbHNlcnZlcjEudmlhZ2ludGVya29tLmRlIChbNjIuMTgwLjMxLjEw XSkgYnkgbXVjOGx4MDIudmlhZ2ludGVya29tLmRlIChMb3R1cyBTTVRQIE1UQSB2NC42LjMgKDc3 OC4yIDEtNC0xOTk5KSkgd2l0aCBTTVRQIGlkIEMxMjU2OTFDLjAwNEI0NEFDOyBGcmksIDE0IEp1 bCAyMDAwIDE1OjQyOjA3ICswMjAwDQpSZWNlaXZlZDogKHFtYWlsIDI1MjQgaW52b2tlZCBieSB1 aWQgMCk7IDE0IEp1bCAyMDAwIDEzOjQyOjA3IC0wMDAwDQpSZWNlaXZlZDogZnJvbSB1bmtub3du IChIRUxPIGNzLnV0ay5lZHUpICh1bmtub3duKQ0KICBieSB1bmtub3duIHdpdGggU01UUDsgMTQg SnVsIDIwMDAgMTM6NDI6MDcgLTAwMDANClJlY2VpdmVkOiBmcm9tIGxvY2FsaG9zdCAoZGFlbW9u QGxvY2FsaG9zdCkgDQogICAgICAgIGJ5IGNzLnV0ay5lZHUgd2l0aCBTTVRQIChjZiB2Mi45cy1V VEspDQoJaWQgSkFBMjk4NzM7IEZyaSwgMTQgSnVsIDIwMDAgMDk6MzQ6MDIgLTA0MDAgKEVEVCkN ClJlY2VpdmVkOiBieSBjcy51dGsuZWR1IChidWxrX21haWxlciB2MS4xMyk7IEZyaSwgMTQgSnVs IDIwMDAgMDk6MzQ6MDIgLTA0MDANClJlY2VpdmVkOiAgDQogICAgICAgIGJ5IGNzLnV0ay5lZHUg KGNmIHYyLjlzLVVUSykNCglpZCBKQUEyOTg1OTsgRnJpLCAxNCBKdWwgMjAwMCAwOTozNDowMSAt MDQwMCAoRURUKQ0KUmVjZWl2ZWQ6IGZyb20gc3dzNS5jdGQub3JubC5nb3YgKG1hcnZpbkBsb2Nh bGhvc3QpIA0KICAgICAgICBieSBjcy51dGsuZWR1IHdpdGggU01UUCAoY2YgdjIuOXMtVVRLKQ0K CWlkIEpBQTI5ODQyOyBGcmksIDE0IEp1bCAyMDAwIDA5OjM0OjAwIC0wNDAwIChFRFQpDQpSZWNl aXZlZDogZnJvbSBzd3M1LmN0ZC5vcm5sLmdvdiAoMTYwLjkxLjY4LjEwNSAtPiBzd3M1LmN0ZC5v cm5sLmdvdikNCiBieSBjcy51dGsuZWR1IChzbXRwc2hpbSB2MS4wKTsgRnJpLCAxNCBKdWwgMjAw MCAwOTozNDowMCAtMDQwMA0KUmVjZWl2ZWQ6IChxbWFpbCA3Mjc4MDcgaW52b2tlZCBieSB1aWQg Mzk5NSk7IDE0IEp1bCAyMDAwIDEzOjM0OjA1IC0wMDAwDQpNSU1FLVZlcnNpb246IDEuMA0KQ29u dGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PXVzLWFzY2lpDQpDb250ZW50LVRyYW5zZmVy LUVuY29kaW5nOiA3Yml0DQpNZXNzYWdlLUlEOiA8MTQ3MDMuNTgzNi41ODYxMzMuMTQ2NDUwQHN3 czUuY3RkLm9ybmwuZ292Pg0KRGF0ZTogRnJpLCAxNCBKdWwgMjAwMCAwOTozNDowNCAtMDQwMCAo RURUKQ0KRnJvbTogRGF2ZSBTaWxsIDxkZTUtZHJ1bXNAc3dzNS5jdGQub3JubC5nb3Y+DQpUbzog ZHJ1bXNAY3MudXRrLmVkdQ0KU3ViamVjdDogUmU6IE1lc3NhZ2UgbXVuZ2luZz8NCkluLVJlcGx5 LVRvOiA8UGluZS5TT0wuNC4yMS4wMDA3MTQxNDA4MTAwLjI5Njk4LTEwMDAwMEBkcmFjby5jdXMu Y2FtLmFjLnVrPg0KUmVmZXJlbmNlczogPDE0NzAyLjY0NDI5LjU4MTY5My4yNjg2NTJAc3dzNS5j dGQub3JubC5nb3Y+DQoJPFBpbmUuU09MLjQuMjEuMDAwNzE0MTQwODEwMC4yOTY5OC0xMDAwMDBA ZHJhY28uY3VzLmNhbS5hYy51az4NClgtTWFpbGVyOiBWTSA2Ljc1IHVuZGVyIDIxLjEgIjIwIE1p bnV0ZXMgdG8gTmlra28iIFhFbWFjcyBMdWNpZCAocGF0Y2ggMikNCk9yZ2FuaXphdGlvbjogT2Fr IFJpZGdlIE5hdGlvbmFsIExhYiwgT2FrIFJpZGdlLCBUZW5uLiwgVVNBDQpYLUZhY2U6ICJwflFd bWd7O2UqfVlSfCkmUS8mUVwqfjVVV2ZaWDM0OzVNPGdIeXEwS3ZHdDwkcWk2PUI3OyQzfjFwP0pj Ny1nPzF2UFZBYyVZWCRFNl0lMWp2azosImYqakF8P35DeGI/V0o1Z3R9TD9xc01BalJPTX5ySGJL Mjd5eD10LEwvP0lIYjhAfGNZZzgiWSl+MElwVX5KLl53LFZXKXU/TTNxLUFTe2ZgQFJaXVdsbA0K WC1EaXNjbGFpbWVyOiBNeSBvcGluaW9ucyBkbyBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50IHRo b3NlIG9mIG15IGVtcGxveWVyDQpMaXN0LVVuc3Vic2NyaWJlOiA8bWFpbHRvOmRydW1zLXJlcXVl c3RAY3MudXRrLmVkdT9TdWJqZWN0PXVuc3Vic2NyaWJlPg0KWC1TcGFtLVJhdGluZzogdW5rbm93 biAxLjYuMiAwLzEwMDAvTg0KDQpQaGlsaXAgSGF6ZWwgPHBoMTBAY3VzLmNhbS5hYy51az4gd3Jv dGU6DQo+DQo+VGhlIFJGQ3MgYXJlIGFsbCBhYm91dCBpbnRlcndvcmtpbmcsIHRoYXQgaXMsIGhv dyB0byB0cmFuc2ZlciBhIG1lc3NhZ2UNCj5vdmVyIHRoZSBJbnRlcm5ldC4gVGhleSBkb24ndCBz YXkgYW55dGhpbmcgYWJvdXQgd2hhdCBhbiBNVEEgbWF5IG9yIG1heSANCj5ub3QgZG8gaW4gdGhl IHByaXZhY3kgb2YgaXRzIG93biBob3N0Lg0KDQpJIHVuZGVyc3RhbmQgdGhhdCA4MjEgb25seSBj b3ZlcnMgbWVzc2FnZSB0cmFuc2ZlciBiZXR3ZWVuIGhvc3RzLCBhbmQNCnRoYXQgaG9zdHMgY2Fu IGRvIHdoYXQgdGhleSB3YW50IG9uY2UgdGhlIG1lc3NhZ2UgaXMgcmVjZWl2ZWQsIGJ1dA0KZG9l cyBpdCBub3QgcHJvdmlkZSBhbnkgZ3VhcmFudGVlIHRoYXQgYSBtZXNzYWdlIGxlYXZpbmcgb25l IGhvc3QNCmJlYXJzIGEgcmVzZW1ibGVuY2UgdG8gdGhlIG1lc3NhZ2UgcmVjZWl2ZWQgYnkgYW5v dGhlcj8gU28gaWYNCk1pY3Jvc29mdCBFeGNoYW5nZSByZXBsYWNlZCBhbGwgb2NjdXJyZW5jZXMg b2YgdGhlIHN0cmluZyAiV2luYmxvd3MiDQp3aXRoICJXaW5kb3dzIi0tZXZlbiBmb3IgbWVzc2Fn ZXMgaXQncyBvbmx5IHJlbGF5aW5nLS10aGF0IHdvdWxkbid0DQp2aW9sYXRlIGFueSBSRkMncz8g U3RyYW5nZS4NCg0KT3V0c2lkZSBvZiB0aGUgcXVlc3Rpb24gb2YgUkZDLWxlZ2FsaXR5LCB3aGF0 IGRvIHBlb3BsZSB0aGluayBvZiBBT0wncw0KU3ViamVjdCByZXdyaXRpbmcgKCI8IiByZXBsYWNl ZCB3aXRoICI8LiIpIGFzIGEgc29sdXRpb24gdG8gdGhlaXINCnByb2JsZW0/DQoNCi1EYXZlDQo= --0__=9iNonzmOPL75BNIt6bOiTZmVW4Rcxh6LhFUkimyTbamcdrFrscbh8WdO-- From owner-drums@cs.utk.edu Fri Jul 14 12:08:07 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14565 for ; Fri, 14 Jul 2000 12:08:06 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA15506; Fri, 14 Jul 2000 12:07:44 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 14 Jul 2000 12:07:43 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA15488; Fri, 14 Jul 2000 12:07:42 -0400 (EDT) Received: from mail-blue.research.att.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA15467; Fri, 14 Jul 2000 12:07:40 -0400 (EDT) Received: from mail-blue.research.att.com (135.207.30.102 -> mail-blue.research.att.com) by cs.utk.edu (smtpshim v1.0); Fri, 14 Jul 2000 12:07:41 -0400 Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id EE7AA4CE1C; Fri, 14 Jul 2000 12:07:45 -0400 (EDT) Received: from 192.168.2.162 (secure.research.att.com [135.207.25.14]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id MAA20696; Fri, 14 Jul 2000 12:07:43 -0400 (EDT) Date: Fri, 14 Jul 2000 11:45:31 -0400 From: John C Klensin To: Philip Hazel , Dave Sill Cc: drums@cs.utk.edu Subject: Re: Message munging? Message-ID: <1502457206.963575131@[192.168.2.162]> In-Reply-To: X-Mailer: Mulberry/2.0.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Friday, July 14, 2000 2:59 PM +0100 Philip Hazel wrote: >... > That is, if a system is "relaying", it must not modify the > message. But who declares that a particular host is a "relay"? > I think this is a post hoc thing: IF a host receives messages > AND transmits them without modification THEN it is a relay. > Otherwise it's a gateway. Sounds like AOL is a gateway in this > terminology. It is a little tighter than that although arguably not much. If I have a boundary, with an Internet and Internet mail environment on one side and some "other" stuff (e.g., private transport protocols, a private address space one is trying to use to hide information, and/or a proprietary mail system on the other side) then the "gateway" rules clearly apply. AOL, as I understand it, meets several of those criteria so, while what they are doing is arguably in lousy taste, it isn't prohibited by the standards. Personally, I would love to prohibit it (and I suspect most of DRUMS would as well), but I believe it is nearly impossible to write rules that would make their behavior protocol-invalid while permitting more traditional gateways into other sorts of mail systems (e.g., UUCP mail as well as proprietary ones) to work in a way generally believed to be acceptable and conforming. And, of course, if we were to put the effort into constructing such a rule, AOL would almost certainly ignore it, since what they are doing makes market sense to them and "works" as they and the overwhelming number of their users define that term. If one doesn't like that, the best option is to try to convince a large fraction of their users that they actually don't like the behavior and are willing to move on if AOL doesn't fix it. If one could do that, I'd predict a quick change of course from them. The odds, however, are not good. > It's crap, of course. Yes, that about covers it. Put more politely, working around what is apparently a piece of sloppy implementation work with a nasty, user-visible kludge is never anything of which one should be proud. john From owner-drums@cs.utk.edu Fri Jul 14 14:09:09 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24440 for ; Fri, 14 Jul 2000 14:09:08 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA26705; Fri, 14 Jul 2000 14:08:41 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 14 Jul 2000 14:08:38 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA26687; Fri, 14 Jul 2000 14:08:38 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA26671; Fri, 14 Jul 2000 14:08:36 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Fri, 14 Jul 2000 14:08:36 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA27006; Fri, 14 Jul 2000 14:08:42 -0400 (EDT) Message-Id: <200007141808.OAA27006@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Sill cc: drums@cs.utk.edu Subject: Re: Message munging? In-reply-to: Your message of "Fri, 14 Jul 2000 09:34:04 EDT." <14703.5836.586133.146450@sws5.ctd.ornl.gov> Date: Fri, 14 Jul 2000 14:08:42 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > I understand that 821 only covers message transfer between hosts, and > that hosts can do what they want once the message is received, but > does it not provide any guarantee that a message leaving one host > bears a resemblence to the message received by another? perhaps not. it doesn't tell you not to shoot yourself either. sometimes obvious things are left unspecified. Keith From owner-drums@cs.utk.edu Fri Jul 14 15:03:19 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12683 for ; Fri, 14 Jul 2000 15:03:19 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA02342; Fri, 14 Jul 2000 15:02:56 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 14 Jul 2000 15:02:55 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA02325; Fri, 14 Jul 2000 15:02:55 -0400 (EDT) Received: from sws5.ctd.ornl.gov (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA02312; Fri, 14 Jul 2000 15:02:54 -0400 (EDT) Received: from sws5.ctd.ornl.gov (160.91.68.105 -> sws5.ctd.ornl.gov) by cs.utk.edu (smtpshim v1.0); Fri, 14 Jul 2000 15:02:54 -0400 Received: (qmail 736018 invoked by uid 3995); 14 Jul 2000 19:03:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14703.25571.794656.257130@sws5.ctd.ornl.gov> Date: Fri, 14 Jul 2000 15:02:59 -0400 (EDT) From: Dave Sill To: drums@cs.utk.edu Subject: Re: Message munging? In-Reply-To: <200007141808.OAA27006@astro.cs.utk.edu> References: <14703.5836.586133.146450@sws5.ctd.ornl.gov> <200007141808.OAA27006@astro.cs.utk.edu> X-Mailer: VM 6.75 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Organization: Oak Ridge National Lab, Oak Ridge, Tenn., USA X-Face: "p~Q]mg{;e*}YR|)&Q/&Q\*~5UWfZX34;5M Content-Transfer-Encoding: 7bit Keith Moore wrote: >> I understand that 821 only covers message transfer between hosts, and >> that hosts can do what they want once the message is received, but >> does it not provide any guarantee that a message leaving one host >> bears a resemblence to the message received by another? > >perhaps not. it doesn't tell you not to shoot yourself either. Right, but if I do that, mail won't be affected. >sometimes obvious things are left unspecified. Yeah, but it seems a little odd to spend years hashing out the minutiae when something as fundamental as message integrity isn't even specified. But I do realize it's a sticky subject and not something DRUMS should try to fix. But when some 800-pound gorilla starts munging messages, it's a lot better to be able to point at an RFC than to tell them that what they're doing is so obviously wrong that it wasn't specified--and, hence, isn't illegal. Not that the gorilla would care, though... -Dave From owner-drums@cs.utk.edu Fri Jul 14 15:16:21 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17569 for ; Fri, 14 Jul 2000 15:16:20 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA04262; Fri, 14 Jul 2000 15:15:57 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 14 Jul 2000 15:15:55 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA04239; Fri, 14 Jul 2000 15:15:55 -0400 (EDT) Received: from serenity.mcc.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA04213; Fri, 14 Jul 2000 15:15:51 -0400 (EDT) Received: from serenity.mcc.ac.uk (130.88.200.93 -> serenity.mcc.ac.uk) by cs.utk.edu (smtpshim v1.0); Fri, 14 Jul 2000 15:15:51 -0400 Received: from nessie.mcc.ac.uk ([130.88.200.20] ident=root) by serenity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 13DAwG-0005ts-00 for drums@cs.utk.edu; Fri, 14 Jul 2000 20:15:56 +0100 Received: from clw.cs.man.ac.uk (clerew.man.ac.uk [194.66.22.208]) by nessie.mcc.ac.uk (8.9.3/8.8.8) with ESMTP id UAA67192 for ; Fri, 14 Jul 2000 20:15:53 +0100 (BST) (envelope-from root@clw.cs.man.ac.uk) Received: (from root@localhost) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) id TAA28519 for drums@cs.utk.edu; Fri, 14 Jul 2000 19:04:01 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) with SMTP id TAA28516 for ; Fri, 14 Jul 2000 19:04:00 +0100 (BST) Message-Id: <200007141804.TAA28516@clw.cs.man.ac.uk> Date: Fri, 14 Jul 2000 19:04:00 +0100 (BST) From: Charles Lindsey Reply-To: Charles Lindsey Subject: Re: Message munging? To: drums@cs.utk.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VdF/0NLjoADnwf6Vl6flsA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc List-Unsubscribe: On Fri, 14 Jul 2000 14:59:50 +0100 (BST) Philip Hazel said... > Ah well, that depends on what you mean by "relaying". The new draft for > 821bis says: > > 2.3.8 Originator, Delivery, Relay, and Gateway Systems Yes, the new draft for usenet article formats (of which I am the Editor) makes a similar distinction, the equivalent terms being injector, server, relayer and gateway Relayers are absolutely forbidden to munge anything (bar Path header), with the intention that every copy of the article worldwide will be identical. Gateways are expected to do the minimum necessary to get them to work (there are various restriction specified, mainly to prevent looping). The assumption with regard to injectors and servers is that they are near enough to those to whom they provide service that they can be "leant on" by their users if they try to be too stupid. It is also useful that, in newsgroups, there are far more readers than writers, so any stupidity will rapidly be noticed and commented on (as is happeniong with certain practices by remarq). And there is a general principle that if you don't like something passing through your system, then you may drop it on the floor, but you do not change it. > Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-drums@cs.utk.edu Fri Jul 14 17:32:42 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28093 for ; Fri, 14 Jul 2000 17:32:42 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA16441; Fri, 14 Jul 2000 17:32:21 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 14 Jul 2000 17:32:19 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA16423; Fri, 14 Jul 2000 17:32:18 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA16407; Fri, 14 Jul 2000 17:32:17 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Fri, 14 Jul 2000 17:32:17 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA01379; Fri, 14 Jul 2000 17:32:23 -0400 (EDT) Message-Id: <200007142132.RAA01379@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Sill cc: drums@cs.utk.edu Subject: Re: Message munging? In-reply-to: Your message of "Fri, 14 Jul 2000 15:02:59 EDT." <14703.25571.794656.257130@sws5.ctd.ornl.gov> Date: Fri, 14 Jul 2000 17:32:23 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > >> I understand that 821 only covers message transfer between hosts, and > >> that hosts can do what they want once the message is received, but > >> does it not provide any guarantee that a message leaving one host > >> bears a resemblence to the message received by another? > > > >perhaps not. it doesn't tell you not to shoot yourself either. > > Right, but if I do that, mail won't be affected. depends on which MTA you're running. :) > >sometimes obvious things are left unspecified. > > Yeah, but it seems a little odd to spend years hashing out the > minutiae when something as fundamental as message integrity isn't even > specified. But I do realize it's a sticky subject and not something > DRUMS should try to fix. for what it's worth, the BINARYMIME SMTP extension does specify rules for message integrity. 821bis could quite reasonably adopt similar rules, but gorillas will always be able to get around the rules by claiming that they're operating gateways rather than relaying MTAs. > But when some 800-pound gorilla starts munging messages, it's a lot > better to be able to point at an RFC than to tell them that what > they're doing is so obviously wrong that it wasn't specified--and, > hence, isn't illegal. > > Not that the gorilla would care, though... I suspect that the gorilla already knows that it's doing bad things, and that there are better ways to fix the problem, but it would rather gather more bananas. Keith From owner-drums@cs.utk.edu Wed Jul 19 00:10:18 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12152 for ; Wed, 19 Jul 2000 00:10:17 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA18559; Wed, 19 Jul 2000 00:09:39 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 19 Jul 2000 00:09:18 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA18532; Wed, 19 Jul 2000 00:09:18 -0400 (EDT) Received: from NOD.RESTON.MCI.NET (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA18517; Wed, 19 Jul 2000 00:09:14 -0400 (EDT) Received: from NOD.RESTON.MCI.NET (166.60.6.38) by cs.utk.edu (smtpshim v1.0); Wed, 19 Jul 2000 00:09:15 -0400 Received: from dhcp-033209.tc-conference.inet2000.gr.jp ([133.195.33.209]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTPA id <01JRXJHAYTMI9N44ES@shoe.reston.mci.net> for drums@cs.utk.edu; Wed, 19 Jul 2000 00:09:08 EST Date: Wed, 19 Jul 2000 00:07:40 -0400 From: John C Klensin Subject: Re: mail-abuse.org tests, and weird addresses... In-reply-to: <200007181832.e6IIWUY25908@black-ice.cc.vt.edu> To: Valdis.Kletnieks@vt.edu Cc: Kyle Jones , sendmail-beta@sendmail.org, ietf-smtp@imc.org, drums@cs.utk.edu Message-id: <1892586626.963965260@dhcp-033209.tc-conference.inet2000.gr.jp> MIME-version: 1.0 X-Mailer: Mulberry/2.0.3 (Win32) Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT List-Unsubscribe: Content-Transfer-Encoding: 7BIT --On Tuesday, July 18, 2000 2:32 PM -0400 Valdis.Kletnieks@vt.edu wrote: > (Am cc'ing the IETF-SMTP list, hopefully it's alive and > somebody there will have guidance on this... For the IETF-SMTP > list, the discussion is what to properly do if handed this > during an SMTP transaction: > > MAIL FROM: > > Sendmail currently issues a '250 OK'. >... [more of original message below]... Hi. If my memory is correct, 501 (syntax error) is intended, as was the exclusion of 553 from the MAIL FROM responses. I agree that the 1123 text is a little muddy (and it is probably at least partially my fault). Please take a look at draft-ietf-drums-smtpupd-12.txt and see if you think it is clear and good enough; if not, comments should probably go to the DRUMS list (copied on this response). I would think that 553 would be used for a situation in which, e.g., the left-hand-side (local-part) of an address was valid syntax in 821 (etc) terms, but invalid for processing/ delivery on the target host while 501 would be used for things that were lexically unacceptable given the 821 grammar. If that were the theory, then a receiving SMTP wouldn't be able to comment on the sender's local part (in MAIL FROM) as long as it obeyed the 821 syntax. But, again, a receiving host could evaluate a local-part syntax against its own rules. For example, assume my host receives RCPT TO: Almost no one has mailbox names that look like that, so bouncing it with a 553 would be reasonable. Bouncing it with 501 would be less so, since the syntax, is I believe, 821-valid. On the other hand, the example given below is invalid everywhere in 821 systems. john > On Tue, 18 Jul 2000 10:46:13 PDT, Kyle Jones > said: >> The attitude I took when I ran a relaying server was that stuff >> like a@b@c was better off bounced immediately. > > I can deal with that attitude. > > However, RFC821 also lists the following codes on page 56: > > 550 Requested action not taken: mailbox unavailable > [E.g., mailbox not found, no access] > 551 User not local; please try > 552 Requested mail action aborted: exceeded storage > allocation 553 Requested action not taken: mailbox > name not allowed [E.g., mailbox syntax incorrect] > 554 Transaction failed > > But then continues to say: > > MAIL > S: 250 > F: 552, 451, 452 > E: 500, 501, 421 > RCPT > S: 250, 251 > F: 550, 551, 552, 553, 450, 451, 452 > E: 500, 501, 503, 421 > > (I.e. you can toss a 553 on the RCPT TO, but not on a MAIL > FROM). > > RFC1123 then muddies things up more: > > 5.2.10 SMTP Replies: RFC-821 Section 4.2 > > A receiver-SMTP SHOULD send only the reply codes > listed in section 4.2.2 of RFC-821 or in this > document. A receiver-SMTP SHOULD use the text shown > in examples in RFC-821 whenever appropriate. > > A sender-SMTP MUST determine its actions only by the > reply code, not by the text (except for 251 and 551 > replies); any text, including no text at all, must be > acceptable. The space (blank) following the reply > code is considered part of the text. Whenever > possible, a sender-SMTP SHOULD test only the first > digit of the reply code, as specified in Appendix E of > RFC-821. > > DISCUSSION: > Interoperability problems have arisen with SMTP > systems using reply codes that are not listed > explicitly in RFC- 821 Section 4.3 but are legal > according to the theory of reply codes explained > in Appendix E. > > > So, is it legal/permissible/suggested to 553 on a MAIL FROM > that can be determined to be syntactically invalid? > -- > Valdis Kletnieks > Operating Systems Analyst > Virginia Tech > > > From owner-drums@cs.utk.edu Wed Jul 19 17:35:24 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20858 for ; Wed, 19 Jul 2000 17:35:23 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA28298; Wed, 19 Jul 2000 17:34:12 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 19 Jul 2000 17:34:06 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA28278; Wed, 19 Jul 2000 17:34:05 -0400 (EDT) Received: from black-ice.cc.vt.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA28265; Wed, 19 Jul 2000 17:34:03 -0400 (EDT) From: Received: from black-ice.cc.vt.edu (128.173.14.71 -> black-ice.cc.vt.edu) by cs.utk.edu (smtpshim v1.0); Wed, 19 Jul 2000 17:34:03 -0400 Received: from black-ice.cc.vt.edu (valdis@localhost [127.0.0.1]) by black-ice.cc.vt.edu (8.11.0.Beta4/8.11.0.Beta4) with ESMTP id e6JLXvY27914; Wed, 19 Jul 2000 17:33:58 -0400 Message-Id: <200007192133.e6JLXvY27914@black-ice.cc.vt.edu> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4+dev To: John C Klensin Cc: ietf-smtp@imc.org, drums@cs.utk.edu Subject: Re: mail-abuse.org tests, and weird addresses... In-Reply-To: Your message of "Wed, 19 Jul 2000 00:07:40 EDT." <1892586626.963965260@dhcp-033209.tc-conference.inet2000.gr.jp> X-Url: http://black-ice.cc.vt.edu/~valdis/ X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1278297722P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 19 Jul 2000 17:33:57 -0400 List-Unsubscribe: --==_Exmh_-1278297722P Content-Type: text/plain; charset=us-ascii On Wed, 19 Jul 2000 00:07:40 EDT, John C Klensin said: > If my memory is correct, 501 (syntax error) is intended, as was > the exclusion of 553 from the MAIL FROM responses. I agree that > the 1123 text is a little muddy (and it is probably at least > partially my fault). Please take a look at > draft-ietf-drums-smtpupd-12.txt and see if you think it is clear > and good enough; if not, comments should probably go to the DRUMS > list (copied on this response). Yes, 501 *is* the correct error, and your example of an embedded blank getting a 553 was better. smtpupd section 4.3.2 specifically allows any/all of 501, 550, and 553 on the MAIL FROM: which gives future releases of Sendmail sufficient room to work. That text looks good and reasonable. Is there a target date for smtpupd to move out of Draft status and into RFC, where it will be more cite-able without being a moving target? -- Valdis Kletnieks Operating Systems Analyst Virginia Tech --==_Exmh_-1278297722P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 Comment: Exmh version 2.2 06/16/2000 iQA/AwUBOXYexXAt5Vm009ewEQLWbwCg69YWHLzqGz7i1q/f7FT7sfSFIvsAn1W8 ersZb5lwY8niPvwREAIwmQRN =uxR1 -----END PGP SIGNATURE----- --==_Exmh_-1278297722P-- From owner-drums@cs.utk.edu Wed Jul 19 19:23:02 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28710 for ; Wed, 19 Jul 2000 19:23:02 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA11464; Wed, 19 Jul 2000 19:22:46 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 19 Jul 2000 19:22:45 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA11447; Wed, 19 Jul 2000 19:22:44 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA11433; Wed, 19 Jul 2000 19:22:42 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Wed, 19 Jul 2000 19:22:42 -0400 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07902 for ; Wed, 19 Jul 2000 16:22:35 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA22270 for ; Wed, 19 Jul 2000 16:22:29 -0700 (PDT) Date: Wed, 19 Jul 2000 16:22:10 -0700 From: DRUMS WG Chair To: "Detailed Revision/Update of Message Standards" Subject: SMTP WG Last-Call Message-ID: <1461297.3173012530@nifty-jr.west.sun.com> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit This is the WG last call on draft-ietf-drums-smtpupd-12.txt. Please read this draft. Unless I hear significant objections in the next week, I will consider this draft the rough concensus of this working group and will ask for an IETF-wide last call for Proposed Standard status. - DRUMS WG Chair From owner-drums@cs.utk.edu Wed Jul 19 20:14:01 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15784 for ; Wed, 19 Jul 2000 20:14:00 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA15228; Wed, 19 Jul 2000 20:13:47 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 19 Jul 2000 20:13:45 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA15210; Wed, 19 Jul 2000 20:13:43 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA15196; Wed, 19 Jul 2000 20:13:41 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> muncher.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Wed, 19 Jul 2000 20:13:41 -0400 Received: (qmail 10975 invoked by uid 1001); 20 Jul 2000 00:14:01 -0000 Date: 20 Jul 2000 00:14:01 -0000 Message-ID: <20000720001401.19958.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call References: <1461297.3173012530@nifty-jr.west.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: My web page http://cr.yp.to/smtp/klensin.html contains many objections to this draft. A copy of the text appears below. (Procedural notes: I have raised all of these objections before. In at least two cases, there is already overwhelming evidence that Klensin's position is not the consensus of the working group: http://cr.yp.to/smtp/drums/19990215054214-9088-qmail@cr-yp-to http://cr.yp.to/djbdns/namedroppers/20000204012814-28947-qmail@cr-yp-to I'd rather discuss content than procedure. Unfortunately, certain people habitually try to destroy productive discussions by claiming, falsely, that there's consensus against my objections. So I feel compelled to preemptively point out these two clearly established counterexamples.) ---Dan smtpupd-10 was released in February 1999. This page is a list of problems in smtpupd-10. I've excluded issues of procedure, document organization, and 8-bit mail. smtpupd-11 was released in March 2000. As far as I can tell, none of these problems were fixed. smtpupd-12 was released in July 2000. Two problems were fixed, as noted below. Interoperability failures in smtpupd-10 --------------------------------------- Klensin says that a client without a name registered in DNS SHOULD send an address literal ... optionally followed by information that will help to identify the client system in HELO. The address literal is fine; a bracketed IP address is a valid RFC 821 domain, and any server that rejected it would be violating RFC 1123, section 5.2.5. However, ``information that will help to identify the client system'' is a Klensin invention that creates new interoperability problems. Clients that send such information will find themselves completely unable to send mail to some hosts. Klensin says that servers ``MUST NOT recognize'' anything other than \015\012 as a line terminator. In reality, for interoperability with existing clients, servers recognize \012 as a line terminator for client requests. Clients do not (and, in practice, cannot) use \012 inside requests except as a line terminator. Klensin says that SMTP servers ``MUST reject'' requests containing underscores or other ``illegal character codes.'' In reality, for interoperability with existing clients, servers accept (for example) EHLO requests containing underscores. Klensin has extended the Received-line syntax to allow fractional seconds. This breaks some Received-line parsers. This problem was fixed in smtpupd-12. There are dozens of other interoperability issues where Klensin does not give adequate warning to future implementors. Safe behavior prohibited by smtpupd-10 -------------------------------------- Klensin says Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in SMTP. This prohibits the behavior of many existing clients: for example, a client relaying a message to a smarthost is violating the protocol if the user typed an address incorrectly. Obeying Klensin's requirement means checking every address in DNS. This is an unacceptable policy violation at some corporate sites, an unacceptable expense for many dumb clients, and an unacceptable obstacle for the vast majority of users when their ISPs are temporarily unable to reach the rest of the Internet. The requirement also prohibits the standard use of domain literals as specified in RFC 1123. Modern MTAs send ``double-bounce'' notifications to the local postmaster when a bounce message is undeliverable. Klensin has three requirements saying that this ``MUST NOT'' be done; only one of the requirements has a relevant exception. Klensin says that an SMTP client ``MUST NOT intentionally close the transmission channel until it sends a QUIT command.'' In reality, if an SMTP client is in the middle of sending a message, and is unable to read the next portion of the message from disk, it ruthlessly closes the connection. Sending QUIT in this situation means sending a corrupted message. Klensin says that VRFY ``MUST be listed ... in an EHLO response'' if it is supported. In reality, as of 1999, approximately 90% of the servers that support both VRFY and EHLO do not list VRFY in response to EHLO. If a client wants to use VRFY for some reason, it simply tries the VRFY command, as per RFC 821; paying attention to the EHLO response would be foolish. There's no reason to require an announcement. Klensin says that SMTP clients ``MUST NOT'' send message data unless the response to DATA is 354. This prohibits the behavior of many existing clients: if a server (in violation of RFC 821) sends (e.g.) a 387 reply, these clients will (as encouraged by RFC 821) treat 387 the same way as 354. The correct rule is that clients must not send message data if the reply begins with 4 or 5. Klensin says that servers ``MUST support the EHLO command even if they do not implement any specific extensions.'' In reality, servers that do not support EHLO are still able to receive mail. If a server does not support any extensions, its only benefit from supporting EHLO is to save a small amount of time for clients that start with EHLO. This is enough of a benefit for me to recommend that all servers support EHLO, but there is no interoperability excuse for requiring it. Klensin says Servers MUST NOT return the extended EHLO-style response to a HELO command. It is unclear what this means. Some obvious interpretations prohibit the behavior of existing hosts. Klensin says Whatever mechanisms are used, servers MUST contain provisions for detecting and stopping trivial loops. It is horrendously unclear what this means. Some obvious interpretations prohibit the behavior of existing hosts. Safe behavior discouraged by smtpupd-10 --------------------------------------- An essential element of a proper multidrop POP mailbox delivery is that the (single) envelope recipient is copied to a header field in the message, typically Delivered-To. However, Klensin says SMTP clients and servers SHOULD NOT copy the full set of RCPT TO command arguments into the headers, either as part of trace headers or as informational or private-extension headers. Klensin says that this ``requirement'' should be violated ``only under exceptional and well-understood circumstances''; Klensin claims that MTAs that use Delivered-To may not ``interoperate properly'' unless ``great care is taken.'' This is garbage. Klensin's alleged justification---namely, that such copying ``defeats the purpose'' of mailing lists and blind carbon copies---is completely incorrect for a message being delivered to one recipient at a time. The normal behavior of part-time dialup hosts and dumb clients is to connect to a relay identified by name (or sometimes IP address). Klensin says that clients that use relays ``SHOULD'' instead perform MX lookups on the relay name. Klensin says that this ``requirement'' should be violated ``only under exceptional and well-understood circumstances''; Klensin claims that clients using the normal procedure may not ``interoperate properly'' unless ``great care is taken.'' This is garbage. There is no reason to demand that these clients use MX lookups. Klensin says that clients ``SHOULD preferentially utilize EHLO rather than HELO.'' Klensin says that this ``requirement'' should be violated ``only under exceptional and well-understood circumstances''; Klensin claims that clients starting with HELO may not ``interoperate properly'' unless ``great care is taken.'' This is garbage. In reality, clients that have no need for extensions can and should start with HELO; EHLO adds quite a bit of unnecessary complexity. Of course, clients that want to use extensions will start with EHLO. Klensin says that SMTP servers ``SHOULD support EXPN.'' Klensin says that this ``requirement'' should be violated ``only under exceptional and well-understood circumstances''; Klensin claims that SMTP servers that always respond 502 to EXPN may not ``interoperate properly'' unless ``great care is taken.'' This is garbage. In reality, EXPN is obsolete. Thousands of the most heavily used mail servers on the Internet always respond 502 to EXPN. Klensin says that SMTP servers ``SHOULD support VRFY''; this means ``at least recognition of local mailboxes.'' Klensin says that this ``requirement'' should be violated ``only under exceptional and well-understood circumstances''; Klensin claims that SMTP servers that always respond 252 to VRFY may not ``interoperate properly'' unless ``great care is taken.'' This is garbage. In reality, VRFY is obsolete. Thousands of the most heavily used mail servers on the Internet always respond 252 to VRFY. Klensin says that an SMTP client ``SHOULD'' wait until it receives the reply to QUIT before closing a connection. Klensin says that this ``requirement'' should be violated ``only under exceptional and well-understood circumstances''; Klensin claims that clients closing the connection immediately after sending QUIT may not ``interoperate properly'' unless ``great care is taken.'' This is garbage. In reality, thousands of SMTP clients close the connection immediately after sending QUIT. There is no reason to wait for the response. Klensin says that an SMTP server ``SHOULD attempt to send a line containing a 421 response code'' if it is shut down by the system administrator. Klensin says that this ``requirement'' should be violated ``only under exceptional and well-understood circumstances''; Klensin claims that servers that simply close the connection may not ``interoperate properly'' unless ``great care is taken.'' This is garbage. In reality, connections are abruptly dropped for a wide variety of reasons, including server shutdowns. Klensin says that every ``SMTP-capable host SHOULD support both the alias and the list models of address expansion for multiple delivery.'' Klensin says that this ``requirement'' should be violated ``only under exceptional and well-understood circumstances''; Klensin claims that servers that don't support mailing lists may not ``interoperate properly'' unless ``great care is taken.'' This is garbage. In reality, firewalls and POP toasters do not, and should not, support mailing lists. Klensin says that SMTP servers ``SHOULD reject'' parameters in RSET, DATA, or QUIT. Klensin says that this ``requirement'' should be violated ``only under exceptional and well-understood circumstances''; Klensin claims that servers that ignore such parameters may not ``interoperate properly'' unless ``great care is taken.'' This is garbage. In reality, thousands of SMTP servers ignore such parameters. Klensin says that all ``fully-capable SMTP implementations'' are ``expected to support'' various client features. This is garbage. In reality, firewalls and POP toasters often run pure SMTP servers. They do not send mail through SMTP, and they are not expected to support any SMTP client features. Installing unused code is a violation of some corporate security policies. Other misleading statements in smtpupd-10 ----------------------------------------- sendmail rewrites messages received through SMTP. Klensin claims that this behavior was ``in response to weak SMTP clients'' that generated incomplete messages. That's backwards. First sendmail was designed to feed all messages, whether received locally or via SMTP, through the same rewriting and routing mechanisms. Then people took advantage of this and wrote dumb clients. Klensin claims that, ``in most cases,'' SMTP clients that send all mail through a relay host neglect to retry delivery after failures. This might be true for some dumb clients but it's certainly not true for serious MTAs such as sendmail. Klensin defines ``relays'' as receiving mail by SMTP and forwarding mail by SMTP. In reality, many relays support other protocols for transferring Internet mail messages, such as QMTP. (These relays generally do not change message formats, so they do not fit Klensin's ``gateway'' requirements.) Klensin says that ``the [message] body, if structured, is defined according to MIME.'' In reality, there are many common non-MIME body structures. Klensin's document begins the same way as the original SMTP specification, RFC 821, written in 1982: The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently. Unfortunately, SMTP does not achieve this objective. It is painfully slow; more importantly, its design has led to a string of interoperability disasters. Klensin requires that years contain at most four digits. In reality, there will be a year 10000. This problem was fixed in smtpupd-12. From owner-drums@cs.utk.edu Wed Jul 19 20:44:02 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25796 for ; Wed, 19 Jul 2000 20:44:01 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA17196; Wed, 19 Jul 2000 20:43:46 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 19 Jul 2000 20:43:37 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA17177; Wed, 19 Jul 2000 20:43:37 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id UAA17164; Wed, 19 Jul 2000 20:43:35 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Wed, 19 Jul 2000 20:43:35 -0400 Received: from dhcp-065042.wireless-conference.inet2000.gr.jp (dhcp-065042.wireless-conference.inet2000.gr.jp [133.195.65.42]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id RAA07924; Wed, 19 Jul 2000 17:43:16 -0700 X-Authentication-Warning: joy.songbird.com: dhcp-065042.wireless-conference.inet2000.gr.jp [133.195.65.42] didn't use HELO protocol Message-Id: <4.3.2.20000720093729.00c02e20@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 20 Jul 2000 09:42:56 +0900 To: "D. J. Bernstein" From: Dave Crocker Subject: Re: SMTP WG Last-Call Cc: drums@cs.utk.edu In-Reply-To: <20000720001401.19958.qmail@cr.yp.to> References: <1461297.3173012530@nifty-jr.west.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 12:14 AM 7/20/00 +0000, D. J. Bernstein wrote: >My web page http://cr.yp.to/smtp/klensin.html contains many objections >to this draft. A copy of the text appears below. > >(Procedural notes: I have raised all of these objections before. In at >least two cases, there is already overwhelming evidence that Klensin's >position is not the consensus of the working group: > > http://cr.yp.to/smtp/drums/19990215054214-9088-qmail@cr-yp-to > http://cr.yp.to/djbdns/namedroppers/20000204012814-28947-qmail@cr-yp-to > >I'd rather discuss content than procedure. Unfortunately, certain people just to provide a quick, public, on-the-record counterpoint: The objection being raised is noteworthy for pointedly personalizing the target of the objection. That fact highlights its primary failing, since the working group has had to respond to the many, cited objections before. The working group has been diligent to evaluate these objections, even to the *strategic* detriment of making progress. Whatever the remaining objections, they are the position of only one working group participant, and they run contrary to well-established *working group* consensus, contrary to the claim. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Thu Jul 20 04:40:12 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17581 for ; Thu, 20 Jul 2000 04:40:11 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id EAA09387; Thu, 20 Jul 2000 04:39:48 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 04:39:40 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id EAA09368; Thu, 20 Jul 2000 04:39:40 -0400 (EDT) Received: from draco.cus.cam.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id EAA09355; Thu, 20 Jul 2000 04:39:37 -0400 (EDT) Received: from draco.cus.cam.ac.uk (131.111.8.18 -> draco.cus.cam.ac.uk) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 04:39:38 -0400 Received: from ph10 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 3.16 #2) id 13FBrh-0000bm-00; Thu, 20 Jul 2000 09:39:33 +0100 Date: Thu, 20 Jul 2000 09:39:33 +0100 (BST) From: Philip Hazel To: Dave Crocker cc: "D. J. Bernstein" , drums@cs.utk.edu Subject: Re: SMTP WG Last-Call In-Reply-To: <4.3.2.20000720093729.00c02e20@mail.bayarea.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: On Thu, 20 Jul 2000, Dave Crocker wrote: > Whatever the remaining objections, they are the position of only > one working group participant, and they run contrary to well-established > *working group* consensus, contrary to the claim. To keep the record straight, let me record here that there are several of Dan's points with which I entirely agree. So it isn't just one participant, it's at least two. And, like Dan, I am an MTA implementor. I have to confess that I decided to give up trying to argue these points in the face of apparently overwhelming opposition. They include the 8-bit thing, which he does not mention in his message. The other major points with which I agree are: In reality, for interoperability with existing clients, servers recognize \012 as a line terminator for client requests. Clients do not (and, in practice, cannot) use \012 inside requests except as a line terminator. In reality, if an SMTP client is in the middle of sending a message, and is unable to read the next portion of the message from disk, it ruthlessly closes the connection. Sending QUIT in this situation means sending a corrupted message. If a client wants to use VRFY for some reason, it simply tries the VRFY command, as per RFC 821; paying attention to the EHLO response would be foolish. There's no reason to require an announcement. The correct rule is that clients must not send message data if the reply begins with 4 or 5. Actually, I would say that the correct rule is that clients must not send data unless the reply begins with 3. Servers MUST NOT return the extended EHLO-style response to a HELO command. It is unclear what this means. Some obvious interpretations prohibit the behavior of existing hosts. It is indeed unclear what this means, since a multi-line response to HELO is permitted. In reality, EXPN is obsolete. In reality, VRFY is obsolete. In reality, thousands of SMTP clients close the connection immediately after sending QUIT. There is no reason to wait for the response. ... provided that this does not screw things up because of the way the TCP/IP stack works on the operating system. Unix is a safe system in this respect. In reality, connections are abruptly dropped for a wide variety of reasons, including server shutdowns. Are there any MTAs that interwork with the "shutdown" command to support what the draft says? In reality, firewalls and POP toasters do not, and should not, support mailing lists. I see no reason to mention aliasing and mailing list expansion in the document that defines SMTP. These activities are things that go on inside an MTA after it has received a message and don't seem to me to have anything to do with a message transfer protocol. The problem is that the document contains material about the way "common" MTAs actually work - useful stuff that certainly should be written somewhere - but there are plenty of situations that are "uncommon". Some other comments of Dan's are valid points, IMHO, but I don't think they are a problem, because they refer to situations where a client is passing data to a known, fixed host (e.g. dial-up client to smarthost). In those cases, the client and server are obviously allowed to use whatever protocol they fancy, and "not-quite-public-SMTP" is an obvious choice. But maybe that could be said somewhere. Philip -- Philip Hazel University of Cambridge Computing Service, ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. From owner-drums@cs.utk.edu Thu Jul 20 06:06:38 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24266 for ; Thu, 20 Jul 2000 06:06:38 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA15687; Thu, 20 Jul 2000 06:06:04 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 06:06:02 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA15670; Thu, 20 Jul 2000 06:06:02 -0400 (EDT) Received: from aarnima1-pc1.tmt.tele.fi (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA15657; Thu, 20 Jul 2000 06:05:59 -0400 (EDT) Received: from aarnima1-pc1.tmt.tele.fi (194.252.70.4 -> aarnima1-pc1.tmt.tele.fi) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 06:06:00 -0400 Received: (mea@aarnima1-pc1.tmt.tele.fi) by mea.tmt.tele.fi id ; Thu, 20 Jul 2000 06:05:50 -0400 From: Matti Aarnio To: drums@cs.utk.edu Subject: Comments on smtpupd-12 Message-Id: <20000720100556Z32074-18330+9@mea.tmt.tele.fi> Date: Thu, 20 Jul 2000 06:05:50 -0400 List-Unsubscribe: I have tried to read the document as a complete newcomer without understanding of how the protocol works -- mindset which has gotten educated by seeing how various bigname vendors make mistakes at their products... (they *must* have newcomers coding the beasts.) Part 2.4: This part speaks gives explicite strings in quotes for clarity, which notation is somewhat missed at some latter places when speaking of e.g. RFC 822 headers Date, From, .. But more of that at appropriate place(s). Explicite string notation is a good idea. Latter in this part says (last paragraph): "Metalanguage terms used in running text are surrounded by pointed brackets (e.g., ) for clarity." Yet the same pointy brackets are used (or not used) at command samples. This is somewhat confusing. Part 3.3: The command syntaxes of MAIL/RCPT/DATA are different from 4.1.1.2/4.1.1.3/4.1.1.4 respectively. This will confuse people. My suggestion is to copy syntaxes from 4.1.1.* into here too. The second to last paragraph: When RFC 822 format is being used, the mail data include the memo header items such as Date, Subject, To, Cc, From [MSGFMT]. ... Here I would like to see explicte stringification of those header names with explicite double-colons: When RFC 822 format is being used, the mail data include the memo header items such as "Date:", "Subject:", "To:", "Cc:", "From:" [MSGFMT]. ... as in my thinking there is definite danger of readers confusing "MAIL FROM:<..>" and "RCPT TO:<..>" envelope commands at least to RFC 822 "From:" and "To:" headers. Ah, and the same with "Resert-To:", "Resent-From:", "Resent-Date:" headers. Part 3.5.3: The first paragraph mentions twice reply code "220", which I seems to be a mistake and should be "250". part 3.6.5: Add new paragraph to the end ? Usage of nationalized forms of "Re: " string in front of the reply message "Subject: content is observed causing awfull looking results in lenghty exchanges, especially when there are people using differently nationalized mail user agents: Subject: Re: Awt: Sv: Vs: topic text Therefore it is SUGGESTED that user agents sending email do always use standard international form when sending, and only do nationalizing of this prefix string at displaying (and possibly printing) the email. Part 3.8.3: ">From the Internet ..." Possibly an artefact from email submission to draft repository ? Part 4.1.1.1: This part does not carry discussion about the error procedure, parts 4.5 thru 4.7 of RFC 1869. Also a note about practical interoperability would be nice, e.g.: For practical interoperability, the SMTP server SHOULD ignore the parameter (or lack of one), and just assume it to be valid. Especially an attempt to verify that the expected domain parameter really is valid is a very quick way to trouble, as many ISPs supply their clients with premade email client configurations carrying some constant strings a'la: "HELO homepc". Part 4.2: A reference to 4.2.1 which I suggest for splitting below. Part 4.2.1: At RFC 821 annex E there seems to exist a notability problem of the multiline reply functionality. Some software don't support receiving multiline replies, and this is propably because this important feature is not highlighted clearly enough -- with its own part number. I suggest that the last four paragraphs of this part are to be split into separate part - number as 4.2.2 with title: "Theory of multiline reply codes" Part 4.4: This is a very long part, which actually carries three different topics. I suggest splitting it to: 4.4.1 The "Received:" header 4.4.2 The "Return-Path:" header 4.4.3 Treatment of accepted RCPT recipients with errors at DATA delivery time (this last feels to be somewhat misplaced) And moving relevant bits of the syntaxes to approriate parts, plus referring to RFC 822 header labels with quoted strings. Perhaps also adding there an introductory paragraph to begin 4.4. Similarly at "Received:" header generation I don't think it really is wise to generate: Received: from homepc (...) by ... but perhaps: Received: from reversed-ip-name-or-address-literal ([1.2.3.4] "HELO homepc") by ... which neatly avoids users from hitting the system with oversize HELO string trying to overflow header generation buffsers, like is so much want of past obscuring attacks.. Part 5: I would begin this part with a short intro: Following applies to SMTP clients which do not have a-priori knowledge of which server to connect, and thus must use the DNS based email routing data. Now the first paragraph is algorithm description in free flowing text. Could that be split into numbered paragraphs and/or bullets with possible introduction ? part 7.2 (BCC) The first paragraph suggests that for security reasons sending SMTP systems might send messages separately for each recipient so that systems doing "for"-clauses (see also part 7.5) won't disclose all recipients. Perhaps at least adding a reference to 7.5 ? part 7.4: Split to 2-3 paragraphs ? (in overall I find lengthy paragraphs of many sentences laborous to read, and I have this strange belief that such ones can always be split to separate paragraphs..) part 7.5: Again split to several paragraps ? part F.5: s/years MUST BE user/years MUST be used/ ?? From owner-drums@cs.utk.edu Thu Jul 20 08:46:04 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14305 for ; Thu, 20 Jul 2000 08:46:03 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id IAA22349; Thu, 20 Jul 2000 08:45:34 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 08:45:31 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id IAA22332; Thu, 20 Jul 2000 08:45:30 -0400 (EDT) Received: from sws5.ctd.ornl.gov (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id IAA22318; Thu, 20 Jul 2000 08:45:29 -0400 (EDT) Received: from sws5.ctd.ornl.gov (160.91.68.105 -> sws5.ctd.ornl.gov) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 08:45:29 -0400 Received: (qmail 69748 invoked by uid 3995); 20 Jul 2000 12:45:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14710.62568.719060.219853@sws5.ctd.ornl.gov> Date: Thu, 20 Jul 2000 08:45:28 -0400 (EDT) From: Dave Sill To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call In-Reply-To: <4.3.2.20000720093729.00c02e20@mail.bayarea.net> References: <1461297.3173012530@nifty-jr.west.sun.com> <4.3.2.20000720093729.00c02e20@mail.bayarea.net> X-Mailer: VM 6.75 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Organization: Oak Ridge National Lab, Oak Ridge, Tenn., USA X-Face: "p~Q]mg{;e*}YR|)&Q/&Q\*~5UWfZX34;5M Content-Transfer-Encoding: 7bit Dave Crocker wrote: > Whatever the remaining objections, they are the position of only >one working group participant, and they run contrary to well-established >*working group* consensus, contrary to the claim. I agree with Dan's objections. I've been here nearly two years and I don't recall seeing clear consensus against any of them. -Dave From owner-drums@cs.utk.edu Thu Jul 20 09:23:58 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03028 for ; Thu, 20 Jul 2000 09:23:58 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA25482; Thu, 20 Jul 2000 09:23:39 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 09:23:38 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA25461; Thu, 20 Jul 2000 09:23:37 -0400 (EDT) Received: from lotus2.lotus.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA25445; Thu, 20 Jul 2000 09:23:31 -0400 (EDT) Received: from lotus2.lotus.com (192.233.136.8 -> lotus2.lotus.com) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 09:23:31 -0400 Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id JAA19362; Thu, 20 Jul 2000 09:24:31 -0400 (EDT) Received: from a3mail.lotus.com (A3MAIL.lotus.com [9.95.5.66]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id JAA22059; Thu, 20 Jul 2000 09:22:53 -0400 (EDT) To: Dave Sill Cc: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call X-Mailer: Lotus Notes Build V505_07112000 July 11, 2000 From: "Nick Shelness/SSW/Lotus" Message-ID: Date: Thu, 20 Jul 2000 14:20:29 +0100 X-MIMETrack: Serialize by Router on A3MAIL/CAM/H/Lotus(Build V505_07062000 |July 6, 2000) at 07/20/2000 09:25:34 AM, Serialize complete at 07/20/2000 09:25:34 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: Dave, You wrote:- > I agree with Dan's objections. I've been here nearly two years and I > don't recall seeing clear consensus against any of them. If you had been around for longer (sadly much longer given the age of the drums wg), you would know that RFC 821, RFC 822, and RFC 1123 form the drums base line. To make a change to this base line in 821bis or b22bis requires rough consensus of the working group. In the case of Dan's points, they all involve changes to the base line, so even where others agree with him, without rough consensus (and none has been seen) it is not possible for the proposed changes to be made. It doesn't involve Dan, but the most striking example of this principle was RFC 822bis' retention of RFC 822's problematic Reply-to: text. Everyone agreed it was broken. We just couldn't reach consensus on how to fix it. Finally, I and made others in the working group abhor personal attacks on the integrity of our colleagues. I for one now stop reading whenever I encounter such an attack and I am not alone. I would, therefore, posit that it is impossible to reach rough consensus on any proposal that includes such an attack. Not enough people will have read it. Over the years a whole number of us have tried to help Dan clean up his act. Each time we have only had the attacks re-directed at us. Its a serious problem, and one for which I perceive no solution. Nick Nick Shelness, IBM Fellow Chief Technology Officer Lotus Development Corp Tel: (617) 693-7484 Assistant: Mary McGurran Tel: (617) 693-4321 From owner-drums@cs.utk.edu Thu Jul 20 09:59:55 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23855 for ; Thu, 20 Jul 2000 09:59:54 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA28963; Thu, 20 Jul 2000 09:59:38 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 09:59:36 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA28942; Thu, 20 Jul 2000 09:59:35 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA28925; Thu, 20 Jul 2000 09:59:28 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 09:59:28 -0400 Received: from dhcp-086012.20F.wireless-hotel.inet2000.gr.jp (dhcp-086012.20F.wireless-hotel.inet2000.gr.jp [133.195.86.12]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id GAA13784; Thu, 20 Jul 2000 06:59:22 -0700 X-Authentication-Warning: joy.songbird.com: dhcp-086012.20F.wireless-hotel.inet2000.gr.jp [133.195.86.12] didn't use HELO protocol Message-Id: <4.3.2.20000720225612.00bc15f0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 20 Jul 2000 22:59:16 +0900 To: Philip Hazel From: Dave Crocker Subject: Re: SMTP WG Last-Call Cc: "D. J. Bernstein" , drums@cs.utk.edu In-Reply-To: References: <4.3.2.20000720093729.00c02e20@mail.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 09:39 AM 7/20/00 +0100, Philip Hazel wrote: >On Thu, 20 Jul 2000, Dave Crocker wrote: > > Whatever the remaining objections, they are the position of only > > one working group participant, and they run contrary to well-established > > *working group* consensus, contrary to the claim. > >To keep the record straight, let me record here that there are several several. yes. my language was sloppily absolute. several, however, is a small number from the set. >of Dan's points with which I entirely agree. So it isn't just one >participant, it's at least two. And, like Dan, I am an MTA implementor. two, yes. and a third has chimed in. again I used absolute language and should have been more "proportional". so far, the 2 statements in support of some of Dan's concerns substantiate my primary observation about lack of substantial support for those concerns. That is, working group consensus was consistently and massively against those concerns. d/ >I have to confess that I decided to give up trying to argue these points >in the face of apparently overwhelming opposition. They include the >8-bit thing, which he does not mention in his message. The other major >points with which I agree are: > > In reality, for interoperability with existing clients, servers > recognize \012 as a line terminator for client requests. Clients do not > (and, in practice, cannot) use \012 inside requests except as a line > terminator. > > In reality, if an SMTP client is in the middle of sending a message, and > is unable to read the next portion of the message from disk, it > ruthlessly closes the connection. Sending QUIT in this situation means > sending a corrupted message. > > If a client wants to use VRFY for some reason, it simply tries the VRFY > command, as per RFC 821; paying attention to the EHLO response would be > foolish. There's no reason to require an announcement. > > The correct rule is that clients must not send message data if the > reply begins with 4 or 5. > >Actually, I would say that the correct rule is that clients must not >send data unless the reply begins with 3. > > Servers MUST NOT return the extended EHLO-style response to a HELO > command. It is unclear what this means. Some obvious interpretations > prohibit the behavior of existing hosts. > >It is indeed unclear what this means, since a multi-line response to >HELO is permitted. > > In reality, EXPN is obsolete. > > In reality, VRFY is obsolete. > > In reality, thousands of SMTP clients close the connection immediately > after sending QUIT. There is no reason to wait for the response. > >... provided that this does not screw things up because of the way the >TCP/IP stack works on the operating system. Unix is a safe system in >this respect. > > In reality, connections are abruptly dropped for a wide variety of > reasons, including server shutdowns. > >Are there any MTAs that interwork with the "shutdown" command to support >what the draft says? > > In reality, firewalls and POP toasters do not, and should not, support > mailing lists. > >I see no reason to mention aliasing and mailing list expansion in the >document that defines SMTP. These activities are things that go on >inside an MTA after it has received a message and don't seem to me to >have anything to do with a message transfer protocol. The problem is >that the document contains material about the way "common" MTAs actually >work - useful stuff that certainly should be written somewhere - but >there are plenty of situations that are "uncommon". > >Some other comments of Dan's are valid points, IMHO, but I don't think >they are a problem, because they refer to situations where a client is >passing data to a known, fixed host (e.g. dial-up client to smarthost). >In those cases, the client and server are obviously allowed to use >whatever protocol they fancy, and "not-quite-public-SMTP" is an obvious >choice. But maybe that could be said somewhere. > >Philip > >-- >Philip Hazel University of Cambridge Computing Service, >ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Thu Jul 20 10:03:15 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25846 for ; Thu, 20 Jul 2000 10:03:14 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id KAA29611; Thu, 20 Jul 2000 10:02:56 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 10:02:56 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id KAA29594; Thu, 20 Jul 2000 10:02:56 -0400 (EDT) Received: from sws5.ctd.ornl.gov (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id KAA29581; Thu, 20 Jul 2000 10:02:54 -0400 (EDT) Received: from sws5.ctd.ornl.gov (160.91.68.105 -> sws5.ctd.ornl.gov) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 10:02:54 -0400 Received: (qmail 71500 invoked by uid 3995); 20 Jul 2000 14:02:54 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14711.1677.969089.868429@sws5.ctd.ornl.gov> Date: Thu, 20 Jul 2000 10:02:53 -0400 (EDT) From: Dave Sill To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Organization: Oak Ridge National Lab, Oak Ridge, Tenn., USA X-Face: "p~Q]mg{;e*}YR|)&Q/&Q\*~5UWfZX34;5M Content-Transfer-Encoding: 7bit "Nick Shelness/SSW/Lotus" wrote: >...To make a change to this base line in 821bis or b22bis >requires rough consensus of the working group. In the case of Dan's >points, they all involve changes to the base line, so even where others >agree with him, without rough consensus (and none has been seen) it is not >possible for the proposed changes to be made. What is the measure of rough consensus? Some fixed number of positive responses? A certain ratio of positives to negatives? >Finally, I and made others in the working group abhor personal attacks on >the integrity of our colleagues. I for one now stop reading whenever I >encounter such an attack and I am not alone. I don't like them, either, but "retaliating" by refusing to consider the objections on their merits is, I think, counterproductive. Dismissing them without consideration only strengthens the attacker's claims that their objections aren't being taking into consideration. And, of course, the goal of producing the best documents/standards can only be achieved by evaluating all input objectively. Thanks for your response, Nick. -Dave From owner-drums@cs.utk.edu Thu Jul 20 12:46:14 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19736 for ; Thu, 20 Jul 2000 12:46:14 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA14872; Thu, 20 Jul 2000 12:45:52 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 12:45:49 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA14852; Thu, 20 Jul 2000 12:45:49 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA14836; Thu, 20 Jul 2000 12:45:47 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 12:45:47 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA04825 for ; Thu, 20 Jul 2000 12:45:46 -0400 (EDT) Message-Id: <200007201645.MAA04825@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call In-reply-to: Your message of "20 Jul 2000 00:14:01 -0000." <20000720001401.19958.qmail@cr.yp.to> Date: Thu, 20 Jul 2000 12:45:46 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: I'm always amused (not) when Dan calls his own opinions "reality" and characterizes the opinions of the docuent editor as if they were purely personal opinions ("Klensin says...") rather than representing the group. It's the document editor's job to state concrete positions on subtle issues and see whether the working group supports those positions. While it's certainly okay for WG participants to object to the language in a document, Dan's efforts to personally target the editor are inexcusable. having said that, I do agree with Dan on some points. > Interoperability failures in smtpupd-10 > --------------------------------------- > > Klensin says that a client without a name registered in DNS > SHOULD send an address literal ... optionally followed by > information that will help to identify the client system > in HELO. The address literal is fine; a bracketed IP address is a > valid RFC 821 domain, and any server that rejected it would be > violating RFC 1123, section 5.2.5. However, ``information that will > help to identify the client system'' is a Klensin invention that > creates new interoperability problems. Clients that send such > information will find themselves completely unable to send mail to > some hosts. IIRC, the WG discussed this at one point and came up with some language very similar to the current smtpupd draft. However, I also have a problem with the notion that the client can send something which is not syntactically compatible with a domain here (or an address literal), as it seems likely to break compatibility with existing servers that quite legitimately expect a domain. Note that section 3.6 says that the host must use either a domain name or an address literal. they need to be consistent. I think the HELO/EHLO argument needs to be a) the FQDN if known, else b) the client's IP address literal, if available, else c) some string which is syntactically compatible with a domain name but unlikely to be confused with a "real" domain name. > Klensin says that servers ``MUST NOT recognize'' anything other > than \015\012 as a line terminator. In reality, for interoperability > with existing clients, servers recognize \012 as a line terminator > for client requests. Clients do not (and, in practice, cannot) use > \012 inside requests except as a line terminator. Despite the fact that some broken clients send LF-terminated commands, I'm comfortable with "MUST NOT recognize" in this case. A server which accepts LF as a terminator introduces the possibility of synchronization errors. While such errors are rare, they have been observed in practice. > Klensin says that SMTP servers ``MUST reject'' requests containing > underscores or other ``illegal character codes.'' In reality, for > interoperability with existing clients, servers accept (for example) > EHLO requests containing underscores. aside: Just because some servers accept such requests does not mean that the standard should endorse such behavior. The purpose of a standard is to specify how things should behave, not to document all of the brain-damage that has been observed. I can live with ``MUST reject'' here. However given that the EHLO and HELO domains typically aren't used for anything other than to put into received header fields, and their use there has marginal utility, MUST seems a bit strong to me. > Klensin says > Only resolvable, fully-qualified, domain names (FQDNs) are > permitted when domain names are used in SMTP. > This prohibits the behavior of many existing clients: So be it. Those clients are not following the standard. smtpupd doesn't say that the server has to reject such messages; it just says that such messages are not permitted *by the standard*. I suppose one could interpret "Only...are permitted" as saying that the server should not accept such messages or that the client must check all domains before sending a message. If so then a slight rewording could be useful. It seems entirely appropriate to say that the use of anything besides an FQDN is an error. However, I would not say that doing so is a violation of the standard as long as the name is in legal FQDN (or domain literal) syntax. so I would recommend changing the text to say that the use of non-FQDNs is an error, rather than to say that such things MUST NOT be sent. > Modern MTAs send ``double-bounce'' notifications to the local > postmaster when a bounce message is undeliverable. Klensin has three > requirements saying that this ``MUST NOT'' be done; only one of the > requirements has a relevant exception. > > Klensin says that an SMTP client ``MUST NOT intentionally close the > transmission channel until it sends a QUIT command.'' In reality, > if an SMTP client is in the middle of sending a message, and is > unable to read the next portion of the message from disk, it > ruthlessly closes the connection. Sending QUIT in this situation > means sending a corrupted message. the correct thing is to say that the SMTP client SHOULD send QUIT under normal conditions; simply omitting QUIT is a violation of the standard. if it is necessary to abort sending a message in a DATA phase, the client MUST close the connection (there's no other way to do it). finally a client that aborts a connection without sending QUIT MUST NOT treat the messages which were transmitted in that session as if they were transferred to the server. > Klensin says that VRFY ``MUST be listed ... in an EHLO response'' > if it is supported. In reality, as of 1999, approximately 90% of > the servers that support both VRFY and EHLO do not list VRFY in > response to EHLO. If a client wants to use VRFY for some reason, > it simply tries the VRFY command, as per RFC 821; paying attention > to the EHLO response would be foolish. There's no reason to require > an announcement. the purpose of the standard is to describe how things should work, not to describe reality. however I don't know of any reason for a MUST requirement to list VRFY. especially given that normal clients shouldn't be using VRFY anyway ... these days, VRFY is for debugging. > Klensin says that SMTP clients ``MUST NOT'' send message data unless > the response to DATA is 354. This prohibits the behavior of many > existing clients: if a server (in violation of RFC 821) sends (e.g.) > a 387 reply, these clients will (as encouraged by RFC 821) treat > 387 the same way as 354. The correct rule is that clients must not > send message data if the reply begins with 4 or 5. the correct rule is that the DATA response must begin with 3. > Klensin says that servers ``MUST support the EHLO command even if > they do not implement any specific extensions.'' this is entirely appropriate. the implementation burden is small. > Klensin says > Servers MUST NOT return the extended EHLO-style response > to a HELO command. > It is unclear what this means. Some obvious interpretations prohibit > the behavior of existing hosts. since the EHLO response should be legal for HELO also (can be multi-line, is syntactically compatible, reply code is the same), I don't see any reason for this prohibition. if we want to say that HELO responses should be single-line, say that, rather than saying it should not be the same as EHLO. > Klensin says > Whatever mechanisms are used, servers MUST contain provisions > for detecting and stopping trivial loops. > It is horrendously unclear what this means. Some obvious interpretations > prohibit the behavior of existing hosts. I would say "servers that relay or forward messages to other servers". some servers cannot cause loops. this might be a good use of SHOULD. > > Safe behavior discouraged by smtpupd-10 > --------------------------------------- > > An essential element of a proper multidrop POP mailbox delivery is > that the (single) envelope recipient is copied to a header field > in the message, typically Delivered-To. However, Klensin says > SMTP clients and servers SHOULD NOT copy the full set of > RCPT TO command arguments into the headers, either as part > of trace headers or as informational or private-extension > headers. should be reworded to say 'servers MUST NOT inculude any envelope recipient address obtained from a RCPT TO command in a message header generated by the server, except that a copy of a message delivered to a particular recipient the message header MAY disclose the recipient address(es) which caused the message to be delivered to that recipient. > The normal behavior of part-time dialup hosts and dumb clients is > to connect to a relay identified by name (or sometimes IP address). > Klensin says that clients that use relays ``SHOULD'' instead perform > MX lookups on the relay name. we need to distinguish between clients that forward all messages of unknown destination to a smart relay (i.e. they have a "default route"), and relays that route messages to their destinations over the Internet. The latter MUST use MX records, or address records if MX records are not found. The former don't need DNS except to find the smart relay. > Klensin says that clients ``SHOULD preferentially utilize EHLO > rather than HELO.'' Klensin says that this ``requirement'' should > be violated ``only under exceptional and well-understood circumstances''; > Klensin claims that clients starting with HELO may not ``interoperate > properly'' unless ``great care is taken.'' This is garbage. In > reality, clients that have no need for extensions can and should > start with HELO; EHLO adds quite a bit of unnecessary complexity. actually, that's false - the client has to be prepared to see a multiline response even if it sends HELO. just because the client sends EHLO doesn't mean that it has to parse the response, beyond the normal SMTP framing, if it's not going to use any extensions. there may be some extensions that all clients SHOULD implement, but I don't know of any reason for a client to send EHLO if it doesn't implement any extensions. > Klensin says that SMTP servers ``SHOULD support EXPN.'' I take this to mean that a server SHOULD implement EXPN if it implements forwarding or mailing lists, but it MAY be configured to always return "sorry, not going to give this to you". (it probably SHOULD be shipped with "no access" being the default) at any rate I think this is a confusion between requirements on the implementaion and requirements on operation - the SHOULD in this case is a requirement of the implementation. > Klensin says that SMTP servers ``SHOULD support VRFY'' similar reasoning to EXPN. > Klensin says that an SMTP client ``SHOULD'' wait until it receives > the reply to QUIT before closing a connection. since it's a SHOULD, I don't have a problem with this. > Klensin says that an SMTP server ``SHOULD attempt to send a line > containing a 421 response code'' if it is shut down by the system > administrator. seems reasonable. some network stacks are better than others at detecting shutdown connections and delivering the news to the application. > Klensin says that every ``SMTP-capable host SHOULD support both the > alias and the list models of address expansion for multiple delivery.'' I don't have a problem with SHOULD. I think the assumption is that a SMTP-capable host is a normal MTA with normal MTA functions, rather than some sort of specialized MTA that doesn't implement aliases and mailing lists. it wouldn't hurt to state this explicitly, though. > Klensin says that SMTP servers ``SHOULD reject'' parameters in RSET, > DATA, or QUIT. I don't have a problem with this at all; clients that supply parameters to these commands may be expecting behavior that the server is not prepared to support. > Klensin says that all ``fully-capable SMTP implementations'' are > ``expected to support'' various client features. This is garbage. > In reality, firewalls and POP toasters often run pure SMTP servers. I don't think of firewalls and POP toasters as 'fully-capable SMTP implementations'. the wording could be better, but it's hard to nail down definitions for all types of SMTP implementations of interest. > sendmail rewrites messages received through SMTP. Klensin claims > that this behavior was ``in response to weak SMTP clients'' that > generated incomplete messages. That's backwards. First sendmail was > designed to feed all messages, whether received locally or via SMTP, > through the same rewriting and routing mechanisms. Then people took > advantage of this and wrote dumb clients. since sendmail and its rewriting behavior predate SMTP, sendmail's rewrite capability obviously was not in response to weak SMTP clients. on the other hand, sendmail's rewriting has often been used in an attempt to fix weak clients and client writers have become accustomed to this. this situation should be rectified. so a slight rewording might be in order. > Klensin claims that, ``in most cases,'' SMTP clients that send all > mail through a relay host neglect to retry delivery after failures. > This might be true for some dumb clients but it's certainly not > true for serious MTAs such as sendmail. depends on what you mean by 'client'. 'user agent' might be a better term. > Klensin defines ``relays'' as receiving mail by SMTP and forwarding > mail by SMTP. In reality, many relays support other protocols for > transferring Internet mail messages, such as QMTP. (These relays > generally do not change message formats, so they do not fit Klensin's > ``gateway'' requirements.) > > Klensin says that ``the [message] body, if structured, is defined > according to MIME.'' In reality, there are many common non-MIME > body structures. I don't see any harm in providing a reference to the MIME spec. a lot of first-time readers have a hard time figuring out how the pieces fit together. > Klensin's document begins the same way as the original SMTP > specification, RFC 821, written in 1982: > The objective of the Simple Mail Transfer Protocol (SMTP) > is to transfer mail reliably and efficiently. > Unfortunately, SMTP does not achieve this objective. depends on what you're comparing it with. it's certainly more reliable and efficient than X.400. there's certainly room for improvement. I would say that SMTP is designed for reliability; the interoperability problems have generally been the result of poor implementation and failure to implement the spec rather than poor design. SMTP doesn't seem terribly efficient given todays network speeds (has too many round-trips) but the per-recipient verification was in fact an efficiency consideration - attempting to avoid transferring messages and nondelivery reports over the net for non-existent recipients. the thing that's missing from this statement is that SMTP was designed to be reasonably simple, hence the lock-step request-response model. anyway I don't think it's necessary to fix this text. Keith From owner-drums@cs.utk.edu Thu Jul 20 13:07:51 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00957 for ; Thu, 20 Jul 2000 13:07:50 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA17182; Thu, 20 Jul 2000 13:07:31 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 13:07:30 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA17163; Thu, 20 Jul 2000 13:07:29 -0400 (EDT) Received: from ns.secondary.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA17148; Thu, 20 Jul 2000 13:07:26 -0400 (EDT) Received: from ns.secondary.com (208.184.76.39 -> ns.secondary.com) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 13:07:27 -0400 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03471 for ; Thu, 20 Jul 2000 10:04:48 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <14711.1677.969089.868429@sws5.ctd.ornl.gov> References: <14711.1677.969089.868429@sws5.ctd.ornl.gov> Date: Thu, 20 Jul 2000 10:07:25 -0700 To: drums@cs.utk.edu From: Paul Hoffman / IMC Subject: Re: SMTP WG Last-Call Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: At 10:02 AM -0400 7/20/00, Dave Sill wrote: >I don't like them, either, but "retaliating" by refusing to consider >the objections on their merits is, I think, counterproductive. Not relative to the amount of time wasted on having the same arguments brought up over and over. The personal attacks usually ensue after Dan brings up an objection and doesn't get the level of agreement he wants. It's not "retaliating"; it is simply not wasting time. >Dismissing them without consideration only strengthens the attacker's >claims that their objections aren't being taking into consideration. We have no obligation to deal with anyone's personality traits in this WG. Dan is certainly not the only one here who has, um, ah, a strongly-opinionated stance to almost everything about 821/822. He is, however, the one who most visibly has no ability to move on when in the minority. >And, of course, the goal of producing the best documents/standards can >only be achieved by evaluating all input objectively. s/input/initial input/ Incessantly repeating arguments that have long ago been resolved does not help achieve the goal. Documenting them in an informational RFC would probably help, but I sincerely doubt that Dan wants to (given his past unhappiness with the RFC system) or is able to (given that such an RFC would require the editor to listen to and include the editorial comments of others). Such an Informational RFC would be a great project for an SMTP developer who is open-minded and wants to promote interoperability among current systems and to help future SMTP developers get it right. --Paul Hoffman, Director --Internet Mail Consortium From owner-drums@cs.utk.edu Thu Jul 20 13:54:01 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25732 for ; Thu, 20 Jul 2000 13:54:00 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA21894; Thu, 20 Jul 2000 13:53:41 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 13:53:39 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA21869; Thu, 20 Jul 2000 13:53:38 -0400 (EDT) Received: from lint.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA21855; Thu, 20 Jul 2000 13:53:35 -0400 (EDT) Received: from lint.cisco.com (171.68.224.209 -> lint.cisco.com) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 13:53:35 -0400 Received: from cisco.com (london-async18.cisco.com [144.254.38.157]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA09083; Thu, 20 Jul 2000 10:52:41 -0700 (PDT) Message-ID: <39773C1E.A22B87B4@cisco.com> Date: Thu, 20 Jul 2000 10:51:26 -0700 From: Eliot Lear Reply-To: lear@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "D. J. Bernstein" CC: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call References: <1461297.3173012530@nifty-jr.west.sun.com> <20000720001401.19958.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit I generally agree with Keith Moore. We've been around this block before, but nevertheless, this is the time in our process for objections. Consider this note largely speaking an endorsement of the document, but one or two touch-ups would be nice. There are two generic themes to Dan Bernstein's note. The first is that he offensively uses the term "Klensin says" when in reality John has done an extraordinary job of bringing together different views for what amounts to the singularly most visible project since IPng or HTTP1.1. I agree with others that I find it hard to navigate through such ad hominem (doubly so when I might agree with one of his points). The second is that Mr. Bernstein hides behind the phrase "breaks existing implementations". Some behavior is simply wrong and to do otherwise would cause MORE interoperability problems. The goal of the document is to improve interoperability. There is a natural tendency to test against existing implementations. However, we must avoid leaving sufficient ambiguity in the text that several independent implementations could be developed such that it would be impossible to interoperate amongst the group. A clean and clear spec. with as little wiggle room as possible is the best solution to this problem. By the way, Bernstein's own mailer is notoriously broken, in as much as it refuses valid messages from a valid source to a valid destination. Playing fast and lose with the rules only further confuses unwitting civilians for what amount to trivial reasons. So for the record, in the interests of space and time, unless otherwise indicated, I fully agree with Keith. Here are the exceptions and elaboration. Dan Bernstein complains about language that says that servers must deal with trivial loops. They must. Because indirection is part and parcel with alias and mailing list parsing, and because such indirection occurs across multiple hosts, you need some form of loop detection. John cites the obvious method. However, there are others. For instance, one can look to see how many times a message-id was processed over a fixed period of time or combine that approach with a destination hash. Each method has its own pitfalls but is better than nothing. The wording in the document demonstrates that this is implementation guidance and not The Idiot's Guide to SMTP. Dan Bernstein complains that prohibition of the user of VRFY in ESMTP without it being listed in the EHLO response is foolish, even though this is sound conservative architecture. More to the point- programs that attempt to use VRFY should use EHLO and not bother the server if it's not listed. Dan Bernstein complains that rejection of verbs with excess garbage on them is wrong, when in reality accepting them may well lead to unforeseen interoperability problems as well as security risks. What happens if there is a collision in the non-standard usage? That turns into an SMTP interoperability problem, about which Mr. Bernstein later complains. In fact, Mr. Bernstein is basing most of his objections on HIS implementation and not looking beyond it. The group has rightly looked beyond one implementation and provided for methods for Mr. Bernstein to deal with his implementation through the use of X- EHLO extensions. Dan Bernstein complains that the document requires SMTP agents to present themselves as full implementations. They should. Firewalls and "POP toasters" need to follow the same rules as everyone else so long as connections can occur in a way that was not pre-arranged. Consenting adults don't need standards. Dan Bernstein complains about the definition of mail relays. That definition is consistent with what we've said previously. Mention of QMTP or other protocols would be at best superfluous and at worst an endorsement of a non-IETF protocol. Dan Bernstein complains that we only endorse MIME as the structured format. For interoperability reasons, we should, especially since it is the ONLY IETF-endorsed structured format. Structure is most useful when others can understand it. Want to use your own? That's fine between consenting adults. Dan Bernstein complains that clients ought not use MX records when connecting to relays. Why? This is a perfectly fine use of an MX record and allows for a very simple mechanism for MULTIPLE relays with preference indication! In fact this point bothers me more than most, since a so-called implementor is making trade-offs against his potential customers. Please let there be no doubt. When we did RFC 1123 we weighed existing behavior against potential benefit to the user, and neither side had an infinite amount of weight. Dan Bernstein complains that the document restricts him from copying envelope information into the headers. That is correct, it does, in order to preserve blind carbon copy functionality. The reasoning for the objection has to do with multi-drop POP boxes. Isn't that POP's failure, not SMTP? It *is* possible to preserve envelope information at the end points, and that is strictly an end implementation decision. Dan Bernstein complains about the desire to move people to ESMTP. This is important, as more and more clients move to ESMTP, old code paths are going to get dusty. Let's move people away from it sooner than later. The notion that EHLO adds excessive complexity is beyond the pale. Especially in mail relays the benefits clearly outweigh the costs. Again, I pretty much agree with Keith on this point. And so I find myself in luke warm agreement with Dan Bernstein on several points, the QUIT businesses being two such points, as previously mentioned. VRFY and EXPN should be done away with, since at this point they can cause more harm than good, and we ought not encourage their use. Also, clients MUST send the appropriate code, and servers should be liberal in honoring 3xx. Finally, I agree with Dan Bernstein that SMTP is most certainly not the most efficient protocol. This follows the rule that specific optimizations always outperform general optimizations. SMTP must cover a broad number of cases and provide interoperability for implementations stretching back 15 years, a truly honerous task, one that Mr. Bernstein clearly does not appreciate. Y10K indeed. Let's see if we can make it to Y2.037k. -- Eliot Lear lear@cisco.com From owner-drums@cs.utk.edu Thu Jul 20 14:06:10 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02815 for ; Thu, 20 Jul 2000 14:06:09 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA23147; Thu, 20 Jul 2000 14:05:51 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 14:05:50 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA23124; Thu, 20 Jul 2000 14:05:50 -0400 (EDT) Received: from probity.mcc.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA23104; Thu, 20 Jul 2000 14:05:46 -0400 (EDT) Received: from probity.mcc.ac.uk (130.88.200.94 -> probity.mcc.ac.uk) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 14:05:46 -0400 Received: from nessie.mcc.ac.uk ([130.88.200.20] ident=root) by probity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 13FKhc-0000rz-00 for drums@cs.utk.edu; Thu, 20 Jul 2000 19:05:44 +0100 Received: from clw.cs.man.ac.uk (clerew.man.ac.uk [194.66.22.208]) by nessie.mcc.ac.uk (8.9.3/8.8.8) with ESMTP id TAA86813 for ; Thu, 20 Jul 2000 19:05:43 +0100 (BST) (envelope-from root@clw.cs.man.ac.uk) Received: (from root@localhost) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) id RAA24343 for drums@cs.utk.edu; Thu, 20 Jul 2000 17:54:13 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) with SMTP id RAA24340 for ; Thu, 20 Jul 2000 17:54:12 +0100 (BST) Message-Id: <200007201654.RAA24340@clw.cs.man.ac.uk> Date: Thu, 20 Jul 2000 17:54:12 +0100 (BST) From: Charles Lindsey Reply-To: Charles Lindsey Subject: Re: Comments on smtpupd-12 To: drums@cs.utk.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vrnXXpjRJIgqfQnf8BKfmA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc List-Unsubscribe: On Thu, 20 Jul 2000 06:05:50 -0400 Matti Aarnio said... > part 3.6.5: > > Add new paragraph to the end ? > > Usage of nationalized forms of "Re: " string in front of > the reply message "Subject: content is observed causing > awfull looking results in lenghty exchanges, especially > when there are people using differently nationalized mail > user agents: > > Subject: Re: Awt: Sv: Vs: topic text > > Therefore it is SUGGESTED that user agents sending email > do always use standard international form when sending, and > only do nationalizing of this prefix string at displaying > (and possibly printing) the email. In USEFOR we have written very strong words on this subject. Using anything other than "Re: " (case sensitive) is a definite No-No. And you cannot have a nationalized format for it, because it is already international (specifically, it is in Latin, being an abbreviation for "in re", or "in the matter of"). Indeed, we had to say as much in our draft, and the same should be said here. I believe the same discussion took place in relation to MESSFOR. Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-drums@cs.utk.edu Thu Jul 20 14:20:30 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10323 for ; Thu, 20 Jul 2000 14:20:30 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA24769; Thu, 20 Jul 2000 14:20:08 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 14:20:07 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA24748; Thu, 20 Jul 2000 14:20:06 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA24734; Thu, 20 Jul 2000 14:20:05 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> muncher.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 14:20:05 -0400 Received: (qmail 17086 invoked by uid 1001); 20 Jul 2000 18:20:11 -0000 Date: 20 Jul 2000 18:20:11 -0000 Message-ID: <20000720182011.21103.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call References: <1461297.3173012530@nifty-jr.west.sun.com> <20000720001401.19958.qmail@cr.yp.to> <4.3.2.20000720093729.00c02e20@mail.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Dave Crocker writes: > they run contrary to well-established *working group* consensus, There's no nice way to say this: Crocker is lying. He's perfectly aware that his claimed consensus has _not_ been established. He is, in fact, trying to _prevent_ the working group from settling these issues. ---Dan From owner-drums@cs.utk.edu Thu Jul 20 15:02:23 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00730 for ; Thu, 20 Jul 2000 15:02:22 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA28389; Thu, 20 Jul 2000 15:00:22 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 15:00:20 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA28371; Thu, 20 Jul 2000 15:00:20 -0400 (EDT) Received: from sws5.ctd.ornl.gov (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA28358; Thu, 20 Jul 2000 15:00:19 -0400 (EDT) Received: from sws5.ctd.ornl.gov (160.91.68.105 -> sws5.ctd.ornl.gov) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 15:00:19 -0400 Received: (qmail 78159 invoked by uid 3995); 20 Jul 2000 19:00:18 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14711.19522.423538.531808@sws5.ctd.ornl.gov> Date: Thu, 20 Jul 2000 15:00:18 -0400 (EDT) From: Dave Sill To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call In-Reply-To: <39773C1E.A22B87B4@cisco.com> References: <1461297.3173012530@nifty-jr.west.sun.com> <20000720001401.19958.qmail@cr.yp.to> <39773C1E.A22B87B4@cisco.com> X-Mailer: VM 6.75 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Organization: Oak Ridge National Lab, Oak Ridge, Tenn., USA X-Face: "p~Q]mg{;e*}YR|)&Q/&Q\*~5UWfZX34;5M Content-Transfer-Encoding: 7bit lear@cisco.com wrote: >The second is that Mr. Bernstein hides behind the phrase "breaks >existing implementations". Some behavior is simply wrong and to do >otherwise would cause MORE interoperability problems. The goal of the >document is to improve interoperability. How does a server accepting \012 as a terminator for client requests harm interoperability? Same thing for servers accepting requests containing underscores. How is interoperability improved by allowing only a single "OK" response code to DATA? >By the way, Bernstein's own mailer is notoriously broken, in as much as >it refuses valid messages from a valid source to a valid destination. Is that broken? I thought the destination MTA was allowed to bounce mail to any local address, valid or not. Do you have a pointer to the section in the draft that disallows bounces to valid addresses from valid sources? I'm sure the anti-spam crowd will object vocally to anything that makes bouncing spam illegal. And doesn't this also prevent servers from using mail quotas? -Dave From owner-drums@cs.utk.edu Thu Jul 20 15:18:56 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08987 for ; Thu, 20 Jul 2000 15:18:56 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA00131; Thu, 20 Jul 2000 15:18:40 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 15:18:39 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA00109; Thu, 20 Jul 2000 15:18:34 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA00096; Thu, 20 Jul 2000 15:18:32 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> muncher.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 15:18:32 -0400 Received: (qmail 17575 invoked by uid 1001); 20 Jul 2000 19:18:54 -0000 Date: 20 Jul 2000 19:18:54 -0000 Message-ID: <20000720191854.19936.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Nick Shelness/SSW/Lotus writes: > In the case of Dan's points, they all involve changes to the base line, That's not even close to being true. Most of my objections are to text added by Klensin. Some of my objections are to text that looks the same but where Klensin has changed some crucial definitions. ---Dan From owner-drums@cs.utk.edu Thu Jul 20 15:27:45 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13170 for ; Thu, 20 Jul 2000 15:27:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA01078; Thu, 20 Jul 2000 15:27:28 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 15:27:28 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA01061; Thu, 20 Jul 2000 15:27:28 -0400 (EDT) Received: from draco.cus.cam.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA01043; Thu, 20 Jul 2000 15:27:25 -0400 (EDT) Received: from draco.cus.cam.ac.uk (131.111.8.18 -> draco.cus.cam.ac.uk) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 15:27:26 -0400 Received: from ph10 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 3.16 #3) id 13FLyd-00004p-00; Thu, 20 Jul 2000 20:27:23 +0100 Date: Thu, 20 Jul 2000 20:27:23 +0100 (BST) From: Philip Hazel To: Keith Moore cc: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call In-Reply-To: <200007201645.MAA04825@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: On Thu, 20 Jul 2000, Keith Moore wrote: > finally a client that aborts a connection without sending QUIT > MUST NOT treat the messages which were transmitted in that session as > if they were transferred to the server. Surely not? Once a client has received an OK response to the final "." for a message, the server takes responsibility, whatever happens, doesn't it? Consider: EHLO MAIL RCPT DATA message 1 . MAIL RCPT DATA .... Suppose at this point the client discovers that can't read its disk. All it can do is break the the connection, but message 1 is long gone; the server may even have delivered it already. -- Philip Hazel University of Cambridge Computing Service, ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. From owner-drums@cs.utk.edu Thu Jul 20 15:36:30 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17838 for ; Thu, 20 Jul 2000 15:36:30 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA02316; Thu, 20 Jul 2000 15:36:17 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 15:36:17 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA02299; Thu, 20 Jul 2000 15:36:16 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA02279; Thu, 20 Jul 2000 15:36:14 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 15:36:14 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA07259; Thu, 20 Jul 2000 15:36:12 -0400 (EDT) Message-Id: <200007201936.PAA07259@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Philip Hazel cc: Keith Moore , drums@cs.utk.edu Subject: Re: SMTP WG Last-Call In-reply-to: Your message of "Thu, 20 Jul 2000 20:27:23 BST." Date: Thu, 20 Jul 2000 15:36:12 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > > finally a client that aborts a connection without sending QUIT > > MUST NOT treat the messages which were transmitted in that session as > > if they were transferred to the server. > > Surely not? Once a client has received an OK response to the final "." > for a message, the server takes responsibility, whatever happens, > doesn't it? sorry, I sent the message prematurely. I meant to go back and fix this. I was originally trying to make a case for MUST NOT, but I wasn't able to do it. Keith From owner-drums@cs.utk.edu Thu Jul 20 15:52:55 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25957 for ; Thu, 20 Jul 2000 15:52:54 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA04657; Thu, 20 Jul 2000 15:52:40 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 15:52:39 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA04631; Thu, 20 Jul 2000 15:52:38 -0400 (EDT) Received: from prognet.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA04614; Thu, 20 Jul 2000 15:52:35 -0400 (EDT) Received: from prognet.com (205.219.198.1 -> prognet.com) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 15:52:36 -0400 Received: from mscharff.real.com ([172.22.104.48]) by prognet.com (8.9.2/8.9.0) with ESMTP id MAA13845 for ; Thu, 20 Jul 2000 12:52:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20000721124625.00afd5f0@mail.real.com> X-Sender: mscharff@mail.real.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 12:53:52 +0100 To: drums@cs.utk.edu From: Michael Scharff Subject: Re: SMTP WG Last-Call In-Reply-To: References: <200007201645.MAA04825@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: Were we to follow the logic that Keith presents, then any messages transmitted during a session that did not complete with a proper QUIT would be resent. This would result in a harrowing number of duplicate messages being received on the recipient side, not to mention the inefficiency of such logic on the server end. Most servers I've worked with WILL deliver ANY message that was "received" i.e. a CR/LF . CR/LF was received allowing the server to end receipt of that particular message, whether or not a QUIT was received to end the session. The reasons for this are numerous, but the most obvious is the fact that there are still a very large number of users on the internet who establish their connection via Dialup. This is unreliable at best, and "drops" in the middle of a session are quite frequent. A nightmare in the making so to speak. Michael Scharff RealNetworks mscharff@real.com At 08:27 PM 7/20/00 +0100, Philip Hazel wrote: >On Thu, 20 Jul 2000, Keith Moore wrote: > > > finally a client that aborts a connection without sending QUIT > > MUST NOT treat the messages which were transmitted in that session as > > if they were transferred to the server. > >Surely not? Once a client has received an OK response to the final "." >for a message, the server takes responsibility, whatever happens, >doesn't it? Consider: > >EHLO >MAIL >RCPT >DATA >message 1 >. >MAIL >RCPT >DATA >.... Suppose at this point the client discovers that can't read its disk. >All it can do is break the the connection, but message 1 is long gone; >the server may even have delivered it already. > >-- >Philip Hazel University of Cambridge Computing Service, >ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. From owner-drums@cs.utk.edu Thu Jul 20 15:53:45 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26355 for ; Thu, 20 Jul 2000 15:53:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA04794; Thu, 20 Jul 2000 15:53:30 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 15:53:30 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA04777; Thu, 20 Jul 2000 15:53:29 -0400 (EDT) Received: from prognet.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA04740; Thu, 20 Jul 2000 15:53:26 -0400 (EDT) Received: from prognet.com (205.219.198.1 -> prognet.com) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 15:53:26 -0400 Received: from mscharff.real.com ([172.22.104.48]) by prognet.com (8.9.2/8.9.0) with ESMTP id MAA14242; Thu, 20 Jul 2000 12:53:35 -0700 (PDT) Message-Id: <4.3.2.7.2.20000721125417.00b009d0@mail.real.com> X-Sender: mscharff@mail.real.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 12:54:42 +0100 To: Keith Moore , Philip Hazel From: Michael Scharff Subject: Re: SMTP WG Last-Call Cc: Keith Moore , drums@cs.utk.edu In-Reply-To: <200007201936.PAA07259@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: Well then, I'll apologize in advance for the message I just sent, reasoning why this was such a bad idea At 03:36 PM 7/20/00 -0400, Keith Moore wrote: > > > finally a client that aborts a connection without sending QUIT > > > MUST NOT treat the messages which were transmitted in that session as > > > if they were transferred to the server. > > > > Surely not? Once a client has received an OK response to the final "." > > for a message, the server takes responsibility, whatever happens, > > doesn't it? > >sorry, I sent the message prematurely. I meant to go back and fix this. > >I was originally trying to make a case for MUST NOT, but I wasn't >able to do it. > >Keith From owner-drums@cs.utk.edu Thu Jul 20 16:17:23 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08860 for ; Thu, 20 Jul 2000 16:17:23 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA07819; Thu, 20 Jul 2000 16:16:20 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 16:16:19 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA07801; Thu, 20 Jul 2000 16:16:18 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA07788; Thu, 20 Jul 2000 16:16:17 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 16:16:17 -0400 Received: (qmail 2161 invoked by uid 1001); 20 Jul 2000 20:16:38 -0000 Date: 20 Jul 2000 20:16:38 -0000 Message-ID: <20000720201638.5591.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: DATA 387 References: <1461297.3173012530@nifty-jr.west.sun.com> <20000720001401.19958.qmail@cr.yp.to> <39773C1E.A22B87B4@cisco.com> <14711.19522.423538.531808@sws5.ctd.ornl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: > allowing only a single "OK" response code to DATA Just to clarify: Everyone agrees that the _protocol_ should prohibit the server from sending, say, 387. The question is whether the _client_ is permitted to accept 387 from a broken server. Please be careful to distinguish what the _protocol_ allows the server to do from what the _client_ might allow the server to do. If the server sends 387 (bad!), the server is violating RFC 821. If the client then treats the 387 as 354 (good! this simplifies the client code, and is encouraged), the client is not violating RFC 821. But it is violating Klensin's spec. It's reasonably clear what Klensin was thinking when he wrote this text. Legitimate servers will occasionally send things like 451 in response to DATA. Clients have to be ready for this. Sending the message after 4xx or 5xx would be a disaster. Clients MUST NOT do that. But Klensin's text is overbroad. He didn't just prohibit sending the message after 4xx or 5xx. He singled out 354. Existing clients that treat all 3xx codes the same way (e.g., exim) are in violation of Klensin's spec. Existing clients that treat all codes below 400 the same way (e.g., qmail) are in violation of Klensin's spec. Procedural matters: Klensin made this change from RFC 821 without the consensus of the working group. When I pointed out Klensin's change more than a year ago, several people agreed with me that clients shouldn't be forced to inspect the 54, and nobody disagreed. But the document still has Klensin's change. ---Dan From owner-drums@cs.utk.edu Thu Jul 20 18:35:40 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14896 for ; Thu, 20 Jul 2000 18:35:40 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA19536; Thu, 20 Jul 2000 18:35:23 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 18:35:21 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA19517; Thu, 20 Jul 2000 18:35:20 -0400 (EDT) Received: from windlord.stanford.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA19504; Thu, 20 Jul 2000 18:35:18 -0400 (EDT) Received: from windlord.stanford.edu (171.64.12.23 -> windlord.Stanford.EDU) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 18:35:18 -0400 Received: (qmail 14807 invoked by uid 50); 20 Jul 2000 22:35:16 -0000 To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call References: <4.3.2.20000720225612.00bc15f0@mail.bayarea.net> In-Reply-To: Dave Crocker's message of "Thu, 20 Jul 2000 22:59:16 +0900" From: Russ Allbery Organization: The Eyrie Date: 20 Jul 2000 15:35:16 -0700 Message-ID: Lines: 30 User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Dave Crocker writes: > two, yes. and a third has chimed in. Make it four on several of these points. > That is, working group consensus was consistently and massively against > those concerns. That is not in agreement with my reading of this working group for the time that I've been here. The working group consensus was consistently and massively against the way in which the concerns were presented, but I think some of these are good points, and do not have a consensus against them. I personally don't have an interest in belaboring these points further because I think at this stage it's considerably more important to the rest of the Internet to get an RFC *published* than to deal with these issues, which I think are by and large minor and can possibly be dealt with in a later revision. But I do feel like I have to chime in given the assertion that no one agreed with any of Dan's points. If someone wants to try to make minor revisions at this stage, Philip Hazel's summary is one that I also generally agree with. If the choice is to not do that due to how late this is in the process, I also agree with that. I've enough experience with IETF working groups to know that if the goal is to get the RFC perfect, there will never actually be an RFC. -- Russ Allbery (rra@stanford.edu) From owner-drums@cs.utk.edu Thu Jul 20 18:54:12 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23159 for ; Thu, 20 Jul 2000 18:54:12 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA21796; Thu, 20 Jul 2000 18:53:41 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 18:53:41 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA21779; Thu, 20 Jul 2000 18:53:40 -0400 (EDT) Received: from golux.thyrsus.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id SAA21766; Thu, 20 Jul 2000 18:53:35 -0400 (EDT) Received: from golux.thyrsus.com (12.23.69.102) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 18:53:35 -0400 Received: (from esr@localhost) by golux.thyrsus.com (8.9.3/8.9.3) id TAA13549; Thu, 20 Jul 2000 19:13:56 -0400 Date: Thu, 20 Jul 2000 19:13:56 -0400 From: esr@thyrsus.com To: Russ Allbery Cc: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call Message-ID: <20000720191356.E13412@thyrsus.com> Reply-To: esr@thyrsus.com References: <4.3.2.20000720225612.00bc15f0@mail.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3us In-Reply-To: Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy List-Unsubscribe: Russ Allbery : > Dave Crocker writes: > > > two, yes. and a third has chimed in. > > Make it four on several of these points. > > > That is, working group consensus was consistently and massively against > > those concerns. > > That is not in agreement with my reading of this working group for the > time that I've been here. The working group consensus was consistently > and massively against the way in which the concerns were presented, but I > think some of these are good points, and do not have a consensus against > them. Make it five because I too agree. Dan's style is deeply obnoxious but some of his technical points have merit. We should not succumb to the temptation to shoot the messenger. -- Eric S. Raymond The price of liberty is, always has been, and always will be blood. The person who is not willing to die for his liberty has already lost it to the first scoundrel who is willing to risk dying to violate that person's liberty. Are you free? -- Andrew Ford From owner-drums@cs.utk.edu Thu Jul 20 20:19:12 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28148 for ; Thu, 20 Jul 2000 20:19:12 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA27844; Thu, 20 Jul 2000 20:17:41 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 20:17:40 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA27827; Thu, 20 Jul 2000 20:17:39 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id UAA27813; Thu, 20 Jul 2000 20:17:36 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 20:17:37 -0400 Received: from dhcp-065042.wireless-conference.inet2000.gr.jp (dhcp-065042.wireless-conference.inet2000.gr.jp [133.195.65.42]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id RAA18531; Thu, 20 Jul 2000 17:16:58 -0700 X-Authentication-Warning: joy.songbird.com: dhcp-065042.wireless-conference.inet2000.gr.jp [133.195.65.42] didn't use HELO protocol Message-Id: <4.3.2.20000721084442.00c046c0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 21 Jul 2000 09:09:36 +0900 To: Russ Allbery From: Dave Crocker Subject: Re: SMTP WG Last-Call Cc: drums@cs.utk.edu In-Reply-To: References: <4.3.2.20000720225612.00bc15f0@mail.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 03:35 PM 7/20/00 -0700, Russ Allbery wrote: >That is not in agreement with my reading of this working group for the >time that I've been here. Out of curiosity: Over what proportion of the life of this working group have you been monitoring the working group's treatment of input from a participant who prefers ad hominems, at the level of calling other participants liars and presuming to know their motives, always claiming them base? >The working group consensus was consistently >and massively against the way in which the concerns were presented, but I >think some of these are good points, and do not have a consensus against >them. I am surprised you have not noted the working group's long history of trying to wade through the morass of aggressive ad hominems to find an occasional gem of valid technical content. The work of the group has been delayed by, perhaps, a year due to this distraction. As well, the overall ability to conduct coherent discussion has been impaired, likely damaging the coherence of the resulting document, in spite of considerable effort by the editors to counteract the problem. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Thu Jul 20 21:02:36 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13266 for ; Thu, 20 Jul 2000 21:02:36 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA00862; Thu, 20 Jul 2000 21:02:19 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 20 Jul 2000 21:02:17 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA00843; Thu, 20 Jul 2000 21:02:17 -0400 (EDT) Received: from windlord.stanford.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA00829; Thu, 20 Jul 2000 21:02:15 -0400 (EDT) Received: from windlord.stanford.edu (171.64.12.23 -> windlord.Stanford.EDU) by cs.utk.edu (smtpshim v1.0); Thu, 20 Jul 2000 21:02:15 -0400 Received: (qmail 15402 invoked by uid 50); 21 Jul 2000 01:02:13 -0000 To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call References: <4.3.2.20000721084442.00c046c0@mail.bayarea.net> In-Reply-To: Dave Crocker's message of "Fri, 21 Jul 2000 09:09:36 +0900" From: Russ Allbery Organization: The Eyrie Date: 20 Jul 2000 18:02:13 -0700 Message-ID: Lines: 49 User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Dave Crocker writes: > Out of curiosity: Over what proportion of the life of this working > group have you been monitoring the working group's treatment of input > from a participant who prefers ad hominems, at the level of calling > other participants liars and presuming to know their motives, always > claiming them base? I think the working group has by and large done a very good job of this. I didn't mean to imply otherwise. >> The working group consensus was consistently and massively against the >> way in which the concerns were presented, but I think some of these are >> good points, and do not have a consensus against them. > I am surprised you have not noted the working group's long history of > trying to wade through the morass of aggressive ad hominems to find an > occasional gem of valid technical content. I have. That was precisely my point. People have objected to the way in which concerns were presented but have *not* objected to some of the specific concerns that were raised. In other words, there has been working group consensus against the *tone* of some of the discussions here, but there has *not* been working group consensus against every proposal raised in an unnecessarily confrontational manner. Quite to the contrary, the working group has, in my opinion, done a fairly good job of separating the content from the presentation. Accordingly, I don't agree with the statement that there has been an overwhelming consensus against all of Dan's positions. I think there is a consensus against some of them, I think that some of them have been put aside as good enough and not worth the time to debate further (like whether clients should be required in the standard to issue QUIT), and I think that some of them could still be merged into the existing draft. The ones in the latter category have also been singled out by Keith Moore and Philip Hazel. Again, I'm not personally asking that this be done. I'm content either way. As I said, I think the most important goal is to get this draft finally published, and that the world needs that more than it needs corrections to how clients are allowed to handle 387. That's just my personal opinion. It is precisely because I *don't* think the working group has overall put personality above producing a solid technical specification that I can't agree with your characterization. -- Russ Allbery (rra@stanford.edu) From owner-drums@cs.utk.edu Fri Jul 21 00:08:51 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20304 for ; Fri, 21 Jul 2000 00:08:50 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA10976; Fri, 21 Jul 2000 00:08:30 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 21 Jul 2000 00:08:25 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA10942; Fri, 21 Jul 2000 00:08:24 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA10925; Fri, 21 Jul 2000 00:08:22 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Fri, 21 Jul 2000 00:08:23 -0400 Received: (qmail 9995 invoked by uid 1001); 21 Jul 2000 04:08:44 -0000 Date: 21 Jul 2000 04:08:44 -0000 Message-ID: <20000721040844.21404.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call References: <20000720001401.19958.qmail@cr.yp.to> <200007201645.MAA04825@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Keith Moore writes: [ about Klensin allowing clients to send 821-violating HELO syntax ] [ that some existing servers will reject, destroying mail service ] > IIRC, the WG discussed this at one point and came up with some language > very similar to the current smtpupd draft. Really? Where exactly can I find that language in the DRUMS archives? My servers accept all sorts of HELO garbage, of course, so I won't have problems with clients that use Klensin's extended syntax. But the AOL servers say helo [1.2.3.4] this is a test. 501 SYNTAX ERROR IN PARAMETERS OR ARGUMENTS and I think it's thoroughly irresponsible to hide this fact from future implementors. This is not a minor issue. This is an interoperability disaster. I've pointed it out repeatedly and it still isn't fixed. [ servers accepting \012 as a line terminator for client requests ] > introduces the possibility of synchronization errors. No, it doesn't. As I said, clients do not (and, in practice, cannot) use \012 inside requests except as a line terminator. [ Klensin says SMTP servers ``MUST reject'' underscores ] > The purpose of a standard is to specify how things should behave, not > to document all of the brain-damage that has been observed. Please be careful to distinguish _clients sending underscores_ from _servers accepting underscores_. The client is violating RFC 821. The server is not violating RFC 821. The server behavior is good. Klensin prohibits the server behavior. This is a change from RFC 821. It's a bad change. It's also a change without working group consensus. [ client -> smarthost ---dialup--> ISP, when users mistype domain names ] > Those clients are not following the standard. That's ridiculous. The clients don't have any way to check that the names are valid. The smarthost doesn't offer the feature, and the client computers don't have their own modems. The smarthost will eventually bounce the message, because the domain doesn't exist. Does this mean that the client did something wrong? Of course not. But Klensin insists that all domain names be ``resolvable.'' > > Klensin says that servers ``MUST support the EHLO command even if > > they do not implement any specific extensions.'' > this is entirely appropriate. the implementation burden is small. I agree that it's easy to implement. However, that doesn't justify the requirement. Servers work even if they don't support EHLO. [ relays are normally identified by name; ``SHOULD'' use MX instead? ] > we need to distinguish [ dumb clients ] You misunderstand. Klensin really does think that dumb clients should be feeding their configured relay names to MX lookups. He even claimed, as I recall, that this was common MUA behavior. > > clients that have no need for extensions can and should > > start with HELO; EHLO adds quite a bit of unnecessary complexity. > actually, that's false Actually, what I said is true. Go read the ESMTP specification. Multiline responses are not the issue. > I think the assumption is that a SMTP-capable host is a normal MTA Bad assumption. Many SMTP-capable hosts don't support mailing lists. Anyway, this is not an interoperability issue. [ RSET, DATA, QUIT ] > clients that supply parameters to these commands may be expecting > behavior that the server is not prepared to support. You're talking about noncompliant behavior by nonexistent clients. Who cares what they expect? Why should we make this change to RFC 821? > I don't think of firewalls and POP toasters as 'fully-capable SMTP > implementations'. I don't think of sendmail as a fully-capable SMTP implementation. :-) ---Dan From owner-drums@cs.utk.edu Fri Jul 21 01:31:35 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29791 for ; Fri, 21 Jul 2000 01:31:35 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id BAA14412; Fri, 21 Jul 2000 01:31:15 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 21 Jul 2000 01:31:13 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id BAA14395; Fri, 21 Jul 2000 01:31:13 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id BAA14382; Fri, 21 Jul 2000 01:31:12 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Fri, 21 Jul 2000 01:31:12 -0400 Received: (qmail 11581 invoked by uid 1001); 21 Jul 2000 05:31:32 -0000 Date: 21 Jul 2000 05:31:32 -0000 Message-ID: <20000721053132.18930.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call References: <1461297.3173012530@nifty-jr.west.sun.com> <20000720001401.19958.qmail@cr.yp.to> <39773C1E.A22B87B4@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Eliot Lear writes: > programs that attempt to use VRFY > should use EHLO and not bother the server if it's not listed. No! Programs that want to use VRFY should simply try it. Programs that behave as you suggest will fail miserably and be discarded by users. > you need some form of loop detection. I can't respond to your alleged justifications until I see a coherent definition of the phrase ``some form of loop detection.'' > Mr. Bernstein is basing most of his objections on HIS implementation False. Half of my objections are on issues that don't affect my code. The other half are on issues that affect other people's code too. > By the way, Bernstein's own mailer is notoriously broken, in as much as > it refuses valid messages from a valid source to a valid destination. Huh? I'm under no obligation to accept your messages. > a so-called implementor This ``so-called implementor'' wrote an SMTP server now running on more than one hundred thousand computers around the Internet. > offensively uses the term "Klensin says" Let's try an example: Klensin says ``Servers MUST NOT return the extended EHLO-style response to a HELO command.'' This is a simple statement of fact about Klensin's document. It seems to be true. Why do you find it offensive? You then assert that this is ``ad hominem.'' Here you're simply wrong. You are, in fact, making a fool of yourself. > Mr. Bernstein hides behind the phrase "breaks > existing implementations". Some behavior is simply wrong and to do > otherwise would cause MORE interoperability problems. I'm not sure what you mean by ``hides'' here. My objections are to (1) Klensin requiring or allowing non-interoperable behavior, (2) Klensin prohibiting safe behavior, (3) Klensin discouraging safe behavior, and (4) Klensin misleading readers. In #1, there's ample evidence that the behavior causes interoperability failures. Are you seriously suggesting that such breakage be allowed? In #2 and #3, the behavior is widely used, and there's not a shred of evidence that it causes interoperability problems. Are you seriously suggesting that users be forced to install new software for no benefit? It would help if you focused on concrete examples, instead of referring to ``some'' unspecified behavior. ---Dan From owner-drums@cs.utk.edu Fri Jul 21 01:51:53 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12855 for ; Fri, 21 Jul 2000 01:51:53 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id BAA15529; Fri, 21 Jul 2000 01:51:29 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 21 Jul 2000 01:51:28 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id BAA15511; Fri, 21 Jul 2000 01:51:28 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id BAA15498; Fri, 21 Jul 2000 01:51:27 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Fri, 21 Jul 2000 01:51:27 -0400 Received: (qmail 3578 invoked by uid 1001); 21 Jul 2000 05:51:48 -0000 Date: 21 Jul 2000 05:51:48 -0000 Message-ID: <20000721055148.11725.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call References: <20000720001401.19958.qmail@cr.yp.to> <200007201645.MAA04825@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Keith Moore writes: > It's the document editor's job to state concrete positions on subtle > issues and see whether the working group supports those positions. In a legitimate standards organization, it is the document editor's job to record the established consensus of the group---and there are procedures in place to prevent them, and you, from misrepresenting the conesnsus. > I'm always amused (not) when Dan calls his own opinions "reality" Let's go back to the videotape, and see how the word ``reality'' was actually used: In reality, for interoperability with existing clients, servers recognize \012 as a line terminator ... In reality, for interoperability with existing clients, servers accept (for example) EHLO requests containing underscores. ... In reality, if an SMTP client is in the middle of sending a message, and is unable to read the next portion of the message from disk, it ruthlessly closes the connection. ... In reality, as of 1999, approximately 90% of the servers that support both VRFY and EHLO do not list VRFY in response to EHLO. ... In reality, servers that do not support EHLO are still able to receive mail. ... In reality, clients that have no need for extensions can and should start with HELO; EHLO adds quite a bit of unnecessary complexity. ... In reality, EXPN is obsolete. Thousands of the most heavily used mail servers on the Internet always respond 502 to EXPN. ... In reality, VRFY is obsolete. Thousands of the most heavily used mail servers on the Internet always respond 252 to VRFY. ... In reality, thousands of SMTP clients close the connection immediately after sending QUIT. ... In reality, connections are abruptly dropped for a wide variety of reasons, including server shutdowns. ... In reality, firewalls and POP toasters do not, and should not, support mailing lists. ... In reality, thousands of SMTP servers ignore such parameters. ... In reality, firewalls and POP toasters often run pure SMTP servers. They do not send mail through SMTP, and they are not expected to support any SMTP client features. Installing unused code is a violation of some corporate security policies. ... In reality, many relays support other protocols for transferring Internet mail messages, such as QMTP. ... In reality, there are many common non-MIME body structures. ... In reality, there will be a year 10000. You think these are ``opinions''? ---Dan From owner-drums@cs.utk.edu Fri Jul 21 02:40:12 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17612 for ; Fri, 21 Jul 2000 02:40:12 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id CAA17607; Fri, 21 Jul 2000 02:38:43 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 21 Jul 2000 02:38:41 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id CAA17590; Fri, 21 Jul 2000 02:38:40 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id CAA17577; Fri, 21 Jul 2000 02:38:39 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> muncher.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Fri, 21 Jul 2000 02:38:39 -0400 Received: (qmail 18250 invoked by uid 1001); 21 Jul 2000 06:39:00 -0000 Date: 21 Jul 2000 06:39:00 -0000 Message-ID: <20000721063900.23233.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call References: <14711.1677.969089.868429@sws5.ctd.ornl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Paul Hoffman / IMC writes: > help future SMTP developers get it right. http://cr.yp.to/smtp.html http://cr.yp.to/immhf.html http://cr.yp.to/im.html These pages cover every interoperability issue I've seen. The IETF specifications, unfortunately, don't even come close. > Incessantly repeating arguments that have long ago been resolved Which ones are you talking about? When, exactly, were they resolved? Please be specific. One issue has certainly been resolved: the wait-for-QUIT-response issue. The group decided against Klensin's change in August 1998. The reason I keep bringing this up is that Klensin _still_ hasn't fixed his document. Part of the VRFY issue has also been resolved: ten people have objected to Klensin's change. Obviously that change has to be undone. But we'd also like 821bis to say clearly that SMTP servers need not support informative responses to VRFY requests. This is the overwhelming majority view among implementors, and probably among DRUMS participants, but Newman hasn't allowed it to be discussed at a meeting. ---Dan From owner-drums@cs.utk.edu Fri Jul 21 04:07:17 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05788 for ; Fri, 21 Jul 2000 04:07:17 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id EAA24943; Fri, 21 Jul 2000 04:07:02 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 21 Jul 2000 04:07:00 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id EAA24926; Fri, 21 Jul 2000 04:07:00 -0400 (EDT) Received: from qualcomm.co.nz (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id EAA24912; Fri, 21 Jul 2000 04:06:56 -0400 (EDT) Received: from qualcomm.co.nz (203.97.196.98 -> doom.qualcomm.co.nz) by cs.utk.edu (smtpshim v1.0); Fri, 21 Jul 2000 04:06:56 -0400 Received: from [203.97.196.100] (203.97.196.100) by qualcomm.co.nz with ESMTP (Eudora Internet Mail Server 3.0.1b2) for ; Fri, 21 Jul 2000 20:06:48 +1200 Mime-Version: 1.0 X-Sender: glenn@qualcomm.co.nz@mail.qualcomm.co.nz Message-Id: In-Reply-To: <20000721055148.11725.qmail@cr.yp.to> References: <20000720001401.19958.qmail@cr.yp.to> <200007201645.MAA04825@astro.cs.utk.edu> <20000721055148.11725.qmail@cr.yp.to> Date: Fri, 21 Jul 2000 20:04:29 +1200 To: drums@cs.utk.edu From: Glenn Anderson Subject: Re: SMTP WG Last-Call Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: > In reality, for interoperability with existing clients, servers > recognize \012 as a line terminator ... In reality, thousands of SMTP servers do not recognise \012 as a line terminator. Clients that use just \012 as a line terminator are broken and should be fixed. Glenn. From owner-drums@cs.utk.edu Fri Jul 21 05:41:08 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00730 for ; Fri, 21 Jul 2000 05:41:07 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA01763; Fri, 21 Jul 2000 05:39:30 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 21 Jul 2000 05:39:21 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id FAA01728; Fri, 21 Jul 2000 05:39:20 -0400 (EDT) Received: from lotus2.lotus.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id FAA01702; Fri, 21 Jul 2000 05:39:17 -0400 (EDT) Received: from lotus2.lotus.com (192.233.136.8 -> lotus2.lotus.com) by cs.utk.edu (smtpshim v1.0); Fri, 21 Jul 2000 05:39:17 -0400 Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id FAA29928; Fri, 21 Jul 2000 05:40:25 -0400 (EDT) Received: from a3mail.lotus.com (A3MAIL.lotus.com [9.95.5.66]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id FAA17665; Fri, 21 Jul 2000 05:39:14 -0400 (EDT) To: "D. J. Bernstein" Cc: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call X-Mailer: Lotus Notes Build V505_07112000 July 11, 2000 From: "Nick Shelness/SSW/Lotus" Message-ID: Date: Fri, 21 Jul 2000 05:39:05 -0400 X-MIMETrack: Serialize by Router on A3MAIL/CAM/H/Lotus(Build V505_07062000 |July 6, 2000) at 07/21/2000 05:41:51 AM, Serialize complete at 07/21/2000 05:41:51 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: Dan, Now that you have now produced a list of concerns minus personal attacks, I will respond. 1. > In reality, for interoperability with existing clients, servers > recognize \012 as a line terminator ... This is true, but is independent of whether it should be required under the standard. I believe that we reached rough consensus that under the standard, be the only valid command terminator. 2. > In reality, for interoperability with existing clients, servers > accept (for example) EHLO requests containing underscores. ... Again, this is true, but is independent of whether it should be required under the standard. I believe that we reached consensus that under the standard EHLO requests MUST NOT contain underscores. 3. > In reality, if an SMTP client is in the middle of sending a message, > and is unable to read the next portion of the message from disk, it > ruthlessly closes the connection. ... Again, this is true, and the standard should and does state what a server and client should do when a connection is closed prior to the transmission of a QUIT and receipt of a QUIT response. To that end, I think that the text in the final paragraph of section 3.9 (the only one that addresses client behavior) could be expanded slightly to make it clear that there are environmental circumstances (in addition to those listed) beyond a client's control that may require it to terminate a connection. For example, SMTP clients that experience events beyond their control, such as an unrecoverable disk read failure, a notification of impeding system shutdown,> a connection close, a connection reset, or other type communications failure (in violation of the intent of this specification but sometimes unavoidable) SHOULD, to maintain the robustness of the mail system, treat the mail transaction as if a 451 response had been received and act accordingly. But fundamentally, this was never at issue. What was at issue is whether it was valid under the standard for a client to tear down a connection after receiving a positive response to a . and with out sending a QUIT and receiving a response. Again, I believe that rough consensus was reached that it was not. 4. > In reality, as of 1999, approximately 90% of the servers that support > both VRFY and EHLO do not list VRFY in response to EHLO. ... So. There was no rough consensus that VRFY and/or EXPN be dropped from the standard. I would quite happily see them both dropped, but there wasn't enough support to do so. What there was rough consensus on was, that under RFC 821bis servers that support EHLO and VRFY MUST announce VRFY support in an EHLO response. 5. > In reality, servers that do not support EHLO are still able to > receive mail. ... Absolutely, but again there was rough consensus that RFC 821bis should encourage the infrastructure to move to employing EHLO in place of HELO. 6. > In reality, clients that have no need for extensions can and should > start with HELO; EHLO adds quite a bit of unnecessary complexity. ... I have no objection to your use of the word "can", but again there was rough consensus that RFC 821bis should encourage the infrastructure to move to employing EHLO in place of HELO. 7. > In reality, EXPN is obsolete. Thousands of the most heavily used mail > servers on the Internet always respond 502 to EXPN. ... See my response to 4. above 8. > In reality, VRFY is obsolete. Thousands of the most heavily used mail > servers on the Internet always respond 252 to VRFY. ... See my response to 4. above 9. > In reality, thousands of SMTP clients close the connection > immediately after sending QUIT. ... See my response to 3. above. 10. > In reality, connections are abruptly dropped for a wide variety of > reasons, including server shutdowns. ... Absolutely. See my response to 3 above. The question is whether, in the absence of abnormal events beyond the control of an SMTP client or server task, it is valid under the standard to drop a connection prior to a client sending a QUIT and receiving a response. Again, there was not rough consensus to make such a change from RFC 821. 11. > In reality, firewalls and POP toasters do not, and should not, > support mailing lists. ... In the case of firewalls, as long as they are completely transparent at the connection and command level to an SMTP client and server, RFC 821bis is silent as it should be. Where an SMTP relay is deployed as a firewall, then it SHOULD (MUST?) comply with the standard. POP toasters are beyond the scope of drums. 12. > In reality, thousands of SMTP servers ignore such parameters. ... Yes, but? 13. > In reality, firewalls and POP toasters often run pure SMTP servers. > They do not send mail through SMTP, and they are not expected to > support any SMTP client features. Installing unused code is a > violation of some corporate security policies. ... RFC 821bis describes on the wire behavior. Thus, an SMTP server need only support on the wire RFC 821bis server features, and an SMTP client need only support on the wire RFC 821bis client features. Where's the problem? 14. > In reality, many relays support other protocols for transferring > Internet mail messages, such as QMTP. ... Certainly true, though within the nomenclature of RFC 821bis these would be gateways rather than relays. They may be completely transparent gateways, but they are gateways none the less. Gateway behavior beyond their SMTP client or server behavior is not within the scope of RFC 821bis 15. > In reality, there are many common non-MIME body structures. ... This is also true, but again rough consensus was reached within the working group that RCF 821bis and 822bis should strongly encourage the use of MIME, to the exclusion of all other body structures. 16. > In reality, there will be a year 10000. Yup 17. > You think these are ``opinions''? In general you state a fact (a reality in your terminology). This is then almost always followed by an opinion. I think that Keith was referring to your opinions as opinions. Your facts are certainly facts. Nick Nick Shelness, IBM Fellow Chief Technology Officer Lotus Development Corp Tel: (617) 693-7484 Assistant: Mary McGurran Tel: (617) 693-4321 From owner-drums@cs.utk.edu Fri Jul 21 05:45:57 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03560 for ; Fri, 21 Jul 2000 05:45:57 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA01759; Fri, 21 Jul 2000 05:39:30 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 21 Jul 2000 05:39:20 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id FAA01727; Fri, 21 Jul 2000 05:39:20 -0400 (EDT) Received: from lotus2.lotus.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id FAA01700; Fri, 21 Jul 2000 05:39:17 -0400 (EDT) Received: from lotus2.lotus.com (192.233.136.8 -> lotus2.lotus.com) by cs.utk.edu (smtpshim v1.0); Fri, 21 Jul 2000 05:39:17 -0400 Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id FAA29927; Fri, 21 Jul 2000 05:40:24 -0400 (EDT) Received: from a3mail.lotus.com (A3MAIL.lotus.com [9.95.5.66]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id FAA17666; Fri, 21 Jul 2000 05:39:14 -0400 (EDT) To: "Dave Sill Cc: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call X-Mailer: Lotus Notes Build V505_07112000 July 11, 2000 From: "Nick Shelness/SSW/Lotus" Message-ID: Date: Fri, 21 Jul 2000 10:39:06 +0100 X-MIMETrack: Serialize by Router on A3MAIL/CAM/H/Lotus(Build V505_07062000 |July 6, 2000) at 07/21/2000 05:41:51 AM, Serialize complete at 07/21/2000 05:41:51 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: Dave, You ask > What is the measure of rough consensus? Some fixed number of positive > responses? A certain ratio of positives to negatives? Let us begin with consensus. This is when all members of a community agree with a proposition, or in a slightly weaker form choose to either agree with a proposition or abstain from opposing it. Within IETF working groups, opponents may wish to express objection, but do not feel strongly enough about the issue to block progress. This is often referred to informally as rough consensus. In addition, there may be disruptive individuals, who if pure consensus was required, could cause a working group activity to grind to a complete halt. Therefore, IETF procedures allow a working group chair to declare rough consensus even when full consensus has not been achieved. In reaching this decision, the chair must take into account the number, the standing and the credibility or the objectors. IETF procedures also allow this declaration to be appealed to the IESG and beyond. In the vast majority of working groups this never occurs. Unfortunately, the drums chair has had to do so on an overly large number of occasions (I wonder why), though he tries to avoid it at all costs. Instances that I particularly remember include the retention of VRFY and EXPN commands in 821bis. There were many others. Nick Nick Shelness, IBM Fellow Chief Technology Officer Lotus Development Corp Tel: (617) 693-7484 Assistant: Mary McGurran Tel: (617) 693-4321 From owner-drums@cs.utk.edu Fri Jul 21 05:52:30 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07375 for ; Fri, 21 Jul 2000 05:52:30 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA03774; Fri, 21 Jul 2000 05:52:17 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 21 Jul 2000 05:52:17 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id FAA03756; Fri, 21 Jul 2000 05:52:16 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA03743; Fri, 21 Jul 2000 05:52:15 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> muncher.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Fri, 21 Jul 2000 05:52:15 -0400 Received: (qmail 20471 invoked by uid 1001); 21 Jul 2000 09:52:36 -0000 Date: 21 Jul 2000 09:52:36 -0000 Message-ID: <20000721095236.8266.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: client requests ending \012 References: <20000720001401.19958.qmail@cr.yp.to> <200007201645.MAA04825@astro.cs.utk.edu> <20000721055148.11725.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Glenn Anderson writes: > Clients that use just \012 as a line terminator are > broken and should be fixed. Certainly. Clients that use \012 as a line terminator for requests are violating RFC 821 and will be violating 821bis. I hope that they all disappear someday. I support education efforts aimed at this goal. In the meantime, however, I refuse to punish the users of those clients. Deliberate torture is not an acceptable way to educate implementors. I will continue to accept \012 as a line terminator for client requests. To summarize the situation: The sender's misbehavior is inexcusable and should be prohibited. But the receiver's tolerance is beneficial and should be allowed. As Jon Postel said: It is nice that many mail-reading programs will accept mail that does not conform to the standard, but that does not justify mail-sending programs' violation of the standard. ---Dan From owner-drums@cs.utk.edu Fri Jul 21 06:34:22 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29979 for ; Fri, 21 Jul 2000 06:34:22 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA06335; Fri, 21 Jul 2000 06:33:55 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 21 Jul 2000 06:33:55 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA06318; Fri, 21 Jul 2000 06:33:54 -0400 (EDT) Received: from draco.cus.cam.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA06288; Fri, 21 Jul 2000 06:33:52 -0400 (EDT) Received: from draco.cus.cam.ac.uk (131.111.8.18 -> draco.cus.cam.ac.uk) by cs.utk.edu (smtpshim v1.0); Fri, 21 Jul 2000 06:33:52 -0400 Received: from ph10 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 3.16 #3) id 13Fa7q-0000iT-00 for drums@cs.utk.edu; Fri, 21 Jul 2000 11:33:50 +0100 Date: Fri, 21 Jul 2000 11:33:50 +0100 (BST) From: Philip Hazel To: drums@cs.utk.edu Subject: Re: client requests ending \012 In-Reply-To: <20000721095236.8266.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: On 21 Jul 2000, D. J. Bernstein wrote: > As Jon Postel said: > > It is nice that many mail-reading programs will accept mail that does > not conform to the standard, but that does not justify mail-sending > programs' violation of the standard. I think it is a great pity that *any* mail-reading programs accept mail that does not conform to the standard. If, from the start, all such programs had been strict, we wouldn't be in the mess we are in today, where, because such tolerance has been common, new implementations are forced to accept non-conforming mail, but their implementors don't know they have do this to until it bites them, because such behaviour is not described in the standard. You cannot implement a usable MTA for today's Internet purely from the information in the RFCs. This is a serious disaster. It is no wonder that some people take a cavalier attitude towards standards when faced with this situation. "Be liberal in what you accept" is always a recipe for storing up trouble that will come back to bite people later. Once you start down that road, you can't retreat, however. We are stuck with the legacy of this attitude. All IMHO, of course. -- Philip Hazel University of Cambridge Computing Service, ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. From owner-drums@cs.utk.edu Fri Jul 21 07:24:35 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23996 for ; Fri, 21 Jul 2000 07:24:34 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA09271; Fri, 21 Jul 2000 07:24:13 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 21 Jul 2000 07:24:11 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id HAA09244; Fri, 21 Jul 2000 07:24:11 -0400 (EDT) Received: from lint.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id HAA09226; Fri, 21 Jul 2000 07:24:08 -0400 (EDT) Received: from lint.cisco.com (171.68.224.209 -> lint.cisco.com) by cs.utk.edu (smtpshim v1.0); Fri, 21 Jul 2000 07:24:09 -0400 Received: from cisco.com (london-async28.cisco.com [144.254.38.167]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id EAA13551; Fri, 21 Jul 2000 04:23:37 -0700 (PDT) Message-ID: <39783271.17BB9C52@cisco.com> Date: Fri, 21 Jul 2000 04:22:25 -0700 From: Eliot Lear Reply-To: lear@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "D. J. Bernstein" CC: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call References: <1461297.3173012530@nifty-jr.west.sun.com> <20000720001401.19958.qmail@cr.yp.to> <39773C1E.A22B87B4@cisco.com> <20000721053132.18930.qmail@cr.yp.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit D. J. Bernstein writes: > No! Programs that want to use VRFY should simply try it. Programs that > behave as you suggest will fail miserably and be discarded by users. The whole point of EHLO was to prevent this sort of poking and prodding. If the server wants implementations to use VRFY it should announce that capability. > > you need some form of loop detection. > > I can't respond to your alleged justifications until I see a coherent > definition of the phrase ``some form of loop detection.'' Alleged? Come on. Run a mailing list of 100 people or more and tell me that with a straight face. And the point of the document is that the method is left to the implementor. I'm not saying it can't be done wrong (numerous mailing list management software have blown it in this area). Why not state a credible argument that this presents a serious interoperability problem, rather than resorting to vague fud? > [...] > I'm not sure what you mean by ``hides'' here. My objections are to > > (1) Klensin requiring or allowing non-interoperable behavior, > (2) Klensin prohibiting safe behavior, > (3) Klensin discouraging safe behavior, and > (4) Klensin misleading readers. > > In #1, there's ample evidence that the behavior causes interoperability > failures. Are you seriously suggesting that such breakage be allowed? Yes in the cases where the alternatives could lead to worse problems. Consider the case where two implementations attempt to add garbage on the end of a command. The result is undefined and then we hear complaints about SMTP, such as the one in your objection. Worse than producing an error is accepting a message with parameters you do not understand, since you may not be able to deliver it properly. By mandating allowance for broken behavior (as in the case with crud on the end of a line) we also open up opportunities for lots of implementation errors, which raise security concerns (improper parsing, buffer overflows). In fact normally I don't think I'd be a stickler on this issue, but because there is an existence proof of abuse of the standard, others WILL follow if we don't fix it. > In #2 and #3, the behavior is widely used, and there's not a shred of > evidence that it causes interoperability problems. Are you seriously > suggesting that users be forced to install new software for no benefit? Except that they'll have the benefit of improved interoperability, meaning that their mail will more likely reach them or their receivers. -- Eliot Lear lear@cisco.com From owner-drums@cs.utk.edu Fri Jul 21 09:54:29 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13586 for ; Fri, 21 Jul 2000 09:54:29 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA15501; Fri, 21 Jul 2000 09:02:26 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 21 Jul 2000 09:02:23 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA15484; Fri, 21 Jul 2000 09:02:23 -0400 (EDT) Received: from sws5.ctd.ornl.gov (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA15471; Fri, 21 Jul 2000 09:02:22 -0400 (EDT) Received: from sws5.ctd.ornl.gov (160.91.68.105 -> sws5.ctd.ornl.gov) by cs.utk.edu (smtpshim v1.0); Fri, 21 Jul 2000 09:02:22 -0400 Received: (qmail 100373 invoked by uid 3995); 21 Jul 2000 13:02:21 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14712.18909.61182.580079@sws5.ctd.ornl.gov> Date: Fri, 21 Jul 2000 09:02:21 -0400 (EDT) From: Dave Sill To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 "20 Minutes to Nikko" XEmacs Lucid (patch 2) Organization: Oak Ridge National Lab, Oak Ridge, Tenn., USA X-Face: "p~Q]mg{;e*}YR|)&Q/&Q\*~5UWfZX34;5M Content-Transfer-Encoding: 7bit "Nick Shelness/SSW/Lotus" wrote: >DJB wrote: >1. >> In reality, for interoperability with existing clients, servers >> recognize \012 as a line terminator ... > >This is true, but is independent of whether it should be required under >the standard. I believe that we reached rough consensus that under the >standard, be the only valid command terminator. The question is not whether it should be required or not, the question is whether or not servers should be allowed to recognize \012 as a line terminator. Nobody is arguing that clients should be allowed to send \012 as a line terminator. >2. >> In reality, for interoperability with existing clients, servers >> accept (for example) EHLO requests containing underscores. ... > >Again, this is true, but is independent of whether it should be required >under the standard. I believe that we reached consensus that under the >standard EHLO requests MUST NOT contain underscores. Same thing: `should servers be allowed to *accept* EHLO requests containing underscores', not `should clients be allowed to *send* them'. >3. >> In reality, if an SMTP client is in the middle of sending a message, >> and is unable to read the next portion of the message from disk, it >> ruthlessly closes the connection. ... > >Again, this is true, and the standard should and does state what a server >and client should do when a connection is closed prior to the transmission >of a QUIT and receipt of a QUIT response. > >To that end, I think that the text in the final paragraph of section 3.9 >(the only one that addresses client behavior) could be expanded slightly >to make it clear that there are environmental circumstances (in addition >to those listed) beyond a client's control that may require it to >terminate a connection. For example, > > SMTP clients that experience events beyond their control, such as an > unrecoverable disk read failure, a notification of impeding system > shutdown,> a connection close, a connection reset, or other type > communications failure (in violation of the intent of this > specification but sometimes unavoidable) SHOULD, to maintain the > robustness of the mail system, treat the mail transaction as if a 451 > response had been received and act accordingly. > >But fundamentally, this was never at issue. What was at issue is whether >it was valid under the standard for a client to tear down a connection >after receiving a positive response to a . and with out >sending a QUIT and receiving a response. Again, I believe that rough >consensus was reached that it was not. That may be so, but isn't a little silly to go through all the trouble to mandate sending the QUIT when possible, if it serves no useful purpose? Especially when skipping the QUIT exchange saves several round trips? If servers have to Do The Right Thing when the connection dies at a certain point, what is gained by outlawing the intentional breaking of the connection? >13. >> In reality, firewalls and POP toasters often run pure SMTP servers. >> They do not send mail through SMTP, and they are not expected to >> support any SMTP client features. Installing unused code is a >> violation of some corporate security policies. ... > >RFC 821bis describes on the wire behavior. Thus, an SMTP server need only >support on the wire RFC 821bis server features, and an SMTP client need >only support on the wire RFC 821bis client features. Where's the problem? The problem is that the draft goes beyond specifying wire behavior: it says that not supporting VRFY is a potential interoperability problem, which it isn't. >15. >> In reality, there are many common non-MIME body structures. ... > >This is also true, but again rough consensus was reached within the >working group that RCF 821bis and 822bis should strongly encourage the use >of MIME, to the exclusion of all other body structures. So the rough consensus of the working group was to lie? It's one thing to encourage MIME, and another to pretend that it's the only way to structure bodies. -Dave From owner-drums@cs.utk.edu Fri Jul 21 11:29:38 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28085 for ; Fri, 21 Jul 2000 11:29:38 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA00143; Fri, 21 Jul 2000 11:29:20 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 21 Jul 2000 11:29:18 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA00125; Fri, 21 Jul 2000 11:29:18 -0400 (EDT) Received: from munnari.OZ.AU (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA29830; Fri, 21 Jul 2000 11:25:27 -0400 (EDT) Received: from munnari.OZ.AU (128.250.1.21 -> munnari.OZ.AU) by cs.utk.edu (smtpshim v1.0); Fri, 21 Jul 2000 11:25:28 -0400 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id PA23509; Sat, 22 Jul 2000 01:25:23 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 22 Jul 2000 01:25:22 +1000 Message-Id: <3573.964193122@mundamutti.cs.mu.OZ.AU> List-Unsubscribe: Date: Thu, 20 Jul 2000 09:39:33 +0100 (BST) From: Philip Hazel Message-ID: In all this discussion, this is the one message that really makes the issues clear (from a WG last call perspective) ... | To keep the record straight, let me record here that there are several | of Dan's points with which I entirely agree. So it isn't just one | participant, it's at least two. And, like Dan, I am an MTA implementor. | | I have to confess that I decided to give up trying to argue these points | in the face of apparently overwhelming opposition. They include the | 8-bit thing, which he does not mention in his message. The other major | points with which I agree are: That demonstrates exactly what happens in WGs. People argue for their point of view, until it becomes clear that the WG is not going to accept the argument (and whether the WG is wrong or not is not something that matters). That really should be the end of the issue - unfortunately there are some participants who never realise that however certain they are that their arguments are correct and valid, and that only a moron could fail to understand the underlying truths, the WG is simply not going to accept them. Those (fortunately few) people keep bringing up the same objections over and over again - and can usually find a few other people who will agree with any one of their points - and from that become even more convinced that their arguments are valid, and are simply being ignored (usually due to some imagined malfeasance by the doc editor). The right thing to do is just as was mentioned above - give up arguing in the face of apparently overwhelming opposition. That's what should have happened here too, unfortunately it hasn't. None of this noise should be treated even half seriously by the WG chair or the IESG. It is noise. kre From owner-drums@cs.utk.edu Sat Jul 22 02:05:29 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24860 for ; Sat, 22 Jul 2000 02:05:28 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id CAA27340; Sat, 22 Jul 2000 02:05:10 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 22 Jul 2000 02:05:06 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id CAA27323; Sat, 22 Jul 2000 02:05:05 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id CAA27309; Sat, 22 Jul 2000 02:05:04 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> muncher.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Sat, 22 Jul 2000 02:05:04 -0400 Received: (qmail 15287 invoked by uid 1001); 22 Jul 2000 06:05:15 -0000 Date: 22 Jul 2000 06:05:15 -0000 Message-ID: <20000722060515.32393.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: client requests ending \012 References: <20000721095236.8266.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Philip Hazel writes: > new implementations are forced to accept non-conforming mail, but > their implementors don't know they have do this to until it bites them, This crucial information is on my web pages, of course. Example: ``Some clients fail to include the \015.'' But Klensin refuses to include this warning in 821bis. Klensin then exacerbates the problem by requiring that servers stop talking to those clients. Klensin's requirement is actively disobeyed by most SMTP servers on the Internet. Good! Obeying Klensin's requirement would immediately cause massive harm to users. > I think it is a great pity that *any* mail-reading programs accept mail > that does not conform to the standard. Nobody has ever written a server that detects every visible misbehavior by SMTP clients. The protocol is far too complicated. A tolerant server is much easier to implement. > If, from the start, all such programs had been strict, Then nobody would have written the programs in the first place. You are talking about a _huge_ implementation expense. SMTP---not to mention the Internet mail message header format---wasn't designed to make this easy. Please note that my comments are specific to these poorly designed protocols. There are other protocols where the same job is easy. ---Dan P.S. Just as a reminder: The issue you're raising was discussed here in late 1998. In a legitimate standards organization, discussions aren't repeated; issues are settled when they're first brought up, and the logic behind each decision is recorded in a format designed for quick future reference. From owner-drums@cs.utk.edu Sat Jul 22 15:17:34 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29016 for ; Sat, 22 Jul 2000 15:17:33 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA27579; Sat, 22 Jul 2000 15:17:09 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 22 Jul 2000 15:17:00 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA27546; Sat, 22 Jul 2000 15:17:00 -0400 (EDT) Received: from khms.westfalen.de (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA27511; Sat, 22 Jul 2000 15:16:50 -0400 (EDT) Received: from khms.westfalen.de (62.156.34.182 -> p3E9C22B6.dip.t-dialin.net) by cs.utk.edu (smtpshim v1.0); Sat, 22 Jul 2000 15:16:51 -0400 Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.12 #1) id 13G4lF-0001UU-00 (Debian); Sat, 22 Jul 2000 21:16:33 +0200 Received: by khms.westfalen.de (CrossPoint v3.12d.kh5 R/C435); 22 Jul 2000 18:49:30 +0200 Date: 22 Jul 2000 18:23:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: drums@cs.utk.edu Message-ID: <7iLHEVKXw-B@khms.westfalen.de> In-Reply-To: <39773C1E.A22B87B4@cisco.com> Subject: Re: SMTP WG Last-Call X-Mailer: CrossPoint v3.12d.kh5 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <1461297.3173012530@nifty-jr.west.sun.com> <20000720001401.19958.qmail@cr.yp.to> <39773C1E.A22B87B4@cisco.com> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 List-Unsubscribe: lear@cisco.com (Eliot Lear) wrote on 20.07.00 in <39773C1E.A22B87B4@cisco.com>: > Dan Bernstein complains > that clients ought not use MX records when connecting to relays. Why? > This is a perfectly fine use of an MX record and allows for a very > simple mechanism for MULTIPLE relays with preference indication! In > fact this point bothers me more than most, since a so-called implementor > is making trade-offs against his potential customers. Please let there > be no doubt. When we did RFC 1123 we weighed existing behavior against > potential benefit to the user, and neither side had an infinite amount > of weight. Are you by any chance talking about the case where a MUA talks to a submission server (*not* a relay)? (Or maybe a "smarthost" scenario - essentially the same thing.) Because in that case, I agree that MX records are exceedingly counter productive. OTOH, I also think that the doc doesn't actually prescribes any behaviour for this case. (Smarthost is by definition by previous local agreement.) If people disagree, a wording fix might be in order. MfG Kai From owner-drums@cs.utk.edu Sat Jul 22 15:34:49 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29014 for ; Sat, 22 Jul 2000 15:17:33 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA27581; Sat, 22 Jul 2000 15:17:09 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 22 Jul 2000 15:17:00 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA27545; Sat, 22 Jul 2000 15:17:00 -0400 (EDT) Received: from khms.westfalen.de (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA27512; Sat, 22 Jul 2000 15:16:50 -0400 (EDT) Received: from khms.westfalen.de (62.156.34.182 -> p3E9C22B6.dip.t-dialin.net) by cs.utk.edu (smtpshim v1.0); Sat, 22 Jul 2000 15:16:51 -0400 Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.12 #1) id 13G4lF-0001UU-01 (Debian); Sat, 22 Jul 2000 21:16:33 +0200 Received: by khms.westfalen.de (CrossPoint v3.12d.kh5 R/C435); 22 Jul 2000 18:49:30 +0200 Date: 22 Jul 2000 18:41:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: drums@cs.utk.edu Message-ID: <7iLHEiWHw-B@khms.westfalen.de> In-Reply-To: <20000720191356.E13412@thyrsus.com> Subject: Re: SMTP WG Last-Call X-Mailer: CrossPoint v3.12d.kh5 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <4.3.2.20000720225612.00bc15f0@mail.bayarea.net> <20000720191356.E13412@thyrsus.com> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 List-Unsubscribe: esr@thyrsus.com wrote on 20.07.00 in <20000720191356.E13412@thyrsus.com>: > Russ Allbery : > > Dave Crocker writes: > > > > > two, yes. and a third has chimed in. > > > > Make it four on several of these points. > > > > > That is, working group consensus was consistently and massively against > > > those concerns. > > > > That is not in agreement with my reading of this working group for the > > time that I've been here. The working group consensus was consistently > > and massively against the way in which the concerns were presented, but I > > think some of these are good points, and do not have a consensus against > > them. > > Make it five because I too agree. Dan's style is deeply obnoxious but some > of his technical points have merit. We should not succumb to the temptation > to shoot the messenger. Six. (And you all know how much I dislike djb's style.) In fact, ISTR that some of the points he made had rough consensus *for*, not against, them. (And some others were, indeed, right out there.) MfG Kai From owner-drums@cs.utk.edu Sat Jul 22 22:19:31 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12593 for ; Sat, 22 Jul 2000 22:19:31 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA11112; Sat, 22 Jul 2000 22:19:15 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 22 Jul 2000 22:19:12 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA11088; Sat, 22 Jul 2000 22:19:12 -0400 (EDT) Received: from serenity.mcc.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA11074; Sat, 22 Jul 2000 22:19:07 -0400 (EDT) Received: from serenity.mcc.ac.uk (130.88.200.93 -> serenity.mcc.ac.uk) by cs.utk.edu (smtpshim v1.0); Sat, 22 Jul 2000 22:19:08 -0400 Received: from nessie.mcc.ac.uk ([130.88.200.20] ident=root) by serenity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 13GBMA-000Gno-00 for drums@cs.utk.edu; Sun, 23 Jul 2000 03:19:06 +0100 Received: from clw.cs.man.ac.uk (clerew.man.ac.uk [194.66.22.208]) by nessie.mcc.ac.uk (8.9.3/8.8.8) with ESMTP id DAA54047 for ; Sun, 23 Jul 2000 03:19:04 +0100 (BST) (envelope-from root@clw.cs.man.ac.uk) Received: (from root@localhost) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) id UAA03347 for drums@cs.utk.edu; Sat, 22 Jul 2000 20:46:56 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) with SMTP id UAA03344 for ; Sat, 22 Jul 2000 20:46:55 +0100 (BST) Message-Id: <200007221946.UAA03344@clw.cs.man.ac.uk> Date: Sat, 22 Jul 2000 20:46:55 +0100 (BST) From: Charles Lindsey Reply-To: Charles Lindsey Subject: Re: SMTP WG Last-Call To: drums@cs.utk.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: G4Cjj9/h0lW9p73YG1Iz8A== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc List-Unsubscribe: On Fri, 21 Jul 2000 09:02:21 -0400 (EDT) Dave Sill said... > The question is not whether it should be required or not, the question > is whether or not servers should be allowed to recognize \012 as a > line terminator. Nobody is arguing that clients should be allowed to > send \012 as a line terminator. Eh? That seems wrong way round to me. If some server chooses to be liberal in what it accepts, then good luck to it. But if it is not the case that all servers are required to recognize \012, then indeed clients MUST NOT send it (if they wish to conform to our standard, that is - they can have a private arrangement with a partivcular server if they wish). > > Same thing: `should servers be allowed to *accept* EHLO requests > containing underscores', not `should clients be allowed to *send* > them'. ditto. > > If servers have to Do The Right Thing when the connection dies at a > certain point, what is gained by outlawing the intentional breaking of > the connection? Keeping their logs clean? Releasing some resources that were being kept allocated for the client that was supposedly still connected? > > So the rough consensus of the working group was to lie? It's one thing > to encourage MIME, and another to pretend that it's the only way to > structure bodies. MIME is the only _recognizes- / _supported_ structure. Perhaps one of those words could usefully appear at the proper point. Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-drums@cs.utk.edu Sat Jul 22 22:53:16 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17182 for ; Sat, 22 Jul 2000 22:53:15 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA12860; Sat, 22 Jul 2000 22:53:02 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 22 Jul 2000 22:53:01 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA12842; Sat, 22 Jul 2000 22:53:01 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA12829; Sat, 22 Jul 2000 22:53:00 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Sat, 22 Jul 2000 22:53:00 -0400 Received: (qmail 19499 invoked by uid 1001); 23 Jul 2000 02:53:21 -0000 Date: 23 Jul 2000 02:53:21 -0000 Message-ID: <20000723025321.8577.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: MX lookups in dumb clients References: <1461297.3173012530@nifty-jr.west.sun.com> <20000720001401.19958.qmail@cr.yp.to> <39773C1E.A22B87B4@cisco.com> <7iLHEVKXw-B@khms.westfalen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Kai Henningsen writes: > OTOH, I also think that the doc doesn't actually prescribes > any behaviour for this case. Oops, you're right. Klensin's bad text in smtpupd-10 (the relay name ``SHOULD be processed'' by the MX procedure) disappeared in smtpupd-11. I didn't catch this change. My apologies. ---Dan From owner-drums@cs.utk.edu Sat Jul 22 23:17:30 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19824 for ; Sat, 22 Jul 2000 23:17:30 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id XAA13990; Sat, 22 Jul 2000 23:17:15 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 22 Jul 2000 23:17:15 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id XAA13973; Sat, 22 Jul 2000 23:17:14 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id XAA13960; Sat, 22 Jul 2000 23:17:12 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Sat, 22 Jul 2000 23:17:12 -0400 Received: (qmail 31103 invoked by uid 1001); 23 Jul 2000 03:17:34 -0000 Date: 23 Jul 2000 03:17:34 -0000 Message-ID: <20000723031734.26334.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call References: <200007221946.UAA03344@clw.cs.man.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Charles Lindsey writes: > clients MUST NOT send it That's not the issue. > If some server chooses to be > liberal in what it accepts, then good luck to it. Right---but Klensin doesn't allow this! Read the damn document. Klensin says that servers ``MUST NOT recognize'' a bare \012 as a terminator for client requests. That's what I'm objecting to. [ EHLO requests containing underscores ] > ditto. Once again: The issue is not whether the client is allowed to send this, but whether the server is allowed to accept it. Klensin says that servers ``MUST reject'' EHLO names containing underscores. RFC 821 doesn't say that. Klensin added this requirement without the consensus of the group. ---Dan From owner-drums@cs.utk.edu Sun Jul 23 00:53:08 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07041 for ; Sun, 23 Jul 2000 00:53:08 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA17112; Sun, 23 Jul 2000 00:52:48 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 23 Jul 2000 00:52:46 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA17093; Sun, 23 Jul 2000 00:52:46 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA17080; Sun, 23 Jul 2000 00:52:44 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Sun, 23 Jul 2000 00:52:45 -0400 Received: (qmail 10499 invoked by uid 1001); 23 Jul 2000 04:53:05 -0000 Date: 23 Jul 2000 04:53:05 -0000 Message-ID: <20000723045305.29789.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Nick Shelness/SSW/Lotus writes: > I believe that we reached consensus that under the > standard EHLO requests MUST NOT contain underscores. That is not the issue. The issue is Klensin's text saying that servers ``MUST reject'' underscores. RFC 821 doesn't say that, and we certainly don't have consensus to make the change. > Absolutely, but again there was rough consensus that RFC 821bis should > encourage the infrastructure to move to employing EHLO in place of HELO. There isn't consensus that clients happy with HELO should be forced to use EHLO instead. > What there was rough consensus on was, that under RFC 821bis servers > that support EHLO and VRFY MUST announce VRFY support in an EHLO response. I don't believe you. It appears that the requirement was invented by Klensin in 1995, with no discussion by DRUMS. In August 1998, I asked what benefit Klensin's requirement had, pointed out that it was incompatible with widespread practice, and asked when DRUMS had discussed it. Nobody responded. In January 1999, I asked again, and again nobody had an answer. The only response was from Paul Hoffman, agreeing that the requirement was wrong. A few people have now spoken up in favor of the requirement, and a few more people have spoken up against it. Obviously most implementors are against it. Compare this to Klensin's policy statement in December 1996: The editor's position is that telling an implementation that clearly conforms today that it is no longer conforming requires very strong and clear consensus. Unfortunately, Klensin takes this ``position'' only for changes that he doesn't find attractive. ---Dan From owner-drums@cs.utk.edu Sun Jul 23 02:17:12 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20117 for ; Sun, 23 Jul 2000 02:17:12 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id CAA19591; Sun, 23 Jul 2000 02:16:56 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 23 Jul 2000 02:16:54 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id CAA19574; Sun, 23 Jul 2000 02:16:54 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id CAA19561; Sun, 23 Jul 2000 02:16:53 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Sun, 23 Jul 2000 02:16:53 -0400 Received: (qmail 17651 invoked by uid 1001); 23 Jul 2000 06:17:13 -0000 Date: 23 Jul 2000 06:17:13 -0000 Message-ID: <20000723061713.13164.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: A quick reminder about SHOULD Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Please remember that the word ``SHOULD'' has a specific definition in Klensin's document. It's much stronger than the RFC 1123 ``SHOULD,'' never mind the English word ``should.'' When RFC 1123 says that every SMTP server ``SHOULD implement EXPN,'' for example, here's what it's saying: There may exist valid reasons in particular circumstances to not implement EXPN, but the full implications should be understood and the case carefully weighed. In contrast, when Klensin says that every SMTP server ``SHOULD support EXPN,'' here's what he's saying: An SMTP server that doesn't support EXPN may interoperate properly, but this will typically be the case only if great care is taken. Consequently, the requirement to support EXPN should be violated only under exceptional and well-understood circumstances. That's certainly not what RFC 1123 says. RFC 1123 is merely giving some bad advice; Klensin is making a patently ridiculous claim about interoperability. You might think at first glance that Klensin's ``SHOULD support EXPN'' is the same as RFC 1123's ``SHOULD implement EXPN.'' Don't be fooled! Klensin made a big change in the definition of ``SHOULD.'' Can we all agree that the spec should recommend against supporting EXPN? Perhaps we can't. But the default position, in the absence of consensus, is what RFC 1123 said, _not_ what Klensin wants to say. ---Dan From owner-drums@cs.utk.edu Sun Jul 23 15:18:28 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20567 for ; Sun, 23 Jul 2000 15:18:28 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA05716; Sun, 23 Jul 2000 15:17:54 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 23 Jul 2000 15:17:31 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA05698; Sun, 23 Jul 2000 15:17:30 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA05685; Sun, 23 Jul 2000 15:17:29 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> muncher.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Sun, 23 Jul 2000 15:17:29 -0400 Received: (qmail 3012 invoked by uid 1001); 23 Jul 2000 19:17:50 -0000 Date: 23 Jul 2000 19:17:50 -0000 Message-ID: <20000723191750.28598.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: HELO procedural notes References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Nick Shelness/SSW/Lotus writes: [ clients not needing extensions can start with HELO ] > I have no objection to your use of the word "can", but again there was > rough consensus that RFC 821bis should encourage the infrastructure to > move to employing EHLO in place of HELO. I've already commented that there certainly isn't consensus to force clients to use EHLO when they're happy with HELO. In fact, according to Leiba's notes of the August 1998 meeting, consensus was established _against_ Klensin's change: Consensus is that "SHOULD use EHLO" be dropped, and a client that doesn't need extensions may use EHLO or HELO at the client's discretion. That's consistent with discussions of the issue on the mailing list. So why does smtpupd-12 still say ``SHOULD preferentially utilize EHLO''? How many times do I have to point this out before Klensin undoes his unauthorized change? And how come certain people---Crocker and Shelness, for example---are claiming that there's consensus for this ``SHOULD''? ---Dan P.S. At the same meeting, according to Leiba's notes, it was decided to ``remain with RFC1123 conventions'' for words like ``SHOULD.'' Klensin's non-1123 definition of ``SHOULD'' appeared in the next draft. From owner-drums@cs.utk.edu Mon Jul 24 06:17:55 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04009 for ; Mon, 24 Jul 2000 06:17:55 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA15124; Mon, 24 Jul 2000 06:17:18 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 24 Jul 2000 06:17:12 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA15107; Mon, 24 Jul 2000 06:17:11 -0400 (EDT) Received: from lotus2.lotus.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA15094; Mon, 24 Jul 2000 06:17:09 -0400 (EDT) Received: from lotus2.lotus.com (192.233.136.8 -> lotus2.lotus.com) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jul 2000 06:17:09 -0400 Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id GAA06043; Mon, 24 Jul 2000 06:18:21 -0400 (EDT) Received: from a3mail.lotus.com (A3MAIL.lotus.com [9.95.5.66]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id GAA10849; Mon, 24 Jul 2000 06:17:07 -0400 (EDT) To: Dave Sill Cc: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call X-Mailer: Lotus Notes Build V505_07182000 July 18, 2000 From: "Nick Shelness/SSW/Lotus" Message-ID: Date: Mon, 24 Jul 2000 06:17:03 -0400 X-MIMETrack: Serialize by Router on A3MAIL/CAM/H/Lotus(Build V505_07062000 |July 6, 2000) at 07/24/2000 06:19:46 AM, Serialize complete at 07/24/2000 06:19:46 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: Dave, You wrote in response to my response to Dan. > >1. > >> In reality, for interoperability with existing clients, servers > >> recognize \012 as a line terminator ... > > > >This is true, but is independent of whether it should be required under > >the standard. I believe that we reached rough consensus that under the > >standard, be the only valid command terminator. > > The question is not whether it should be required or not, the question > is whether or not servers should be allowed to recognize \012 as a > line terminator. Nobody is arguing that clients should be allowed to > send \012 as a line terminator. Very early on in the drums effort, the working group was faced by a choice. In updating RFC 821/1123 and 822, we could a)leave the documents largely as they were, b) update the documents to legitimize what had previously been protocol violations, or c) update the documents to actively reject protocol violations. If a) was the choice taken, then there was not much need for drums. Both b) and c) are perfectly legitimate choices. At the time the consensus of the group was to pursue c) and this has been the case ever since. What you are arguing for here is effectively a), which in this case clearly hasn't been historically very successful. If we can't reach rough consensus on a matter (see for example, the reply-to: discussions, then the group has little choice to stay with a). But in this case, we previously did reach rough consensus, which was to pursue approach c) and to actively reject illegal command terminators. > >2. > >> In reality, for interoperability with existing clients, servers > >> accept (for example) EHLO requests containing underscores. ... > > > >Again, this is true, but is independent of whether it should be required > >under the standard. I believe that we reached consensus that under the > >standard EHLO requests MUST NOT contain underscores. > > Same thing: `should servers be allowed to *accept* EHLO requests > containing underscores', not `should clients be allowed to *send* > them'. See my response to 1 above. > >3. > >> In reality, if an SMTP client is in the middle of sending a message, > >> and is unable to read the next portion of the message from disk, it > >> ruthlessly closes the connection. ... > > > >Again, this is true, and the standard should and does state what a server > >and client should do when a connection is closed prior to the transmission > >of a QUIT and receipt of a QUIT response. > > > >To that end, I think that the text in the final paragraph of section 3.9 > >(the only one that addresses client behavior) could be expanded slightly > >to make it clear that there are environmental circumstances (in addition > >to those listed) beyond a client's control that may require it to > >terminate a connection. For example, > > > > SMTP clients that experience events beyond their control, such as an > > unrecoverable disk read failure, a notification of impeding system > > shutdown,> a connection close, a connection reset, or other type > > communications failure (in violation of the intent of this > > specification but sometimes unavoidable) SHOULD, to maintain the > > robustness of the mail system, treat the mail transaction as if a 451 > > response had been received and act accordingly. > > > >But fundamentally, this was never at issue. What was at issue is whether > >it was valid under the standard for a client to tear down a connection > >after receiving a positive response to a . and with out > >sending a QUIT and receiving a response. Again, I believe that rough > >consensus was reached that it was not. > > That may be so, but isn't a little silly to go through all the trouble > to mandate sending the QUIT when possible, if it serves no useful > purpose? Especially when skipping the QUIT exchange saves several > round trips? > > If servers have to Do The Right Thing when the connection dies at a > certain point, what is gained by outlawing the intentional breaking of > the connection? Clearly SMTP could have designed originally without starting and ending in-band brackets (i.e., without HELO and QUIT commands), but it wasn't. The working group, with the exception at the time largely of Dan, didn't feel comfortable about removing them. So that today, a client that tears down a TCP connection prior to sending a QUIT and receiving a response, is violating the protocol. In the context of my response to 1 above, the working group chose approach c). > >13. > >> In reality, firewalls and POP toasters often run pure SMTP servers. > >> They do not send mail through SMTP, and they are not expected to > >> support any SMTP client features. Installing unused code is a > >> violation of some corporate security policies. ... > > > >RFC 821bis describes on the wire behavior. Thus, an SMTP server need only > >support on the wire RFC 821bis server features, and an SMTP client need > >only support on the wire RFC 821bis client features. Where's the problem? > > The problem is that the draft goes beyond specifying wire behavior: it > says that not supporting VRFY is a potential interoperability problem, > which it isn't. VRFY and responses to it are on the wire. For the rest, see my response to 1 above. > >15. > >> In reality, there are many common non-MIME body structures. ... > > > >This is also true, but again rough consensus was reached within the > >working group that RCF 821bis and 822bis should strongly encourage the use > >of MIME, to the exclusion of all other body structures. > > So the rough consensus of the working group was to lie? It's one thing > to encourage MIME, and another to pretend that it's the only way to > structure bodies. On the widely interoperable Internet, which is what RFC 821bis and 822bis are addressing, it is the only way to structure bodies! This in no way precludes communities from employing other experimental encodings. Nick Nick Shelness, IBM Fellow Chief Technology Officer Lotus Development Corp Tel: (617) 693-7484 Assistant: Mary McGurran Tel: (617) 693-4321 From owner-drums@cs.utk.edu Mon Jul 24 17:22:21 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10943 for ; Mon, 24 Jul 2000 17:22:20 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA05171; Mon, 24 Jul 2000 17:21:42 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 24 Jul 2000 17:21:34 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA05146; Mon, 24 Jul 2000 17:21:34 -0400 (EDT) Received: from qualcomm.co.nz (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA05131; Mon, 24 Jul 2000 17:21:26 -0400 (EDT) Received: from qualcomm.co.nz (203.97.196.98 -> doom.qualcomm.co.nz) by cs.utk.edu (smtpshim v1.0); Mon, 24 Jul 2000 17:21:28 -0400 Received: from [203.97.196.100] (203.97.196.100) by qualcomm.co.nz with ESMTP (Eudora Internet Mail Server 3.0.1) for ; Sun, 23 Jul 2000 10:54:04 +1200 Mime-Version: 1.0 X-Sender: glenn@qualcomm.co.nz@mail.qualcomm.co.nz Message-Id: In-Reply-To: <20000722060515.32393.qmail@cr.yp.to> References: <20000721095236.8266.qmail@cr.yp.to> <20000722060515.32393.qmail@cr.yp.to> Date: Sun, 23 Jul 2000 10:51:38 +1200 To: drums@cs.utk.edu From: Glenn Anderson Subject: Re: client requests ending \012 Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: >Klensin then exacerbates the problem by requiring that servers stop >talking to those clients. Klensin's requirement is actively disobeyed by >most SMTP servers on the Internet. Good! Obeying Klensin's requirement >would immediately cause massive harm to users. I disagree, my server refuses \012 as an end of line, has done for years now, and the only "clients" that I have had users report problems with recently are scripts that have been hastily written. These reports are very infrequent. Glenn. From owner-drums@cs.utk.edu Tue Jul 25 04:23:14 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22243 for ; Tue, 25 Jul 2000 04:23:13 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id EAA08881; Tue, 25 Jul 2000 04:22:30 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 04:22:26 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id EAA08863; Tue, 25 Jul 2000 04:22:26 -0400 (EDT) Received: from draco.cus.cam.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id EAA08849; Tue, 25 Jul 2000 04:22:23 -0400 (EDT) Received: from draco.cus.cam.ac.uk (131.111.8.18 -> draco.cus.cam.ac.uk) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 04:22:23 -0400 Received: from ph10 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 3.16 #3) id 13Gzym-0003Qj-00; Tue, 25 Jul 2000 09:22:20 +0100 Date: Tue, 25 Jul 2000 09:22:20 +0100 (BST) From: Philip Hazel To: Glenn Anderson cc: drums@cs.utk.edu Subject: Re: client requests ending \012 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: On Sun, 23 Jul 2000, Glenn Anderson wrote: > I disagree, my server refuses \012 as an end of line, has done for > years now, and the only "clients" that I have had users report > problems with recently are scripts that have been hastily written. > These reports are very infrequent. On how many hosts does your server run? I originally wrote Exim to be strict; after it had found its way out into the world, it hit this problem. I cannot now remember which clients caused it. I left the "strict" code in, controlled by an #ifdef, but I don't suppose anybody uses it. -- Philip Hazel University of Cambridge Computing Service, ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. From owner-drums@cs.utk.edu Tue Jul 25 04:44:07 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28150 for ; Tue, 25 Jul 2000 04:44:07 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id EAA10664; Tue, 25 Jul 2000 04:43:51 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 04:43:50 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id EAA10647; Tue, 25 Jul 2000 04:43:50 -0400 (EDT) Received: from draco.cus.cam.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id EAA10632; Tue, 25 Jul 2000 04:43:48 -0400 (EDT) Received: from draco.cus.cam.ac.uk (131.111.8.18 -> draco.cus.cam.ac.uk) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 04:43:48 -0400 Received: from ph10 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 3.16 #3) id 13H0JW-0003vG-00 for drums@cs.utk.edu; Tue, 25 Jul 2000 09:43:46 +0100 Date: Tue, 25 Jul 2000 09:43:46 +0100 (BST) From: Philip Hazel To: drums@cs.utk.edu Subject: Re: client requests ending \012 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: Perhaps this problem is about to get worse. This was recently posted on comp.mail.misc: ------ Forwarded Article <397CAD6B.39518851@usa.net> ------ From Karsten Fischer Hi, i've got a problem with javamail. I discovered that all apperances of the linefeed character "\n" were changed into an "\r\n" (Carriage Return+Linefeed) while sending the mail to the smtpserver. I'm working with S/MIME Routines and signed Mails so that all Mails had a bad digest (bad signature) because of the changed Mail Body. Is there an option to prevent this modification ? Ciao, Karsten ------ End of Forwarded Article -- Philip Hazel University of Cambridge Computing Service, ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. From owner-drums@cs.utk.edu Tue Jul 25 07:35:19 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10603 for ; Tue, 25 Jul 2000 07:35:18 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA20371; Tue, 25 Jul 2000 07:35:02 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 07:34:59 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id HAA20352; Tue, 25 Jul 2000 07:34:58 -0400 (EDT) Received: from qualcomm.co.nz (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id HAA20339; Tue, 25 Jul 2000 07:34:54 -0400 (EDT) Received: from qualcomm.co.nz (203.97.196.98 -> doom.qualcomm.co.nz) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 07:34:55 -0400 Received: from [203.97.196.100] (203.97.196.100) by qualcomm.co.nz with ESMTP (Eudora Internet Mail Server 3.0.1) for ; Tue, 25 Jul 2000 23:33:43 +1200 Mime-Version: 1.0 X-Sender: glenn@qualcomm.co.nz@mail.qualcomm.co.nz Message-Id: In-Reply-To: References: Date: Tue, 25 Jul 2000 23:31:01 +1200 To: drums@cs.utk.edu From: Glenn Anderson Subject: Re: client requests ending \012 Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: >On Sun, 23 Jul 2000, Glenn Anderson wrote: > >> I disagree, my server refuses \012 as an end of line, has done for >> years now, and the only "clients" that I have had users report >> problems with recently are scripts that have been hastily written. >> These reports are very infrequent. > >On how many hosts does your server run? Judging by Dan's survey at , it is running on tens of thousands of hosts. Glenn. From owner-drums@cs.utk.edu Tue Jul 25 09:00:12 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06120 for ; Tue, 25 Jul 2000 09:00:12 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id IAA25570; Tue, 25 Jul 2000 08:59:59 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 08:59:58 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id IAA25552; Tue, 25 Jul 2000 08:59:57 -0400 (EDT) Received: from draco.cus.cam.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id IAA25538; Tue, 25 Jul 2000 08:59:51 -0400 (EDT) Received: from draco.cus.cam.ac.uk (131.111.8.18 -> draco.cus.cam.ac.uk) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 08:59:51 -0400 Received: from ph10 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 3.16 #3) id 13H4JJ-000392-00; Tue, 25 Jul 2000 13:59:49 +0100 Date: Tue, 25 Jul 2000 13:59:49 +0100 (BST) From: Philip Hazel To: Glenn Anderson cc: drums@cs.utk.edu Subject: Re: client requests ending \012 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: On Tue, 25 Jul 2000, Glenn Anderson wrote: > >On how many hosts does your server run? > > Judging by Dan's survey at > , it is running on tens of > thousands of hosts. Hmm. I wish I could now remember what client it was that caused me to change Exim. There certainly *was* a problem, and I remember being cross about it when I added the following to Exim's ChangeLog: 67. It seems there are sites that send only LF instead of CRLF in their SMTP transactions, and that smail and sendmail can handle them. Relax Exim's constraints so as to run with the herd. This was in February, 1997. Maybe the rogues have become extinct in the last three years? -- Philip Hazel University of Cambridge Computing Service, ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. From owner-drums@cs.utk.edu Tue Jul 25 11:39:20 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00921 for ; Tue, 25 Jul 2000 11:39:19 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA10053; Tue, 25 Jul 2000 11:39:00 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 11:38:57 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA10035; Tue, 25 Jul 2000 11:38:56 -0400 (EDT) Received: from alpha.ipswitch.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA10010; Tue, 25 Jul 2000 11:38:54 -0400 (EDT) Received: from alpha.ipswitch.com (216.104.149.100) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 11:38:54 -0400 Received: from wks222 [216.104.149.222] by alpha.ipswitch.com (SMTPD32-6.04) id A5AD1A5D004A; Tue, 25 Jul 2000 11:43:41 -0400 From: "Mark Symons" To: Subject: RE: client requests ending \012 Date: Tue, 25 Jul 2000 11:35:28 -0400 Message-ID: <000401bff64d$f5ebcfd0$de9568d8@wks222.augusta.ipswitch.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: Importance: Normal List-Unsubscribe: Content-Transfer-Encoding: 7bit >>On Sun, 23 Jul 2000, Glenn Anderson wrote: >>> I disagree, my server refuses \012 as an end of line, has done for >>> years now, and the only "clients" that I have had users report >>> problems with recently are scripts that have been hastily written. >>> These reports are very infrequent. >> On how many hosts does your server run? > Judging by Dan's survey at > , it is running on > tens of thousands of hosts. There's another useful survey that can be found at: http://www.sirana.com/smtp/default.asp The survey claims to have surveyed 1.3 million hosts. Mark Symons Ipswitch, Inc Augusta GA From owner-drums@cs.utk.edu Tue Jul 25 12:13:43 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12356 for ; Tue, 25 Jul 2000 12:13:42 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA14336; Tue, 25 Jul 2000 12:13:30 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 12:13:29 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA14311; Tue, 25 Jul 2000 12:13:29 -0400 (EDT) Received: from probity.mcc.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA14296; Tue, 25 Jul 2000 12:13:25 -0400 (EDT) Received: from probity.mcc.ac.uk (130.88.200.94 -> probity.mcc.ac.uk) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 12:13:25 -0400 Received: from nessie.mcc.ac.uk ([130.88.200.20] ident=root) by probity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 13H7Kd-0006op-00 for drums@cs.utk.edu; Tue, 25 Jul 2000 17:13:23 +0100 Received: from clw.cs.man.ac.uk (clerew.man.ac.uk [194.66.22.208]) by nessie.mcc.ac.uk (8.9.3/8.8.8) with ESMTP id RAA35468 for ; Tue, 25 Jul 2000 17:13:22 +0100 (BST) (envelope-from root@clw.cs.man.ac.uk) Received: (from root@localhost) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) id NAA19630 for drums@cs.utk.edu; Tue, 25 Jul 2000 13:57:52 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) with SMTP id NAA19627 for ; Tue, 25 Jul 2000 13:57:51 +0100 (BST) Message-Id: <200007251257.NAA19627@clw.cs.man.ac.uk> Date: Tue, 25 Jul 2000 13:57:51 +0100 (BST) From: Charles Lindsey Reply-To: Charles Lindsey Subject: Re: client requests ending \012 To: drums@cs.utk.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yyCW/zeUgk3U05lYe+kLiA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc List-Unsubscribe: On Tue, 25 Jul 2000 09:43:46 +0100 (BST) Philip Hazel said... > > i've got a problem with javamail. I discovered that all apperances of > the linefeed character "\n" were changed into an "\r\n" (Carriage > Return+Linefeed) while sending the mail to the smtpserver. I'm working > with S/MIME Routines and signed Mails so that all Mails had a bad digest > (bad signature) because of the changed Mail Body. Is there an option to > prevent this modification ? Which sounds like a good reason not to use S/MIME. PGP (with its '-t' option) is especially designed to treat all line endings as CRLF, and to disregard trailing whitespace (but not trailing blank lines, infortunately). Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-drums@cs.utk.edu Tue Jul 25 12:40:33 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21787 for ; Tue, 25 Jul 2000 12:40:33 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA17702; Tue, 25 Jul 2000 12:40:12 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 12:40:11 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA17678; Tue, 25 Jul 2000 12:40:10 -0400 (EDT) Received: from prognet.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA17664; Tue, 25 Jul 2000 12:40:08 -0400 (EDT) Received: from prognet.com (205.219.198.1 -> prognet.com) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 12:40:08 -0400 Received: from mscharff.real.com ([172.22.104.48]) by prognet.com (8.9.2/8.9.0) with ESMTP id JAA17853 for ; Tue, 25 Jul 2000 09:40:13 -0700 (PDT) Message-Id: <4.3.2.7.2.20000725093157.00af95f0@mail.real.com> X-Sender: mscharff@mail.real.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Jul 2000 09:41:26 +0100 To: drums@cs.utk.edu From: Michael Scharff Subject: Re: client requests ending \012 In-Reply-To: <200007251257.NAA19627@clw.cs.man.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: I have to chime in here and protest such a response. This sounds like a good reason to go back and insure that CRLF is a MUST and NOT considered optional in ANY CASE. I don't understand why it is so difficult to simply establish a consensus (which it seems pretty obvious to me that there is one, at least on this subject) and move forward with it. There are ALWAYS going to be "rogues" who choose not to adhere to, or perhaps to not even learn, the standards. This is not what we should be focused on, nor is it truly feasible either. What we should be doing is determining REAL, VALID, TECHNICAL reasons for or against any specific mechanism or procedure, such as CRLF . CRLF At 01:57 PM 7/25/00 +0100, you wrote: > On Tue, 25 Jul 2000 09:43:46 +0100 (BST) > Philip Hazel said... > > > > > i've got a problem with javamail. I discovered that all apperances of > > the linefeed character "\n" were changed into an "\r\n" (Carriage > > Return+Linefeed) while sending the mail to the smtpserver. I'm working > > with S/MIME Routines and signed Mails so that all Mails had a bad digest > > (bad signature) because of the changed Mail Body. Is there an option to > > prevent this modification ? > >Which sounds like a good reason not to use S/MIME. PGP (with its '-t' >option) is especially designed to treat all line endings as CRLF, >and to disregard trailing whitespace (but not trailing blank lines, >infortunately). > >Charles H. Lindsey ---------At Home, doing my own >thing------------------------ >Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl >Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, >U.K. >PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 >AB A5 From owner-drums@cs.utk.edu Tue Jul 25 14:58:51 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01610 for ; Tue, 25 Jul 2000 14:58:51 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA02836; Tue, 25 Jul 2000 14:53:26 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 14:53:24 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA02817; Tue, 25 Jul 2000 14:53:24 -0400 (EDT) Received: from draco.cus.cam.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA02783; Tue, 25 Jul 2000 14:53:21 -0400 (EDT) Received: from draco.cus.cam.ac.uk (131.111.8.18 -> draco.cus.cam.ac.uk) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 14:53:21 -0400 Received: from ph10 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 3.16 #3) id 13H9pL-0002f0-00; Tue, 25 Jul 2000 19:53:15 +0100 Date: Tue, 25 Jul 2000 19:53:15 +0100 (BST) From: Philip Hazel To: Michael Scharff cc: drums@cs.utk.edu Subject: Re: client requests ending \012 In-Reply-To: <4.3.2.7.2.20000725093157.00af95f0@mail.real.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: On Tue, 25 Jul 2000, Michael Scharff wrote: > I have to chime in here and protest such a response. This sounds like a > good reason to go back and insure that CRLF is a MUST and NOT considered > optional in ANY CASE. The problem is historical baggage. I can't remember the details, but the reason I changed Exim was something like this: There was a company that had a server running Sendmail or Smail (I can't remember which) and a whole slew of local clients. They changed the server to Exim, and some clients stopped working. The clients were running software for which the source was not available. Management's attitude was "The clients used to work, so they should continue to work."; the technical guys didn't want to go back. Maybe I'm too kind hearted, but I listened to their plea for help. It's the old, old story: if a non-conformance gets widely spread, something will exploit it, and you can never claw back to strict conformance. Once some widely used server is "liberal in what it accepts", everybody else has to follow suit. Look at PP; it tried to implement the RFC "correctly", even to the extent of rejecting messages without a Date: header line (just one example). This just caused trouble. -- Philip Hazel University of Cambridge Computing Service, ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. From owner-drums@cs.utk.edu Tue Jul 25 17:21:52 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10939 for ; Tue, 25 Jul 2000 17:21:52 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA16795; Tue, 25 Jul 2000 17:16:40 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 17:16:38 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA16777; Tue, 25 Jul 2000 17:16:37 -0400 (EDT) Received: from mail.seattlelab.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA16764; Tue, 25 Jul 2000 17:16:35 -0400 (EDT) Received: from mail.seattlelab.com (204.250.145.6 -> mail.seattlelab.com) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 17:16:35 -0400 Received: by mail.seattlelab.com from localhost (router,SLMail V4.1); Tue, 25 Jul 2000 14:20:32 -0700 for Received: from vorlon.seattlelab.com [204.250.145.60] by mail.seattlelab.com [204.250.145.6] (SLmail 4.1.3397) with SMTP id A3D94DD6624911D48F2D004005422FBF for ; Tue, 25 Jul 2000 14:20:31 -0700 From: "Lee Thompson" To: drums@cs.utk.edu Subject: Re: client requests ending \012 Date: Tue, 25 Jul 2000 14:16:51 -0700 Organization: Seattle Lab, Inc. Reply-To: lt@seattlelab.com Message-ID: References: <200007251257.NAA19627@clw.cs.man.ac.uk> <4.3.2.7.2.20000725093157.00af95f0@mail.real.com> In-Reply-To: <4.3.2.7.2.20000725093157.00af95f0@mail.real.com> X-Mailer: Forte Agent 1.8/32.548 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SLUIDL: 9FE74041-624911D4-8F2D0040-05422FBF List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA10939 On Tue, 25 Jul 2000 09:41:26 +0100, you wrote: > I have to chime in here and protest such a response. This sounds like a > good reason to go back and insure that CRLF is a MUST and NOT considered > optional in ANY CASE. I don't understand why it is so difficult to simply > establish a consensus (which it seems pretty obvious to me that there is > one, at least on this subject) and move forward with it. There are ALWAYS > going to be "rogues" who choose not to adhere to, or perhaps to not even > learn, the standards. This is not what we should be focused on, nor is it > truly feasible either. What we should be doing is determining REAL, VALID, > TECHNICAL reasons for or against any specific mechanism or procedure, such > as CRLF . CRLF We market a SMTP/POP3 server for win32 platform and have had to make numerous changes over the years to allow one client (or server) or another interoperate with us. Unfortunately most IT people aren't interested in "that client isn't working to spec" -- they're in the position of having all of their deployed client software working with the server -- and if ours doesn't - they'll go to someone else. The SMTP/Message Format system currently in use is a mess. We have nearly 20 years of standard drift and those standards are vague in some areas. For better or for worse the internet is now a commercial environment which means interoperability and reliability are the key factors. I do think the revised spec should tighten the standard down -- but I also think MTAs should be liberal in what they accept. Anyway my 2 cents :) -- Lee Thompson lt@seattlelab.com Seattle Lab Inc. http://www.seattlelab.com Software Engineer ICQ: 19545760 From owner-drums@cs.utk.edu Tue Jul 25 17:40:51 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15860 for ; Tue, 25 Jul 2000 17:40:51 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA18952; Tue, 25 Jul 2000 17:38:08 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 17:38:03 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA18932; Tue, 25 Jul 2000 17:38:02 -0400 (EDT) Received: from ckmso1.proxy.att.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA18911; Tue, 25 Jul 2000 17:38:00 -0400 (EDT) Received: from ckmso1.proxy.att.com (12.20.58.69 -> ckmso1.att.com) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 17:38:00 -0400 Received: from dns.maillennium.att.com ([135.25.114.99]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id RAA04062 for ; Tue, 25 Jul 2000 17:37:54 -0400 (EDT) Received: from att.com ([135.197.90.148]) by maillennium.att.com (labmail) with SMTP id <2000072521353609900k1u9ce> (Authid: tony@maillennium.att.com); Tue, 25 Jul 2000 21:35:36 +0000 Message-ID: <397E0802.3DDD634C@att.com> Date: Tue, 25 Jul 2000 17:34:58 -0400 From: Tony Hansen Organization: AT&T Laboratories X-Mailer: Mozilla 4.73 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: drums@cs.utk.edu Subject: Re: client requests ending \012 References: <200007251257.NAA19627@clw.cs.man.ac.uk> <4.3.2.7.2.20000725093157.00af95f0@mail.real.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit For DATA, our internal SMTP server keeps reading until it sees a block of data ending in crlf.crlf or it times out. Only on the timeout does it then check to see if there was a lf.lf. Yes, we'll recognize it, but a client that sends it is going to get lousy performance. Seems like a reasonable tradeoff. Tony Hansen tony@att.com From owner-drums@cs.utk.edu Tue Jul 25 18:06:27 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22255 for ; Tue, 25 Jul 2000 18:06:26 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA20965; Tue, 25 Jul 2000 18:01:12 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 18:01:12 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA20948; Tue, 25 Jul 2000 18:01:11 -0400 (EDT) Received: from prognet.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id SAA20933; Tue, 25 Jul 2000 18:01:08 -0400 (EDT) Received: from prognet.com (205.219.198.1 -> prognet.com) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 18:01:08 -0400 Received: from mscharff.real.com ([172.22.104.48]) by prognet.com (8.9.2/8.9.0) with ESMTP id PAA15441; Tue, 25 Jul 2000 15:01:13 -0700 (PDT) Message-Id: <4.3.2.7.2.20000725145831.00af4ec0@mail.real.com> X-Sender: mscharff@mail.real.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Jul 2000 15:02:19 +0100 To: "Larry Osterman" , "Philip Hazel" From: Michael Scharff Subject: RE: client requests ending \012 Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" List-Unsubscribe: I don't disagree with this philosophy at all. What I have issue with is that we appear to be expanding the RFC's to include these "gentlemen's agreements" instead of holding true to the original concept that you describe below. If anything , we have taken it to the extreme in the name of "interoperability". As I stated before, there will always be "rogues" and "non-conformists", however, this doesn't mean that we should relax the standard to the point where there is no standard at all.




At 02:39 PM 7/25/00 -0700, Larry Osterman wrote:

I've been keeping quiet for quite some time now, but I gotta chime in right now:

Even if 821bis has a MUST that CRLF is the line terminator (and not just LF), this only means that a server MUST treat CRLF as a line terminator, and that a conforming client MUST generate only CRLF characters.

It says NOTHING about what a particular implementation choses to accept in the face of broken clients.  When faced with a client that sends only LF, an SMTP server vendor has two choices that they can make:

        1) Say to the author of the client: "You are violating the protocol, fix your client (neener neener :))"
or      2) Change the server to also accept LF as a line terminator (be liberal in what you accept, conservative in what you generate).

There is nothing in 821bis that says that a server MUST NOT accept LF as a line terminator, all that 821bis does is to specify the conforming on-the-wire format for the SMTP protocol.  A server vendor can still choose (for the sake of interoperability) to accept input from non conforming clients, that's their choice.  However a vendor does not HAVE to accept input from a non conforming client, and having an explicit prohibition against LF (or if you'd rather, an explicit endorsement of CRLF) in the protocol provides amunition for a server vendor that wants to say #1.  If the specification is mute, then the client vendor can say (as they did to Philip below) "but [sendmail|qmail|whatever] accepted my input, your server must be the broken one".

I've been reading the recent debate with a great deal of amusement, this issue (and the issue involving arguments to DATA and RSET) make it clear to me that some of the people reading the list have forgotten one of the principal tenets of IETF protocol design:

There is nothing in 821bis (or any other IETF protocol) that prevents servers from chosing to accept inputs that are NOT covered by 821bis (arguments to DATA and RSET, or raw LF's as line terminators, for example), but if they do so, they are doing it between concenting adults and outside the protocol.

As long as a server/client accepts ALL legal inputs as defined by 821bis, and produces output that is in conformance with 821bis, it's an 821bis server.  Anything else falls into the area of gentleman's agreements.

What the protocol definition does is to describe what you MUST do to claim to be 821bis, and it provides amunition for those who ARE 821bis to try to convince those who are NOT 821bis to change.  It is NOT intended to be a comprehensive implementors guide, neither is it intended to be a document that describes every possible situation that might be encountered in internet email (some of the strawmen brought up during the "must say quit" debate come to mind on that respect).

(And before anyone rakes me over the coals, I know that Nick Shelness and Keith Moore have both said what I said multiple times, I just thought it needed to be said still one more time).


Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000 and Exchange Platinum!  Please notify the sender of any difficulties.

I'm an individual, and nothing I say should be considered an official policy of Microsoft :)

> -----Original Message-----
> From: Philip Hazel [mailto:ph10@cus.cam.ac.uk]
> Sent: Tuesday, July 25, 2000 11:53 AM
> To: Michael Scharff
> Cc: drums@cs.utk.edu
> Subject: Re: client requests ending \012
>
>
> On Tue, 25 Jul 2000, Michael Scharff wrote:
>
> > I have to chime in here and protest such a response. This
> sounds like a
> > good reason to go back and insure that CRLF is a MUST and
> NOT considered
> > optional in ANY CASE.
>
> The problem is historical baggage. I can't remember the
> details, but the
> reason I changed Exim was something like this: There was a
> company that
> had a server running Sendmail or Smail (I can't remember which) and a
> whole slew of local clients. They changed the server to Exim,
> and some
> clients stopped working. The clients were running software
> for which the
> source was not available. Management's attitude was "The
> clients used to
> work, so they should continue to work."; the technical guys
> didn't want to
> go back. Maybe I'm too kind hearted, but I listened to their plea for
> help.
>
> It's the old, old story: if a non-conformance gets widely spread,
> something will exploit it, and you can never claw back to strict
> conformance. Once some widely used server is "liberal in what it
> accepts", everybody else has to follow suit. Look at PP; it tried to
> implement the RFC "correctly", even to the extent of
> rejecting messages
> without a Date: header line (just one example). This just caused
> trouble.
>
> --
> Philip Hazel            University of Cambridge Computing Service,
> ph10@cus.cam.ac.uk      Cambridge, England. Phone: +44 1223 334714.
>
From owner-drums@cs.utk.edu Tue Jul 25 18:16:16 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26429 for ; Tue, 25 Jul 2000 18:16:16 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA21818; Tue, 25 Jul 2000 18:11:02 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 18:11:02 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA21801; Tue, 25 Jul 2000 18:11:02 -0400 (EDT) Received: from dfssl.exchange.microsoft.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA21787; Tue, 25 Jul 2000 18:10:59 -0400 (EDT) Received: from dfssl.exchange.microsoft.com (131.107.88.59 -> dfssl.exchange.microsoft.com) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 18:10:59 -0400 Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Jul 2000 14:40:37 -0700 (Pacific Daylight Time) Received: from DF-SPOT.platinum.corp.microsoft.com ([172.30.236.99]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Tue, 25 Jul 2000 14:49:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4408.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFF680.CF850FBB" Subject: RE: client requests ending \012 Date: Tue, 25 Jul 2000 14:39:28 -0700 Message-ID: Thread-Topic: client requests ending \012 Thread-Index: Ab/2afkpe6ZM0grtQN+iSzXCFjHFvwAFAQVw From: "Larry Osterman" To: "Philip Hazel" , "Michael Scharff" Cc: X-OriginalArrivalTime: 25 Jul 2000 21:49:30.0272 (UTC) FILETIME=[360DD200:01BFF682] List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01BFF680.CF850FBB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've been keeping quiet for quite some time now, but I gotta chime in right now: Even if 821bis has a MUST that CRLF is the line terminator (and not just LF), this only means that a server MUST treat CRLF as a line terminator, and that a conforming client MUST generate only CRLF characters. It says NOTHING about what a particular implementation choses to accept in the face of broken clients. When faced with a client that sends only LF, an SMTP server vendor has two choices that they can make: 1) Say to the author of the client: "You are violating the protocol, fix your client (neener neener :))" or 2) Change the server to also accept LF as a line terminator (be liberal in what you accept, conservative in what you generate). There is nothing in 821bis that says that a server MUST NOT accept LF as a line terminator, all that 821bis does is to specify the conforming on-the-wire format for the SMTP protocol. A server vendor can still choose (for the sake of interoperability) to accept input from non conforming clients, that's their choice. However a vendor does not HAVE to accept input from a non conforming client, and having an explicit prohibition against LF (or if you'd rather, an explicit endorsement of CRLF) in the protocol provides amunition for a server vendor that wants to say #1. If the specification is mute, then the client vendor can say (as they did to Philip below) "but [sendmail|qmail|whatever] accepted my input, your server must be the broken one". I've been reading the recent debate with a great deal of amusement, this issue (and the issue involving arguments to DATA and RSET) make it clear to me that some of the people reading the list have forgotten one of the principal tenets of IETF protocol design: There is nothing in 821bis (or any other IETF protocol) that prevents servers from chosing to accept inputs that are NOT covered by 821bis (arguments to DATA and RSET, or raw LF's as line terminators, for example), but if they do so, they are doing it between concenting adults and outside the protocol. As long as a server/client accepts ALL legal inputs as defined by 821bis, and produces output that is in conformance with 821bis, it's an 821bis server. Anything else falls into the area of gentleman's agreements. What the protocol definition does is to describe what you MUST do to claim to be 821bis, and it provides amunition for those who ARE 821bis to try to convince those who are NOT 821bis to change. It is NOT intended to be a comprehensive implementors guide, neither is it intended to be a document that describes every possible situation that might be encountered in internet email (some of the strawmen brought up during the "must say quit" debate come to mind on that respect). (And before anyone rakes me over the coals, I know that Nick Shelness and Keith Moore have both said what I said multiple times, I just thought it needed to be said still one more time). Larry Osterman Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 2000 and Exchange Platinum! Please notify the sender of any difficulties. I'm an individual, and nothing I say should be considered an official policy of Microsoft :) > -----Original Message----- > From: Philip Hazel [mailto:ph10@cus.cam.ac.uk] > Sent: Tuesday, July 25, 2000 11:53 AM > To: Michael Scharff > Cc: drums@cs.utk.edu > Subject: Re: client requests ending \012 >=20 >=20 > On Tue, 25 Jul 2000, Michael Scharff wrote: >=20 > > I have to chime in here and protest such a response. This=20 > sounds like a=20 > > good reason to go back and insure that CRLF is a MUST and=20 > NOT considered=20 > > optional in ANY CASE.=20 >=20 > The problem is historical baggage. I can't remember the=20 > details, but the=20 > reason I changed Exim was something like this: There was a=20 > company that=20 > had a server running Sendmail or Smail (I can't remember which) and a=20 > whole slew of local clients. They changed the server to Exim,=20 > and some=20 > clients stopped working. The clients were running software=20 > for which the=20 > source was not available. Management's attitude was "The=20 > clients used to > work, so they should continue to work."; the technical guys=20 > didn't want to > go back. Maybe I'm too kind hearted, but I listened to their plea for=20 > help. >=20 > It's the old, old story: if a non-conformance gets widely spread,=20 > something will exploit it, and you can never claw back to strict=20 > conformance. Once some widely used server is "liberal in what it=20 > accepts", everybody else has to follow suit. Look at PP; it tried to=20 > implement the RFC "correctly", even to the extent of=20 > rejecting messages > without a Date: header line (just one example). This just caused=20 > trouble. >=20 > --=20 > Philip Hazel University of Cambridge Computing Service, > ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. >=20 ------_=_NextPart_001_01BFF680.CF850FBB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: client requests ending \012

I've been keeping quiet for quite some time now, but I = gotta chime in right now:


Even if 821bis has a MUST that CRLF is the line = terminator (and not just LF), this only means that a server MUST treat = CRLF as a line terminator, and that a conforming client MUST generate = only CRLF characters.

It says NOTHING about what a particular implementation = choses to accept in the face of broken clients.  When faced with a = client that sends only LF, an SMTP server vendor has two choices that = they can make:

        1) Say to = the author of the client: "You are violating the protocol, fix your = client (neener neener :))"
or      2) Change the server = to also accept LF as a line terminator (be liberal in what you accept, = conservative in what you generate).

There is nothing in 821bis that says that a server = MUST NOT accept LF as a line terminator, all that 821bis does is to = specify the conforming on-the-wire format for the SMTP protocol.  A = server vendor can still choose (for the sake of interoperability) to = accept input from non conforming clients, that's their choice.  = However a vendor does not HAVE to accept input from a non conforming = client, and having an explicit prohibition against LF (or if you'd = rather, an explicit endorsement of CRLF) in the protocol provides = amunition for a server vendor that wants to say #1.  If the = specification is mute, then the client vendor can say (as they did to = Philip below) "but [sendmail|qmail|whatever] accepted my input, = your server must be the broken one".

I've been reading the recent debate with a great deal = of amusement, this issue (and the issue involving arguments to DATA and = RSET) make it clear to me that some of the people reading the list have = forgotten one of the principal tenets of IETF protocol = design:

There is nothing in 821bis (or any other IETF = protocol) that prevents servers from chosing to accept inputs that are = NOT covered by 821bis (arguments to DATA and RSET, or raw LF's as line = terminators, for example), but if they do so, they are doing it between = concenting adults and outside the protocol.

As long as a server/client accepts ALL legal inputs as = defined by 821bis, and produces output that is in conformance with = 821bis, it's an 821bis server.  Anything else falls into the area = of gentleman's agreements.

What the protocol definition does is to describe what = you MUST do to claim to be 821bis, and it provides amunition for those = who ARE 821bis to try to convince those who are NOT 821bis to = change.  It is NOT intended to be a comprehensive implementors = guide, neither is it intended to be a document that describes every = possible situation that might be encountered in internet email (some of = the strawmen brought up during the "must say quit" debate come = to mind on that respect).

(And before anyone rakes me over the coals, I know = that Nick Shelness and Keith Moore have both said what I said multiple = times, I just thought it needed to be said still one more = time).



Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 = and Outlook 2000 and Exchange Platinum!  Please notify the sender = of any difficulties.

I'm an individual, and nothing I say should be = considered an official policy of Microsoft :)


> -----Original Message-----
> From: Philip Hazel [mailto:ph10@cus.cam.ac.uk]
> Sent: Tuesday, July 25, 2000 11:53 AM
> To: Michael Scharff
> Cc: drums@cs.utk.edu
> Subject: Re: client requests ending \012
>
>
> On Tue, 25 Jul 2000, Michael Scharff = wrote:
>
> > I have to chime in here and protest such a = response. This
> sounds like a
> > good reason to go back and insure that CRLF = is a MUST and
> NOT considered
> > optional in ANY CASE.
>
> The problem is historical baggage. I can't = remember the
> details, but the
> reason I changed Exim was something like this: = There was a
> company that
> had a server running Sendmail or Smail (I can't = remember which) and a
> whole slew of local clients. They changed the = server to Exim,
> and some
> clients stopped working. The clients were = running software
> for which the
> source was not available. Management's attitude = was "The
> clients used to
> work, so they should continue to work."; = the technical guys
> didn't want to
> go back. Maybe I'm too kind hearted, but I = listened to their plea for
> help.
>
> It's the old, old story: if a non-conformance = gets widely spread,
> something will exploit it, and you can never = claw back to strict
> conformance. Once some widely used server is = "liberal in what it
> accepts", everybody else has to follow = suit. Look at PP; it tried to
> implement the RFC "correctly", even to = the extent of
> rejecting messages
> without a Date: header line (just one example). = This just caused
> trouble.
>
> --
> Philip = Hazel            = University of Cambridge Computing Service,
> ph10@cus.cam.ac.uk      = Cambridge, England. Phone: +44 1223 334714.
>

------_=_NextPart_001_01BFF680.CF850FBB-- From owner-drums@cs.utk.edu Tue Jul 25 18:22:26 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28986 for ; Tue, 25 Jul 2000 18:22:26 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA22529; Tue, 25 Jul 2000 18:17:15 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 18:17:14 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA22512; Tue, 25 Jul 2000 18:17:14 -0400 (EDT) Received: from solidum.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id SAA22497; Tue, 25 Jul 2000 18:17:08 -0400 (EDT) Received: from solidum.com (207.35.224.226) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 18:17:12 -0400 Received: from phobos.solidum.com (mcr@phobos.solidum.com [192.168.1.13]) by solidum.com (8.8.7/8.8.7) with ESMTP id SAA06823 for ; Tue, 25 Jul 2000 18:17:07 -0400 Message-Id: <200007252217.SAA06823@solidum.com> To: drums@cs.utk.edu Subject: Re: client requests ending \012 In-Reply-To: Your message of "Tue, 25 Jul 2000 14:16:51 PDT." Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII Date: Tue, 25 Jul 2000 18:17:06 -0400 From: Michael Richardson List-Unsubscribe: >>>>> "Lee" == Lee Thompson writes: Lee> We market a SMTP/POP3 server for win32 platform and have had to make Lee> numerous changes over the years to allow one client (or server) or Lee> another interoperate with us. Lee> Unfortunately most IT people aren't interested in "that client isn't Lee> working to spec" -- they're in the position of having all of their Lee> deployed client software working with the server -- and if ours Lee> doesn't - they'll go to someone else. Some group, e.g. IMC or some such, needs to actually test against the spec. :!mcr!: | Solidum Systems Corporation, http://www.solidum.com Michael Richardson |For a better connected world,where data flows faster Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html mailto:mcr@sandelman.ottawa.on.ca mailto:mcr@solidum.com From owner-drums@cs.utk.edu Tue Jul 25 21:20:32 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17395 for ; Tue, 25 Jul 2000 21:20:32 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA04248; Tue, 25 Jul 2000 21:20:19 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Tue, 25 Jul 2000 21:20:17 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA04228; Tue, 25 Jul 2000 21:20:17 -0400 (EDT) Received: from ns.secondary.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA04215; Tue, 25 Jul 2000 21:20:15 -0400 (EDT) Received: from ns.secondary.com (208.184.76.39 -> ns.secondary.com) by cs.utk.edu (smtpshim v1.0); Tue, 25 Jul 2000 21:20:15 -0400 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA20222 for ; Tue, 25 Jul 2000 18:17:09 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: References: Date: Tue, 25 Jul 2000 18:20:11 -0700 To: From: Paul Hoffman / IMC Subject: RE: client requests ending \012 Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: At 2:39 PM -0700 7/25/00, Larry Osterman wrote: >Even if 821bis has a MUST that CRLF is the line terminator (and not >just LF), this only means that a server MUST treat CRLF as a line >terminator, and that a conforming client MUST generate only CRLF >characters. The actual text from 2.3.7 reads: Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator. "MUST NOT recognize" is what is being discussed here. --Paul Hoffman, Director --Internet Mail Consortium From owner-drums@cs.utk.edu Wed Jul 26 04:36:02 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04057 for ; Wed, 26 Jul 2000 04:36:01 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id EAA22584; Wed, 26 Jul 2000 04:35:43 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 04:35:41 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id EAA22567; Wed, 26 Jul 2000 04:35:41 -0400 (EDT) Received: from draco.cus.cam.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id EAA22554; Wed, 26 Jul 2000 04:35:39 -0400 (EDT) Received: from draco.cus.cam.ac.uk (131.111.8.18 -> draco.cus.cam.ac.uk) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 04:35:39 -0400 Received: from ph10 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 3.16 #3) id 13HMfB-0000pZ-00; Wed, 26 Jul 2000 09:35:37 +0100 Date: Wed, 26 Jul 2000 09:35:37 +0100 (BST) From: Philip Hazel To: Paul Hoffman / IMC cc: drums@cs.utk.edu Subject: RE: client requests ending \012 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: On Tue, 25 Jul 2000, Paul Hoffman / IMC wrote: > The actual text from 2.3.7 reads: > > Conforming > implementations MUST NOT recognize or generate any other character or > character sequence as a line terminator. > > "MUST NOT recognize" is what is being discussed here. Quite. This seems to be a tightening up of the "be liberal in what you accept" philosophy. On the one hand, I would like to see this, but on the other hand, I don't believe you can achieve it, because it would require vast numbers of deployed MTAs to change more or less simultaneously. The genie is out of the bottle, as I keep saying. -- Philip Hazel University of Cambridge Computing Service, ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. From owner-drums@cs.utk.edu Wed Jul 26 05:05:11 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10597 for ; Wed, 26 Jul 2000 05:05:10 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA24099; Wed, 26 Jul 2000 05:05:00 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 05:04:59 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id FAA24082; Wed, 26 Jul 2000 05:04:59 -0400 (EDT) Received: from coltrane.datcon.co.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id FAA24068; Wed, 26 Jul 2000 05:04:55 -0400 (EDT) Received: from coltrane.datcon.co.uk (192.91.191.4 -> smtp.datcon.co.uk) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 05:04:55 -0400 Received: by smtp.datcon.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 26 Jul 2000 10:04:47 +0100 Message-ID: <211CB011B50ED3118DEB00902778A63630C646@basie.datcon.co.uk> From: Edward Hibbert To: drums@cs.utk.edu Subject: RE: client requests ending \012 Date: Wed, 26 Jul 2000 10:04:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain List-Unsubscribe: I disapprove of the "must not recognise" text. I think that: - existing implementations will ignore this text in the proven interest of interoperability - any new implementor who follows the RFC will become very frustrated when it later emerges that the RFC is explicitly encouraging them to add interop problems to their code. There's an analogy in the X.400 world, where the spec is much tighter and there are people who test implementations for conformance. Even that doesn't stop interop problems, and since it is the suppliers of the most correct implementations who are typically more responsive to fixing problems than the worse implementations which are violating the spec, the policy of being liberal in what you accept has emerged there too. I would agree with Dan that there is no consensus on this point. Edward Hibbert DCL. -----Original Message----- From: Philip Hazel [mailto:ph10@cus.cam.ac.uk] Sent: Wednesday, July 26, 2000 9:36 AM To: Paul Hoffman / IMC Cc: drums@cs.utk.edu Subject: RE: client requests ending \012 On Tue, 25 Jul 2000, Paul Hoffman / IMC wrote: > The actual text from 2.3.7 reads: > > Conforming > implementations MUST NOT recognize or generate any other character or > character sequence as a line terminator. > > "MUST NOT recognize" is what is being discussed here. Quite. This seems to be a tightening up of the "be liberal in what you accept" philosophy. On the one hand, I would like to see this, but on the other hand, I don't believe you can achieve it, because it would require vast numbers of deployed MTAs to change more or less simultaneously. The genie is out of the bottle, as I keep saying. -- Philip Hazel University of Cambridge Computing Service, ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. From owner-drums@cs.utk.edu Wed Jul 26 05:37:28 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17627 for ; Wed, 26 Jul 2000 05:37:27 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id FAA28829; Wed, 26 Jul 2000 05:37:13 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 05:37:12 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id FAA28812; Wed, 26 Jul 2000 05:37:12 -0400 (EDT) Received: from ss3000e.cselt.it (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id FAA28799; Wed, 26 Jul 2000 05:37:04 -0400 (EDT) Received: from ss3000e.cselt.it (163.162.41.5 -> ss3000e.cselt.it) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 05:37:08 -0400 Received: from beatles.cselt.it (beatles.cselt.it [163.162.29.125]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0FYA00BJOSO7GK@ss3000e.cselt.it> for drums@cs.utk.edu; Wed, 26 Jul 2000 11:21:43 +0200 (MET DST) Received: from beatles.cselt.it (beatles.cselt.it [163.162.29.125]) by beatles.cselt.it (8.9.3/8.9.3) with SMTP id LAA26383 for ; Wed, 26 Jul 2000 11:26:49 +0200 (MET DST) Date: Wed, 26 Jul 2000 11:26:49 +0200 (MET DST) From: Maurizio Codogno Subject: RE: client requests ending \012 To: drums@cs.utk.edu Reply-to: Maurizio Codogno Message-id: <200007260926.LAA26383@beatles.cselt.it> MIME-version: 1.0 X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-MD5: cAcvdCaSB7yDVGm1qWQhPw== List-Unsubscribe: > From: Edward Hibbert > I disapprove of the "must not recognise" text. I think that: > - existing implementations will ignore this text in the proven interest of > interoperability > - any new implementor who follows the RFC will become very frustrated when > it later emerges that the RFC is explicitly encouraging them to add interop > problems to their code. but this means that you explicitly defy the scope of the standard, approving bad implementations and mandating good guys to accept them. ciao, .mau. From owner-drums@cs.utk.edu Wed Jul 26 06:17:50 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26392 for ; Wed, 26 Jul 2000 06:17:49 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA00683; Wed, 26 Jul 2000 06:17:36 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 06:17:36 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA00666; Wed, 26 Jul 2000 06:17:35 -0400 (EDT) Received: from lint.cisco.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA00652; Wed, 26 Jul 2000 06:17:33 -0400 (EDT) Received: from lint.cisco.com (171.68.224.209 -> lint.cisco.com) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 06:17:33 -0400 Received: from cisco.com (london-async22.cisco.com [144.254.38.161]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id DAA12954; Wed, 26 Jul 2000 03:17:28 -0700 (PDT) Message-ID: <397EBAB3.4A47D191@cisco.com> Date: Wed, 26 Jul 2000 03:17:23 -0700 From: Eliot Lear Reply-To: lear@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Edward Hibbert CC: drums@cs.utk.edu Subject: Re: client requests ending \012 References: <211CB011B50ED3118DEB00902778A63630C646@basie.datcon.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit The problem, again, is that LF.LF causes ambiguity, and so this business about being liberal in what you accept is not relevant. One should not be liberal in what one accepts at the expense of not being able to accept legitimate text. -- Eliot Lear lear@cisco.com From owner-drums@cs.utk.edu Wed Jul 26 06:58:50 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06056 for ; Wed, 26 Jul 2000 06:58:49 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA02442; Wed, 26 Jul 2000 06:58:36 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 06:58:34 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA02385; Wed, 26 Jul 2000 06:58:33 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA02349; Wed, 26 Jul 2000 06:58:30 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 06:58:30 -0400 Received: from free.88.106.bayarea.net (free.88.106.bayarea.net [205.219.88.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id DAA10010 for ; Wed, 26 Jul 2000 03:58:28 -0700 X-Authentication-Warning: joy.songbird.com: free.88.106.bayarea.net [205.219.88.106] didn't use HELO protocol Message-Id: <4.3.2.20000726035015.00bdbe10@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 26 Jul 2000 03:55:10 -0700 To: drums@cs.utk.edu From: Dave Crocker Subject: Re: client requests ending \012 In-Reply-To: <20000721095236.8266.qmail@cr.yp.to> References: <20000720001401.19958.qmail@cr.yp.to> <200007201645.MAA04825@astro.cs.utk.edu> <20000721055148.11725.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: So, my question to the list is this: What is being accomplished by this lengthy thread? We are re-hashing a topic that was argued and decided before. Why? Do we have new information? No! We are seeing that some participants have not read, or do not recall, the specification text or the history of relevant discussion. Document progress should not be delayed by such clarifications. We are seeing that some participants do not understand the difference between rules of a standard, versus choices made in the privacy of one's own network. Is it really necessary to delay the document further while we engage in pedagogy about standards? Let's move on. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Wed Jul 26 07:24:17 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06068 for ; Wed, 26 Jul 2000 06:58:51 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA02434; Wed, 26 Jul 2000 06:58:36 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 06:58:33 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA02384; Wed, 26 Jul 2000 06:58:33 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA02348; Wed, 26 Jul 2000 06:58:30 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 06:58:30 -0400 Received: from free.88.106.bayarea.net (free.88.106.bayarea.net [205.219.88.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id DAA10006; Wed, 26 Jul 2000 03:58:27 -0700 X-Authentication-Warning: joy.songbird.com: free.88.106.bayarea.net [205.219.88.106] didn't use HELO protocol Message-Id: <4.3.2.20000726034710.00bd4100@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 26 Jul 2000 03:48:47 -0700 To: lt@seattlelab.com From: Dave Crocker Subject: Re: client requests ending \012 Cc: drums@cs.utk.edu In-Reply-To: References: <4.3.2.7.2.20000725093157.00af95f0@mail.real.com> <200007251257.NAA19627@clw.cs.man.ac.uk> <4.3.2.7.2.20000725093157.00af95f0@mail.real.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 02:16 PM 7/25/00 -0700, Lee Thompson wrote: >The SMTP/Message Format system currently in use is a mess. We have nearly 20 >years of standard drift and those standards are vague in some areas. For >better or for worse the internet is now a commercial environment which means >interoperability and reliability are the key factors. There is truth in what you observe, but it does not apply to CRLF. If anything the standards drift is due to constantly making local changes to accept non-conforming behavior. It is the norm for email. Imagine if folks had taken that approach for TCP... d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Wed Jul 26 07:24:17 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06066 for ; Wed, 26 Jul 2000 06:58:50 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id GAA02440; Wed, 26 Jul 2000 06:58:36 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 06:58:34 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id GAA02401; Wed, 26 Jul 2000 06:58:33 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id GAA02366; Wed, 26 Jul 2000 06:58:31 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 06:58:31 -0400 Received: from free.88.106.bayarea.net (free.88.106.bayarea.net [205.219.88.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id DAA09996; Wed, 26 Jul 2000 03:58:23 -0700 X-Authentication-Warning: joy.songbird.com: free.88.106.bayarea.net [205.219.88.106] didn't use HELO protocol Message-Id: <4.3.2.20000726034406.00bb9430@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 26 Jul 2000 03:46:43 -0700 To: Philip Hazel From: Dave Crocker Subject: Re: client requests ending \012 Cc: Michael Scharff , drums@cs.utk.edu In-Reply-To: References: <4.3.2.7.2.20000725093157.00af95f0@mail.real.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 07:53 PM 7/25/00 +0100, Philip Hazel wrote: >whole slew of local clients. They changed the server to Exim, and some >clients stopped working. The clients were running software for which the >source was not available. Management's attitude was "The clients used to >work, so they should continue to work."; the technical guys didn't want to >go back. Maybe I'm too kind hearted, but I listened to their plea for >help. You took a quality approach to responding to a customer problem. The line "it worked with the competition's software" pretty much left you with no choice about making a change. The difficulty is with imposing a fix for a local problem as a global product default. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Wed Jul 26 09:29:56 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10214 for ; Wed, 26 Jul 2000 09:29:55 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA12280; Wed, 26 Jul 2000 09:29:19 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 09:29:16 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA12263; Wed, 26 Jul 2000 09:29:15 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA12247; Wed, 26 Jul 2000 09:29:14 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 09:29:14 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA29477; Wed, 26 Jul 2000 09:29:09 -0400 (EDT) Message-Id: <200007261329.JAA29477@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: lear@cisco.com cc: Edward Hibbert , drums@cs.utk.edu Subject: Re: client requests ending \012 In-reply-to: Your message of "Wed, 26 Jul 2000 03:17:23 PDT." <397EBAB3.4A47D191@cisco.com> Date: Wed, 26 Jul 2000 09:29:09 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > The problem, again, is that LF.LF causes ambiguity, and so this business > about being liberal in what you accept is not relevant. One should not > be liberal in what one accepts at the expense of not being able to > accept legitimate text. right. the issue is not whether you accept LF as a command terminator (unless you use the same routine to read commands as you do to read DATA) the issue is whether a server accepts LF . LF as a message terminator for DATA. related issues include when a client sees a LF . in a message body - does it send LF . or LF ..? and when a server sees LF ..foo in a message body, does it remove the first dot? note that detecting the use of bare LF as a command terminator may be an effective way of identifying broken clients before the DATA phase, where it's easier to provide meaningful error messages. Keith From owner-drums@cs.utk.edu Wed Jul 26 09:35:42 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11577 for ; Wed, 26 Jul 2000 09:35:41 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA12899; Wed, 26 Jul 2000 09:35:21 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 09:35:20 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA12881; Wed, 26 Jul 2000 09:35:20 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA12864; Wed, 26 Jul 2000 09:35:18 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 09:35:18 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA29613; Wed, 26 Jul 2000 09:35:13 -0400 (EDT) Message-Id: <200007261335.JAA29613@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Philip Hazel , Michael Scharff , drums@cs.utk.edu Subject: Re: client requests ending \012 In-reply-to: Your message of "Wed, 26 Jul 2000 03:46:43 PDT." <4.3.2.20000726034406.00bb9430@mail.bayarea.net> Date: Wed, 26 Jul 2000 09:35:13 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > The difficulty is with imposing a fix for a local problem as a global > product default. except that it's not purely a local problem - the same clients could (and often do) crop up anywhere. and the vendor ends up dealing with this support issue again and again. much easier to just 'fix' the problem. I'd say that the difficulty is one of trying to get people to accept near-term pain to minimize long-term pain. and also the difficulty of replacing many broken clients when you can "fix" the problem on a small number of servers. Keith this may actually be a "flaw" in the traditional IETF notion of interoperability testing being sufficient - merely being able to interoperate doesn't mean that the implementations conform to the standard, or more importantly, that the implementations behave robustly in corner cases (like LF . LF in the middle of a message). From owner-drums@cs.utk.edu Wed Jul 26 12:13:41 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14104 for ; Wed, 26 Jul 2000 12:13:41 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA26192; Wed, 26 Jul 2000 12:13:24 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 12:13:22 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA26175; Wed, 26 Jul 2000 12:13:22 -0400 (EDT) Received: from probity.mcc.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA26147; Wed, 26 Jul 2000 12:13:16 -0400 (EDT) Received: from probity.mcc.ac.uk (130.88.200.94 -> probity.mcc.ac.uk) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 12:13:17 -0400 Received: from nessie.mcc.ac.uk ([130.88.200.20] ident=root) by probity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 13HTo3-000HCg-00 for drums@cs.utk.edu; Wed, 26 Jul 2000 17:13:15 +0100 Received: from clw.cs.man.ac.uk (clerew.man.ac.uk [194.66.22.208]) by nessie.mcc.ac.uk (8.9.3/8.8.8) with ESMTP id RAA77407 for ; Wed, 26 Jul 2000 17:13:13 +0100 (BST) (envelope-from root@clw.cs.man.ac.uk) Received: (from root@localhost) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) id RAA26417 for drums@cs.utk.edu; Wed, 26 Jul 2000 17:02:02 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) with SMTP id RAA26414 for ; Wed, 26 Jul 2000 17:02:01 +0100 (BST) Message-Id: <200007261602.RAA26414@clw.cs.man.ac.uk> Date: Wed, 26 Jul 2000 17:02:01 +0100 (BST) From: Charles Lindsey Reply-To: Charles Lindsey Subject: Re: client requests ending \012 To: drums@cs.utk.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: o4jz2AJ87YjQmH8CgAqcCA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc List-Unsubscribe: On Wed, 26 Jul 2000 09:35:37 +0100 (BST) Philip Hazel said... > > On Tue, 25 Jul 2000, Paul Hoffman / IMC wrote: > > > The actual text from 2.3.7 reads: > > > > Conforming > > implementations MUST NOT recognize or generate any other character or > > character sequence as a line terminator. > > > > "MUST NOT recognize" is what is being discussed here. > > Quite. This seems to be a tightening up of the "be liberal in what you > accept" philosophy. On the one hand, I would like to see this, but on > the other hand, I don't believe you can achieve it, because it would > require vast numbers of deployed MTAs to change more or less > simultaneously. The genie is out of the bottle, as I keep saying. This sound like a classic case for saying "SHOULD NOT recognize". You are only suppose to say MUST NOT if something would otherwise immediately break, which does not seem to be the case here. On Wed, 26 Jul 2000 03:17:23 -0700 Eliot Lear said... > > The problem, again, is that LF.LF causes ambiguity, and so this business > about being liberal in what you accept is not relevant. One should not > be liberal in what one accepts at the expense of not being able to > accept legitimate text. What precisely is the ambiguity? Naked LF should not be found in a conforming message, so if a server chooses to be liberal when it sees same are there two possible interpretations it could place? If not, there is no ambiguity. Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-drums@cs.utk.edu Wed Jul 26 13:09:23 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23189 for ; Wed, 26 Jul 2000 13:09:22 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA02698; Wed, 26 Jul 2000 13:09:03 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 13:09:03 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA02679; Wed, 26 Jul 2000 13:09:02 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA02663; Wed, 26 Jul 2000 13:09:01 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 13:09:01 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id NAA03951; Wed, 26 Jul 2000 13:08:57 -0400 (EDT) Message-Id: <200007261708.NAA03951@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Charles Lindsey cc: drums@cs.utk.edu Subject: Re: client requests ending \012 In-reply-to: Your message of "Wed, 26 Jul 2000 17:02:01 BST." <200007261602.RAA26414@clw.cs.man.ac.uk> Date: Wed, 26 Jul 2000 13:08:56 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > Naked LF should not be found in a conforming message naked LF is valid in RFC 822. (though it's highly likely to be converted to CRLF by some MTA) Keith From owner-drums@cs.utk.edu Wed Jul 26 14:38:31 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13655 for ; Wed, 26 Jul 2000 14:38:30 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id OAA11909; Wed, 26 Jul 2000 14:38:15 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 14:38:11 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id OAA11892; Wed, 26 Jul 2000 14:38:09 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id OAA11868; Wed, 26 Jul 2000 14:38:03 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 14:38:03 -0400 Received: from free.88.106.bayarea.net (free.88.106.bayarea.net [205.219.88.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id LAA14448; Wed, 26 Jul 2000 11:38:01 -0700 X-Authentication-Warning: joy.songbird.com: free.88.106.bayarea.net [205.219.88.106] didn't use HELO protocol Message-Id: <4.3.2.20000726113203.00be3a60@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 26 Jul 2000 11:33:38 -0700 To: Keith Moore From: Dave Crocker Subject: Re: client requests ending \012 Cc: drums@cs.utk.edu In-Reply-To: <200007261335.JAA29613@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 09:35 AM 7/26/00 -0400, Keith Moore wrote: > > The difficulty is with imposing a fix for a local problem as a global > > product default. > >except that it's not purely a local problem - the same clients could The context of my statement was not a general discussion about Things Around the Net. We were told of a specific situation that forced the change to the code. That specific situation was local. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Wed Jul 26 15:34:40 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22438 for ; Wed, 26 Jul 2000 15:34:39 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA17167; Wed, 26 Jul 2000 15:34:28 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 15:34:27 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA17149; Wed, 26 Jul 2000 15:34:26 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA17128; Wed, 26 Jul 2000 15:34:25 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 15:34:25 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA06565; Wed, 26 Jul 2000 15:34:24 -0400 (EDT) Message-Id: <200007261934.PAA06565@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Keith Moore , drums@cs.utk.edu Subject: Re: client requests ending \012 In-reply-to: Your message of "Wed, 26 Jul 2000 11:33:38 PDT." <4.3.2.20000726113203.00be3a60@mail.bayarea.net> Date: Wed, 26 Jul 2000 15:34:23 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > We were told of a specific situation that forced the change to the code. > That specific situation was local. perhaps, but the general problem of clients that send bare LF is not. From owner-drums@cs.utk.edu Wed Jul 26 15:41:23 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23952 for ; Wed, 26 Jul 2000 15:41:22 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA17986; Wed, 26 Jul 2000 15:41:05 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 15:41:04 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA17968; Wed, 26 Jul 2000 15:41:03 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA17941; Wed, 26 Jul 2000 15:41:00 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 15:41:01 -0400 Received: from free.88.106.bayarea.net (free.88.106.bayarea.net [205.219.88.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id MAA15166; Wed, 26 Jul 2000 12:40:59 -0700 X-Authentication-Warning: joy.songbird.com: free.88.106.bayarea.net [205.219.88.106] didn't use HELO protocol Message-Id: <4.3.2.20000726123420.00b72db0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 26 Jul 2000 12:36:25 -0700 To: Keith Moore From: Dave Crocker Subject: Re: client requests ending \012 Cc: drums@cs.utk.edu In-Reply-To: <200007261934.PAA06565@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 03:34 PM 7/26/00 -0400, Keith Moore wrote: > > We were told of a specific situation that forced the change to the code. > > That specific situation was local. > >perhaps, but the general problem of clients that send bare LF is not. Well in fact, for the experiences of the particular system that was being discussed, yes it was indeed only local. And we have report that another, widely deployed system, is not seeing bare LFs. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Wed Jul 26 15:44:25 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24744 for ; Wed, 26 Jul 2000 15:44:25 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA18466; Wed, 26 Jul 2000 15:44:08 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 15:44:08 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA18444; Wed, 26 Jul 2000 15:44:07 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA18408; Wed, 26 Jul 2000 15:44:05 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 15:44:05 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id PAA06798; Wed, 26 Jul 2000 15:44:04 -0400 (EDT) Message-Id: <200007261944.PAA06798@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Keith Moore , drums@cs.utk.edu Subject: Re: client requests ending \012 In-reply-to: Your message of "Wed, 26 Jul 2000 12:36:25 PDT." <4.3.2.20000726123420.00b72db0@mail.bayarea.net> Date: Wed, 26 Jul 2000 15:44:04 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > Well in fact, for the experiences of the particular system that was being > discussed, yes it was indeed only local. all experiences of a particular system are "only local". so what? From owner-drums@cs.utk.edu Wed Jul 26 15:56:22 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28986 for ; Wed, 26 Jul 2000 15:56:22 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA20248; Wed, 26 Jul 2000 15:56:10 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 15:56:10 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA20231; Wed, 26 Jul 2000 15:56:09 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA20214; Wed, 26 Jul 2000 15:56:04 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 15:56:04 -0400 Received: from free.88.106.bayarea.net (free.88.106.bayarea.net [205.219.88.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id MAA15404; Wed, 26 Jul 2000 12:56:02 -0700 X-Authentication-Warning: joy.songbird.com: free.88.106.bayarea.net [205.219.88.106] didn't use HELO protocol Message-Id: <4.3.2.20000726124804.00bd6340@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 26 Jul 2000 12:49:43 -0700 To: Keith Moore From: Dave Crocker Subject: Re: client requests ending \012 Cc: Keith Moore , drums@cs.utk.edu In-Reply-To: <200007261944.PAA06798@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 03:44 PM 7/26/00 -0400, Keith Moore wrote: > > Well in fact, for the experiences of the particular system that was being > > discussed, yes it was indeed only local. > >all experiences of a particular system are "only local". so what? very creative misunderstanding. the operational situation that was described was with clients that were within the organization using the MTA. This is in marked contrast to email coming from OUTSIDE (ie, non-local) the organization. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Wed Jul 26 17:22:37 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24953 for ; Wed, 26 Jul 2000 17:22:37 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA28074; Wed, 26 Jul 2000 17:22:16 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 17:22:14 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA28056; Wed, 26 Jul 2000 17:22:14 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA28036; Wed, 26 Jul 2000 17:22:12 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 17:22:12 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA08550; Wed, 26 Jul 2000 17:22:10 -0400 (EDT) Message-Id: <200007262122.RAA08550@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Keith Moore , drums@cs.utk.edu Subject: Re: client requests ending \012 In-reply-to: Your message of "Wed, 26 Jul 2000 12:49:43 PDT." <4.3.2.20000726124804.00bd6340@mail.bayarea.net> Date: Wed, 26 Jul 2000 17:22:10 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > the operational situation that was described was with clients that were > within the organization using the MTA. > > This is in marked contrast to email coming from OUTSIDE (ie, non-local) the > organization. how? SMTP treats both kinds of mail just the same. Keith From owner-drums@cs.utk.edu Wed Jul 26 17:26:04 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26133 for ; Wed, 26 Jul 2000 17:26:03 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA28588; Wed, 26 Jul 2000 17:25:47 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 17:25:46 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA28571; Wed, 26 Jul 2000 17:25:46 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA28554; Wed, 26 Jul 2000 17:25:41 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 17:25:41 -0400 Received: from free.88.106.bayarea.net (free.88.106.bayarea.net [205.219.88.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id OAA16318; Wed, 26 Jul 2000 14:25:37 -0700 X-Authentication-Warning: joy.songbird.com: free.88.106.bayarea.net [205.219.88.106] didn't use HELO protocol Message-Id: <4.3.2.20000726142008.00b951a0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Wed, 26 Jul 2000 14:20:36 -0700 To: Keith Moore From: Dave Crocker Subject: Re: client requests ending \012 Cc: Keith Moore , drums@cs.utk.edu In-Reply-To: <200007262122.RAA08550@astro.cs.utk.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 05:22 PM 7/26/00 -0400, Keith Moore wrote: > > the operational situation that was described was with clients that were > > within the organization using the MTA. > > > > This is in marked contrast to email coming from OUTSIDE (ie, non-local) the > > organization. > >how? SMTP treats both kinds of mail just the same. the administrators of the intranet do not. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Wed Jul 26 17:46:40 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02949 for ; Wed, 26 Jul 2000 17:46:40 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA00945; Wed, 26 Jul 2000 17:46:18 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 17:46:14 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA00928; Wed, 26 Jul 2000 17:46:14 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA00907; Wed, 26 Jul 2000 17:46:12 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 17:46:12 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA09029; Wed, 26 Jul 2000 17:46:11 -0400 (EDT) Message-Id: <200007262146.RAA09029@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Dave Crocker cc: Keith Moore , drums@cs.utk.edu Subject: Re: client requests ending \012 In-reply-to: Your message of "Wed, 26 Jul 2000 14:20:36 PDT." <4.3.2.20000726142008.00b951a0@mail.bayarea.net> Date: Wed, 26 Jul 2000 17:46:11 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > > >how? SMTP treats both kinds of mail just the same. > > the administrators of the intranet do not. I don't see how this is relevant. Keith From owner-drums@cs.utk.edu Wed Jul 26 20:36:46 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04355 for ; Wed, 26 Jul 2000 20:36:46 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA12346; Wed, 26 Jul 2000 20:36:31 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 20:36:29 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA12329; Wed, 26 Jul 2000 20:36:29 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id UAA12315; Wed, 26 Jul 2000 20:36:27 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 20:36:27 -0400 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA06709; Wed, 26 Jul 2000 17:36:09 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA13912; Wed, 26 Jul 2000 17:35:56 -0700 (PDT) Date: Wed, 26 Jul 2000 17:35:22 -0700 From: DRUMS WG Chair To: "Detailed Revision/Update of Message Standards" cc: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Subject: Procedures for Moving Forward Message-ID: <3884949.3173621722@nifty-jr.west.sun.com> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit Since 23 individuals have responded to the WG last call on draft 12 of the SMTP document, it is clear we lack WG rough concensus. This WG is way late, and both John and I are busy people. It is clear that I have done a poor job of tracking issues recently, and I don't have the time to maintain a quality web page on issues the way I used to. So I'm going to introduce some new procedural rules designed to help track issues and speed up progress. Unless you really want this working group to continue for a few more years, follow these rules: (1) Do not post to this list unless one of the following criteria is met: (1a) You are raising a single issue of concern with SMTP draft 12, include specific text for a proposed change, and use a new subject line descriptive of the issue. (1b) You are expressing support for a post of type (1a), and preserve the subject line (with Re: prefix). (1c) The WG Chair has explicitly declared an issue open for debate, and you preserve the subject line (with Re: prefix). (1d) The WG Chair reserves the right to post procedural comments at any time. If you have issue with WG Chair procedures, send email to the WG chair privately. (2) The WG Chair will not declare any issue open unless 4 people express support for it. (3) Posts which reference individuals in any way that could be construed as impolite will be ignored. (As WG Chair, I will point out new issue posts which meet this criteria as time permits). (4) Posts which raise multiple issues will be ignored. (As WG Chair, I will point out new issue posts which meet this criteria as time permits). (5) Non-technical issues are out of scope because we are running too late. You may send minor editoral comments directly to the document editor, and the document editor will apply them at his discretion. - DRUMS WG Chair From owner-drums@cs.utk.edu Wed Jul 26 21:02:07 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07558 for ; Wed, 26 Jul 2000 21:02:07 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA13983; Wed, 26 Jul 2000 21:01:35 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 21:01:34 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA13966; Wed, 26 Jul 2000 21:01:34 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA13953; Wed, 26 Jul 2000 21:01:31 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 21:01:31 -0400 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA13780; Wed, 26 Jul 2000 18:01:29 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA15119; Wed, 26 Jul 2000 18:01:16 -0700 (PDT) Date: Wed, 26 Jul 2000 18:00:48 -0700 From: DRUMS WG Chair To: Matti Aarnio cc: drums@cs.utk.edu Subject: Re: Comments on smtpupd-12 Message-ID: <3976713.3173623248@nifty-jr.west.sun.com> In-Reply-To: <20000720100556Z32074-18330+9@mea.tmt.tele.fi> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit This thread has too many issues, and thus I won't be able to track them and they may get lost. Please send each technical issue in a separate message with a new subject line. Send editorial issues to the document editor with the key word "Editorial" in the subject line. Given how late we are, the document editor will likely ignore all such messages if he gets too many, so please only send extremely simple and non-controversial or very important editorial changes to him. - DRUMS WG Chair From owner-drums@cs.utk.edu Wed Jul 26 21:06:04 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08149 for ; Wed, 26 Jul 2000 21:06:03 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA14459; Wed, 26 Jul 2000 21:05:49 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 21:05:49 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA14442; Wed, 26 Jul 2000 21:05:49 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA14428; Wed, 26 Jul 2000 21:05:47 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 21:05:47 -0400 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA14717; Wed, 26 Jul 2000 18:05:45 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA15315; Wed, 26 Jul 2000 18:05:27 -0700 (PDT) Date: Wed, 26 Jul 2000 18:04:58 -0700 From: DRUMS WG Chair To: "D. J. Bernstein" cc: drums@cs.utk.edu Subject: Re: SMTP WG Last-Call Message-ID: <3991793.3173623498@nifty-jr.west.sun.com> In-Reply-To: <20000720001401.19958.qmail@cr.yp.to> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Thursday, July 20, 2000 0:14 +0000 "D. J. Bernstein" wrote: > My web page http://cr.yp.to/smtp/klensin.html contains many objections > to this draft. A copy of the text appears below. This thread contains too many issues, and many of them are stated in a fashion which could be construed as impolite. If you wish these issues to be tracked, please follow the procedures in my post "Procedures for Moving Forward" if you have not already done so. I apologize for the fact that I have done a poor job of tracking some of the issues you have raised and hope these new procedures will help. Thank you, - DRUMS WG Chair From owner-drums@cs.utk.edu Wed Jul 26 21:08:54 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08503 for ; Wed, 26 Jul 2000 21:08:54 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA14930; Wed, 26 Jul 2000 21:08:43 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 21:08:42 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA14913; Wed, 26 Jul 2000 21:08:41 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA14900; Wed, 26 Jul 2000 21:08:39 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 21:08:40 -0400 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA15378 for ; Wed, 26 Jul 2000 18:08:37 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA15422 for ; Wed, 26 Jul 2000 18:08:27 -0700 (PDT) Date: Wed, 26 Jul 2000 18:07:59 -0700 From: DRUMS WG Chair To: drums@cs.utk.edu Subject: Re: DATA 387 Message-ID: <4002650.3173623679@nifty-jr.west.sun.com> In-Reply-To: <20000720201638.5591.qmail@cr.yp.to> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit This issue will be considered closed unless specific proposed changes to draft 12 of the SMTP document are posted and at least 4 people (including initial poster) support the proposed change. - DRUMS WG Chair From owner-drums@cs.utk.edu Wed Jul 26 22:13:38 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21580 for ; Wed, 26 Jul 2000 22:13:38 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA18522; Wed, 26 Jul 2000 22:13:20 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Wed, 26 Jul 2000 22:13:19 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA18505; Wed, 26 Jul 2000 22:13:19 -0400 (EDT) Received: from serenity.mcc.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA18491; Wed, 26 Jul 2000 22:13:15 -0400 (EDT) Received: from serenity.mcc.ac.uk (130.88.200.93 -> serenity.mcc.ac.uk) by cs.utk.edu (smtpshim v1.0); Wed, 26 Jul 2000 22:13:16 -0400 Received: from nessie.mcc.ac.uk ([130.88.200.20] ident=root) by serenity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 13HdAg-00063x-00 for drums@cs.utk.edu; Thu, 27 Jul 2000 03:13:14 +0100 Received: from clw.cs.man.ac.uk (clerew.man.ac.uk [194.66.22.208]) by nessie.mcc.ac.uk (8.9.3/8.8.8) with ESMTP id DAA89752 for ; Thu, 27 Jul 2000 03:13:12 +0100 (BST) (envelope-from root@clw.cs.man.ac.uk) Received: (from root@localhost) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) id TAA27466 for drums@cs.utk.edu; Wed, 26 Jul 2000 19:31:44 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) with SMTP id TAA27463 for ; Wed, 26 Jul 2000 19:31:43 +0100 (BST) Message-Id: <200007261831.TAA27463@clw.cs.man.ac.uk> Date: Wed, 26 Jul 2000 19:31:43 +0100 (BST) From: Charles Lindsey Reply-To: Charles Lindsey Subject: Re: client requests ending \012 To: drums@cs.utk.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: JnG/PKk8/3v4GrC2utGDVg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc List-Unsubscribe: On Wed, 26 Jul 2000 13:08:56 -0400 Keith Moore said... > > > Naked LF should not be found in a conforming message > > naked LF is valid in RFC 822. > (though it's highly likely to be converted to CRLF by some MTA) > Ah! But I see that it is not allowed in MESSFOR. But presumably MTAs will need to cope with stuff that conformed to the old standard for some considerable time. FWIW, it will not be allowed in the new USEFOR. Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-drums@cs.utk.edu Thu Jul 27 01:03:31 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20366 for ; Thu, 27 Jul 2000 01:03:30 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id BAA28578; Thu, 27 Jul 2000 01:03:11 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 01:03:09 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id BAA28561; Thu, 27 Jul 2000 01:03:09 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id BAA28548; Thu, 27 Jul 2000 01:03:07 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 01:03:07 -0400 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA25067 for ; Wed, 26 Jul 2000 22:03:05 -0700 (PDT) Received: from [192.129.100.100] (dsl198-113.Eng.Sun.COM [129.146.198.113]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA22339 for ; Wed, 26 Jul 2000 22:02:20 -0700 (PDT) Date: Wed, 26 Jul 2000 22:01:45 -0700 From: DRUMS WG Chair To: drums@cs.utk.edu Subject: Re: client requests ending \012 Message-ID: <4127989.3173637705@[192.129.100.100]> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit This debate closed on the grounds it is a rathole. There appears to be some dissatisfaction with the text in draft 12 on this topic, so parties interested in changing that text should follow the procedures documented in the message "Procedures for Moving Forward". In addition, this WG clearly lacks rough concensus on the phrase "be liberal in what you accept", and thus that phrase will not be treated as an axiom. - DRUMS WG Chair From owner-drums@cs.utk.edu Thu Jul 27 01:10:17 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23580 for ; Thu, 27 Jul 2000 01:10:16 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id BAA29144; Thu, 27 Jul 2000 01:10:04 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 01:10:03 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id BAA29122; Thu, 27 Jul 2000 01:10:03 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id BAA29097; Thu, 27 Jul 2000 01:09:59 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 01:09:59 -0400 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA26166 for ; Wed, 26 Jul 2000 22:09:58 -0700 (PDT) Received: from [192.129.100.100] (dsl198-113.Eng.Sun.COM [129.146.198.113]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA22440 for ; Wed, 26 Jul 2000 22:09:06 -0700 (PDT) Date: Wed, 26 Jul 2000 22:08:31 -0700 From: DRUMS WG Chair To: drums@cs.utk.edu Subject: Re: A quick reminder about SHOULD Message-ID: <4152437.3173638111@[192.129.100.100]> In-Reply-To: <20000723061713.13164.qmail@cr.yp.to> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit This subject will be disregarded on the grounds that it makes references to a person in a manner which could be considered impolite. If there is a proposed change to the text in draft 12 behind this, make that proposal politely under a new subject and we'll see if there's enough support to reconsider the issue. - DRUMS WG Chair --On Sunday, July 23, 2000 6:17 +0000 "D. J. Bernstein" wrote: > Please remember that the word ``SHOULD'' has a specific definition in > Klensin's document. It's much stronger than the RFC 1123 ``SHOULD,'' > never mind the English word ``should.'' > > When RFC 1123 says that every SMTP server ``SHOULD implement EXPN,'' for > example, here's what it's saying: > > There may exist valid reasons in particular circumstances to not > implement EXPN, but the full implications should be understood and > the case carefully weighed. > > In contrast, when Klensin says that every SMTP server ``SHOULD support > EXPN,'' here's what he's saying: > > An SMTP server that doesn't support EXPN may interoperate properly, > but this will typically be the case only if great care is taken. > Consequently, the requirement to support EXPN should be violated only > under exceptional and well-understood circumstances. > > That's certainly not what RFC 1123 says. RFC 1123 is merely giving some > bad advice; Klensin is making a patently ridiculous claim about > interoperability. > > You might think at first glance that Klensin's ``SHOULD support EXPN'' > is the same as RFC 1123's ``SHOULD implement EXPN.'' Don't be fooled! > Klensin made a big change in the definition of ``SHOULD.'' > > Can we all agree that the spec should recommend against supporting EXPN? > Perhaps we can't. But the default position, in the absence of consensus, > is what RFC 1123 said, _not_ what Klensin wants to say. > > ---Dan From owner-drums@cs.utk.edu Thu Jul 27 09:34:20 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24727 for ; Thu, 27 Jul 2000 09:34:19 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA24078; Thu, 27 Jul 2000 09:34:03 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 09:33:57 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA24056; Thu, 27 Jul 2000 09:33:57 -0400 (EDT) Received: from web2306.mail.yahoo.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA24019; Thu, 27 Jul 2000 09:33:49 -0400 (EDT) Received: from web2306.mail.yahoo.com (128.11.68.151 -> web2306.mail.yahoo.com) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 09:33:49 -0400 Message-ID: <20000727133348.3618.qmail@web2306.mail.yahoo.com> Received: from [171.78.52.182] by web2306.mail.yahoo.com; Thu, 27 Jul 2000 06:33:48 PDT Date: Thu, 27 Jul 2000 06:33:48 -0700 (PDT) From: Arthur Gallun Reply-To: gallun@iname.com Subject: unsubscribe To: drums@cs.utk.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: unsubscribe __________________________________________________ Do You Yahoo!? Get Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ From owner-drums@cs.utk.edu Thu Jul 27 11:15:27 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14556 for ; Thu, 27 Jul 2000 11:15:26 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA04656; Thu, 27 Jul 2000 11:15:07 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 11:15:05 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA04631; Thu, 27 Jul 2000 11:15:04 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA04605; Thu, 27 Jul 2000 11:15:03 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 11:15:03 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id LAA17836; Thu, 27 Jul 2000 11:15:02 -0400 (EDT) Message-Id: <200007271515.LAA17836@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: drums@cs.utk.edu Subject: suggested revision for MUST/SHOULD cc: moore@cs.utk.edu From: Keith Moore Date: Thu, 27 Jul 2000 11:15:02 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: this is a very slight rewording; were it not for the controversy surrounding the subject I would have submitted it to the author as an editorial change. however I do think a slight bit of tweaking is worthwhile here. > The terms "MUST" and "SHOULD" (and "MUST NOT" and "SHOULD NOT") are > used in the same general sense here as in the Host Requirements > Standards [RFC-1123]. Specifically, "MUST" or "MUST NOT" identify > absolute requirements for conformance to this specification. > Implementations that do not conform to them lie outside the scope of > this specification. Implementations that are fully conforming also > adhere to all "SHOULD" and "SHOULD NOT" requirements. Implementations > that adhere to all "MUST" ("MUST NOT") but not to all of these are > considered to be partially conforming. ( separate the definitions of "fully" and "partially" conforming from the text that explains when MUST/SHOULD/etc are used, so that the latter is clearly distinguished. ) > "MUST" and "MUST NOT" are generally used when the requirement is > necessary to ensure robust interoperation between conforming > implementations. "SHOULD" and "SHOULD NOT" are also used to > describe cases where the requirement is necessary for robust > interoperation between (fully or partially) conforming > implementations, but when it is recognized that there may be > valid reasons for a particular implementation (or a particular > type of implementation) to not follow the requirement. > An implementation should violate "SHOULD" or "SHOULD NOT" > requirements only under exceptional circumstances, and when great > care has been taken to understand the implications of that choice. 1. suggested text is even more careful to say 'conforming' implementations. nowhere does it say anything about interoperation between noncomforing implementations, or between a conforming implementation and a noncomforming one. so for instance "MUST reject bare LF" does not interfere with interoperability between conforming implementations. 2. says that MUST/SHOULD are "generally" used when needed for interoperation...to allow room for other good reasons to use them. 3. slight rewording of when to violate SHOULD > In some cases this document imposes "MUST" and/or "SHOULD" > requirements which deviate from a significant body of current practice > at the time of this writing. In such cases these requirements are > imposed when experience indicates that following such requirements > is likely to lead, in practice, to better interoperation, or > smoother operation of the Internet email infrastructure. Though > this document does attempt to ensure that (fully or partially) > implementations of this specification will interoperate with > (fully or partially) conforming implementations of its predecessors, > it does not attempt to legitimize common deviations from those > specifications, and it does impose new requirements. Existing > implementations of SMTP will need some changes if they are to > conform to this new specification. separate paragraph to explain use of MUST/SHOULD which deviates from current practice (since this seems to be a common source of confusion). the stuff about "not legitimizing common deviations" and "we didn't try to write the spec so that existing implementations would automatically be conforming" might be a bit over the top, or it might be better placed elsewhere, but again, it does seem to be a common source of confusion. > Statements using "MAY" describe features or styles of doing things that > may be followed, or not, at the discretion of the implementation, > normally without causing significant interoperability problems. Keith From owner-drums@cs.utk.edu Thu Jul 27 11:55:18 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23478 for ; Thu, 27 Jul 2000 11:55:18 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA08934; Thu, 27 Jul 2000 11:55:06 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 11:55:06 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA08916; Thu, 27 Jul 2000 11:55:05 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA08899; Thu, 27 Jul 2000 11:55:03 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 11:55:03 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id LAA18743; Thu, 27 Jul 2000 11:54:55 -0400 (EDT) Message-Id: <200007271554.LAA18743@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: gallun@iname.com cc: drums@cs.utk.edu Subject: Re: unsubscribe In-reply-to: Your message of "Thu, 27 Jul 2000 06:33:48 PDT." <20000727133348.3618.qmail@web2306.mail.yahoo.com> X-SUBJECT-MSG-FROM: Arthur Gallun Date: Thu, 27 Jul 2000 11:54:55 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: I don't find your name on the drums mail list - perhaps you are subscribed using a different address? From owner-drums@cs.utk.edu Thu Jul 27 15:17:48 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04578 for ; Thu, 27 Jul 2000 15:17:43 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA25962; Thu, 27 Jul 2000 15:17:00 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 15:16:57 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA25945; Thu, 27 Jul 2000 15:16:57 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id PAA25932; Thu, 27 Jul 2000 15:16:55 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 15:16:55 -0400 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24136 for ; Thu, 27 Jul 2000 12:16:53 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA03704 for ; Thu, 27 Jul 2000 12:16:51 -0700 (PDT) Date: Thu, 27 Jul 2000 12:16:16 -0700 From: DRUMS WG Chair To: drums@cs.utk.edu Subject: Re: HELO procedural notes Message-ID: <5667759.3173688976@nifty-jr.west.sun.com> In-Reply-To: <20000723191750.28598.qmail@cr.yp.to> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Sunday, July 23, 2000 19:17 +0000 "D. J. Bernstein" wrote: > ... > In fact, according to Leiba's notes of the August 1998 meeting, > ... > > Consensus is that "SHOULD use EHLO" be dropped, and a client that > doesn't need extensions may use EHLO or HELO at the client's > discretion. > > That's consistent with discussions of the issue on the mailing list. > > So why does smtpupd-12 still say ``SHOULD preferentially utilize EHLO''? > ... Section 3.2 of smtpupd-09 (and later) complies with WG rough concensus from that meeting, including the goal of encouraging use of EHLO. The editor's comments on this issue are in section X.1.9(iv). I searched my archives for messages with "HELO" in the subject line. According to such messages, one person has objected to this text on at least two occasions. In all cases there was no support expressed for the objection. The chair concludes there is rough concensus that the current text is adequate for RFC publication and the issue is permanently closed. - DRUMS WG Chair From owner-drums@cs.utk.edu Thu Jul 27 15:46:26 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14152 for ; Thu, 27 Jul 2000 15:46:25 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA28867; Thu, 27 Jul 2000 15:46:08 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 15:46:08 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id PAA28833; Thu, 27 Jul 2000 15:46:07 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id PAA28800; Thu, 27 Jul 2000 15:45:59 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 15:45:59 -0400 Received: (qmail 32179 invoked by uid 1001); 27 Jul 2000 19:42:55 -0000 Date: 27 Jul 2000 19:42:55 -0000 Message-ID: <20000727194255.29561.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: client requests ending \012 References: <4127989.3173637705@[192.129.100.100]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Chris Newman writes: > This debate closed on the grounds it is a rathole. No, it isn't. The situation here is very simple: * This requirement on servers does not appear in the base documents. * Most SMTP servers on the Internet do not obey the requirement. * There is obviously not consensus to add the requirement. The requirement must be removed from smtpupd. You have no choice. If you think you can close the debate and keep the requirement, you're wrong. ---Dan From owner-drums@cs.utk.edu Thu Jul 27 16:14:18 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21842 for ; Thu, 27 Jul 2000 16:14:17 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA01616; Thu, 27 Jul 2000 16:13:58 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 16:13:56 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA01598; Thu, 27 Jul 2000 16:13:56 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA01585; Thu, 27 Jul 2000 16:13:53 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 16:13:53 -0400 Received: (qmail 20076 invoked by uid 1001); 27 Jul 2000 20:14:15 -0000 Date: 27 Jul 2000 20:14:15 -0000 Message-ID: <20000727201415.6819.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: HELO procedural notes References: <20000723191750.28598.qmail@cr.yp.to> <5667759.3173688976@nifty-jr.west.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Section 2.2.1 says ``clients SHOULD preferentially utilize EHLO rather than HELO,'' which is in blatant violation of the decision I quoted from Leiba's meeting notes. ---Dan From owner-drums@cs.utk.edu Thu Jul 27 16:26:46 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25163 for ; Thu, 27 Jul 2000 16:26:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA02872; Thu, 27 Jul 2000 16:26:33 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 16:26:32 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA02855; Thu, 27 Jul 2000 16:26:32 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA02835; Thu, 27 Jul 2000 16:26:27 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 16:26:27 -0400 Received: (qmail 18862 invoked by uid 1001); 27 Jul 2000 20:26:48 -0000 Date: 27 Jul 2000 20:26:48 -0000 Message-ID: <20000727202648.17171.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: HELO procedural notes References: <20000723191750.28598.qmail@cr.yp.to> <5667759.3173688976@nifty-jr.west.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Chris Newman writes: > Section 3.2 of smtpupd-09 (and later) complies with WG rough concensus from > that meeting, including the goal of encouraging use of EHLO. Reader beware! Newman is trying to mislead you. He's perfectly aware that section 2.2.1 is in blatant violation of the meeting consensus, but he doesn't want to admit it, so he ignores section 2.2.1 and talks about section 3.2. ---Dan From owner-drums@cs.utk.edu Thu Jul 27 16:39:03 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28659 for ; Thu, 27 Jul 2000 16:39:02 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA04863; Thu, 27 Jul 2000 16:38:46 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 16:38:45 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA04845; Thu, 27 Jul 2000 16:38:44 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA04831; Thu, 27 Jul 2000 16:38:42 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 16:38:42 -0400 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA07941 for ; Thu, 27 Jul 2000 13:38:40 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA09953 for ; Thu, 27 Jul 2000 13:38:35 -0700 (PDT) Date: Thu, 27 Jul 2000 13:38:03 -0700 From: DRUMS WG Chair To: drums@cs.utk.edu Subject: Re: suggested revision for MUST/SHOULD Message-ID: <5962888.3173693883@nifty-jr.west.sun.com> In-Reply-To: <200007271515.LAA17836@astro.cs.utk.edu> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit If you support Keith's proposed wording change, please speak up now. If three people (in addition to Keith) express support, the issue will be open for objections and debate. Otherwise we will keep the current wording in draft 12. - DRUMS WG Chair --On Thursday, July 27, 2000 11:15 -0400 Keith Moore wrote: > this is a very slight rewording; were it not for the controversy > surrounding the subject I would have submitted it to the author > as an editorial change. however I do think a slight bit of > tweaking is worthwhile here. > >> The terms "MUST" and "SHOULD" (and "MUST NOT" and "SHOULD NOT") are >> used in the same general sense here as in the Host Requirements >> Standards [RFC-1123]. Specifically, "MUST" or "MUST NOT" identify >> absolute requirements for conformance to this specification. >> Implementations that do not conform to them lie outside the scope of >> this specification. Implementations that are fully conforming also >> adhere to all "SHOULD" and "SHOULD NOT" requirements. Implementations >> that adhere to all "MUST" ("MUST NOT") but not to all of these are >> considered to be partially conforming. > > ( separate the definitions of "fully" and "partially" conforming > from the text that explains when MUST/SHOULD/etc are used, so that > the latter is clearly distinguished. ) > >> "MUST" and "MUST NOT" are generally used when the requirement is >> necessary to ensure robust interoperation between conforming >> implementations. "SHOULD" and "SHOULD NOT" are also used to >> describe cases where the requirement is necessary for robust >> interoperation between (fully or partially) conforming >> implementations, but when it is recognized that there may be >> valid reasons for a particular implementation (or a particular >> type of implementation) to not follow the requirement. >> An implementation should violate "SHOULD" or "SHOULD NOT" >> requirements only under exceptional circumstances, and when great >> care has been taken to understand the implications of that choice. > > 1. suggested text is even more careful to say 'conforming' > implementations. nowhere does it say anything about interoperation > between noncomforing implementations, or between a conforming > implementation and a noncomforming one. so for instance "MUST reject > bare LF" does not interfere with interoperability between conforming > implementations. > > 2. says that MUST/SHOULD are "generally" used when needed for > interoperation...to allow room for other good reasons to use them. > > 3. slight rewording of when to violate SHOULD > >> In some cases this document imposes "MUST" and/or "SHOULD" >> requirements which deviate from a significant body of current practice >> at the time of this writing. In such cases these requirements are >> imposed when experience indicates that following such requirements >> is likely to lead, in practice, to better interoperation, or >> smoother operation of the Internet email infrastructure. Though >> this document does attempt to ensure that (fully or partially) >> implementations of this specification will interoperate with >> (fully or partially) conforming implementations of its predecessors, >> it does not attempt to legitimize common deviations from those >> specifications, and it does impose new requirements. Existing >> implementations of SMTP will need some changes if they are to >> conform to this new specification. > > separate paragraph to explain use of MUST/SHOULD which deviates > from current practice (since this seems to be a common source of > confusion). the stuff about "not legitimizing common deviations" > and "we didn't try to write the spec so that existing implementations > would automatically be conforming" might be a bit over the top, or > it might be better placed elsewhere, but again, it does seem to be > a common source of confusion. > >> Statements using "MAY" describe features or styles of doing things that >> may be followed, or not, at the discretion of the implementation, >> normally without causing significant interoperability problems. > > Keith > From owner-drums@cs.utk.edu Thu Jul 27 16:46:37 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00610 for ; Thu, 27 Jul 2000 16:46:36 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA06782; Thu, 27 Jul 2000 16:46:16 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 16:46:15 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA06765; Thu, 27 Jul 2000 16:46:15 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA06749; Thu, 27 Jul 2000 16:46:13 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 16:46:13 -0400 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA14703 for ; Thu, 27 Jul 2000 13:46:11 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA10885 for ; Thu, 27 Jul 2000 13:46:04 -0700 (PDT) Date: Thu, 27 Jul 2000 13:45:33 -0700 From: DRUMS WG Chair To: "Detailed Revision/Update of Message Standards" Subject: Re: Procedures for Moving Forward Message-ID: <5989945.3173694333@nifty-jr.west.sun.com> In-Reply-To: <3884949.3173621722@nifty-jr.west.sun.com> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Wednesday, July 26, 2000 17:35 -0700 DRUMS WG Chair wrote: > (1) Do not post to this list unless one of the following criteria is met: > > (1a) You are raising a single issue of concern with SMTP draft 12, > include specific text for a proposed change, and use a new subject line > descriptive of the issue. > > (1b) You are expressing support for a post of type (1a), and preserve the > subject line (with Re: prefix). > > (1c) The WG Chair has explicitly declared an issue open for debate, and > you preserve the subject line (with Re: prefix). > > (1d) The WG Chair reserves the right to post procedural comments at any > time. If you have issue with WG Chair procedures, send email to the WG > chair privately. Posts which violate these rules (I count three so far) will result in a private warning from the Chair and will otherwise be ignored. - DRUMS WG Chair From owner-drums@cs.utk.edu Thu Jul 27 17:06:10 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04994 for ; Thu, 27 Jul 2000 17:06:10 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA09095; Thu, 27 Jul 2000 17:05:56 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 17:05:56 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA09076; Thu, 27 Jul 2000 17:05:55 -0400 (EDT) Received: from candle.brasslantern.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA09063; Thu, 27 Jul 2000 17:05:52 -0400 (EDT) Received: from candle.brasslantern.com (206.184.69.215 -> dynamic215.as32.snfcca01.pacific.verio.net) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 17:05:53 -0400 Received: (from schaefer@localhost) by candle.brasslantern.com (8.9.2/8.9.2) id OAA08865 for drums@cs.utk.edu; Thu, 27 Jul 2000 14:05:48 -0700 (PDT) From: "Bart Schaefer" Message-Id: <000727140546.ZM8864@candle.brasslantern.com> Date: Thu, 27 Jul 2000 14:05:46 -0700 In-Reply-To: <5962888.3173693883@nifty-jr.west.sun.com> Comments: In reply to DRUMS WG Chair "Re: suggested revision for MUST/SHOULD" (Jul 27, 1:38pm) References: <5962888.3173693883@nifty-jr.west.sun.com> X-Mailer: Z-Mail Lite (5.0.0 30July97) To: drums@cs.utk.edu Subject: Re: suggested revision for MUST/SHOULD MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: On Jul 27, 1:38pm, DRUMS WG Chair wrote: > Subject: Re: suggested revision for MUST/SHOULD > If you support Keith's proposed wording change, please speak up now. I support this change. From owner-drums@cs.utk.edu Thu Jul 27 17:13:34 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06605 for ; Thu, 27 Jul 2000 17:13:33 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA09940; Thu, 27 Jul 2000 17:13:21 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 17:13:21 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA09923; Thu, 27 Jul 2000 17:13:20 -0400 (EDT) Received: from ss3000e.cselt.it (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA09909; Thu, 27 Jul 2000 17:13:17 -0400 (EDT) Received: from ss3000e.cselt.it (163.162.41.5 -> ss3000e.cselt.it) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 17:13:17 -0400 Received: from beatles.cselt.it (beatles.cselt.it [163.162.29.125]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0FYD00K69JZTZ8@ss3000e.cselt.it> for drums@cs.utk.edu; Thu, 27 Jul 2000 23:07:05 +0200 (MET DST) Received: (from mau@localhost) by beatles.cselt.it (8.9.3/8.9.3) id XAA17405 for drums@cs.utk.edu; Thu, 27 Jul 2000 23:12:10 +0200 (MET DST) Date: Thu, 27 Jul 2000 23:12:10 +0200 (MET DST) From: Maurizio Codogno Subject: Re: suggested revision for MUST/SHOULD To: drums@cs.utk.edu Message-id: <200007272112.XAA17405@beatles.cselt.it> List-Unsubscribe: > If you support Keith's proposed wording change, please speak up now. I support it. ciao, .mau. From owner-drums@cs.utk.edu Thu Jul 27 17:18:47 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07711 for ; Thu, 27 Jul 2000 17:18:46 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA10631; Thu, 27 Jul 2000 17:18:27 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 17:18:26 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA10612; Thu, 27 Jul 2000 17:18:25 -0400 (EDT) Received: from prognet.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA10598; Thu, 27 Jul 2000 17:18:19 -0400 (EDT) Received: from prognet.com (205.219.198.1 -> prognet.com) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 17:18:19 -0400 Received: from mscharff.real.com ([172.22.104.48]) by prognet.com (8.9.2/8.9.0) with ESMTP id OAA13648; Thu, 27 Jul 2000 14:18:26 -0700 (PDT) Message-Id: <4.3.2.7.2.20000727141924.00aede70@mail.real.com> X-Sender: mscharff@mail.real.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jul 2000 14:19:34 +0100 To: DRUMS WG Chair , drums@cs.utk.edu From: Michael Scharff Subject: Re: suggested revision for MUST/SHOULD In-Reply-To: <5962888.3173693883@nifty-jr.west.sun.com> References: <200007271515.LAA17836@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: I too will support this change. From owner-drums@cs.utk.edu Thu Jul 27 17:19:51 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07938 for ; Thu, 27 Jul 2000 17:19:50 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA10801; Thu, 27 Jul 2000 17:19:36 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 17:19:36 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA10784; Thu, 27 Jul 2000 17:19:35 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA10770; Thu, 27 Jul 2000 17:19:34 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 17:19:34 -0400 Received: (qmail 30312 invoked by uid 1001); 27 Jul 2000 21:19:55 -0000 Date: 27 Jul 2000 21:19:55 -0000 Message-ID: <20000727211955.9658.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: HELO procedural notes References: <20000723191750.28598.qmail@cr.yp.to> <5667759.3173688976@nifty-jr.west.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Some juicy historical details in this message---including an admission from the document editor that the continued presence of this text is an ``error'' on his part! We have consensus against this text. But Crocker says that there's consensus for the text. Newman agrees and says that the issue is permanently closed. _They_ are the people interfering with DRUMS. Chris Newman writes: > I searched my archives for messages with "HELO" in the subject line. Those are not the only relevant messages. If you don't like the time it takes to do a full-text search, blame yourself (and Klensin, of course) for not keeping track of DRUMS discussions. > According to such messages, one person has objected to this text on at > least two occasions. In all cases there was no support expressed for the > objection. There have been public objections from Philip Hazel (28 July 1998), Robert Elz (5 August 1998), John Myers (6 August 1998), and of course me---not to mention the decision at the in-person meeting, and the fact that some widespread clients deliberately start with HELO. Furthermore, on 30 January 1999, after I pointed out that the problem still hadn't been fixed, Klensin asked me for a list of places where the EHLO preferences should be toned down as indicated by the minutes .... If I can get a precise list ... they will be fixed; any omissions are errors, not intentional. ... I will try to fix things according to principles if that is all I get, but I do make mistakes. I took Klensin at his word, and sent a message to DRUMS explaining in detail exactly what changes had to be made. How many people here have ever expressed _support_ for the notion that clients should be forced to use EHLO? Why was it ever added to the document in the first place? > The chair concludes there is rough concensus that the current > text is adequate for RFC publication and the issue is permanently closed. Try again, Chris. ---Dan From owner-drums@cs.utk.edu Thu Jul 27 17:53:28 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15484 for ; Thu, 27 Jul 2000 17:53:27 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA14335; Thu, 27 Jul 2000 17:53:00 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 17:52:56 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA14310; Thu, 27 Jul 2000 17:52:56 -0400 (EDT) Received: from candle.brasslantern.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA14297; Thu, 27 Jul 2000 17:52:52 -0400 (EDT) Received: from candle.brasslantern.com (206.184.69.215 -> dynamic215.as32.snfcca01.pacific.verio.net) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 17:52:53 -0400 Received: (from schaefer@localhost) by candle.brasslantern.com (8.9.2/8.9.2) id OAA08887 for drums@cs.utk.edu; Thu, 27 Jul 2000 14:52:50 -0700 (PDT) From: "Bart Schaefer" Message-Id: <000727145248.ZM8886@candle.brasslantern.com> Date: Thu, 27 Jul 2000 14:52:48 -0700 In-Reply-To: <3884949.3173621722@nifty-jr.west.sun.com> Comments: In reply to DRUMS WG Chair "Procedures for Moving Forward" (Jul 26, 5:35pm) References: <3884949.3173621722@nifty-jr.west.sun.com> X-Mailer: Z-Mail Lite (5.0.0 30July97) To: drums@cs.utk.edu Subject: Conflict between X.1.9(iv) and literal interpretation of draft-12 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Keith's new text for section 2.3 makes it clear that implementations that do not follow SHOULD requirements are only partially conforming. Section 2.3 further states that MAY indicates cases where interoperability is not harmed by a given behavior. The text in 2.2.1 makes EHLO a SHOULD requirement. The text in 3.2 says clients MAY use HELO. The justification in X.1.9(iv) indicates that 3.2 permits HELO clients to be considered fully conforming. This does not follow from a literal interpretation of the above-noted three sections, either in draft 12 or as reworded by Keith. Suggested change: Expand the definition of MAY in 2.3 as follows: > Statements using "MAY" describe features or styles of doing things > that may be followed, or not, at the discretion of the implementation, > normally without causing significant interoperability problems. Such > statements reflect a relaxation of the conformance requirements for > "SHOULD": in any instance of conflict, an implementation exercising > discretion as explicitly permitted by "MAY" is still considered fully > conforming. This suggested change appears to reflect the spirit in which "MAY" has been employed, at least in this instance. From owner-drums@cs.utk.edu Thu Jul 27 18:22:02 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22014 for ; Thu, 27 Jul 2000 18:22:01 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA16570; Thu, 27 Jul 2000 18:21:50 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 18:21:49 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA16553; Thu, 27 Jul 2000 18:21:49 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id SAA16539; Thu, 27 Jul 2000 18:21:47 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 18:21:47 -0400 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA03828 for ; Thu, 27 Jul 2000 15:21:45 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA19843 for ; Thu, 27 Jul 2000 15:21:40 -0700 (PDT) Date: Thu, 27 Jul 2000 15:21:00 -0700 From: DRUMS WG Chair To: drums@cs.utk.edu Subject: Re: suggested revision for MUST/SHOULD Message-ID: <6334158.3173700060@nifty-jr.west.sun.com> In-Reply-To: <200007271515.LAA17836@astro.cs.utk.edu> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit The proposed replacement text on this topic has sufficient support to be considered. If you object to the proposed replacement text to the extent that you want to prolong this working group, please reply to this thread with the following information: (1) A description of the technical basis for your objection. (2) State whether or not you prefer the proposed replacement text to the text in draft 12. (3) Include alternative replacement text if you find both options unacceptable to the extent that you wish to prolong the working group. Debate about the technical basis for any proposed replacement text is also appropriate at this time, but please be concise. If there are no objections to the proposed replacement text, I will direct the document editor to include it in draft 13. - DRUMS WG Chair From owner-drums@cs.utk.edu Thu Jul 27 18:53:47 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28274 for ; Thu, 27 Jul 2000 18:53:47 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA19626; Thu, 27 Jul 2000 18:53:29 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 18:53:27 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id SAA19609; Thu, 27 Jul 2000 18:53:27 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id SAA19596; Thu, 27 Jul 2000 18:53:26 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 18:53:26 -0400 Received: (qmail 14524 invoked by uid 1001); 27 Jul 2000 22:53:47 -0000 Date: 27 Jul 2000 22:53:47 -0000 Message-ID: <20000727225347.4260.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: suggested revision for MUST/SHOULD References: <200007271515.LAA17836@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: I agree that this needs discussion. However, I have a different suggestion: the definitions of ``SHOULD'' et al. should simply be copied from RFC 2119, with no extra text. (I say ``copied'' rather than ``incorporated by reference'' to avoid the issue of whether smtpupd is obliged to follow RFC 2119, section 6.) Most readers will be expecting the RFC 2119 definitions. Many readers will misinterpret the document if it uses anything else---they'll never realize that there are new definitions. I've checked a bunch of ``SHOULD''s in the document, and they all seem to predate the new definitions, which appeared in smtpupd-09. Presumably they were written with the RFC 2119 (or almost identical RFC 1123) definitions in mind. The new definitions seem to have screwed up the meaning of these ``SHOULD''s. ---Dan From owner-drums@cs.utk.edu Thu Jul 27 19:16:19 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00857 for ; Thu, 27 Jul 2000 19:16:14 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA21881; Thu, 27 Jul 2000 19:16:01 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 19:16:00 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA21864; Thu, 27 Jul 2000 19:16:00 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA21848; Thu, 27 Jul 2000 19:15:58 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 19:15:58 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id TAA26238; Thu, 27 Jul 2000 19:15:56 -0400 (EDT) Message-Id: <200007272315.TAA26238@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bart Schaefer" cc: drums@cs.utk.edu Subject: Re: Conflict between X.1.9(iv) and literal interpretation of draft-12 In-reply-to: Your message of "Thu, 27 Jul 2000 14:52:48 PDT." <000727145248.ZM8886@candle.brasslantern.com> Date: Thu, 27 Jul 2000 19:15:56 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: I'd be fine with Bart's proposed change to the MAY language. -Keith From owner-drums@cs.utk.edu Thu Jul 27 19:18:21 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01106 for ; Thu, 27 Jul 2000 19:18:20 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA22264; Thu, 27 Jul 2000 19:18:09 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 19:18:08 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA22242; Thu, 27 Jul 2000 19:18:08 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA22209; Thu, 27 Jul 2000 19:18:06 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> koobera.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 19:18:06 -0400 Received: (qmail 17115 invoked by uid 1001); 27 Jul 2000 23:18:28 -0000 Date: 27 Jul 2000 23:18:28 -0000 Message-ID: <20000727231828.21319.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Subject: Re: Procedures for Moving Forward References: <3884949.3173621722@nifty-jr.west.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: There are many problems with Newman's procedures. For example: * Newman condones unauthorized changes by the document editor. * Newman fails to recognize previously stated objections and previous suggestions of revisions to the text. Those of us who disagree with the document editor have been forced to speak up again and again and again. * Newman prohibits messages discussing more than one issue. There's no harm in trying---I tried this after smtpupd-09---but sometimes two issues really should be discussed together. * Newman has a ridiculously broad prohibition on messages ``that could be construed as impolite.'' This is selectively enforced against messages whose content Newman doesn't like. * Newman prohibits everything other than objections to smtpupd. In particular, procedural objections such as this one aren't allowed. We'd be done a hell of a lot faster if we simply settled the issues, rather than spending all this time on bogus meta-discussions. ---Dan From owner-drums@cs.utk.edu Thu Jul 27 19:19:32 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01245 for ; Thu, 27 Jul 2000 19:19:32 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA22400; Thu, 27 Jul 2000 19:19:16 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 19:19:15 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA22382; Thu, 27 Jul 2000 19:19:14 -0400 (EDT) Received: from snark.thyrsus.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA22368; Thu, 27 Jul 2000 19:19:11 -0400 (EDT) Received: from snark.thyrsus.com (207.106.50.26 -> snark.tuxedo.org) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 19:19:11 -0400 Received: (from esr@localhost) by snark.thyrsus.com (8.9.3/8.9.3) id TAA10972; Thu, 27 Jul 2000 19:29:54 -0400 Date: Thu, 27 Jul 2000 19:29:54 -0400 From: "Eric S. Raymond" To: "D. J. Bernstein" Cc: drums@cs.utk.edu Subject: Re: suggested revision for MUST/SHOULD Message-ID: <20000727192954.A10964@thyrsus.com> Reply-To: esr@thyrsus.com References: <200007271515.LAA17836@astro.cs.utk.edu> <20000727225347.4260.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000727225347.4260.qmail@cr.yp.to>; from djb@cr.yp.to on Thu, Jul 27, 2000 at 10:53:47PM -0000 Organization: Eric Conspiracy Secret Labs X-Eric-Conspiracy: There is no conspiracy List-Unsubscribe: D. J. Bernstein : > I agree that this needs discussion. > > However, I have a different suggestion: the definitions of ``SHOULD'' et > al. should simply be copied from RFC 2119, with no extra text. > > (I say ``copied'' rather than ``incorporated by reference'' to avoid the > issue of whether smtpupd is obliged to follow RFC 2119, section 6.) > > Most readers will be expecting the RFC 2119 definitions. Many readers > will misinterpret the document if it uses anything else---they'll never > realize that there are new definitions. > > I've checked a bunch of ``SHOULD''s in the document, and they all seem > to predate the new definitions, which appeared in smtpupd-09. Presumably > they were written with the RFC 2119 (or almost identical RFC 1123) > definitions in mind. The new definitions seem to have screwed up the > meaning of these ``SHOULD''s. > > ---Dan I think this is a good suggestion. -- Eric S. Raymond No matter how one approaches the figures, one is forced to the rather startling conclusion that the use of firearms in crime was very much less when there were no controls of any sort and when anyone, convicted criminal or lunatic, could buy any type of firearm without restriction. Half a century of strict controls on pistols has ended, perversely, with a far greater use of this weapon in crime than ever before. -- Colin Greenwood, in the study "Firearms Control", 1972 From owner-drums@cs.utk.edu Thu Jul 27 21:21:36 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14888 for ; Thu, 27 Jul 2000 21:21:36 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id VAA00365; Thu, 27 Jul 2000 21:21:15 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 21:21:12 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id VAA00348; Thu, 27 Jul 2000 21:21:11 -0400 (EDT) Received: from ns.secondary.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id VAA00335; Thu, 27 Jul 2000 21:21:09 -0400 (EDT) Received: from ns.secondary.com (208.184.76.39 -> ns.secondary.com) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 21:21:09 -0400 Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA25308 for ; Thu, 27 Jul 2000 18:17:53 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <20000727192954.A10964@thyrsus.com> References: <200007271515.LAA17836@astro.cs.utk.edu> <20000727225347.4260.qmail@cr.yp.to> <20000727192954.A10964@thyrsus.com> Date: Thu, 27 Jul 2000 18:21:06 -0700 To: drums@cs.utk.edu From: Paul Hoffman / IMC Subject: Re: suggested revision for MUST/SHOULD Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: At 7:29 PM -0400 7/27/00, Eric S. Raymond wrote: >D. J. Bernstein : >> I agree that this needs discussion. >> >> However, I have a different suggestion: the definitions of ``SHOULD'' et >> al. should simply be copied from RFC 2119, with no extra text. >> >> (I say ``copied'' rather than ``incorporated by reference'' to avoid the >> issue of whether smtpupd is obliged to follow RFC 2119, section 6.) >> >> Most readers will be expecting the RFC 2119 definitions. Many readers >> will misinterpret the document if it uses anything else---they'll never >> realize that there are new definitions. >> >> I've checked a bunch of ``SHOULD''s in the document, and they all seem >> to predate the new definitions, which appeared in smtpupd-09. Presumably >> they were written with the RFC 2119 (or almost identical RFC 1123) >> definitions in mind. The new definitions seem to have screwed up the >> meaning of these ``SHOULD''s. >> >> ---Dan > >I think this is a good suggestion. I agree with Dan and Eric. A typical implemetor will assume that MUST and SHOULD are used as they are in every other mail standard, namely as they are stated in 2119. --Paul Hoffman, Director --Internet Mail Consortium From owner-drums@cs.utk.edu Thu Jul 27 23:31:08 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07526 for ; Thu, 27 Jul 2000 23:31:08 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id XAA06696; Thu, 27 Jul 2000 23:30:52 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Thu, 27 Jul 2000 23:30:49 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id XAA06670; Thu, 27 Jul 2000 23:30:49 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id XAA06654; Thu, 27 Jul 2000 23:30:47 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Thu, 27 Jul 2000 23:30:47 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id XAA01229; Thu, 27 Jul 2000 23:30:45 -0400 (EDT) Message-Id: <200007280330.XAA01229@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Paul Hoffman / IMC cc: drums@cs.utk.edu Subject: 2nd suggested revision for MUST/SHOULD In-reply-to: Your message of "Thu, 27 Jul 2000 18:21:06 PDT." Date: Thu, 27 Jul 2000 23:30:45 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: several points: I see no inherent problem with copying the 2119 definitions for MUST/SHOULD. However I assume that much of the existing text is based on the 1123 definitions of these terms, so changing might require examining every occurance of these terms. Fortunately, the 1123, 2119, and proposed definitions of these terms are quite similar. And I do see value in consistency with 2119, though RFCs which deviate from the 2119 definitions are not uncommon. However I wonder if the definitions of "fully conforming" vs. "partially conforming" may still be useful, regardless of which definitions of MUST/SHOULD are used. OTOH, I do have some reservations about defining "fully/partially conforming" in this way because (if memory serves) SHOULD [NOT] are sometimes used to avoid having to specify the behavior of each particular kind of MTA configuration. An SMTP implementation that, for whatever valid reason, doesn't perform every single one of the functions of an MTA (submission, delivery, relaying, aliasing, list expansion, etc) should perhaps be "fully conforming" as long as it meets the SHOULD [NOT] requirements for the functions that it does perform. I also think that it's worthwhile to explain - why SHOULD or even MUST might specify something that degrades interoperability with noncomforming implementations of this or a previous specification. (interoperability with conforming implementations is paramount) - that the spec is deliberately tightened as compared to previous versions; pre-existing implementations are expected to require some changes no matter which definitions of MUST/SHOULD/MAY are used. personally, I don't think that consistency with 2119 is so important that it necessiates changing the document at this late date. but if it helps us get consensus on the document, it might be worth it. so at the risk of bogging things down more, here is a 2nd concrete proposal. the paragraphs not in 2119 are labelled [A], [B], and [C] for easy reference in DRUMS discussion, not for inclusion in the RFC. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as follows: 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification. 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. 5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.) [A] An implementation that does not adhere to each of the "MUST" and "MUST NOT" requirements is not considered to be conforming to this specification. An implementation that adheres to each of the "MUST" and "MUST NOT" requirements, but does not adhere to each of the "SHOULD" and "SHOULD NOT" requirements, is considered to be partially conforming to this specification. An implementation that adheres to all requirements is considered to be fully conforming. There is no intention or expectation that partially or fully conforming implementations of this specification will interoperate with nonconforming implementations of either this specification or its predecessors. [B] "MUST" and "MUST NOT" are generally used when the requirement is necessary to ensure robust interoperation between conforming implementations. "SHOULD" and "SHOULD NOT" are also used to describe cases where the requirement is necessary for robust interoperation between (fully or partially) conforming implementations, but when it is recognized that there may be valid reasons for a particular implementation (or a particular type of implementation) to not follow the requirement. [C] In some cases this document imposes "MUST" and/or "SHOULD" requirements which deviate from a significant body of current practice at the time of this writing. In such cases these requirements are imposed when experience indicates that following such requirements is likely to lead, in practice, to better interoperation, or smoother operation of the Internet email infrastructure. Though this document does attempt to ensure that (fully or partially) implementations of this specification will interoperate with (fully or partially) conforming implementations of its predecessors, it does not attempt to legitimize common deviations from those specifications, and it does impose new requirements. Existing implementations of SMTP will need some changes if they are to conform to this new specification. From owner-drums@cs.utk.edu Fri Jul 28 07:14:12 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17669 for ; Fri, 28 Jul 2000 07:14:12 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA29444; Fri, 28 Jul 2000 07:13:45 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 07:13:43 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id HAA29427; Fri, 28 Jul 2000 07:13:43 -0400 (EDT) Received: from probity.mcc.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id HAA29414; Fri, 28 Jul 2000 07:13:39 -0400 (EDT) Received: from probity.mcc.ac.uk (130.88.200.94 -> probity.mcc.ac.uk) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 07:13:40 -0400 Received: from nessie.mcc.ac.uk ([130.88.200.20] ident=root) by probity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 13I85C-0009Vs-00 for drums@cs.utk.edu; Fri, 28 Jul 2000 12:13:38 +0100 Received: from clw.cs.man.ac.uk (clerew.man.ac.uk [194.66.22.208]) by nessie.mcc.ac.uk (8.9.3/8.8.8) with ESMTP id MAA50859 for ; Fri, 28 Jul 2000 12:13:35 +0100 (BST) (envelope-from root@clw.cs.man.ac.uk) Received: (from root@localhost) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) id JAA07095 for drums@cs.utk.edu; Fri, 28 Jul 2000 09:39:23 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) with SMTP id JAA07092 for ; Fri, 28 Jul 2000 09:39:22 +0100 (BST) Message-Id: <200007280839.JAA07092@clw.cs.man.ac.uk> Date: Fri, 28 Jul 2000 09:39:22 +0100 (BST) From: Charles Lindsey Reply-To: Charles Lindsey Subject: Re: 2nd suggested revision for MUST/SHOULD To: drums@cs.utk.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: eSTzKGCN269Jnq3DbvLgnQ== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc List-Unsubscribe: On Thu, 27 Jul 2000 23:30:45 -0400 Keith Moore said... > > several points: > > I see no inherent problem with copying the 2119 definitions for > MUST/SHOULD. However I assume that much of the existing text is > based on the 1123 definitions of these terms, so changing might > require examining every occurance of these terms. Fortunately, > the 1123, 2119, and proposed definitions of these terms are quite > similar. And I do see value in consistency with 2119, though > RFCs which deviate from the 2119 definitions are not uncommon. > > However I wonder if the definitions of "fully conforming" > vs. "partially conforming" may still be useful, regardless of which > definitions of MUST/SHOULD are used. OTOH, I do have some > reservations about defining "fully/partially conforming" in this way > because (if memory serves) SHOULD [NOT] are sometimes used to avoid > having to specify the behavior of each particular kind of MTA > configuration. An SMTP implementation that, for whatever valid > reason, doesn't perform every single one of the functions of an MTA > (submission, delivery, relaying, aliasing, list expansion, etc) > should perhaps be "fully conforming" as long as it meets the > SHOULD [NOT] requirements for the functions that it does perform. > > I also think that it's worthwhile to explain > > - why SHOULD or even MUST might specify something that degrades > interoperability with noncomforming implementations of this or > a previous specification. (interoperability with conforming > implementations is paramount) > > - that the spec is deliberately tightened as compared to previous > versions; pre-existing implementations are expected to require > some changes > > no matter which definitions of MUST/SHOULD/MAY are used. > > personally, I don't think that consistency with 2119 is so important > that it necessiates changing the document at this late date. > but if it helps us get consensus on the document, it might be worth it. > > so at the risk of bogging things down more, here is a 2nd concrete > proposal. the paragraphs not in 2119 are labelled [A], [B], and [C] > for easy reference in DRUMS discussion, not for inclusion in the > RFC. Yes, I think that is better, because the relationship to 2119 is now clear. But I see little point in repeating the 2119 text in full. Other standards just refer to it. A couple of nit picks: > [B] ... > type of implementation) to not follow the requirement. ^^^^^^^^^^^^^ not to follow (split infinitive :-( ) > > [C] In some cases this document imposes "MUST" and/or "SHOULD" > requirements which deviate from a significant body of current practice > at the time of this writing. In such cases these requirements are > imposed when experience indicates that following such requirements > is likely to lead, in practice, to better interoperation, or > smoother operation of the Internet email infrastructure. Though > this document does attempt to ensure that (fully or partially) ^ conforming > implementations of this specification will interoperate with > (fully or partially) conforming implementations of its predecessors, > it does not attempt to legitimize common deviations from those > specifications, and it does impose new requirements. Existing ^ Some > implementations of SMTP will need some changes if they are to > conform to this new specification. > Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-drums@cs.utk.edu Fri Jul 28 07:44:07 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24053 for ; Fri, 28 Jul 2000 07:44:07 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA01687; Fri, 28 Jul 2000 07:43:54 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 07:43:53 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id HAA01670; Fri, 28 Jul 2000 07:43:53 -0400 (EDT) Received: from lotus2.lotus.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id HAA01657; Fri, 28 Jul 2000 07:43:51 -0400 (EDT) Received: from lotus2.lotus.com (192.233.136.8 -> lotus2.lotus.com) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 07:43:51 -0400 Received: from internet2.lotus.com (internet2.lotus.com [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id HAA21515 for ; Fri, 28 Jul 2000 07:45:07 -0400 (EDT) Received: from a3mail.lotus.com (CRD.lotus.com [9.95.5.66]) by internet2.lotus.com (8.9.3/8.9.3) with ESMTP id HAA25407 for ; Fri, 28 Jul 2000 07:43:47 -0400 (EDT) To: drums@cs.utk.edu Subject: Re: 2nd suggested revision for MUST/SHOULD X-Mailer: Lotus Notes Build V505_07242000 July 24, 2000 From: "Nick Shelness/SSW/Lotus" Message-ID: Date: Fri, 28 Jul 2000 12:43:40 +0100 X-MIMETrack: Serialize by Router on A3MAIL/CAM/H/Lotus(Build V505_07062000 |July 6, 2000) at 07/28/2000 07:46:28 AM, Serialize complete at 07/28/2000 07:46:28 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: I concur with Keith's proposed text as modified by Charles Lindsey. I would also be quite happy to see a reference to RFC 2119 rather than copied text. Nick Nick Shelness, IBM Fellow Chief Technology Officer Lotus Development Corp Tel: (617) 693-7484 Assistant: Mary McGurran Tel: (617) 693-4321 From owner-drums@cs.utk.edu Fri Jul 28 09:29:48 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17483 for ; Fri, 28 Jul 2000 09:29:48 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA08066; Fri, 28 Jul 2000 09:29:34 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 09:29:29 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id JAA08049; Fri, 28 Jul 2000 09:29:29 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA08032; Fri, 28 Jul 2000 09:29:27 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 09:29:27 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id JAA02267; Fri, 28 Jul 2000 09:29:23 -0400 (EDT) Message-Id: <200007281329.JAA02267@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Charles Lindsey cc: drums@cs.utk.edu Subject: Re: 2nd suggested revision for MUST/SHOULD In-reply-to: Your message of "Fri, 28 Jul 2000 09:39:22 BST." <200007280839.JAA07092@clw.cs.man.ac.uk> X-SUBJECT-MSG-FROM: Charles Lindsey Date: Fri, 28 Jul 2000 09:29:23 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > But I see little point in repeating the 2119 text in full. as Dan pointed out, there is language in 2119 (specifically section 6) that over-constrains use of 2119. since 2119 was published it is apparent that there are valid reasons to use 2119 keywords that are not "actually required for interoperation or to limit behavior which has potential for causing harm" ... especially when we base try to define conformance to the specification strictly in terms of these keywords. the normal workaround (until 2119 is revised) is for a document to provide its own definitions of MUST/SHOULD/etc. I suppose we could try referencing 2119 with a disclaimer that section 6 does not apply...and see if that gets by IESG. if we wanted to try this I'd strongly recommend that someone approach the author of 2119 first and ask him in person about it. one thing that worries me about defining conformance in this way: do we have confidence that adhering to the MUSTs SHOULDs etc is sufficient to call an implementation conforming, in the sense that we believe that the implementation will function properly and interoperate with other implementations? or are there enough things in the document that are not specified in this way? somehow I don't like the idea that "if the document doesn't say MUST or SHOULD about a particular thing, it's not needed for conformance, so we can disregard it" Keith From owner-drums@cs.utk.edu Fri Jul 28 10:40:46 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03930 for ; Fri, 28 Jul 2000 10:40:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id KAA14049; Fri, 28 Jul 2000 10:40:28 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 10:40:22 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id KAA14015; Fri, 28 Jul 2000 10:40:21 -0400 (EDT) Received: from muncher.math.uic.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id KAA14001; Fri, 28 Jul 2000 10:40:20 -0400 (EDT) Received: from muncher.math.uic.edu (131.193.178.181 -> muncher.math.uic.edu) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 10:40:20 -0400 Received: (qmail 28741 invoked by uid 1001); 28 Jul 2000 14:40:41 -0000 Date: 28 Jul 2000 14:40:41 -0000 Message-ID: <20000728144041.2983.qmail@cr.yp.to> From: "D. J. Bernstein" To: drums@cs.utk.edu Cc: sob@harvard.edu Subject: Re: 2nd suggested revision for MUST/SHOULD References: <200007280839.JAA07092@clw.cs.man.ac.uk> <200007281329.JAA02267@astro.cs.utk.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: Keith Moore writes: > as Dan pointed out, there is language in 2119 (specifically > section 6) that over-constrains use of 2119. That's not what I said. As far as I'm concerned, the biggest flaw in section 6 of RFC 2119 is that IETF documents in general _aren't_ required to follow it. If you're violating section 6, chances are excellent that you're violating United States antitrust law. In the words of the Federal Trade Commission, standards must not impose ``construction requirements'' in place of ``performance requirements.'' I understand that the smtpupd editor refuses to follow section 6. I was trying to stay away from this issue, so that we could focus on bringing the document's definition of ``SHOULD'' in line with what the readers will expect. Copying the RFC 2119 text is the easiest way to do this. ---Dan P.S. Why hasn't Newman declared that your message will be ignored? See section 4 of his ``procedures.'' From owner-drums@cs.utk.edu Fri Jul 28 11:13:49 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12185 for ; Fri, 28 Jul 2000 11:13:48 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA16822; Fri, 28 Jul 2000 11:13:27 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 11:13:27 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA16805; Fri, 28 Jul 2000 11:13:26 -0400 (EDT) Received: from prognet.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA16792; Fri, 28 Jul 2000 11:13:24 -0400 (EDT) Received: from prognet.com (205.219.198.1 -> prognet.com) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 11:13:24 -0400 Received: from mscharff.real.com ([172.22.104.48]) by prognet.com (8.9.2/8.9.0) with ESMTP id IAA01433; Fri, 28 Jul 2000 08:13:17 -0700 (PDT) Message-Id: <4.3.2.7.2.20000728081328.00aebd90@mail.real.com> X-Sender: mscharff@mail.real.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Jul 2000 08:14:32 +0100 To: "Nick Shelness/SSW/Lotus" , drums@cs.utk.edu From: Michael Scharff Subject: Re: 2nd suggested revision for MUST/SHOULD In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: The issue with merely referencing 2119 is that it will allow for the train of thought that other items in 2119 may somehow be relevant as well. Just a thought. At 12:43 PM 7/28/00 +0100, Nick Shelness/SSW/Lotus wrote: >I concur with Keith's proposed text as modified by Charles Lindsey. I >would also be quite happy to see a reference to RFC 2119 rather than >copied text. > >Nick > >Nick Shelness, IBM Fellow >Chief Technology Officer >Lotus Development Corp >Tel: (617) 693-7484 > >Assistant: Mary McGurran >Tel: (617) 693-4321 From owner-drums@cs.utk.edu Fri Jul 28 11:49:34 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24825 for ; Fri, 28 Jul 2000 11:49:33 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id LAA21633; Fri, 28 Jul 2000 11:49:12 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 11:49:10 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id LAA21615; Fri, 28 Jul 2000 11:49:09 -0400 (EDT) Received: from candle.brasslantern.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id LAA21600; Fri, 28 Jul 2000 11:49:04 -0400 (EDT) Received: from candle.brasslantern.com (206.184.69.215 -> dynamic215.as32.snfcca01.pacific.verio.net) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 11:49:04 -0400 Received: (from schaefer@localhost) by candle.brasslantern.com (8.9.2/8.9.2) id IAA09366 for drums@cs.utk.edu; Fri, 28 Jul 2000 08:49:02 -0700 (PDT) From: "Bart Schaefer" Message-Id: <1000728154901.ZM9365@candle.brasslantern.com> Date: Fri, 28 Jul 2000 15:49:01 +0000 In-Reply-To: <200007281329.JAA02267@astro.cs.utk.edu> Comments: In reply to Keith Moore "Re: 2nd suggested revision for MUST/SHOULD" (Jul 28, 9:29am) References: <200007281329.JAA02267@astro.cs.utk.edu> X-Mailer: Z-Mail (5.0.0 30July97) To: drums@cs.utk.edu Subject: Re: 2nd suggested revision for MUST/SHOULD MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: On Jul 28, 9:29am, Keith Moore wrote: } Subject: Re: 2nd suggested revision for MUST/SHOULD } } one thing that worries me about defining conformance in this way: } do we have confidence that adhering to the MUSTs SHOULDs etc } is sufficient to call an implementation conforming, in the } sense that we believe that the implementation will function } properly and interoperate with other implementations? I'd also like to point out that the "SHOULD"/"MAY" problem with X.1.9(iv) still exists if these definitions of fully v. partially conforming are attached to the definitions from 2119. I believe we either need to use 2119 without such additions, or else include something along the lines of my suggested "MAY" text as well. I think that each of the suggested revisions is more clearly stated than the text presently in 2.3. -- Bart Schaefer Zanshin http://www.well.com/user/barts http://www.zanshin.com From owner-drums@cs.utk.edu Fri Jul 28 12:31:15 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04353 for ; Fri, 28 Jul 2000 12:31:14 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA26278; Fri, 28 Jul 2000 12:30:58 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 12:30:58 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA26261; Fri, 28 Jul 2000 12:30:57 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id MAA26244; Fri, 28 Jul 2000 12:30:56 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 12:30:56 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id MAA05688; Fri, 28 Jul 2000 12:30:54 -0400 (EDT) Message-Id: <200007281630.MAA05688@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "D. J. Bernstein" cc: drums@cs.utk.edu, sob@harvard.edu Subject: Re: 2nd suggested revision for MUST/SHOULD In-reply-to: Your message of "28 Jul 2000 14:40:41 -0000." <20000728144041.2983.qmail@cr.yp.to> Date: Fri, 28 Jul 2000 12:30:54 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > > as Dan pointed out, there is language in 2119 (specifically > > section 6) that over-constrains use of 2119. > > That's not what I said. I stand corrected. sorry to put words in your mouth. Keith From owner-drums@cs.utk.edu Fri Jul 28 16:12:49 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05033 for ; Fri, 28 Jul 2000 16:12:48 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA13184; Fri, 28 Jul 2000 16:11:35 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 16:11:32 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA13160; Fri, 28 Jul 2000 16:11:31 -0400 (EDT) Received: from achilles.ctd.anl.gov (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA13134; Fri, 28 Jul 2000 16:11:27 -0400 (EDT) Received: from achilles.ctd.anl.gov (146.137.32.1 -> achilles.ctd.anl.gov) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 16:11:27 -0400 Received: by achilles.ctd.anl.gov (8.9.1a/8.9.1) id PAA14923; Fri, 28 Jul 2000 15:11:21 -0500 (CDT) Date: Fri, 28 Jul 2000 15:11:21 -0500 (CDT) From: Barry Finkel Message-Id: <200007282011.PAA14923@achilles.ctd.anl.gov> To: drums@cs.utk.edu Subject: Re: 2nd suggested revision for MUST/SHOULD In-Reply-To: Mail from 'Keith Moore ' dated: Thu, 27 Jul 2000 23:30:45 -0400 Cc: moore@cs.utk.edu List-Unsubscribe: Keith Moore wrote: > [A] An implementation that does not adhere to each of the "MUST" and "MUST >NOT" requirements is not considered to be conforming to this specification. Is there a semantic difference between "is not considered to be conforming" vs. "is considered not to be conforming" vs. "is considered to be non-conforming" I am not sure. To me, the latter two seem stronger. ---------------------------------------------------------------------- Barry S. Finkel Electronics and Computing Technologies Division Argonne National Laboratory Phone: +1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-9689 Building 221, Room B236 Internet: BSFinkel@anl.gov Argonne, IL 60439-4844 IBMMAIL: I1004994 From owner-drums@cs.utk.edu Fri Jul 28 16:20:56 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06748 for ; Fri, 28 Jul 2000 16:20:55 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id QAA14121; Fri, 28 Jul 2000 16:20:41 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 16:20:40 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id QAA14104; Fri, 28 Jul 2000 16:20:40 -0400 (EDT) Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA14083; Fri, 28 Jul 2000 16:20:39 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 16:20:39 -0400 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA09680; Fri, 28 Jul 2000 16:20:37 -0400 (EDT) Message-Id: <200007282020.QAA09680@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Barry Finkel cc: drums@cs.utk.edu, moore@cs.utk.edu Subject: Re: 2nd suggested revision for MUST/SHOULD In-reply-to: Your message of "Fri, 28 Jul 2000 15:11:21 CDT." <200007282011.PAA14923@achilles.ctd.anl.gov> Date: Fri, 28 Jul 2000 16:20:37 -0400 Sender: moore@cs.utk.edu List-Unsubscribe: > Is there a semantic difference between > > "is not considered to be conforming" > vs. > "is considered not to be conforming" > vs. > "is considered to be non-conforming" > > I am not sure. To me, the latter two seem stronger. yes, there probably is a difference. to use more blunt language, to me it seems safer to say "implementation X does not meet our definition of 'good'" than to say "implementation X is 'bad'". but we could probably make a case for the latter. Keith From owner-drums@cs.utk.edu Fri Jul 28 19:36:58 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21978 for ; Fri, 28 Jul 2000 19:36:58 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA28089; Fri, 28 Jul 2000 19:36:33 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 19:36:26 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA28071; Fri, 28 Jul 2000 19:36:25 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA28057; Fri, 28 Jul 2000 19:36:19 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 19:36:19 -0400 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA29191; Fri, 28 Jul 2000 16:36:12 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA09802; Fri, 28 Jul 2000 16:36:11 -0700 (PDT) Date: Fri, 28 Jul 2000 16:35:33 -0700 From: DRUMS WG Chair To: drums@cs.utk.edu cc: John Klensin , Paul Hoffman Subject: Re: suggested revision for MUST/SHOULD Message-ID: <2302674.3173790933@nifty-jr.west.sun.com> In-Reply-To: <20000727225347.4260.qmail@cr.yp.to> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit --On Thursday, July 27, 2000 22:53 +0000 "D. J. Bernstein" wrote: > However, I have a different suggestion: the definitions of ``SHOULD'' et > al. should simply be copied from RFC 2119, with no extra text. > > (I say ``copied'' rather than ``incorporated by reference'' to avoid the > issue of whether smtpupd is obliged to follow RFC 2119, section 6.) > > Most readers will be expecting the RFC 2119 definitions. Many readers > will misinterpret the document if it uses anything else---they'll never > realize that there are new definitions. The document editor has privately told me he is agreeable to the proposal to copy the definitions from RFC 2119 under the condition that there is a review of all MUST/SHOULD usage in the draft relative to the changed meanings. Paul Hoffman has volunteered to perform that review. If no one objects, I will ask Paul to perform that review and post proposed text changes (if any are needed) to the list for consideration. - DRUMS WG Chair From owner-drums@cs.utk.edu Fri Jul 28 20:10:47 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00573 for ; Fri, 28 Jul 2000 20:10:45 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA00541; Fri, 28 Jul 2000 20:09:54 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 20:09:53 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA00524; Fri, 28 Jul 2000 20:09:52 -0400 (EDT) Received: from mercury.Sun.COM (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id UAA00511; Fri, 28 Jul 2000 20:09:40 -0400 (EDT) Received: from mercury.Sun.COM (192.9.25.1 -> mercury.Sun.COM) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 20:09:41 -0400 Received: from westmail2.West.Sun.COM ([129.153.100.30]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA08025 for ; Fri, 28 Jul 2000 17:09:37 -0700 (PDT) Received: from nifty-jr.west.sun.com (nifty-jr.West.Sun.COM [129.153.12.95]) by westmail2.West.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA12737 for ; Fri, 28 Jul 2000 17:09:36 -0700 (PDT) Date: Fri, 28 Jul 2000 17:08:58 -0700 From: DRUMS WG Chair To: "Detailed Revision/Update of Message Standards" Subject: SMTP draft Issues Message-ID: <2423275.3173792938@nifty-jr.west.sun.com> X-Mailer: Mulberry/2.0.3 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit "suggested revision for MUST/SHOULD" Debate Open, proposal for rough concensus pending "Conflict between X.1.9(iv) and literal interpretation of draft-12" Debate Closed, only 2 explicit supporters of proposed text "2nd suggested revision for MUST/SHOULD" (replacement language for "fully conforming") Debate Closed, only 3 explicit supporters of proposed text These are the only issues I'm currently tracking. If you want some other issue to be considered, please start a new subject and include proposed changes to the text in the SMTP draft. Please don't debate an issue until we have at least 4 posts expressing support (including the original proposer). This work is so overdue that I'm experimenting with somewhat heavy-handed procedures to avoid unnecessary debate and simplify issue tracking. Feel free to send comments on procedural issues to me privately. - DRUMS WG Chair From owner-drums@cs.utk.edu Fri Jul 28 20:15:59 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01735 for ; Fri, 28 Jul 2000 20:15:57 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA01015; Fri, 28 Jul 2000 20:15:15 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 20:15:14 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id UAA00998; Fri, 28 Jul 2000 20:15:14 -0400 (EDT) Received: from windlord.stanford.edu (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA00979; Fri, 28 Jul 2000 20:15:04 -0400 (EDT) Received: from windlord.stanford.edu (171.64.12.23 -> windlord.Stanford.EDU) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 20:15:05 -0400 Received: (qmail 4187 invoked by uid 50); 29 Jul 2000 00:14:59 -0000 To: drums@cs.utk.edu Subject: Re: suggested revision for MUST/SHOULD References: <2302674.3173790933@nifty-jr.west.sun.com> In-Reply-To: DRUMS WG Chair's message of "Fri, 28 Jul 2000 16:35:33 -0700" From: Russ Allbery Organization: The Eyrie Date: 28 Jul 2000 17:14:59 -0700 Message-ID: Lines: 16 User-Agent: Gnus/5.0802 (Gnus v5.8.2) XEmacs/21.1 (Biscayne) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii List-Unsubscribe: DRUMS WG Chair writes: > The document editor has privately told me he is agreeable to the > proposal to copy the definitions from RFC 2119 under the condition that > there is a review of all MUST/SHOULD usage in the draft relative to the > changed meanings. Paul Hoffman has volunteered to perform that review. > If no one objects, I will ask Paul to perform that review and post > proposed text changes (if any are needed) to the list for consideration. I was hesitating on agreeing with that proposal due to the amount of work it would take to do that review. Thank you, Paul! I think it will be less confusing for this RFC to use the same definitions as most others these days are, even if the degree of the differences is arguable. -- Russ Allbery (rra@stanford.edu) From owner-drums@cs.utk.edu Fri Jul 28 20:16:53 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01937 for ; Fri, 28 Jul 2000 20:16:47 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id UAA01126; Fri, 28 Jul 2000 20:16:01 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 20:16:01 -0400 Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id UAA01111; Fri, 28 Jul 2000 20:16:00 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 20:16:00 -0400 Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id UAA13841 for dist-drums@cs.utk.edu; Fri, 28 Jul 2000 20:16:00 -0400 (EDT) Received: from ss3000e.cselt.it (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id QAA16047; Fri, 28 Jul 2000 16:33:35 -0400 (EDT) Received: from ss3000e.cselt.it (163.162.41.5 -> ss3000e.cselt.it) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 16:33:35 -0400 Received: from beatles.cselt.it (beatles.cselt.it [163.162.29.125]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0FYF00L5NCTOM3@ss3000e.cselt.it> for drums@cs.utk.edu; Fri, 28 Jul 2000 22:27:24 +0200 (MET DST) Received: (from mau@localhost) by beatles.cselt.it (8.9.3/8.9.3) id WAA21386 for drums@cs.utk.edu; Fri, 28 Jul 2000 22:32:28 +0200 (MET DST) Date: Fri, 28 Jul 2000 22:32:28 +0200 (MET DST) From: Maurizio Codogno Subject: "not conformity" To: drums@cs.utk.edu Message-id: <200007282032.WAA21386@beatles.cselt.it> List-Unsubscribe: > > Is there a semantic difference between > > > > "is not considered to be conforming" > > vs. > > "is considered not to be conforming" > > vs. > > "is considered to be non-conforming" > > > > I am not sure. To me, the latter two seem stronger. > > yes, there probably is a difference. I am sure a linguist will point out what are the differences among the forms. From my own point of view (a foreign mathematician, who speaks English as a second language) there is no practical difference. Since specs are not written for Professors of English, I wouldn't care which one to select :-) ciao, .mau. From owner-drums@cs.utk.edu Fri Jul 28 22:14:45 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27837 for ; Fri, 28 Jul 2000 22:14:43 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA08086; Fri, 28 Jul 2000 22:13:43 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Fri, 28 Jul 2000 22:13:38 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA08065; Fri, 28 Jul 2000 22:13:37 -0400 (EDT) Received: from probity.mcc.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA08037; Fri, 28 Jul 2000 22:13:23 -0400 (EDT) Received: from probity.mcc.ac.uk (130.88.200.94 -> probity.mcc.ac.uk) by cs.utk.edu (smtpshim v1.0); Fri, 28 Jul 2000 22:13:24 -0400 Received: from nessie.mcc.ac.uk ([130.88.200.20] ident=root) by probity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 13IM7s-000G7Q-00 for drums@cs.utk.edu; Sat, 29 Jul 2000 03:13:20 +0100 Received: from clw.cs.man.ac.uk (clerew.man.ac.uk [194.66.22.208]) by nessie.mcc.ac.uk (8.9.3/8.8.8) with ESMTP id DAA75298 for ; Sat, 29 Jul 2000 03:13:18 +0100 (BST) (envelope-from root@clw.cs.man.ac.uk) Received: (from root@localhost) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) id UAA10270 for drums@cs.utk.edu; Fri, 28 Jul 2000 20:44:09 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) with SMTP id UAA10267 for ; Fri, 28 Jul 2000 20:44:08 +0100 (BST) Message-Id: <200007281944.UAA10267@clw.cs.man.ac.uk> Date: Fri, 28 Jul 2000 20:44:08 +0100 (BST) From: Charles Lindsey Reply-To: Charles Lindsey Subject: Re: 2nd suggested revision for MUST/SHOULD To: drums@cs.utk.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8AHggxW3iQBk9dXk+l2IbA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc List-Unsubscribe: On Fri, 28 Jul 2000 09:29:23 -0400 Keith Moore said... > > > But I see little point in repeating the 2119 text in full. > > as Dan pointed out, there is language in 2119 (specifically > section 6) that over-constrains use of 2119. since 2119 > was published it is apparent that there are valid reasons > to use 2119 keywords that are not "actually required for > interoperation or to limit behavior which has potential > for causing harm" ... especially when we base try to define > conformance to the specification strictly in terms of > these keywords. > > the normal workaround (until 2119 is revised) is for a > document to provide its own definitions of MUST/SHOULD/etc. > I suppose we could try referencing 2119 with a disclaimer > that section 6 does not apply...and see if that gets by IESG. > if we wanted to try this I'd strongly recommend that someone > approach the author of 2119 first and ask him in person about it. Well we wanted to do something long those lines in USEFOR, so we asked the higher ups in IESG (specifially the Area Director, who will be the same Area Director as DRUMS, I imagine) whether we were allowed to contemplate such a thing. Specifically, we wanted either to extend the use of SHOULD to encompass things that were not strictly necessary for interoperability, but which were nevertheless highly desirable for the smooth functioning of Usenet. Alternatively, we asked if we could define a word OUGHT for that purpose. We were told in no uncertain terms that we could not do either of those things. The most we would be allowed to do would be to use "ought" in lower case for such things (which is what we will likely now do). So with that precedent established, I hardly see how DRUMS can make any substantial departure from 2119. But yes, referencing 2119 with such disclaimers as you think appropriate would be the right way to do it, if you can get the powers that be to allow it. Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-drums@cs.utk.edu Sat Jul 29 07:29:41 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15782 for ; Sat, 29 Jul 2000 07:29:40 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA00620; Sat, 29 Jul 2000 07:29:07 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 29 Jul 2000 07:29:04 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id HAA00585; Sat, 29 Jul 2000 07:29:04 -0400 (EDT) Received: from mailout06.sul.t-online.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id HAA00536; Sat, 29 Jul 2000 07:28:59 -0400 (EDT) Received: from mailout06.sul.t-online.com (194.25.134.19 -> mailout06.sul.t-online.com) by cs.utk.edu (smtpshim v1.0); Sat, 29 Jul 2000 07:28:59 -0400 Received: from fmrl01.sul.t-online.de by mailout06.sul.t-online.com with smtp id 13IUnV-0002tH-00; Sat, 29 Jul 2000 13:28:53 +0200 Received: from khms.westfalen.de (340048396503-0001@[62.155.166.4]) by fmrl01.sul.t-online.com with esmtp id 13IUnR-206YWeC; Sat, 29 Jul 2000 13:28:49 +0200 Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.12 #1) id 13IUnQ-000215-01 (Debian); Sat, 29 Jul 2000 13:28:48 +0200 Received: by khms.westfalen.de (CrossPoint v3.12d.kh5 R/C435); 29 Jul 2000 13:27:19 +0200 Date: 29 Jul 2000 12:27:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: drums@cs.utk.edu Message-ID: <7imD-dUmw-B@khms.westfalen.de> In-Reply-To: Subject: Re: client requests ending \012 X-Mailer: CrossPoint v3.12d.kh5 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <4.3.2.7.2.20000725093157.00af95f0@mail.real.com> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 X-Sender: 340048396503-0001@t-dialin.net List-Unsubscribe: ph10@cus.cam.ac.uk (Philip Hazel) wrote on 25.07.00 in : > On Tue, 25 Jul 2000, Michael Scharff wrote: > > > I have to chime in here and protest such a response. This sounds like a > > good reason to go back and insure that CRLF is a MUST and NOT considered > > optional in ANY CASE. > > The problem is historical baggage. I can't remember the details, but the > reason I changed Exim was something like this: There was a company that > had a server running Sendmail or Smail (I can't remember which) and a > whole slew of local clients. They changed the server to Exim, and some > clients stopped working. The clients were running software for which the > source was not available. Management's attitude was "The clients used to > work, so they should continue to work."; the technical guys didn't want to > go back. Maybe I'm too kind hearted, but I listened to their plea for > help. > > It's the old, old story: if a non-conformance gets widely spread, > something will exploit it, and you can never claw back to strict > conformance. Once some widely used server is "liberal in what it > accepts", everybody else has to follow suit. Look at PP; it tried to > implement the RFC "correctly", even to the extent of rejecting messages > without a Date: header line (just one example). This just caused > trouble. There's an answer to this. Unfortunately, it takes a significant amount of work, so it's not very likely to be actually employed. That is, whenever you enable non-RFC behaviour, make it depend on an option that says, for example, break_rfc_allow_linefeed_lineends, and defaults to off. The point being, (a) only those people who think they need it activate it, so chances are any odd server you happen to look at will still reject it as an error, and (b) people who switch it on *learn* that it conflicts with the standard. I don't expect it to happen, but I do think it would be a good thing. MfG Kai From owner-drums@cs.utk.edu Sat Jul 29 07:29:44 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15807 for ; Sat, 29 Jul 2000 07:29:43 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id HAA00618; Sat, 29 Jul 2000 07:29:07 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 29 Jul 2000 07:29:04 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id HAA00586; Sat, 29 Jul 2000 07:29:04 -0400 (EDT) Received: from mailout03.sul.t-online.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id HAA00532; Sat, 29 Jul 2000 07:28:57 -0400 (EDT) Received: from mailout03.sul.t-online.com (194.25.134.81 -> mailout03.sul.t-online.com) by cs.utk.edu (smtpshim v1.0); Sat, 29 Jul 2000 07:28:58 -0400 Received: from fmrl00.sul.t-online.de by mailout03.sul.t-online.com with smtp id 13IUnU-000796-00; Sat, 29 Jul 2000 13:28:52 +0200 Received: from khms.westfalen.de (340048396503-0001@[62.155.166.4]) by fmrl00.sul.t-online.com with esmtp id 13IUnS-0RpmwSC; Sat, 29 Jul 2000 13:28:50 +0200 Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.12 #1) id 13IUnQ-000215-02 (Debian); Sat, 29 Jul 2000 13:28:48 +0200 Received: by khms.westfalen.de (CrossPoint v3.12d.kh5 R/C435); 29 Jul 2000 13:27:19 +0200 Date: 29 Jul 2000 12:33:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: drums@cs.utk.edu Message-ID: <7imD-v2Hw-B@khms.westfalen.de> In-Reply-To: <4.3.2.20000726034710.00bd4100@mail.bayarea.net> Subject: Re: client requests ending \012 X-Mailer: CrossPoint v3.12d.kh5 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <4.3.2.7.2.20000725093157.00af95f0@mail.real.com> <200007251257.NAA19627@clw.cs.man.ac.uk> <4.3.2.7.2.20000725093157.00af95f0@mail.real.com> <4.3.2.20000726034710.00bd4100@mail.bayarea.net> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 X-Sender: 340048396503-0001@t-dialin.net List-Unsubscribe: dcrocker@brandenburg.com (Dave Crocker) wrote on 26.07.00 in <4.3.2.20000726034710.00bd4100@mail.bayarea.net>: > At 02:16 PM 7/25/00 -0700, Lee Thompson wrote: > >The SMTP/Message Format system currently in use is a mess. We have nearly > >20 years of standard drift and those standards are vague in some areas. > >For better or for worse the internet is now a commercial environment which > >means interoperability and reliability are the key factors. > > There is truth in what you observe, but it does not apply to CRLF. If > anything the standards drift is due to constantly making local changes to > accept non-conforming behavior. It is the norm for email. > > Imagine if folks had taken that approach for TCP... Oh, they have. But I notice that, at least in the case I'm familiar with, they're a little more obvious about what is going on: -- snip -- PC/TCP compatibility mode CONFIG_INET_PCTCP If you have been having difficulties telnetting to your Linux machine from a DOS system that uses (broken) PC/TCP networking software (all versions up to OnNet 2.0) over your local Ethernet try saying Y here. Everyone else says N. People having problems with NCSA telnet should see the file linux/Documentation/networking/ncsa-telnet. -- snip -- MfG Kai From owner-drums@cs.utk.edu Sat Jul 29 09:52:18 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25399 for ; Sat, 29 Jul 2000 09:52:18 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id JAA05371; Sat, 29 Jul 2000 09:52:06 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 29 Jul 2000 09:52:04 -0400 Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id JAA05355; Sat, 29 Jul 2000 09:52:03 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Sat, 29 Jul 2000 09:52:03 -0400 Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id JAA18639 for dist-drums@cs.utk.edu; Sat, 29 Jul 2000 09:52:03 -0400 (EDT) Received: from mailout05.sul.t-online.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id HAA00535; Sat, 29 Jul 2000 07:28:59 -0400 (EDT) Received: from mailout05.sul.t-online.com (194.25.134.82 -> mailout05.sul.t-online.com) by cs.utk.edu (smtpshim v1.0); Sat, 29 Jul 2000 07:28:59 -0400 Received: from fmrl01.sul.t-online.de by mailout05.sul.t-online.com with smtp id 13IUnV-00030R-00; Sat, 29 Jul 2000 13:28:53 +0200 Received: from khms.westfalen.de (340048396503-0001@[62.155.166.4]) by fmrl01.sul.t-online.com with esmtp id 13IUnR-206HTcC; Sat, 29 Jul 2000 13:28:49 +0200 Received: from root by khms.westfalen.de with local-bsmtp (Exim 3.12 #1) id 13IUnQ-000215-03 (Debian); Sat, 29 Jul 2000 13:28:48 +0200 Received: by khms.westfalen.de (CrossPoint v3.12d.kh5 R/C435); 29 Jul 2000 13:27:19 +0200 Date: 29 Jul 2000 13:42:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: drums@cs.utk.edu Message-ID: <7imE0SMHw-B@khms.westfalen.de> In-Reply-To: <20000728144041.2983.qmail@cr.yp.to> Subject: Re: 2nd suggested revision for MUST/SHOULD X-Mailer: CrossPoint v3.12d.kh5 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <20000728144041.2983.qmail@cr.yp.to> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 X-Sender: 340048396503-0001@t-dialin.net List-Unsubscribe: djb@cr.yp.to (D. J. Bernstein) wrote on 28.07.00 in <20000728144041.2983.qmail@cr.yp.to>: > If you're violating section 6, chances are excellent that you're > violating United States antitrust law. In the words of the Federal Trade > Commission, standards must not impose ``construction requirements'' in > place of ``performance requirements.'' From my memory, the "not following 6" issue is *not* about construction requirements, it's about performance requirements not (directly) on the wire - stuff like certain configuration options must (whould, whatever) be available, for example. As far as I can tell, construction requirements have generally been avoided as much as humanly possible by drums. And of course, while I suspect most participants of deums actually agree with this particular requirement, it is also quite obvious to me that the US law in question is completely irrelevant here - Internet standards cannot be subject to US legislation. The UN might have a case. MfG Kai From owner-drums@cs.utk.edu Sat Jul 29 12:15:57 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03495 for ; Sat, 29 Jul 2000 12:15:57 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA10199; Sat, 29 Jul 2000 12:15:44 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 29 Jul 2000 12:15:40 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id MAA10152; Sat, 29 Jul 2000 12:15:40 -0400 (EDT) Received: from altavistausa.com (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id MAA09984; Sat, 29 Jul 2000 12:14:50 -0400 (EDT) Received: from altavistausa.com (209.81.238.131 -> max1-3.newyork.corecomm.net) by cs.utk.edu (smtpshim v1.0); Sat, 29 Jul 2000 12:14:51 -0400 From: Subject: Re: From Lorraine,as promised,I can lower your bill.. Date: Sat, 29 Jul 2000 13:11:12 Message-Id: <178.899009.494013@altavistausa.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" To: undisclosed-recipients:; List-Unsubscribe: Untitled Document


Today, everyone knows the impact of the Internet.
But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!

Uk $.04     France $.06    UAE  $.31    Saudi Arabia $.59     Denmark $.04      Sweden $.05

Click Here Now.

If you do not have flash please go to
www.macromedia.com
to download it.

From owner-drums@cs.utk.edu Sat Jul 29 19:10:53 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02562 for ; Sat, 29 Jul 2000 19:10:52 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA00339; Sat, 29 Jul 2000 19:10:24 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 29 Jul 2000 19:10:18 -0400 Received: from astro.cs.utk.edu (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA00323; Sat, 29 Jul 2000 19:10:18 -0400 (EDT) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by cs.utk.edu (smtpshim v1.0); Sat, 29 Jul 2000 19:10:18 -0400 Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id TAA27986 for dist-drums@cs.utk.edu; Sat, 29 Jul 2000 19:10:17 -0400 (EDT) Received: from munnari.OZ.AU (marvin@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA26502; Sat, 29 Jul 2000 17:25:12 -0400 (EDT) Received: from munnari.OZ.AU (128.250.1.21 -> munnari.OZ.AU) by cs.utk.edu (smtpshim v1.0); Sat, 29 Jul 2000 17:25:14 -0400 Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id VA11481; Sun, 30 Jul 2000 07:24:58 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Charles Lindsey Cc: drums@cs.utk.edu Subject: Re: 2nd suggested revision for MUST/SHOULD In-Reply-To: Your message of "Fri, 28 Jul 2000 20:44:08 +0100." <200007281944.UAA10267@clw.cs.man.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 30 Jul 2000 07:24:57 +1000 Message-Id: <22553.964905897@mundamutti.cs.mu.OZ.AU> List-Unsubscribe: Date: Fri, 28 Jul 2000 20:44:08 +0100 (BST) From: Charles Lindsey Message-ID: <200007281944.UAA10267@clw.cs.man.ac.uk> | We were told in no uncertain terms that we could not do either of those | things. The most we would be allowed to do would be to use "ought" in | lower case for such things (which is what we will likely now do). I have no idea which AD told you that, but either they misunderstood exactly what it was you were asking, or they had lost the plot completely. 2119 is a nice common reference for some terms which (these days) are commonly used in documents - but there has never been, and isn't, any compulsion to use the things, or to refrain from defining your own terms to augment what is in 2119. If anything like that were to be considered as a requirement for the IETF it would have to be agreed by the IETF first - and the way that would be done would be by going through the poisson WG first, and then an IETF last call after that. None of that has happened for any suggestion in any way related to use of 2119, it hasn't even been hinted at. Neither ADs, nor the IESG get to just invent new rules, any time it looks like that is what is happening you should investigate closely - sometimes it is all just a misunderstanding (or an old rule you didn't know about is being applied). Other times the AD/IESG has just lost the plot. kre From owner-drums@cs.utk.edu Sat Jul 29 19:34:57 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05558 for ; Sat, 29 Jul 2000 19:34:57 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id TAA01749; Sat, 29 Jul 2000 19:34:43 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sat, 29 Jul 2000 19:34:43 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id TAA01726; Sat, 29 Jul 2000 19:34:42 -0400 (EDT) Received: from joy.songbird.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id TAA01710; Sat, 29 Jul 2000 19:34:41 -0400 (EDT) Received: from joy.songbird.com (208.184.79.7 -> joy.songbird.com) by cs.utk.edu (smtpshim v1.0); Sat, 29 Jul 2000 19:34:41 -0400 Received: from free.88.106.bayarea.net (free.88.106.bayarea.net [205.219.88.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id QAA19005; Sat, 29 Jul 2000 16:34:22 -0700 X-Authentication-Warning: joy.songbird.com: free.88.106.bayarea.net [205.219.88.106] didn't use HELO protocol Message-Id: <4.3.2.20000729163022.00ccf330@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sat, 29 Jul 2000 16:34:07 -0700 To: Robert Elz From: Dave Crocker Subject: Re: 2nd suggested revision for MUST/SHOULD Cc: Charles Lindsey , drums@cs.utk.edu In-Reply-To: <22553.964905897@mundamutti.cs.mu.OZ.AU> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: At 07:24 AM 7/30/00 +1000, Robert Elz wrote: >If anything like that were to be considered as a requirement for the IETF >it would have to be agreed by the IETF first - and the way that would be >done would be by going through the poisson WG first, and then an IETF >last call after that. None of that has happened for any suggestion in >any way related to use of 2119, it hasn't even been hinted at. Just to underscore this a bit more: The IETF makes firm and universal rules that apply to all working groups, concerning working group PROCESS. There is very damn little about working group technical CONTENT (or even specification syntax) that is mandated. (I'm tempted to say that none is, but exceptions have started to occur, like pressure for strong security and use of unicode, but even these have some flexibility.) Working Groups are presumed to be competent to decide the details appropriate for their situation. Area Directors should, must and do intervene when a working group is out of control. But those are -- unfortunately not as rare as one might like -- boundary conditions. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-drums@cs.utk.edu Sun Jul 30 13:30:29 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19638 for ; Sun, 30 Jul 2000 13:30:28 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id NAA15312; Sun, 30 Jul 2000 13:30:00 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 30 Jul 2000 13:29:48 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id NAA15294; Sun, 30 Jul 2000 13:29:48 -0400 (EDT) Received: from draco.cus.cam.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id NAA15281; Sun, 30 Jul 2000 13:29:45 -0400 (EDT) Received: from draco.cus.cam.ac.uk (131.111.8.18 -> draco.cus.cam.ac.uk) by cs.utk.edu (smtpshim v1.0); Sun, 30 Jul 2000 13:29:46 -0400 Received: from ph10 (helo=localhost) by draco.cus.cam.ac.uk with local-esmtp (Exim 3.16 #3) id 13IwuF-0006ej-00; Sun, 30 Jul 2000 18:29:43 +0100 Date: Sun, 30 Jul 2000 18:29:43 +0100 (BST) From: Philip Hazel To: Kai Henningsen cc: drums@cs.utk.edu Subject: Re: client requests ending \012 In-Reply-To: <7imD-dUmw-B@khms.westfalen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: On 29 Jul 2000, Kai Henningsen wrote: > That is, whenever you enable non-RFC behaviour, make it depend on an > option that says, for example, break_rfc_allow_linefeed_lineends, and > defaults to off. A number (but not all) of the RFC-breaking features of Exim do indeed work that way, and I certainly agree with the principle. -- Philip Hazel University of Cambridge Computing Service, ph10@cus.cam.ac.uk Cambridge, England. Phone: +44 1223 334714. From owner-drums@cs.utk.edu Sun Jul 30 17:13:44 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26459 for ; Sun, 30 Jul 2000 17:13:43 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id RAA28118; Sun, 30 Jul 2000 17:13:28 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Sun, 30 Jul 2000 17:13:27 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id RAA28101; Sun, 30 Jul 2000 17:13:26 -0400 (EDT) Received: from serenity.mcc.ac.uk (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id RAA28088; Sun, 30 Jul 2000 17:13:23 -0400 (EDT) Received: from serenity.mcc.ac.uk (130.88.200.93 -> serenity.mcc.ac.uk) by cs.utk.edu (smtpshim v1.0); Sun, 30 Jul 2000 17:13:23 -0400 Received: from nessie.mcc.ac.uk ([130.88.200.20] ident=root) by serenity.mcc.ac.uk with esmtp (Exim 2.05 #4) id 13J0Of-0009P8-00 for drums@cs.utk.edu; Sun, 30 Jul 2000 22:13:21 +0100 Received: from clw.cs.man.ac.uk (clerew.man.ac.uk [194.66.22.208]) by nessie.mcc.ac.uk (8.9.3/8.8.8) with ESMTP id WAA04979 for ; Sun, 30 Jul 2000 22:13:19 +0100 (BST) (envelope-from root@clw.cs.man.ac.uk) Received: (from root@localhost) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) id UAA18638 for drums@cs.utk.edu; Sun, 30 Jul 2000 20:35:06 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by clw.cs.man.ac.uk (8.9.1b+Sun/8.9.1) with SMTP id UAA18635 for ; Sun, 30 Jul 2000 20:35:06 +0100 (BST) Message-Id: <200007301935.UAA18635@clw.cs.man.ac.uk> Date: Sun, 30 Jul 2000 20:35:05 +0100 (BST) From: Charles Lindsey Reply-To: Charles Lindsey Subject: Re: 2nd suggested revision for MUST/SHOULD To: drums@cs.utk.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=ISO-8859-1 Content-MD5: Uloxko4oP+LHY/EguJ5giA== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id RAA26459 On Sun, 30 Jul 2000 07:24:57 +1000 Robert Elz said... > > Date: Fri, 28 Jul 2000 20:44:08 +0100 (BST) > From: Charles Lindsey > Message-ID: <200007281944.UAA10267@clw.cs.man.ac.uk> > > | We were told in no uncertain terms that we could not do either of those > | things. The most we would be allowed to do would be to use "ought" in > | lower case for such things (which is what we will likely now do). > > I have no idea which AD told you that, but either they misunderstood > exactly what it was you were asking, or they had lost the plot completely.. The request for a ruling was made by our WG Chair to Keith Moore and Patrik Fältström (I believe the Area Directorship was in a hand-over state at that time). New Freed was also brought into the discussions. There were half a dozen or so emails to discuss the issue. > > 2119 is a nice common reference for some terms which (these days) are > commonly used in documents - but there has never been, and isn't, any > compulsion to use the things, or to refrain from defining your own terms > to augment what is in 2119. We were told, amongst other things, that there was at least one IESG member known to be picky about not following 2119. I am still not clear what the objection to introducing OUGHT was, though. Charles H. Lindsey ---------At Home, doing my own thing------------------------ Email: chl@clw.cs.man.ac.uk Web: http://www.cs.man.ac.uk/~chl Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-drums@cs.utk.edu Mon Jul 31 00:34:49 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17049 for ; Mon, 31 Jul 2000 00:34:49 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA09919; Mon, 31 Jul 2000 00:34:30 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 31 Jul 2000 00:34:27 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA09902; Mon, 31 Jul 2000 00:34:27 -0400 (EDT) Received: from horsey.gshapiro.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA09889; Mon, 31 Jul 2000 00:34:24 -0400 (EDT) Received: from horsey.gshapiro.net (209.220.147.178 -> horsey.gshapiro.net) by cs.utk.edu (smtpshim v1.0); Mon, 31 Jul 2000 00:34:25 -0400 Received: from monkeyboy.gshapiro.net (p253.stsn.com [208.32.226.253] (may be forged)) by horsey.gshapiro.net (8.11.0/8.11.0) with ESMTP id e6V4Y8N16489 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (192 bits) verified OK) for ; Sun, 30 Jul 2000 21:34:17 -0700 (PDT) Received: (from gshapiro@localhost) by monkeyboy.gshapiro.net (8.11.0/8.11.0) id e6V4Y4P02609; Sun, 30 Jul 2000 21:34:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14725.444.435491.789547@monkeyboy.gshapiro.net> Date: Sun, 30 Jul 2000 21:34:04 -0700 (PDT) From: Gregory Neil Shapiro To: drums@cs.utk.edu Subject: Minor edits for smtpupd-12 X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid List-Unsubscribe: Content-Transfer-Encoding: 7bit In accordance with the procedures for moving forward, I will be mailing out separate messages for issues I found in reading the document (sorry in advance for what may appear like a mail bomb). However, I am going to send all of the typo corrections together in this single message as I believe they don't need to be tracked, just corrected. If the chair would prefer otherwise, I will repost. 2.3.5 "("labels" in DNS terminology [RFC-DNS]" - Need closing parenthesis after [RFC-DNS]. 2.4 "(e.g., "TO:" and "to:" in the MAIL command)" - Should be RCPT command. 3.5.3 "A server MUST NOT return a 220 code in response to a VRFY or EXPN command unless it has actually verified the address. In particular, a server MUST NOT return 220 if" - The two "220" mentions should be "250". 4.1.2/4.1.3 - The ABNF comments (';' sections) should line up vertically in the definitions for A-d-l and esmtp-value (4.1.2) and IPv6-comp (4.1.3). 4.1.3 "a standardized "tag" that identifies the address syntax, a space, and the address itself," - It's a colon, not a space after the tag. 4.4 - The ABNF comments should use ';' in comment continuations just as is done in other ABNF in the document and should be vertically aligned. The definitions which need this fix are Stamp, TCP-info, Addtl-Link, and Attdl-Protocol. 4.5.1 "the domains for which the SMTP s erver" - s/s erver/server/ D.3 - Step 2: There should not be a blank line between "S: 250 OK" and "C: QUIT" From owner-drums@cs.utk.edu Mon Jul 31 00:37:16 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17566 for ; Mon, 31 Jul 2000 00:37:16 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA10054; Mon, 31 Jul 2000 00:37:03 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 31 Jul 2000 00:37:03 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA10037; Mon, 31 Jul 2000 00:37:02 -0400 (EDT) Received: from horsey.gshapiro.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA10024; Mon, 31 Jul 2000 00:37:00 -0400 (EDT) Received: from horsey.gshapiro.net (209.220.147.178 -> horsey.gshapiro.net) by cs.utk.edu (smtpshim v1.0); Mon, 31 Jul 2000 00:37:00 -0400 Received: from monkeyboy.gshapiro.net (p253.stsn.com [208.32.226.253] (may be forged)) by horsey.gshapiro.net (8.11.0/8.11.0) with ESMTP id e6V4aoN16503 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (192 bits) verified OK) for ; Sun, 30 Jul 2000 21:36:58 -0700 (PDT) Received: (from gshapiro@localhost) by monkeyboy.gshapiro.net (8.11.0/8.11.0) id e6V4alu02616; Sun, 30 Jul 2000 21:36:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14725.606.683615.90633@monkeyboy.gshapiro.net> Date: Sun, 30 Jul 2000 21:36:46 -0700 (PDT) From: Gregory Neil Shapiro To: drums@cs.utk.edu Subject: smtpupd-12: Four letter command verbs X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid List-Unsubscribe: Content-Transfer-Encoding: 7bit Section 2.4 states, "All commands begin with a four letter command verb." SMTP Service Extension for Secure SMTP over TLS (RFC 2487) breaks this rule. In light of this, should section 2.4's text be modified? From owner-drums@cs.utk.edu Mon Jul 31 00:40:18 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18224 for ; Mon, 31 Jul 2000 00:40:17 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA10445; Mon, 31 Jul 2000 00:40:05 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 31 Jul 2000 00:40:04 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA10424; Mon, 31 Jul 2000 00:40:04 -0400 (EDT) Received: from horsey.gshapiro.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA10391; Mon, 31 Jul 2000 00:39:59 -0400 (EDT) Received: from horsey.gshapiro.net (209.220.147.178 -> horsey.gshapiro.net) by cs.utk.edu (smtpshim v1.0); Mon, 31 Jul 2000 00:39:59 -0400 Received: from monkeyboy.gshapiro.net (p253.stsn.com [208.32.226.253] (may be forged)) by horsey.gshapiro.net (8.11.0/8.11.0) with ESMTP id e6V4dnN16517 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (192 bits) verified OK) for ; Sun, 30 Jul 2000 21:39:57 -0700 (PDT) Received: (from gshapiro@localhost) by monkeyboy.gshapiro.net (8.11.0/8.11.0) id e6V4dkI02621; Sun, 30 Jul 2000 21:39:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14725.785.893646.447082@monkeyboy.gshapiro.net> Date: Sun, 30 Jul 2000 21:39:45 -0700 (PDT) From: Gregory Neil Shapiro To: drums@cs.utk.edu Subject: smtpupd-12: MAIL resets state tables and buffers X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid List-Unsubscribe: Content-Transfer-Encoding: 7bit Section 4.1.4 states, "MAIL ... MUST not be sent if a mail transaction is already open" which I agree with. However, the wording in 3.3 and 4.1.12 do not make this restriction and actually read as if: C: MAIL From: S: 250 Ok C: MAIL From: S: 250 Ok should be allowed an implicit RSET would be done after receiving the second MAIL command. Hoping that 4.1.4 is correct, this restriction should be mentioned in sections 3.3 and 4.1.12. From owner-drums@cs.utk.edu Mon Jul 31 00:40:59 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18375 for ; Mon, 31 Jul 2000 00:40:59 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA10590; Mon, 31 Jul 2000 00:40:46 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 31 Jul 2000 00:40:46 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA10573; Mon, 31 Jul 2000 00:40:46 -0400 (EDT) Received: from horsey.gshapiro.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA10560; Mon, 31 Jul 2000 00:40:44 -0400 (EDT) Received: from horsey.gshapiro.net (209.220.147.178 -> horsey.gshapiro.net) by cs.utk.edu (smtpshim v1.0); Mon, 31 Jul 2000 00:40:44 -0400 Received: from monkeyboy.gshapiro.net (p253.stsn.com [208.32.226.253] (may be forged)) by horsey.gshapiro.net (8.11.0/8.11.0) with ESMTP id e6V4eZN16525 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (192 bits) verified OK) for ; Sun, 30 Jul 2000 21:40:42 -0700 (PDT) Received: (from gshapiro@localhost) by monkeyboy.gshapiro.net (8.11.0/8.11.0) id e6V4eVV02628; Sun, 30 Jul 2000 21:40:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14725.831.808285.924968@monkeyboy.gshapiro.net> Date: Sun, 30 Jul 2000 21:40:31 -0700 (PDT) From: Gregory Neil Shapiro To: drums@cs.utk.edu Subject: smtpupd-12: Order of commands X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid List-Unsubscribe: Content-Transfer-Encoding: 7bit Given that section 4.1.4 is "Order of Commands", should it mention the the actual order (MAIL, followed by RCPT, followed by DATA)? From owner-drums@cs.utk.edu Mon Jul 31 00:43:58 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19018 for ; Mon, 31 Jul 2000 00:43:58 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id AAA11103; Mon, 31 Jul 2000 00:43:45 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 31 Jul 2000 00:43:45 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id AAA11086; Mon, 31 Jul 2000 00:43:44 -0400 (EDT) Received: from horsey.gshapiro.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id AAA11015; Mon, 31 Jul 2000 00:43:41 -0400 (EDT) Received: from horsey.gshapiro.net (209.220.147.178 -> horsey.gshapiro.net) by cs.utk.edu (smtpshim v1.0); Mon, 31 Jul 2000 00:43:42 -0400 Received: from monkeyboy.gshapiro.net (p253.stsn.com [208.32.226.253] (may be forged)) by horsey.gshapiro.net (8.11.0/8.11.0) with ESMTP id e6V4hWN16532 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (192 bits) verified OK) for ; Sun, 30 Jul 2000 21:43:40 -0700 (PDT) Received: (from gshapiro@localhost) by monkeyboy.gshapiro.net (8.11.0/8.11.0) id e6V4hTd02632; Sun, 30 Jul 2000 21:43:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14725.1009.660906.108929@monkeyboy.gshapiro.net> Date: Sun, 30 Jul 2000 21:43:29 -0700 (PDT) From: Gregory Neil Shapiro To: drums@cs.utk.edu Subject: smtpupd-12: optional in replies? X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid List-Unsubscribe: Content-Transfer-Encoding: 7bit Section 4.2.1 states, "In many cases the SMTP client then simply needs to search for the reply code followed by at the beginning of a line." Earlier in section 4.2, the document claims the part of the text portion of the reply and is therefore optional (the ABNF backs up this fact). The quoted text from 4.2.1 conflicts with this. From owner-drums@cs.utk.edu Mon Jul 31 22:47:50 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11192 for ; Mon, 31 Jul 2000 22:47:50 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA04980; Mon, 31 Jul 2000 22:47:05 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 31 Jul 2000 22:46:47 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA04776; Mon, 31 Jul 2000 22:46:46 -0400 (EDT) Received: from playground.sun.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA04731; Mon, 31 Jul 2000 22:46:42 -0400 (EDT) Received: from playground.sun.com (192.9.5.5 -> playground.Sun.COM) by cs.utk.edu (smtpshim v1.0); Mon, 31 Jul 2000 22:46:43 -0400 Received: from opal.eng.sun.com (sun-barr.Sun.COM [192.9.9.1]) by playground.sun.com (8.11.0+Sun/8.11.0) with ESMTP id e712ked19880; Mon, 31 Jul 2000 19:46:40 -0700 (PDT) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e712kd1133573; Mon, 31 Jul 2000 19:46:40 -0700 (PDT) Message-Id: <200008010246.e712kd1133573@opal.eng.sun.com> X-Mailer: exmh version 2.1.2 06/08/2000 To: Gregory Neil Shapiro cc: drums@cs.utk.edu Subject: Re: smtpupd-12: optional in replies? X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg In-reply-to: Your message of "Sun, 30 Jul 2000 21:43:29 PDT." <14725.1009.660906.108929@monkeyboy.gshapiro.net> References: <14725.1009.660906.108929@monkeyboy.gshapiro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 Jul 2000 22:46:39 -0400 From: John Beck List-Unsubscribe: Gregory> Section 4.2.1 states, "In many cases the SMTP client then simply Gregory> needs to search for the reply code followed by at the beginning Gregory> of a line." Gregory> Earlier in section 4.2, the document claims the part of the text Gregory> portion of the reply and is therefore optional (the ABNF backs up Gregory> this fact). The quoted text from 4.2.1 conflicts with this. I agree that there are some minor inconsistencies here which should be resolved. 4.2 says: --- An SMTP reply consists of a three digit number (transmitted as three numeric characters) followed by some text unless specified otherwise in this document. ... Formally, a reply is defined to be the sequence: a three-digit code, , one line of text, and , or a multiline reply (as defined in section 4.2.1). Since, in violation of this specification, the text is sometimes not sent, clients which do not receive it SHOULD be prepared to process the code alone (with or without a trailing space character). ... In ABNF, server responses are: Greeting = "220 " Domain [ SP text ] CRLF Reply-line = Reply-code [ SP text ] CRLF --- and 4.2.1 says: --- The format for multiline replies requires that every line, except the last, begin with the reply code, followed immediately by a hyphen, "-" (also known as minus), followed by text. The last line will begin with the reply code, followed immediately by , optionally some text, and . As noted above, servers SHOULD send the if subsequent text is not sent, but clients MUST be prepared for it to be omitted. For example: 123-First line 123-Second line 123-234 text beginning with numbers 123 The last line In many cases the SMTP client then simply needs to search for the reply code followed by at the beginning of a line, and ignore all preceding lines. ... --- If omitting the text is in violation of this spec, doesn't that mean that servers MUST send the and that the [] indicating optional don't belong? Furthermore, why does 4.2 say clients SHOULD be prepared to do one thing yet 4.2.1 say clients MUST be prepared to do something similar? I would personally favor tightening the spec, but consistency is the main thing. If we can reach consensus on what to say, I'll volunteer to come up with some text to say it. -- John From owner-drums@cs.utk.edu Mon Jul 31 22:53:18 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11805 for ; Mon, 31 Jul 2000 22:53:17 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA05482; Mon, 31 Jul 2000 22:53:06 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 31 Jul 2000 22:53:06 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA05460; Mon, 31 Jul 2000 22:53:05 -0400 (EDT) Received: from horsey.gshapiro.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA05444; Mon, 31 Jul 2000 22:53:03 -0400 (EDT) Received: from horsey.gshapiro.net (209.220.147.178 -> horsey.gshapiro.net) by cs.utk.edu (smtpshim v1.0); Mon, 31 Jul 2000 22:53:03 -0400 Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.11.0/8.11.0) id e712r2N27568; Mon, 31 Jul 2000 19:53:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14726.15246.14179.350238@horsey.gshapiro.net> Date: Mon, 31 Jul 2000 19:53:02 -0700 (PDT) From: Gregory Neil Shapiro To: drums@cs.utk.edu Subject: Re: smtpupd-12: MAIL resets state tables and buffers In-Reply-To: <14725.785.893646.447082@monkeyboy.gshapiro.net> References: <14725.785.893646.447082@monkeyboy.gshapiro.net> X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid List-Unsubscribe: Content-Transfer-Encoding: 7bit gshapiro> Section 4.1.4 states, "MAIL ... MUST not be sent if a mail gshapiro> transaction is already open" which I agree with. However, the gshapiro> wording in 3.3 and 4.1.12 do not make this restriction and gshapiro> actually read as if: gshapiro> C: MAIL From: gshapiro> S: 250 Ok gshapiro> C: MAIL From: gshapiro> S: 250 Ok gshapiro> should be allowed an implicit RSET would be done after receiving gshapiro> the second MAIL command. gshapiro> Hoping that 4.1.4 is correct, this restriction should be gshapiro> mentioned in sections 3.3 and 4.1.12. Note that "4.1.12" should be "4.1.1.2" in the last line of my original post. From owner-drums@cs.utk.edu Mon Jul 31 22:54:44 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11996 for ; Mon, 31 Jul 2000 22:54:43 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id WAA05682; Mon, 31 Jul 2000 22:54:32 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 31 Jul 2000 22:54:32 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id WAA05656; Mon, 31 Jul 2000 22:54:31 -0400 (EDT) Received: from horsey.gshapiro.net (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id WAA05619; Mon, 31 Jul 2000 22:54:27 -0400 (EDT) Received: from horsey.gshapiro.net (209.220.147.178 -> horsey.gshapiro.net) by cs.utk.edu (smtpshim v1.0); Mon, 31 Jul 2000 22:54:28 -0400 Received: (from gshapiro@localhost) by horsey.gshapiro.net (8.11.0/8.11.0) id e712sQg27582; Mon, 31 Jul 2000 19:54:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14726.15330.419198.366630@horsey.gshapiro.net> Date: Mon, 31 Jul 2000 19:54:26 -0700 (PDT) From: Gregory Neil Shapiro To: drums@cs.utk.edu Subject: Re: smtpupd-12: Order of commands In-Reply-To: <14725.831.808285.924968@monkeyboy.gshapiro.net> References: <14725.831.808285.924968@monkeyboy.gshapiro.net> X-Mailer: VM 6.75 under 21.2 (beta35) "Nike" XEmacs Lucid List-Unsubscribe: Content-Transfer-Encoding: 7bit gshapiro> Given that section 4.1.4 is "Order of Commands", should it gshapiro> mention the the actual order (MAIL, followed by RCPT, followed by gshapiro> DATA)? Sorry, ignore this comment. I missed the mention in the 9th paragraph. From owner-drums@cs.utk.edu Mon Jul 31 23:14:27 2000 Received: from cs.utk.edu (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14275 for ; Mon, 31 Jul 2000 23:14:27 -0400 (EDT) Received: from localhost (daemon@localhost) by cs.utk.edu with SMTP (cf v2.9s-UTK) id XAA08128; Mon, 31 Jul 2000 23:14:15 -0400 (EDT) Received: by cs.utk.edu (bulk_mailer v1.13); Mon, 31 Jul 2000 23:14:15 -0400 Received: by cs.utk.edu (cf v2.9s-UTK) id XAA08111; Mon, 31 Jul 2000 23:14:14 -0400 (EDT) Received: from playground.sun.com (marvin@localhost) by cs.utk.edu with ESMTP (cf v2.9s-UTK) id XAA08098; Mon, 31 Jul 2000 23:14:11 -0400 (EDT) Received: from playground.sun.com (192.9.5.5 -> playground.Sun.COM) by cs.utk.edu (smtpshim v1.0); Mon, 31 Jul 2000 23:14:11 -0400 Received: from opal.eng.sun.com (sun-barr.Sun.COM [192.9.9.1]) by playground.sun.com (8.11.0+Sun/8.11.0) with ESMTP id e713EAd20144; Mon, 31 Jul 2000 20:14:10 -0700 (PDT) Received: from opal (localhost [127.0.0.1]) by opal.eng.sun.com (8.10.2+Sun/8.10.2) with ESMTP id e713E91133801; Mon, 31 Jul 2000 20:14:09 -0700 (PDT) Message-Id: <200008010314.e713E91133801@opal.eng.sun.com> X-Mailer: exmh version 2.1.2 06/08/2000 To: Gregory Neil Shapiro cc: drums@cs.utk.edu Subject: Re: smtpupd-12: MAIL resets state tables and buffers X-Image-URL: http://playground.sun.com/~jbeck/gif/Misc/john-face.jpg In-reply-to: Your message of "Sun, 30 Jul 2000 21:39:45 PDT." <14725.785.893646.447082@monkeyboy.gshapiro.net> References: <14725.785.893646.447082@monkeyboy.gshapiro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 Jul 2000 23:14:09 -0400 From: John Beck List-Unsubscribe: (Cited text modified per <14726.15246.14179.350238@horsey.gshapiro.net>) Gregory> Section 4.1.4 states, "MAIL ... MUST not be sent if a mail Gregory> transaction is already open" which I agree with. However, the Gregory> wording in 3.3 and 4.1.1.2 do not make this restriction and actually Gregory> read as if: Gregory> C: MAIL From: Gregory> S: 250 Ok Gregory> C: MAIL From: Gregory> S: 250 Ok Gregory> should be allowed an implicit RSET would be done after receiving the Gregory> second MAIL command. Gregory> Hoping that 4.1.4 is correct, this restriction should be mentioned in Gregory> sections 3.3 and 4.1.1.2. Actually, 4.1.1.2 does say: --- In general, the MAIL command may be sent only when no mail transaction is in progress, see section 4.1.4. --- So I think that section is OK. But section 3.3 says: --- This command tells the SMTP-receiver that a new mail transaction is starting and to reset all its state tables and buffers, including any recipients or mail data. --- This sounds like an implied RSET to me. So I propose modifying the first paragraph of 3.3 to: --- There are three steps to SMTP mail transactions. The transaction starts with a MAIL command which gives the sender identification. (In general, the MAIL command may be sent only when no mail transaction is in progress; see section 4.1.4.) A series of one or more RCPT commands follows giving the receiver information. Then a DATA command initiates transfer of the mail data and is terminated by the "end of mail" data indicator, which also confirms the transaction. --- -- John