Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0D3UwQa005836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 20:30:59 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0D3Uwq4005829; Thu, 12 Jan 2012 20:30:58 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from pop3.winserver.com (secure.winserver.com [208.247.131.9]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0D3Uvi9005659 for ; Thu, 12 Jan 2012 20:30:58 -0700 (MST) (envelope-from hsantos@santronics.com) DKIM-Signature: v=1; d=santronics.com; s=tms1; a=rsa-sha1; c=simple/relaxed; t=1326425448; h=Received:Received:Message-ID: Date:From:Organization:To:Subject:List-ID; bh=AgXt/dyr4gmh8iLLQ0 exQwPgpjQ=; b=xwF8Rj8y2Z6M3f30iiGol3ZzRIN3TVDmyaLvuiC6D2YtRU6ocn Vma/D+5hghWm+K1JoVafG5RfSejnV/+IVl/Rzgc0oZCGdyl2ntEvbDXN/PX8nyh6 QnGx40KCXbH0j7uEd+nK6caOULiPY1pIwM5ur5YciM0NKJhgncuOHD9fs= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for ietf-smtp@imc.org; Thu, 12 Jan 2012 22:30:48 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3922299708.36383.964; Thu, 12 Jan 2012 22:30:47 -0500 Message-ID: <4F0FA56A.1050406@santronics.com> Date: Thu, 12 Jan 2012 22:30:50 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "ietf-smtp@imc.org" Subject: Re: Proprietary or non-standard SMTP AUTH mechanisms References: <4F0F431D.3040204@santronics.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Murray S. Kucherawy wrote: > Do they deviate from the SMTP AUTH framework in any way, other than > maybe the method name? No deviation other than a private method name, proprietary, but standard implementation of SMTP AUTH. Just a private/unique method 100% designed for proprietary client entry only. > That's really what I'm after. If you do your own thing with its own > name but still stick to the general base64 and "334" and such, then > it's still compliant as far as the context about which I'm asking. I see your point. We consider it a trade secret and part of our corporate and legal security policy not divulge details, but frankly nothing special other than leveraging a standard protocol method including the client/server base64 SASL challenge/response handshaking and the expected SMTP AUTH reply codes that by design offers the flexibility to offer new methods, including non-standard ones. While off hand at the moment I can't recall any specific method by name, I would swear there are quite a few of others private methods by just seeing some obscure/unknown AUTH names exposed in logs. But I don't known if they were ever proposed I-D or not. -- Sincerely Hector Santos http://www.santronics.com jabber: hector@jabber.isdg.net Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CKrsi6015114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 13:53:54 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0CKrsPa015113; Thu, 12 Jan 2012 13:53:54 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by hoffman.proper.com (8.14.4/8.14.3) with SMTP id q0CKrr3U015108 for ; Thu, 12 Jan 2012 13:53:54 -0700 (MST) (envelope-from csg@alameth.org) Received: (qmail 44986 invoked from network); 12 Jan 2012 20:53:52 -0000 Received: from 67.115.118.5 (HELO clavinova.eng.sonicwall.com) (67.115.118.5) by relay02.pair.com with SMTP; 12 Jan 2012 20:53:52 -0000 X-pair-Authenticated: 67.115.118.5 Message-ID: <4F0F4860.6000602@alameth.org> Date: Thu, 12 Jan 2012 12:53:52 -0800 From: "Carl S. Gutekunst" User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 To: "Murray S. Kucherawy" CC: "ietf-smtp@imc.org" Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt References: <20120110051303.5950.qmail@joyce.lan> <4F0C60FA.5080507@dcrocker.net> <4F0C8033.5060102@dcrocker.net> In-Reply-To: X-Stationery: 0.5.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Murray S. Kucherawy wrote: > If however there are extant or possible implementations that actually queue a message for spam evaluation by some other agent, and that's a totally separate step (even by separate software) than the basic message intake, then it makes sense to denote that as a state in this context. > > My own experience with various MTA implementations is that spam, virus, and other content evaluation is all part of the intake step, before it hits a queue where prolonged delay is likely. That's why this is giving me quite a bit of pause. > Shoveling the message off to another service for evaluation is indeed rare among stand-alone MTAs, but pretty common in cloud-based implementations, especially those that use a forest of single-purpose blades. There are frontends to SpamAssassin that support this as well. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CKglmi014287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 13:42:47 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0CKgldH014286; Thu, 12 Jan 2012 13:42:47 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CKgklT014281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 12 Jan 2012 13:42:46 -0700 (MST) (envelope-from msk@cloudmark.com) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 12 Jan 2012 12:42:38 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 12 Jan 2012 12:42:44 -0800 From: "Murray S. Kucherawy" To: "ietf-smtp@imc.org" Date: Thu, 12 Jan 2012 12:42:43 -0800 Subject: RE: Proprietary or non-standard SMTP AUTH mechanisms Thread-Topic: Proprietary or non-standard SMTP AUTH mechanisms Thread-Index: AczRadcs5Cwcs3+qQ4mkOtKv8aArVgAAKSXQ Message-ID: References: <4F0F431D.3040204@santronics.com> In-Reply-To: <4F0F431D.3040204@santronics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by hoffman.proper.com id q0CKgklS014282 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-smtp@mail.imc.org [mailto:owner-ietf-smtp@mail.imc.org] On Behalf Of Hector Santos > Sent: Thursday, January 12, 2012 12:31 PM > To: ietf-smtp@imc.org > Cc: ietf-smtp@imc.org > Subject: Re: Proprietary or non-standard SMTP AUTH mechanisms > > We have a few proprietary SMTP AUTH mechanism. The design goal was to > lower the development overhead for coding the standard mechanisms, or > the need for encryption and SSL libraries for our proprietary mail/user > clients. For an example, the GUI Frontend Navigator client: > > http://www.winserver.com/public/wcnavigator.wct > > provided by our operators to their users, uses an internal SMTP AUTH > mechanism to send mail to its online backend connected local server > only. In the past, only IP was used, but with dynamic IPs or mail > bot clients moved around, SMTP AUTH helps here. Do they deviate from the SMTP AUTH framework in any way, other than maybe the method name? That's really what I'm after. If you do your own thing with its own name but still stick to the general base64 and "334" and such, then it's still compliant as far as the context about which I'm asking. -MSK Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CKej2J014191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 13:40:46 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0CKejs5014190; Thu, 12 Jan 2012 13:40:45 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CKejpZ014184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 12 Jan 2012 13:40:45 -0700 (MST) (envelope-from msk@cloudmark.com) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 12 Jan 2012 12:40:37 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 12 Jan 2012 12:40:44 -0800 From: "Murray S. Kucherawy" To: "ietf-smtp@imc.org" Date: Thu, 12 Jan 2012 12:40:43 -0800 Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Topic: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Index: AczRYvyCz+yNHPKgTkyvwfu5EUkfUQAB1v2w Message-ID: References: <20120110051303.5950.qmail@joyce.lan> <4F0C60FA.5080507@dcrocker.net> <4F0C8033.5060102@dcrocker.net> <4F0F38C1.600@alameth.org> In-Reply-To: <4F0F38C1.600@alameth.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id q0CKejpY014185 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Carl S. Gutekunst [mailto:csg@alameth.org] > Sent: Thursday, January 12, 2012 11:47 AM > To: Robert A. Rosenberg > Cc: Murray S. Kucherawy; ietf-smtp@imc.org > Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt > > Offline or deferred processing for potential threats or detecting > policy violations is pretty common. But the keyword "spam" is a > judgment, not a reason. How about verbs like "study", "analyze", or > even "filter"? I was thinking about "content-eval" as a generic, and then the implementation could use a comment after that to be more specific, e.g. "state content-eval (spam checking)". The ABNF already allows this. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CKdlwb014161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 13:39:47 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0CKdlHk014160; Thu, 12 Jan 2012 13:39:47 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CKdkIg014155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 12 Jan 2012 13:39:47 -0700 (MST) (envelope-from msk@cloudmark.com) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 12 Jan 2012 12:39:38 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 12 Jan 2012 12:39:45 -0800 From: "Murray S. Kucherawy" To: "ietf-smtp@imc.org" Date: Thu, 12 Jan 2012 12:39:44 -0800 Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Topic: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Index: AczRXoPD8F/MFpqES9iCMYSHkBaYQwACidfg Message-ID: References: <20120110051303.5950.qmail@joyce.lan> <4F0C60FA.5080507@dcrocker.net> <4F0C8033.5060102@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id q0CKdlIf014156 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Robert A. Rosenberg [mailto:hal9001@panix.com] > Sent: Thursday, January 12, 2012 11:11 AM > To: Murray S. Kucherawy > Cc: ietf-smtp@imc.org > Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt > > I was thinking of checking the message to see if it were possible spam. > You might have some cases where your processing can not do an immediate > SPAM/HAM determination but have some delay in making that decision. > Thus the spam state while the message is delayed while the extended > check is being done. OK, this makes more sense. What I'd seen so far suggested using "state spam" to indicate that the agent adding the field tagged it as spam. The intent here is to show a transition into a processing state. The particular impact I'm hoping to enable is the ability to see why there was a delay between timestamps. If however there are extant or possible implementations that actually queue a message for spam evaluation by some other agent, and that's a totally separate step (even by separate software) than the basic message intake, then it makes sense to denote that as a state in this context. My own experience with various MTA implementations is that spam, virus, and other content evaluation is all part of the intake step, before it hits a queue where prolonged delay is likely. That's why this is giving me quite a bit of pause. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CKVTof013287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 13:31:29 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0CKVT8m013286; Thu, 12 Jan 2012 13:31:29 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ntbbs.winserver.com (secure.winserver.com [208.247.131.9]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CKVS7i013281 for ; Thu, 12 Jan 2012 13:31:28 -0700 (MST) (envelope-from hsantos@santronics.com) DKIM-Signature: v=1; d=santronics.com; s=tms1; a=rsa-sha1; c=simple/relaxed; t=1326400282; h=Received:Received:Message-ID: Date:From:Organization:Subject:To:List-ID; bh=IYSmvnzDDui8hGfTqS siWy3e/tY=; b=wlGKCBMjyZkq+CGQcqduzqgZnwsLESje4mFQk/dWPzWhv1E1Ed E6oV6q4Mxu7SyOAGgFXMfoUgk15yg0lUTdtkkmoTezxenXaPVBuGdAGnAi9Qr+O1 8QXFSQ/NsDEoTTFy2aP5mBsZQQqjKXjzgN0L4MIBfPXcew9et2cv1Vl90= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for ietf-smtp@imc.org; Thu, 12 Jan 2012 15:31:22 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3897134407.36383.3544; Thu, 12 Jan 2012 15:31:21 -0500 Message-ID: <4F0F431D.3040204@santronics.com> Date: Thu, 12 Jan 2012 15:31:25 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 CC: "ietf-smtp@imc.org" Subject: Re: Proprietary or non-standard SMTP AUTH mechanisms References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: ietf-smtp@imc.org Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: We have a few proprietary SMTP AUTH mechanism. The design goal was to lower the development overhead for coding the standard mechanisms, or the need for encryption and SSL libraries for our proprietary mail/user clients. For an example, the GUI Frontend Navigator client: http://www.winserver.com/public/wcnavigator.wct provided by our operators to their users, uses an internal SMTP AUTH mechanism to send mail to its online backend connected local server only. In the past, only IP was used, but with dynamic IPs or mail bot clients moved around, SMTP AUTH helps here. Murray S. Kucherawy wrote: > Are there any known proprietary or other non-standard SMTP AUTH mechanisms that deviate from the syntax specified un RFC4954? > > For example, is there an unofficial SMTP AUTH mechanism that allows unencoded binary data in the challenges or responses? A vendor controlling both the client and the server could get away with something like that, but something standards-based analyzing that traffic might be confused by it. > > Thanks, > -MSK > > -- Sincerely Hector Santos http://www.santronics.com jabber: hector@jabber.isdg.net Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CJlF53008644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 12:47:15 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0CJlFb5008643; Thu, 12 Jan 2012 12:47:15 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by hoffman.proper.com (8.14.4/8.14.3) with SMTP id q0CJlEnW008638 for ; Thu, 12 Jan 2012 12:47:14 -0700 (MST) (envelope-from csg@alameth.org) Received: (qmail 9881 invoked from network); 12 Jan 2012 19:47:13 -0000 Received: from 67.115.118.5 (HELO clavinova.eng.sonicwall.com) (67.115.118.5) by relay02.pair.com with SMTP; 12 Jan 2012 19:47:13 -0000 X-pair-Authenticated: 67.115.118.5 Message-ID: <4F0F38C1.600@alameth.org> Date: Thu, 12 Jan 2012 11:47:13 -0800 From: "Carl S. Gutekunst" User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 To: "Robert A. Rosenberg" CC: "Murray S. Kucherawy" , "ietf-smtp@imc.org" Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt References: <20120110051303.5950.qmail@joyce.lan> <4F0C60FA.5080507@dcrocker.net> <4F0C8033.5060102@dcrocker.net> In-Reply-To: X-Stationery: 0.5.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Robert A. Rosenberg wrote: >> If a "spam" state were to exist, what are the conditions under which >> it would be released for processing and delivery? >> > > I was thinking of checking the message to see if it were possible > spam. You might have some cases where your processing can not do an > immediate SPAM/HAM determination but have some delay in making that > decision. Thus the spam state while the message is delayed while the > extended check is being done. Offline or deferred processing for potential threats or detecting policy violations is pretty common. But the keyword "spam" is a judgment, not a reason. How about verbs like "study", "analyze", or even "filter"? ("Weigh" and "adjudge" are arguable more accurate, except no one would have idea what they mean. Which is heavier, ham or spam?) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CJFFh2005869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 12:15:15 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0CJFF1o005868; Thu, 12 Jan 2012 12:15:15 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CJFEkf005863 for ; Thu, 12 Jan 2012 12:15:14 -0700 (MST) (envelope-from hal9001@panix.com) Received: from [192.168.1.11] (ool-457198e0.dyn.optonline.net [69.113.152.224]) by mailbackend.panix.com (Postfix) with ESMTP id A44F52E9D5; Thu, 12 Jan 2012 14:15:13 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20120110051303.5950.qmail@joyce.lan> <4F0C60FA.5080507@dcrocker.net> <4F0C8033.5060102@dcrocker.net> X-Mailer: Eudora for Mac OS X 6.2.4 (MacOS 10.5.8) Date: Thu, 12 Jan 2012 14:11:21 -0500 To: "Murray S. Kucherawy" From: "Robert A. Rosenberg" Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt Cc: "ietf-smtp@imc.org" Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 22:30 -0800 on 01/11/2012, Murray S. Kucherawy wrote about Re: FW: I-D Action: draft-kucherawy-received-state-00.txt: > > -----Original Message----- >> From: Robert A. Rosenberg [mailto:hal9001@panix.com] >> Sent: Wednesday, January 11, 2012 9:20 PM >> To: dcrocker@bbiw.net >> Cc: Murray S. Kucherawy; ietf-smtp@imc.org; Dave CROCKER >> Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt >>  >> That depends on the meaning of the SPAM state. If it means checking if >> the message IS spam that is different from it meaning that the message >> has been identified AS spam. You are treating as the latter when the >> intent might be the former (ie: The check might introduce a delay in >> processing the message so you are marking it to show the reason for the >> delay). > >I don't know what it means for a message to be in a "spam" state. > >A message in a "hold for moderation" state means it's stuck in a >queue until a moderator does something with it. > >A message in a "quarantine" state means it's quarantined, >inaccessible, until an operator brings it out or destroys it. > >A message in a "timed" state means it's held in a queue until a >certain release time arrives. > >All of these are states that cause processing delays, but ultimately >from which the message will be released. > >If a "spam" state were to exist, what are the conditions under which >it would be released for processing and delivery? > >-MSK I was thinking of checking the message to see if it were possible spam. You might have some cases where your processing can not do an immediate SPAM/HAM determination but have some delay in making that decision. Thus the spam state while the message is delayed while the extended check is being done. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CHV322094765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 10:31:03 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0CHV3k7094764; Thu, 12 Jan 2012 10:31:03 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CHV2aT094759 for ; Thu, 12 Jan 2012 10:31:02 -0700 (MST) (envelope-from alexey.melnikov@isode.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1326389460; d=isode.com; s=selector; i=@isode.com; bh=ZDb/zcM2fLXpsNrb8X/gjwYI9LvbIduvVBUWW4ZvTFs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=FCAgATLNMELMfkWHDtwN1Lb2a95xvDNNk/2UOPNS/P4jPRTGfP13bMk1wf9KsOQpwQg2Ab vE9oS+Iakeu+mYAXUBedAgblIgkohNt4XQV1AgzdIJgqs5+Wrk5QuDJQD0KGE+vSsiVPWb Iq8PmaoAZOzAuGLITBEGwZx4io8eSuo=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 12 Jan 2012 17:31:00 +0000 Message-ID: <4F0F18E7.2050606@isode.com> Date: Thu, 12 Jan 2012 17:31:19 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: John C Klensin CC: "Murray S. Kucherawy" , ietf-smtp@imc.org Subject: Re: Proprietary or non-standard SMTP AUTH mechanisms References: <4F0EB21D.5050206@isode.com> <30353C7ACB1879BF600FAB8B@PST.JCK.COM> In-Reply-To: <30353C7ACB1879BF600FAB8B@PST.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 12/01/2012 16:14, John C Klensin wrote: > --On Thursday, January 12, 2012 10:12 +0000 Alexey Melnikov > wrote: > >>> For example, is there an unofficial SMTP AUTH mechanism that >>> allows unencoded binary data in the challenges or responses? >>> A vendor controlling both the client and the server could >>> get away with something like that, but something >>> standards-based analyzing that traffic might be confused by >>> it. >>> >> All SASL exchange data in SMTP must be base64 encoded, so no >> unencoded binary data can ever occur if IETF standards are >> followed. > Alexey, Hi John, > Yes, but I don't think that was Murray's question. SMTP AUTH > was originally designed in the absence of SASL. We hope all > non-SASL applications/implementations have disappeared, but I > wouldn't count on it. When we designed CRAM-MD5, we were at > least vaguely aware of an assortment of cookie/ shared > not-very-secret approaches floating around, some of which relied > on binary data. I hope those have disappeared too, but I have > no way to verify that they have. > > What people forget as they quibble about the security properties > of CRAM-MD5 was that it was specified precisely to illustrate > that something was possible that would not require much more > server effort and support than plain-text passwords (a > requirement that Kerberos and assorted digital signature plans > could not satisfy) and that would be at least a tad more secure > against eavesdropping than either those passwords or [other] > cleartext shared secrets. Our goal wasn't "high security > mechanism" (we knew how to do those), but "significantly better > than clear text" and that largely to prove a point in the IETF. > > But security by obscurity always has some appeal, especially > when eavesdropping in the transmission channel are not believed > to be issues, and old SMTP implementations tend to linger around > as long as they are still perceived as working (e.g., no new > feature appears that they don't have and that is considered > important). So I don't have much confidence that all of those > old cases have been eliminated and Murray's question, at least > as I understood it, starts me muttering about proving universal > negatives. While what you say is possible (AUTH= hack is a proof), the requirement for base64 encoding AUTH exchange comes from draft-myers-smtp-auth-00.txt dated April 1995 (which later became RFC 2554). So it looks like binary data was never allowed in SMTP AUTH. (In general SASL mechanisms can exchange arbitrary binary data. How such data is transfered on the wire is defined by protocols that use SASL.) Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CGEVEJ085738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 09:14:31 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0CGEVcl085737; Thu, 12 Jan 2012 09:14:31 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CGESUu085731 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 12 Jan 2012 09:14:30 -0700 (MST) (envelope-from john-ietf@jck.com) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1RlNID-000AnX-33; Thu, 12 Jan 2012 11:14:21 -0500 Date: Thu, 12 Jan 2012 11:14:20 -0500 From: John C Klensin To: Alexey Melnikov , "Murray S. Kucherawy" cc: ietf-smtp@imc.org Subject: Re: Proprietary or non-standard SMTP AUTH mechanisms Message-ID: <30353C7ACB1879BF600FAB8B@PST.JCK.COM> In-Reply-To: <4F0EB21D.5050206@isode.com> References: <4F0EB21D.5050206@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Thursday, January 12, 2012 10:12 +0000 Alexey Melnikov wrote: >> For example, is there an unofficial SMTP AUTH mechanism that >> allows unencoded binary data in the challenges or responses? >> A vendor controlling both the client and the server could >> get away with something like that, but something >> standards-based analyzing that traffic might be confused by >> it. >> > All SASL exchange data in SMTP must be base64 encoded, so no > unencoded binary data can ever occur if IETF standards are > followed. Alexey, Yes, but I don't think that was Murray's question. SMTP AUTH was originally designed in the absence of SASL. We hope all non-SASL applications/implementations have disappeared, but I wouldn't count on it. When we designed CRAM-MD5, we were at least vaguely aware of an assortment of cookie/ shared not-very-secret approaches floating around, some of which relied on binary data. I hope those have disappeared too, but I have no way to verify that they have. What people forget as they quibble about the security properties of CRAM-MD5 was that it was specified precisely to illustrate that something was possible that would not require much more server effort and support than plain-text passwords (a requirement that Kerberos and assorted digital signature plans could not satisfy) and that would be at least a tad more secure against eavesdropping than either those passwords or [other] cleartext shared secrets. Our goal wasn't "high security mechanism" (we knew how to do those), but "significantly better than clear text" and that largely to prove a point in the IETF. But security by obscurity always has some appeal, especially when eavesdropping in the transmission channel are not believed to be issues, and old SMTP implementations tend to linger around as long as they are still perceived as working (e.g., no new feature appears that they don't have and that is considered important). So I don't have much confidence that all of those old cases have been eliminated and Murray's question, at least as I understood it, starts me muttering about proving universal negatives. john Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CACQGx046409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jan 2012 03:12:26 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0CACQ2t046407; Thu, 12 Jan 2012 03:12:26 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0CACOiF046402 for ; Thu, 12 Jan 2012 03:12:25 -0700 (MST) (envelope-from alexey.melnikov@isode.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1326363143; d=isode.com; s=selector; i=@isode.com; bh=TNNtC+49L0+mo7ICXezhZ2lUoswrelm5+Yrhnfa9XHQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=iR/lcMQWxyIw3n5BMD2MmJFZx2HOM8eqUS1nhCOFe+hsJdZ09tvOK0t1M8cd/zCWlHqF93 +CXBjihr3+3bula5dj2glUe6iw5rIu4t0DBZmqRFeNDHD/cdNvluJa2SRt/pB/wLULfBsu cXGD7AveP44poLLRYmKJ7LQJQeD+7zU=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 12 Jan 2012 10:12:23 +0000 Message-ID: <4F0EB21D.5050206@isode.com> Date: Thu, 12 Jan 2012 10:12:45 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: "Murray S. Kucherawy" CC: "ietf-smtp@imc.org" Subject: Re: Proprietary or non-standard SMTP AUTH mechanisms References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080806010906080908020501" Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------080806010906080908020501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 11/01/2012 23:46, Murray S. Kucherawy wrote: > > Are there any known proprietary or other non-standard SMTP AUTH > mechanisms that deviate from the syntax specified un RFC4954? > Not that I know of. > > For example, is there an unofficial SMTP AUTH mechanism that allows > unencoded binary data in the challenges or responses? A vendor > controlling both the client and the server could get away with > something like that, but something standards-based analyzing that > traffic might be confused by it. > All SASL exchange data in SMTP must be base64 encoded, so no unencoded binary data can ever occur if IETF standards are followed. --------------080806010906080908020501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 11/01/2012 23:46, Murray S. Kucherawy wrote:

Are there any known proprietary or other non-standard SMTP AUTH mechanisms that deviate from the syntax specified un RFC4954?

Not that I know of.

 For example, is there an unofficial SMTP AUTH mechanism that allows unencoded binary data in the challenges or responses?  A vendor controlling both the client and the server could get away with something like that, but something standards-based analyzing that traffic might be confused by it.

All SASL exchange data in SMTP must be base64 encoded, so no unencoded binary data can ever occur if IETF standards are followed.

--------------080806010906080908020501-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0C6UBEN025075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 23:30:11 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0C6UBB4025074; Wed, 11 Jan 2012 23:30:11 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0C6UAYh025068 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Jan 2012 23:30:10 -0700 (MST) (envelope-from msk@cloudmark.com) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 11 Jan 2012 22:30:02 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 11 Jan 2012 22:30:09 -0800 From: "Murray S. Kucherawy" To: "ietf-smtp@imc.org" Date: Wed, 11 Jan 2012 22:30:08 -0800 Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Topic: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Index: AczQ8wwfJq+Jrq47SWGlqd97YAYvEwAADyoQ Message-ID: References: <20120110051303.5950.qmail@joyce.lan> <4F0C60FA.5080507@dcrocker.net> <4F0C8033.5060102@dcrocker.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id q0C6UAYg025070 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Robert A. Rosenberg [mailto:hal9001@panix.com] > Sent: Wednesday, January 11, 2012 9:20 PM > To: dcrocker@bbiw.net > Cc: Murray S. Kucherawy; ietf-smtp@imc.org; Dave CROCKER > Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt > > That depends on the meaning of the SPAM state. If it means checking if > the message IS spam that is different from it meaning that the message > has been identified AS spam. You are treating as the latter when the > intent might be the former (ie: The check might introduce a delay in > processing the message so you are marking it to show the reason for the > delay). I don't know what it means for a message to be in a "spam" state. A message in a "hold for moderation" state means it's stuck in a queue until a moderator does something with it. A message in a "quarantine" state means it's quarantined, inaccessible, until an operator brings it out or destroys it. A message in a "timed" state means it's held in a queue until a certain release time arrives. All of these are states that cause processing delays, but ultimately from which the message will be released. If a "spam" state were to exist, what are the conditions under which it would be released for processing and delivery? -MSK Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0C6Pvn4024726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 23:25:57 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0C6PvJ5024725; Wed, 11 Jan 2012 23:25:57 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0C6Pu1Y024713 for ; Wed, 11 Jan 2012 23:25:57 -0700 (MST) (envelope-from hal9001@panix.com) Received: from [192.168.1.11] (ool-457198e0.dyn.optonline.net [69.113.152.224]) by mailbackend.panix.com (Postfix) with ESMTP id 1FD552E2CE; Thu, 12 Jan 2012 01:25:56 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <4F0C8033.5060102@dcrocker.net> References: <20120110051303.5950.qmail@joyce.lan> <4F0C60FA.5080507@dcrocker.net> <4F0C8033.5060102@dcrocker.net> X-Mailer: Eudora for Mac OS X 6.2.4 (MacOS 10.5.8) Date: Thu, 12 Jan 2012 00:20:07 -0500 To: dcrocker@bbiw.net From: "Robert A. Rosenberg" Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt Cc: "Murray S. Kucherawy" , "ietf-smtp@imc.org" , Dave CROCKER Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 10:15 -0800 on 01/10/2012, Dave CROCKER wrote about Re: FW: I-D Action: draft-kucherawy-received-state-00.txt: >On 1/10/2012 10:02 AM, Murray S. Kucherawy wrote: >>>> Those aren't queueing states though; they're metadata about the message. >>> >>> I think I don't understand what this means. >> >> The example given was "spam", which strikes me as a label attached to a >> message somehow (perhaps as metadata) and not a phase of message handling >> enroute to its destination. > >This suggests a confusion about the clause. Does it provide a label >to explain >the specific Received field or does it label the message? I think that having >it used as a label for the message is just plain wrong. Put those >somewhere else. That depends on the meaning of the SPAM state. If it means checking if the message IS spam that is different from it meaning that the message has been identified AS spam. You are treating as the latter when the intent might be the former (ie: The check might introduce a delay in processing the message so you are marking it to show the reason for the delay). Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0BNkppF086217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 16:46:51 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0BNkp8f086215; Wed, 11 Jan 2012 16:46:51 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0BNko9n086207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Jan 2012 16:46:51 -0700 (MST) (envelope-from msk@cloudmark.com) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 11 Jan 2012 15:46:42 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 11 Jan 2012 15:46:49 -0800 From: "Murray S. Kucherawy" To: "ietf-smtp@imc.org" Date: Wed, 11 Jan 2012 15:46:48 -0800 Subject: Proprietary or non-standard SMTP AUTH mechanisms Thread-Topic: Proprietary or non-standard SMTP AUTH mechanisms Thread-Index: AczQu0jkZqAF++8pSsynBPwUENrSbg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F5833273385BB34F99288B3648C4F06F19C6C1582FEXCHC2corpclo_" MIME-Version: 1.0 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --_000_F5833273385BB34F99288B3648C4F06F19C6C1582FEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are there any known proprietary or other non-standard SMTP AUTH mechanisms = that deviate from the syntax specified un RFC4954? For example, is there an unofficial SMTP AUTH mechanism that allows unencod= ed binary data in the challenges or responses? A vendor controlling both t= he client and the server could get away with something like that, but somet= hing standards-based analyzing that traffic might be confused by it. Thanks, -MSK --_000_F5833273385BB34F99288B3648C4F06F19C6C1582FEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are there any kn= own proprietary or other non-standard SMTP AUTH mechanisms that deviate fro= m the syntax specified un RFC4954?

=  

For example, is there an unofficial SM= TP AUTH mechanism that allows unencoded binary data in the challenges or re= sponses?  A vendor controlling both the client and the server could ge= t away with something like that, but something standards-based analyzing th= at traffic might be confused by it.

 

Thanks,

-MSK

 

= --_000_F5833273385BB34F99288B3648C4F06F19C6C1582FEXCHC2corpclo_-- Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0BLvNpX074703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 14:57:23 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0BLvNwv074702; Wed, 11 Jan 2012 14:57:23 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mail.catinthebox.net (ntbbs.winserver.com [208.247.131.9]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0BLvMVe074695 for ; Wed, 11 Jan 2012 14:57:22 -0700 (MST) (envelope-from hsantos@santronics.com) DKIM-Signature: v=1; d=santronics.com; s=tms1; a=rsa-sha1; c=simple/relaxed; t=1326319031; h=Received:Received:Message-ID: Date:From:Organization:To:Subject:List-ID; bh=00d5JXSKKI+Z0nJhiv DrDUmTx1g=; b=slPKRDuVIAVSUarsH1/y5ecgoKgv/wadoCQcLxHKDvVqO6kEmS 23AmPBJQX8HBJsShYO+RlMRJ9p/68wOe1mFFumYbIbC/jrYunp010Uj8Km29C0uY OWuQvGeBGSsCqilrr28aLrHqO4+VXrx3s+ml5KBtoeFLA6/1+C2t8VSmQ= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for ietf-smtp@imc.org; Wed, 11 Jan 2012 16:57:11 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3815885124.33109.3436; Wed, 11 Jan 2012 16:57:11 -0500 Message-ID: <4F0E05B1.9020801@santronics.com> Date: Wed, 11 Jan 2012 16:57:05 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: ietf-smtp@imc.org Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt References: <20120110172624.6054.qmail@joyce.lan> <4F0C7B02.5030406@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tony Finch wrote: >> The problem with this is lack of flexibility. > > Which is why the Received: header can be extended with other clauses for > other purposes. We don't need multiple layers of genericity here. +1, ideal, but will most likely required the larger code change, in logic flow and when to add the Received since it has to be at the top for the current hop. -- Sincerely Hector Santos http://www.santronics.com jabber: hector@jabber.isdg.net Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0BGCMvZ044706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 09:12:23 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0BGCMi8044705; Wed, 11 Jan 2012 09:12:22 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0BGCMMs044699 for ; Wed, 11 Jan 2012 09:12:22 -0700 (MST) (envelope-from fanf2@hermes.cam.ac.uk) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:34426) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Rl0mg-0007wj-pg (Exim 4.72) (return-path ); Wed, 11 Jan 2012 16:12:18 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Rl0mf-0002oD-Vi (Exim 4.67) (return-path ); Wed, 11 Jan 2012 16:12:17 +0000 Date: Wed, 11 Jan 2012 16:12:17 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: dcrocker@bbiw.net cc: John Levine , ietf-smtp@imc.org Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt In-Reply-To: <4F0C7B02.5030406@dcrocker.net> Message-ID: References: <20120110172624.6054.qmail@joyce.lan> <4F0C7B02.5030406@dcrocker.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dave CROCKER wrote: > On 1/10/2012 9:26 AM, John Levine wrote: > > > > Well, yeah, but there are a lot of kind of states other than queueing > > states. That's why I'd suggest a keyword that tells you this is about > > queues or delays or something. > > This puts the specific semantic into the definition of the clause, rather than > the value used in the clause. Just like the other Received: header clauses. > The problem with this is lack of flexibility. Which is why the Received: header can be extended with other clauses for other purposes. We don't need multiple layers of genericity here. Tony. -- f.anthony.n.finch http://dotat.at/ Lundy, Fastnet, Irish Sea, Shannon: Southwest, veering west or northwest, 4 or 5, increasing 6 or 7 for a time in Irish Sea and Shannon. Slight or moderate, occasionally rough in Fastnet and Shannon. Occasional rain. Moderate or good. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0BG60hN043809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jan 2012 09:06:00 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0BG60H2043808; Wed, 11 Jan 2012 09:06:00 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ppsw-51.csi.cam.ac.uk (ppsw-51.csi.cam.ac.uk [131.111.8.151]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0BG5wUh043795 for ; Wed, 11 Jan 2012 09:05:59 -0700 (MST) (envelope-from fanf2@hermes.cam.ac.uk) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:50944) by ppsw-51.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1Rl0gW-0003Qw-Xq (Exim 4.72) (return-path ); Wed, 11 Jan 2012 16:05:56 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1Rl0gW-0001mf-7H (Exim 4.67) (return-path ); Wed, 11 Jan 2012 16:05:56 +0000 Date: Wed, 11 Jan 2012 16:05:56 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: John Levine cc: ietf-smtp@imc.org, msk@cloudmark.com Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt In-Reply-To: <20120110051303.5950.qmail@joyce.lan> Message-ID: References: <20120110051303.5950.qmail@joyce.lan> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John Levine wrote: > > Other nits: if this is really about deliberate delays, I'd suggest > using a term like "queued" or "delay" or "hold" rather than "state". > I can think of states that might be interesting but don't involve a > delay, e.g. characterized as spam, or downcoded from 8 bits to 6 bits. I agree and I have previously made the same suggestion. Tony. -- f.anthony.n.finch http://dotat.at/ Tyne, Dogger, Fisher, German Bight, Humber: West or southwest, veering northwest later, 4 or 5, increasing 6 to gale 8, occasionally severe gale 9 in Fisher, perhaps severe gale 9 later in Tyne, Dogger and German Bight. Moderate or rough, occasionally very rough. Rain or squally showers. Moderate or good. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AKMoEl029554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 13:22:50 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0AKMo0s029553; Tue, 10 Jan 2012 13:22:50 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from mx10.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AKMnRF029548 for ; Tue, 10 Jan 2012 13:22:49 -0700 (MST) (envelope-from R.E.Sonneveld@sonnection.nl) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LXL00G00MUCYQ00@hydrogen.mailtransaction.com>; Tue, 10 Jan 2012 21:22:48 +0100 (CET) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LXL009ACNA06H00@hydrogen.mailtransaction.com>; Tue, 10 Jan 2012 21:22:48 +0100 (CET) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LXL00O0XNA0A900@lion.sonnection.nl> for ietf-smtp@imc.org; Tue, 10 Jan 2012 21:22:48 +0100 (CET) Message-id: <4F0C9F64.7000701@sonnection.nl> Date: Tue, 10 Jan 2012 21:28:20 +0100 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: dcrocker@bbiw.net Cc: Dave CROCKER , "Murray S. Kucherawy" , "ietf-smtp@imc.org" Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt References: <20120110051303.5950.qmail@joyce.lan> <4F0C60FA.5080507@dcrocker.net> <4F0C8033.5060102@dcrocker.net> <4F0C8B0C.7070307@dcrocker.net> In-reply-to: <4F0C8B0C.7070307@dcrocker.net> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1326226968; bh=8NCf/F6LPfcY0dnGdt2qX+UPoo/WEwOHlh/IwFvorik=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=EOqDsEWJgiUnPBEaJVwB32qo2t1RDOnGbOtVtCxocY1tyERib7U+9Ff9+YP/KexLZ lDEtsAEImxbizl1uhcON4m4Q7KzHvJt0jde1I4S7QFVQwApO21hffYOdBDos/YmDj1 EuXj5JwxkuS6DSt0qNLI85jMDEo6GrDpW5b856E4= X-DKIM: OpenDKIM Filter v2.1.3 hydrogen.mailtransaction.com 0LXL00G00MUCYQ00 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 1/10/12 8:01 PM, Dave CROCKER wrote: > > > > On 1/10/2012 10:21 AM, Murray S. Kucherawy wrote: >>> OK. Putting this simplistically, we already have lots of Received: >>> fields >>> being generated and we should have a clause value that covers this >>> probably-uninteresting set? I suggest "normal" or somesuch, not >>> "none". >>> The message, /is/ after all, making a transition. Whatever state or >>> queue >>> it just entered, it does exist. >> >> John suggested what's essentially a no-op state name to accommodate >> those >> implementations that, in supporting this, will always want to put >> some kind >> of state clause down, and that seems a decent idea to me. >> >> "normal" would be fine with me too. > > > Doing what sales folk call "selling past the sale" I'll note that > there is no such thing as a no-op, since the presence of the Received: > field means that some sort of 'op' took place. So the question is > what the "nature" of the op is. The "nature" of the op (or no-op) is 'received'. I.e. the message was received. A state of 'received' more or less duplicates the header name (Received), but if there needs to be a no-op state, then let's call it just 'received'. /rolf Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AJIqvZ024544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 12:18:52 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0AJIqsb024542; Tue, 10 Jan 2012 12:18:52 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AJIp17024535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Jan 2012 12:18:51 -0700 (MST) (envelope-from msk@cloudmark.com) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Jan 2012 11:18:40 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Jan 2012 11:18:47 -0800 From: "Murray S. Kucherawy" To: "ietf-smtp@imc.org" Date: Tue, 10 Jan 2012 11:18:45 -0800 Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Topic: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Index: AczPzB+TWdutekZaQq6fHYI8WuARCwAACp1w Message-ID: References: <4F0C7B02.5030406@dcrocker.net> <20120110191045.34622.qmail@joyce.lan> In-Reply-To: <20120110191045.34622.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by hoffman.proper.com id q0AJIq16024536 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: owner-ietf-smtp@mail.imc.org [mailto:owner-ietf-smtp@mail.imc.org] On Behalf Of John Levine > Sent: Tuesday, January 10, 2012 11:11 AM > To: ietf-smtp@imc.org > Cc: dcrocker@bbiw.net > Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt > > >If the new clause is only for delays, then we can't extend use of the > >clause to cover extra processing steps. If the label is for more > >general use, then we can. > > That's OK, but now I'm wondering if the syntax should allow a list of > states rather than just one > > Received: blah blah STATE DOWNCODED-TO-7,MODERATED blah blah I don't think we're talking about this kind of metadata here. Really this is meant to talk about a delay introduced while waiting for something to happen, usually operator intervention of some kind (quarantine, list moderation). An automatic step like downcoding or (for another example) virus scrubbing only introduces a compute delay and a bit of I/O, not an enforced usually-human-caused delay like the other cases. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AJBJP3024200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 12:11:19 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0AJBJSi024197; Tue, 10 Jan 2012 12:11:19 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from leila.iecc.com (leila.iecc.com [64.57.183.34]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AJBAuc024190 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jan 2012 12:11:17 -0700 (MST) (envelope-from johnl@iecc.com) Received: (qmail 59963 invoked from network); 10 Jan 2012 19:11:08 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Jan 2012 19:11:08 -0000 Date: 10 Jan 2012 19:10:45 -0000 Message-ID: <20120110191045.34622.qmail@joyce.lan> From: "John Levine" To: ietf-smtp@imc.org Cc: dcrocker@bbiw.net Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt In-Reply-To: <4F0C7B02.5030406@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >If the new clause is only for delays, then we can't extend use of the clause to >cover extra processing steps. If the label is for more general use, >then we can. That's OK, but now I'm wondering if the syntax should allow a list of states rather than just one > Received: blah blah STATE DOWNCODED-TO-7,MODERATED blah blah I suppose you could use two received headers for two states, but that seems unlike the way people use them now. R's, John Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AJ1wVI023825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 12:01:58 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0AJ1wRq023824; Tue, 10 Jan 2012 12:01:58 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AJ1vor023819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jan 2012 12:01:58 -0700 (MST) (envelope-from dhc@dcrocker.net) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0AJ1fLW008824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 11:01:55 -0800 Message-ID: <4F0C8B0C.7070307@dcrocker.net> Date: Tue, 10 Jan 2012 11:01:32 -0800 From: Dave CROCKER Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" CC: "ietf-smtp@imc.org" Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt References: <20120110051303.5950.qmail@joyce.lan> <4F0C60FA.5080507@dcrocker.net> <4F0C8033.5060102@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 10 Jan 2012 11:01:56 -0800 (PST) Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 1/10/2012 10:21 AM, Murray S. Kucherawy wrote: >> OK. Putting this simplistically, we already have lots of Received: fields >> being generated and we should have a clause value that covers this >> probably-uninteresting set? I suggest "normal" or somesuch, not "none". >> The message, /is/ after all, making a transition. Whatever state or queue >> it just entered, it does exist. > > John suggested what's essentially a no-op state name to accommodate those > implementations that, in supporting this, will always want to put some kind > of state clause down, and that seems a decent idea to me. > > "normal" would be fine with me too. Doing what sales folk call "selling past the sale" I'll note that there is no such thing as a no-op, since the presence of the Received: field means that some sort of 'op' took place. So the question is what the "nature" of the op is. A label like "normal" therefore can cover the existing header fields with a generic term for the nature. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AILHbF021879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 11:21:17 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0AILH30021878; Tue, 10 Jan 2012 11:21:17 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AILHhh021868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Jan 2012 11:21:17 -0700 (MST) (envelope-from msk@cloudmark.com) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Jan 2012 10:21:05 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Jan 2012 10:21:12 -0800 From: "Murray S. Kucherawy" To: "ietf-smtp@imc.org" Date: Tue, 10 Jan 2012 10:21:11 -0800 Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Topic: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Index: AczPw9coWl6wVWaPRHe0EjeSVm2wmAAAF4CQ Message-ID: References: <20120110051303.5950.qmail@joyce.lan> <4F0C60FA.5080507@dcrocker.net> <4F0C8033.5060102@dcrocker.net> In-Reply-To: <4F0C8033.5060102@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id q0AILHhg021870 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Dave CROCKER [mailto:dhc@dcrocker.net] > Sent: Tuesday, January 10, 2012 10:15 AM > To: Murray S. Kucherawy > Cc: ietf-smtp@imc.org > Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt > > This suggests a confusion about the clause. Does it provide a label to > explain the specific Received field or does it label the message? I > think that having it used as a label for the message is just plain > wrong. Put those somewhere else. +1. > OK. Putting this simplistically, we already have lots of Received: > fields being generated and we should have a clause value that covers > this probably-uninteresting set? I suggest "normal" or somesuch, not > "none". The message, /is/ after all, making a transition. Whatever > state or queue it just entered, it does exist. John suggested what's essentially a no-op state name to accommodate those implementations that, in supporting this, will always want to put some kind of state clause down, and that seems a decent idea to me. "normal" would be fine with me too. -MSK Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AIFWSY021599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 11:15:32 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0AIFWPo021598; Tue, 10 Jan 2012 11:15:32 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AIFVQ0021590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jan 2012 11:15:32 -0700 (MST) (envelope-from dhc@dcrocker.net) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0AIFPiO007620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 10:15:30 -0800 Message-ID: <4F0C8033.5060102@dcrocker.net> Date: Tue, 10 Jan 2012 10:15:15 -0800 From: Dave CROCKER Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" CC: "ietf-smtp@imc.org" Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt References: <20120110051303.5950.qmail@joyce.lan> <4F0C60FA.5080507@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 10 Jan 2012 10:15:31 -0800 (PST) Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 1/10/2012 10:02 AM, Murray S. Kucherawy wrote: >>> Those aren't queueing states though; they're metadata about the message. >> >> I think I don't understand what this means. > > The example given was "spam", which strikes me as a label attached to a > message somehow (perhaps as metadata) and not a phase of message handling > enroute to its destination. This suggests a confusion about the clause. Does it provide a label to explain the specific Received field or does it label the message? I think that having it used as a label for the message is just plain wrong. Put those somewhere else. >> Use of the clause requires a new Received header field. The condition the >> 'none' value seems intended for is for typical header fields as are >> generated today. Either these should get meaningful labels or the existing >> label 'other' should suffice. > > I think "other" implies the message is entering some kind of queue state that > will introduce an atypical delay, where "none" is an explicit statement that > this is not the case. They are semantically different. OK. Putting this simplistically, we already have lots of Received: fields being generated and we should have a clause value that covers this probably-uninteresting set? I suggest "normal" or somesuch, not "none". The message, /is/ after all, making a transition. Whatever state or queue it just entered, it does exist. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AI2Z7B020963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 11:02:35 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0AI2ZXJ020962; Tue, 10 Jan 2012 11:02:35 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from groups.winserver.com (mail.santronics.com [208.247.131.9]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AI2YoP020957 for ; Tue, 10 Jan 2012 11:02:34 -0700 (MST) (envelope-from hsantos@santronics.com) DKIM-Signature: v=1; d=santronics.com; s=tms1; a=rsa-sha1; c=simple/relaxed; t=1326218547; h=Received:Received:Message-ID: Date:From:Organization:To:Subject:List-ID; bh=DoT4Q2teZlPcI4KbaA 0cg66M+WU=; b=w0m8ZjsU0S/ERltBWRTHObVWRQe9cQZ9o50uPEMaTg0AhzX5aB lXjTJhze89rycSkp4X/rCA+Yu0+DBC525KevYfTGqtaSg07kKnlQJkvEi+tvePTp UgF905hFmnmwl9NYOBB7SeQH0Wa8krBll6JtgCtvHLpBa+9HiswTG4C3M= Received: by winserver.com (Wildcat! SMTP Router v6.4.454.1) for ietf-smtp@imc.org; Tue, 10 Jan 2012 13:02:27 -0500 Received: from [192.168.1.101] ([99.3.147.93]) by winserver.com (Wildcat! SMTP v6.4.454.1) with ESMTP id 3715401463.33109.3048; Tue, 10 Jan 2012 13:02:26 -0500 Message-ID: <4F0C7D2D.30806@santronics.com> Date: Tue, 10 Jan 2012 13:02:21 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "ietf-smtp@imc.org" Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt References: <20120110051303.5950.qmail@joyce.lan> <4F0C60FA.5080507@dcrocker.net> In-Reply-To: <4F0C60FA.5080507@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: +1 Dave. My Take: 1) This should be a MAY implement 2) It can only be a SHOULD with a presumption of other ideas already existing. Its like I MAY build a house, and if I do, I SHOULD do certain things expected in building a house. This should not say I SHOULD build a house. Dave CROCKER wrote: > > > > On 1/9/2012 10:50 PM, Murray S. Kucherawy wrote: >> I just changed it to MAY, on the grounds that it will probably be >> user/admin >> pressure that gets the feature added rather than something normative >> (e.g., >> nobody requires this, but all the cool kids do it). > > Mumble. Although I can see the merit in choosing MAY, I suggest you > revert to SHOULD. > > This is a point of continuing confusion. Does the normative language in > an extension spec mean "relative to the overall service" or "relative to > /this/ specification? > > And then there is the usual debate about degree of importance that > guides must/may/should. > > My take: > > If we think use of the STATE clause is nice but not all that > important, then the normative word should be MAY. If we think this can > have significant benefit and especially when widely adopted, the word > should be SHOULD. > > We could argue that email has done well enough without it for many > years, so this should be MAY. We could also argue that obscure delays > are a significant problem and that the current scale of Internet mail > and challenges in diagnosing problems means that it's important to guide > potential implementers about the importance of implementing this. > > I prefer SHOULD. > > We need better insight into mail transit. > > >>> Other nits: if this is really about deliberate delays, I'd suggest >>> using a >>> term like "queued" or "delay" or "hold" rather than "state". I can >>> think of >>> states that might be interesting but don't involve a delay, e.g. >>> characterized as spam, or downcoded from 8 bits to 6 bits. > > The choice of word affects possible later use. STATE makes is > reasonable to consider other uses. DELAY or HOLD constrain the used. > QUEUED strikes me as synonymous with STATE, actually. > > >> Those aren't queueing states though; they're metadata about the message. > > I think I don't understand what this means. > > The choice of the word STATE does imply that there is a grand state > machine that describes handling of the message and that this annotation > records the timing of a transition through it. The implication is correct. > > While the motivation for this annotation is to account for unusual > delays, I do not see why the semantics of the clause label needs to be > limited to that more constrained semantic. Using the more general label > does not make the software for the clause more complex; but it does make > it easier to consider extended use, later. > > >> I saw "state downcode", I'd conclude that the time gap implied by the >> delta >> between adjacent Received fields indicated the amount of time that >> host spent >> downcoding the message. >> >>> Also, it might be a good idea to have a state name for no delay, e.g >>> "queued none", both for the benefit of dorky software that always >>> wants to >>> put the same set of clauses in its Received: headers, and to provide an >>> explicit way to say hey, this delay wasn't my idea. >> >> That's not a bad idea. Thanks. > > Use of the clause requires a new Received header field. The condition > the 'none' value seems intended for is for typical header fields as are > generated today. Either these should get meaningful labels or the > existing label 'other' should suffice. > > d/ > -- Sincerely Hector Santos http://www.santronics.com jabber: hector@jabber.isdg.net Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AI2Atn020949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 11:02:10 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0AI2AHk020948; Tue, 10 Jan 2012 11:02:10 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AI2AWG020943 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Jan 2012 11:02:10 -0700 (MST) (envelope-from msk@cloudmark.com) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Jan 2012 10:02:02 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Jan 2012 10:02:09 -0800 From: "Murray S. Kucherawy" To: "ietf-smtp@imc.org" Date: Tue, 10 Jan 2012 10:02:08 -0800 Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Topic: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Index: AczPsUIeTOYR3X4jSZKOzZ3AAVbWCgAEGfqQ Message-ID: References: <20120110051303.5950.qmail@joyce.lan> <4F0C60FA.5080507@dcrocker.net> In-Reply-To: <4F0C60FA.5080507@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id q0AI2AWF020944 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: Dave CROCKER [mailto:dhc@dcrocker.net] > Sent: Tuesday, January 10, 2012 8:02 AM > To: Murray S. Kucherawy > Cc: ietf-smtp@imc.org > Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt > > > Those aren't queueing states though; they're metadata about the > > message. > > I think I don't understand what this means. The example given was "spam", which strikes me as a label attached to a message somehow (perhaps as metadata) and not a phase of message handling enroute to its destination. > Use of the clause requires a new Received header field. The condition > the 'none' value seems intended for is for typical header fields as are > generated today. Either these should get meaningful labels or the > existing label 'other' > should suffice. I think "other" implies the message is entering some kind of queue state that will introduce an atypical delay, where "none" is an explicit statement that this is not the case. They are semantically different. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AHxfKf020781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 10:59:41 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0AHxff7020780; Tue, 10 Jan 2012 10:59:41 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AHxe4Y020775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Jan 2012 10:59:41 -0700 (MST) (envelope-from msk@cloudmark.com) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 10 Jan 2012 09:59:28 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Jan 2012 09:59:35 -0800 From: "Murray S. Kucherawy" To: "ietf-smtp@imc.org" Date: Tue, 10 Jan 2012 09:59:33 -0800 Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Topic: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Index: AczPvQmjwOMBprQjQMSDYscwHJ+SeQABDKFA Message-ID: References: <20120110172624.6054.qmail@joyce.lan> In-Reply-To: <20120110172624.6054.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by hoffman.proper.com id q0AHxf4X020776 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: John Levine [mailto:johnl@taugh.com] > Sent: Tuesday, January 10, 2012 9:26 AM > To: ietf-smtp@imc.org > Cc: Murray S. Kucherawy > Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt > > It seems reasonable to use MUSTard that assumes that the reader is > going to implement this spec, in which case it's SHOULD and > RECOMMENDED. Or not, in which case it's MAY and OPTIONAL. Then given this and Dave's post, I'm inclined to go back to SHOULD. > It wasn't > clear to me that you're only expected to add the clause when you queue > the message for longer than normal, but that should be easy enough to > fix. The second paragraph of the Introduction section is meant to make this plain, i.e., that you do this for anything other than queue-for-later-when-transport-fails. Can you suggest wording tweaks? > Well, yeah, but there are a lot of kind of states other than queueing > states. That's why I'd suggest a keyword that tells you this is about > queues or delays or something. I've never heard "spam" (your example) used as part of a state machine. It's essentially a label attached to a message, not a phase of handling while a message is in transit. -MSK Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AHrNK5020468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 10:53:23 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0AHrMhg020467; Tue, 10 Jan 2012 10:53:22 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AHrM0c020462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jan 2012 10:53:22 -0700 (MST) (envelope-from dhc@dcrocker.net) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0AHrGgX007041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 09:53:21 -0800 Message-ID: <4F0C7B02.5030406@dcrocker.net> Date: Tue, 10 Jan 2012 09:53:06 -0800 From: Dave CROCKER Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: John Levine CC: ietf-smtp@imc.org Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt References: <20120110172624.6054.qmail@joyce.lan> In-Reply-To: <20120110172624.6054.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 10 Jan 2012 09:53:22 -0800 (PST) Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 1/10/2012 9:26 AM, John Levine wrote: >> Those aren't queueing states though; they're metadata about the message. >> >If I saw "state downcode", I'd conclude that the time gap implied by the >> >delta between adjacent Received fields indicated the amount of time that >> >host spent downcoding the message. > Well, yeah, but there are a lot of kind of states other than queueing > states. That's why I'd suggest a keyword that tells you this is about > queues or delays or something. This puts the specific semantic into the definition of the clause, rather than the value used in the clause. The problem with this is lack of flexibility. For example, it could be noteworthy to record a processing step that introduces no interesting delay. If the new clause is only for delays, then we can't extend use of the clause to cover extra processing steps. If the label is for more general use, then we can. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AHQrsP019364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 10:26:53 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0AHQr0o019363; Tue, 10 Jan 2012 10:26:53 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from leila.iecc.com (leila.iecc.com [64.57.183.34]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AHQpU1019354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jan 2012 10:26:52 -0700 (MST) (envelope-from johnl@iecc.com) Received: (qmail 78802 invoked from network); 10 Jan 2012 17:26:46 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Jan 2012 17:26:46 -0000 Date: 10 Jan 2012 17:26:24 -0000 Message-ID: <20120110172624.6054.qmail@joyce.lan> From: "John Levine" To: ietf-smtp@imc.org Cc: msk@cloudmark.com Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >> In that case, suggest changing the OPTIONAL to something like >> "RECOMMENDED if the message has been held." > >But RECOMMENDED is the same as SHOULD, to which you originally objected. Quoting Abraham Lincoln*, when a judge pointed out that he was arguing the opposite position from one in a case earlier in the day, "Your honor, this morning I was wrong." It seems reasonable to use MUSTard that assumes that the reader is going to implement this spec, in which case it's SHOULD and RECOMMENDED. Or not, in which case it's MAY and OPTIONAL. It wasn't clear to me that you're only expected to add the clause when you queue the message for longer than normal, but that should be easy enough to fix. >> Other nits: if this is really about deliberate delays, I'd suggest >> using a term like "queued" or "delay" or "hold" rather than "state". >> I can think of states that might be interesting but don't involve a >> delay, e.g. characterized as spam, or downcoded from 8 bits to 6 bits. > >Those aren't queueing states though; they're metadata about the message. >If I saw "state downcode", I'd conclude that the time gap implied by the >delta between adjacent Received fields indicated the amount of time that >host spent downcoding the message. Well, yeah, but there are a lot of kind of states other than queueing states. That's why I'd suggest a keyword that tells you this is about queues or delays or something. R's, John * - an American politician of the Victorian era, a contemporary of MacDonald Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AG2K6I015339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 09:02:20 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0AG2K7R015338; Tue, 10 Jan 2012 09:02:20 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0AG2Jsg015333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jan 2012 09:02:19 -0700 (MST) (envelope-from dhc@dcrocker.net) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q0AG2C9p004179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jan 2012 08:02:17 -0800 Message-ID: <4F0C60FA.5080507@dcrocker.net> Date: Tue, 10 Jan 2012 08:02:02 -0800 From: Dave CROCKER Reply-To: dcrocker@bbiw.net Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" CC: "ietf-smtp@imc.org" Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt References: <20120110051303.5950.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 10 Jan 2012 08:02:18 -0800 (PST) Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On 1/9/2012 10:50 PM, Murray S. Kucherawy wrote: > I just changed it to MAY, on the grounds that it will probably be user/admin > pressure that gets the feature added rather than something normative (e.g., > nobody requires this, but all the cool kids do it). Mumble. Although I can see the merit in choosing MAY, I suggest you revert to SHOULD. This is a point of continuing confusion. Does the normative language in an extension spec mean "relative to the overall service" or "relative to /this/ specification? And then there is the usual debate about degree of importance that guides must/may/should. My take: If we think use of the STATE clause is nice but not all that important, then the normative word should be MAY. If we think this can have significant benefit and especially when widely adopted, the word should be SHOULD. We could argue that email has done well enough without it for many years, so this should be MAY. We could also argue that obscure delays are a significant problem and that the current scale of Internet mail and challenges in diagnosing problems means that it's important to guide potential implementers about the importance of implementing this. I prefer SHOULD. We need better insight into mail transit. >> Other nits: if this is really about deliberate delays, I'd suggest using a >> term like "queued" or "delay" or "hold" rather than "state". I can think of >> states that might be interesting but don't involve a delay, e.g. >> characterized as spam, or downcoded from 8 bits to 6 bits. The choice of word affects possible later use. STATE makes is reasonable to consider other uses. DELAY or HOLD constrain the used. QUEUED strikes me as synonymous with STATE, actually. > Those aren't queueing states though; they're metadata about the message. I think I don't understand what this means. The choice of the word STATE does imply that there is a grand state machine that describes handling of the message and that this annotation records the timing of a transition through it. The implication is correct. While the motivation for this annotation is to account for unusual delays, I do not see why the semantics of the clause label needs to be limited to that more constrained semantic. Using the more general label does not make the software for the clause more complex; but it does make it easier to consider extended use, later. > I saw "state downcode", I'd conclude that the time gap implied by the delta > between adjacent Received fields indicated the amount of time that host spent > downcoding the message. > >> Also, it might be a good idea to have a state name for no delay, e.g >> "queued none", both for the benefit of dorky software that always wants to >> put the same set of clauses in its Received: headers, and to provide an >> explicit way to say hey, this delay wasn't my idea. > > That's not a bad idea. Thanks. Use of the clause requires a new Received header field. The condition the 'none' value seems intended for is for typical header fields as are generated today. Either these should get meaningful labels or the existing label 'other' should suffice. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0A6oquY092409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jan 2012 23:50:52 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0A6oqcu092408; Mon, 9 Jan 2012 23:50:52 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0A6opig092402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Jan 2012 23:50:52 -0700 (MST) (envelope-from msk@cloudmark.com) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Jan 2012 22:50:39 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 9 Jan 2012 22:50:46 -0800 From: "Murray S. Kucherawy" To: "ietf-smtp@imc.org" Date: Mon, 9 Jan 2012 22:50:45 -0800 Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Topic: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Index: AczPVpZKPtl2LdcOS2yeA60gXlP0kgADH1dA Message-ID: References: <20120110051303.5950.qmail@joyce.lan> In-Reply-To: <20120110051303.5950.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by hoffman.proper.com id q0A6oqif092404 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: John Levine [mailto:johnl@taugh.com] > Sent: Monday, January 09, 2012 9:13 PM > To: ietf-smtp@imc.org > Cc: Murray S. Kucherawy > Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt > > In that case, suggest changing the OPTIONAL to something like > "RECOMMENDED if the message has been held." But RECOMMENDED is the same as SHOULD, to which you originally objected. The "if the message has been held" is implicit in the idea that this is only used if some kind of administrative hold has been imposed (rather than caused by a transport anomaly). I just changed it to MAY, on the grounds that it will probably be user/admin pressure that gets the feature added rather than something normative (e.g., nobody requires this, but all the cool kids do it). > Other nits: if this is really about deliberate delays, I'd suggest > using a term like "queued" or "delay" or "hold" rather than "state". > I can think of states that might be interesting but don't involve a > delay, e.g. characterized as spam, or downcoded from 8 bits to 6 bits. Those aren't queueing states though; they're metadata about the message. If I saw "state downcode", I'd conclude that the time gap implied by the delta between adjacent Received fields indicated the amount of time that host spent downcoding the message. > Also, it might be a good idea to have a state name for no delay, e.g > "queued none", both for the benefit of dorky software that always wants > to put the same set of clauses in its Received: headers, and to provide > an explicit way to say hey, this delay wasn't my idea. That's not a bad idea. Thanks. -MSK Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0A5DS38088719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jan 2012 22:13:28 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0A5DSoR088718; Mon, 9 Jan 2012 22:13:28 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from leila.iecc.com (leila.iecc.com [64.57.183.34]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0A5DQKc088712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Jan 2012 22:13:27 -0700 (MST) (envelope-from johnl@iecc.com) Received: (qmail 65927 invoked from network); 10 Jan 2012 05:13:25 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Jan 2012 05:13:25 -0000 Date: 10 Jan 2012 05:13:03 -0000 Message-ID: <20120110051303.5950.qmail@joyce.lan> From: "John Levine" To: ietf-smtp@imc.org Cc: msk@cloudmark.com Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >But since you're the second person to mention that, I guess some >wordsmithing is in order to make that clear. In that case, suggest changing the OPTIONAL to something like "RECOMMENDED if the message has been held." Other nits: if this is really about deliberate delays, I'd suggest using a term like "queued" or "delay" or "hold" rather than "state". I can think of states that might be interesting but don't involve a delay, e.g. characterized as spam, or downcoded from 8 bits to 6 bits. Also, it might be a good idea to have a state name for no delay, e.g "queued none", both for the benefit of dorky software that always wants to put the same set of clauses in its Received: headers, and to provide an explicit way to say hey, this delay wasn't my idea. R's, John Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0A4HOk4087098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jan 2012 21:17:24 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0A4HOes087097; Mon, 9 Jan 2012 21:17:24 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0A4HN4D087092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Jan 2012 21:17:23 -0700 (MST) (envelope-from msk@cloudmark.com) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Jan 2012 20:17:15 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 9 Jan 2012 20:17:22 -0800 From: "Murray S. Kucherawy" To: "ietf-smtp@imc.org" Date: Mon, 9 Jan 2012 20:17:25 -0800 Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Topic: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Index: AczPTYQIUGAP9G2tSAGsISaCJIIG3wAAMMkQ Message-ID: References: <20120110040807.20516.qmail@joyce.lan> In-Reply-To: <20120110040807.20516.qmail@joyce.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by hoffman.proper.com id q0A4HN4C087093 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > -----Original Message----- > From: John Levine [mailto:johnl@taugh.com] > Sent: Monday, January 09, 2012 8:08 PM > To: ietf-smtp@imc.org > Cc: Murray S. Kucherawy > Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt > > In the first paragraph of section 3, I'd say MAY rather than SHOULD, > both because it conflicts with the OPTIONAL at the end of the section, > and just because the world has gotten along without this feature for > 30 years so its practical necessity remains debatable. The SHOULD only applies to people that are implementing this, meaning if you claim to be compliant with this, then you'll always add it unless you have a very good (operational) reason why you don't. If it was SHOULD and also "Updates RFC5321", I'd agree with you, but this is meant as an independent and optional extension. But since you're the second person to mention that, I guess some wordsmithing is in order to make that clear. > Other than that it seems mostly harmless. Has anyone implemented it > yet? I've floated the idea to some open source and commercial MTAs and mailbox providers, and one popular MLM. We'll see what traction it gets. Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0A48WrR086782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jan 2012 21:08:32 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q0A48W5Z086781; Mon, 9 Jan 2012 21:08:32 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from leila.iecc.com (leila.iecc.com [64.57.183.34]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q0A48UYU086776 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Jan 2012 21:08:31 -0700 (MST) (envelope-from johnl@iecc.com) Received: (qmail 29160 invoked from network); 10 Jan 2012 04:08:29 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Jan 2012 04:08:29 -0000 Date: 10 Jan 2012 04:08:07 -0000 Message-ID: <20120110040807.20516.qmail@joyce.lan> From: "John Levine" To: ietf-smtp@imc.org Cc: msk@cloudmark.com Subject: Re: FW: I-D Action: draft-kucherawy-received-state-00.txt In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: In the first paragraph of section 3, I'd say MAY rather than SHOULD, both because it conflicts with the OPTIONAL at the end of the section, and just because the world has gotten along without this feature for 30 years so its practical necessity remains debatable. Other than that it seems mostly harmless. Has anyone implemented it yet? R's, John Received: from hoffman.proper.com (localhost [127.0.0.1]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q09MjlXo076737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jan 2012 15:45:47 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) Received: (from majordom@localhost) by hoffman.proper.com (8.14.4/8.13.5/Submit) id q09Mjlxn076735; Mon, 9 Jan 2012 15:45:47 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org) X-Authentication-Warning: hoffman.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id q09MjkwF076730 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Jan 2012 15:45:47 -0700 (MST) (envelope-from msk@cloudmark.com) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 9 Jan 2012 14:45:39 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 9 Jan 2012 14:45:46 -0800 From: "Murray S. Kucherawy" To: SMTP Discussion Date: Mon, 9 Jan 2012 14:45:44 -0800 Subject: RE: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Topic: FW: I-D Action: draft-kucherawy-received-state-00.txt Thread-Index: AcynZBAEo5zT3L9ARPCvFLMtt2b7hAAUs61ACdpXKAA= Message-ID: References: <4EC3778E.3010204@santronics.com> <9110482181.20111116014427@pobox.com> <1484004834.20111118232129@pobox.com> <4EC76573.2090006@dcrocker.net> <1638495041.20111119114957@pobox.com> <4EC8ADCF.7090606@gmail.com> <7410327538.20111120010538@pobox.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id q09MjlwE076731 Sender: owner-ietf-smtp@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi all, In response to feedback here, I posted an -01 version of this document over a month ago. It includes text addressing Bill's question about what exactly is going on when a state change is indicated. Further review and comments welcome, which will guide me toward selecting next steps (if any). Cheers, -MSK