From lemonade-bounces@ietf.org Wed Feb 01 04:16:09 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4E5x-0005kO-IO; Wed, 01 Feb 2006 04:16:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4E5v-0005hO-G6 for lemonade@megatron.ietf.org; Wed, 01 Feb 2006 04:16:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24818 for ; Wed, 1 Feb 2006 04:14:30 -0500 (EST) Received: from rgminet01.oracle.com ([148.87.113.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4EH4-0005LW-7D for lemonade@ietf.org; Wed, 01 Feb 2006 04:27:38 -0500 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by rgminet01.oracle.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id k119FsKJ023228; Wed, 1 Feb 2006 02:15:54 -0700 Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k119Fsjb017100; Wed, 1 Feb 2006 02:15:54 -0700 Received: from us.oracle.com (dhcp-amer-csvpn-gw2-141-144-72-76.vpn.oracle.com [141.144.72.76]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k119FqkW017087 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 1 Feb 2006 02:15:53 -0700 From: "Stephane H. Maes" To: "Zoltan.Ordogh@nokia.com" , "gparsons@nortel.com" , "lemonade@ietf.org" Subject: RE: [lemonade] Draft Liaison to OMA Date: Wed, 1 Feb 2006 01:15:47 -0800 In-Reply-To: <084CB2DF0B7F5E47BC056ABBDF423700018C3D9A@trebe101.NOE.Nokia.com> X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4.2.8 70113 (11.0.6359) Message-ID: <20060201011548968.00000002632@smaes-lap> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org As I stated: "fixing the concerns of OMA", tehrefore ensuring no duplicatio= n etc... This doc will explain the pieces that Lemonade profile and the items it add= ress for MEM. Stephane = _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) = -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] = Sent: Wednesday, February 01, 2006 1:13 AM To: stephane.maes@oracle.com; gparsons@nortel.com; lemonade@ietf.org Subject: RE: [lemonade] Draft Liaison to OMA Hi Stephane, while the techincal content of the draft is valid and I agree to it (well, = most if it anyway), I would not go for the RFC status. What will happen when there is an IETF mobile email AD and there is an OMA = mobile email AD? Customers will be confused which one to implement and we are going to be th= e ones who have to explain which one they should choose and why - this will= be difficult. Also, there might be interoperability issues later on. So th= ere should be only one AD. I do not have a preference on where the AD is, t= he important thing is that there is only one. If it is IETF, then the OMA A= D should not be progressed any further and dropped and all future OMA specs= shall reference the IETF AD, or vice versa. This is the reason I would like to clarify the statement in the LS - I beli= eve it is vague - we need a clear message what is going to happen. Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of ext Stephane H. Maes Sent: 31 January, 2006 16:49 To: gparsons@nortel.com; lemonade@ietf.org Subject: Re: [lemonade] Draft Liaison to OMA Zoltan, = It seems correct to me: 1) its the LEMONADE WG view as agreed hence a ietf deaft 2) this way its is documented, visible and stored somewhere as a working do= cument hence a draft. This does not imply bor discuss its long term status hence again beung a dr= aft. I personally believe that it makes a lot of sense to have it become RF= C (fizing the concrens raised by OMA of course) when work and relationship = between specs stabilize. Stephane _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le Ph: +1-203-300-7786 (mobile/SMS/skype); Fax / Office UM: +1-650-607-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: Zoltan.Ordogh@nokia.com Date: Tue, 31 Jan 2006 15:30:34 To:, Subject: RE: [lemonade] Draft Liaison to OMA "The purpose of the WG Internet Draft is to allow this to be documented in = the IETF and to further affirm its status as a WG view." What does it mean? Will it become an RFC later on? Could You please clarify= /reword this sentence? = = Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 = = ________________________________ From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of ext Glenn Parsons Sent: 25 January, 2006 23:31 To: lemonade@ietf.org Subject: [lemonade] Draft Liaison to OMA Folks, = As agreed, we will be sending a liaison to OMA MEM in time for their Feb me= eting. = As a result, please provide comment on the proposed liaison to OMA by Jan 3= 0th. We will send it on Jan 31st if there is no objection. Cheers, Glenn. = From: IETF LEMONADE Working Group = To: OMA MWG MEM Sub Working Group = Title: Regarding the LEMONADE Profile = Response contact: lemonade@ietf.org = Purpose: For Action = Deadline: March 13, 2006 = The LEMONADE working group (WG) would like to thank the OMA Mobile Email Su= b Working Group for your latest liaison. = Our previous liaison indicated that we have proposed a realization of the O= MA MEM architecture using IETF protocols and that we documented this in an = Internet Draft (see draft-ietf-lemonade-oma-mem-realization-00.txt). The p= urpose of the WG Internet Draft is to allow this to be documented in the IE= TF and to further affirm its status as a WG view. There is no intent to publish the OMA MEM RD, AD or TS in IETF. = As we have indicated before, the LEMONADE WG is working on a set of extensi= ons to IMAP and ESMTP to support mobile email. This set will be succinctly= described in the LEMONADE profile (draft-ietf-lemonade-profile-bis). This= will cover interface ME-2 as well as the notifications aspects of ME-3 in = the OMA MEM AD. The OMA TS can normatively reference the LEMONADE profile.= We appreciate your response to the questions that we had asked in our previ= ous liaison. We have a number of follow-on comments/questions: 1. We will support signed notifications but will add the ability to turn i= t off. = 2. OMA STI is currently being used in CONVERT. However we are concerned w= ith the large number of optional parameters. We would prefer a shorter fin= ite mandatory set (that is extensible). What advice can you offer on a sho= rter set? 3. We will be providing managed SIEVE to manage the filters. Additional m= ethods (such as XDMS) could be used as well. = 4. We are evaluating where in our protocols delays may play a role. We no= te that there may be a tradeoff in mobile phones on battery life vs delay. = What delay aspects are of concern to the OMA - is it roundtrip, network o= r service level? 5. We are aware of the limitations for mutual authentication on mobile dev= ices. TLS is not required, and this could be handled by SASL mechanisms wh= ich are already on mobile phones. 6. Message recall is possible within the submit (i.e., administrative) dom= ain. We indicated that we could design protocol for this based on MSGTRK. = However, in the general end-to-end Internet Mail case it is practically im= possible to design a message recall solution that will reliably work. We would like to draw your attention to the fact that LEMONADE has wrapped = up the first phase of its work. We are currently working on finalizing the= content of Profile bis. Additional input on details required to meet OMA r= equirements have been reviewed, and most have become WG documents. The tim= eline would likely result in conclusion later in early 2006. Up-to-date information on LEMONADE Internet-Drafts and RFCs can always be f= ound at http://www.ietf.org/html.charters/lemonade-charter.html with more detail tracked on= the supplemental site. Finally, as information, the next meetings of the IETF LEMONADE WG are: = * Mar 20-24 - IETF 65 plenary - Dallas, TX = * Jul 10-14 - IETF 66 plenary - TBD = = _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 01 04:13:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4E34-0004EA-3k; Wed, 01 Feb 2006 04:13:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4E30-00047Z-Td for lemonade@megatron.ietf.org; Wed, 01 Feb 2006 04:13:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24515 for ; Wed, 1 Feb 2006 04:11:19 -0500 (EST) From: Zoltan.Ordogh@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4EDz-0005D4-En for lemonade@ietf.org; Wed, 01 Feb 2006 04:24:28 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k119Co9c012331; Wed, 1 Feb 2006 11:12:53 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 11:12:39 +0200 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 11:12:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Draft Liaison to OMA Date: Wed, 1 Feb 2006 11:12:38 +0200 Message-ID: <084CB2DF0B7F5E47BC056ABBDF423700018C3D9A@trebe101.NOE.Nokia.com> In-Reply-To: <18950122.1138718895068.JavaMail.teamon@bda034-cell00.bisx.prod.on.blackberry> Thread-Topic: [lemonade] Draft Liaison to OMA Thread-Index: AcYmdwMN5Oqzt0hvRKSWhAz7Eg6MEwAl3s9w To: , , X-OriginalArrivalTime: 01 Feb 2006 09:12:38.0929 (UTC) FILETIME=[A5FA8810:01C6270F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Hi Stephane, while the techincal content of the draft is valid and I agree to it = (well, most if it anyway), I would not go for the RFC status. What will happen when there is an IETF mobile email AD and there is an = OMA mobile email AD? Customers will be confused which one to implement and we are going to be = the ones who have to explain which one they should choose and why - this = will be difficult. Also, there might be interoperability issues later = on. So there should be only one AD. I do not have a preference on where = the AD is, the important thing is that there is only one. If it is IETF, = then the OMA AD should not be progressed any further and dropped and all = future OMA specs shall reference the IETF AD, or vice versa. This is the reason I would like to clarify the statement in the LS - I = believe it is vague - we need a clear message what is going to happen. Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On = Behalf Of ext Stephane H. Maes Sent: 31 January, 2006 16:49 To: gparsons@nortel.com; lemonade@ietf.org Subject: Re: [lemonade] Draft Liaison to OMA Zoltan,=20 It seems correct to me: 1) its the LEMONADE WG view as agreed hence a ietf deaft 2) this way its is documented, visible and stored somewhere as a working = document hence a draft. This does not imply bor discuss its long term status hence again beung a = draft. I personally believe that it makes a lot of sense to have it = become RFC (fizing the concrens raised by OMA of course) when work and = relationship between specs stabilize. Stephane _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, = Oracle Ph: +1-203-300-7786 (mobile/SMS/skype); Fax / Office UM: = +1-650-607-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: Zoltan.Ordogh@nokia.com Date: Tue, 31 Jan 2006 15:30:34=20 To:, Subject: RE: [lemonade] Draft Liaison to OMA "The purpose of the WG Internet Draft is to allow this to be documented = in the IETF and to further affirm its status as a WG view." What does it mean? Will it become an RFC later on? Could You please = clarify/reword this sentence? =20 =20 Best regards: Zolt=E1n =D6rd=F6gh=20 E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566=20 =20 ________________________________ From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On = Behalf Of ext Glenn Parsons Sent: 25 January, 2006 23:31 To: lemonade@ietf.org Subject: [lemonade] Draft Liaison to OMA Folks,=20 As agreed, we will be sending a liaison to OMA MEM in time for their Feb = meeting.=20 As a result, please provide comment on the proposed liaison to OMA by = Jan 30th. We will send it on Jan 31st if there is no objection. Cheers,=20 Glenn.=20 From: IETF LEMONADE Working Group=20 To: OMA MWG MEM Sub Working Group=20 Title: Regarding the LEMONADE Profile =20 Response contact: lemonade@ietf.org=20 Purpose: For Action=20 Deadline: March 13, 2006=20 The LEMONADE working group (WG) would like to thank the OMA Mobile Email = Sub Working Group for your latest liaison.=20 Our previous liaison indicated that we have proposed a realization of = the OMA MEM architecture using IETF protocols and that we documented = this in an Internet Draft (see = draft-ietf-lemonade-oma-mem-realization-00.txt). The purpose of the WG = Internet Draft is to allow this to be documented in the IETF and to = further affirm its status as a WG view. There is no intent to publish the OMA MEM RD, AD or TS in IETF.=20 As we have indicated before, the LEMONADE WG is working on a set of = extensions to IMAP and ESMTP to support mobile email. This set will be = succinctly described in the LEMONADE profile = (draft-ietf-lemonade-profile-bis). This will cover interface ME-2 as = well as the notifications aspects of ME-3 in the OMA MEM AD. The OMA TS = can normatively reference the LEMONADE profile. We appreciate your response to the questions that we had asked in our = previous liaison. We have a number of follow-on comments/questions: 1. We will support signed notifications but will add the ability to = turn it off.=20 2. OMA STI is currently being used in CONVERT. However we are = concerned with the large number of optional parameters. We would prefer = a shorter finite mandatory set (that is extensible). What advice can = you offer on a shorter set? 3. We will be providing managed SIEVE to manage the filters. = Additional methods (such as XDMS) could be used as well.=20 4. We are evaluating where in our protocols delays may play a role. We = note that there may be a tradeoff in mobile phones on battery life vs = delay. What delay aspects are of concern to the OMA - is it roundtrip, = network or service level? 5. We are aware of the limitations for mutual authentication on mobile = devices. TLS is not required, and this could be handled by SASL = mechanisms which are already on mobile phones. 6. Message recall is possible within the submit (i.e., administrative) = domain. We indicated that we could design protocol for this based on = MSGTRK. However, in the general end-to-end Internet Mail case it is = practically impossible to design a message recall solution that will = reliably work. We would like to draw your attention to the fact that LEMONADE has = wrapped up the first phase of its work. We are currently working on = finalizing the content of Profile bis. Additional input on details = required to meet OMA requirements have been reviewed, and most have = become WG documents. The timeline would likely result in conclusion = later in early 2006. Up-to-date information on LEMONADE Internet-Drafts and RFCs can always = be found at http://www.ietf.org/html.charters/lemonade-charter.html = with more = detail tracked on the supplemental site. Finally, as information, the next meetings of the IETF LEMONADE WG are:=20 * Mar 20-24 - IETF 65 plenary - Dallas, TX=20 * Jul 10-14 - IETF 66 plenary - TBD=20 =09 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 01 04:35:15 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4EOR-0006Is-4Q; Wed, 01 Feb 2006 04:35:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4EOH-0006Ei-UY for lemonade@megatron.ietf.org; Wed, 01 Feb 2006 04:35:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26438 for ; Wed, 1 Feb 2006 04:33:18 -0500 (EST) From: Zoltan.Ordogh@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4EZG-00067y-N2 for lemonade@ietf.org; Wed, 01 Feb 2006 04:46:27 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k119YocA010720; Wed, 1 Feb 2006 11:34:53 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 11:34:46 +0200 Received: from trebe101.NOE.Nokia.com ([172.22.124.61]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 11:34:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [lemonade] Draft Liaison to OMA Date: Wed, 1 Feb 2006 11:34:44 +0200 Message-ID: <084CB2DF0B7F5E47BC056ABBDF423700018C3DC9@trebe101.NOE.Nokia.com> In-Reply-To: <20060201011548968.00000002632@smaes-lap> Thread-Topic: [lemonade] Draft Liaison to OMA Thread-Index: AcYnEENHpzsP0ESMTOqHbhwmbZWz8wAAmD0Q To: , , X-OriginalArrivalTime: 01 Feb 2006 09:34:46.0102 (UTC) FILETIME=[BD090F60:01C62712] X-Spam-Score: 0.3 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This is exactly what I am missing from the LS. The message in the LS in = unclear.=20 Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext Stephane H. Maes [mailto:stephane.maes@oracle.com]=20 Sent: 01 February, 2006 11:16 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); gparsons@nortel.com; = lemonade@ietf.org Subject: RE: [lemonade] Draft Liaison to OMA As I stated: "fixing the concerns of OMA", tehrefore ensuring no = duplication etc... This doc will explain the pieces that Lemonade profile and the items it = address for MEM. Stephane=20 _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, = Oracle. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) =20 -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com]=20 Sent: Wednesday, February 01, 2006 1:13 AM To: stephane.maes@oracle.com; gparsons@nortel.com; lemonade@ietf.org Subject: RE: [lemonade] Draft Liaison to OMA Hi Stephane, while the techincal content of the draft is valid and I agree to it = (well, most if it anyway), I would not go for the RFC status. What will happen when there is an IETF mobile email AD and there is an = OMA mobile email AD? Customers will be confused which one to implement and we are going to be = the ones who have to explain which one they should choose and why - this = will be difficult. Also, there might be interoperability issues later = on. So there should be only one AD. I do not have a preference on where = the AD is, the important thing is that there is only one. If it is IETF, = then the OMA AD should not be progressed any further and dropped and all = future OMA specs shall reference the IETF AD, or vice versa. This is the reason I would like to clarify the statement in the LS - I = believe it is vague - we need a clear message what is going to happen. Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On = Behalf Of ext Stephane H. Maes Sent: 31 January, 2006 16:49 To: gparsons@nortel.com; lemonade@ietf.org Subject: Re: [lemonade] Draft Liaison to OMA Zoltan,=20 It seems correct to me: 1) its the LEMONADE WG view as agreed hence a ietf deaft 2) this way its is documented, visible and stored somewhere as a working = document hence a draft. This does not imply bor discuss its long term status hence again beung a = draft. I personally believe that it makes a lot of sense to have it = become RFC (fizing the concrens raised by OMA of course) when work and = relationship between specs stabilize. Stephane _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, = Oracle Ph: +1-203-300-7786 (mobile/SMS/skype); Fax / Office UM: = +1-650-607-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: Zoltan.Ordogh@nokia.com Date: Tue, 31 Jan 2006 15:30:34 To:, Subject: RE: [lemonade] Draft Liaison to OMA "The purpose of the WG Internet Draft is to allow this to be documented = in the IETF and to further affirm its status as a WG view." What does it mean? Will it become an RFC later on? Could You please = clarify/reword this sentence? =20 =20 Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566=20 =20 ________________________________ From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On = Behalf Of ext Glenn Parsons Sent: 25 January, 2006 23:31 To: lemonade@ietf.org Subject: [lemonade] Draft Liaison to OMA Folks,=20 As agreed, we will be sending a liaison to OMA MEM in time for their Feb = meeting.=20 As a result, please provide comment on the proposed liaison to OMA by = Jan 30th. We will send it on Jan 31st if there is no objection. Cheers, Glenn.=20 From: IETF LEMONADE Working Group=20 To: OMA MWG MEM Sub Working Group=20 Title: Regarding the LEMONADE Profile =20 Response contact: lemonade@ietf.org=20 Purpose: For Action=20 Deadline: March 13, 2006=20 The LEMONADE working group (WG) would like to thank the OMA Mobile Email = Sub Working Group for your latest liaison.=20 Our previous liaison indicated that we have proposed a realization of = the OMA MEM architecture using IETF protocols and that we documented = this in an Internet Draft (see = draft-ietf-lemonade-oma-mem-realization-00.txt). The purpose of the WG = Internet Draft is to allow this to be documented in the IETF and to = further affirm its status as a WG view. There is no intent to publish the OMA MEM RD, AD or TS in IETF.=20 As we have indicated before, the LEMONADE WG is working on a set of = extensions to IMAP and ESMTP to support mobile email. This set will be = succinctly described in the LEMONADE profile = (draft-ietf-lemonade-profile-bis). This will cover interface ME-2 as = well as the notifications aspects of ME-3 in the OMA MEM AD. The OMA TS = can normatively reference the LEMONADE profile. We appreciate your response to the questions that we had asked in our = previous liaison. We have a number of follow-on comments/questions: 1. We will support signed notifications but will add the ability to = turn it off.=20 2. OMA STI is currently being used in CONVERT. However we are = concerned with the large number of optional parameters. We would prefer = a shorter finite mandatory set (that is extensible). What advice can = you offer on a shorter set? 3. We will be providing managed SIEVE to manage the filters. = Additional methods (such as XDMS) could be used as well.=20 4. We are evaluating where in our protocols delays may play a role. We = note that there may be a tradeoff in mobile phones on battery life vs = delay. What delay aspects are of concern to the OMA - is it roundtrip, = network or service level? 5. We are aware of the limitations for mutual authentication on mobile = devices. TLS is not required, and this could be handled by SASL = mechanisms which are already on mobile phones. 6. Message recall is possible within the submit (i.e., administrative) = domain. We indicated that we could design protocol for this based on = MSGTRK. However, in the general end-to-end Internet Mail case it is = practically impossible to design a message recall solution that will = reliably work. We would like to draw your attention to the fact that LEMONADE has = wrapped up the first phase of its work. We are currently working on = finalizing the content of Profile bis. Additional input on details = required to meet OMA requirements have been reviewed, and most have = become WG documents. The timeline would likely result in conclusion = later in early 2006. Up-to-date information on LEMONADE Internet-Drafts and RFCs can always = be found at http://www.ietf.org/html.charters/lemonade-charter.html = with more = detail tracked on the supplemental site. Finally, as information, the next meetings of the IETF LEMONADE WG are:=20 * Mar 20-24 - IETF 65 plenary - Dallas, TX=20 * Jul 10-14 - IETF 66 plenary - TBD=20 =09 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 01 10:19:46 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Jlq-00019B-49; Wed, 01 Feb 2006 10:19:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4Jlm-00013U-QI for lemonade@megatron.ietf.org; Wed, 01 Feb 2006 10:19:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07077 for ; Wed, 1 Feb 2006 10:18:05 -0500 (EST) Received: from agminet01.oracle.com ([141.146.126.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4Jwy-00015L-BP for lemonade@ietf.org; Wed, 01 Feb 2006 10:31:16 -0500 Received: from rgmsgw300.us.oracle.com (rgmsgw300.us.oracle.com [138.1.186.49]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k11FJMcL031451; Wed, 1 Feb 2006 09:19:22 -0600 Received: from rgmsgw300.us.oracle.com (localhost [127.0.0.1]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k11FJM8U027488; Wed, 1 Feb 2006 08:19:22 -0700 Received: from us.oracle.com (dhcp-amer-csvpn-gw2-141-144-72-76.vpn.oracle.com [141.144.72.76]) by rgmsgw300.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k11FJLfQ027477 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 1 Feb 2006 08:19:21 -0700 From: "Stephane H. Maes" To: "Zoltan.Ordogh@nokia.com" , "gparsons@nortel.com" , "lemonade@ietf.org" Subject: RE: [lemonade] Draft Liaison to OMA Date: Wed, 1 Feb 2006 07:19:15 -0800 In-Reply-To: <084CB2DF0B7F5E47BC056ABBDF423700018C3DC9@trebe101.NOE.Nokia.com> X-Sent-Folder-Path: Sent Items X-Mailer: Oracle Connector for Outlook 9.0.4.2.8 70113 (11.0.6359) Message-ID: <20060201071916266.00000002632@smaes-lap> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "stephane.maes@oracle.com" List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Oh I see. Good point. Stephane = _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) = -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of Zoltan.Ordogh@nokia.com Sent: Wednesday, February 01, 2006 1:35 AM To: stephane.maes@oracle.com; gparsons@nortel.com; lemonade@ietf.org Subject: RE: [lemonade] Draft Liaison to OMA This is exactly what I am missing from the LS. The message in the LS in unc= lear. = Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: ext Stephane H. Maes [mailto:stephane.maes@oracle.com] Sent: 01 February, 2006 11:16 To: Ordogh Zoltan (Nokia-TP-MSW/Tampere); gparsons@nortel.com; lemonade@iet= f.org Subject: RE: [lemonade] Draft Liaison to OMA As I stated: "fixing the concerns of OMA", tehrefore ensuring no duplicatio= n etc... This doc will explain the pieces that Lemonade profile and the items it add= ress for MEM. Stephane = _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le. Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296 e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!/skype) or stephane_maes@hotmail.com (MSN Messenger) = -----Original Message----- From: Zoltan.Ordogh@nokia.com [mailto:Zoltan.Ordogh@nokia.com] Sent: Wednesday, February 01, 2006 1:13 AM To: stephane.maes@oracle.com; gparsons@nortel.com; lemonade@ietf.org Subject: RE: [lemonade] Draft Liaison to OMA Hi Stephane, while the techincal content of the draft is valid and I agree to it (well, = most if it anyway), I would not go for the RFC status. What will happen when there is an IETF mobile email AD and there is an OMA = mobile email AD? Customers will be confused which one to implement and we are going to be th= e ones who have to explain which one they should choose and why - this will= be difficult. Also, there might be interoperability issues later on. So th= ere should be only one AD. I do not have a preference on where the AD is, t= he important thing is that there is only one. If it is IETF, then the OMA A= D should not be progressed any further and dropped and all future OMA specs= shall reference the IETF AD, or vice versa. This is the reason I would like to clarify the statement in the LS - I beli= eve it is vague - we need a clear message what is going to happen. Thank You. Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of ext Stephane H. Maes Sent: 31 January, 2006 16:49 To: gparsons@nortel.com; lemonade@ietf.org Subject: Re: [lemonade] Draft Liaison to OMA Zoltan, = It seems correct to me: 1) its the LEMONADE WG view as agreed hence a ietf deaft 2) this way its is documented, visible and stored somewhere as a working do= cument hence a draft. This does not imply bor discuss its long term status hence again beung a dr= aft. I personally believe that it makes a lot of sense to have it become RF= C (fizing the concrens raised by OMA of course) when work and relationship = between specs stabilize. Stephane _____ Stephane H. Maes, PhD, Director of Architecture, Mobile, Voice, and Communications Platforms, Orac= le Ph: +1-203-300-7786 (mobile/SMS/skype); Fax / Office UM: +1-650-607-6296. e-mail: stephane.maes@oracle.com IM: shmaes (AIM/Y!) or stephane_maes@hotmail.com (MSN Messenger) -----Original Message----- From: Zoltan.Ordogh@nokia.com Date: Tue, 31 Jan 2006 15:30:34 To:, Subject: RE: [lemonade] Draft Liaison to OMA "The purpose of the WG Internet Draft is to allow this to be documented in = the IETF and to further affirm its status as a WG view." What does it mean? Will it become an RFC later on? Could You please clarify= /reword this sentence? = = Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan.ordogh@nokia.com Phone: +358 50 386 0566 = = ________________________________ From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org] On Behal= f Of ext Glenn Parsons Sent: 25 January, 2006 23:31 To: lemonade@ietf.org Subject: [lemonade] Draft Liaison to OMA Folks, = As agreed, we will be sending a liaison to OMA MEM in time for their Feb me= eting. = As a result, please provide comment on the proposed liaison to OMA by Jan 3= 0th. We will send it on Jan 31st if there is no objection. Cheers, Glenn. = From: IETF LEMONADE Working Group To: OMA MWG MEM Sub Working Group = Title: Regarding the LEMONADE Profile = Response contact: lemonade@ietf.org Purpose: For Action Deadline: March 13, 2006 = The LEMONADE working group (WG) would like to thank the OMA Mobile Email Su= b Working Group for your latest liaison. = Our previous liaison indicated that we have proposed a realization of the O= MA MEM architecture using IETF protocols and that we documented this in an = Internet Draft (see draft-ietf-lemonade-oma-mem-realization-00.txt). The p= urpose of the WG Internet Draft is to allow this to be documented in the IE= TF and to further affirm its status as a WG view. There is no intent to publish the OMA MEM RD, AD or TS in IETF. = As we have indicated before, the LEMONADE WG is working on a set of extensi= ons to IMAP and ESMTP to support mobile email. This set will be succinctly= described in the LEMONADE profile (draft-ietf-lemonade-profile-bis). This= will cover interface ME-2 as well as the notifications aspects of ME-3 in = the OMA MEM AD. The OMA TS can normatively reference the LEMONADE profile.= We appreciate your response to the questions that we had asked in our previ= ous liaison. We have a number of follow-on comments/questions: 1. We will support signed notifications but will add the ability to turn i= t off. = 2. OMA STI is currently being used in CONVERT. However we are concerned w= ith the large number of optional parameters. We would prefer a shorter fin= ite mandatory set (that is extensible). What advice can you offer on a sho= rter set? 3. We will be providing managed SIEVE to manage the filters. Additional m= ethods (such as XDMS) could be used as well. = 4. We are evaluating where in our protocols delays may play a role. We no= te that there may be a tradeoff in mobile phones on battery life vs delay. = What delay aspects are of concern to the OMA - is it roundtrip, network o= r service level? 5. We are aware of the limitations for mutual authentication on mobile dev= ices. TLS is not required, and this could be handled by SASL mechanisms wh= ich are already on mobile phones. 6. Message recall is possible within the submit (i.e., administrative) dom= ain. We indicated that we could design protocol for this based on MSGTRK. = However, in the general end-to-end Internet Mail case it is practically im= possible to design a message recall solution that will reliably work. We would like to draw your attention to the fact that LEMONADE has wrapped = up the first phase of its work. We are currently working on finalizing the= content of Profile bis. Additional input on details required to meet OMA r= equirements have been reviewed, and most have become WG documents. The tim= eline would likely result in conclusion later in early 2006. Up-to-date information on LEMONADE Internet-Drafts and RFCs can always be f= ound at http://www.ietf.org/html.charters/lemonade-charter.html with more detail tracked on= the supplemental site. Finally, as information, the next meetings of the IETF LEMONADE WG are: = * Mar 20-24 - IETF 65 plenary - Dallas, TX = * Jul 10-14 - IETF 66 plenary - TBD = = _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 01 18:12:54 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4R9i-00027S-ON; Wed, 01 Feb 2006 18:12:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4R9g-0001xq-4Y for lemonade@megatron.ietf.org; Wed, 01 Feb 2006 18:12:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25455 for ; Wed, 1 Feb 2006 18:10:54 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4RKc-00058v-4O for lemonade@ietf.org; Wed, 01 Feb 2006 18:24:10 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k11NCBu04205 for ; Wed, 1 Feb 2006 18:12:11 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Feb 2006 18:12:07 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0829A5A4@zcarhxm0.corp.nortel.com> Thread-Topic: Draft Liaison to OMA - revised Thread-Index: AcYnhOu42f8o3a0LShWGZmg1pDtpCw== From: "Glenn Parsons" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 Subject: [lemonade] Draft Liaison to OMA - revised X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1704452885==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1704452885== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C62784.EE282839" This is a multi-part message in MIME format. ------_=_NextPart_001_01C62784.EE282839 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Below is the revised Liaison that we will send. Cheers, Glenn. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From: IETF LEMONADE Working Group To: OMA MWG MEM Sub Working Group Title: Regarding the LEMONADE Profile=09 Response contact: lemonade@ietf.org Purpose: For Action Deadline: March 13, 2006 The LEMONADE working group (WG) would like to thank the OMA Mobile Email Sub Working Group for your latest liaison. Our previous liaison indicated that we have proposed a realization of the OMA MEM architecture using IETF protocols and that we documented this in an Internet Draft (see draft-ietf-lemonade-oma-mem-realization-00.txt). The purpose of the WG Internet Draft is to provide a working document in the IETF to ensure that our work addresses the OMA MEM required features within our scope and to further affirm its status as a WG view. As is the case with some other WG documents in the LEMONADE WG, there is currently no intent to progress this draft to an RFC. Further, there is no intent to publish the OMA MEM RD, AD or TS in IETF. As we have indicated before, the LEMONADE WG is working on a set of extensions to IMAP and ESMTP to support mobile email. This set will be succinctly described in the LEMONADE profile (draft-ietf-lemonade-profile-bis). This will cover the protocol exchanged on interface ME-2 (ME-2a and ME-2b) as well as the notifications aspects of ME-3, referring to the interfaces described in the OMA MEM AD. The OMA TS can normatively reference the LEMONADE profile for these interface aspects and for the MEM protocol. In addition, we are also considering a best practices document on deployment considerations that may be useful to OMA MEM.=20 We appreciate your response to the questions that we had asked in our previous liaison. We have a number of follow-on comments/questions: 1. We will support signed notifications but will add the ability to turn it off. 2. OMA STI is currently being used in CONVERT (the IMAP extension to request static content transformation). However we are concerned with the large number of optional parameters. We would prefer a shorter finite mandatory set (that is extensible). What advice can you offer on a shorter set? 3. We will be providing 'Manage SIEVE Protocol' to manage the filters. Additional methods (such as XDMS) could be used as well by OMA if desired. But a complete set of remote management functionality will be made available by the LEMONADE work as part of the LEMONADE profile. 4. We are evaluating where in our protocols delays may play a role. We note that there may be a tradeoff in mobile phones on battery life vs delay. What delay aspects are of concern to the OMA - is it roundtrip, network or service level? Clearly our design will aim at minimizing delays that are within our control. We would like to make sure we understand the aspect of particular interest to OMA MEM. 5. We are aware of the limitations for mutual authentication on mobile devices. We apologize for the confusion in our previous response. Mutual authentication is a feature provided by SASL (RFC 2222) framework, or SASL + TLS. However the use of TLS is not required, and this could just be handled by SASL mechanisms which are optimized for mobile phone use. 6. Message recall is possible within the submit (i.e., administrative) domain. We indicated that we could design protocol for this based on MSGTRK (RFC 3888). However, in the general end-to-end Internet Mail case it is practically impossible to design a message recall solution that will reliably work. We encourage OMA MEM WG to consider that reality and verify that recall is still a desired target mechanisms for OMA MEM We would like to draw your attention to the fact that LEMONADE has wrapped up the first phase of its work. We are currently working on finalizing the content of Profile bis. Additional input on details required to meet OMA requirements have been reviewed, and most have become WG documents. The timeline would likely result in conclusion in early 2006. Up-to-date information on LEMONADE Internet-Drafts and RFCs can always be found at http://www.ietf.org/html.charters/lemonade-charter.html with more detail tracked on the supplemental site. Finally, as information, the next meetings of the IETF LEMONADE WG are: * Mar 20-24 - IETF 65 plenary - Dallas, TX * Jul 10-14 - IETF 66 plenary - TBD ------_=_NextPart_001_01C62784.EE282839 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft Liaison to OMA - revised

Folks,

Below is the revised Liaison that we = will send.

Cheers,
Glenn.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /FONT>


From: IETF LEMONADE Working = Group
To: OMA MWG MEM Sub Working = Group
Title: Regarding the LEMONADE = Profile  
Response contact:  = lemonade@ietf.org
Purpose:  For Action
Deadline:  March 13, = 2006


The LEMONADE working group (WG) = would like to thank the OMA Mobile Email Sub Working Group for your = latest liaison.

Our previous liaison indicated = that we have proposed a realization of the OMA MEM architecture using = IETF protocols and that we documented this in an Internet Draft (see = draft-ietf-lemonade-oma-mem-realization-00.txt).  The purpose of = the WG Internet Draft is to provide a working document in the IETF to = ensure that our work addresses the OMA MEM required features within our = scope and to further affirm its status as a WG view.  As is the = case with some other WG documents in the LEMONADE WG, there is currently = no intent to progress this draft to an RFC.

Further, there is no intent to = publish the OMA MEM RD, AD or TS in IETF.

As we have indicated before, the = LEMONADE WG is working on a set of extensions to IMAP and ESMTP to = support mobile email.  This set will be succinctly described in the = LEMONADE profile (draft-ietf-lemonade-profile-bis).  This will = cover the protocol exchanged on interface ME-2 (ME-2a and ME-2b) as well = as the notifications aspects of ME-3, referring to the interfaces = described in the OMA MEM AD.  The OMA TS can normatively reference = the LEMONADE profile for these interface aspects and for the MEM = protocol.  In addition, we are also considering a best practices = document on deployment considerations that may be useful to OMA MEM. =

We appreciate your response to = the questions that we had asked in our previous liaison.  We have a = number of follow-on comments/questions:

1.  We will support signed = notifications but will add the ability to turn it off.

2.  OMA STI is currently = being used in CONVERT (the IMAP extension to request static content = transformation).  However we are concerned with the large number of = optional parameters.  We would prefer a shorter finite mandatory = set (that is extensible).  What advice can you offer on a shorter = set?

3.  We will be providing = ‘Manage SIEVE Protocol’ to manage the filters.  = Additional methods (such as XDMS) could be used as well by OMA if = desired.  But a complete set of remote management functionality = will be made available by the LEMONADE work as part of the LEMONADE = profile.

4.  We are evaluating where = in our protocols delays may play a role.  We note that there may be = a tradeoff in mobile phones on battery life vs delay.   What = delay aspects are of concern to the OMA – is it roundtrip, network = or service level? Clearly our design will aim at  minimizing delays = that are within our control. We would like to make  sure we = understand the aspect of particular interest to OMA MEM.

5.  We are aware of the = limitations for mutual authentication on mobile devices.  We = apologize for the confusion in our previous response.  Mutual = authentication is a feature provided by SASL (RFC 2222) framework, or = SASL + TLS. However the use of TLS is not required, and this could just = be handled by SASL mechanisms which are optimized for mobile phone = use.

6.  Message recall is = possible within the submit (i.e., administrative) domain.  We = indicated that we could design protocol for this based on MSGTRK (RFC = 3888).  However, in the general end-to-end Internet Mail case it is = practically impossible to design a message recall solution that will = reliably work. We encourage OMA MEM WG to consider that  reality = and verify that recall is still a desired target mechanisms for OMA = MEM

We would like to draw your = attention to the fact that LEMONADE has wrapped up the first phase of = its work.  We are currently working on finalizing the content of = Profile bis.  Additional input on details required to meet OMA = requirements have been reviewed, and most have become WG = documents.  The timeline would likely result in conclusion in early = 2006.

Up-to-date information on = LEMONADE Internet-Drafts and RFCs can always be found at http://www.ietf.org/html.charters/lemonade-charter.html with more detail tracked on the = supplemental site.

Finally, as information, the next = meetings of the IETF LEMONADE WG are:

  • Mar 20-24 – IETF 65 = plenary – Dallas, TX
  • Jul 10-14 – IETF 66 = plenary - TBD


------_=_NextPart_001_01C62784.EE282839-- --===============1704452885== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============1704452885==-- From lemonade-bounces@ietf.org Mon Feb 06 15:50:24 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6DJY-0007Is-At; Mon, 06 Feb 2006 15:50:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6DJD-0007B6-UI; Mon, 06 Feb 2006 15:50:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22370; Mon, 6 Feb 2006 15:48:22 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6DVS-00057k-Ja; Mon, 06 Feb 2006 16:02:43 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1F6DJB-0001Cr-KZ; Mon, 06 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 06 Feb 2006 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: lemonade@ietf.org Subject: [lemonade] I-D ACTION:draft-ietf-lemonade-rfc2192bis-01.txt X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Enhancements to Internet email to support diverse service environments Working Group of the IETF. Title : IMAP URL Scheme Author(s) : A. Melnikov, et al. Filename : draft-ietf-lemonade-rfc2192bis-01.txt Pages : 22 Date : 2006-2-6 IMAP [IMAP4] is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mail- ing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-rfc2192bis-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-lemonade-rfc2192bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-lemonade-rfc2192bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-6131024.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-lemonade-rfc2192bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-lemonade-rfc2192bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-6131024.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --NextPart-- From lemonade-bounces@ietf.org Wed Feb 08 17:08:50 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6xUY-0006qz-Du; Wed, 08 Feb 2006 17:08:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6xUW-0006qW-UT for lemonade@megatron.ietf.org; Wed, 08 Feb 2006 17:08:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08436 for ; Wed, 8 Feb 2006 17:06:58 -0500 (EST) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6xh3-0008As-ND for lemonade@ietf.org; Wed, 08 Feb 2006 17:21:47 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k18M8NCn030463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 8 Feb 2006 14:08:24 -0800 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k18M8MUg029550; Wed, 8 Feb 2006 14:08:23 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Wed, 8 Feb 2006 14:06:52 -0800 To: Alexey Melnikov From: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-07.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This update looks great. I do have two comments; both should be quite easy fixes: (1) In section 2.4.2. Typo; please change: an MUA. During submission [RFC2476] to: an MUA. During submission [SUBMIT] (2) In section 3.3 The text: LEMONADE compliant mail submission servers MUST ("expand") all BURL is confusing, since it is not clear what the parenthesis mean. I'd suggest simply deleting them. That would make the text: LEMONADE compliant mail submission servers MUST "expand" all BURL -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- The two most common elements in the universe are hydrogen and stupidity. --Harlan Ellison _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 08 21:12:43 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F71IZ-0000J2-Dw; Wed, 08 Feb 2006 21:12:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4gMJ-0007l5-US for lemonade@megatron.ietf.org; Thu, 02 Feb 2006 10:27:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12112; Thu, 2 Feb 2006 10:25:18 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F4gXe-0007oC-DS; Thu, 02 Feb 2006 10:38:43 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F4gLn-00058s-NP; Thu, 02 Feb 2006 10:26:23 -0500 Content-Type: text/plain Mime-Version: 1.0 To: OMA-LIAISON@mail.openmobilealliance.org From: Glenn Parsons(IETF LEMONADE WG) Message-Id: Date: Thu, 02 Feb 2006 10:26:23 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA12112 X-Mailman-Approved-At: Wed, 08 Feb 2006 21:12:38 -0500 Cc: hardie@qualcomm.com, statements@ietf.org, eburger@brooktrout.com, Jerry.Weingarten@comverse.com, dean.willis@softarmor.com, lemonade@ietf.org, Christine.Mera@forapolis.com, gparsons@nortel.com, Dorothy.gellert@nokia.com Subject: [lemonade] New Liaison Statement, "Regarding the LEMONADE Profile" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Title: Regarding the LEMONADE Profile Submission Date: 2006-02-02 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_det= ail.cgi?detail_id=3D193=20 Please reply by 2006-03-13 From: Glenn Parsons(IETF LEMONADE WG) To: OMA MEM(OMA-LIAISON@mail.openmobilealliance.org) Cc: eburger@brooktrout.com Dorothy.gellert@nokia.com hardie@qualcomm.com dean.willis@softarmor.com Christine.Mera@forapolis.com lemonade@ietf.org Jerry.Weingarten@comverse.com Reponse Contact: lemonade@ietf.org Technical Contact: eburger@brooktrout.com gparsons@nortel.com Purpose: For action=20 Body: From: IETF LEMONADE Working Group To: OMA MWG MEM Sub Working Group Title: =09 Response contact: lemonade@ietf.org Purpose: For Action Deadline: March 13, 2006 The LEMONADE working group (WG) would like to thank the OMA Mobile Email = Sub Working Group for your latest liaison. Our previous liaison indicated that we have proposed a realization of the= OMA MEM architecture using IETF protocols and that we documented this in= an Internet Draft (see draft-ietf-lemonade-oma-mem-realization-00.txt). = The purpose of the WG Internet Draft is to provide a working document in= the IETF to ensure that our work addresses the OMA MEM required features= within our scope and to further affirm its status as a WG view. As is t= he case with some other WG documents in the LEMONADE WG, there is current= ly no intent to progress this draft to an RFC. Further, there is no intent to publish the OMA MEM RD, AD or TS in IETF. As we have indicated before, the LEMONADE WG is working on a set of exten= sions to IMAP and ESMTP to support mobile email. This set will be succin= ctly described in the LEMONADE profile (draft-ietf-lemonade-profile-bis).= This will cover the protocol exchanged on interface ME-2 (ME-2a and ME-= 2b) as well as the notifications aspects of ME-3, referring to the interf= aces described in the OMA MEM AD. The OMA TS can normatively reference t= he LEMONADE profile for these interface aspects and for the MEM protocol.= In addition, we are also considering a best practices document on deplo= yment considerations that may be useful to OMA MEM.=20 We appreciate your response to the questions that we had asked in our pre= vious liaison. We have a number of follow-on comments/questions: 1. We will support signed notifications but will add the ability to turn= it off. 2. OMA STI is currently being used in CONVERT (draft-ietf-lemonade-conve= rt). However we are concerned with the large number of optional paramete= rs. We would prefer a shorter finite mandatory set (that is extensible).= What advice can you offer on a shorter set? 3. We will be providing =E2=80=98Manage SIEVE Protocol=E2=80=99 to manag= e the filters. Additional methods (such as XDMS) could be used as well b= y OMA if desired. But a complete set of remote management functionality = will be made available by the LEMONADE work as part of the LEMONADE profi= le. 4. We are evaluating where in our protocols delays may play a role. We = note that there may be a tradeoff in mobile phones on battery life vs del= ay. What delay aspects are of concern to the OMA =E2=80=93 is it roundt= rip, network or service level? Clearly our design will aim at minimizing= delays that are within our control. We would like to make sure we under= stand the aspect of particular interest to OMA MEM. 5. We are aware of the limitations for mutual authentication on mobile d= evices. We apologize for the confusion in our previous response. Mutual= authentication is a feature provided by SASL (RFC 2222) framework, or SA= SL + TLS. However the use of TLS is not required, and this could just be = handled by SASL mechanisms which are optimized for mobile phone use. 6. Message recall is possible within the submit (i.e., administrative) d= omain. We indicated that we could design protocol for this based on MSGT= RK (RFC 3888). However, in the general end-to-end Internet Mail case it = is practically impossible to design a message recall solution that will r= eliably work. We encourage OMA MEM WG to consider that reality and verif= y that recall is still a desired target mechanisms for OMA MEM We would like to draw your attention to the fact that LEMONADE has wrappe= d up the first phase of its work. We are currently working on finalizing= the content of Profile bis. Additional input on details required to mee= t OMA requirements have been reviewed, and most have become WG documents.= The timeline would likely result in conclusion in early 2006. Up-to-date information on LEMONADE Internet-Drafts and RFCs can always be= found at http://www.ietf.org/html.charters/lemonade-charter.html with mo= re detail tracked on the supplemental site. Finally, as information, the next meetings of the IETF LEMONADE WG are: - Mar 20-24 =E2=80=93 IETF 65 plenary =E2=80=93 Dallas, TX - Jul 10-14 =E2=80=93 IETF 66 plenary - TBD Attachment(s): PDF of liaison (https://datatracker.ietf.org/documents/LIAISON/file2= 67.pdf) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 08 21:12:44 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F71Ia-0000JF-0f; Wed, 08 Feb 2006 21:12:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6EMa-0000LR-4U; Mon, 06 Feb 2006 16:57:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09004; Mon, 6 Feb 2006 16:55:54 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6EYr-0004S3-0h; Mon, 06 Feb 2006 17:10:17 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1F6EMP-0008JY-5i; Mon, 06 Feb 2006 16:57:25 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 06 Feb 2006 16:57:25 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Wed, 08 Feb 2006 21:12:36 -0500 Cc: lemonade mailing list , lemonade chair , Internet Architecture Board , lemonade chair , RFC Editor Subject: [lemonade] Protocol Action: 'Lemonade Profile' to Proposed Standard X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org The IESG has approved the following document: - 'Lemonade Profile ' as a Proposed Standard This document is the product of the Enhancements to Internet email to support diverse service environments Working Group. The IESG contact persons are Ted Hardie and Scott Hollenbeck. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-07.txt Technical Summary The LEMONADE profile is a profile (a set of required extensions, restrictions and usage modes) of the IMAP and mail submission protocols. This profile allows clients (especially those that are constrained in memory, bandwidth, processing power, or other areas) to efficiently use IMAP and Submission to access and submit mail. This includes the ability to forward received mail without needing to download and upload the mail, to optimize submission and to efficiently resynchronize in case of loss of connectivity with the server. Working Group Summary The IETF LEMONADE WG has done considerable work on developing protocols to support features to improve email access in diverse environments. This includes various efficiency improvements to the base IMAP and SMTP protocols that have been documented in separate documents. A notable addition is a mechanism to forward a message without downloading it to the client. The profile explains this and other improvements along with examples. To aid interoperability, this document indicates which IMAP & SMTP extensions are mandatory. Though work is continuing on additional improvements, there is consensus in the WG to progress the LEMONADE profile. Protocol Quality The profile lists several new features to IMAP and SMTP that have already been implemented by several vendors. This has already resulted in changes to the spec to clarify the protocols. In addition it has resulted in removing some other new protocols that are not fully baked at this time and will be included in a later revision of this document. The document was reviewed for the IESG by Ted Hardie. The PROTO shepherd is Glenn Parsons. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 09 05:59:57 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F79Wn-0006a3-O9; Thu, 09 Feb 2006 05:59:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F79Wm-0006ZY-Pt for lemonade@megatron.ietf.org; Thu, 09 Feb 2006 05:59:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09325 for ; Thu, 9 Feb 2006 05:58:05 -0500 (EST) Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F79jP-0002Q0-MR for lemonade@ietf.org; Thu, 09 Feb 2006 06:13:01 -0500 Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 9 Feb 2006 10:58:58 +0000 Message-ID: <43EB206C.60904@isode.com> Date: Thu, 09 Feb 2006 10:58:52 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Randall Gellens Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-profile-07.txt References: In-Reply-To: MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Randall Gellens wrote: > This update looks great. I do have two comments; both should be quite > easy fixes: The document just got approved, but we will address the issues during AUTH48. > (1) > > In section 2.4.2. > Typo; please change: > an MUA. During submission [RFC2476] > to: > an MUA. During submission [SUBMIT] > > > (2) > > In section 3.3 > The text: > LEMONADE compliant mail submission servers MUST ("expand") all BURL > is confusing, since it is not clear what the parenthesis mean. I'd > suggest simply deleting them. > That would make the text: > LEMONADE compliant mail submission servers MUST "expand" all BURL > _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Feb 13 14:49:41 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8jhd-0004KJ-6i; Mon, 13 Feb 2006 14:49:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8jhb-0004KB-Ls for lemonade@megatron.ietf.org; Mon, 13 Feb 2006 14:49:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18562 for ; Mon, 13 Feb 2006 14:47:53 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8jvG-0003jK-JC for lemonade@ietf.org; Mon, 13 Feb 2006 15:03:47 -0500 Received: from ihemail2.lucent.com (h192-11-222-163.lucent.com [192.11.222.163]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k1DJnZGk025630 for ; Mon, 13 Feb 2006 13:49:36 -0600 (CST) Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k1DJnYvv014205 for ; Mon, 13 Feb 2006 13:49:34 -0600 (CST) Received: by oh0012exch001p.cb.lucent.com with Internet Mail Service (5.5.2657.72) id <1SHYY435>; Mon, 13 Feb 2006 14:49:34 -0500 Message-ID: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> From: "Esh, Thomas D (Tom)" To: "'lemonade@ietf.org'" Date: Mon, 13 Feb 2006 14:49:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.8 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [lemonade] RFC 3516 (IMAP4 Binary Content Extension) Question X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0635968921==" Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0635968921== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C630D6.9C911A0C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C630D6.9C911A0C Content-Type: text/plain I have a question regarding RFC 3516 (IMAP4 Binary Content Extension). What should be the value of a FETCH BINARY.SIZE on a multipart/mixed component? The encoding types of the parts could vary. Should the IMAP4 server return the size as if all the components were decoded? The same is true of a message/rfc822 component or any component that contains other components. Thanks Tom Thomas D. Esh Email: esh@lucent.com Lucent Technologies Work: 614-367-4390 Room 4O05-1L Mobile: 740-334-2319 6100 East Broad Street Home: 740-321-1245 Columbus, OH 43213 MMS: 7403342319@vzwpix.com Our lives begin to end the day we become silent about things that matter. -- Martin Luther King, Jr. ------_=_NextPart_001_01C630D6.9C911A0C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RFC 3516 (IMAP4 Binary Content Extension) Question

I have a question regarding RFC 3516 = (IMAP4 Binary Content Extension).

What should be the value of a FETCH = BINARY.SIZE on a multipart/mixed component?
The encoding types of the parts could = vary.  Should the IMAP4 server return the size
as if all the components were = decoded?

The same is true of a message/rfc822 = component or any component that contains
other components.

Thanks
Tom

Thomas D. = Esh           &nb= sp;   Email: esh@lucent.com
Lucent = Technologies          = Work: 614-367-4390
Room = 4O05-1L           = ;    Mobile: 740-334-2319
6100 East Broad = Street       Home: 740-321-1245
Columbus, OH  = 43213           MMS: = 7403342319@vzwpix.com

Our lives begin to end the day = we become silent about
things that matter. -- Martin = Luther King, Jr.

------_=_NextPart_001_01C630D6.9C911A0C-- --===============0635968921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============0635968921==-- From lemonade-bounces@ietf.org Mon Feb 13 15:43:39 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8kXr-0005KL-O9; Mon, 13 Feb 2006 15:43:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8kXp-0005IN-LM for lemonade@megatron.ietf.org; Mon, 13 Feb 2006 15:43:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21590 for ; Mon, 13 Feb 2006 15:41:53 -0500 (EST) Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8klR-00058M-Q2 for lemonade@ietf.org; Mon, 13 Feb 2006 15:57:46 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1F8kXi-0006ZL-Qg; Mon, 13 Feb 2006 20:43:30 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id DFEF4498003; Mon, 13 Feb 2006 20:54:41 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25019-02; Mon, 13 Feb 2006 20:54:39 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 49DEE498002; Mon, 13 Feb 2006 20:54:39 +0000 (GMT) Date: Mon, 13 Feb 2006 20:43:27 +0000 Subject: Re: [lemonade] RFC 3516 (IMAP4 Binary Content Extension) Question References: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> In-Reply-To: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> MIME-Version: 1.0 Message-Id: <23543.1139863408.056195@peirce.dave.cridland.net> From: Dave Cridland To: "Esh\, Thomas D \(Tom\)" Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Mon Feb 13 19:49:33 2006, Esh, Thomas D (Tom) wrote: > > I have a question regarding RFC 3516 (IMAP4 Binary Content > Extension). > > What should be the value of a FETCH BINARY.SIZE on a > multipart/mixed component? > The encoding types of the parts could vary. Should the IMAP4 > server return the size > as if all the components were decoded? > > The same is true of a message/rfc822 component or any component > that contains > other components. This came up on the IMAP mailing list a little while ago - you may find the full discussion in the archives, but as I recall, the BINARY.SIZE for multipart/mixed is the same as its encoded size, because the multipart *itself* is encoded using an identity encoding. It's the same for message/rfc822, etc. These all use 7BIT CTE, nothing else. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Feb 13 15:57:56 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8klg-000211-Mg; Mon, 13 Feb 2006 15:57:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8kle-00020m-Hd for lemonade@megatron.ietf.org; Mon, 13 Feb 2006 15:57:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22968 for ; Mon, 13 Feb 2006 15:56:09 -0500 (EST) Received: from mxout1.cac.washington.edu ([140.142.32.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8kzK-0005o6-RI for lemonade@ietf.org; Mon, 13 Feb 2006 16:12:03 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout1.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k1DKvpLp015909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Feb 2006 12:57:52 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k1DKvow5022149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Feb 2006 12:57:51 -0800 Date: Mon, 13 Feb 2006 12:57:50 -0800 (PST) From: Mark Crispin To: "Esh, Thomas D (Tom)" Subject: Re: [lemonade] RFC 3516 (IMAP4 Binary Content Extension) Question In-Reply-To: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> Message-ID: References: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/Plain; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: "'lemonade@ietf.org'" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Mon, 13 Feb 2006, Esh, Thomas D (Tom) wrote: > What should be the value of a FETCH BINARY.SIZE on a multipart/mixed > component? The encoding types of the parts could vary. Should the IMAP4 > server return the size as if all the components were decoded? Only terminal MIME parts (that is, those which are not MULTIPART or MESSAGE/RFC822) have an encoding other than 7BIT (in certain circumstances, a part of type MESSAGE/RFC822 may have an encoding of 8BIT). Thus, it is meaningless to FETCH BINARY.SIZE or BINARY on such parts. I'm surprised that RFC 3516 does not forbid non-terminal nodes. It should. Note that BINARY does not take the same type of part specifier as BODY, In particular, you can not use any RFC 3501 section-text BODY parts (HEADER, TEXT, MIME, etc.) with BINARY. Thus, there is no BINARY specifier for a MULTIPART directly under a message; the question only comes up with a nested MULTIPART. So, in effect, there's a partial syntax prohibition of using BINARY on non-terminal parts. Here is my advice to you: 1) In your client, do NOT attempt to FETCH BINARY or BINARY.SIZE for a non-terminal body part, because it may be forbidden in the future. It does no good to use it; and in the case of BINARY.SIZE it's a complete waste of time since you already have that value from the BODYSTRUCTURE. 2) In your server, treat FETCH BINARY as equivalent to FETCH BODY, and FETCH BINARY.SIZE as a request for the number in the BODYSTRUCTURE, whenever the part specifier refers to a MULTIPART or MESSAGE/RFC822. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Feb 13 16:15:30 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8l2g-0008Ia-Th; Mon, 13 Feb 2006 16:15:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F8l2f-0008IO-34 for lemonade@megatron.ietf.org; Mon, 13 Feb 2006 16:15:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24156 for ; Mon, 13 Feb 2006 16:13:44 -0500 (EST) Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F8lGD-0006GN-Db for lemonade@ietf.org; Mon, 13 Feb 2006 16:29:38 -0500 Received: from [10.8.9.61] ([66.119.182.37]) (authenticated bits=0) by orthanc.ca (8.13.4/8.13.4) with ESMTP id k1DLF6a6066601; Mon, 13 Feb 2006 14:15:09 -0700 (MST) (envelope-from lyndon@orthanc.ca) Message-ID: <43F0F6D5.90408@orthanc.ca> Date: Mon, 13 Feb 2006 13:15:01 -0800 From: Lyndon Nerenberg User-Agent: Thunderbird 1.5 (X11/20060201) MIME-Version: 1.0 To: Mark Crispin Subject: Re: [lemonade] RFC 3516 (IMAP4 Binary Content Extension) Question References: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on orthanc.ca X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: "'lemonade@ietf.org'" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org > I'm surprised that RFC 3516 does not forbid non-terminal nodes. It should. And it will when the next revision gets published. It's time to gather up an errata list and get going on this. I need someone to document the issues that were raised in Vancouver as well. --lyndon _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Feb 14 19:20:32 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F9API-0006pJ-8B; Tue, 14 Feb 2006 19:20:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F918k-0007Xe-IO for lemonade@megatron.ietf.org; Tue, 14 Feb 2006 09:26:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29551; Tue, 14 Feb 2006 09:25:02 -0500 (EST) Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F91MV-0003Lh-1N; Tue, 14 Feb 2006 09:41:07 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k1EEQT9W022084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Feb 2006 14:26:29 GMT Received: from root by ietf.org with local (Exim 4.43) id 1F918P-0007Do-F6; Tue, 14 Feb 2006 09:26:29 -0500 Received: from mirror by ietf.org with local (Exim 4.43) id 1F8SRI-0004bc-Vl; Sun, 12 Feb 2006 20:23:40 -0500 Content-Type: text/plain Mime-Version: 1.0 To: Gparsons@nortel.com, eburger@brooktrout.com From: Dean Willis(OMA) Message-Id: Date: Sun, 12 Feb 2006 20:23:40 -0500 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by willow.neustar.com id k1EEQT9W022084 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 14 Feb 2006 19:20:28 -0500 Cc: lemonade@ietf.org, Ted Hardie , Scott Hollenbeck , Jerry.weingarten@comverse.com, statements@ietf.org Subject: [lemonade] New Liaison Statement, "OMA LS_0082 Liaison on Mobile E-Mail" X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Title: OMA LS_0082 Liaison on Mobile E-Mail Submission Date: 2006-02-12 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_det= ail.cgi?detail_id=3D198=20 From: Dean Willis(OMA) To: IETF LEMONADE WG(Gparsons@nortel.com, eburger@brooktrout.com) Cc: lemonade@ietf.org Ted Hardie Scott Hollenbeck Reponse Contact: Jerry.weingarten@comverse.com Technical Contact: Jerry.weingarten@comverse.com Purpose: For information=20 Body: 1 Overview=20 This liaison is in response to specific questions raised in a liaison fro= m IETF LEMONADE in =20 OMA-MEM-2006-0023-ILS-fromIETF-on-LEMONADE-Profile.=20 2 Proposal=20 OMA MWG-MEM thanks IETF LEMONADE for their consideration of our previous = liaison. We understand, and will take into consideration, your comments.= =20 However, we have the following additional comments to your questions:=20 1. (on your question 2) MWG-MEM has not yet considered this and thanks I= ETF LEMONADE for bringing=20 this to our attention. As a result, we will study the possibility of a s= horter list that is mandatory for the MEM enabler (and likely solicit the= advice of the OMA STI group). We will provide IETF LEMONADE an update o= n this after our next meeting. =20 2. (on your question 4) According to the MWG-MEM RD, only notification a= nd send/receive roundtrip delay is of concern at this point. We will inf= orm IETF LEMONADE if these requirements change.=20 3. (on your question 6) According to the MWG-MEM RD, message recall is s= till a requirement. Specifically, that the client be able to request a r= ecall and that success/failure be indicated back. MWG-MEM will consider = IETF LEMONADE=E2=80=99s input in its realization of this requirement and = will let IETF know if any further work is requested. Note that work conti= nues on the MEM architecture document (AD). OMA MWG-MEM intends to conti= nue to provide detailed updates of the Mobile e-mail enabler related acti= vities as our work progresses. OMA MWG-MEM will hold its next meeting on = April 3-7 in Vancouver, Canada.=20 3 Requested Action(s)=20 We request the IETF LEMONADE Working Group to consider and accept these c= omments. =20 4 Conclusion OMA MWG-MEM SWG wishes to thank the IETF LEMONADE WG for its= response to OMA MWG-MEM=E2=80=99s previous liaison and for the analysis = and feedback they provided regarding the draft OMA Mobile Email RD and AD. =20 OMA MWG-MEM looks forward to continued collaboration on these matters wit= h the IETF LEMONADE WG. Finally, OMA MWG-MEM wishes to thank the IETF LE= MONADE WG for its kind consideration of this liaison. Attachment(s): LS_0082 on Mobile E-Mail (https://datatracker.ietf.org/documents/LIA= ISON/file272.pdf) _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 17 09:41:02 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6n8-0006pQ-G0; Fri, 17 Feb 2006 09:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA6n7-0006ou-D7 for lemonade@megatron.ietf.org; Fri, 17 Feb 2006 09:41:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13335 for ; Fri, 17 Feb 2006 09:39:12 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA71U-0002Dh-Cd for lemonade@ietf.org; Fri, 17 Feb 2006 09:55:57 -0500 Received: from ihemail1.lucent.com (h192-11-222-161.lucent.com [192.11.222.161]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k1HEeqoI009485; Fri, 17 Feb 2006 08:40:53 -0600 (CST) Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k1HEepwa011881; Fri, 17 Feb 2006 08:40:52 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 17 Feb 2006 08:40:51 -0600 Message-ID: <54E40201497DF142B06B27255953F797AC2218@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: "'Randall Gellens'" , lemonade@ietf.org Date: Fri, 17 Feb 2006 08:40:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Subject: [lemonade] Future Delivery edit list X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org I took an action item in London to post a -04 "final" version of the future delivery draft. I have mined my email logs and found only the below message from Randy commenting on the BNF. If there issues others, please shout now. Randy suggests a clean-up to the BNF, but also suggests a esthetic preference for an alternate syntax. Can I get a response from those folks who care as to which they prefer? Based on the responses, I will pick one. a) HOLD=for;future-release-interval and HOLD=until;future-release-date-time - or - b) HOLDFOR=future-release-interval and HOLDUNTIL=future-release-date-time Greg V. -----Original Message----- From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On Behalf Of Randall Gellens Sent: Monday, November 07, 2005 7:20 PM To: lemonade@ietf.org Subject: Re: [lemonade] Question 2: how to change the extension framework Sorry about replying to an old thread. Now that -03 has been published and went with the (IMHO) uglier syntax, the ABNF for it looks odd: Using ABNF [n2], the syntax of this parameter is as follows: future-release-interval = future-release-integer future-release-date-time = Internet-style-date-time-UTC hold-type = "for" / "until" hold-info = future-release-interval / future-release-date-time hold-param = "HOLD=" (("for;" future-release-interval) / ("until;" future-release-date-time)) The absence of this parameter on the MAIL command does not imply a default value for this parameter. NOTE: The ABNF for hold-param contains expanded alternatives because of a deficiency in ABNF; there is no way to indicate described in the text. If we could, then the resulting ABNF for hold-param would be: hold-param = "HOLD=" hold-type ";" hold-info It looks to me like the wording in the NOTE is missing a line. But how about making the ABNF: hold-param = "HOLD=" hold-for / hold-until hold-for = "for;" future-release-interval hold-until = "until;" future-release-date-time future-release-interval = future-release-integer future-release-date-time = Internet-style-date-time-UTC This would cleanly show that you can use one form or the other. Although I still think using "HOLD-FOR" and "HOLD-UNTIL" followed immediately by the value would be cleaner than using "HOLD" and then having an extra hold-type and semicolon before the value. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Premature optimization is the root of all evil --C. A. R. Hoare _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 17 11:02:29 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA83x-00065N-K7; Fri, 17 Feb 2006 11:02:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA74M-0005js-Ke for lemonade@megatron.ietf.org; Fri, 17 Feb 2006 09:58:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16120 for ; Fri, 17 Feb 2006 09:57:01 -0500 (EST) Received: from monkey.teamware.com ([62.61.83.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA7Ij-0003J6-Tf for lemonade@ietf.org; Fri, 17 Feb 2006 10:13:46 -0500 Received: from intrepid (intrepid.teamw.com [10.142.128.11]) by monkey.teamware.com (8.13.1/8.13.1) with ESMTP id k1HF1nJ8023824; Fri, 17 Feb 2006 17:01:49 +0200 Received: from [10.142.130.127] ([10.142.130.127]) by intrepid with ESMTP id m2hhfi9t; 17 Feb 2006 17:15:00 +0200 Message-ID: <43F5E487.9080305@teamware.com> Date: Fri, 17 Feb 2006 16:58:15 +0200 From: Antony Bowesman Organization: Teamware Group User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vaudreuil, Greg M (Greg)" Subject: Re: [lemonade] Future Delivery edit list References: <54E40201497DF142B06B27255953F797AC2218@il0015exch007u.ih.lucent.com> In-Reply-To: <54E40201497DF142B06B27255953F797AC2218@il0015exch007u.ih.lucent.com> X-TWG-MDN: never Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TWG-MailScanner-Information: Please contact the ISP for more information X-TWG-MailScanner: Found to be clean X-TWG-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 5, autolearn=not spam) X-MailScanner-From: adb@teamware.com X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: 'Randall Gellens' , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org Vaudreuil, Greg M (Greg) wrote: > > Randy suggests a clean-up to the BNF, but also suggests a esthetic preference > for an alternate syntax. Can I get a response from those folks who care as > to which they prefer? Based on the responses, I will pick one. > > a) HOLD=for;future-release-interval and HOLD=until;future-release-date-time > > - or - > > b) HOLDFOR=future-release-interval and HOLDUNTIL=future-release-date-time I agree with Randy about b; it's cleaner with marginally less parsing needed. hold-type or hold-param does not allow extensions, so doesn't add value. Antony > > Greg V. > > -----Original Message----- From: lemonade-bounces@ietf.org > [mailto:lemonade-bounces@ietf.org]On Behalf Of Randall Gellens Sent: Monday, > November 07, 2005 7:20 PM To: lemonade@ietf.org Subject: Re: [lemonade] > Question 2: how to change the extension framework > > > Sorry about replying to an old thread. Now that -03 has been published and > went with the (IMHO) uglier syntax, the ABNF for it looks odd: > > Using ABNF [n2], the syntax of this parameter is as follows: > > future-release-interval = future-release-integer > > future-release-date-time = Internet-style-date-time-UTC > > hold-type = "for" / "until" > > hold-info = future-release-interval / future-release-date-time > > hold-param = "HOLD=" (("for;" future-release-interval) / ("until;" > future-release-date-time)) > > The absence of this parameter on the MAIL command does not imply a default > value for this parameter. > > NOTE: The ABNF for hold-param contains expanded alternatives because of a > deficiency in ABNF; there is no way to indicate described in the text. If > we could, then the resulting ABNF for hold-param would be: > > hold-param = "HOLD=" hold-type ";" hold-info > > > It looks to me like the wording in the NOTE is missing a line. > > But how about making the ABNF: > > hold-param = "HOLD=" hold-for / hold-until hold-for = "for;" > future-release-interval hold-until = "until;" future-release-date-time > future-release-interval = future-release-integer future-release-date-time = > Internet-style-date-time-UTC > > This would cleanly show that you can use one form or the other. > > Although I still think using "HOLD-FOR" and "HOLD-UNTIL" followed immediately > by the value would be cleaner than using "HOLD" and then having an extra > hold-type and semicolon before the value. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 17 13:55:05 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAAkz-0008T2-BK; Fri, 17 Feb 2006 13:55:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAAkx-0008Sb-EG for lemonade@megatron.ietf.org; Fri, 17 Feb 2006 13:55:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21677 for ; Fri, 17 Feb 2006 13:53:15 -0500 (EST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAAzN-0001uD-1a for lemonade@ietf.org; Fri, 17 Feb 2006 14:10:01 -0500 Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k1HIsv8u017299 for ; Fri, 17 Feb 2006 11:54:57 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IUU00901HJHR300@mail-amer.sun.com> (original mail from Anil.Srivastava@Sun.COM) for lemonade@ietf.org; Fri, 17 Feb 2006 11:54:57 -0700 (MST) Received: from [192.18.127.162] (host-162-127-18-192.iplanet.com [192.18.127.162]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IUU00IKEHVF3660@mail-amer.sun.com>; Fri, 17 Feb 2006 11:54:57 -0700 (MST) Date: Fri, 17 Feb 2006 10:54:49 -0800 (Pacific Standard Time) From: Anil SRIVASTAVA Subject: Re: [lemonade] Future Delivery edit list In-reply-to: <54E40201497DF142B06B27255953F797AC2218@il0015exch007u.ih.lucent.com> To: "Vaudreuil, Greg M (Greg)" Message-id: Organization: Sun Microsystems [http://www.sun.com] MIME-version: 1.0 X-Mailer: Pine 4.64 (Windows XP) - Got Pine? [http://www.washington.edu/pine] Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT Accept-Language: English; en X-Message-Class: normal X-Endorsement: Message brought to you by Sun Java Enterprise System Communication Suite 4 References: <54E40201497DF142B06B27255953F797AC2218@il0015exch007u.ih.lucent.com> X-Message-flag: Outlook: the best virus distribution system around X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: 7BIT Cc: 'Randall Gellens' , lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anil.Srivastava@Sun.COM List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On 2006-02-17/08:40 [-0600], gregv@lucent.com [Vaudreuil, Greg M (Greg)] wrote: > > I took an action item in London to post a -04 "final" version of the future delivery draft. I have mined my email logs and found only the below message from Randy commenting on the BNF. > > If there issues others, please shout now. > > Randy suggests a clean-up to the BNF, but also suggests a esthetic > preference for an alternate syntax. Can I get a response from those > folks who care as to which they prefer? Based on the responses, I > will pick one. > > a) HOLD=for;future-release-interval and HOLD=until;future-release-date-time > > - or - > > b) HOLDFOR=future-release-interval and HOLDUNTIL=future-release-date-time 'b' is a cleaner syntax. Anil > > Greg V. > > -----Original Message----- > From: lemonade-bounces@ietf.org [mailto:lemonade-bounces@ietf.org]On > Behalf Of Randall Gellens > Sent: Monday, November 07, 2005 7:20 PM > To: lemonade@ietf.org > Subject: Re: [lemonade] Question 2: how to change the extension > framework > > > Sorry about replying to an old thread. Now that -03 has been > published and went with the (IMHO) uglier syntax, the ABNF for it > looks odd: > > Using ABNF [n2], the syntax of this parameter is as follows: > > future-release-interval = future-release-integer > > future-release-date-time = Internet-style-date-time-UTC > > hold-type = "for" / "until" > > hold-info = future-release-interval / future-release-date-time > > hold-param = "HOLD=" (("for;" future-release-interval) / > ("until;" future-release-date-time)) > > The absence of this parameter on the MAIL command does not imply a > default value for this parameter. > > NOTE: The ABNF for hold-param contains expanded alternatives > because of a deficiency in ABNF; there is no way to indicate > described in the text. If we could, then the resulting ABNF for > hold-param would be: > > hold-param = "HOLD=" hold-type ";" hold-info > > > It looks to me like the wording in the NOTE is missing a line. > > But how about making the ABNF: > > hold-param = "HOLD=" hold-for / hold-until > hold-for = "for;" future-release-interval > hold-until = "until;" future-release-date-time > future-release-interval = future-release-integer > future-release-date-time = Internet-style-date-time-UTC > > This would cleanly show that you can use one form or the other. > > Although I still think using "HOLD-FOR" and "HOLD-UNTIL" followed > immediately by the value would be cleaner than using "HOLD" and then > having an extra hold-type and semicolon before the value. > -- > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly-selected tag: --------------- > Premature optimization is the root of all evil > --C. A. R. Hoare > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > _______________ Anil SRIVASTAVA anil.srivastava@Sun.COM _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 17 14:16:21 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAB5Z-00056b-9r; Fri, 17 Feb 2006 14:16:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAB5X-00056W-Oq for lemonade@megatron.ietf.org; Fri, 17 Feb 2006 14:16:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23128 for ; Fri, 17 Feb 2006 14:14:31 -0500 (EST) Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FABK1-0002jR-PO for lemonade@ietf.org; Fri, 17 Feb 2006 14:31:18 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k1HJGH9m000517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Feb 2006 11:16:17 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k1HJGG49020037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 17 Feb 2006 11:16:17 -0800 Date: Fri, 17 Feb 2006 11:16:16 -0800 (PST) From: Mark Crispin To: lemonade@ietf.org Subject: Re: [lemonade] Future Delivery edit list In-Reply-To: Message-ID: References: <54E40201497DF142B06B27255953F797AC2218@il0015exch007u.ih.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri, 17 Feb 2006, Anil SRIVASTAVA wrote: >> a) HOLD=for;future-release-interval and HOLD=until;future-release-date-time >> - or - >> b) HOLDFOR=future-release-interval and HOLDUNTIL=future-release-date-time > 'b' is a cleaner syntax. Unless it is intended that there be expansion space for other "hold" options, (b) is preferable to (a). I believe that it is worth the exercise to consider, and to reject explicitly, the possibility of other "hold" options. In other words, we should attempt the exercise of coming up with other possible "hold" options, and satisfy ourselves that they are undesirable and/or useless. That way, we will also have the transcript of that discussion in the list archives, so that years from now when we are second-guessed, we can refer back to the discussion. I personally believe that other "hold" options will turn out to be undesirable and/or useless. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 17 15:41:10 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FACPe-0004G1-Cp; Fri, 17 Feb 2006 15:41:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FACPc-0004E0-LZ for lemonade@megatron.ietf.org; Fri, 17 Feb 2006 15:41:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02854 for ; Fri, 17 Feb 2006 15:39:19 -0500 (EST) Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FACdx-0007dK-GZ for lemonade@ietf.org; Fri, 17 Feb 2006 15:56:07 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FACPQ-0002DD-A8; Fri, 17 Feb 2006 20:40:56 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 4F781498003; Fri, 17 Feb 2006 20:52:49 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18180-10; Fri, 17 Feb 2006 20:52:46 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 31577498002; Fri, 17 Feb 2006 20:52:46 +0000 (GMT) Date: Fri, 17 Feb 2006 20:40:51 +0000 Subject: Re: [lemonade] Future Delivery edit list References: <54E40201497DF142B06B27255953F797AC2218@il0015exch007u.ih.lucent.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <24385.1140208852.645487@peirce.dave.cridland.net> From: Dave Cridland To: Mark Crispin Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Fri Feb 17 19:16:16 2006, Mark Crispin wrote: > On Fri, 17 Feb 2006, Anil SRIVASTAVA wrote: >>> a) HOLD=for;future-release-interval and >>> HOLD=until;future-release-date-time >>> - or - >>> b) HOLDFOR=future-release-interval and >>> HOLDUNTIL=future-release-date-time >> 'b' is a cleaner syntax. > > Unless it is intended that there be expansion space for other > "hold" options, (b) is preferable to (a). > > I believe that it is worth the exercise to consider, and to reject > explicitly, the possibility of other "hold" options. In other > words, we should attempt the exercise of coming up with other > possible "hold" options, and satisfy ourselves that they are > undesirable and/or useless. > > Well, this sounds like an entertaining diversion. :-) Both existing hold functions are, at their core, "Hold until a specific time", although they vary in how that time is specified. The only other family I can think of is a "Hold until an event". There needs to be some corresponding mechanism to indicate that the event has happened, so this is really "Hold until explicit release", and the most generic version of this would use further ESMTP in some future session to "release" the message. I can implement this now as a BURL based send, but that might lose the envelope, and does require a certain degree of infrastructure (which Lemonade mandates, but still). Alternately, I can implement by using CHECKPOINT, and sending by simply terminating the message at a later date, but the use of CHECKPOINT with BURL/BDAT is undefined, as far as I know. Note that *with* CHECKPOINT, we can also easily build any specific "Release this message when X happens", by supplying the most likely observing server of event X with the TRANSID to release (by using BDAT 0 LAST, of course). Moreover, CHECKPOINT in a Lemonade setting would appear to be a sensible avenue to explore further anyway - I implemented it server-side a while ago, but I've not yet done the client side. In any case, it would seem that further extending future delivery hold options to encompass "hold until an event" would be the wrong way of achieving that goal - not only would it mean much more work, but it'd yield fewer side-benefits. A time-based release criteria is a specialization of a generic event based release criteria, and it happens that since there is no "internet cron", this does need extra hooks in order to support it - others do not, or if they do, submission is not the place to put the hooks. That seems to support Mark's argument that we're unlikely to do any further HOLD=xxx; beyond what we have. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Feb 18 05:29:23 2006 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAPL9-00017Y-Mt; Sat, 18 Feb 2006 05:29:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAPL7-000165-Sb for lemonade@megatron.ietf.org; Sat, 18 Feb 2006 05:29:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06277 for ; Sat, 18 Feb 2006 05:27:32 -0500 (EST) Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAPZa-0000o8-R1 for lemonade@ietf.org; Sat, 18 Feb 2006 05:44:28 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FAPKw-0007Vw-C5; Sat, 18 Feb 2006 10:29:10 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 9EB20498004; Sat, 18 Feb 2006 10:41:09 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23530-03; Sat, 18 Feb 2006 10:41:06 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 4FAEF498002; Sat, 18 Feb 2006 10:41:06 +0000 (GMT) Date: Sat, 18 Feb 2006 10:29:05 +0000 Subject: Re: [lemonade] RFC 3516 (IMAP4 Binary Content Extension) Question References: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> <43F0F6D5.90408@orthanc.ca> In-Reply-To: <43F0F6D5.90408@orthanc.ca> MIME-Version: 1.0 Message-Id: <24385.1140258546.627271@peirce.dave.cridland.net> From: Dave Cridland To: Lyndon Nerenberg Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: lemonade-bounces@ietf.org Errors-To: lemonade-bounces@ietf.org On Mon Feb 13 21:15:01 2006, Lyndon Nerenberg wrote: >> I'm surprised that RFC 3516 does not forbid non-terminal nodes. >> It should. > > And it will when the next revision gets published. It's time to > gather up an errata list and get going on this. I need someone to > document the issues that were raised in Vancouver as well. Looking through my INBOX: 1) LITERAL+ interaction. (I know it's generally felt that using LITERAL+ with APPEND is bad, but this isn't the case with CATENATE/MULTIAPPEND as well.) 2) Signalling whether uploads will always be rejected with UNKNOWN-CTE. 3) S/MIME and Binary mess. (Not an IMAP BINARY issue as such, but still needs addressing. I'm not clear on what the issues are, precisely, I assume S/MIME signs the representation and not a canonical form.) 4) Non-terminal MIME node handling. 5) When to issue UNKNOWN-CTE. (ie, before or after the literal transmission). 6) Section 4.4 ambiguity WRT content conversion. I've a message dating from last May (2005-05-09 in fact) from you (Lyndon), subject "RFC3516", which might be useful - let me know if you need a copy, or if you'd like it forwarded to the list. Is this a good enough start? Have I missed anything? (I've not looked through the Vancouver minutes, just added those items I could recall.) Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Feb 18 14:39:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAXvt-00011o-Hd; Sat, 18 Feb 2006 14:39:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAXvs-00011j-MP for lemonade@ietf.org; Sat, 18 Feb 2006 14:39:52 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAXvr-0006Gy-A6 for lemonade@ietf.org; Sat, 18 Feb 2006 14:39:52 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FAXvp-0001sI-RU; Sat, 18 Feb 2006 19:39:49 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 17318498003; Sat, 18 Feb 2006 19:51:53 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26234-08; Sat, 18 Feb 2006 19:51:50 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 078F4498002; Sat, 18 Feb 2006 19:51:50 +0000 (GMT) Date: Sat, 18 Feb 2006 19:39:45 +0000 Subject: Re: [lemonade] RFC 3516 (IMAP4 Binary Content Extension) Question References: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> <43F0F6D5.90408@orthanc.ca> <24385.1140258546.118882@peirce.dave.cridland.net> In-Reply-To: <24385.1140258546.118882@peirce.dave.cridland.net> MIME-Version: 1.0 Message-Id: <24385.1140291586.251580@peirce.dave.cridland.net> From: Dave Cridland To: Lyndon Nerenberg Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sat Feb 18 10:29:05 2006, Dave Cridland wrote: > 2) Signalling whether uploads will always be rejected with > UNKNOWN-CTE. Arnt pointed out this is a little overbroad, which is quite true. This is not a situation we should encourage, but the fact remains that some IMAP BINARY implementations in the wild reject all attempts at an APPEND with a Binary CTE with UNKNOWN-CTE. More specifically, some simply reject at the first use of a literal8 in an APPEND command. This is currently legal behaviour for RFC3516, so this point was merely suggesting that if a server only supports the BINARY FETCH items, there should be some mechanism to signal that to the client, so it doesn't attempt a binary upload. For Lemonade, we can then choose to mandate "binary upload support" for Profile 2. This may all be closely related to points 5 and 6, and indeed probably is - the points I've enumerated are merely those I could find in my INBOX and scatty memory, I've not attempted to sort them out. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Feb 18 15:39:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAYs3-0001vT-Cq; Sat, 18 Feb 2006 15:39:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAYs1-0001vM-El for lemonade@ietf.org; Sat, 18 Feb 2006 15:39:57 -0500 Received: from orthanc.ca ([209.89.70.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAYs0-0007BX-28 for lemonade@ietf.org; Sat, 18 Feb 2006 15:39:57 -0500 Received: from [192.168.15.2] (d154-5-28-131.bchsia.telus.net [154.5.28.131]) (authenticated bits=0) by orthanc.ca (8.13.4/8.13.4) with ESMTP id k1IKdoqZ017125; Sat, 18 Feb 2006 13:39:50 -0700 (MST) (envelope-from lyndon@orthanc.ca) In-Reply-To: <24385.1140258546.627271@peirce.dave.cridland.net> References: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> <43F0F6D5.90408@orthanc.ca> <24385.1140258546.627271@peirce.dave.cridland.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <62955498-0822-43CD-920A-495C6C48CAA8@orthanc.ca> Content-Transfer-Encoding: quoted-printable From: Lyndon Nerenberg Subject: Re: [lemonade] RFC 3516 (IMAP4 Binary Content Extension) Question Date: Sat, 18 Feb 2006 12:39:48 -0800 To: Dave Cridland X-Mailer: Apple Mail (2.746.2) X-Spam-Status: No, score=1.0 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on orthanc.ca X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Feb 18, 2006, at 2:29 AM, Dave Cridland wrote: > 2) Signalling whether uploads will always be rejected with UNKNOWN-=20 > CTE. Why would the server not just do a dynamic conversion to a non-binary =20= representation as it stores the message? That's what sentence two of =20= section 4.4 is all about. I guess I don't understand why a server =20 would be willing to translate in one direction (FETCH), but not the =20 other (APPEND). I realize that the second paragraph of =A74.4 introduces an ambiguity. =20= The intention was not to require the server to store the APPENDed =20 data in a binary format. --lyndon= _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sat Feb 18 15:49:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAZ1j-0002Ik-LZ; Sat, 18 Feb 2006 15:49:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAZ1h-0002Ic-QN for lemonade@ietf.org; Sat, 18 Feb 2006 15:49:57 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAZ1g-0007Jx-EI for lemonade@ietf.org; Sat, 18 Feb 2006 15:49:57 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k1IKnrtB008658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 18 Feb 2006 12:49:54 -0800 X-Auth-Received: from pangtzu.panda.com (pangtzu.panda.com [206.124.149.117]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k1IKnpae019226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 18 Feb 2006 12:49:53 -0800 Date: Sat, 18 Feb 2006 12:49:51 -0800 (PST) From: Mark Crispin To: Lyndon Nerenberg Subject: Re: [lemonade] RFC 3516 (IMAP4 Binary Content Extension) Question In-Reply-To: <62955498-0822-43CD-920A-495C6C48CAA8@orthanc.ca> Message-ID: References: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> <43F0F6D5.90408@orthanc.ca> <24385.1140258546.627271@peirce.dave.cridland.net> <62955498-0822-43CD-920A-495C6C48CAA8@orthanc.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sat, 18 Feb 2006, Lyndon Nerenberg wrote: > I guess I don't understand why a server would be willing > to translate in one direction (FETCH), but not the other (APPEND). FETCH is easy. Just get the segment as normal, and if it has a CTE (which you get from the BODYSTRUCTURE) of BASE64 or QUOTED-PRINTABLE then apply the translation. APPEND is hard. The server actually has to parse the message, and transform it. Unless, that is, the server is stupid and just accepts any old crap that is appended to it, and if binary content gets sent with a non-binary fetch, well the MUA/user deserved to lose. That's the trouble with "unfunded mandates"; if there's a stupid thing to do that works for the 98% case, it's all too easy to choose that instead of the right thing. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Feb 19 09:09:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FApFc-0008JX-FK; Sun, 19 Feb 2006 09:09:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FApFb-0008JS-Io for lemonade@ietf.org; Sun, 19 Feb 2006 09:09:23 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FApFa-000415-4b for lemonade@ietf.org; Sun, 19 Feb 2006 09:09:23 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id BE6C54AC1B for ; Sun, 19 Feb 2006 15:09:20 +0100 (CET) Message-Id: Date: Sun, 19 Feb 2006 15:18:52 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] RFC 3516 (IMAP4 Binary Content Extension) Question References: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> <43F0F6D5.90408@orthanc.ca> <24385.1140258546.627271@peirce.dave.cridland.net> <62955498-0822-43CD-920A-495C6C48CAA8@orthanc.ca> In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Mark Crispin writes: > On Sat, 18 Feb 2006, Lyndon Nerenberg wrote: >> I guess I don't understand why a server would be willing to translate >> in one direction (FETCH), but not the other (APPEND). > > FETCH is easy. Just get the segment as normal, and if it has a CTE > (which you get from the BODYSTRUCTURE) of BASE64 or QUOTED-PRINTABLE > then apply the translation. > > APPEND is hard. The server actually has to parse the message, and > transform it. I don't get that. IMAP servers contain enough parsing and transmormation smarts to handle FETCH BODYSTRUCTURE, FETCH BODY[1] and SEARCH BODY. APPEND with literal8 seems easy. It needs the same parsing code, plus b64 and/or q-p encoding functions, right? Explain? Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Feb 19 09:22:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FApS7-00005o-1M; Sun, 19 Feb 2006 09:22:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FApS6-00005j-Ji for lemonade@ietf.org; Sun, 19 Feb 2006 09:22:18 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FApS5-0004KS-74 for lemonade@ietf.org; Sun, 19 Feb 2006 09:22:18 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FApS2-0005m3-0h; Sun, 19 Feb 2006 14:22:14 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 9955F498003; Sun, 19 Feb 2006 14:34:25 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30359-06; Sun, 19 Feb 2006 14:34:22 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id B52A7498002; Sun, 19 Feb 2006 14:34:22 +0000 (GMT) Date: Sun, 19 Feb 2006 14:22:09 +0000 Subject: Re: [lemonade] RFC 3516 (IMAP4 Binary Content Extension) Question References: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> <43F0F6D5.90408@orthanc.ca> <24385.1140258546.627271@peirce.dave.cridland.net> <62955498-0822-43CD-920A-495C6C48CAA8@orthanc.ca> In-Reply-To: MIME-Version: 1.0 Message-Id: <24385.1140358930.628450@peirce.dave.cridland.net> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sun Feb 19 14:18:52 2006, Arnt Gulbrandsen wrote: > Mark Crispin writes: >> On Sat, 18 Feb 2006, Lyndon Nerenberg wrote: >>> I guess I don't understand why a server would be willing to >>> translate in one direction (FETCH), but not the other (APPEND). >> >> FETCH is easy. Just get the segment as normal, and if it has a >> CTE (which you get from the BODYSTRUCTURE) of BASE64 or >> QUOTED-PRINTABLE then apply the translation. >> >> APPEND is hard. The server actually has to parse the message, and >> transform it. > > I don't get that. IMAP servers contain enough parsing and > transmormation smarts to handle FETCH BODYSTRUCTURE, FETCH BODY[1] > and SEARCH BODY. APPEND with literal8 seems easy. It needs the same > parsing code, plus b64 and/or q-p encoding functions, right? > > No. Handling 3516 for FETCH only means you can use the same MIME parser you've used for the past decade or so. Handling 3516 for APPEND means your MIME parser has to handle binary. Binary MIME is actually terribly easy to parse, but it has a fearsome reputation, and appears to have scared people for years - witness the statements at the top of RFC3030. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Feb 19 09:38:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAphU-0000Ot-Ry; Sun, 19 Feb 2006 09:38:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAphU-0000Oo-Bh for lemonade@ietf.org; Sun, 19 Feb 2006 09:38:12 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAphS-0004UO-UV for lemonade@ietf.org; Sun, 19 Feb 2006 09:38:12 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 11EC34AC1B for ; Sun, 19 Feb 2006 15:38:10 +0100 (CET) Message-Id: Date: Sun, 19 Feb 2006 15:47:41 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] RFC 3516 (IMAP4 Binary Content Extension) Question References: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> <43F0F6D5.90408@orthanc.ca> <24385.1140258546.627271@peirce.dave.cridland.net> <62955498-0822-43CD-920A-495C6C48CAA8@orthanc.ca> <24385.1140358930.628450@peirce.dave.cridland.net> In-Reply-To: <24385.1140358930.628450@peirce.dave.cridland.net> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi Dave. I thought today is a Sunday? Dave Cridland writes: > No. Handling 3516 for FETCH only means you can use the same MIME > parser you've used for the past decade or so. Handling 3516 for > APPEND means your MIME parser has to handle binary. That's just-send-8 plus null bytes? I wrote zero lines of code to handle that case ;) That's why I'm surprised when Mark says it's hard. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Feb 19 09:57:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FApzn-0000tf-9s; Sun, 19 Feb 2006 09:57:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FApzl-0000ta-P2 for lemonade@ietf.org; Sun, 19 Feb 2006 09:57:05 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FApzj-0004lE-FW for lemonade@ietf.org; Sun, 19 Feb 2006 09:57:05 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FApzf-0008Bp-Vi; Sun, 19 Feb 2006 14:57:00 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id BB17E498003; Sun, 19 Feb 2006 15:09:11 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30583-02; Sun, 19 Feb 2006 15:09:08 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id CE4E9498002; Sun, 19 Feb 2006 15:09:08 +0000 (GMT) Date: Sun, 19 Feb 2006 14:56:55 +0000 Subject: Re: [lemonade] RFC 3516 (IMAP4 Binary Content Extension) Question References: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> <43F0F6D5.90408@orthanc.ca> <24385.1140258546.627271@peirce.dave.cridland.net> <62955498-0822-43CD-920A-495C6C48CAA8@orthanc.ca> <24385.1140358930.628450@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <24385.1140361016.499935@peirce.dave.cridland.net> From: Dave Cridland To: Arnt Gulbrandsen Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sun Feb 19 14:47:41 2006, Arnt Gulbrandsen wrote: > Hi Dave. I thought today is a Sunday? > > It is. :-/ > Dave Cridland writes: >> No. Handling 3516 for FETCH only means you can use the same MIME >> parser you've used for the past decade or so. Handling 3516 for >> APPEND means your MIME parser has to handle binary. > > That's just-send-8 plus null bytes? > > Not quite, it's infinite line length, too. Which isn't a problem, but "old" MIME parsers treat anything beyond 1000 octet line lengths as an error case. > I wrote zero lines of code to handle that case ;) That's why I'm > surprised when Mark says it's hard. I don't think Mark's saying it *is* hard. Merely that it has an amount of effort, and intrusiveness, much higher than leaving out the APPEND side, hence some people have opted for skipping that. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Feb 19 13:24:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAtDx-0004uD-FK; Sun, 19 Feb 2006 13:23:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAtDv-0004u5-HP for lemonade@ietf.org; Sun, 19 Feb 2006 13:23:55 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAtDu-0000tS-6i for lemonade@ietf.org; Sun, 19 Feb 2006 13:23:55 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout3.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k1JINlt0027470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 19 Feb 2006 10:23:47 -0800 X-Auth-Received: from Shimo-Tomobiki.panda.com (150.sub-70-203-99.myvzw.com [70.203.99.150]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k1JINAQH025317 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 19 Feb 2006 10:23:45 -0800 Date: Sun, 19 Feb 2006 10:23:02 -0800 From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] RFC 3516 (IMAP4 Binary Content Extension) Question In-Reply-To: <24385.1140358930.628450@peirce.dave.cridland.net> Message-ID: References: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> <43F0F6D5.90408@orthanc.ca> <24385.1140258546.627271@peirce.dave.cridland.net> <62955498-0822-43CD-920A-495C6C48CAA8@orthanc.ca> <24385.1140358930.628450@peirce.dave.cridland.net> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Enhancements to Internet email to support diverse service enivronments , Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sun, 19 Feb 2006, Dave Cridland wrote: > No. Handling 3516 for FETCH only means you can use the same MIME parser > you've used for the past decade or so. Handling 3516 for APPEND means your > MIME parser has to handle binary. AND the message has to be transformed into a non-binary form when stored. All the counts in IMAP, starting with RFC822.SIZE, have to reflect this transformed form. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Sun Feb 19 13:32:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1-ext.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAtMI-000539-9Y; Sun, 19 Feb 2006 13:32:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAtMH-000534-6w for lemonade@ietf.org; Sun, 19 Feb 2006 13:32:33 -0500 Received: from mxout2.cac.washington.edu ([140.142.33.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAtMF-0001E2-SB for lemonade@ietf.org; Sun, 19 Feb 2006 13:32:33 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k1JIWQmx016756 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 19 Feb 2006 10:32:27 -0800 X-Auth-Received: from Shimo-Tomobiki.panda.com (150.sub-70-203-99.myvzw.com [70.203.99.150]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k1JIVwOM006817 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 19 Feb 2006 10:32:24 -0800 Date: Sun, 19 Feb 2006 10:31:44 -0800 From: Mark Crispin To: Dave Cridland Subject: Re: [lemonade] RFC 3516 (IMAP4 Binary Content Extension) Question In-Reply-To: <24385.1140361016.499935@peirce.dave.cridland.net> Message-ID: References: <0C6AA2145B810F499C69B0947DC50781092E339B@oh0012exch001p.cb.lucent.com> <43F0F6D5.90408@orthanc.ca> <24385.1140258546.627271@peirce.dave.cridland.net> <62955498-0822-43CD-920A-495C6C48CAA8@orthanc.ca> <24385.1140358930.628450@peirce.dave.cridland.net> <24385.1140361016.499935@peirce.dave.cridland.net> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Enhancements to Internet email to support diverse service enivronments , Arnt Gulbrandsen X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Sun, 19 Feb 2006, Dave Cridland wrote: >> That's just-send-8 plus null bytes? > Not quite, it's infinite line length, too. And tranformation to the non-binary form for default/ordinary IMAP fetches. FETCH BINARY can be done on the fly from non-binary stored data. The reverse is much more costly (unacceptably costly) since it involves such things as RFC822.SIZE and BODYSTRUCTURE counts. If your server returns BINARY as a C-T-E in BODYSTRUCTURE, or returns NUL in any non-BINARY FETCH, then it is non-compliant. To do things right, you can't just accept any old text for APPEND and hope for the best; you have to validate the text and make certain that you can transform it into a non-BINARY form. So, the delivery process has to do the work. This is not a trivial task; but it's one that many people overlook. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Feb 21 19:54:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBiHA-0006Us-Uc; Tue, 21 Feb 2006 19:54:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBiH9-0006Um-0Z for lemonade@ietf.org; Tue, 21 Feb 2006 19:54:39 -0500 Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBiH7-0005m4-MB for lemonade@ietf.org; Tue, 21 Feb 2006 19:54:38 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:56730) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1FBiGv-0004mD-3W (Exim 4.54) for lemonade@ietf.org (return-path ); Wed, 22 Feb 2006 00:54:25 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FBiGv-0003Iz-1d (Exim 4.53) for lemonade@ietf.org (return-path ); Wed, 22 Feb 2006 00:54:25 +0000 Date: Wed, 22 Feb 2006 00:54:25 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: lemonade@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [lemonade] streamlined message submission X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The talk about round-trip times on the main IETF list (combined with some other things I have been thinking abou recently) got me interested. How much can you streamline message submission? Current securely authenticated message submission requires at least eleven round trips (including TCP startup and shutdown). BURL can reduce this to nine. The non-standard but popular smtps reduces it to six. A further tweak to SMTP's start sequence could reduce it to five. This seems pretty good. I've written this up in more detail. The following are all fairly short, and where they aren't they are formulaic. http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-submission-streamlined.txt http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-tls-on-connect.txt http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-quickstart.txt http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-rcpthdr.txt Tony. -- f.a.n.finch http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Feb 21 20:59:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBjHg-0001YI-MJ; Tue, 21 Feb 2006 20:59:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBjHf-0001Y9-Jz for lemonade@ietf.org; Tue, 21 Feb 2006 20:59:15 -0500 Received: from [209.55.107.55] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBjHe-0007Fn-2W for lemonade@ietf.org; Tue, 21 Feb 2006 20:59:15 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LZ8M8PRGKW008UGN@mauve.mrochek.com> for lemonade@ietf.org; Tue, 21 Feb 2006 17:59:12 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1140573552; h=Date: From:Subject:MIME-version:Content-type; b=UA0RTtB1Qakmp2MREF8lBZkv0 MKrOeZfdoMlbAxFJPAO1OIguKU3imrirypw27/wZsJVbLcfjti+z3jtlpByug== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LZ8ERZDACG00009C@mauve.mrochek.com>; Tue, 21 Feb 2006 17:59:08 -0800 (PST) To: Tony Finch Message-id: <01LZ8M8NO8S800009C@mauve.mrochek.com> Date: Tue, 21 Feb 2006 17:09:59 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] streamlined message submission In-reply-to: "Your message dated Wed, 22 Feb 2006 00:54:25 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > The talk about round-trip times on the main IETF list (combined with some > other things I have been thinking abou recently) got me interested. How > much can you streamline message submission? Current securely authenticated > message submission requires at least eleven round trips (including TCP > startup and shutdown). BURL can reduce this to nine. The non-standard but > popular smtps reduces it to six. A further tweak to SMTP's start sequence > could reduce it to five. This seems pretty good. > I've written this up in more detail. The following are all fairly short, > and where they aren't they are formulaic. > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-submission-streamlined.txt This is effectively a description of how to combine the remaining mechanisms plus BURL. > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-tls-on-connect.txt I have to say I agreed with the decision not to go with separate ports and with STARTTLS instead. And although this does reduce round trips significantly I'm fairly unenthusiastic it, but less because I agreed with the prior decision and more because I predict there will be opposition to moving back to the smtps approach from the security folks. And although we've supported smtps in our product for a long time, I don't in practice see the large amounts of lingering use of it you do. > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-quickstart.txt This extension seems quite reasonable to me. I would suggest that you point out in the security considerations that logging of the client's IP address is more useful in practice than logging of the EHLO value. (This is mentioned in section 1 but bears repeating. Or perhaps some of the discussion in the introduction should be moved to the security considerations section.) You probably do need to include an SMTP service extension registration template, even though as you say this doesn't really conform to the EHLO extension announcement model. > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-rcpthdr.txt First an editorial comment - the draft refers repeatedly to RFC 2476. This RFC is obsolete, having been replaced by draft-gellens-submit-bis-02.txt, which has already been approved as a draft standard. As the draft points out, this doesn't reduce the number of round trips except in the case where more than 4K of recipient data is involved, which is quite rare in practice. I therefore see little value in it. I also see lots of problems with it, including but not limited to: (0) How are malformed or unparseable To:/Cc:/Bcc: fields supposed to be handled? There's no place to report such an error in the dialogue and a DSN isn't designed to report such issues. (1) How are problems with specific recipient addresses supposed to be handled? The draft seems to say that this is covered in RFC 2476. But it isn't - in fact RFC 2476 specifically talks about using RCPT TO command responses to report this sort of thing - the facility you have eliminated. AFAICT the best that could be done is to return a DSN later. But after having seen this model used elsewhere I can tell you that users absolutely hate it. If there's a problem with a recipient they've specified they want to see it right there on the screen when they send a message. Getting back a DSN later is nowhere near as good, and as joe-jobs and blowback spam continues to grow DSNs stand an ever-increasing chance of being lost in the shuffle. (2) The reliance on header ordering to handle Resent- is something I find to be quite problematic, language about it in RFC 2822 notwithstanding. I also have to say I find the argument that traffic analysis of a pipelined session often reveals the number of recipients and this mechanism protects against it to be pretty dubious. There's a lot of variably sized stuff in the various commands and it would be very difficult to track its cumulative effect. Additionally, in the case where recipients are scattered around on different destination systems, a message is going to be split and sent multiple times to different destinations. In this case even if TLS is used for everything tracking the overall size and temporal adjacency of the messages sent by a given system will let you correlate things to the point where you'll know at least how many different destinations for a given message was sent to, regardless of whether or not this mechanism is used. In short, I really don't think this one's a keeper. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 22 09:14:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBulC-0006Ta-Op; Wed, 22 Feb 2006 09:14:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBulA-0006TT-Ql for lemonade@ietf.org; Wed, 22 Feb 2006 09:14:28 -0500 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBul7-00058k-CT for lemonade@ietf.org; Wed, 22 Feb 2006 09:14:28 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:37235) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1FBul0-0007E7-25 (Exim 4.54) (return-path ); Wed, 22 Feb 2006 14:14:18 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FBul0-00035q-Jj (Exim 4.53) (return-path ); Wed, 22 Feb 2006 14:14:18 +0000 Date: Wed, 22 Feb 2006 14:14:18 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ned Freed Subject: Re: [lemonade] streamlined message submission In-Reply-To: <01LZ8M8NO8S800009C@mauve.mrochek.com> Message-ID: References: <01LZ8M8NO8S800009C@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Tue, 21 Feb 2006, Ned Freed wrote: Thanks for your comments. > I have to say I agreed with the decision not to go with separate ports and with > STARTTLS instead. And although this does reduce round trips significantly I'm > fairly unenthusiastic it, but less because I agreed with the prior decision and > more because I predict there will be opposition to moving back to the smtps > approach from the security folks. And although we've supported smtps in our > product for a long time, I don't in practice see the large amounts of lingering > use of it you do. I expect that what will continue to happen, whether this draft moves on or not, is the STARTTLS and TLS-on-connect models will operate in parallel. Most of the TLS-on-connect requirement comes from Microsoft Outlook. > > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-rcpthdr.txt I'll check submit-bis. Thanks for reminding me about it. > As the draft points out, this doesn't reduce the number of round trips except > in the case where more than 4K of recipient data is involved, which is quite > rare in practice. Or if the number of recipients tips the combination of envelope and data over this limit - assuming they are pipelined together via the BURL extension. > (0) How are malformed or unparseable To:/Cc:/Bcc: fields supposed to be > handled? By rejection of the message data, as in RFC 2476 sections 5.1 and 3.2. > (1) How are problems with specific recipient addresses supposed to be handled? Dave Cridland also said I should consider this more carefully. I didn't worry about it too much because the wisdom I have received is that an MSA should accept-and-bounce rather than reject, because that way the right error message is more likely to get through to the user. I still get complaints from users quoting the message "valid RCPT command must precede DATA" rather than the RCPT rejection message, and I still see mad MUAs repeatedly retrying a 550ed message every second for days, so I still don't trust them to behave sensibly. > (2) The reliance on header ordering to handle Resent- is something I find > to be quite problematic, language about it in RFC 2822 notwithstanding. The main reason for writing this down is to address a problem that arose in the development of Exim: it isn't clear how an MSA should treat a re-sent message, given the mismatch between RFC 822 and RFC 2822. In particular, should Sender:, Message-ID: and Date: fields be fixed up or should the Resent- versions be fixed up, and in the latter case, which set should be fixed? This part should probably be decoupled from the RCPTHDR idea. It may be useful input to 2822-bis. I agree that RCPTHDR by itself is not really compelling. Tony. -- f.a.n.finch http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 22 09:42:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBvC8-0007iN-Su; Wed, 22 Feb 2006 09:42:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBvC7-0007iH-SV for lemonade@ietf.org; Wed, 22 Feb 2006 09:42:19 -0500 Received: from [209.55.107.55] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBvC7-0006Su-HN for lemonade@ietf.org; Wed, 22 Feb 2006 09:42:19 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LZ9CVT3D800094G8@mauve.mrochek.com> for lemonade@ietf.org; Wed, 22 Feb 2006 06:42:16 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1140619336; h=Date: From:Subject:MIME-version:Content-type; b=HH35csuCbwVYocLfmuaBtdRpw 8C4fhzMZCOMt6kDJOXiSu6Ahlt9+XyzqEjFud4/VVUZ4PSvg17BF+TdNp/6+w== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LZ8ERZDACG00009C@mauve.mrochek.com>; Wed, 22 Feb 2006 06:42:14 -0800 (PST) To: Tony Finch Message-id: <01LZ9CVRUSC000009C@mauve.mrochek.com> Date: Wed, 22 Feb 2006 06:20:12 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] streamlined message submission In-reply-to: "Your message dated Wed, 22 Feb 2006 14:14:18 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01LZ8M8NO8S800009C@mauve.mrochek.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: lemonade@ietf.org, Ned Freed X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > (0) How are malformed or unparseable To:/Cc:/Bcc: fields supposed to be > > handled? > By rejection of the message data, as in RFC 2476 sections 5.1 and 3.2. I'm sorry, but RFC 2476's implication that messages should be rejected for having invalid header syntax is not practical in many cases. There's just too much cruft out there. > > (1) How are problems with specific recipient addresses supposed to be handled? > Dave Cridland also said I should consider this more carefully. I didn't > worry about it too much because the wisdom I have received is that an MSA > should accept-and-bounce rather than reject, because that way the right > error message is more likely to get through to the user. This is almost the exact opposite of our experience. Immediate rejection is handled well by most MUAs, which typically present (a) A messasge in the user's own language saying there's a problem, (b) The address that failed, and (c) The actual error message, which may not be in their language but doesn't really have to be. Now, there are a few MUAs that don't present the error message, or present the wrong one, and this bothers technical types a lot. But the alternative - a report generated later, appearing in the inbox, is far more difficult for nontechnical users to deal with. Often as not they can't figure out what message the report applies to, what went wrong, or what address was the one that had a problem. Language issues are often the root cause of some of the problems here. We go to tremendous lengths in our product to try and make appropriate language choices for DSNs in order to avoid these issues, but it is never enough. You cannot get away from the fact that the DSN isn't attached to the message that had a problem in the same way that immediate response is. > I still get > complaints from users quoting the message "valid RCPT command must precede > DATA" rather than the RCPT rejection message, and I still see mad MUAs > repeatedly retrying a 550ed message every second for days, so I still > don't trust them to behave sensibly. But you trust them to display DSNs ssnsibly? Sorry, this makes no sense at all to me. The only MUA I have ever seen that actually did DSN display localization and correlation with sent messages was X.400 based. For whatever reason this has not caught on in the Internet protocol world, likely due to the fact that DSN and MDN formats were standardized so late in the game. (The fact that there is ongoing resistance to using the standard formats in some quarters doesn't help either.) Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 22 09:44:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBvDk-0007pT-Jx; Wed, 22 Feb 2006 09:44:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBvDj-0007pO-N1 for lemonade@ietf.org; Wed, 22 Feb 2006 09:43:59 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBvDh-0006XB-5C for lemonade@ietf.org; Wed, 22 Feb 2006 09:43:59 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FBvDd-0007Cg-St; Wed, 22 Feb 2006 14:43:54 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 8575D498003; Wed, 22 Feb 2006 14:44:00 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09477-07; Wed, 22 Feb 2006 14:43:56 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 572B7498002; Wed, 22 Feb 2006 14:43:56 +0000 (GMT) Date: Wed, 22 Feb 2006 14:43:48 +0000 Subject: Re: [lemonade] streamlined message submission References: In-Reply-To: MIME-Version: 1.0 Message-Id: <21533.1140619429.225276@peirce.dave.cridland.net> From: Dave Cridland To: Tony Finch Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Feb 22 00:54:25 2006, Tony Finch wrote: > I've written this up in more detail. The following are all fairly > short, > and where they aren't they are formulaic. > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-submission-streamlined.txt BURL doesn't allow clients to pipeline AUTH - that's just possible anyway with a server that supports PIPELINING. I have no idea why you'd want to pipeline QUIT - it's never going to be a good idea. You leave the connection open until it times out, in case you need to reuse it later. (Yes, this isn't nice to the server.) Oh, and I believe that it's possible to include the banner in the TCP SYN+ACK packet coming from the server, but I couldn't swear to it. That one just got told to me in the pub once. I *think* Linux's TCP stack allows you to write the banner to a listening socket or something odd to get the behaviour, but I'd have to ask about. What I really do like about this draft is the round-trip list - both this one and the TLS one. Those are actually really useful, and I for one would appreciate you publishing those on their own in at least I-D form, and include how it changes if we have TLS session cache hits, etc. It'd be useful to have a similar one for IMAP. > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-tls-on-connect.txt The problem with removing the STARTTLS round-trip is that quite a bit of discussion and argument went into putting it there in the first place. The two arguments I personally find most convincing are: 1) Look at HTTP. Nobody uses TLS except when they absolutely have to, there, and generally, https: scheme URIs point to different content than http: scheme URIs. The two ports have mutated into two protocols - not good. 2) If unusual ports are used, and TLS is unavailable (something my own client is sometimes forced to deal with), then splitting the ports means that it's extremely difficult and ugly to deal with. Simply not issuing STARTTLS in order to have TLS-less access makes life much easier. FWIW, back when SSL usage for IMAP was first being discussed on the IMAP mailing list, one of the arguments against a seperate port was that SSL was designed in such a way that it could identify whether it was TLS or not - a distinct inline switching command was not actually required, in other words. You *could* put such a capability in a banner, and observer the first octets to come through, seeing if they were valid TLS hello octets. I have virtually no idea what I'm talking about here, though. > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-quickstart.txt A round-trip saved, that's good. This is a rough analogue of the IMAP CAPABILITY response code. The question is, is it possible that some ESMTP clients might be confused by a multiline response? I'm mildly concerned by that. There's an alternate model for this sort of thing - you can issue a server configuration indicator in the banner, which changes whenever the configuration does, such that if you recognise it, then the EHLO becomes redundant, because you know the capabilities. Moreover, you've cached them *after* the secure channel setup, of course, so you needn't ever fetch them until you see that change. I'm thinking: S: 220 foo.example.net ESMTP CONFIGMAGICNUMBER <200602221436@example.net> C: // Elide EHLO, we know the thing supports TLS because we know that magic key. C: STARTTLS S: 250 Groovy. // TLS exchange. // No need to reissue EHLO, we have those cached. C: AUTH DIGEST-MD5 fastreauthgunk S: 2xx respauthgunk etc. Now... In theory we can also elide that AUTH, if TLS session caching hit, since that's presumably proof enough that we are the same source as last time. We can certainly use a AUTH EXTERNAL there on that premise, can't we? Has anyone been looking at BTNS, which ought to provide much the same thing with IPSec? > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-rcpthdr.txt > > Okay, I already commented on this to you. Ned's arguments are better than mine, too. :-) > BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. > MODERATE OR > GOOD. If you could change that to Lundy, I'd actually find it useful. Biscay is quite a way off for me. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 22 10:46:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwBy-0001t8-P1; Wed, 22 Feb 2006 10:46:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwBx-0001t3-B7 for lemonade@ietf.org; Wed, 22 Feb 2006 10:46:13 -0500 Received: from monkey.teamware.com ([62.61.83.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBwBv-0000nM-TL for lemonade@ietf.org; Wed, 22 Feb 2006 10:46:13 -0500 Received: from intrepid (intrepid.teamw.com [10.142.128.11]) by monkey.teamware.com (8.13.1/8.13.1) with ESMTP id k1MFnPtG001572; Wed, 22 Feb 2006 17:49:25 +0200 Received: from [10.142.130.127] ([10.142.130.127]) by intrepid with ESMTP id m2mi4ojo; 22 Feb 2006 18:04:00 +0200 Message-ID: <43FC8731.3080505@teamware.com> Date: Wed, 22 Feb 2006 17:45:53 +0200 From: Antony Bowesman Organization: Teamware Group User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ned Freed Subject: Re: [lemonade] streamlined message submission References: <01LZ8M8NO8S800009C@mauve.mrochek.com> <01LZ9CVRUSC000009C@mauve.mrochek.com> In-Reply-To: <01LZ9CVRUSC000009C@mauve.mrochek.com> X-TWG-MDN: never Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TWG-MailScanner-Information: Please contact the ISP for more information X-TWG-MailScanner: Found to be clean X-TWG-MailScanner-SpamCheck: not spam, SpamAssassin (score=0, required 5, autolearn=not spam) X-MailScanner-From: adb@teamware.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Ned Freed wrote: > > But you trust them to display DSNs ssnsibly? Sorry, this makes no sense at all > to me. The only MUA I have ever seen that actually did DSN display localization > and correlation with sent messages was X.400 based. For whatever reason this Netscape some years ago had the option to move incoming reports to the sent folder which Thunderbird adopted. This worked reasonalby well, but for some reason TB has now removed DSN requests completely and few people support MDN, so it's not so useful. > has not caught on in the Internet protocol world, likely due to the fact that > DSN and MDN formats were standardized so late in the game. (The fact that there > is ongoing resistance to using the standard formats in some quarters doesn't > help either.) Yes, MS' winmail.dat did plenty of harm to the idea of reports. The privacy issue with MDN may also have affected adoption. Antony _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 22 11:01:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwR6-0002dA-HL; Wed, 22 Feb 2006 11:01:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBwR5-0002d2-BE for lemonade@ietf.org; Wed, 22 Feb 2006 11:01:51 -0500 Received: from [209.55.107.55] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBwR0-0001JB-P6 for lemonade@ietf.org; Wed, 22 Feb 2006 11:01:51 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LZ9FNCISTS008NQS@mauve.mrochek.com> for lemonade@ietf.org; Wed, 22 Feb 2006 08:01:45 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1140624104; h=Date: From:Subject:MIME-version:Content-type; b=Knx4f8hJH+3lgA7q06aIAQtti n23SO3K1QCqjAtg0EP+3aLYc6HtGgy34Z4kzAGfF7/HWl9HLAj/Tic5mX4zVw== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LZ8ERZDACG00009C@mauve.mrochek.com>; Wed, 22 Feb 2006 08:01:42 -0800 (PST) To: Dave Cridland Message-id: <01LZ9FNBLMAS00009C@mauve.mrochek.com> Date: Wed, 22 Feb 2006 07:12:34 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] streamlined message submission In-reply-to: "Your message dated Wed, 22 Feb 2006 14:43:48 +0000" <21533.1140619429.225276@peirce.dave.cridland.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <21533.1140619429.225276@peirce.dave.cridland.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: diverse service enivronments , Enhancements X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > On Wed Feb 22 00:54:25 2006, Tony Finch wrote: > > I've written this up in more detail. The following are all fairly > > short, > > and where they aren't they are formulaic. > > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-submission-streamlined.txt > BURL doesn't allow clients to pipeline AUTH - that's just possible > anyway with a server that supports PIPELINING. I have no idea why > you'd want to pipeline QUIT - it's never going to be a good idea. You > leave the connection open until it times out, in case you need to > reuse it later. (Yes, this isn't nice to the server.) The thing a lot of clients do is simply drop the connection without ever sending a QUIT, rules to the contrary notwithstanding. Of course the user can be told that the message was successfully sent the instant the response to the final DATA/BURL/BDAT has been received. The QUIT can then be handled asynchronously in the background. So if the goal is to improve user experience, QUIT handling doesn't have to be relevant. > Oh, and I believe that it's possible to include the banner in the TCP > SYN+ACK packet coming from the server, but I couldn't swear to it. > That one just got told to me in the pub once. I *think* Linux's TCP > stack allows you to write the banner to a listening socket or > something odd to get the behaviour, but I'd have to ask about. Wow, you sure have more interesting conversations at the pub than I do ;-) Anyway, I know of a couple of tricks in this space. One is the technique described in RFC 1644, which eliminates the three way handshakes for repeated connections between the same two machines. It isn't clear to me that this would be useful in SMTP, however. Often as not there are a whole bunch of front end machines a client can connect to, and arranging things so the client would have an affinity for the last server would be tricky. The other is to piggyback data on either the syn, syn-ack, or both. This has been discussed many times on various lists but if there's an RFC discussing it in detail I don't know the number. Piggyback data on syn isn't interesting in SMTP since the server speaks first, but returning the server banner on the syn-ack would represent some savings. The problem lies in implementation - most (all?) TCP APIs don't allow data to be specified in the accept call. Some stacks offer a way to delay sending acks in hopes they can be piggybacked on returned data, but I don't know if this ever extends to syn-ack or not. The trick you described of writing data to the socket before calling accept is not one I've heard of before. I may try it and see if it works. > > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-quickstart.txt > A round-trip saved, that's good. This is a rough analogue of the IMAP > CAPABILITY response code. > The question is, is it possible that some ESMTP clients might be > confused by a multiline response? I'm mildly concerned by that. This used to be a problem in practice, but several years ago some fairly popular SMTP server started spitting out multiline banners (something sort of "no trespassing" sign, I think) and refused to provide an option to disable it, which then got a lot of the incompliant gunk cleaned up. (It is always nice when something that's widely deployed pushes the envelope this way.) At this point I think compliance is pretty good - as it happens I forgot to dismantle a test a few months back and inadvertently ran with a mulitline banner for a while and noticed no problems. > There's an alternate model for this sort of thing - you can issue a > server configuration indicator in the banner, which changes whenever > the configuration does, such that if you recognise it, then the EHLO > becomes redundant, because you know the capabilities. Moreover, > you've cached them *after* the secure channel setup, of course, so > you needn't ever fetch them until you see that change. We actually use a similar trick in our SMTP in order to avoid having to code the list of supported extensions into the proxy. This is one of those things that sounds simple but it is actually surprisingly hard to implement correctly. I forget exactly what bugs we had, but we definitely had a couple. I actually worry more about implementors getting this right than I do about getting multiline banner processing right. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 22 12:17:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBxbs-0003S8-Gy; Wed, 22 Feb 2006 12:17:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBxbq-0003S3-RM for lemonade@ietf.org; Wed, 22 Feb 2006 12:17:02 -0500 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBxbp-0004qw-8g for lemonade@ietf.org; Wed, 22 Feb 2006 12:17:02 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:55139) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1FBxbf-0002Z4-17 (Exim 4.54) (return-path ); Wed, 22 Feb 2006 17:16:51 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FBxbf-000447-9j (Exim 4.53) (return-path ); Wed, 22 Feb 2006 17:16:51 +0000 Date: Wed, 22 Feb 2006 17:16:51 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Cridland Subject: Re: [lemonade] streamlined message submission In-Reply-To: <21533.1140619429.225276@peirce.dave.cridland.net> Message-ID: References: <21533.1140619429.225276@peirce.dave.cridland.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 22 Feb 2006, Dave Cridland wrote: > > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-submission-streamlined.txt > > BURL doesn't allow clients to pipeline AUTH - that's just possible > anyway with a server that supports PIPELINING. The BURL spec is the only document that gives permission to do it. The AUTH spec doesn't say anything about PIPELINING, and PIELINING says Additional commands added by other SMTP extensions may only appear as the last command in a group unless otherwise specified by the extensions that define the commands. RFC 3030 is a bit unclear about the interaction of BDAT and pipelining - it doesn't describe things in terms of the "last command in a group" as RFC 2920 does. It does allow BDAT to be pipelined with itself but doesn't talk about pipelining it with the preceding or following envelopes. The BURL spec clarifies that you can do this is the server supports BURL. > I have no idea why you'd want to pipeline QUIT - it's never going to be > a good idea. You leave the connection open until it times out, in case > you need to reuse it later. (Yes, this isn't nice to the server.) Pipelined QUIT is included in an example in RFC 2920. It shouldn't be a problem if the client waits for all the server's responses. Note that in my ladder diagrams I show the server initiating the connection close, so this should Just Work. Some clients close the connection immediately after QUIT, which is liable to cut off the server's response, especially if you are also using TLS (which doesn't support half-closed connections). Of course I am not precluding connection cacheing, and I should probably add a mention of it to the drafts. > Oh, and I believe that it's possible to include the banner in the TCP > SYN+ACK packet coming from the server, but I couldn't swear to it. Maybe. From a look at Stevens and Comer I think it would work at the client end of common TCP stacks, though I can't find any sign of support at the server end. > What I really do like about this draft is the round-trip list - both > this one and the TLS one. Those are actually really useful, and I for > one would appreciate you publishing those on their own in at least I-D > form, and include how it changes if we have TLS session cache hits, etc. > It'd be useful to have a similar one for IMAP. Yes, I need to add something about TLS session cacheing. It has implications for what exchanges can be piggybacked. > [TLS-on-connect is not kosher] > 1) Look at HTTP. Nobody uses TLS except when they absolutely have to, > there, and generally, https: scheme URIs point to different content than > http: scheme URIs. The two ports have mutated into two protocols - not > good. We have this for SMTP too: message submission on port 587, usually with TLS, and message transfer on port 25, usually without. In both cases the general distinction is that TLS is used to protect authentication, and anonymous connections go in the clear. > 2) If unusual ports are used, and TLS is unavailable (something my own > client is sometimes forced to deal with), then splitting the ports means > that it's extremely difficult and ugly to deal with. Simply not issuing > STARTTLS in order to have TLS-less access makes life much easier. You seem to be arguing in favour of the downgrade attack vulnerability. In this situation you must interact with the user because it indicates that some intermediaty (firewall or attacker) is screwing with connectivity to the configured submission server, and they need to find out from someone who knows what is the right thing to do. > [vague ideas about autodetecting TLS] You can't reliably auto-detect plaintext SMTP (or IMAP) versus TLS-on-connect on the same port, because there's a mismatch between who talks first. If it was consistently the client that talked first then the server could autodetect, but the SMTP or IMAP server banner prevents this. > > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-quickstart.txt > > A round-trip saved, that's good. This is a rough analogue of the IMAP > CAPABILITY response code. Exactly. > The question is, is it possible that some ESMTP clients might be > confused by a multiline response? I'm mildly concerned by that. We should try it out. I have a multiline banner on my MX hosts which doesn't cause interop problems, but MUAs are likely to be more troublesome. > There's an alternate model for this sort of thing - you can issue a server > configuration indicator in the banner, which changes whenever the > configuration does, such that if you recognise it, then the EHLO becomes > redundant, because you know the capabilities. Interesting idea, especially for use with STARTTLS. The other thing I am considering is a way for the client to avoid waiting for the server banner, which would save another round trip. This would bring a STARTTLS connection down to 5 RTT, or 4 RTT with a cached TLS session; cf. 3 RTT for TLS-on-connect, or 2 RTT with a cached TLS session and server banner. > Now... In theory we can also elide that AUTH, if TLS session caching hit, > since that's presumably proof enough that we are the same source as last time. > We can certainly use a AUTH EXTERNAL there on that premise, can't we? Another interesting idea, though it doesn't belong in the QUICKSTART document. I was also thinking about implicit authentication recently: if the submission server trusts the IMAP server, the authorization in a URLAUTH implies that the user was recently authenticated by the IMAP server, so the submission server can treat it as an authentication token. > Has anyone been looking at BTNS, which ought to provide much the same > thing with IPSec? I believe the motivation behind BTNS was ssh's known_hosts cache, which avoids the need for a PKI or out-of-band trust management, provided that you make a "leap of faith" and trust the server the first time you connect. There's nothing to prevent you from using this model with TLS; in fact RFC 3207 suggests doing so as a defence against man-in-the-middle attacks when using optional STARTTLS between MTAs. Tony. -- f.a.n.finch http://dotat.at/ SOLE LUNDY FASTNET: EAST OR NORTHEAST 5 TO 7. SHOWERS. GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 22 12:53:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FByB1-00055u-Io; Wed, 22 Feb 2006 12:53:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FByB0-00055o-DF for lemonade@ietf.org; Wed, 22 Feb 2006 12:53:22 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FByAy-0006Fz-Vy for lemonade@ietf.org; Wed, 22 Feb 2006 12:53:22 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:42551) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1FBy9r-0000QI-PS (Exim 4.54) (return-path ); Wed, 22 Feb 2006 17:52:11 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FBy9r-0001Dt-RF (Exim 4.53) (return-path ); Wed, 22 Feb 2006 17:52:11 +0000 Date: Wed, 22 Feb 2006 17:52:11 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Ned Freed Subject: Re: [lemonade] streamlined message submission In-Reply-To: <01LZ9FNBLMAS00009C@mauve.mrochek.com> Message-ID: References: <21533.1140619429.225276@peirce.dave.cridland.net> <01LZ9FNBLMAS00009C@mauve.mrochek.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 22 Feb 2006, Ned Freed wrote: > > Anyway, I know of a couple of tricks in this space. One is the technique > described in RFC 1644, which eliminates the three way handshakes for > repeated connections between the same two machines. There are serious problems with T/TCP. See http://tcp-impl.grc.nasa.gov/tcp-impl/list/archive/1292.html I believe the only OS that ever shipped it is FreeBSD, and the support has rotted to death over recent years as security hardening has broken it. > The other is to piggyback data on either the syn, syn-ack, or both. The former is the essence of T/TCP, and is really undesirable because it makes you MUCH more vulnerable to syn floods. > This used to be a problem in practice, but several years ago some fairly > popular SMTP server started spitting out multiline banners (something > sort of "no trespassing" sign, I think) and refused to provide an option > to disable it, which then got a lot of the incompliant gunk cleaned up. > (It is always nice when something that's widely deployed pushes the > envelope this way.) :-) > > There's an alternate model for this sort of thing - you can issue a > > server configuration indicator in the banner, which changes whenever > > the configuration does, such that if you recognise it, then the EHLO > > becomes redundant, because you know the capabilities. Moreover, > > you've cached them *after* the secure channel setup, of course, so > > you needn't ever fetch them until you see that change. > > We actually use a similar trick in our SMTP in order to avoid having to > code the list of supported extensions into the proxy. This is one of those > things that sounds simple but it is actually surprisingly hard to implement > correctly. I forget exactly what bugs we had, but we definitely had a couple. > I actually worry more about implementors getting this right than I do about > getting multiline banner processing right. It's hard to specify clearly, which is a bad sign. Tony. -- f.a.n.finch http://dotat.at/ CAPE WRATH TO RATTRAY HEAD INCLUDING ORKNEY: NORTH OR NORTHEAST 4 OR 5, OCCASIONALLY 3 AT FIRST. RAIN LATER. GOOD OCCASIONALLY MODERATE LATER. SLIGHT OR MODERATE. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 22 20:14:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC54K-0007bM-Ob; Wed, 22 Feb 2006 20:14:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC54J-0007ZW-Mr for lemonade@ietf.org; Wed, 22 Feb 2006 20:14:55 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC54I-0005Z6-1T for lemonade@ietf.org; Wed, 22 Feb 2006 20:14:55 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FC54G-0004kA-Tw; Thu, 23 Feb 2006 01:14:53 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 57D62498003; Thu, 23 Feb 2006 01:15:04 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13140-08; Thu, 23 Feb 2006 01:14:59 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id D7CD9498002; Thu, 23 Feb 2006 01:14:59 +0000 (GMT) Date: Thu, 23 Feb 2006 01:14:47 +0000 Subject: Re: [lemonade] streamlined message submission References: <21533.1140619429.225276@peirce.dave.cridland.net> In-Reply-To: MIME-Version: 1.0 Message-Id: <22667.1140657288.257701@peirce.dave.cridland.net> From: Dave Cridland To: Tony Finch Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Feb 22 17:16:51 2006, Tony Finch wrote: > On Wed, 22 Feb 2006, Dave Cridland wrote: > > > > > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-submission-streamlined.txt > > > > BURL doesn't allow clients to pipeline AUTH - that's just possible > > anyway with a server that supports PIPELINING. > > The BURL spec is the only document that gives permission to do it. > The > AUTH spec doesn't say anything about PIPELINING, and PIELINING says > > Additional commands added by other SMTP extensions may only > appear as > the last command in a group unless otherwise specified by the > extensions that define the commands. > > RFC 3030 is a bit unclear about the interaction of BDAT and > pipelining - > it doesn't describe things in terms of the "last command in a > group" as > RFC 2920 does. It does allow BDAT to be pipelined with itself but > doesn't > talk about pipelining it with the preceding or following envelopes. > The > BURL spec clarifies that you can do this is the server supports > BURL. > > Right, that's an interesting thing I'd not noticed before. As I've said before, I've always held the opinion that really, you want to know if you've misspelt an address before sending it to anyone at all, so I've always sent the envelope in one group, and the data in another. > > Oh, and I believe that it's possible to include the banner in the > TCP > > SYN+ACK packet coming from the server, but I couldn't swear to it. > > Maybe. From a look at Stevens and Comer I think it would work at the > client end of common TCP stacks, though I can't find any sign of > support > at the server end. > > Okay... As far as I can find out, there's no API for this in the Linux implementation, but apparently, Phil Karn's KA9Q NOS (which I'm not familiar with at all) has done this for years. Between us, we must know someone who can do an API implementation on either FreeBSD or Linux, surely? > > [TLS-on-connect is not kosher] > > > 1) Look at HTTP. Nobody uses TLS except when they absolutely have > to, > > there, and generally, https: scheme URIs point to different > content than > > http: scheme URIs. The two ports have mutated into two protocols > - not > > good. > > We have this for SMTP too: message submission on port 587, usually > with > TLS, and message transfer on port 25, usually without. In both > cases the > general distinction is that TLS is used to protect authentication, > and > anonymous connections go in the clear. > > Ah, but we have the option to have anonymous MTA activity use TLS (there's plenty of MX machines supporting this), and the option to use, say, IP Sec etc for submission. > > 2) If unusual ports are used, and TLS is unavailable (something > my own > > client is sometimes forced to deal with), then splitting the > ports means > > that it's extremely difficult and ugly to deal with. Simply not > issuing > > STARTTLS in order to have TLS-less access makes life much easier. > > You seem to be arguing in favour of the downgrade attack > vulnerability No, I meant the client platform doesn't have TLS support available. Sadly, Polymer has to deal with that, too, sometimes. Generally it's older Python versions on Linux and other UNIXes, where the TLS code doesn't handle non-blocking sockets. So when given "imaps" URIs, I have to attempt to guess what the "imap" port might be, and hope it's equivalent. Obviously I issue a paranoia warning, too. > > [vague ideas about autodetecting TLS] > > You can't reliably auto-detect plaintext SMTP (or IMAP) versus > TLS-on-connect on the same port, because there's a mismatch between > who > talks first. If it was consistently the client that talked first > then the > server could autodetect, but the SMTP or IMAP server banner > prevents this. > > Well, you could in theory autodetect after the banner was sent, and the banner would need to indicate whether TLS autodetection were supported. > > The question is, is it possible that some ESMTP clients might be > > confused by a multiline response? I'm mildly concerned by that. > > We should try it out. I have a multiline banner on my MX hosts which > doesn't cause interop problems, but MUAs are likely to be more > troublesome. > > Test it out on those annoying students. :-) > > There's an alternate model for this sort of thing - you can issue > a server > > configuration indicator in the banner, which changes whenever the > > configuration does, such that if you recognise it, then the EHLO > becomes > > redundant, because you know the capabilities. > > Interesting idea, especially for use with STARTTLS. > > Ned seems to shoot it down based on experience, which I'll bow to. My gut feeling was that it really ought to be possible to specify this quite easily, and implement it easily, too, just by using a relatively strong hash of the capability listing. > The other thing I am considering is a way for the client to avoid > waiting > for the server banner, which would save another round trip. This > would > bring a STARTTLS connection down to 5 RTT, or 4 RTT with a cached > TLS > session; cf. 3 RTT for TLS-on-connect, or 2 RTT with a cached TLS > session > and server banner. > > *nods* Wrapping the banner into the SYN+ACK would seem to have the same effect for an easier shot, if we can. Means having platform level support, of course. > > Now... In theory we can also elide that AUTH, if TLS session > caching hit, > > since that's presumably proof enough that we are the same source > as last time. > > We can certainly use a AUTH EXTERNAL there on that premise, can't > we? > > Another interesting idea, though it doesn't belong in the QUICKSTART > document. I was also thinking about implicit authentication > recently: if > the submission server trusts the IMAP server, the authorization in a > URLAUTH implies that the user was recently authenticated by the IMAP > server, so the submission server can treat it as an authentication > token. > > No... Posession of a URLAUTH URL doesn't mean that you obtained it from the IMAP server, you might have obtained it from someone else, legally or otherwise. > > Has anyone been looking at BTNS, which ought to provide much the > same > > thing with IPSec? > > I believe the motivation behind BTNS was ssh's known_hosts cache, > which > avoids the need for a PKI or out-of-band trust management, provided > that > you make a "leap of faith" and trust the server the first time you > connect. There's nothing to prevent you from using this model with > TLS; > in fact RFC 3207 suggests doing so as a defence against > man-in-the-middle > attacks when using optional STARTTLS between MTAs. > > BTNS charter seemed to suggest to me it related to ascertaining that the peer was the same peer as previously. If the "previous" connection was authenticated, then it seems to me that provides useful information without any leaps of faith. Of course, nightmares ensue if you've multiple connections to the same peer using *different* authentication, and these mechanisms can't differentiate. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Wed Feb 22 22:26:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC77c-0006xq-O3; Wed, 22 Feb 2006 22:26:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FC77b-0006xl-KV for lemonade@ietf.org; Wed, 22 Feb 2006 22:26:27 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FC77W-0002tM-7e for lemonade@ietf.org; Wed, 22 Feb 2006 22:26:27 -0500 Received: from fe-amer-02.sun.com ([192.18.108.176]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k1N3QK8u020553 for ; Wed, 22 Feb 2006 20:26:21 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IV400401DH7MU00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for lemonade@ietf.org; Wed, 22 Feb 2006 20:26:20 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IV4002BUEVT9410@mail-amer.sun.com>; Wed, 22 Feb 2006 20:26:20 -0700 (MST) Date: Wed, 22 Feb 2006 19:27:37 -0800 From: Chris Newman Subject: Re: [lemonade] streamlined message submission In-reply-to: To: Tony Finch , lemonade@ietf.org Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Tony Finch wrote on 2/22/06 0:54 +0000: > The talk about round-trip times on the main IETF list (combined with some > other things I have been thinking abou recently) got me interested. How > much can you streamline message submission? Current securely authenticated > message submission requires at least eleven round trips (including TCP > startup and shutdown). BURL can reduce this to nine. I'm glad someone noticed that little feature I slipped into BURL :-) > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-tls-on-connect.txt As written, I'd have to strongly oppose this draft. If you recast it as a "submits" port that is never to be used for MTA to MTA transfer, that addresses the most serious concern. But I still think this is the wrong direction to move. While I'd have to say TLS is the only truly useful security layer for applications available today, it's wrong to assume that will be true for the indefinite future. If the IPsec folks ever come up with APIs and mechanisms that are useful for user authentication by applications, then that would probably be a preferable mechanism as it could resist DOS attacks that TLS can't. Deploying a new port in submit clients is difficult (and deploying a new port in SMTP clients is borderline impossible). We're just starting to see 587 catch on despite years of ISPs blocking outbound port 25 and the other deployment reasons to use a separate port for submission. Introducing another port now would just involve more disruption and confusion and make interoperability worse. I recommend you drop this proposal and focus on a modification of quickstart (perhaps QUICKSTART+TLS), to avoid waiting for either the server success response to the STARTTLS command, or requiring a new EHLO command after the STARTTLS command. That gets most of the benefit without assuming TLS is the only security layer ever used. FWIW, some other problems with separate ports are documented here: http://www.apps.ietf.org/rfc/rfc2595.html#sec-7 Some of that text is dated. The second bullet is correct in spirit but wrong in details due to changes in what was deployed then vs. now (40-bit is gone and GSSAPI+Kerberos 5 had security flaws). The third bullet is wrong, but can be corrected by replacing "use TLS when available" with "require TLS if it's been advertised previously for that service". Indeed, I'd argue the best clients should use that policy by default. > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-quickstart.txt I like this idea. IMAP made a similar move in the RFC 3501 revision and I believe it has worked well in practice. I have no objections to adopting this as a lemonade WG item, or pursuing it as an individual submission. > http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-rcpthdr.txt The semantics of RFC 822/2822 headers and RFC 821/2821 envelope recipients are subtly different. Those differences make attempts to derive the envelope from the headers a dangerous and error-prone thing to do. Imagine what would happen if the post office opened letters and determined the recipient address from the letter headers? It would probably work most of the time, but the failures would be spectacular and unpleasant. I believe the same is true of this proposal. It introduces a level of operational complexity into the system that is best avoided. I know it's annoying for a mail client to construct an SMTP envelope and RFC 2822 header which usually contain the same information, but it's also simple. If you really want to pursue something along these lines, I suspect the reverse approach is viable: construct the RFC 2822 headers from an annotated SMTP envelope at submit time. - Chris _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 08:08:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCGCy-0003mG-2G; Thu, 23 Feb 2006 08:08:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCG1C-0003sA-OS for lemonade@ietf.org; Thu, 23 Feb 2006 07:56:26 -0500 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCG1B-0008At-AG; Thu, 23 Feb 2006 07:56:26 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:57979) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1FCG13-0003SI-2Q (Exim 4.54) (return-path ); Thu, 23 Feb 2006 12:56:17 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FCG13-00084t-Mt (Exim 4.53) (return-path ); Thu, 23 Feb 2006 12:56:17 +0000 Date: Thu, 23 Feb 2006 12:56:17 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Chris Newman In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-Mailman-Approved-At: Thu, 23 Feb 2006 08:08:35 -0500 Cc: lemonade@ietf.org, ietf-smtp@ietf.org, Gregory Vaudreuil Subject: [lemonade] Re: PIPELINING, AUTH, and CHUNKING X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed, 22 Feb 2006, Chris Newman wrote: > Tony Finch wrote on 2/22/06 0:54 +0000: > > > Current securely authenticated message submission requires at least > > eleven round trips (including TCP startup and shutdown). BURL can > > reduce this to nine. > > I'm glad someone noticed that little feature I slipped into BURL :-) Yes it is nice, but on reflection I think the way it is specified isn't ideal. In particular, to quote that bit from RFC 2920 again: Additional commands added by other SMTP extensions may only appear as the last command in a group unless otherwise specified by the extensions that define the commands. So I think the BURL spec is wrong to talk about pipelining AUTH, and if you want to allow pipelined AUTH it should be specified as an update to RFC 2554. Furthermore, it isn't safe in all situations for a client to pipeline a single round-trip AUTH. For example, it's common to have dual-purpose MSA and MX servers which operate in MSA mode after AUTH and MX mode otherwise. If the client pipelines an AUTH and an intended submission, but the auth fails, bad things will happen - recipients will be rejected that would have been OK, an incomplete message will suffer an anti-spam penalty instead of being fixed up, etc. Pipelined AUTH is OK if the server is going to reject any un-authenticated submissions, in which case the server should explicitly say so, perhaps by using an EHLO keyword line such as 250 PIPEAUTH PLAIN EXTERNAL. I've also copied this message to Gregory Vaudreuil because of questions about PIPELINING and BDAT, as well as BURL. RFC 3030 implies that BDAT can be pipelined, though the way it says so doesn't follow the "last command in a group" model of RFC 2920. Furthermore, some of the descriptive text and the example in section 4.2 imply a synchronization point between the envelope and data, though because all the commands in the sequence can be pipelined, this isn't a forced sync point. It would be more correct to terminate the envelope commands with a NOOP to force a sync. The BURL spec requires a sync point after the "LAST" BDAT or BURL command, instead of after the message envelope. I think it would be better for BDAT and BURL to not require any synchronization at all: if the client wants a sync, it can use the NOOP command. Note that the main reason a sync point is required after DATA is so that the client and server agree about whether the next utterance from the client is a command or is message data. This isn't a problem for BDAT because the command and data are sent together, with a single response from the server for both. This would allow a client to pipeline multiple messages together, which means you can move from using TCP in interactive mode to bulk data mode, and therefore make the best use of the available bandwidth. For example, consider a 1Mb/s link with a 100ms RTT. If the client sends a 5KB message, this takes about 50ms to transmit, so by the time the server's replies arrive the client will be one or two messages further on; if there was a problem, the client can deal with it asynchronously, and it will have done 50ms extra useful work. If the client sends a 20KB message, the server's replies will start arriving part-way through message transmission, so if there is a problem the client can usefully RSET it before the next chunk to save time and bandwidth. I think it would be cool to allow this kind of high-bandwidth asynchronous message transmission. It is also more friendly from the point of congestion control than having multiple concurrent SMTP connections perpetually in TCP slow start. Tony. -- f.a.n.finch http://dotat.at/ FAIR ISLE FAEROES: NORTH OR NORTHEAST 4 OR 5, INCREASING 6 IN FAIR ISLE FOR A TIME, BUT VARIABLE 4 IN FAEROES AT FIRST. FAIR. GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 08:22:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCGQV-00047k-SW; Thu, 23 Feb 2006 08:22:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCGQT-00045T-Dy for lemonade@ietf.org; Thu, 23 Feb 2006 08:22:33 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCGQP-0000rt-4g for lemonade@ietf.org; Thu, 23 Feb 2006 08:22:33 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39204) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1FCGQG-0007Y1-PQ (Exim 4.54) (return-path ); Thu, 23 Feb 2006 13:22:20 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FCGQG-0003Q3-Qv (Exim 4.53) (return-path ); Thu, 23 Feb 2006 13:22:20 +0000 Date: Thu, 23 Feb 2006 13:22:20 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Cridland , Ned Freed , Chris Newman In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org Subject: [lemonade] Re: PIPELINING and failed recipients X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I think both Ned and Dave mentioned the irritation that can arise from a message and receiving a bounce for some of the recipients. (Note to self: ietf-smtp@ietf.org is the wrong address). One advantage of a sync point after the message envelope is that the client can decide not to proceed if a subset of the recipients are rejected; this doesn't work if the envelope and data are pipelined. (It is also limited by how strongly the server can verify addresses.) What do you think of having a NOPARTFAIL parameter to the MAIL command, which means that the client is asking the server to reject the message data if any of the recipients are rejected - "no partial failure". Tony. -- f.a.n.finch http://dotat.at/ NORTH UTSIRE: VARIABLE 4, BUT NORTHEAST 5 TO 7 AT FIRST IN NORTHWEST. SHOWERS LATER. GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 08:52:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCGtA-0005Ll-5Z; Thu, 23 Feb 2006 08:52:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCGt8-0005LA-Es for lemonade@ietf.org; Thu, 23 Feb 2006 08:52:10 -0500 Received: from mxgate1.brooktrout.com ([204.176.74.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCGt5-0002GJ-8J for lemonade@ietf.org; Thu, 23 Feb 2006 08:52:10 -0500 X-IronPort-AV: i="4.02,140,1139202000"; d="scan'208"; a="28870119:sNHT37756160" X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 23 Feb 2006 08:51:35 -0500 Message-ID: <330A23D8336C0346B5C1A5BB19666647024A20A9@ATLANTIS.Brooktrout.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 65th IETF DRAFT Agenda Thread-Index: AcY2EGcABOZd5402Tm213gPhzH/iMACb7PHA From: "Burger, Eric" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [lemonade] FW: 65th IETF DRAFT Agenda X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Preliminary. Don't complain if you buy tickets and these dates or times change. -----Original Message----- From: IETF Agenda [mailto:agenda@ietf.org]=20 Sent: Saturday, February 18, 2006 11:47 PM DRAFT Agenda of the Sixty-fifth IETF March 19-24, 2006 As of 02/18/2006 MONDAY, March 20, 2006 1520-1720 Afternoon Session II APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG WEDNESDAY, March 22 2006 0900-1130 Morning Session I APP lemonade Enhancements to Internet email to Support Diverse Service Environments WG _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 09:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHXv-000089-Bx; Thu, 23 Feb 2006 09:34:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHXu-00007z-6v for lemonade@ietf.org; Thu, 23 Feb 2006 09:34:18 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCHXs-0004Y7-Q2; Thu, 23 Feb 2006 09:34:18 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k1NEY9xx011228; Thu, 23 Feb 2006 08:34:09 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Feb 2006 08:34:09 -0600 Message-ID: <54E40201497DF142B06B27255953F7971BFAC739@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Tony Finch Date: Thu, 23 Feb 2006 08:34:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: lemonade@ietf.org, ietf-smtp@ietf.org Subject: [lemonade] RE: PIPELINING, AUTH, and CHUNKING X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org A revised version of the ESMTP binary extension expired as an ID two years ago or so. That document clarified the interaction between chunking and pipelining. A reference to the expired draft is below. I stalled in the process of moving the document to draft standard (unable to compile a suitable implementation report). I will resurect the draft and edit the language to make it consistent with the RFC 2920 concept of a group. http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-vaudreuil-esmtp-binary3-01.txt Greg V. -----Original Message----- From: Tony Finch [mailto:fanf2@hermes.cam.ac.uk]On Behalf Of Tony Finch Sent: Thursday, February 23, 2006 7:56 AM To: Chris Newman Cc: Tony Finch; Gregory Vaudreuil; lemonade@ietf.org; ietf-smtp@ietf.org Subject: Re: PIPELINING, AUTH, and CHUNKING On Wed, 22 Feb 2006, Chris Newman wrote: > Tony Finch wrote on 2/22/06 0:54 +0000: > > > Current securely authenticated message submission requires at least > > eleven round trips (including TCP startup and shutdown). BURL can > > reduce this to nine. > > I'm glad someone noticed that little feature I slipped into BURL :-) Yes it is nice, but on reflection I think the way it is specified isn't ideal. In particular, to quote that bit from RFC 2920 again: Additional commands added by other SMTP extensions may only appear as the last command in a group unless otherwise specified by the extensions that define the commands. So I think the BURL spec is wrong to talk about pipelining AUTH, and if you want to allow pipelined AUTH it should be specified as an update to RFC 2554. Furthermore, it isn't safe in all situations for a client to pipeline a single round-trip AUTH. For example, it's common to have dual-purpose MSA and MX servers which operate in MSA mode after AUTH and MX mode otherwise. If the client pipelines an AUTH and an intended submission, but the auth fails, bad things will happen - recipients will be rejected that would have been OK, an incomplete message will suffer an anti-spam penalty instead of being fixed up, etc. Pipelined AUTH is OK if the server is going to reject any un-authenticated submissions, in which case the server should explicitly say so, perhaps by using an EHLO keyword line such as 250 PIPEAUTH PLAIN EXTERNAL. I've also copied this message to Gregory Vaudreuil because of questions about PIPELINING and BDAT, as well as BURL. RFC 3030 implies that BDAT can be pipelined, though the way it says so doesn't follow the "last command in a group" model of RFC 2920. Furthermore, some of the descriptive text and the example in section 4.2 imply a synchronization point between the envelope and data, though because all the commands in the sequence can be pipelined, this isn't a forced sync point. It would be more correct to terminate the envelope commands with a NOOP to force a sync. The BURL spec requires a sync point after the "LAST" BDAT or BURL command, instead of after the message envelope. I think it would be better for BDAT and BURL to not require any synchronization at all: if the client wants a sync, it can use the NOOP command. Note that the main reason a sync point is required after DATA is so that the client and server agree about whether the next utterance from the client is a command or is message data. This isn't a problem for BDAT because the command and data are sent together, with a single response from the server for both. This would allow a client to pipeline multiple messages together, which means you can move from using TCP in interactive mode to bulk data mode, and therefore make the best use of the available bandwidth. For example, consider a 1Mb/s link with a 100ms RTT. If the client sends a 5KB message, this takes about 50ms to transmit, so by the time the server's replies arrive the client will be one or two messages further on; if there was a problem, the client can deal with it asynchronously, and it will have done 50ms extra useful work. If the client sends a 20KB message, the server's replies will start arriving part-way through message transmission, so if there is a problem the client can usefully RSET it before the next chunk to save time and bandwidth. I think it would be cool to allow this kind of high-bandwidth asynchronous message transmission. It is also more friendly from the point of congestion control than having multiple concurrent SMTP connections perpetually in TCP slow start. Tony. -- f.a.n.finch http://dotat.at/ FAIR ISLE FAEROES: NORTH OR NORTHEAST 4 OR 5, INCREASING 6 IN FAIR ISLE FOR A TIME, BUT VARIABLE 4 IN FAEROES AT FIRST. FAIR. GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 09:45:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHiN-00078F-9T; Thu, 23 Feb 2006 09:45:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHiL-000785-N8 for lemonade@ietf.org; Thu, 23 Feb 2006 09:45:05 -0500 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCHiK-0004zH-Dk for lemonade@ietf.org; Thu, 23 Feb 2006 09:45:05 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:42781) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1FCHiB-0002eG-20 (Exim 4.54) (return-path ); Thu, 23 Feb 2006 14:44:55 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FCHiB-0007NU-I9 (Exim 4.53) (return-path ); Thu, 23 Feb 2006 14:44:55 +0000 Date: Thu, 23 Feb 2006 14:44:55 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Vaudreuil, Greg M (Greg)" In-Reply-To: <54E40201497DF142B06B27255953F7971BFAC739@il0015exch007u.ih.lucent.com> Message-ID: References: <54E40201497DF142B06B27255953F7971BFAC739@il0015exch007u.ih.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: lemonade@ietf.org Subject: [lemonade] RE: PIPELINING, AUTH, and CHUNKING X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 23 Feb 2006, Vaudreuil, Greg M (Greg) wrote: > > A revised version of the ESMTP binary extension expired as an ID two > years ago or so. That document clarified the interaction between > chunking and pipelining. A reference to the expired draft is below. Cool, thanks. Yes, it's much clearer, and allows full pipelining of multiple messages :-) > I stalled in the process of moving the document to draft standard > (unable to compile a suitable implementation report). I will resurect > the draft and edit the language to make it consistent with the RFC 2920 > concept of a group. A couple of additional suggestions arising from the updated draft: Should the sentence abut pipelining in the middle of page 4 be moved to the paragraph about pipelining at the top of the same page? Also, "Receivers MUST accept the BDAT command even where there are no valid recipients." - why not allow them to reject in this situation? Tony. -- f.a.n.finch http://dotat.at/ TYNE DOGGER: NORTHEAST 4 VEERING EAST 5 OR 6. OCCASIONAL RAIN. MAINLY GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 11:09:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJ1z-0005DK-2Y; Thu, 23 Feb 2006 11:09:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJ1y-0005CC-6K for lemonade@ietf.org; Thu, 23 Feb 2006 11:09:26 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCJ1w-0003WF-V7 for lemonade@ietf.org; Thu, 23 Feb 2006 11:09:26 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k1NG9CMl009783; Thu, 23 Feb 2006 10:09:12 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Feb 2006 10:09:12 -0600 Message-ID: <54E40201497DF142B06B27255953F7971BFAC91E@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Tony Finch Date: Thu, 23 Feb 2006 10:09:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: lemonade@ietf.org Subject: [lemonade] RE: PIPELINING, AUTH, and CHUNKING X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org >Cool, thanks. Yes, it's much clearer, and allows full pipelining of >multiple messages :-) Allowing multiple messages was not the intent. Help me figure out why you see this as acceptable so I can fix it when I align the language with RFC 2920 :-) >Also, "Receivers MUST accept the BDAT command even where there are no >valid recipients." - why not allow them to reject in this situation? Can you suggest better language? The receiver has to ingest BDAT segments when there are no valid recipients... the sender will place these segments in-flight before they know if there are valid recipients. The receiver has to eat the full chunk, and then discard if there is no one to relay the data to. I called the process of eating the bytes in flight and preparing for the next command "accept". Greg V. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 12:14:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJzf-0004TS-D0; Thu, 23 Feb 2006 12:11:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCJze-0004TK-1L for lemonade@ietf.org; Thu, 23 Feb 2006 12:11:06 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCJzd-0005bI-KU for lemonade@ietf.org; Thu, 23 Feb 2006 12:11:06 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:42715) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1FCJwD-0004Fi-Ni (Exim 4.54) (return-path ); Thu, 23 Feb 2006 17:07:33 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FCJwD-0003ON-6f (Exim 4.53) (return-path ); Thu, 23 Feb 2006 17:07:33 +0000 Date: Thu, 23 Feb 2006 17:07:33 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Vaudreuil, Greg M (Greg)" In-Reply-To: <54E40201497DF142B06B27255953F7971BFAC91E@il0015exch007u.ih.lucent.com> Message-ID: References: <54E40201497DF142B06B27255953F7971BFAC91E@il0015exch007u.ih.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: lemonade@ietf.org Subject: [lemonade] RE: PIPELINING, AUTH, and CHUNKING X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 23 Feb 2006, Vaudreuil, Greg M (Greg) wrote: > > Allowing multiple messages was not the intent. Help me figure out why > you see this as acceptable so I can fix it when I align the language > with RFC 2920 :-) >From the client point of view, as with normal pipelining you would need to keep track of all the commands that you had issued but not yet received replies to. The difference is that these commands & replies can relate to multiple outstanding message transmissions. When the client receives a reply corresponding to a BDAT LAST command, it performs the processing it would perform after the reply to a . in trad SMTP (e.g. marking the message as completed). One thing to worry about might be RFC 1047 message duplication, but this pipelining should not add any extra latency to the round trip between the clientftinishing transmission of the message and receiving the server's reply, so it should not make the problem worse. > >Also, "Receivers MUST accept the BDAT command even where there are no > >valid recipients." - why not allow them to reject in this situation? > > Can you suggest better language? Ah, I had read "accept" as "give a success reply to" (as opposed to reject). I suggest the following text for the paragraph about pipelining: If the receiver-SMTP has declared support for the PIPELINING extension [PIPE], the BDAT command MAY appear at any point in a pipelined group of commands. That is, the sender-SMTP MAY send BDAT commands immediately after the MAIL FROM and RCPT TO commands, and it is not necessary to wait for the response to determine if there is a valid recipient. The receiver-SMTP MUST be prepared to read and reply to BDAT commands even when there are no valid recipients. As when pipelining after the DATA command, the sender-SMTP MAY also send MAIL FROM and other commands for the next message immediately after sending the BDAT LAST of the current message. The sender-SMTP MAY use the NOOP command to introduce a synchronization point. And in the paragraph about BDAT failures: A 250 response MUST be sent to each successful BDAT data block within a mail transaction. If a failure occurs after a BDAT command is received, the receiver-SMTP MUST read and discard the associated message data before sending the appropriate 5XX or 4XX code. If a 5XX or 4XX code is received by the sender-SMTP in response to a BDAT chunk, the transaction SHOULD be considered failed and the sender-SMTP SHOULD NOT send any additional BDAT segments. If the receiver-SMTP has declared support for command pipelining [PIPE], it MUST be prepared to read additional BDAT chunks already in the pipeline after the failed BDAT; it SHOULD reply to them with the same 5XX or 4XX error as the preceding failed chunk. Tony. -- f.a.n.finch http://dotat.at/ FAEROES: VARIABLE 4 BECOMING NORTH OR NORTHEAST 4 OR 5. FAIR. GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 13:43:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLQq-000625-4n; Thu, 23 Feb 2006 13:43:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLQp-000607-Em for lemonade@ietf.org; Thu, 23 Feb 2006 13:43:15 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCLQo-0008HJ-4z for lemonade@ietf.org; Thu, 23 Feb 2006 13:43:15 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FCLQm-0005L0-Pc; Thu, 23 Feb 2006 18:43:12 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 72CFE498004; Thu, 23 Feb 2006 18:43:31 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17760-04; Thu, 23 Feb 2006 18:43:23 +0000 (GMT) Received: from invsysm1 (unknown [213.205.200.194]) by turner.dave.cridland.net (Postfix) with ESMTP id B376B498002; Thu, 23 Feb 2006 18:43:20 +0000 (GMT) Date: Thu, 23 Feb 2006 18:43:34 +0000 Subject: Re: [lemonade] RE: PIPELINING, AUTH, and CHUNKING References: <54E40201497DF142B06B27255953F7971BFAC91E@il0015exch007u.ih.lucent.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <9210.1140720274.153511@invsysm1> From: Dave Cridland To: Tony Finch Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Feb 23 17:07:33 2006, Tony Finch wrote: > On Thu, 23 Feb 2006, Vaudreuil, Greg M (Greg) wrote: > > > > Allowing multiple messages was not the intent. Help me figure > out why > > you see this as acceptable so I can fix it when I align the > language > > with RFC 2920 :-) > > I've no problem at all with sending the next transaction pipelined with the end of the first. > message. The sender-SMTP MAY use the NOOP command to introduce a > synchronization point. Why? Surely if you want to synchronize, you just wait for all outstanding commands to be completed? A NOOP at the end is just extra data. Dave. (On the train via GPRS.) -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 13:50:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLYA-0002wI-SC; Thu, 23 Feb 2006 13:50:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLY9-0002sX-K3 for lemonade@ietf.org; Thu, 23 Feb 2006 13:50:49 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCLY9-0008QY-79 for lemonade@ietf.org; Thu, 23 Feb 2006 13:50:49 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FCLY7-0001T5-Sx; Thu, 23 Feb 2006 18:50:47 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id CD008498003; Thu, 23 Feb 2006 18:51:06 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17849-03; Thu, 23 Feb 2006 18:50:58 +0000 (GMT) Received: from invsysm1 (unknown [213.205.200.194]) by turner.dave.cridland.net (Postfix) with ESMTP id D4262498002; Thu, 23 Feb 2006 18:50:55 +0000 (GMT) Date: Thu, 23 Feb 2006 18:51:29 +0000 References: In-Reply-To: MIME-Version: 1.0 Message-Id: <9210.1140720723.319530@invsysm1> From: Dave Cridland To: Tony Finch Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Enhancements to Internet email to support diverse service enivronments , Chris Newman , Ned Freed Subject: [lemonade] Re: PIPELINING and failed recipients X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Feb 23 13:22:20 2006, Tony Finch wrote: > I think both Ned and Dave mentioned the irritation that can arise > from a > message and receiving a bounce for some of the recipients. (Note to > self: > ietf-smtp@ietf.org is the wrong address). One advantage of a sync > point > after the message envelope is that the client can decide not to > proceed if > a subset of the recipients are rejected; this doesn't work if the > envelope > and data are pipelined. This is what Polymer does already - it synchs after the envelope, before sending any data command (ie, DATA/BURL/BDAT). > (It is also limited by how strongly the server can > verify addresses.) What do you think of having a NOPARTFAIL > parameter to > the MAIL command, which means that the client is asking the server > to > reject the message data if any of the recipients are rejected - "no > partial failure". Hard to implement conclusively. Also, if the server rejects one recipient out of several, and the client doesn't wish the message to be sent, why on earth transmit the data? Transmission bears a very high cost, both in terms of battery power on a mobile phone, and in terms of financial cost. Dave. (Currently hit 10.91k up, 38.45k down over expensive UK GPRS) -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 14:08:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLpg-0004nD-3y; Thu, 23 Feb 2006 14:08:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLpe-0004ke-4b for lemonade@ietf.org; Thu, 23 Feb 2006 14:08:54 -0500 Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCLoE-0000Jp-0P for lemonade@ietf.org; Thu, 23 Feb 2006 14:07:27 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:52098) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1FCLns-0003bE-4E (Exim 4.54) (return-path ); Thu, 23 Feb 2006 19:07:04 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FCLns-0004xp-93 (Exim 4.53) (return-path ); Thu, 23 Feb 2006 19:07:04 +0000 Date: Thu, 23 Feb 2006 19:07:04 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Cridland Subject: Re: [lemonade] RE: PIPELINING, AUTH, and CHUNKING In-Reply-To: <9210.1140720274.153511@invsysm1> Message-ID: References: <54E40201497DF142B06B27255953F7971BFAC91E@il0015exch007u.ih.lucent.com> <9210.1140720274.153511@invsysm1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 23 Feb 2006, Dave Cridland wrote: > > > The sender-SMTP MAY use the NOOP command to introduce a > > synchronization point. > > Why? RFC 2920 says NOOP is included in the group of commands that can only appear as the last command in a group so that it can be used as a synchronization point. Perhaps I'm suggesting defences against bugs that don't exist... Tony. -- f.a.n.finch http://dotat.at/ SOUTHEAST ICELAND: SOUTHWEST 4 OR 5, OCCASIONALLY 6 AT FIRST, BECOMING VARIABLE 4. MAINLY FAIR. GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 14:09:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLpy-00051Y-O5; Thu, 23 Feb 2006 14:09:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLpg-0004ke-Dk for lemonade@ietf.org; Thu, 23 Feb 2006 14:08:56 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCLjF-0000Eh-8c for lemonade@ietf.org; Thu, 23 Feb 2006 14:02:19 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:50530) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1FCLj4-0004RO-NB (Exim 4.54) (return-path ); Thu, 23 Feb 2006 19:02:06 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FCLj4-0004DS-52 (Exim 4.53) (return-path ); Thu, 23 Feb 2006 19:02:06 +0000 Date: Thu, 23 Feb 2006 19:02:06 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: lemonade@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.6 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [lemonade] SMTP QUICKSTART X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I have updated the QUICKSTART draft. The main difference is a description of how to save the server greeting round-trip and how to skip EHLO after STARTTLS. I've added packet traces to show the three RTT savings from QUICKSTART plus one from TLS session cacheing. I'm wondering if it might be safer for the client to indicate quickstart using a QHLO command, which may be pipelined. Any opinions? http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-quickstart.txt Tony. -- f.a.n.finch http://dotat.at/ MULL OF KINTYRE TO ARDNAMURCHAN POINT: NORTHEAST VEERING EAST 4 OR 5. RAIN AT FIRST. MAINLY GOOD. MODERATE OR ROUGH OFFSHORE. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 14:19:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLzY-0003Wv-Pg; Thu, 23 Feb 2006 14:19:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCLzX-0003WH-FT for lemonade@ietf.org; Thu, 23 Feb 2006 14:19:07 -0500 Received: from rutherford.zen.co.uk ([212.23.3.142]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCLzV-0000m4-5o for lemonade@ietf.org; Thu, 23 Feb 2006 14:19:07 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by rutherford.zen.co.uk with esmtp (Exim 4.34) id 1FCLzU-0000UE-2s; Thu, 23 Feb 2006 19:19:04 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id B57EA498003; Thu, 23 Feb 2006 19:19:22 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17849-10; Thu, 23 Feb 2006 19:19:05 +0000 (GMT) Received: from invsysm1 (unknown [213.205.200.194]) by turner.dave.cridland.net (Postfix) with ESMTP id 78560498002; Thu, 23 Feb 2006 19:19:00 +0000 (GMT) Date: Thu, 23 Feb 2006 19:19:39 +0000 Subject: Re: [lemonade] RE: PIPELINING, AUTH, and CHUNKING References: <54E40201497DF142B06B27255953F7971BFAC91E@il0015exch007u.ih.lucent.com> <9210.1140720274.153511@invsysm1> In-Reply-To: MIME-Version: 1.0 Message-Id: <22658.1140722416.152560@invsysm1> From: Dave Cridland To: Tony Finch Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Rutherford-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Feb 23 19:07:04 2006, Tony Finch wrote: > On Thu, 23 Feb 2006, Dave Cridland wrote: > > > > > The sender-SMTP MAY use the NOOP command to introduce a > > > synchronization point. > > > > Why? > > RFC 2920 says NOOP is included in the group of commands that can > only > appear as the last command in a group so that it can be used as a > synchronization point. Perhaps I'm suggesting defences against bugs > that > don't exist... I think so. The only way that would help is if the client couldn't track completion of the individual commands. In which case it's really not going to work anyway. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 14:46:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCMPw-0002nx-L8; Thu, 23 Feb 2006 14:46:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCMPv-0002ns-BX for lemonade@ietf.org; Thu, 23 Feb 2006 14:46:23 -0500 Received: from heisenberg.zen.co.uk ([212.23.3.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCMPt-0001eP-Uq for lemonade@ietf.org; Thu, 23 Feb 2006 14:46:23 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by heisenberg.zen.co.uk with esmtp (Exim 4.30) id 1FCMPs-0004zb-Ud; Thu, 23 Feb 2006 19:46:21 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id 4977C498003; Thu, 23 Feb 2006 19:46:40 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17969-08; Thu, 23 Feb 2006 19:46:37 +0000 (GMT) Received: from invsysm1 (unknown [213.205.200.194]) by turner.dave.cridland.net (Postfix) with ESMTP id A51DE498002; Thu, 23 Feb 2006 19:46:31 +0000 (GMT) Date: Thu, 23 Feb 2006 19:47:02 +0000 Subject: Re: [lemonade] SMTP QUICKSTART References: In-Reply-To: MIME-Version: 1.0 Message-Id: <25269.1140724067.114807@invsysm1> From: Dave Cridland To: Tony Finch Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Heisenberg-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu Feb 23 19:02:06 2006, Tony Finch wrote: > I have updated the QUICKSTART draft. The main difference is a > description > of how to save the server greeting round-trip and how to skip EHLO > after > STARTTLS. I've added packet traces to show the three RTT savings > from > QUICKSTART plus one from TLS session cacheing. > > Skipping waiting for the greeting looks a little scary to me. That in itself would argue that this went Experimental, whereas other parts of it are on much firmer footing. I also think there's a problem in ommitting the post-TLS EHLO - simply hoping the server's capabilities haven't changed seems a little vague. I really would prefer to look again at some form of capability change indicator, and using that to elide EHLOs. I don't think that's mutually exclusive with QUICKSTART, unless QUICKSTART starts using more than the TCP window for capability data. > I'm wondering if it might be safer for the client to indicate > quickstart > using a QHLO command, which may be pipelined. Any opinions? > > Six octets of signalling information which the submit server uses for what? OTOH, you've suggested using this in MTA-MTA, where this is needed - spotting protocol misuse is used to block spammers sometimes. Personally, I don't think there's a major round-trip issue between MTAs. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 15:13:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCMqD-0002jn-GX; Thu, 23 Feb 2006 15:13:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCMqC-0002jE-9N for lemonade@ietf.org; Thu, 23 Feb 2006 15:13:32 -0500 Received: from ppsw-1.csi.cam.ac.uk ([131.111.8.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCMqA-0002bA-T8 for lemonade@ietf.org; Thu, 23 Feb 2006 15:13:32 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39073) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:fanf2) id 1FCMpr-0002oP-3g (Exim 4.54) (return-path ); Thu, 23 Feb 2006 20:13:11 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FCMpr-0006Ja-38 (Exim 4.53) (return-path ); Thu, 23 Feb 2006 20:13:11 +0000 Date: Thu, 23 Feb 2006 20:13:11 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Cridland Subject: Re: [lemonade] SMTP QUICKSTART In-Reply-To: <25269.1140724067.114807@invsysm1> Message-ID: References: <25269.1140724067.114807@invsysm1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 23 Feb 2006, Dave Cridland wrote: > > > I'm wondering if it might be safer for the client to indicate quickstart > > using a QHLO command, which may be pipelined. Any opinions? > > Six octets of signalling information which the submit server uses for what? > > I really would prefer to look again at some form of capability change > indicator, and using that to elide EHLOs. I don't think that's mutually I was partly wondering what would happen to mobile clients connecting to a network with a hostile firewall which doesn't understand QUICKSTART. The client needs a way to recover gracefully, and I thought an extra command not supported by non-QUICKSTART servers might help. OK, how about this. The QUICKSTART ehlo keyword gets a parameter which the client echoes back in the QHLO command. If the server detects a mismatch, it rejects everything until the client says EHLO (which would probably happen anyway according to usual service extension rules). e.g. C: QHLO 35681d17 hunny.100acre.example C: STARTTLS S: 220-smtp.100acre.example ESMTP S: 220-QUICKSTART 35681d17 S: 220-PIPELINING S: 220 STARTTLS S: 250 quickstart ok S: 220 go ahead ... C: QHLO 26f1aa9c hunny.100acre.example C: AUTH PLAIN AHBvb2gAYmVhcg== S: 220-smtp.100acre.example ESMTP S: 220-QUICKSTART 26f1aa9c S: 220-PIPELINING S: 220 AUTH PLAIN S: 235 auth ok or C: QHLO 3c9e4e9b hunny.100acre.example C: STARTTLS S: 220-smtp.100acre.example ESMTP S: 220-QUICKSTART 35681d17 S: 220-PIPELINING S: 220 STARTTLS S: 550 bad quickstart token S: 503 bad sequence of commands C: EHLO aaah.i.am.covered.in.bees S: 250-smtp.100acre.example ESMTP S: 250-QUICKSTART 35681d17 S: 250-PIPELINING S: 250 STARTTLS C: STARTTLS S: 220 go ahead ... Tony. -- f.a.n.finch http://dotat.at/ NORTH UTSIRE: VARIABLE 4, BUT NORTHEAST 5 TO 7 AT FIRST IN NORTHWEST. SHOWERS. GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 15:16:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCMtI-0004oS-9Q; Thu, 23 Feb 2006 15:16:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCMtG-0004oH-K0 for lemonade@ietf.org; Thu, 23 Feb 2006 15:16:42 -0500 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCMtF-0002lS-As for lemonade@ietf.org; Thu, 23 Feb 2006 15:16:42 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:39793) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1FCMt8-00071s-0y (Exim 4.54) (return-path ); Thu, 23 Feb 2006 20:16:34 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FCMt8-0006sr-46 (Exim 4.53) (return-path ); Thu, 23 Feb 2006 20:16:34 +0000 Date: Thu, 23 Feb 2006 20:16:34 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Tony Finch Subject: Re: [lemonade] SMTP QUICKSTART In-Reply-To: Message-ID: References: <25269.1140724067.114807@invsysm1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 23 Feb 2006, Tony Finch wrote: > C: QHLO 26f1aa9c hunny.100acre.example > C: AUTH PLAIN AHBvb2gAYmVhcg== Er the server's response should have read S: 250 quickstart ok S: 235 auth ok Tony. -- f.a.n.finch http://dotat.at/ SOUTH UTSIRE: VARIABLE 3 OR 4, BECOMING SOUTHEAST 5 OR 6 FOR A TIME. SHOWERS. GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 16:51:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOMu-0005IH-Lm; Thu, 23 Feb 2006 16:51:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOMt-0005I9-Dx for lemonade@ietf.org; Thu, 23 Feb 2006 16:51:23 -0500 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCOMt-0006kE-3y for lemonade@ietf.org; Thu, 23 Feb 2006 16:51:23 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k1NLpDb0024644; Thu, 23 Feb 2006 15:51:13 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 23 Feb 2006 15:51:13 -0600 Message-ID: <54E40201497DF142B06B27255953F7971BFACF39@il0015exch007u.ih.lucent.com> From: "Vaudreuil, Greg M (Greg)" To: Dave Cridland , Tony Finch Subject: RE: [lemonade] RE: PIPELINING, AUTH, and CHUNKING Date: Thu, 23 Feb 2006 15:51:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org So... The big question for me is the following: Is pipelining between transactions something that should be specified in CHUNKING or a revision to PIPELINING? My view is that pipelining across transactions is completely orthoganal to CHUNKING, and the language in this draft should neither permit nor deny such behavior, defering to the base PIPELINING document. If so, the only clarification here is that it is explicitly acceptable to pipeline the BDAT commands following the envelope without a synchronization. Reasonable? Greg V. -----Original Message----- From: Dave Cridland [mailto:dave@cridland.net] Sent: Thursday, February 23, 2006 2:20 PM To: Tony Finch Cc: Enhancements to Internet email to support diverse service enivronments Subject: Re: [lemonade] RE: PIPELINING, AUTH, and CHUNKING On Thu Feb 23 19:07:04 2006, Tony Finch wrote: > On Thu, 23 Feb 2006, Dave Cridland wrote: > > > > > The sender-SMTP MAY use the NOOP command to introduce a > > > synchronization point. > > > > Why? > > RFC 2920 says NOOP is included in the group of commands that can > only > appear as the last command in a group so that it can be used as a > synchronization point. Perhaps I'm suggesting defences against bugs > that > don't exist... I think so. The only way that would help is if the client couldn't track completion of the individual commands. In which case it's really not going to work anyway. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 16:55:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOQz-0007ti-1z; Thu, 23 Feb 2006 16:55:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCOQx-0007tZ-Of for lemonade@ietf.org; Thu, 23 Feb 2006 16:55:35 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCOQt-0006ti-Tp for lemonade@ietf.org; Thu, 23 Feb 2006 16:55:35 -0500 Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Thu, 23 Feb 2006 21:55:06 +0000 Message-ID: <43FE2F34.2080601@isode.com> Date: Thu, 23 Feb 2006 21:55:00 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vaudreuil, Greg M (Greg)" Subject: Re: [lemonade] RE: PIPELINING, AUTH, and CHUNKING References: <54E40201497DF142B06B27255953F7971BFACF39@il0015exch007u.ih.lucent.com> In-Reply-To: <54E40201497DF142B06B27255953F7971BFACF39@il0015exch007u.ih.lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Vaudreuil, Greg M (Greg) wrote: >So... > >The big question for me is the following: > >Is pipelining between transactions something that should be specified in CHUNKING or a revision to PIPELINING? My view is that pipelining across transactions is completely orthoganal to CHUNKING, and the language in this draft should neither permit nor deny such behavior, defering to the base PIPELINING document. > > Yes. >If so, the only clarification here is that it is explicitly acceptable to pipeline the BDAT commands following the envelope without a synchronization. > > Yes. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 18:57:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQKj-0003KG-UA; Thu, 23 Feb 2006 18:57:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQKi-0003IV-Ej for lemonade@ietf.org; Thu, 23 Feb 2006 18:57:16 -0500 Received: from brmea-mail-2.sun.com ([192.18.98.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCQKY-0003KR-E1 for lemonade@ietf.org; Thu, 23 Feb 2006 18:57:16 -0500 Received: from fe-amer-09.sun.com ([192.18.108.183]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k1NNv58u008578 for ; Thu, 23 Feb 2006 16:57:06 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IV500J01ZTBHE00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for lemonade@ietf.org; Thu, 23 Feb 2006 16:57:05 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IV500788ZV3DT00@mail-amer.sun.com>; Thu, 23 Feb 2006 16:57:05 -0700 (MST) Date: Thu, 23 Feb 2006 15:58:24 -0800 From: Chris Newman Subject: Re: [lemonade] SMTP QUICKSTART In-reply-to: <25269.1140724067.114807@invsysm1> To: Dave Cridland , Tony Finch Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <25269.1140724067.114807@invsysm1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Dave Cridland wrote on 2/23/06 19:47 +0000: > On Thu Feb 23 19:02:06 2006, Tony Finch wrote: >> I have updated the QUICKSTART draft. The main difference is a >> description >> of how to save the server greeting round-trip and how to skip EHLO >> after >> STARTTLS. I've added packet traces to show the three RTT savings >> from >> QUICKSTART plus one from TLS session cacheing. >> >> > Skipping waiting for the greeting looks a little scary to me. That in itself > would argue that this went Experimental, whereas other parts of it are on > much firmer footing. Skipping waiting for the greeting is a complete non-starter in SMTP (25) -- it's a common MTA feature to flush the input buffer after sending the greeting to force spammers to wait for that round trip. It's much more cost-effective to do that to _all_ transfers (legitimate or not) than to allow spammers to blast full speed. I suppose it might be feasible in Submit (587), but it needs a separate capability from PIPELINING or QUICKSTART. On the issue of TLS integration, I was thinking of something along these lines: S: ... S: 220-QUICKSTART TLS S: ... C: QUICKTLS [server-domain] S: This "TLS" advertisement is stronger than the "STARTTLS" advertisement. Instead of simply stating the server understands the command, this states the server is ready to negotiate TLS. So the client can issue the command and immediately begin the TLS negotiation without waiting for the server response to the QUICKTLS command. The ability for the client to tell the server the host name it is using to talk to the server permits virtual domains without burning IP addresses, another useful feature that STARTTLS is missing. And why worry about all that complexity of caching server capabilities when the server can be explicit about it in the banner to save the round-trips in all cases? - Chris _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 19:09:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQWx-0004Ny-Co; Thu, 23 Feb 2006 19:09:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQWw-0004NS-G1 for lemonade@ietf.org; Thu, 23 Feb 2006 19:09:54 -0500 Received: from mxout3.cac.washington.edu ([140.142.32.166]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCQWv-00042l-3v for lemonade@ietf.org; Thu, 23 Feb 2006 19:09:54 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout3.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k1O09jKK029277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 23 Feb 2006 16:09:45 -0800 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k1O09iXx003082 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 23 Feb 2006 16:09:45 -0800 Date: Thu, 23 Feb 2006 16:09:45 -0800 (Pacific Standard Time) From: Mark Crispin To: Chris Newman Subject: Re: [lemonade] SMTP QUICKSTART In-Reply-To: Message-ID: References: <25269.1140724067.114807@invsysm1> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 23 Feb 2006, Chris Newman wrote: > Skipping waiting for the greeting is a complete non-starter in SMTP (25) -- > it's a common MTA feature to flush the input buffer after sending the > greeting to force spammers to wait for that round trip. It's much more > cost-effective to do that to _all_ transfers (legitimate or not) than to > allow spammers to blast full speed. I agree. I put that in the TOPS-20 SMTP server 23 years ago. Of course, I think that you meant to say "before sending the CRLF that terminates the greeting" instead of "after sending the greeting". > And why worry about all that complexity of caching server capabilities when > the server can be explicit about it in the banner to save the round-trips in > all cases? I agree. I was terribly disappointed when the NNTP people rejected this. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 19:12:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQZI-0006ES-Ed; Thu, 23 Feb 2006 19:12:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCQZG-0006Dq-Uz for lemonade@ietf.org; Thu, 23 Feb 2006 19:12:18 -0500 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCQZG-000482-FK; Thu, 23 Feb 2006 19:12:18 -0500 Received: from fe-amer-04.sun.com ([192.18.108.178]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k1O0CGuf006947; Thu, 23 Feb 2006 17:12:18 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0IV600G010HCYJ00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM); Thu, 23 Feb 2006 17:12:16 -0700 (MST) Received: from [10.1.110.5] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0IV60041W0KEQL20@mail-amer.sun.com>; Thu, 23 Feb 2006 17:12:16 -0700 (MST) Date: Thu, 23 Feb 2006 16:13:35 -0800 From: Chris Newman Subject: Re: [lemonade] Re: PIPELINING, AUTH, and CHUNKING In-reply-to: To: Tony Finch Message-id: MIME-version: 1.0 X-Mailer: Mulberry/3.1.6 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: lemonade@ietf.org, ietf-smtp@ietf.org, Gregory Vaudreuil X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Tony Finch wrote on 2/23/06 12:56 +0000: > On Wed, 22 Feb 2006, Chris Newman wrote: >> Tony Finch wrote on 2/22/06 0:54 +0000: >> >> > Current securely authenticated message submission requires at least >> > eleven round trips (including TCP startup and shutdown). BURL can >> > reduce this to nine. >> >> I'm glad someone noticed that little feature I slipped into BURL :-) > > Yes it is nice, but on reflection I think the way it is specified isn't > ideal. In particular, to quote that bit from RFC 2920 again: > > Additional commands added by other SMTP extensions may only appear as > the last command in a group unless otherwise specified by the > extensions that define the commands. > > So I think the BURL spec is wrong to talk about pipelining AUTH, and if > you want to allow pipelined AUTH it should be specified as an update to > RFC 2554. > > Furthermore, it isn't safe in all situations for a client to pipeline a > single round-trip AUTH. For example, it's common to have dual-purpose MSA > and MX servers which operate in MSA mode after AUTH and MX mode otherwise. > If the client pipelines an AUTH and an intended submission, but the auth > fails, bad things will happen - recipients will be rejected that would > have been OK, an incomplete message will suffer an anti-spam penalty > instead of being fixed up, etc. Well, if a server advertises all of BURL, PIPELINING, and AUTH PLAIN/EXTERNAL, then it must permit AUTH PLAIN/EXTERNAL to be pipelined in order to comply with the BURL spec. A bit convoluted, but that's what the specs say. Yes, this would probably be better done in an RFC 2554 update, but I don't have time to write one. > Pipelined AUTH is OK if the server is going to reject any un-authenticated > submissions, in which case the server should explicitly say so, perhaps by > using an EHLO keyword line such as 250 PIPEAUTH PLAIN EXTERNAL. BURL is a submit-only extension with a normative reference to draft-gellens-submit-bis-02 which requires authentication. So it's safe for clients to assume authentication is required if both BURL and AUTH are advertised. - Chris _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Thu Feb 23 19:42:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCR2u-00067A-FN; Thu, 23 Feb 2006 19:42:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCR2t-000645-6Q for lemonade@ietf.org; Thu, 23 Feb 2006 19:42:55 -0500 Received: from [209.55.107.55] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCR2r-00053p-Rh for lemonade@ietf.org; Thu, 23 Feb 2006 19:42:55 -0500 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LZBC5R9L9C007Y5L@mauve.mrochek.com> for lemonade@ietf.org; Thu, 23 Feb 2006 16:42:51 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=nowsp; d=mrochek.com; s=mauve; t=1140741771; h=Date: From:Subject:MIME-version:Content-type; b=tIdTsNlW3SfQYCwbju2UMX6Zo O7mIkO0aCRnPK9Oq9NvaoYzMzi8XmLihnXGxXQvNyVDfXrsgDQJM5AAKEgKtw== Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01LZA99D42AO00009C@mauve.mrochek.com>; Thu, 23 Feb 2006 16:42:49 -0800 (PST) To: Chris Newman Message-id: <01LZBC5PW8YK00009C@mauve.mrochek.com> Date: Thu, 23 Feb 2006 16:36:56 -0800 (PST) From: Ned Freed Subject: Re: [lemonade] SMTP QUICKSTART In-reply-to: "Your message dated Thu, 23 Feb 2006 15:58:24 -0800" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <25269.1140724067.114807@invsysm1> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > > Skipping waiting for the greeting looks a little scary to me. That in itself > > would argue that this went Experimental, whereas other parts of it are on > > much firmer footing. > Skipping waiting for the greeting is a complete non-starter in SMTP (25) -- > it's a common MTA feature to flush the input buffer after sending the greeting > to force spammers to wait for that round trip. It's much more cost-effective > to do that to _all_ transfers (legitimate or not) than to allow spammers to > blast full speed. I suppose it might be feasible in Submit (587), but it needs > a separate capability from PIPELINING or QUICKSTART. We haven't released our code with this feature yet so we don't have a lot of experience with it, but my guess is ISPs will want to use this trick to block spam from infected PCs. And I doubt the authentication requirement for submit will make much difference here: If these spambots don't already know how to dig the necessary credentials out of the PC's configuration they soon will. in other words, I'm dubious this makes sense even on the submit port. > On the issue of TLS integration, I was thinking of something along these lines: > S: ... > S: 220-QUICKSTART TLS > S: ... > C: QUICKTLS [server-domain] > > S: > This "TLS" advertisement is stronger than the "STARTTLS" advertisement. > Instead of simply stating the server understands the command, this states the > server is ready to negotiate TLS. So the client can issue the command and > immediately begin the TLS negotiation without waiting for the server response > to the QUICKTLS command. The ability for the client to tell the server the > host name it is using to talk to the server permits virtual domains without > burning IP addresses, another useful feature that STARTTLS is missing. > And why worry about all that complexity of caching server capabilities when the > server can be explicit about it in the banner to save the round-trips in all > cases? Full agreement here. Caching server capabilities is something we should avoid it at all possible. Ned _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 24 04:51:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCZcE-0008FP-D6; Fri, 24 Feb 2006 04:51:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCZcD-0008FK-Qz for lemonade@ietf.org; Fri, 24 Feb 2006 04:51:57 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCZc9-0004oB-Hx for lemonade@ietf.org; Fri, 24 Feb 2006 04:51:57 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:51722) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1FCZbQ-0001PJ-O1 (Exim 4.54) (return-path ); Fri, 24 Feb 2006 09:51:08 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FCZbQ-0005Jz-DH (Exim 4.53) (return-path ); Fri, 24 Feb 2006 09:51:08 +0000 Date: Fri, 24 Feb 2006 09:51:08 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Chris Newman Subject: Re: [lemonade] Re: PIPELINING, AUTH, and CHUNKING In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 23 Feb 2006, Chris Newman wrote: > > Well, if a server advertises all of BURL, PIPELINING, and AUTH PLAIN/EXTERNAL, > then it must permit AUTH PLAIN/EXTERNAL to be pipelined in order to comply > with the BURL spec. A bit convoluted, but that's what the specs say. Yes, > this would probably be better done in an RFC 2554 update, but I don't have > time to write one. In that case I suggest that the BURL spec should have an explicit Updates: RFC2554 annotation, since it changes the behavior of AUTH. Tony. -- f.a.n.finch http://dotat.at/ FAIR ISLE: NORTHEAST 4 OR 5, OCCASIONALLY 6 LATER. RAIN LATER. MAINLY GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 24 04:57:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCZh9-0003FC-UY; Fri, 24 Feb 2006 04:57:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCZh9-0003DV-1B for lemonade@ietf.org; Fri, 24 Feb 2006 04:57:03 -0500 Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCZh7-0004zk-Nu for lemonade@ietf.org; Fri, 24 Feb 2006 04:57:03 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:53446) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1FCZgy-0001Oy-05 (Exim 4.54) (return-path ); Fri, 24 Feb 2006 09:56:52 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FCZgx-0006Dg-VT (Exim 4.53) (return-path ); Fri, 24 Feb 2006 09:56:51 +0000 Date: Fri, 24 Feb 2006 09:56:51 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: "Vaudreuil, Greg M (Greg)" Subject: RE: [lemonade] RE: PIPELINING, AUTH, and CHUNKING In-Reply-To: <54E40201497DF142B06B27255953F7971BFACF39@il0015exch007u.ih.lucent.com> Message-ID: References: <54E40201497DF142B06B27255953F7971BFACF39@il0015exch007u.ih.lucent.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 23 Feb 2006, Vaudreuil, Greg M (Greg) wrote: > > The big question for me is the following: > > Is pipelining between transactions something that should be specified in > CHUNKING or a revision to PIPELINING? My view is that pipelining across > transactions is completely orthoganal to CHUNKING, and the language in > this draft should neither permit nor deny such behavior, defering to the > base PIPELINING document. The PIPELINING spec already allows the next message envelope to be pipelined after the previous message data, i.e. pipelining from one transaction to the next. The only required synchronization point is in the middle of a transaction, at DATA. > If so, the only clarification here is that it is explicitly acceptable > to pipeline the BDAT commands following the envelope without a > synchronization. I think that would have the effect I am after, since it eliminates the remaining synchronization point. Tony. -- f.a.n.finch http://dotat.at/ LOUGH FOYLE TO CARLINGFORD LOUGH: EAST OR NORTHEAST 5 OR 6, BUT 7 SOUTH OF BALLYQUINTIN POINT AT FIRST. RAIN THEN FAIR. GOOD, OCCASIONALLY MODERATE. MODERATE OR ROUGH. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 24 05:25:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCa8Y-0004gk-Kd; Fri, 24 Feb 2006 05:25:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCa8X-0004fS-46 for lemonade@ietf.org; Fri, 24 Feb 2006 05:25:21 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCa8V-0005kR-NN for lemonade@ietf.org; Fri, 24 Feb 2006 05:25:21 -0500 Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Fri, 24 Feb 2006 10:25:10 +0000 Message-ID: <43FEDF05.7070408@isode.com> Date: Fri, 24 Feb 2006 10:25:09 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tony Finch Subject: Re: [lemonade] Re: PIPELINING, AUTH, and CHUNKING References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: lemonade@ietf.org, Chris Newman X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Tony Finch wrote: >On Thu, 23 Feb 2006, Chris Newman wrote: > > >>Well, if a server advertises all of BURL, PIPELINING, and AUTH PLAIN/EXTERNAL, >>then it must permit AUTH PLAIN/EXTERNAL to be pipelined in order to comply >>with the BURL spec. A bit convoluted, but that's what the specs say. Yes, >>this would probably be better done in an RFC 2554 update, but I don't have >>time to write one. >> >> >In that case I suggest that the BURL spec should have an explicit >Updates: RFC2554 annotation, since it changes the behavior of AUTH. > > Indeed. Also note that Rob Siemborski did a revision of RFC 2554. Even though his draft has expired, I thought it was in a good shape and probably it is time to Last Call it now. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 24 05:43:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCaPs-00087k-Pf; Fri, 24 Feb 2006 05:43:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCaPr-00087Y-Sy for lemonade@ietf.org; Fri, 24 Feb 2006 05:43:15 -0500 Received: from ppsw-7.csi.cam.ac.uk ([131.111.8.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCaPq-0006GX-GF for lemonade@ietf.org; Fri, 24 Feb 2006 05:43:15 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:40272) by ppsw-7.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1FCaPl-000751-Nf (Exim 4.54) (return-path ); Fri, 24 Feb 2006 10:43:09 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FCaPl-0004b9-9R (Exim 4.53) (return-path ); Fri, 24 Feb 2006 10:43:09 +0000 Date: Fri, 24 Feb 2006 10:43:09 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Chris Newman Subject: Re: [lemonade] SMTP QUICKSTART In-Reply-To: Message-ID: References: <25269.1140724067.114807@invsysm1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 23 Feb 2006, Chris Newman wrote: > > S: ... > S: 220-QUICKSTART TLS > S: ... > C: QUICKTLS [server-domain] > > S: > > So the client can issue the command and immediately begin the TLS > negotiation without waiting for the server response to the QUICKTLS > command. Nice! I suppose this is a fair replacement for anticipating the server's greeting. Instead of C-->S: TCP SYN C<--S: TCP SYN/ACK C-->S: TCP ACK + SMTP QHLO, STARTTLS C<--S: SMTP quickstart greeting, 250 OK, 220 OK C-->S: TLS hello C<--S: TLS hello, certificate, etc. you have C-->S: TCP SYN C<--S: TCP SYN/ACK C-->S: TCP ACK C<--S: SMTP quickstart greeting C-->S: SMTP QUICKTLS + TLS hello C<--S: TLS hello, certificate, etc. (Hmm, I don't think you combine them because of the need for error handling, and it might be tricky for an implementation to handle pipelining of SMTP and TLS in both directions...) > The ability for the client to tell the server the host name it is using > to talk to the server permits virtual domains without burning IP > addresses, another useful feature that STARTTLS is missing. Excellent idea. > And why worry about all that complexity of caching server capabilities when > the server can be explicit about it in the banner to save the round-trips in > all cases? The server banner after TLS loses you the benefit of TLS session cacheing. Here's an uncached exchange: C-->S: SMTP QUICKTLS + TLS hello C<--S: TLS hello, certificate, etc. C-->S: TLS key exch, change cipher, finish handshake C<--S: TLS change cipher, finish handshake, SMTP greeting C-->S: SMTP AUTH + SASL PLAIN And cached: C-->S: SMTP QUICKTLS + TLS hello C<--S: TLS hello, change cipher, finish handshake C-->S: TLS change cipher, finish handshake C<--S: SMTP greeting C-->S: SMTP AUTH + SASL PLAIN This is why I wanted the client to be able to talk first after the TLS handshake. I can't see how to allow this without a capability cache. Tony. -- f.a.n.finch http://dotat.at/ FAIR ISLE: NORTHEAST 4 OR 5, OCCASIONALLY 6 LATER. RAIN LATER. MAINLY GOOD. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 24 10:02:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCeSe-000396-Uc; Fri, 24 Feb 2006 10:02:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHPE-0001nh-J7 for lemonade@ietf.org; Thu, 23 Feb 2006 09:25:20 -0500 Received: from [156.154.16.129] (helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCGqH-00023w-Hl for lemonade@ietf.org; Thu, 23 Feb 2006 08:49:13 -0500 Received: from ppsw-9.csi.cam.ac.uk ([131.111.8.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FCGbn-0000uH-Ah for lemonade@ietf.org; Thu, 23 Feb 2006 08:34:17 -0500 X-Cam-SpamDetails: Not scanned X-Cam-AntiVirus: No virus found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:43592) by ppsw-9.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1FCGbW-0006Rn-W3 (Exim 4.54) (return-path ); Thu, 23 Feb 2006 13:33:58 +0000 Received: from fanf2 (helo=localhost) by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1FCGbW-00056q-SW (Exim 4.53) (return-path ); Thu, 23 Feb 2006 13:33:58 +0000 Date: Thu, 23 Feb 2006 13:33:58 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Arnt Gulbrandsen Subject: Re: [lemonade] Re: PIPELINING, AUTH, and CHUNKING In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: -1.1 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Fri, 24 Feb 2006 10:02:23 -0500 Cc: lemonade@ietf.org, Chris Newman , Gregory Vaudreuil X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Thu, 23 Feb 2006, Arnt Gulbrandsen wrote: > Tony Finch writes: > > I think it would be cool to allow this kind of high-bandwidth asynchronous > > message transmission. > > Cool, yes, very, but useful? The only use case I can think of is a spammer > using a mobile-phone botnet to send lots of mail. It's probably more useful for MTA-MTA transmission than message submission. Think of dealing with the queue after an outage, for example. The MTAs I know well aren't capable of this level of performance because of the faff they incur to switch between messages on the same connection, but implementation limitations shouldn't restrict the protocol design. Perhaps Ecelerity could make good use of the feature :-) Tony. -- f.a.n.finch http://dotat.at/ MULL OF KINTYRE TO ARDNAMURCHAN POINT: NORTHEAST 4 OR 5, OCCASIONALLY 3 AT FIRST. RAIN FOR A TIME. MODERATE OR GOOD. SLIGHT OR MODERATE. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 24 10:02:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCeSe-000391-QD; Fri, 24 Feb 2006 10:02:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCGLC-00011q-B6 for lemonade@ietf.org; Thu, 23 Feb 2006 08:17:06 -0500 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCGLA-0000cy-UE; Thu, 23 Feb 2006 08:17:06 -0500 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id 355054AC1F; Thu, 23 Feb 2006 14:17:02 +0100 (CET) Message-Id: Date: Thu, 23 Feb 2006 14:26:52 +0100 From: Arnt Gulbrandsen To: lemonade@ietf.org Subject: Re: [lemonade] Re: PIPELINING, AUTH, and CHUNKING References: In-Reply-To: Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Fri, 24 Feb 2006 10:02:23 -0500 Cc: Gregory, Chris Newman , ietf-smtp@ietf.org, Vaudreuil X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Tony Finch writes: > I think it would be cool to allow this kind of high-bandwidth > asynchronous message transmission. Cool, yes, very, but useful? The only use case I can think of is a spammer using a mobile-phone botnet to send lots of mail. Arnt _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 24 11:14:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCfaN-0000qp-8s; Fri, 24 Feb 2006 11:14:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCfaL-0000qh-LB for lemonade@ietf.org; Fri, 24 Feb 2006 11:14:25 -0500 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCfaJ-0008UJ-UG for lemonade@ietf.org; Fri, 24 Feb 2006 11:14:25 -0500 Received: from nappa.corp.google.com (nappa.corp.google.com [172.24.0.4]) by smtp-out.google.com with ESMTP id k1OGEHjr019633 for ; Fri, 24 Feb 2006 08:14:17 -0800 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=JhDfsLQu2ZcFSKyX0ya8XsEYEUMDH7gx9lDivN2M9IZ63Yf7D+QFJVVwn1UGytx4a snx8lq0sjCNaw4rIrY8OQ== Received: from smtp-out2.google.com (fpc20.prod.google.com [10.253.3.20]) by nappa.corp.google.com with ESMTP id k1OG96Mh016100 for ; Fri, 24 Feb 2006 08:14:11 -0800 Received: by smtp-out2.google.com with SMTP id 20so4075fpc for ; Fri, 24 Feb 2006 08:14:11 -0800 (PST) Received: by 10.253.5.4 with SMTP id 4mr4954fpe; Fri, 24 Feb 2006 08:14:11 -0800 (PST) Received: by 10.253.3.15 with HTTP; Fri, 24 Feb 2006 08:14:11 -0800 (PST) Message-ID: <5b93232d0602240814x7af278cdl13ffe448b230e0a6@mail.google.com> Date: Fri, 24 Feb 2006 08:14:11 -0800 From: "Rob Siemborski" To: "Alexey Melnikov" Subject: Re: [lemonade] Re: PIPELINING, AUTH, and CHUNKING In-Reply-To: <43FEDF05.7070408@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43FEDF05.7070408@isode.com> X-Spam-Score: -4.3 (----) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: lemonade@ietf.org, Chris Newman X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I was holding that for when 2222bis finally got published. It looks like its making progress again so I'll have to go back through and double check that 2554bis is still ok, then publish it. -Rob On 2/24/06, Alexey Melnikov wrote: > Tony Finch wrote: > > >On Thu, 23 Feb 2006, Chris Newman wrote: > > > > > >>Well, if a server advertises all of BURL, PIPELINING, and AUTH PLAIN/EX= TERNAL, > >>then it must permit AUTH PLAIN/EXTERNAL to be pipelined in order to com= ply > >>with the BURL spec. A bit convoluted, but that's what the specs say. = Yes, > >>this would probably be better done in an RFC 2554 update, but I don't h= ave > >>time to write one. > >> > >> > >In that case I suggest that the BURL spec should have an explicit > >Updates: RFC2554 annotation, since it changes the behavior of AUTH. > > > > > Indeed. > > Also note that Rob Siemborski did a revision of RFC 2554. Even though > his draft has expired, I thought it was in a good shape and probably it > is time to Last Call it now. > > > _______________________________________________ > lemonade mailing list > lemonade@ietf.org > https://www1.ietf.org/mailman/listinfo/lemonade > -- Rob Siemborski | PGP:0x5CE32FCC | robsiemb@google.com Software Engineer | | 650-623-6925 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 24 14:28:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCicJ-00073z-Co; Fri, 24 Feb 2006 14:28:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCicI-00073r-QT for lemonade@ietf.org; Fri, 24 Feb 2006 14:28:38 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCicG-0006PF-Gi for lemonade@ietf.org; Fri, 24 Feb 2006 14:28:38 -0500 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k1OJORW16661 for ; Fri, 24 Feb 2006 14:24:27 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Feb 2006 14:28:30 -0500 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D0894A215@zcarhxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft deadline Thread-Index: AcY5eH5wp8bCxa/YSxy+KuNgvv9GbQ== From: "Glenn Parsons" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Subject: [lemonade] Draft deadline X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1226828655==" Errors-To: lemonade-bounces@ietf.org This is a multi-part message in MIME format. --===============1226828655== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63978.7FE3391D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63978.7FE3391D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, A gentle reminder that the deadlines for draft submission for the upcoming meeting in Dallas is approaching: February 27, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (14:00 GMT) March 6, Monday - Internet Draft final submission cut-off by 09:00 ET (14:00 GMT) As we discussed in Beijing, I would hope to see revised drafts on: Profile-bis=20 Notifications=20 Message event Content transformation (CONVERT) Filters (IMAP SIEVE & manage SIEVE) Quick reconnect 2192bis And new 00 drafts on: VFOLDER Content transformation (the streaming one) Compression Firewall deployment considerations (BCP) Firewall binding options (Informational) Cheers, Glenn. ------_=_NextPart_001_01C63978.7FE3391D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft deadline

Folks,

A gentle reminder that the deadlines = for draft submission for the upcoming meeting in Dallas is = approaching:

    February 27, Monday - Internet Draft = Cut-off for initial document (-00) submission by 09:00 ET (14:00 = GMT)
    March 6, Monday - Internet Draft final submission cut-off by 09:00 ET = (14:00 GMT)

As we discussed in Beijing, I would = hope to see revised drafts on:

    Profile-bis
    Notifications
    Message event
    Content transformation = (CONVERT)
    Filters (IMAP SIEVE & manage = SIEVE)
    Quick reconnect
    2192bis

And new 00 drafts on:

    VFOLDER
    Content transformation (the streaming = one)
    Compression
    Firewall deployment considerations = (BCP)
    Firewall binding options = (Informational)

Cheers,
Glenn.

------_=_NextPart_001_01C63978.7FE3391D-- --===============1226828655== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade --===============1226828655==-- From lemonade-bounces@ietf.org Fri Feb 24 19:41:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCnVR-0002Ca-OA; Fri, 24 Feb 2006 19:41:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCnVR-0002CE-Al for lemonade@ietf.org; Fri, 24 Feb 2006 19:41:53 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCnVQ-0002vY-0h for lemonade@ietf.org; Fri, 24 Feb 2006 19:41:53 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k1P0fnuL021742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Feb 2006 16:41:49 -0800 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k1P0fdw3005957; Fri, 24 Feb 2006 16:41:47 -0800 (PST) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 24 Feb 2006 16:41:36 -0800 To: "Burger, Eric" , Glenn Parsons From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: lemonade@ietf.org Subject: [lemonade] New Draft on Qpopper MIME Mangling and Macro Extensions X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I sent in a draft on the Qpopper MIME mangling and macro extensions, thinking it might be of interest in our discussions on similar topics. If you'd like to grab a copy before it appears in the I-D directories, it is available here: -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Opportunity always knocks at the least opportune moment. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 24 19:41:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCnVP-0002BS-JN; Fri, 24 Feb 2006 19:41:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCnVO-00029v-Cq for lemonade@ietf.org; Fri, 24 Feb 2006 19:41:50 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCnVN-0002vV-2K for lemonade@ietf.org; Fri, 24 Feb 2006 19:41:50 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k1P0fiuL021737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Feb 2006 16:41:45 -0800 Received: from [192.168.1.13] (loud.qualcomm.com [129.46.172.15]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k1P0fdw1005957; Fri, 24 Feb 2006 16:41:42 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <330A23D8336C0346B5C1A5BB19666647020F8D24@ATLANTIS.Brooktrout.com> References: <330A23D8336C0346B5C1A5BB19666647020F8D24@ATLANTIS.Brooktrout.com> X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 24 Feb 2006 16:41:35 -0800 To: "Burger, Eric" , Glenn Parsons From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: lemonade@ietf.org Subject: [lemonade] New Draft on Deployment Considerations X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org The draft has been sent in, but if you'd like to grab a copy before it appears in the I-D directories, it is available here: . -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- mokita (moe-KEE-tah; New Guinean; noun): truth everybody knows but nobody speaks. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 24 21:29:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCpBE-0008H2-Pv; Fri, 24 Feb 2006 21:29:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCpBE-0008Gx-13 for lemonade@ietf.org; Fri, 24 Feb 2006 21:29:08 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCpBC-0006PD-ND for lemonade@ietf.org; Fri, 24 Feb 2006 21:29:08 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k1P2T3N7025392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Feb 2006 18:29:04 -0800 Received: from [192.168.1.13] (vpn-10-50-16-37.qualcomm.com [10.50.16.37]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k1P2T0fx018826; Fri, 24 Feb 2006 18:29:03 -0800 (PST) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 24 Feb 2006 18:28:53 -0800 To: "Burger, Eric" , Glenn Parsons From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: lemonade@ietf.org Subject: [lemonade] New Draft on Qpopper MIME Mangling and Macro Extensions X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > I sent in a draft on the Qpopper MIME mangling and macro > extensions, thinking it might be of interest in our discussions on > similar topics. > > If you'd like to grab a copy before it appears in the I-D > directories, it is available here: > Oops. Correct URL is . -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- Q: How many surrealists does it take to screw in a light bulb? A: A Fish. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Fri Feb 24 21:29:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCpBD-0008Gl-Lb; Fri, 24 Feb 2006 21:29:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCpBD-0008Gg-5G for lemonade@ietf.org; Fri, 24 Feb 2006 21:29:07 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCpBC-0006PC-RJ for lemonade@ietf.org; Fri, 24 Feb 2006 21:29:07 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k1P2T2N7025391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 Feb 2006 18:29:03 -0800 Received: from [192.168.1.13] (vpn-10-50-16-37.qualcomm.com [10.50.16.37]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k1P2T0fv018826; Fri, 24 Feb 2006 18:29:02 -0800 (PST) Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X v7.0a X-message-flag: Using Outlook? Upgrade to Eudora: Date: Fri, 24 Feb 2006 18:28:17 -0800 To: "Burger, Eric" , Glenn Parsons From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: lemonade@ietf.org Subject: [lemonade] Re: New Draft on Deployment Considerations X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org > The draft has been sent in, but if you'd like to grab a copy before > it appears in the I-D directories, it is available here: > . Oops, I got the draft URLs backwards. This one is at -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly-selected tag: --------------- There is a life-size picture of a dogcow conveniently located in the Finder. Look under "Page Setup..." Now look under "Options." Like any talented dog, it can do flips. Like any talented cow, it can do precision bitmap alignment. --Apple Tech Note #31 _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Mon Feb 27 09:50:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjhJ-00008i-Fr; Mon, 27 Feb 2006 09:50:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjhH-00007J-Ep for lemonade@ietf.org; Mon, 27 Feb 2006 09:49:59 -0500 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDjhH-00051P-1J for lemonade@ietf.org; Mon, 27 Feb 2006 09:49:59 -0500 Received: from [172.16.1.198] (shiny.isode.com [62.3.217.250]) by rufus.isode.com via TCP (submission) with ESMTPA; Mon, 27 Feb 2006 14:49:46 +0000 Message-ID: <44031182.7030301@isode.com> Date: Mon, 27 Feb 2006 14:49:38 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Glenn Parsons Subject: Re: [lemonade] Draft deadline References: <085091CB2CA14E4B8B163FFC37C84E9D0894A215@zcarhxm0.corp.nortel.com> In-Reply-To: <085091CB2CA14E4B8B163FFC37C84E9D0894A215@zcarhxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Glenn Parsons wrote: > As we discussed in Beijing, I would hope to see revised drafts on: > > Profile-bis > Notifications > Message event > Content transformation (CONVERT) > Filters (IMAP SIEVE & manage SIEVE) > The latter was published this month: draft-martin-managesieve-06.txt > Quick reconnect > Published this month: draft-ietf-lemonade-reconnect-05.txt > 2192bis > Published this month: draft-ietf-lemonade-rfc2192bis-01.txt. So I am almost of the hook ;-). Alexey _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Feb 28 20:48:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEGSH-0006cc-LN; Tue, 28 Feb 2006 20:48:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEGSH-0006cX-3g for lemonade@ietf.org; Tue, 28 Feb 2006 20:48:41 -0500 Received: from rwcrmhc14.comcast.net ([204.127.192.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEGSF-0005Fx-RU for lemonade@ietf.org; Tue, 28 Feb 2006 20:48:41 -0500 Received: from gawhitelaptop (c-67-162-191-81.hsd1.tx.comcast.net[67.162.191.81]) by comcast.net (rwcrmhc14) with SMTP id <20060301014838m1400392uhe>; Wed, 1 Mar 2006 01:48:39 +0000 From: "Greg White" To: Date: Tue, 28 Feb 2006 19:47:51 -0600 Message-ID: <027501c63cd2$26b7b450$6401a8c0@gawhitelaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [lemonade] final future release question (I think) X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org Hi folks, I am finishing up what I believe to be the last version of the Future Release draft, and I need to take a vote: Regarding the syntax of parameters on the MAIL command: The draft currently specifies the following: future-release-interval =3D future-release-integer future-release-date-time =3D Internet-style-date-time-UTC hold-type =3D "for" / "until" hold-info =3D future-release-interval / = future-release-date-time hold-param =3D "HOLD=3D" (("for;" future-release-interval) / ("until;" future-release-date-time)) Back in 11/05, Randy Gellens and Mark Crispin expressed a preference for = the following: future-release-interval =3D future-release-integer future-release-date-time =3D Internet-style-date-time-UTC hold-for-param =3D "HOLDFOR=3D" future-release-interval hold-until-param =3D "HOLDFOR=3D" future-release-date-time The reason I chose the first method was: 1) This forces the client to choose only one method of future = release, and the server only has to look for one HOLD parameter on the MAIL = command. 2) OK, so the server still has to parse the two subvalues in the = HOLD value to figure out what to do, but we already know how to do that (e.g. = the ORCPT parameter of the DSN extension). 3) In my mind, having two HOLD parameters makes it easier for the = client to screw up; i.e. putting both parms on the MAIL command, which = certainly the server should reject. But now the server has to make that check. Randy and Mark, could you state again (I apologize) why you like the two parm version better? Finally, if anyone has strong preferences one way or another, let me = know, and highest score wins. I'll get it in and we can LC this thing. Thanks, Greg _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Feb 28 21:01:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEGeZ-0005iJ-JT; Tue, 28 Feb 2006 21:01:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEGeY-0005iE-Sc for lemonade@ietf.org; Tue, 28 Feb 2006 21:01:22 -0500 Received: from mxout5.cac.washington.edu ([140.142.32.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEGeX-0006Rk-Hx for lemonade@ietf.org; Tue, 28 Feb 2006 21:01:22 -0500 Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) by mxout5.cac.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k2121JGS003669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 28 Feb 2006 18:01:19 -0800 X-Auth-Received: from Tomobiki-Cho.CAC.Washington.EDU (tomobiki-cho.cac.washington.edu [128.95.135.58]) (authenticated authid=mrc) by smtp.washington.edu (8.13.5+UW05.10/8.13.5+UW05.09) with ESMTP id k2121JIb020604 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 28 Feb 2006 18:01:19 -0800 Date: Tue, 28 Feb 2006 18:01:14 -0800 (Pacific Standard Time) From: Mark Crispin To: Greg White Subject: Re: [lemonade] final future release question (I think) In-Reply-To: <027501c63cd2$26b7b450$6401a8c0@gawhitelaptop> Message-ID: References: <027501c63cd2$26b7b450$6401a8c0@gawhitelaptop> Organization: Networks & Distributed Computing MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: lemonade@ietf.org X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org I have two objections to your proposal. First, I see nothing in RFC 2822 that prevents a client from specifying multiple parameters with the same name. Consequently, I think that your concern against HOLDFOR= and HOLDUNTIL= is misplaced; a client can just as easily have HOLD=for; and HOLD=until; in the same command. Second, I think that your proposed HOLD=for;20 syntax is bizarre (not to mention ugly). Is there any precedent for such use of semicolon in SMTP? I'm not aware of any (I admit that I haven't been keeping careful track). Where I have seen semi-colon used with parameters, it has been as a delimiter between parameters as in MIME. Consequently, my vote is against your proposal, and for HOLDFOR= and HOLDUNTIL= as previously discussed. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade From lemonade-bounces@ietf.org Tue Feb 28 21:26:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEH2b-0005hK-Ku; Tue, 28 Feb 2006 21:26:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEH2a-0005df-FH for lemonade@ietf.org; Tue, 28 Feb 2006 21:26:12 -0500 Received: from pythagoras.zen.co.uk ([212.23.3.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEH2Z-0007Bz-2G for lemonade@ietf.org; Tue, 28 Feb 2006 21:26:12 -0500 Received: from [217.155.137.60] (helo=turner.dave.cridland.net) by pythagoras.zen.co.uk with esmtp (Exim 4.30) id 1FEH2W-0006vO-KR; Wed, 01 Mar 2006 02:26:08 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by turner.dave.cridland.net (Postfix) with ESMTP id DD07E498004; Wed, 1 Mar 2006 02:27:21 +0000 (GMT) Received: from turner.dave.cridland.net ([127.0.0.1]) by localhost (turner.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27988-08; Wed, 1 Mar 2006 02:27:05 +0000 (GMT) Received: from peirce.dave.cridland.net (unknown [IPv6:2001:4bd0:2029:0:2e0:81ff:fe29:d16a]) by turner.dave.cridland.net (Postfix) with ESMTP id 97CF2498002; Wed, 1 Mar 2006 02:27:03 +0000 (GMT) Date: Wed, 01 Mar 2006 02:25:48 +0000 Subject: Re: [lemonade] final future release question (I think) References: <027501c63cd2$26b7b450$6401a8c0@gawhitelaptop> In-Reply-To: MIME-Version: 1.0 Message-Id: <28755.1141179949.810563@peirce.dave.cridland.net> From: Dave Cridland To: Mark Crispin Content-Type: text/plain; charset="us-ascii"; format="flowed" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at dave.cridland.net X-Originating-Pythagoras-IP: [217.155.137.60] X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Enhancements to Internet email to support diverse service enivronments X-BeenThere: lemonade@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Enhancements to Internet email to support diverse service enivronments List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: lemonade-bounces@ietf.org On Wed Mar 1 02:01:14 2006, Mark Crispin wrote: > I have two objections to your proposal. > > First, I see nothing in RFC 2822 that prevents a client from > specifying multiple parameters with the same name. Consequently, I > think that your concern against HOLDFOR= and HOLDUNTIL= is > misplaced; a client can just as easily have HOLD=for; and > HOLD=until; in the same command. > > Agreed. > Second, I think that your proposed HOLD=for;20 syntax is bizarre > (not to mention ugly). Is there any precedent for such use of > semicolon in SMTP? I'm not aware of any (I admit that I haven't > been keeping careful track). Where I have seen semi-colon used with > parameters, it has been as a delimiter between parameters as in > MIME. > > IIRC, DSN uses them for ORCPT, as Greg said, stuff like ORCPT=dns;MRC@CAC.WASHINGTON.EDU - but this is purely based on my highly fallible memory. The argument as presented is firstly a mitigation, and secondly only has effect where DSN is already supported. > Consequently, my vote is against your proposal, and for HOLDFOR= > and HOLDUNTIL= as previously discussed. > > Your original argument being that hold-for would not gain any new values that ought to make it through last call, essentially. I agree (with this argument of Mark's, and thus I'm for HOLDFOR/HOLDUNTIL) on the basis that I cannot conceive of any, and none have been presented. Dave. -- You see things; and you say "Why?" But I dream things that never were; and I say "Why not?" - George Bernard Shaw _______________________________________________ lemonade mailing list lemonade@ietf.org https://www1.ietf.org/mailman/listinfo/lemonade