From brong@fastmail.fm Wed Aug 1 05:10:43 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A58621F8996 for ; Wed, 1 Aug 2012 05:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cZsxwz4HKsE for ; Wed, 1 Aug 2012 05:10:41 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id B770D21F898D for ; Wed, 1 Aug 2012 05:10:41 -0700 (PDT) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 4D46121084; Wed, 1 Aug 2012 08:10:40 -0400 (EDT) Received: from web2.nyi.mail.srv.osa ([10.202.2.212]) by compute6.internal (MEProxy); Wed, 01 Aug 2012 08:10:40 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= FHg++qEepCqXiYiSWNfu/OXcckU=; b=myR/dQVWpfM3CHyjOZFJX7t2APZ35Sg4 UTkd672Dym2SJqUAtpi7pfxnSfSxwbQN9Ftqm7ZuhSr81MsA5+e1ok+DDQtaSfYu TmHF0vfkCnFnNcjjPoi+toFgdXJxcWDTKKCoXSKCa3BI1XMtqukS2UPAgqgPr+M1 JAGo56WXqhI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=FHg++qEepCqXiYiSWNfu/OXcckU=; b=i4a PGQZckGXrM7oy842lJJ0pJFMPfLAiWLkPJDQst9aGPNYrJi2Civ53LTJeMn1rD7G k1WuLkmDu32W9TJcbLcyrmNm1iyjR/TG2LFzTlxOQKclpES/ZpB62vyWRy1j7apQ /gl3I3G3157n5jTxU8tU0rlHs4E55+SYuUPpB4M0= Received: by web2.nyi.mail.srv.osa (Postfix, from userid 99) id 1F1295C2E7A; Wed, 1 Aug 2012 08:10:40 -0400 (EDT) Message-Id: <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> X-Sasl-Enc: suWW8rlVVH+YWSps1wEE2Qlz9FBMwKiqojDc2pcngSb+ 1343823040 From: Bron Gondwana To: Arnt Gulbrandsen , imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <50159CBE.3050308@gulbrandsen.priv.no> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> Date: Wed, 01 Aug 2012 14:10:40 +0200 Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 12:10:43 -0000 On Sun, Jul 29, 2012, at 10:27 PM, Arnt Gulbrandsen wrote: > On 07/29/2012 07:54 PM, Barry Leiba wrote: > > Yes, I very strongly prefer normative language here, rather than leaving > > it entirely unspecified. There are too many vague implementation > > choices in IMAP already, which cause problems for client developers. > > I very strongly dislike writing things like "servers may optimise > unimportant corner cases" (I rephrased to bring the issue out more > clearly). Yes, they may, but I don't think good RFCs should say things > like that, and rewording to shroud the issue doesn't remove the problem. > > I thought about possible rules that would satisfy both you, Alexey and > myself, and I changed my own position. I now think that the only > sensible behaviour is to mandate OK. > > Arguments: > > First, copystoreexpunge works that way. Do we have a good reason to fail > in cases copystoreexpunge OKs? I fail to see any. Performance in corner > cases doesn't matter, and the locking issue Bron brings up is a cyrus bug. I agree - it's a Cyrus bug. I'm going to fix Cyrus. Sorry I even brought the topic up! Let's behave like COPYSTOREEXPUNGE and not screw around. > Second, other move-capable systems I use support noop moves, and it's > convenient. SQL servers do not reject an UPDATE ... WHERE when zero rows > would be affected, they say "OK, 0 rows affected". The unix mv command > also accepts noop moves, and many, many shell scripts and state machines > depend on it. "mv $a $basedir/unprocessed" works even if $a happens to > be in unprocessed already, "mv $(find ...) foo" works, etc. What would COPYUID say? Bron. -- Bron Gondwana brong@fastmail.fm From arnt@gulbrandsen.priv.no Wed Aug 1 05:24:32 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609F921F8CB8 for ; Wed, 1 Aug 2012 05:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xpu29exdx4N5 for ; Wed, 1 Aug 2012 05:24:31 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C6F21F8CCC for ; Wed, 1 Aug 2012 05:24:31 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 0D3FBF8CE9B; Wed, 1 Aug 2012 12:24:30 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343823869-8717-8716/10/5; Wed, 1 Aug 2012 12:24:29 +0000 Message-Id: <5019200B.6000006@gulbrandsen.priv.no> Date: Wed, 1 Aug 2012 14:24:43 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: Bron Gondwana References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> In-Reply-To: <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 12:24:32 -0000 On 08/01/2012 02:10 PM, Bron Gondwana wrote: > What would COPYUID say? Something that describes reality. If the server doesn't reissue UIDs, COPYUID has to say something like 42:69 42:69 (ie. unity mapping). If the server reissues, then it has to say 42:69 12342:12369 or whatever. Or the server might not send COPYUID, wich would cause some unnecessary cache misses, but who cares about cache efficiency in such uncommon cases? Arnt From brong@fastmail.fm Wed Aug 1 05:57:53 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD6611E847A for ; Wed, 1 Aug 2012 05:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtvHYIL4UGyf for ; Wed, 1 Aug 2012 05:57:52 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 4645911E82C2 for ; Wed, 1 Aug 2012 05:57:52 -0700 (PDT) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id AFCF420F96; Wed, 1 Aug 2012 08:57:51 -0400 (EDT) Received: from web2.nyi.mail.srv.osa ([10.202.2.212]) by compute4.internal (MEProxy); Wed, 01 Aug 2012 08:57:51 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:cc:mime-version:content-transfer-encoding :content-type:in-reply-to:references:subject:date; s=mesmtp; bh= CTdhYWb87kfUNFsKBdF3uHgAdG0=; b=MF0pKA1379o6aN1ijbDBIygJ7GBNGKwL t2fwus93cHNqyB9jPiHW1vEHqVPX3MFOH/ZJIXbBvGSJO8HOLyj5ySQUutS8LolR YCBjdI0xeBzxRwDGFdTWwXVYOYdoKH7NsueCE4LP6a9PeBB9bA4hcIhHGa1anGjx 4VjZuPyMa38= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:cc:mime-version :content-transfer-encoding:content-type:in-reply-to:references :subject:date; s=smtpout; bh=CTdhYWb87kfUNFsKBdF3uHgAdG0=; b=uB1 YJ4QGZMwbBD1Xd6sFkjf4N2zAoHGItvavl/g4bNgL38iafBE14cfbt0hae8p+27N nmDTCm2JOBvsYIxZHMIJS+141JQ1fUBSA0c6jXQPTNcJfUy2/RdaGpHEtoTbrrZe EfLsYSxuxtKwtqI0hJRkmZC4BngzfUbagWbmAEoM= Received: by web2.nyi.mail.srv.osa (Postfix, from userid 99) id 827435C2E7A; Wed, 1 Aug 2012 08:57:51 -0400 (EDT) Message-Id: <1343825871.15969.140661109335193.5C29A5ED@webmail.messagingengine.com> X-Sasl-Enc: xR/qX2R15e6OxAgtIPJf+TUS7OA35IaEecZqyXxho3iQ 1343825871 From: Bron Gondwana To: Arnt Gulbrandsen MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface In-Reply-To: <5019200B.6000006@gulbrandsen.priv.no> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> <5019200B.6000006@gulbrandsen.priv.no> Date: Wed, 01 Aug 2012 14:57:51 +0200 Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 12:57:53 -0000 On Wed, Aug 1, 2012, at 02:24 PM, Arnt Gulbrandsen wrote: > On 08/01/2012 02:10 PM, Bron Gondwana wrote: > > What would COPYUID say? > > Something that describes reality. > > If the server doesn't reissue UIDs, COPYUID has to say something like > 42:69 42:69 (ie. unity mapping). If the server reissues, then it has to > say 42:69 12342:12369 or whatever. Or the server might not send COPYUID, > wich would cause some unnecessary cache misses, but who cares about > cache efficiency in such uncommon cases? Is a client going to cope with unity mapping? I guess they will actually, since they presumably think they are different folders for some reason. Makes sense. Bron. -- Bron Gondwana brong@fastmail.fm From arnt@gulbrandsen.priv.no Wed Aug 1 05:59:46 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C6B11E84ED for ; Wed, 1 Aug 2012 05:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DD4dN09i-ULF for ; Wed, 1 Aug 2012 05:59:45 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CCB11E84E3 for ; Wed, 1 Aug 2012 05:59:44 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 49C7AFA057F; Wed, 1 Aug 2012 12:59:44 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343825983-8717-8716/10/6; Wed, 1 Aug 2012 12:59:43 +0000 Message-Id: <5019284C.9060307@gulbrandsen.priv.no> Date: Wed, 1 Aug 2012 14:59:56 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: Bron Gondwana References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> <5019200B.6000006@gulbrandsen.priv.no> <1343825871.15969.140661109335193.5C29A5ED@webmail.messagingengine.com> In-Reply-To: <1343825871.15969.140661109335193.5C29A5ED@webmail.messagingengine.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 12:59:46 -0000 On 08/01/2012 02:57 PM, Bron Gondwana wrote: > Is a client going to cope with unity mapping? I guess they will actually, > since they presumably think they are different folders for some reason. Maybe I ought to put in a hint that this case warrants testing (and for clients, both with and without the extension). Arnt From blong@google.com Wed Aug 1 17:13:54 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4149721F8914 for ; Wed, 1 Aug 2012 17:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-Cs058h6CC2 for ; Wed, 1 Aug 2012 17:13:53 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0310921F89B4 for ; Wed, 1 Aug 2012 17:13:52 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so14740111obb.31 for ; Wed, 01 Aug 2012 17:13:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=9ZCpQ4HgdIMmWnt03l4JlP4GZb6cUMNKffsIRhMYyts=; b=WU+guUy2DMMQGo4bTSv/3JxVrzTXF9wqWtpO+gHMytymavhVdqWzAxbFah97XwEKxq zeen9ok9WL0YQ1OZBnucjbeVlZwKPZogwG4T/Mwb7dmo+dqNbHe0xbrFBWqaiKRjc1jE cMkfYDH2GwDHDVQxLtRja8mnXi+GCoAUyMrrqoElst6zB4TgmfPTe/Mt/K2fHbA/uolB +45NtRf22t9XB7HgagXx0WYhJGyQwpu7l87Yh34dwezPf1KRNA6uiTLSuPwBVOTN741W WW+pAGE/KtNmTlUdb0Cb7sHq4w2ZPGiTa1ymLsvkDfbLljopPU3QE1io/X662EfeuswL Lx0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=9ZCpQ4HgdIMmWnt03l4JlP4GZb6cUMNKffsIRhMYyts=; b=QbYepJp0GNCKu7pjfzhZy+LX6X94KRvL8h5ZmQiSf0zG8P2w6ByGkYkTxRL0/U6iiN NxxFheYj3lmKa+BIyxulzsNIAuwK1Wk8MiWL/I1thJP+MrtkBiG2mT6hC1okdYUhaORw CoAQl6yOL4BWw6efFcnVKI+xN0eAYHM0yZp11qPkFS1pei4ctShheiLsApkap5O/GDs7 Y4gvFhFnEooRFMIEAVDaHVP+yXj/jPhpRcd3VHioPYzAFD6QcNU84gqqlUYZM+Hx22KC W1YZQLS9e6S2P72G+HguJPubf05qelckgMotcoJPuWljcbzu/6nHh45ElXTPR5iapv/Z 1QhQ== Received: by 10.182.0.13 with SMTP id 13mr18790073oba.55.1343866432518; Wed, 01 Aug 2012 17:13:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.0.13 with SMTP id 13mr18790060oba.55.1343866432354; Wed, 01 Aug 2012 17:13:52 -0700 (PDT) Received: by 10.76.163.104 with HTTP; Wed, 1 Aug 2012 17:13:52 -0700 (PDT) In-Reply-To: <500D154F.20809@flaska.net> References: <500D154F.20809@flaska.net> Date: Wed, 1 Aug 2012 17:13:52 -0700 Message-ID: From: Brandon Long To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= Content-Type: multipart/alternative; boundary=f46d043c802453798f04c63d49a9 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmAgUY2xMJ7Ii9hVh9ulYnnWe5uanAqz5pp3N4EK+30mDKYbyGoBhk/P2Unjq9NJAvit9cLUn64CJZqvL3LPq73ukQvRcnKBlVW5gltVf8skaLQz3C3N1mmqLgX7dI5FIOcj8PjcW7ZdL/m3pppWDHWnUCY8Z0GyVBOsrc+JEAYdtoSiPOsx/XeB5MOD1Ijlls7f1/I Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:13:54 -0000 --f46d043c802453798f04c63d49a9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jul 23, 2012 at 2:11 AM, Jan Kundr=E1t wrote: [snip] > > Please tell that to Google who still produces invalid BODYSTRUCTURE > responses on e-mails with attached message/rfc822 parts (last checked a f= ew > months ago, anyway). As a client developer, I can assure you that it is N= OT > FUN to try to guess what five fields out of a sequence of twenty mandator= y > fields are missing today. I won't willingly inflict the same on any other > programmer unless I'm in a really, really nasty mood. I'm not sure its that complicated, but if you'd like the current information on that... I tried to fix this almost a year ago. The bug was that our parser considers message/rfc822 attachments with content-disposition: attachment to be a blob, not a multipart container. Simple problem, just have it always consider it a multipart container. Except that doesn't work if the attachment is content-transfer-encoded. Note that its against spec to content-transfer-encode a message/rfc822 attachment, but some people do it anyways. And there is some comment that the future utf8 message headers would require you to cte a message/rfc822 attachment, but let's ignore that for now. So, let's only treat it as a multipart container if its not encoded. We could also add a step somewhere else to "fix" messages to not be cte, but that doesn't really happen at the parser level. We could make a copy of the attachment and decode it, but its not clear if that will work correctly for body part handling in IMAP either (how do you ask for just the text of a sub-part that's encoded at higher level?) Anyways, turns out, this breaks a whole bunch of assumptions in our code, but fix most of them. Run into fact that during certain rebuilding steps, we've now shifted what's considered an attachment in a major way on some messages, making old parsed messages and new parsed messages be very dissimilar. Rollback change again. Why I say its not complicated is because our "breakage" is in whether or not the message/rfc822 is considered a container or not. I don't like that we're broken, but IMAP is essentially forcing us to handle messages in a specific format for that protocol, which is in direct competition with the more common use case for our customers (which is dragging and dropping an ".eml file" into an email, which they expect to be an attachment). I'd like to fix it, but even if we correct our parser, I'm not sure when we'd get around to re-parsing all of our existing messages to fix this case (we often re-parse messages, but we've never had a change which requires re-computing what's an attachment, doing this would require some immense resources). We could, theoretically, re-compose the full message and re-parse it in order to correctly produce a BODYSTRUCTURE response, but the extra resources necessary to always do that is completely infeasible for however few clients out there haven't already worked around our brokenness. As always, I'm sorry Gmail was not designed to satisfy IMAP from the get go (no, really I am, since my team has to make the two mostly work together), but it wasn't, so compromises are made. In any case, the bug is still open, the fix is now a very known quantity, and when the backend team gets the resources to work on it, it'll probably get done... maybe next year. Brandon Brandon --f46d043c802453798f04c63d49a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, J= ul 23, 2012 at 2:11 AM, Jan Kundr=E1t <jkt@flaska.net>= ; wrote:
[snip]

Please tell that to Google who still produces invalid BODYSTRUCTURE respons= es on e-mails with attached message/rfc822 parts (last checked a few months= ago, anyway). As a client developer, I can assure you that it is NOT FUN t= o try to guess what five fields out of a sequence of twenty mandatory field= s are missing today. I won't willingly inflict the same on any other pr= ogrammer unless I'm in a really, really nasty mood.

I'm not sure its that complicated, but if you'd= like the current information on that...

I tried t= o fix this almost a year ago. =A0The bug was that our parser considers mess= age/rfc822 attachments with content-disposition: attachment to be a blob, n= ot a multipart container.

Simple problem, just have it always consider it a multi= part container.

Except that doesn't work if th= e attachment is content-transfer-encoded. =A0Note that its against spec to = content-transfer-encode a message/rfc822 attachment, but some people do it = anyways. =A0And there is some comment that the future utf8 message headers = would require you to cte a message/rfc822 attachment, but let's ignore = that for now.

So, let's only treat it as a multipart container if= its not encoded. =A0We could also add a step somewhere else to "fix&q= uot; messages to not be cte, but that doesn't really happen at the pars= er level. =A0We could make a copy of the attachment and decode it, but its = not clear if that will work correctly for body part handling in IMAP either= (how do you ask for just the text of a sub-part that's encoded at high= er level?)

Anyways, turns out, this breaks a whole bunch of assump= tions in our code, but fix most of them. =A0Run into fact that during certa= in rebuilding steps, we've now shifted what's considered an attachm= ent in a major way on some messages, making old parsed messages and new par= sed messages be very dissimilar. =A0Rollback change again.

Why I say its not complicated is because our "brea= kage" is in whether or not the message/rfc822 is considered a containe= r or not. =A0I don't like that we're broken, but IMAP is essentiall= y forcing us to handle messages in a specific format for that protocol, whi= ch is in direct competition with the more common use case for our customers= (which is dragging and dropping an ".eml file" into an email, wh= ich they expect to be an attachment). I'd like to fix it, but even if w= e correct our parser, I'm not sure when we'd get around to re-parsi= ng all of our existing messages to fix this case (we often re-parse message= s, but we've never had a change which requires re-computing what's = an attachment, doing this would require some immense resources).

We could, theoretically, re-compose the full message an= d re-parse it in order to correctly produce a BODYSTRUCTURE response, but t= he extra resources necessary to always do that is completely infeasible for= however few clients out there haven't already worked around our broken= ness.

As always, I'm sorry Gmail was not designed to sati= sfy IMAP from the get go (no, really I am, since my team has to make the tw= o mostly work together), but it wasn't, so compromises are made.

In any case, the bug is still open, the fix is now a ve= ry known quantity, and when the backend team gets the resources to work on = it, it'll probably get done... maybe next year.

Brandon

Brandon
--f46d043c802453798f04c63d49a9-- From adrien@qbik.com Wed Aug 1 17:30:38 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93BE11E8113 for ; Wed, 1 Aug 2012 17:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.737 X-Spam-Level: X-Spam-Status: No, score=-3.737 tagged_above=-999 required=5 tests=[AWL=-1.138, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-PU0Sklc+ml for ; Wed, 1 Aug 2012 17:30:38 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id CF56611E80FD for ; Wed, 1 Aug 2012 17:30:37 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.5 (Build 3447)) with SMTP id <0019171206@smtp.qbik.com>; Thu, 02 Aug 2012 12:30:35 +1200 From: "Adrien W. de Croy" To: "Ned Freed" , "Arnt Gulbrandsen" Date: Thu, 02 Aug 2012 00:30:35 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <01OI6KIY5A200006TF@mauve.mrochek.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:30:38 -0000 ------ Original Message ------ From: "Ned Freed" > >P.S. And doing this stuff "right", for some value of "right", doesn't=20 >make=20 >submission facilities in IMAP a good idea.=20 I'm one of those who believes submission in IMAP is a great idea, long=20 overdue. But obviously others think it's a bad idea. I'm keen to make sure I didn't overlook something that would alter my=20 position on this. So, my questions are: 1. Why is submission in IMAP such a bad idea? 2. Why should the benefits of: * simplified client configuration (one set of credentials and 1=20 protocol to configure for mail rather than 2) * simplified server administration (one firewall port to open) * reduced support burden for mail operators (no more "I can receive=20 mail fine, but I can't send" support queries) * reduced problems for clients, e.g. - ISP blocks port 25 (common) - debugging issues related to errors in any configuration item=20 (since these are halved). be abandoned? Maybe there's a use-case where the badness doesn't apply, and maybe=20 that use-case is enough to justify submission in IMAP, and in other=20 cases it can be disabled - e.g. shouldn't it then just be a policy=20 issue for the operator of the server. Regards Adrien From tss@iki.fi Wed Aug 1 17:43:00 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A03811E81DD for ; Wed, 1 Aug 2012 17:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.505 X-Spam-Level: X-Spam-Status: No, score=-110.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-gmQYijJ6HX for ; Wed, 1 Aug 2012 17:42:59 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id AE0B211E819B for ; Wed, 1 Aug 2012 17:42:59 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 4081A1AE87B3; Thu, 2 Aug 2012 03:42:58 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Thu, 2 Aug 2012 03:42:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Adrien W. de Croy" X-Mailer: Apple Mail (2.1084) Cc: Arnt Gulbrandsen , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:43:00 -0000 On 2.8.2012, at 3.30, Adrien W. de Croy wrote: > 2. Why should the benefits of: >=20 > * simplified client configuration (one set of credentials and 1 = protocol to configure for mail rather than 2) > * simplified server administration (one firewall port to open) > * reduced support burden for mail operators (no more "I can receive = mail fine, but I can't send" support queries) > * reduced problems for clients, e.g. > - ISP blocks port 25 (common) > - debugging issues related to errors in any configuration item = (since these are halved). >=20 > be abandoned? All of these can be reduced to one question: * Why can't the client ask how to submit a message via SMTP protocol = (via whatever host:port)? From lyndon@orthanc.ca Wed Aug 1 17:44:26 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B6311E81DD for ; Wed, 1 Aug 2012 17:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXK67bJTKfpJ for ; Wed, 1 Aug 2012 17:44:25 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [199.48.133.202]) by ietfa.amsl.com (Postfix) with ESMTP id 309D711E819B for ; Wed, 1 Aug 2012 17:44:25 -0700 (PDT) Received: from [172.25.0.6] ([184.69.13.98]) (authenticated bits=0) by orthanc.ca (8.14.5/8.14.5) with ESMTP id q720iNJK051383 for ; Wed, 1 Aug 2012 17:44:24 -0700 (PDT) (envelope-from lyndon@orthanc.ca) From: Lyndon Nerenberg Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_8568C528-07FC-45C2-BDD1-07DEE3228153"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Wed, 1 Aug 2012 17:44:19 -0700 In-Reply-To: To: imapext@ietf.org References: Message-Id: <59CADF8D-14A3-44E4-AA02-2D979C076E1D@orthanc.ca> X-Mailer: Apple Mail (2.1278) Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:44:26 -0000 --Apple-Mail=_8568C528-07FC-45C2-BDD1-07DEE3228153 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > I'm keen to make sure I didn't overlook something that would alter my = position on this. Ned, which WG is the right one for the 'mail submission via mail reading = protocols considered harmful' draft? That document needs to be written. = Soon. There is a lot of history that must be codified and condensed to = prevent future futility ... --lyndon= --Apple-Mail=_8568C528-07FC-45C2-BDD1-07DEE3228153 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJQGc1jAAoJEG8PnXiV/JnUnVEP/3nnbaem4gkLGPbTJuYgmGpe I9L7ZA35QB2u7H/Oiy+d42WhzpgVzikWbHDW3ju2LUEey17I1f0jssdnxeTjvOyx mp4WXEgMYMBI3ZRRohPbSCRTAnNjKtR5hk7USDg22XHHvTKqETxHU9XM3WhiByMY xJBzC/OQzKPB/yiJmyJcUC2CjALHL51MURgWtvPVcDSGEcgVplo7DyzMlTaMN2QR RwB6WZOHEYqZA7dNuzqhk5e8MpFf4Ir+WZmLPxAdvC8lbTAES8f+tPNek6JLSVlo aYPxSM9Rps48kQ70kUe8xM2Me4UnQy4ygQzE2W2bHLoudT/oH/S0b6D8wTsToMa8 dsZLrYoL2GUHOZipDs3qVID8dOownVy4MP3xfwcb+sulrBEkMZCtofa550dxn3sQ myhbkhm1LwySISvxfe77LEi/nQqqYzNXPx/x1Hfi/efifLUhPzFmjFGmftRZTF2j uJ6vrg9vdzusOXZLO+K0kgAreTrmYzh6usL6W9XKJ1V0rV6ALrNpz2voDd1fU7pN WT7/34dLqHilr3lG31957yEZr2f8s14LWsxcuC+vJJc4hjZH6VZxSaUVXpTydLwm mZxXrtboDfejgX5/Vy2ogq6Uj/ETaJTZ+4xO2fBj/D3wYX1s/U7YpoL7pZfOirlg BZaNoJmfU3cqEt+FMBXI =dgky -----END PGP SIGNATURE----- --Apple-Mail=_8568C528-07FC-45C2-BDD1-07DEE3228153-- From tss@iki.fi Wed Aug 1 17:48:43 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E046511E81F3 for ; Wed, 1 Aug 2012 17:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.51 X-Spam-Level: X-Spam-Status: No, score=-110.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GD22nszzbB2V for ; Wed, 1 Aug 2012 17:48:43 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5282D11E81F6 for ; Wed, 1 Aug 2012 17:48:43 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 9711E1AE87B3; Thu, 2 Aug 2012 03:48:42 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <59CADF8D-14A3-44E4-AA02-2D979C076E1D@orthanc.ca> Date: Thu, 2 Aug 2012 03:48:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <18602849-57CC-47AD-B73B-D57B6225788D@iki.fi> References: <59CADF8D-14A3-44E4-AA02-2D979C076E1D@orthanc.ca> To: Lyndon Nerenberg X-Mailer: Apple Mail (2.1084) Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:48:44 -0000 On 2.8.2012, at 3.44, Lyndon Nerenberg wrote: >> I'm keen to make sure I didn't overlook something that would alter my = position on this. >=20 > Ned, which WG is the right one for the 'mail submission via mail = reading protocols considered harmful' draft? That document needs to be = written. Soon. There is a lot of history that must be codified and = condensed to prevent future futility ... Even though I don't want to implement it (for a server), and I think = it's probably not a good idea .. I'm still not sure if it actually a = really bad idea. I can understand why client people want it at least. From lyndon@orthanc.ca Wed Aug 1 17:51:12 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C76A311E81F3 for ; Wed, 1 Aug 2012 17:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8+XjFEn0few for ; Wed, 1 Aug 2012 17:51:11 -0700 (PDT) Received: from orthanc.ca (orthanc.ca [199.48.133.202]) by ietfa.amsl.com (Postfix) with ESMTP id 3534611E8106 for ; Wed, 1 Aug 2012 17:51:11 -0700 (PDT) Received: from [172.25.0.6] ([184.69.13.98]) (authenticated bits=0) by orthanc.ca (8.14.5/8.14.5) with ESMTP id q720pAof051412 for ; Wed, 1 Aug 2012 17:51:10 -0700 (PDT) (envelope-from lyndon@orthanc.ca) From: Lyndon Nerenberg Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_E252573D-F150-4D39-B61B-CED034135314"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Wed, 1 Aug 2012 17:51:06 -0700 In-Reply-To: To: imapext@ietf.org References: Message-Id: X-Mailer: Apple Mail (2.1278) Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:51:12 -0000 --Apple-Mail=_E252573D-F150-4D39-B61B-CED034135314 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012-08-01, at 17:42 PM, Timo Sirainen wrote: > (via whatever host:port)? Timo nails it. All that is missing is resource discovery to find the SMTP submission = server. Given that we don't even have discovery for the mail reading part, it = shouldn't be that hard to come up with something that encapsulates = *both* reading and sending in a single simple service discovery = mechanism. No? --lyndon --Apple-Mail=_E252573D-F150-4D39-B61B-CED034135314 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJQGc76AAoJEG8PnXiV/JnUUA4P+wS/dXKJmXpG8DFcmzBwLnIY XGk5yLO5za0cdseTUiox+rLYzUI9wBKGwuYttPnWPzNi0txzwm3JNRL3a1Q9vwdR 7dV1/8kf1tf0LtMMqonO3RNzQQPMgcHyQORti2G2kPblAcAmsOBQwMxhsTY1zwBQ yQzO8YmqsxYmKMJaWP9vUMp45U9leNMbVUoOs63FqDQj2qhg0XVg2GbU1CwKv31s ig9C3SOUQCnMmf7RS6YcraivI6ZHYhjEdrwljDWT58QcXb1iXUmm+JqR2+koEqC+ ybOi29H8IQ+cWc5sTrwyREEdnWRi4foM2HwGmIHBXjjyJ16Dj1LauY9WC+fbPpIA jzYU7mfInYecGMAfqH170Z+T2Oc3nEq4QohngGN20llHczachxeJRubfNChbu7fT bJYQjgYrOpTGwlp1FEc71HdhTIn00Ilx6d9RyOmrTKMS2J6Nf7R/P0ko/cqM+0yK YnH4UkLQ9TSTDCiD3j+3357Nm/X/bN+faBzqjG+D1Kpxh5HCBD2WSXk07mlvDJ9a Y6/IhMis6H42jmbtg+gAl5yr+hqFMSGOTPAZKWCh9waZLScUNo3B/VHR/IrolDbC Iv0ZuWxRSliJ2QCFLei3BVWlAGyAYuipUy3iUjVHZcNX5icSg0qYYe7/Lcu4AsqR HlCDZN4x3yMzurPSQ/Pr =1ouZ -----END PGP SIGNATURE----- --Apple-Mail=_E252573D-F150-4D39-B61B-CED034135314-- From derek.diget+ietf-imapext@wmich.edu Wed Aug 1 17:57:45 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB42921F897B for ; Wed, 1 Aug 2012 17:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx-nbkzIDsnh for ; Wed, 1 Aug 2012 17:57:44 -0700 (PDT) Received: from mx-tmp.wmich.edu (mx-tmp.wmich.edu [141.218.1.43]) by ietfa.amsl.com (Postfix) with ESMTP id C188A21F8979 for ; Wed, 1 Aug 2012 17:57:44 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=US-ASCII Received: from spaz.oit.wmich.edu (spaz.oit.wmich.edu [141.218.24.51]) by mta01.service.private (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 64bit)) with ESMTPSA id <0M8300IYJS04X2B0@mta01.service.private> for imapext@ietf.org; Wed, 01 Aug 2012 20:57:41 -0400 (EDT) X-WMU-Spam: Gauge=X, Probability=10% on Wed Aug 1 20:57:41 2012, Report=' WMU_MSA_SMTP+ 0, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1500_1599 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_EDU_TLD 0, SPF_NEUTRAL 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_MAILTO 0, __URI_NO_PATH 0, __URI_NS ' X-WMU-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.2.4831 - Wed Aug 1 20:57:41 2012 Date: Wed, 01 Aug 2012 20:57:40 -0400 (EDT) From: Derek Diget X-X-Sender: diget@spaz.oit.wmich.edu To: "imapext@ietf.org" In-reply-to: Message-id: References: Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 00:57:45 -0000 On Aug 2, 2012 at 03:42 +0300, Timo Sirainen wrote: =>On 2.8.2012, at 3.30, Adrien W. de Croy wrote: => =>> 2. Why should the benefits of: =>> =>> * simplified client configuration (one set of credentials and 1 protocol to configure for mail rather than 2) =>> * simplified server administration (one firewall port to open) Lets just make the Internet work on TCP port 80. :,) If we have to use another port because this one is full there is always 443. :) =>> * reduced support burden for mail operators (no more "I can receive mail fine, but I can't send" support queries) =>> * reduced problems for clients, e.g. =>> - ISP blocks port 25 (common) Clients should be using SUBMISSION (TCP 587 - RFC 6409) and operators should be looking at RFC 5068. =>> - debugging issues related to errors in any configuration item (since these are halved). =>> =>> be abandoned? => =>All of these can be reduced to one question: => => * Why can't the client ask how to submit a message via SMTP protocol (via whatever host:port)? RFC 6186 - Use of SRV Records for Locating Email Submission/Access Services (Not sure if there are any clients supporting this yet. :( -- *********************************************************************** Derek Diget Office of Information Technology Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ *********************************************************************** From adrien@qbik.com Wed Aug 1 18:00:40 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2067D21F89EF for ; Wed, 1 Aug 2012 18:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.712 X-Spam-Level: X-Spam-Status: No, score=-3.712 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+hKUQmrOp-h for ; Wed, 1 Aug 2012 18:00:39 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id C492321F88D6 for ; Wed, 1 Aug 2012 18:00:37 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.5 (Build 3447)) with SMTP id <0019171248@smtp.qbik.com>; Thu, 02 Aug 2012 13:00:36 +1200 From: "Adrien W. de Croy" To: "Timo Sirainen" , "Lyndon Nerenberg" Date: Thu, 02 Aug 2012 01:00:36 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <18602849-57CC-47AD-B73B-D57B6225788D@iki.fi> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:00:40 -0000 ------ Original Message ------ From: "Timo Sirainen" >On 2.8.2012, at 3.44, Lyndon Nerenberg wrote: > > >>> >>>I'm keen to make sure I didn't overlook something that would alter my= position on this. >>> >> >> >>Ned, which WG is the right one for the 'mail submission via mail reading= protocols considered harmful' draft? That document needs to be written.= Soon. There is a lot of history that must be codified and condensed to = prevent future futility ... >> > > >Even though I don't want to implement it (for a server), and I think it's= probably not a good idea .. I'm still not sure if it actually a really = bad idea. I can understand why client people want it at least. > Actually we're just server implementors as well. We do get a heap of support issues about inability to do one or other=20 of SMTP or IMAP. I'm sick of debugging those issues with clients, and=20 I'm sure customers are constantly bewildered that mail is still so=20 "difficult" in the 21st century when we've been doing it for so long. =20 There's a perceived lack of progress on basic usability. The causes are normally due to issues such as inaccessibility of one=20 port vs another through a firewall or ISP, or issues relating to=20 different realms of credentials, or quite often simple human error=20 entering server names and passwords twice. Anyway, that's why I'm keen to see it. Ironically, webmail has it. And where does the future of mail seem to=20 be going? The contortions that mail client vendors go through to try and ease=20 this process is obvious when you try to create a user account in=20 Thunderbird or many other mail clients. Any time you use another protocol for something you have issues=20 associated with accessibility of that protocol, realms of credentials=20 etc. Each of SMTP, POP3, IMAP have their own methods to establish=20 credentials. =20 In the context of this discussion, there are 2 functions of mail=20 clients. Retrieval, and submission. There is a cost associated with maintaining and supporting users of any=20 1 protocol. Requiring 2 protocols for the function of a mail client=20 has a double cost compared to a single protocol that could do both. If we abstracted, back to some sort of discovery protocol where you=20 queried for configuration of SMTP or IMAP, we'd be not necessarily any=20 better off. If a client can connect to the discovery service, it knows it has that=20 connection, it doesn't know it can connect on other ports. Any port=20 you require to be used has a non-zero chance of being unavailable due=20 to whatever reason, so the more ports you require for mail function,=20 the higher the chance that you won't get full function. Adrien > > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext > > From adrien@qbik.com Wed Aug 1 18:03:20 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1034921F8A49 for ; Wed, 1 Aug 2012 18:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.688 X-Spam-Level: X-Spam-Status: No, score=-3.688 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dyyb9q-0dq5 for ; Wed, 1 Aug 2012 18:03:19 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id E0E1621F8A44 for ; Wed, 1 Aug 2012 18:03:18 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.5 (Build 3447)) with SMTP id <0019171256@smtp.qbik.com>; Thu, 02 Aug 2012 13:03:17 +1200 From: "Adrien W. de Croy" To: "Lyndon Nerenberg" , "imapext@ietf.org" Date: Thu, 02 Aug 2012 01:03:17 +0000 Content-Type: multipart/alternative; boundary="------=_MBF156018E-2074-4D9F-B056-54B40C650BE5" In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:03:20 -0000 --------=_MBF156018E-2074-4D9F-B056-54B40C650BE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 ------ Original Message ------ From: "Lyndon Nerenberg" To: "imapext@ietf.org" Sent: 2/08/2012 12:51:06 p.m. Subject: Re: [imapext] Mail submission over IMAP >On 2012-08-01, at 17:42 PM, Timo Sirainen wrote: > > >> >>(via whatever host:port)? >> > > >Timo nails it. > >All that is missing is resource discovery to find the SMTP submission serv= er. > Discovery is independent of accessibility. So whilst I think discovery=20 could be a great thing, and simplify a lot of client configuration, you=20 still don't address basic accessibility to a port. Furthermore, the discovery server would probably also require some=20 credentials if it is handing out potentially sensitive information=20 (which server to connect to for such-and-such a mailbox). So this would mean we'd either have to hobble discovery to only public=20 information, or we'd actually exacerbate the problem. > > >Given that we don't even have discovery for the mail reading part, it shou= ldn't be that hard to come up with something that encapsulates *both* readi= ng and sending in a single simple service discovery mechanism. No? > >--lyndon > > > --------=_MBF156018E-2074-4D9F-B056-54B40C650BE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
------ Original Message ------
From: "Lynd= on Nerenberg" <lyndon@orthanc.ca>
To: "imapext@ietf.org" <imape= xt@ietf.org>
Sent: 2/08/2012 12:51:06 p.m.
Subject: Re: [imapext]= Mail submission over IMAP
On 2012-08-01, at 17:42 PM, Timo Sirainen wrote:



(via whatever host:port)?



Timo nails it.

All that is missing is resource discovery to find the SMTP submission serve=
r.
 
Discovery is independent of accessibi= lity.  So whilst I think discovery could be a great thing, and simplif= y a lot of client configuration, you still don't address basic accessibilit= y to a port.
 
Furthermore, the discovery server = would probably also require some credentials if it is handing out potential= ly sensitive information (which server to connect to for such-and-such a= mailbox).
 
So this would mean we'd either have= to hobble discovery to only public information, or we'd actually exacerbat= e the problem.

 

Given that we don't even have discovery for the mail reading part, it shoul=
dn't be that hard to come up with something that encapsulates *both* readin=
g and sending in a single simple service discovery mechanism.  No?

--lyndon
--------=_MBF156018E-2074-4D9F-B056-54B40C650BE5-- From adrien@qbik.com Wed Aug 1 18:21:43 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D5B21F8AFC for ; Wed, 1 Aug 2012 18:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FPBaNjzXsSx for ; Wed, 1 Aug 2012 18:21:42 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 09C3421F88E7 for ; Wed, 1 Aug 2012 18:21:41 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.5 (Build 3447)) with SMTP id <0019171271@smtp.qbik.com>; Thu, 02 Aug 2012 13:21:40 +1200 From: "Adrien W. de Croy" To: "Derek Diget" , "imapext@ietf.org" Date: Thu, 02 Aug 2012 01:21:40 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:21:43 -0000 ------ Original Message ------ From: "Derek Diget" To: "imapext@ietf.org" Sent: 2/08/2012 12:57:40 p.m. Subject: Re: [imapext] Mail submission over IMAP >On Aug 2, 2012 at 03:42 +0300, Timo Sirainen wrote: >=3D>On 2.8.2012, at 3.30, Adrien W. de Croy wrote: >=3D> >=3D>> 2. Why should the benefits of: >=3D>> >=3D>> * simplified client configuration (one set of credentials and 1 prot= ocol to configure for mail rather than 2) >=3D>> * simplified server administration (one firewall port to open) > >Lets just make the Internet work on TCP port 80. :,) If we have to use >another port because this one is full there is always 443. :) > mail is already going there (along with seemingly everything else). Webmail, GMail, Live mail, Yahoo, OWA etc etc etc. All provide=20 submission and retrieval in the 1 protocol, with 1 set of credentials. Personally I prefer to use a dedicated email client, so I'm keen to see=20 a dedicated protocol rather than using HTTP (esp in-house). And we also have to implement policy on HTTP, so actually I'd prefer to=20 see port 80/443 used for fewer things rather than more. > >=3D>> * reduced support burden for mail operators (no more "I can receive= mail fine, but I can't send" support queries) >=3D>> * reduced problems for clients, e.g. >=3D>> - ISP blocks port 25 (common) > >Clients should be using SUBMISSION (TCP 587 - RFC 6409) and operators >should be looking at RFC 5068. > Sure. =20 Is there any way to advertise that IMAP server A and SUBMISSION server=20 B use the same realm of credentials (e.g. "you should use same=20 user/pass") Otherwise you still need to enter 2 usernames and passwords. You'd be=20 amazed how wrong people can get this. > > > >=3D>> - debugging issues related to errors in any configuration item= (since these are halved). >=3D>> >=3D>> be abandoned? >=3D> >=3D>All of these can be reduced to one question: >=3D> >=3D> * Why can't the client ask how to submit a message via SMTP protocol= (via whatever host:port)? > > >RFC 6186 - Use of SRV Records for Locating Email Submission/Access Service= s >(Not sure if there are any clients supporting this yet. :( > DNS is a difficult answer to that question. Many organisations would=20 love to run a mail server without having to run a DNS server. =20 Education here is a cost as well, as people need to be educated to set=20 up SRV records etc. Providing an integrated solution for those that do run both (e.g.=20 publish necessary records to DNS from mail server) is also difficult,=20 and adds links in the chain which can cause support issues. Adrien > > > >-- >*********************************************************************** >Derek Diget Office of Information Technology >Western Michigan University - Kalamazoo Michigan USA - www.wmich.edu/ >*********************************************************************** >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext > > From adrien@qbik.com Wed Aug 1 18:32:03 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93EA11E8152 for ; Wed, 1 Aug 2012 18:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.644 X-Spam-Level: X-Spam-Status: No, score=-3.644 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4C4+XwMvtCF for ; Wed, 1 Aug 2012 18:32:03 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id C85C811E8138 for ; Wed, 1 Aug 2012 18:32:02 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.5 (Build 3447)) with SMTP id <0019171282@smtp.qbik.com>; Thu, 02 Aug 2012 13:32:01 +1200 From: "Adrien W. de Croy" To: "Timo Sirainen" Date: Thu, 02 Aug 2012 01:32:01 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Ned Freed , Arnt Gulbrandsen , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 01:32:03 -0000 ------ Original Message ------ From: "Timo Sirainen" To: "Adrien W. de Croy" Cc: "Arnt Gulbrandsen" ;"Ned Freed"=20 ;"imapext@ietf.org" Sent: 2/08/2012 12:42:57 p.m. Subject: Re: [imapext] Mail submission over IMAP >On 2.8.2012, at 3.30, Adrien W. de Croy wrote: > > >> >>2. Why should the benefits of: >> >>* simplified client configuration (one set of credentials and 1 protocol= to configure for mail rather than 2) >>* simplified server administration (one firewall port to open) >>* reduced support burden for mail operators (no more "I can receive mail= fine, but I can't send" support queries) >>* reduced problems for clients, e.g. >> - ISP blocks port 25 (common) >> - debugging issues related to errors in any configuration item (since= these are halved). >> >>be abandoned? >> > > >All of these can be reduced to one question: > >* Why can't the client ask how to submit a message via SMTP protocol (via= whatever host:port)? > there's one more benefit I forgot. The simple issue of bandwidth etc (having to transmit the content using=20 SMTP, and also APPEND to outbox), especially when dealing with large=20 attachments, obviously was considered enough of an issue to propose=20 BURL. Sorry but BURL is hideous IMO. Requiring SMTP/submission server=20 vendors to write IMAP clients, solve inter-realm trust issues etc, when=20 compared to writing an SMTP submission agent (very simple) into an IMAP=20 server I guess that's why it remains enticing to simply allow=20 submission in IMAP itself... you have already established credentials,=20 you have the message, you can cheaply copy it to sent items, all you=20 need is cheap submission. The sorts of privacy / trust issues involved with mail submission are=20 entirely different to those involved in mail retrieval (which is what=20 an SMTP server needs to do to process BURL). This had all sorts of=20 knock-on effects relating to security / privacy of the SMTP transaction=20 to protected embedded IMAP credentials, or required some token-based=20 approach to avert this. Seems to me the solutions involved around the sanctioned approach to=20 solving this problem are worse than SUBMIT in IMAP. Adrien > > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext > > From ned.freed@mrochek.com Wed Aug 1 23:05:12 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 370B621F86E0 for ; Wed, 1 Aug 2012 23:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.501 X-Spam-Level: X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWhQmDWN1hJ6 for ; Wed, 1 Aug 2012 23:05:11 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7E52D21F8B99 for ; Wed, 1 Aug 2012 23:05:06 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIK0GC22UO006CL6@mauve.mrochek.com> for imapext@ietf.org; Wed, 1 Aug 2012 23:00:00 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Wed, 1 Aug 2012 22:59:57 -0700 (PDT) Message-id: <01OIK0GA2IYO0006TF@mauve.mrochek.com> Date: Wed, 01 Aug 2012 22:49:14 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 02 Aug 2012 00:30:35 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <01OI6KIY5A200006TF@mauve.mrochek.com> To: "Adrien W. de Croy" Cc: Arnt Gulbrandsen , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 06:05:12 -0000 > ------ Original Message ------ > From: "Ned Freed" > > > >P.S. And doing this stuff "right", for some value of "right", doesn't > >make > >submission facilities in IMAP a good idea. > I'm one of those who believes submission in IMAP is a great idea, long > overdue. > But obviously others think it's a bad idea. > I'm keen to make sure I didn't overlook something that would alter my > position on this. > So, my questions are: > 1. Why is submission in IMAP such a bad idea? > 2. Why should the benefits of: > * simplified client configuration (one set of credentials and 1 > protocol to configure for mail rather than 2) Actually, it's exactly the opposite - since for the forseeble future a significant number of servers won't suport such an extension, even assuming it deploys, clients still have to support SUBMIT, so this complicates configuration rather than simplifying it. Additionally, unless the extension is properly defined to support future SMTP extensions - and almost all of the proposals, including the present one, fail on this, you grot up the client with having to use different protocols in different cases. Extensive past experience argues strongly that addingc complexity of this sort is rarely if ever a good idea. > * simplified server administration (one firewall port to open) Wrong again, for the the opposite reason - clients suporting this are even less likely to deploy in a timely way, so you get rid of nothing. > * reduced support burden for mail operators (no more "I can receive > mail fine, but I can't send" support queries) This assumes the dominant reason mail can't be sent is because of a submission problem. My experience says otherwise. > * reduced problems for clients, e.g. > - ISP blocks port 25 (common) Problem already solved by SUBMIT. > - debugging issues related to errors in any configuration item > (since these are halved). More like multiplied. > be abandoned? See above. > Maybe there's a use-case where the badness doesn't apply, and maybe > that use-case is enough to justify submission in IMAP, and in other > cases it can be disabled - e.g. shouldn't it then just be a policy > issue for the operator of the server. The only advantage I can see here is for mobile clients, where the use of a single port and shared authentication has some advantages. But all of these advantages accrue from a much simpler approach of tunneling SUBMIT inside the IMAP session. This solves almsot all of the problems noted above and requires essentially no new protocol work. Ned From arnt@gulbrandsen.priv.no Thu Aug 2 01:50:21 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E8A21F8D41 for ; Thu, 2 Aug 2012 01:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWRrVrP3zKJ7 for ; Thu, 2 Aug 2012 01:50:21 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6687921F881D for ; Thu, 2 Aug 2012 01:50:10 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id B3BF3F8D3B8; Thu, 2 Aug 2012 08:50:08 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343897406-8717-8716/10/10; Thu, 2 Aug 2012 08:50:06 +0000 Message-Id: <501A3F4D.5030701@gulbrandsen.priv.no> Date: Thu, 2 Aug 2012 10:50:21 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 08:50:21 -0000 On 08/02/2012 02:51 AM, Lyndon Nerenberg wrote: > Given that we don't even have discovery for the mail reading part, it = shouldn't be that hard to come up with something that encapsulates*both* = reading and sending in a single simple service discovery mechanism. No? We do have an SRV-based mechanism to locate IMAP and Submit servers now.=20 Hardly anyone uses it, AFAIK because of the chicken and egg problem. We might add a way to ask the IMAP server about the Submit server, but I=20 don't see any advantage in that over the SRV approach. Arnt From arnt@gulbrandsen.priv.no Thu Aug 2 02:03:28 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EBA21F8E3B for ; Thu, 2 Aug 2012 02:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsswnJScvnRj for ; Thu, 2 Aug 2012 02:03:28 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A70521F8E01 for ; Thu, 2 Aug 2012 02:03:28 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 883DBF8DB36; Thu, 2 Aug 2012 09:03:27 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343898206-8717-8716/10/11; Thu, 2 Aug 2012 09:03:26 +0000 Message-Id: <501A426C.9060702@gulbrandsen.priv.no> Date: Thu, 2 Aug 2012 11:03:40 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <500C04B5.3030206@flaska.net> <500C140D.2010000@gulbrandsen.priv.no> <01OI6KIY5A200006TF@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 09:03:28 -0000 On 08/02/2012 02:30 AM, Adrien W. de Croy wrote: > But obviously others think it's a bad idea. It depends what the idea is. I think providing an exact duplicate of SMTP in IMAP is design and duplication, mandating code duplication, and not likely to have a good fate. Providing something else, with a stated set of use cases and no scope extension, might be a good idea. If sending this mail is _the_ use case I think it might be a good idea. Arnt From adrien@qbik.com Thu Aug 2 05:28:37 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426E221F8A79 for ; Thu, 2 Aug 2012 05:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=-1.629, BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI45fxvRNRIJ for ; Thu, 2 Aug 2012 05:28:36 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8A221F8A77 for ; Thu, 2 Aug 2012 05:28:36 -0700 (PDT) Received: From [192.168.1.25] (unverified [219.89.218.88]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.6 (Build 3449)) with SMTP id <0019171920@smtp.qbik.com>; Fri, 03 Aug 2012 00:28:34 +1200 From: "Adrien de Croy" To: "Ned Freed" Date: Thu, 02 Aug 2012 12:28:33 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <01OIK0GA2IYO0006TF@mauve.mrochek.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Arnt Gulbrandsen , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 12:28:37 -0000 ------ Original Message ------ From: "Ned Freed" > >>------ Original Message ------=20 >>From: "Ned Freed" =20 >>>=20 >>>P.S. And doing this stuff "right", for some value of "right",=20 >>doesn't=20 >>>make=20 >>>submission facilities in IMAP a good idea.=20 >>I'm one of those who believes submission in IMAP is a great idea,=20 >>long=20 >>overdue.=20 > >>But obviously others think it's a bad idea.=20 > >>I'm keen to make sure I didn't overlook something that would alter my=20 >>position on this.=20 > >>So, my questions are:=20 > >>1. Why is submission in IMAP such a bad idea?=20 > >>2. Why should the benefits of:=20 > >>* simplified client configuration (one set of credentials and 1=20 >>protocol to configure for mail rather than 2)=20 > >Actually, it's exactly the opposite - since for the forseeble future=20 >a significant number of servers won't suport such an extension, even=20 >assuming it deploys, clients still have to support SUBMIT, so this=20 >complicates configuration rather than simplifying it.=20 I agree it complicates the task for client authors, but I'm not certain=20 that this would necessarily affect end users. In the discovery phase of account creation, if the client started with=20 IMAP, and established that the server supported SUBMIT via IMAP, then=20 it could skip the SMTP / SUBMISSION setup phase, and hide the=20 associated configuration UI. This would therefore result in a simplification for the user=20 configuration. As for the task for the client author, in the scheme of things it's a=20 pretty simple spec and set of requirements. Compared to something like=20 QRESYNC / CONDSTORE it's a walk in the park. > > >Additionally, unless the extension is properly defined to support=20 >future SMTP=20 >extensions - and almost all of the proposals, including the present=20 >one, fail=20 >on this, you grot up the client with having to use different protocols=20 >in=20 >different cases. Extensive past experience argues strongly that=20 >addingc=20 >complexity of this sort is rarely if ever a good idea.=20 I'm struggling to think of a single ESMTP extension (apart from DSN)=20 that would be required to be used by the client for submission. Most ESMTP extensions I'm familiar with relate to things that are either a) already covered in the IMAP connection (e.g. authentication, TLS=20 negotiation etc) b) not applicable since transfer of the message is done by=20 APPEND/COPY/CATENATE (e.g. transfer encodings, chunking, resume etc) The one that stands out is DSN control, which was already envisaged by=20 the proposal. Or are you thinking of things like SRS etc? I wouldn't think those=20 were applicable for submission, but only transfer. > > >>* simplified server administration (one firewall port to open)=20 > >Wrong again, for the the opposite reason - clients suporting this=20 >are even less likely to deploy in a timely way, so you get rid of=20 >nothing.=20 I don't know about that either. Corporates tend to standardise on software for various reasons. It=20 would only take someone to write an Outlook connector to do this. Obviously there would be a certain amount of time required for uptake,=20 during which both systems would be required, but the interim would be=20 no worse for general usage. There's one more dimension added for=20 troubleshooting (e.g. how was the mail submitted), but I don't see that=20 as a big issue. > > >>* reduced support burden for mail operators (no more "I can receive=20 >>mail fine, but I can't send" support queries)=20 > >This assumes the dominant reason mail can't be sent is because of a=20 >submission=20 >problem. My experience says otherwise.=20 OK, I'm interested in your experience here, what are the main causes=20 you see? In fact our biggest cause is user error. > > >>* reduced problems for clients, e.g.=20 >> - ISP blocks port 25 (common)=20 > >Problem already solved by SUBMIT.=20 just another port. > > >> - debugging issues related to errors in any configuration item=20 >>(since these are halved).=20 > >More like multiplied.=20 Sure there's more debugging for submission problems, since you inserted=20 an option for submission, however in a well-designed system, it should=20 be simple to determine how a message was submitted. I'm mainly thinking corporate use here, rather than say ISP. ISP use=20 would be an entirely different scenario. Maybe the ISP would then=20 choose not to advertise SUBMIT in IMAP. They can judge the impact on=20 their own support-desk either way. > > >>be abandoned?=20 > >See above.=20 > >>Maybe there's a use-case where the badness doesn't apply, and maybe=20 >>that use-case is enough to justify submission in IMAP, and in other=20 >>cases it can be disabled - e.g. shouldn't it then just be a policy=20 >>issue for the operator of the server.=20 > >The only advantage I can see here is for mobile clients, where the use=20 >of a single port and shared authentication has some advantages.=20 I think also corporate email use would benefit a lot from this. That's=20 mainly who our customers are. I don't know what it would mean for=20 ISPs, although I understand they do generally field a bunch of support=20 about submission. Maybe that's improved. I'm sure others here have some interesting comments to make about that. >But=20 >all of these advantages accrue from a much simpler approach of=20 >tunneling=20 >SUBMIT inside the IMAP session. This solves almsot all of the problems=20 >noted above and requires essentially no new protocol work.=20 That could be an interesting approach, but I still think way more=20 complex to implement than a SUBMIT command in IMAP. Adrien > > > Ned=20 From adrien@qbik.com Thu Aug 2 05:30:05 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 217B021F8564 for ; Thu, 2 Aug 2012 05:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=-1.598, BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnOnOLOHve0J for ; Thu, 2 Aug 2012 05:30:04 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4B61321F8550 for ; Thu, 2 Aug 2012 05:30:04 -0700 (PDT) Received: From [192.168.1.25] (unverified [219.89.218.88]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.6 (Build 3449)) with SMTP id <0019171925@smtp.qbik.com>; Fri, 03 Aug 2012 00:30:02 +1200 From: "Adrien de Croy" To: "Arnt Gulbrandsen" , "imapext@ietf.org" Date: Thu, 02 Aug 2012 12:30:02 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <501A3F4D.5030701@gulbrandsen.priv.no> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 12:30:05 -0000 ------ Original Message ------ From: "Arnt Gulbrandsen" >On 08/02/2012 02:51 AM, Lyndon Nerenberg wrote:=20 >>Given that we don't even have discovery for the mail reading part, it=20 >>shouldn't be that hard to come up with something that=20 >>encapsulates*both* reading and sending in a single simple service=20 >>discovery mechanism. No?=20 > >We do have an SRV-based mechanism to locate IMAP and Submit servers=20 >now. Hardly anyone uses it, AFAIK because of the chicken and egg=20 >problem.=20 > >We might add a way to ask the IMAP server about the Submit server, but=20 >I don't see any advantage in that over the SRV approach.=20 It would have 1 advantage I can think of and that's the administrator=20 can configure it in the IMAP server, regardless of whether they run a=20 DNS server or have ready access to publish SRV records or not. Adrien > > >Arnt=20 > >_______________________________________________=20 >imapext mailing list=20 >imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext=20 From tss@iki.fi Thu Aug 2 05:55:16 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86AA721F873E for ; Thu, 2 Aug 2012 05:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.515 X-Spam-Level: X-Spam-Status: No, score=-110.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yGswhDyQ-tx for ; Thu, 2 Aug 2012 05:55:16 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id BFD8B21F873D for ; Thu, 2 Aug 2012 05:55:15 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 66EBD1AE8359; Thu, 2 Aug 2012 15:55:14 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Thu, 2 Aug 2012 15:55:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adrien de Croy X-Mailer: Apple Mail (2.1084) Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 12:55:16 -0000 On 2.8.2012, at 15.28, Adrien de Croy wrote: >> Additionally, unless the extension is properly defined to support = future SMTP extensions - and almost all of the proposals, including the = present one, fail on this, you grot up the client with having to use = different protocols in different cases. Extensive past experience argues = strongly that addingc complexity of this sort is rarely if ever a good = idea.=20 >=20 > I'm struggling to think of a single ESMTP extension (apart from DSN) = that would be required to be used by the client for submission. EAI in future maybe. From adrien@qbik.com Thu Aug 2 06:21:07 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4F621F85E1 for ; Thu, 2 Aug 2012 06:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.168 X-Spam-Level: X-Spam-Status: No, score=-3.168 tagged_above=-999 required=5 tests=[AWL=-1.569, BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qccdoup1hlGb for ; Thu, 2 Aug 2012 06:21:06 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id CA73921F85DD for ; Thu, 2 Aug 2012 06:21:05 -0700 (PDT) Received: From [192.168.1.25] (unverified [219.89.218.88]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.6 (Build 3449)) with SMTP id <0019171982@smtp.qbik.com>; Fri, 03 Aug 2012 01:21:02 +1200 From: "Adrien de Croy" To: "Timo Sirainen" Date: Thu, 02 Aug 2012 13:21:01 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 13:21:07 -0000 ------ Original Message ------ From: "Timo Sirainen" To: "Adrien de Croy" Cc: "imapext@ietf.org" Sent: 3/08/2012 12:55:14 a.m. Subject: Re: [imapext] Mail submission over IMAP >On 2.8.2012, at 15.28, Adrien de Croy wrote: > > >>> >>>Additionally, unless the extension is properly defined to support future= SMTP extensions - and almost all of the proposals, including the present= one, fail on this, you grot up the client with having to use different = protocols in different cases. Extensive past experience argues strongly = that addingc complexity of this sort is rarely if ever a good idea. >>> >> >> >>I'm struggling to think of a single ESMTP extension (apart from DSN) that= would be required to be used by the client for submission. >> > > >EAI in future maybe. > I presume you mean draft-ietf-eai-smtpext? I just skimmed it, I can see how that sort of extension would create=20 problems that's for sure. that I-D already has a bunch of problems, but who knows what likelihood=20 it has of being adopted. If you need to also provide an=20 ASCII-compatible email address alternative, the question "what's the=20 point" comes to mind. I also wonder why they allow options for=20 encoding of domain part. if SUBMIT over IMAP mandated support for internationalisable forward=20 and return path, the problem could be just pushed to the IMAP server. But that's only 1 I-D, I guess there may be others. The rot sets in. In any extensible system though, we have the choice how to move=20 forward. If someone defines a new SMTP extension, then a client needs=20 a server to implement it. =20 So we do come back to extending SUBMIT over IMAP to support those=20 submission extensions that require it. =20 It's hard to gauge how much real impact this would have. That EAI=20 draft is fairly special case in that it requires additional data from=20 the submitter. But any ESMTP extension is optional. Adrien > > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext > > From arnt@gulbrandsen.priv.no Thu Aug 2 06:28:25 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB56B21F867A for ; Thu, 2 Aug 2012 06:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztvTafpc9pI0 for ; Thu, 2 Aug 2012 06:28:25 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42ADE21F866C for ; Thu, 2 Aug 2012 06:28:25 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id B7CE5F8CA0B; Thu, 2 Aug 2012 13:28:24 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343914103-8717-8716/10/15; Thu, 2 Aug 2012 13:28:23 +0000 Message-Id: <501A8086.4020408@gulbrandsen.priv.no> Date: Thu, 2 Aug 2012 15:28:38 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 13:28:25 -0000 On 08/02/2012 03:21 PM, Adrien de Croy wrote: > that I-D already has a bunch of problems, but who knows what likelihood > it has of being adopted. Close to 100% according to what I've heard. CJKV users who damned well want the features and will live with the problems. Then the rest of us will have to choose whether we'll interoperate or not. Arnt From cyrus@daboo.name Thu Aug 2 07:32:09 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4561011E80AE for ; Thu, 2 Aug 2012 07:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqotqn2xH+zz for ; Thu, 2 Aug 2012 07:32:08 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id AC1FE11E80A6 for ; Thu, 2 Aug 2012 07:32:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 3A23A2D0DAC5; Thu, 2 Aug 2012 10:32:08 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3S_lCjbSccBG; Thu, 2 Aug 2012 10:32:07 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 5E3132D0DABA; Thu, 2 Aug 2012 10:32:06 -0400 (EDT) Date: Thu, 02 Aug 2012 10:32:02 -0400 From: Cyrus Daboo To: "Adrien W. de Croy" , Derek Diget , imapext@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1700 Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:32:09 -0000 Hi Adrien, --On August 2, 2012 1:21:40 AM +0000 "Adrien W. de Croy" wrote: >> RFC 6186 - Use of SRV Records for Locating Email Submission/Access >> Services (Not sure if there are any clients supporting this yet. :( >> > > DNS is a difficult answer to that question. Many organisations would > love to run a mail server without having to run a DNS server. Education > here is a cost as well, as people need to be educated to set up SRV > records etc. > > Providing an integrated solution for those that do run both (e.g. publish > necessary records to DNS from mail server) is also difficult, and adds > links in the chain which can cause support issues. There was some recent discussion about developing a service discovery protocol that would encapsulate not only email related services, but calendaring, contacts, im, directory, security etc - basically anything that a user needs to setup in the "Accounts" panel of their device. Folks at the calendaring and scheduling consortium (CalConnect) are very interested in this and we will have a draft with the basic idea out soon. The basic premise is an SRV record that points to an http server where a service discovery document can be retrieved and that document will contain all the necessary setup parameters for a device (or pointers/URLs to other config options). Whilst SRV will be present, it will not be mandatory in that the discovery document could reside at a .well-known URI at the top-level of the domain where accounts are being configured. There are lots of nitty-gritty details that would need to be worked out and we can leave that discussion for when the draft is out - soon. -- Cyrus Daboo From ned.freed@mrochek.com Thu Aug 2 07:35:47 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52CE11E80BF for ; Thu, 2 Aug 2012 07:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb4lNzr+Cpv4 for ; Thu, 2 Aug 2012 07:35:47 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCD211E80AE for ; Thu, 2 Aug 2012 07:35:47 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIKIAH21O0006GV0@mauve.mrochek.com> for imapext@ietf.org; Thu, 2 Aug 2012 07:30:40 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Thu, 2 Aug 2012 07:30:33 -0700 (PDT) Message-id: <01OIKIACF7AO0006TF@mauve.mrochek.com> Date: Thu, 02 Aug 2012 07:27:46 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 01 Aug 2012 17:51:06 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: Lyndon Nerenberg Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:35:48 -0000 > On 2012-08-01, at 17:42 PM, Timo Sirainen wrote: > > (via whatever host:port)? > Timo nails it. > All that is missing is resource discovery to find the SMTP submission server. RFC 6186? Ned From ned.freed@mrochek.com Thu Aug 2 07:35:48 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4771F11E80AE for ; Thu, 2 Aug 2012 07:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djq-VO1XHcxp for ; Thu, 2 Aug 2012 07:35:47 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id AE23111E80BA for ; Thu, 2 Aug 2012 07:35:47 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIKIEVN7WW006GV0@mauve.mrochek.com> for imapext@ietf.org; Thu, 2 Aug 2012 07:34:13 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Thu, 2 Aug 2012 07:34:09 -0700 (PDT) Message-id: <01OIKIET0FDI0006TF@mauve.mrochek.com> Date: Thu, 02 Aug 2012 07:31:40 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 01 Aug 2012 17:44:19 -0700" <59CADF8D-14A3-44E4-AA02-2D979C076E1D@orthanc.ca> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <59CADF8D-14A3-44E4-AA02-2D979C076E1D@orthanc.ca> To: Lyndon Nerenberg Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:35:48 -0000 > > I'm keen to make sure I didn't overlook something that would alter my > > position on this. > Ned, which WG is the right one for the 'mail submission via mail reading > protocols considered harmful' draft? Probably best to write a draft and take it to appaawg. These days most documents that don't really warrant a WG of their own are processed there. OTOH, if a WG is deemed necessary, that's the place to start the process of chartering it. > That document needs to be written. Soon. There is a lot of history that must > be codified and condensed to prevent future futility ... Agreed. IMO the only proposal that even comes close to making the cut would be a pure tunneling scheme, and even then I remain to be convinced it is worth it. Ned From cyrus@daboo.name Thu Aug 2 07:36:52 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F272011E80E7 for ; Thu, 2 Aug 2012 07:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dz6lRgUwWO+o for ; Thu, 2 Aug 2012 07:36:51 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 65F5411E80E6 for ; Thu, 2 Aug 2012 07:36:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id F03B82D0DBEA; Thu, 2 Aug 2012 10:36:50 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaQx77SljrvT; Thu, 2 Aug 2012 10:36:50 -0400 (EDT) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id F1DD52D0DBDF; Thu, 2 Aug 2012 10:36:48 -0400 (EDT) Date: Thu, 02 Aug 2012 10:36:46 -0400 From: Cyrus Daboo To: Ned Freed , "Adrien W. de Croy" Message-ID: In-Reply-To: <01OIK0GA2IYO0006TF@mauve.mrochek.com> References: <01OI6KIY5A200006TF@mauve.mrochek.com> <01OIK0GA2IYO0006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1241 Cc: Arnt Gulbrandsen , imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:36:52 -0000 Hi Ned, --On August 1, 2012 10:49:14 PM -0700 Ned Freed wrote: >> Maybe there's a use-case where the badness doesn't apply, and maybe >> that use-case is enough to justify submission in IMAP, and in other >> cases it can be disabled - e.g. shouldn't it then just be a policy >> issue for the operator of the server. > > The only advantage I can see here is for mobile clients, where the use > of a single port and shared authentication has some advantages. But > all of these advantages accrue from a much simpler approach of tunneling > SUBMIT inside the IMAP session. This solves almsot all of the problems > noted above and requires essentially no new protocol work. I think that is absolutely the right approach if only one port can be used (in particular on the basis that SMTP is going to exist no matter what and clients are still going to have to do SMTP-over-587 for various services no matter what). It would need to be somewhat smarter than just doing plain SMTP - e.g. there ought to be a way to pass a reference to an existing IMAP message to be used as the DATA or from which the basic FROM/RCPT TO can be extracted. But beyond that, it ought to look and feel just like SMTP. -- Cyrus Daboo From ned.freed@mrochek.com Thu Aug 2 11:30:51 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C7711E8229 for ; Thu, 2 Aug 2012 11:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pb2AGnHb4Ec6 for ; Thu, 2 Aug 2012 11:30:50 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C68D111E8209 for ; Thu, 2 Aug 2012 11:30:49 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIKQHVW4680059OZ@mauve.mrochek.com> for imapext@ietf.org; Thu, 2 Aug 2012 11:25:43 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Thu, 2 Aug 2012 11:25:37 -0700 (PDT) Message-id: <01OIKQHRTLOU0006TF@mauve.mrochek.com> Date: Thu, 02 Aug 2012 10:54:20 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 02 Aug 2012 12:28:33 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <01OIK0GA2IYO0006TF@mauve.mrochek.com> To: Adrien de Croy Cc: Arnt Gulbrandsen , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 18:30:51 -0000 > ------ Original Message ------ > From: "Ned Freed" > > > >>------ Original Message ------ > >>From: "Ned Freed" > >>> > >>>P.S. And doing this stuff "right", for some value of "right", > >>doesn't > >>>make > >>>submission facilities in IMAP a good idea. > >>I'm one of those who believes submission in IMAP is a great idea, > >>long > >>overdue. > > > >>But obviously others think it's a bad idea. > > > >>I'm keen to make sure I didn't overlook something that would alter my > >>position on this. > > > >>So, my questions are: > > > >>1. Why is submission in IMAP such a bad idea? > > > >>2. Why should the benefits of: > > > >>* simplified client configuration (one set of credentials and 1 > >>protocol to configure for mail rather than 2) > > > >Actually, it's exactly the opposite - since for the forseeble future > >a significant number of servers won't suport such an extension, even > >assuming it deploys, clients still have to support SUBMIT, so this > >complicates configuration rather than simplifying it. > I agree it complicates the task for client authors, but I'm not certain > that this would necessarily affect end users. You have a lot of faith in client authors. Faith which appears to me to be supported by evidence of past behavior. > In the discovery phase of account creation, if the client started with > IMAP, and established that the server supported SUBMIT via IMAP, then > it could skip the SMTP / SUBMISSION setup phase, and hide the > associated configuration UI. Discovery phases are inherently problematic because they assume the server is available at the time of account creation. Moreover, the setup phase you seem so concerned about can simply default to same set of credentials, which is certainly the norm. > This would therefore result in a simplification for the user > configuration. I'm far from convinced of that. > As for the task for the client author, in the scheme of things it's a > pretty simple spec and set of requirements. Compared to something like > QRESYNC / CONDSTORE it's a walk in the park. > > > > > >Additionally, unless the extension is properly defined to support > >future SMTP > >extensions - and almost all of the proposals, including the present > >one, fail > >on this, you grot up the client with having to use different protocols > >in > >different cases. Extensive past experience argues strongly that > >addingc > >complexity of this sort is rarely if ever a good idea. > I'm struggling to think of a single ESMTP extension (apart from DSN) > that would be required to be used by the client for submission. 8BITMIME. BINARY. SIZE. ENHANCEDSTATUSCODES. FUTURERELEASE. DELIVERBY. MT-PRIORITY. CHUNKING. PIPELINING. MTRK. None of these are *required*, but for that matter neither is DSN. But all of can be quite useful to clients, and with the exception of MT-PRIORITY (too new) are used by various clients when they are available. And perhaps more to the point, who can say what extensions will be defined in the future, and for what purpose? MT-PRIORITY is about to be published as an RFC. > Most ESMTP extensions I'm familiar with relate to things that are either > a) already covered in the IMAP connection (e.g. authentication, TLS > negotiation etc) AFAICT the only ones you "cover" are 8BITMIME, BINARY, CHUNKING, PIPELINING, and perhaps ENHANCEDSTATUSCODES. > b) not applicable since transfer of the message is done by > APPEND/COPY/CATENATE (e.g. transfer encodings, chunking, resume etc) Your experience appears to be extremely narrow and limited then. > The one that stands out is DSN control, which was already envisaged by > the proposal. On the contrary, it doesn't stand out at all in SUBMIT. (Relay is another matter.) > Or are you thinking of things like SRS etc? I wouldn't think those > were applicable for submission, but only transfer. If you're talking about post-SRS, that's not a standardized, nor reasonable, SMTP extension. > > > > > >>* simplified server administration (one firewall port to open) > > > >Wrong again, for the the opposite reason - clients suporting this > >are even less likely to deploy in a timely way, so you get rid of > >nothing. > I don't know about that either. You might want to look at statistics for typical mixes of clients seen by servers then, with an eye to how many old versions are in use. > Corporates tend to standardise on software for various reasons. It > would only take someone to write an Outlook connector to do this. Even if that were true - and I am highly skeptical it is - it in no way makes a case for standarizing something. > Obviously there would be a certain amount of time required for uptake, > during which both systems would be required, but the interim would be > no worse for general usage. There's one more dimension added for > troubleshooting (e.g. how was the mail submitted), but I don't see that > as a big issue. > > > > > >>* reduced support burden for mail operators (no more "I can receive > >>mail fine, but I can't send" support queries) > > > >This assumes the dominant reason mail can't be sent is because of a > >submission > >problem. My experience says otherwise. > OK, I'm interested in your experience here, what are the main causes > you see? Main cause is probably credential issues of some sort. But of the issues that have to be esclated and which therefore cost the most to address, broken filtering and bad MIME top the list. In other words, the top complaint after they're able to connect to their mailbox isn't, "Why can't I send mail?", it's "Why didn't the recipient get what I sent?" and "Why was what they got a pile of garbage?" > In fact our biggest cause is user error. Yes, but that doesn't mean the error is problems filling in the name of the SUBMIT server. > > > > > >>* reduced problems for clients, e.g. > >> - ISP blocks port 25 (common) > > > >Problem already solved by SUBMIT. > just another port. The point is it is a *different* port. ISPs specifically block port 25, and for good reason. They don't block the SUBMIT port, again for good reason. > > > > > >> - debugging issues related to errors in any configuration item > >>(since these are halved). > > > >More like multiplied. > Sure there's more debugging for submission problems, since you inserted > an option for submission, however in a well-designed system, it should > be simple to determine how a message was submitted. Not when the problem only turns up after it was received. (Please tell me you're not counting on being able to see Received: fields.) > I'm mainly thinking corporate use here, rather than say ISP. ISP use > would be an entirely different scenario. Maybe the ISP would then > choose not to advertise SUBMIT in IMAP. They can judge the impact on > their own support-desk either way. The corporations you appear to be envisioning are a lot more homogenous than I think it is is reasonable to assume. > > > > > >>be abandoned? > > > >See above. > > > >>Maybe there's a use-case where the badness doesn't apply, and maybe > >>that use-case is enough to justify submission in IMAP, and in other > >>cases it can be disabled - e.g. shouldn't it then just be a policy > >>issue for the operator of the server. > > > >The only advantage I can see here is for mobile clients, where the use > >of a single port and shared authentication has some advantages. > I think also corporate email use would benefit a lot from this. That's > mainly who our customers are. I don't know what it would mean for > ISPs, although I understand they do generally field a bunch of support > about submission. Maybe that's improved. > I'm sure others here have some interesting comments to make about that. > >But > >all of these advantages accrue from a much simpler approach of > >tunneling > >SUBMIT inside the IMAP session. This solves almsot all of the problems > >noted above and requires essentially no new protocol work. > That could be an interesting approach, but I still think way more > complex to implement than a SUBMIT command in IMAP. Actually, it's far simpler and provides much more flexibility. I rather suspect I could implement it in a couple of hours, whereas a properly designed submit extension would take far longer and require far more testing and QA. The only part that's in any way tricky is the handling of disconnects. Ned From arnt@gulbrandsen.priv.no Thu Aug 2 13:29:23 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0633911E808E for ; Thu, 2 Aug 2012 13:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jugcGHzSu98Q for ; Thu, 2 Aug 2012 13:29:22 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 73B0C11E8087 for ; Thu, 2 Aug 2012 13:29:22 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 092F3F8C96F; Thu, 2 Aug 2012 20:29:21 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343939360-8717-8716/10/18; Thu, 2 Aug 2012 20:29:20 +0000 Message-Id: <501AE32F.90903@gulbrandsen.priv.no> Date: Thu, 2 Aug 2012 22:29:35 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <01OIK0GA2IYO0006TF@mauve.mrochek.com> <01OIKQHRTLOU0006TF@mauve.mrochek.com> In-Reply-To: <01OIKQHRTLOU0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 20:29:23 -0000 Ned answers Adrien: >> I agree it complicates the task for client authors, but I'm not certain >> that this would necessarily affect end users. > > You have a lot of faith in client authors. Faith which appears to me to > be supported by evidence of past behavior. At least we can have faith that the proposal will reappear. Imap move is progressing nicely. I think we can last call it in a week or two. That draft exists because people keep asking for it, and at some point it's better to just do a reasonable job of an extension than to keep repeating no no no and you should be doing that not this. It's quite clear that clients will have to continue supporting copy/store/expunge, but still, move is wanted. Imap submit hasn't had quite the level of requests that imap move has had. But the same argument does apply, correspondingly weaker. The argument about broken packet filters does, too. And clients _have_ been good about supporting some simple extensions. 4978 quite shocked me. Personally I like 6186 very much. Personally. Arnt From adrien@qbik.com Thu Aug 2 14:03:18 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B3121E80A5 for ; Thu, 2 Aug 2012 14:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.139 X-Spam-Level: X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vc7JHCEPOCIt for ; Thu, 2 Aug 2012 14:03:17 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 9437F21E80A1 for ; Thu, 2 Aug 2012 14:03:13 -0700 (PDT) Received: From [192.168.1.25] (unverified [219.89.218.88]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.6 (Build 3449)) with SMTP id <0019172667@smtp.qbik.com>; Fri, 03 Aug 2012 09:03:10 +1200 From: "Adrien de Croy" To: "Arnt Gulbrandsen" , "imapext@ietf.org" Date: Thu, 02 Aug 2012 21:03:07 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <501AE32F.90903@gulbrandsen.priv.no> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:03:18 -0000 =EF=BB=BF ------ Original Message ------ From: "Arnt Gulbrandsen" >Ned answers Adrien:=20 >>>I agree it complicates the task for client authors, but I'm not=20 >>>certain=20 >>>that this would necessarily affect end users.=20 >> >>You have a lot of faith in client authors. Faith which appears to me=20 >>to=20 >>be supported by evidence of past behavior.=20 > >At least we can have faith that the proposal will reappear.=20 I think so > > >Imap move is progressing nicely. I think we can last call it in a week=20 >or two. That draft exists because people keep asking for it, and at=20 >some point it's better to just do a reasonable job of an extension=20 >than to keep repeating no no no and you should be doing that not this.=20 >It's quite clear that clients will have to continue supporting=20 >copy/store/expunge, but still, move is wanted.=20 and used. > >Imap submit hasn't had quite the level of requests that imap move has=20 >had. But the same argument does apply, correspondingly weaker. The=20 >argument about broken packet filters does, too. And clients _have_=20 >been good about supporting some simple extensions. 4978 quite shocked=20 >me.=20 4978 is fantastic for us, especially for mobile or other remote=20 clients. IMAP esp S->C is _highly_ redundant/compressible. We get=20 over 80% reduction in most connections. On a capped paid $/MB 3G=20 connection it's a life saver, and also speeds things up for the client=20 quite a bit. > > >Personally I like 6186 very much. Personally.=20 I am a big fan of discovery, but we need to learn from things like the=20 WPAD fiasco (DNS or DHCP to resolve a configuration URL). Any time you introduce another step to intialisation, it's a point of=20 failure. With WPAD, you get issues like being unable to retrieve the=20 WPAD.dat file, or it's syntactically incorrect, or DHCP option 252=20 wasn't there, or specified correctly, or the name in the specified URL=20 wasn't resolvable etc etc etc etc etc. There are a lot of things to=20 get right in order to get WPAD working. Adrien > > >Arnt=20 > >_______________________________________________=20 >imapext mailing list=20 >imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext=20 From adrien@qbik.com Thu Aug 2 14:27:09 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A4711E814B for ; Thu, 2 Aug 2012 14:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.112 X-Spam-Level: X-Spam-Status: No, score=-3.112 tagged_above=-999 required=5 tests=[AWL=-1.513, BAYES_00=-2.599, SUBJ_RE_NUM=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLuT1-y5FBNm for ; Thu, 2 Aug 2012 14:27:08 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2F09711E80FD for ; Thu, 2 Aug 2012 14:27:05 -0700 (PDT) Received: From [192.168.1.25] (unverified [219.89.218.88]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.6 (Build 3449)) with SMTP id <0019172714@smtp.qbik.com>; Fri, 03 Aug 2012 09:27:03 +1200 From: "Adrien de Croy" To: "Ned Freed" Date: Thu, 02 Aug 2012 21:26:59 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <01OIKQHRTLOU0006TF@mauve.mrochek.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Ned Freed , Arnt Gulbrandsen , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:27:09 -0000 =EF=BB=BF ------ Original Message ------ From: "Ned Freed" > >>------ Original Message ------=20 >>From: "Ned Freed" =20 >>>=20 >>>>------ Original Message ------=20 >>>>From: "Ned Freed" =20 >>>>>=20 >>>>>P.S. And doing this stuff "right", for some value of "right",=20 >>>>doesn't=20 >>>>>make=20 >>>>>submission facilities in IMAP a good idea.=20 >>>>I'm one of those who believes submission in IMAP is a great idea,=20 >>>>long=20 >>>>overdue.=20 >>>=20 >>>>But obviously others think it's a bad idea.=20 >>>=20 >>>>I'm keen to make sure I didn't overlook something that would alter=20 >>my=20 >>>>position on this.=20 >>>=20 >>>>So, my questions are:=20 >>>=20 >>>>1. Why is submission in IMAP such a bad idea?=20 >>>=20 >>>>2. Why should the benefits of:=20 >>>=20 >>>>* simplified client configuration (one set of credentials and 1=20 >>>>protocol to configure for mail rather than 2)=20 >>>=20 >>>Actually, it's exactly the opposite - since for the forseeble future=20 >>>a significant number of servers won't suport such an extension, even=20 >>>assuming it deploys, clients still have to support SUBMIT, so this=20 >>>complicates configuration rather than simplifying it.=20 > >>I agree it complicates the task for client authors, but I'm not=20 >>certain=20 >>that this would necessarily affect end users.=20 > >You have a lot of faith in client authors. Faith which appears to me=20 >to=20 >be supported by evidence of past behavior.=20 I guess you mean unsupported. I don't disagree, but remain optimistic. > > >>In the discovery phase of account creation, if the client started=20 >>with=20 >>IMAP, and established that the server supported SUBMIT via IMAP, then=20 >>it could skip the SMTP / SUBMISSION setup phase, and hide the=20 >>associated configuration UI.=20 > >Discovery phases are inherently problematic because they assume the=20 >server is available at the time of account creation.=20 definitely, and I've had big arguments with TB devs about this. As long as the discovery process allows not-too-painful fallback to=20 manual configuration, and the number of configuration data points can=20 be minimised, that's about the best we can do. >>I'm struggling to think of a single ESMTP extension (apart from DSN)=20 >>that would be required to be used by the client for submission.=20 > >8BITMIME. BINARY. SIZE. ENHANCEDSTATUSCODES. FUTURERELEASE. DELIVERBY.=20 >MT-PRIORITY. CHUNKING. PIPELINING. MTRK.=20 > >None of these are *required*, but for that matter neither is DSN. But=20 >all of=20 >can be quite useful to clients, and with the exception of MT-PRIORITY=20 >(too new)=20 >are used by various clients when they are available.=20 Many extensions would become the responsibility of the IMAP server=20 acting as a submission client on behalf. It would need to do the same=20 thing its MTA needs to do anyway, connect, evaluate capabilities etc=20 etc. I see things like deliverby, and futurerelease being something that=20 should be under client control though. Anything that requires decisions / data from the client on a=20 per-message basis would need to be supplied at the time that submission=20 is initiated (either by SUBMIT within IMAP, or something else). > > >And perhaps more to the point, who can say what extensions will be=20 >defined in=20 >the future, and for what purpose? MT-PRIORITY is about to be published=20 >as an=20 >RFC.=20 Sure, hence my comment about rot setting in in my later email. > > >>Most ESMTP extensions I'm familiar with relate to things that are=20 >>either=20 > >>a) already covered in the IMAP connection (e.g. authentication, TLS=20 >>negotiation etc)=20 > >AFAICT the only ones you "cover" are 8BITMIME, BINARY, CHUNKING,=20 >PIPELINING,=20 >and perhaps ENHANCEDSTATUSCODES.=20 > >>b) not applicable since transfer of the message is done by=20 >>APPEND/COPY/CATENATE (e.g. transfer encodings, chunking, resume etc)=20 > >Your experience appears to be extremely narrow and limited then.=20 Anything is possible. =20 I'm still keen to solve double-transmission. in order to do that, the=20 message that has already been composed (e.g. in Drafts or Outbox or=20 whatever, by way of CATENATE, COPY whatever) needs to be able to be=20 submitted for delivery on behalf of the client, without requiring the=20 client to retrieve it, and retransmit it to a submission server. > > >>The one that stands out is DSN control, which was already envisaged=20 >>by=20 >>the proposal.=20 > >On the contrary, it doesn't stand out at all in SUBMIT. (Relay is=20 >another=20 >matter.)=20 > >>Or are you thinking of things like SRS etc? I wouldn't think those=20 >>were applicable for submission, but only transfer.=20 > >If you're talking about post-SRS, that's not a standardized, nor=20 >reasonable,=20 >SMTP extension.=20 sure, I agree with you, it's a nightmare. > > >>>=20 >>>=20 >>>>* simplified server administration (one firewall port to open)=20 >>>=20 >>>Wrong again, for the the opposite reason - clients suporting this=20 >>>are even less likely to deploy in a timely way, so you get rid of=20 >>>nothing.=20 > >>I don't know about that either.=20 > >You might want to look at statistics for typical mixes of clients seen=20 >by servers then, with an eye to how many old versions are in use.=20 most of our customers (and admittedly I'm talking a fairly restricted=20 use case) are using 1 or more of=20 outlook or outlook express or Thunderbird and/or IOS mail client We really don't see significant use of other clients. But this is not=20 rigorous or general by any means. > > >>Corporates tend to standardise on software for various reasons. It=20 >>would only take someone to write an Outlook connector to do this.=20 > >Even if that were true - and I am highly skeptical it is - it in no=20 >way makes a=20 >case for standarizing something.=20 IMO a case for standardisation of something is made in order to enable=20 interoperability when a significant (whatever that is) number of people=20 are affected. So if MS decided to put such a thing into Exchange, and Outlook, and=20 published a spec for it, I think you'd find it got adopted. > > >>Obviously there would be a certain amount of time required for=20 >>uptake,=20 >>during which both systems would be required, but the interim would be=20 >>no worse for general usage. There's one more dimension added for=20 >>troubleshooting (e.g. how was the mail submitted), but I don't see=20 >>that=20 >>as a big issue.=20 >>>=20 >>>=20 >>>>* reduced support burden for mail operators (no more "I can receive=20 >>>>mail fine, but I can't send" support queries)=20 >>>=20 >>>This assumes the dominant reason mail can't be sent is because of a=20 >>>submission=20 >>>problem. My experience says otherwise.=20 >>OK, I'm interested in your experience here, what are the main causes=20 >>you see?=20 > >Main cause is probably credential issues of some sort. But of the=20 >issues that=20 >have to be esclated and which therefore cost the most to address,=20 >broken=20 >filtering and bad MIME top the list. In other words, the top complaint=20 >after=20 >they're able to connect to their mailbox isn't, "Why can't I send=20 >mail?", it's=20 >"Why didn't the recipient get what I sent?" and "Why was what they got=20 >a pile=20 >of garbage?"=20 that's not generally something we can address by anything IMAP-related. > > >>In fact our biggest cause is user error.=20 > >Yes, but that doesn't mean the error is problems filling in the name=20 >of the=20 >SUBMIT server.=20 often entering of credentials is the problem. But there definitely are=20 problems discovering usable submission services. > > >>>=20 >>>=20 >>>>* reduced problems for clients, e.g.=20 >>>> - ISP blocks port 25 (common)=20 >>>=20 >>>Problem already solved by SUBMIT.=20 > >>just another port.=20 > >The point is it is a *different* port. ISPs specifically block port=20 >25, and for=20 >good reason. They don't block the SUBMIT port, again for good reason.=20 I don't disagree. I guess my point was that any time you introduce a=20 requirement to make another TCP connection you have potential issues=20 relating to name resolution, local (client-side) firewalls, routing (if=20 it's a different IP), credential establishment etc etc etc. > > >>>=20 >>>=20 >>>> - debugging issues related to errors in any configuration item=20 >>>>(since these are halved).=20 >>>=20 >>>More like multiplied.=20 > >>Sure there's more debugging for submission problems, since you=20 >>inserted=20 >>an option for submission, however in a well-designed system, it=20 >>should=20 >>be simple to determine how a message was submitted.=20 > >Not when the problem only turns up after it was received. (Please tell=20 >me=20 >you're not counting on being able to see Received: fields.)=20 hell no. Mostly server logs. It depends on the realm of authority of=20 the problem location (e.g. whether you can even get server logs). > > >>I'm mainly thinking corporate use here, rather than say ISP. ISP use=20 >>would be an entirely different scenario. Maybe the ISP would then=20 >>choose not to advertise SUBMIT in IMAP. They can judge the impact on=20 >>their own support-desk either way.=20 > >The corporations you appear to be envisioning are a lot more=20 >homogenous=20 >than I think it is is reasonable to assume.=20 We mainly deal with SMBs, so maybe they are skewed that way. > > >>>But=20 >>>all of these advantages accrue from a much simpler approach of=20 >>>tunneling=20 >>>SUBMIT inside the IMAP session. This solves almsot all of the=20 >>problems=20 >>>noted above and requires essentially no new protocol work.=20 > >>That could be an interesting approach, but I still think way more=20 >>complex to implement than a SUBMIT command in IMAP.=20 > >Actually, it's far simpler and provides much more flexibility. I=20 >rather suspect=20 >I could implement it in a couple of hours, whereas a properly designed=20 >submit=20 >extension would take far longer and require far more testing and QA.=20 >The only=20 >part that's in any way tricky is the handling of disconnects.=20 I did think a bit about this before I replied. Any time the submission service is a different physical process to the=20 IMAP service, you have a problem of transmission of credentials. This=20 would require the client to tunnel auth through the IMAP server to the=20 submission server, and therefore require configuration for submission=20 credentials. So that problem remains. You could mandate the same=20 creds be used, but that would probably cause problems, or at best place=20 limitations on how submission and IMAP are deployed (must be in same=20 auth realm). Maybe that's not so bad. I don't know how you'd avoid re-transmission of the message from the=20 client though, unless the IMAP server proxied the tunneled SMTP, and=20 inspected the protocol and you had a BURL-like extension that could=20 access the message content. At least in this case, you wouldn't have=20 inter-domain trust issues with a submit server trying to retrieve an=20 IMAP message for submission. The only thing this really would solve is the TCP port access. Proxying SMTP over IMAP begs the question "why?", and "why not proxy=20 everything through some simpler protocol that does the auth/security=20 leg-work?". E.g. CONNECT over HTTP. I think there was an RFC for=20 something that abstracted establishment of creds, security etc before=20 passing over to a service. Does SSH do this? Adrien > > > Ned=20 >_______________________________________________=20 >imapext mailing list=20 >imapext@ietf.org=20 >https://www.ietf.org/mailman/listinfo/imapext=20 From blong@google.com Thu Aug 2 14:56:30 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8F821E80B0 for ; Thu, 2 Aug 2012 14:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.67 X-Spam-Level: X-Spam-Status: No, score=-102.67 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQtesa9bSkJ6 for ; Thu, 2 Aug 2012 14:56:29 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4437E11E814B for ; Thu, 2 Aug 2012 14:56:29 -0700 (PDT) Received: by ghbg16 with SMTP id g16so27328ghb.31 for ; Thu, 02 Aug 2012 14:56:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=ImQ6QxtnPIfDv2x+FEXaw0fGOYpZnEDtG2bFRajvKTw=; b=mFkbJe3v1PlCpw3D27Uwo84QYcTe2E/GWMfMqjPPc0FSqQUtttAbmqZlC7CR4XKpMP 2ZMFl+F3eS1KK7CwTsbfUCsdtiR8hCt9ma1j4eknMRojrIktI4FpQuoJ1jZ8nXz2oYPW NzaEW+ccXvQo729GPie7hxH2Ryv3JKwACu1pTbdMRsKtHi1YkpFYZt/qWefW6kEFWYcK JEXwzPULwVLE0r/IGymsF4BAVPRbfRNW7ocLYMF0SpGWIUjdVzwcalnpZNUzNsc1se9d mnHhsssiHFgec1jZk4QSbAZQBBtjkZK/7FJy+GPfHPrDTUMWz/VhFMoIRnV5Gm0wfuZx K/Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=ImQ6QxtnPIfDv2x+FEXaw0fGOYpZnEDtG2bFRajvKTw=; b=ib5FIRRfG2iOmXaEGUWevcRjE3L0a7qucwwVM0VdDwyYEclF9mExryNqGSv9NqV333 hprVDFgD6+RxBIsvtaDIWEJRoeki4WnQDJsznS1uLgJGOblJ8/wakoQRy+iX4ZIHu+4r LqBjImVRLFcdUJob5DgYmKvGUVLBN2dAdY0pe7z/Z0JNt/WA23k7JH07LAAYdPf36WJf f38s23AkDbLGpNSPWCgaT1xy36/lD2sWk9zhN64KYrAJn4uxBlKTnY2yEQySf16buVKf SkHWqIejIz0gDT0EmB9lk1v34fzjsfB1onsZn/qNIGKNezI5eQUUR7AxvV1xzx3XXw44 MAHA== Received: by 10.60.169.100 with SMTP id ad4mr10277501oec.21.1343944588667; Thu, 02 Aug 2012 14:56:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.169.100 with SMTP id ad4mr10277486oec.21.1343944588541; Thu, 02 Aug 2012 14:56:28 -0700 (PDT) Received: by 10.76.6.209 with HTTP; Thu, 2 Aug 2012 14:56:28 -0700 (PDT) Date: Thu, 2 Aug 2012 14:56:28 -0700 Message-ID: From: Brandon Long To: Adrien de Croy Content-Type: multipart/alternative; boundary=bcaec517a4c0cc3f3f04c64f7be3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkgjp9RyUaD+TVipi7RPdOzoNt2CTUYKUL+k61Tq27RLINhQIJQ7rQClsf2nBOb9dtT+3qUot/KQyb9T8NRTWzgXFWKu6awuU8/2QHcSqIDf4DpGfXumJW7hLvrA8q7sgEqkhthqqlUwoVQMcmtJozBMLQiwcpbG9NUIqcphVHQ6baMknYt2bqJGV/zhveaQATWQyHK Cc: Arnt Gulbrandsen , Ned Freed , "imapext@ietf.org" Subject: [imapext] IMAP clients X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 21:56:30 -0000 --bcaec517a4c0cc3f3f04c64f7be3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 2, 2012 at 2:26 PM, Adrien de Croy wrote: > > ------ Original Message ------ > From: "Ned Freed" > >> You might want to look at statistics for typical mixes of clients seen by >> servers then, with an eye to how many old versions are in use. >> > most of our customers (and admittedly I'm talking a fairly restricted use > case) are using 1 or more of > outlook or outlook express or Thunderbird > and/or IOS mail client > > We really don't see significant use of other clients. But this is not > rigorous or general by any means. We try to keep track of what clients are using our IMAP service. If you're willing to log all FETCH requests, its not that hard to at least bucket by client (yeah for a protocol so general that every client implements it differently). Doesn't help overly much with versions, though. We've been trying to encourage client authors we deal with to use the ID extension so we can do a better job of understanding when things break, but obviously that's mostly new clients (iOS, Android Email, WinPhone, Apple Mail and I think Thunderbird now all report with ID). Obviously our list of clients is skewed compared to what most servers probably see, but most of our usage is mobile clients, followed by the most popular desktop clients (in order), Apple Mail, Thunderbird, Outlook, Outlook Express... then much further down we have Pine, Pegasus Mail, and Opera. But agreed, with the top 4 mobile (iOS, Android Email, WinPhone and Blackberry/BIS (not sure if they speak IMAP to anyone but Gmail, though)) plus Apple Mail, Thunderbird, Outlook and Outlook Express, you're probably talking about the top 99% of all IMAP clients. I'm happy to share the FETCH matches we do for about 25 clients. Its not exact, and probably unnecessary since most of those are just in the noise. Brandon --bcaec517a4c0cc3f3f04c64f7be3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Aug 2, 20= 12 at 2:26 PM, Adrien de Croy <adrien@qbik.com> wrote:

------ Original Message ------
From: "Ned Freed" <ned.freed@mrochek.com>
You might want to look at statistics for typical mixes of clients seen by s= ervers then, with an eye to how many old versions are in use.
most of our customers (and admittedly I'm talking a fairly restricted u= se case) are using 1 or more of
outlook or outlook express or Thunderbird
and/or IOS mail client

We really don't see significant use of other clients. =A0But this is no= t rigorous or general by any means.

We try = to keep track of what clients are using our IMAP service. =A0If you're = willing to log all FETCH requests, its not that hard to at least bucket by = client (yeah for a protocol so general that every client implements it diff= erently).

Doesn't help overly much with versions, though. =A0= We've been trying to encourage client authors we deal with to use the I= D extension so we can do a better job of understanding when things break, b= ut obviously that's mostly new clients (iOS, Android Email, WinPhone, A= pple Mail and I think Thunderbird now all report with ID).

Obviously our list of clients is skewed compared to wha= t most servers probably see, but most of our usage is mobile clients, follo= wed by the most popular desktop clients (in order), Apple Mail, Thunderbird= , Outlook, Outlook Express... then much further down we have Pine, Pegasus = Mail, and Opera.

But agreed, with the top 4 mobile (iOS, Android Email, = WinPhone and Blackberry/BIS (not sure if they speak IMAP to anyone but Gmai= l, though)) plus Apple Mail, Thunderbird, Outlook and Outlook Express, you&= #39;re probably talking about the top 99% of all IMAP clients.

I'm happy to share the FETCH matches we do for abou= t 25 clients. =A0Its not exact, and probably unnecessary since most of thos= e are just in the noise.

Brandon
--bcaec517a4c0cc3f3f04c64f7be3-- From tss@iki.fi Thu Aug 2 15:04:16 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485D621E80C9 for ; Thu, 2 Aug 2012 15:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.519 X-Spam-Level: X-Spam-Status: No, score=-110.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0XDlzBuCyFP for ; Thu, 2 Aug 2012 15:04:15 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 92FA421E80C7 for ; Thu, 2 Aug 2012 15:04:15 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 2F5751AE8359; Fri, 3 Aug 2012 01:04:14 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Fri, 3 Aug 2012 01:04:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <81FFA4ED-CA53-406D-BE99-CFA2D9A375E0@iki.fi> References: To: Brandon Long X-Mailer: Apple Mail (2.1084) Cc: imapext@ietf.org Subject: Re: [imapext] IMAP clients X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:04:16 -0000 On 3.8.2012, at 0.56, Brandon Long wrote: > Obviously our list of clients is skewed compared to what most servers = probably see, but most of our usage is mobile clients, followed by the = most popular desktop clients (in order), Apple Mail, Thunderbird, = Outlook, Outlook Express... then much further down we have Pine, Pegasus = Mail, and Opera. I'd be interested in percentages also if those aren't a secret. :) > But agreed, with the top 4 mobile (iOS, Android Email, WinPhone and = Blackberry/BIS (not sure if they speak IMAP to anyone but Gmail, = though)) plus Apple Mail, Thunderbird, Outlook and Outlook Express, = you're probably talking about the top 99% of all IMAP clients. BIS talks IMAP to everyone. > I'm happy to share the FETCH matches we do for about 25 clients. Its = not exact, and probably unnecessary since most of those are just in the = noise. I'm interested of those. Maybe at some point I'll make a Dovecot plugin = doing similar statistics. There are probably also other things you can = use to detect clients. From blong@google.com Thu Aug 2 15:07:44 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F19011E8102 for ; Thu, 2 Aug 2012 15:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.708 X-Spam-Level: X-Spam-Status: No, score=-102.708 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU++fvrX60Du for ; Thu, 2 Aug 2012 15:07:43 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1D311E8105 for ; Thu, 2 Aug 2012 15:07:43 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so42406obb.31 for ; Thu, 02 Aug 2012 15:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=lB2NlqS7R/TseTNcboMT8jYLSIFUJjrkPput7eFs/x8=; b=FasFi0cK+FE60LKKbN+PhLiOJvNSoTDGAkuyM2xImcBiwEIwMFFu6U+fkxfFpLz3uR IcHduPYk1Aw/s0k819vLdEx5SABQmzdxRMIXuPxbJ1M+1BQ7SMPmKURoaHePnhjoCObi tNQNMhN6KGXiSQEtdciViTV9Z/G+VbY2wS2q2eB5kUYaLiX6qU1Kmw6vb9kPiN+d9ei1 CF2mTvePF6aiMkej8b+lOzkPEZ3PycB7domkhyd7k/EJ4988wGYBGEoj6GXByJnpj5X3 yy7EKDV78PeMfpXSgQ2qeavmHsJrE/8lIZAtI8+XmKLeIL2bhvIPl8GT23hhJ0203aeQ yRkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=lB2NlqS7R/TseTNcboMT8jYLSIFUJjrkPput7eFs/x8=; b=Pwnn/xQRP8DRbpjZSXnhTLhZGsae2Fgc9zfWtkbKTdo8nWmv0c/itpMDrbRDg+KifI HnR7RTtCUgP5QHo/CICDUdb8hCOTBn9wUVkuG+rinDWl65pqMnof9mDDwhfxELp1IHep l7BoAQClhy9A7tjVsAie2Y0eCwWuQHjwOKnWhuaSMwgYClhDd6WX6SVmRTk347DUU5HO J5nCOikWiqlVI7R7HrUKD2BE+NezLknQ4iT1DeqCXkHdRxGkmU+gPV1CYMKXPxRSeHko JnBcVk2tOHpn7cdSUEteazECIG9h2hk74YwC8tqns04Wu6z0vzu5geNd89Fq/13TIQO8 XPFw== Received: by 10.182.167.41 with SMTP id zl9mr40210127obb.43.1343945262801; Thu, 02 Aug 2012 15:07:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.167.41 with SMTP id zl9mr40210108obb.43.1343945262638; Thu, 02 Aug 2012 15:07:42 -0700 (PDT) Received: by 10.76.6.209 with HTTP; Thu, 2 Aug 2012 15:07:42 -0700 (PDT) In-Reply-To: References: <01OIKQHRTLOU0006TF@mauve.mrochek.com> Date: Thu, 2 Aug 2012 15:07:42 -0700 Message-ID: From: Brandon Long To: Adrien de Croy Content-Type: multipart/alternative; boundary=e89a8f839b0bfa26b904c64fa3a9 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm7GNkkyasREUDPWbs04MOErm8mJWYC6fzir2ZC+DtyUMiq1bdaqCUmesgkniKzjoUxSvOQkoewArraqroRUSXm0w5U9xETfrY+UPqVHwswFanuUjT5xw/9BWW6JoQjr6b4v9Ft9OvP13Lx+CVfzBIb/6Pt1KBskZ+9JqhIIacLA2NZpG2jiJv+hlKWdxWTnunXZL9B Cc: Arnt Gulbrandsen , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:07:44 -0000 --e89a8f839b0bfa26b904c64fa3a9 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 2, 2012 at 2:26 PM, Adrien de Croy wrote: > > ------ Original Message ------ > From: "Ned Freed" > >> >> Actually, it's far simpler and provides much more flexibility. I rather >> suspect I could implement it in a couple of hours, whereas a properly >> designed submit extension would take far longer and require far more >> testing and QA. The only part that's in any way tricky is the handling of >> disconnects. >> > I did think a bit about this before I replied. > > Any time the submission service is a different physical process to the > IMAP service, you have a problem of transmission of credentials. This > would require the client to tunnel auth through the IMAP server to the > submission server, and therefore require configuration for submission > credentials. So that problem remains. You could mandate the same creds be > used, but that would probably cause problems, or at best place limitations > on how submission and IMAP are deployed (must be in same auth realm). > Maybe that's not so bad. > I'm confused, are there really that many systems which would have separate trust for IMAP and SMTP? The servers should be in the same trust domain. I would imagine the default for most open source servers on Unix would be something like calling /usr/lib/sendmail with -f of the user. For us, we have "send message" on the Gmail app server, and that server is set to trust us to choose who to send as (or we can just pass the internal credentials, but we have to do that for many other requests already). There's already a mail server in the same trust domain to delivery mail to the IMAP server, after all. If your server really makes this hard, then don't implement SUBMIT. As with almost every IMAP extension ever made, the clients have to support the server not offering it. > I don't know how you'd avoid re-transmission of the message from the > client though, unless the IMAP server proxied the tunneled SMTP, and > inspected the protocol and you had a BURL-like extension that could access > the message content. At least in this case, you wouldn't have inter-domain > trust issues with a submit server trying to retrieve an IMAP message for > submission. > It removes the re-transmission from the client to the server, which is often over much slower/expensive links. Piping the message to /usr/lib/sendmail hardly qualifies as the same as the client sending the message twice over a 2G mobile connection. > The only thing this really would solve is the TCP port access. > It solves the client configuration problem, complete with all the possible error cases that are associated with every service that needs to be configured. In fact, I imagine for the average linux user self-installation, it also makes it easier to install, as they need to make passwords work with only a single service (the IMAP server) and not two services (admittedly its been a while, but smtp-auth for MSA is annoying to configure on a bunch of the popular mail servers). Brandon --e89a8f839b0bfa26b904c64fa3a9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, A= ug 2, 2012 at 2:26 PM, Adrien de Croy <adrien@qbik.com&= gt; wrote:

------ Original Message ------
From: "Ned Freed" <ned.freed@mrochek.com>

Actually, it's far simpler and provides much more flexibility. I rather= suspect I could implement it in a couple of hours, whereas a properly desi= gned submit extension would take far longer and require far more testing an= d QA. The only part that's in any way tricky is the handling of disconn= ects.
I did think a bit about this before I replied.

Any time the submission service is a different physical process to the IMAP= service, you have a problem of transmission of credentials. =A0This would = require the client to tunnel auth through the IMAP server to the submission= server, and therefore require configuration for submission credentials. = =A0So that problem remains. =A0You could mandate the same creds be used, bu= t that would probably cause problems, or at best place limitations on how s= ubmission and IMAP are deployed (must be in same auth realm). =A0Maybe that= 's not so bad.

I'm confused, are there really that ma= ny systems which would have separate trust for IMAP and SMTP?
The servers should be in the same trust domain. =A0I would imag= ine the default for most open source servers on Unix would be something lik= e calling /usr/lib/sendmail with -f of the user. =A0For us, we have "s= end message" on the Gmail app server, and that server is set to trust = us to choose who to send as (or we can just pass the internal credentials, = but we have to do that for many other requests already). =A0There's alr= eady a mail server in the same trust domain to delivery mail to the IMAP se= rver, after all.

If your server really makes this hard, then don't i= mplement SUBMIT. =A0As with almost every IMAP extension ever made, the clie= nts have to support the server not offering it.
=A0
I don't know how you'd avoid re-transmission of the message from th= e client though, unless the IMAP server proxied the tunneled SMTP, and insp= ected the protocol and you had a BURL-like extension that could access the = message content. =A0At least in this case, you wouldn't have inter-doma= in trust issues with a submit server trying to retrieve an IMAP message for= submission.

It removes the re-transmission from the cl= ient to the server, which is often over much slower/expensive links. =A0Pip= ing the message to /usr/lib/sendmail hardly qualifies as the same as the cl= ient sending the message twice over a 2G mobile connection.
=A0
The only thing this really would solve is the TCP port access.

It solves the client configuration problem, complet= e with all the possible error cases that are associated with every service = that needs to be configured. =A0In fact, I imagine for the average linux us= er self-installation, it also makes it easier to install, as they need to m= ake passwords work with only a single service (the IMAP server) and not two= services (admittedly its been a while, but smtp-auth for MSA is annoying t= o configure on a bunch of the popular mail servers).

Brandon
--e89a8f839b0bfa26b904c64fa3a9-- From ned.freed@mrochek.com Thu Aug 2 15:19:52 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C69421E80D4 for ; Thu, 2 Aug 2012 15:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTTnGutLqdMM for ; Thu, 2 Aug 2012 15:19:51 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A2A7B21E80CA for ; Thu, 2 Aug 2012 15:19:51 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIKYHVRHLC001OM2@mauve.mrochek.com> for imapext@ietf.org; Thu, 2 Aug 2012 15:14:47 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Thu, 2 Aug 2012 15:14:40 -0700 (PDT) Message-id: <01OIKYHRTM8M0006TF@mauve.mrochek.com> Date: Thu, 02 Aug 2012 14:45:42 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 02 Aug 2012 21:26:59 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed References: <01OIKQHRTLOU0006TF@mauve.mrochek.com> To: Adrien de Croy Cc: Arnt Gulbrandsen , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:19:52 -0000 > I'm still keen to solve double-transmission. in order to do that, the > message that has already been composed (e.g. in Drafts or Outbox or > whatever, by way of CATENATE, COPY whatever) needs to be able to be > submitted for delivery on behalf of the client, without requiring the > client to retrieve it, and retransmit it to a submission server. RFC 4468. > >You might want to look at statistics for typical mixes of clients seen > >by servers then, with an eye to how many old versions are in use. > most of our customers (and admittedly I'm talking a fairly restricted > use case) are using 1 or more of > outlook or outlook express or Thunderbird > and/or IOS mail client And what versions of Outlook are people using? > We really don't see significant use of other clients. But this is not > rigorous or general by any means. Irrelevant to my point. > >>Corporates tend to standardise on software for various reasons. It > >>would only take someone to write an Outlook connector to do this. > > > >Even if that were true - and I am highly skeptical it is - it in no > >way makes a > >case for standarizing something. > IMO a case for standardisation of something is made in order to enable > interoperability when a significant (whatever that is) number of people > are affected. > So if MS decided to put such a thing into Exchange, and Outlook, and > published a spec for it, I think you'd find it got adopted. I'm still failing to see how this is relevant to the current proposal. > >>OK, I'm interested in your experience here, what are the main causes > >>you see? > > > >Main cause is probably credential issues of some sort. But of the > >issues that > >have to be esclated and which therefore cost the most to address, > >broken > >filtering and bad MIME top the list. In other words, the top complaint > >after > >they're able to connect to their mailbox isn't, "Why can't I send > >mail?", it's > >"Why didn't the recipient get what I sent?" and "Why was what they got > >a pile > >of garbage?" > that's not generally something we can address by anything IMAP-related. That's exactly my point. > >The point is it is a *different* port. ISPs specifically block port > >25, and for > >good reason. They don't block the SUBMIT port, again for good reason. > I don't disagree. I guess my point was that any time you introduce a > requirement to make another TCP connection you have potential issues > relating to name resolution, local (client-side) firewalls, routing (if > it's a different IP), credential establishment etc etc etc. Yes, and every time you introduce a major new extension, you have issues with bugs, client adoption, server adoption, stateful firewalls (which alone should be cause for grave concern), credential binding, etc. etc. It's always a tradeoff, but it is one that is heavily canted towards existing mechanism, especially when the new mechanism offers at best offers a small measure of increased operational utility and no new functionality. I'm really not seeing anything that's even close to making the case here. > >>Sure there's more debugging for submission problems, since you > >>inserted > >>an option for submission, however in a well-designed system, it > >>should > >>be simple to determine how a message was submitted. > > > >Not when the problem only turns up after it was received. (Please tell > >me > >you're not counting on being able to see Received: fields.) > hell no. Mostly server logs. It depends on the realm of authority of > the problem location (e.g. whether you can even get server logs). Not much of an improvement. Try finding something like this in a server log in a setup with, oh, say, 10 servers and an aggregate transaction rate of 10,000 messages a second. That's not an especially large setup in my world. And given the complexity of message composition, part of the problem here is that you'll almost certainly need the actual message in order to be able to eliminate client composition problems from the mix. And yes, this is also a problem with BURL. > Any time the submission service is a different physical process to the > IMAP service, you have a problem of transmission of credentials. This > would require the client to tunnel auth through the IMAP server to the > submission server, and therefore require configuration for submission > credentials. So that problem remains. There is nothing that says the SMTP connection that appears through the tunnel is in the same state as one you get from the start on the SUBMIT port. What you'd want to have happen is for the IMAP server to proxy over the user's credentials. How this is done doesn't need to be standardized, although I suppose you could if you wanted to. > You could mandate the same > creds be used, but that would probably cause problems, or at best place > limitations on how submission and IMAP are deployed (must be in same > auth realm). Maybe that's not so bad. Huh? The current proposal has exactly the same set of problems: You're depending on the credentials the user has already established with the IMAP server to be sufficient for the submission operation. As it happens we solved this problem 10+ years ago in order to support various sorts of proxies. I won't say it is trivial - there are a couple of details that aren't obvious - but it's hardly rocket science. And I doubt very, very much we're the only vendor who has done it. In fact I know we're not. > I don't know how you'd avoid re-transmission of the message from the > client though, unless the IMAP server proxied the tunneled SMTP, and > inspected the protocol and you had a BURL-like extension that could > access the message content. At least in this case, you wouldn't have > inter-domain trust issues with a submit server trying to retrieve an > IMAP message for submission. Exactly. The main problem with BURL is that it tries to address the inter-domain trust situation, and that makes the protocol overly complex. > The only thing this really would solve is the TCP port access. Not true. > Proxying SMTP over IMAP begs the question "why?", So does the current proposal, only more so. This is having your work translated into French because you're hoping against all odds that the translation will be better than the original. (Apologies to Thurber.) > and "why not proxy > everything through some simpler protocol that does the auth/security > leg-work?". E.g. CONNECT over HTTP. I think there was an RFC for > something that abstracted establishment of creds, security etc before > passing over to a service. Does SSH do this? That's more or less what BEEP tried to do. The lack of interest was overwhelming. Ned From blong@google.com Thu Aug 2 15:48:22 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2AC11E8189 for ; Thu, 2 Aug 2012 15:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.738 X-Spam-Level: X-Spam-Status: No, score=-103.738 tagged_above=-999 required=5 tests=[AWL=1.238, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxlDIrsk-+dR for ; Thu, 2 Aug 2012 15:48:20 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2743E11E8173 for ; Thu, 2 Aug 2012 15:48:20 -0700 (PDT) Received: by yhq56 with SMTP id 56so72087yhq.31 for ; Thu, 02 Aug 2012 15:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=mkIrPcwZ1wiHwzsUliLHcs90bPlN5vAhquBQs2H8CvM=; b=JktrpNf0113u/GAvFqWgqrRGmtAk2+p3ThFbaxqCsh4iZNM5Rv/oRO53QcPzit9YzP i5ErQAc5sxirOjqR/Qbw2intUbysox38EvJepwdZvC3C+QmBqnM4te8TEW/vKJrIVzSs VQIsk8XezsQRJXYvK1q2h2uORd1D08nm2uJ69aTDLWQlDWNxd8sAHWd/vY5y+dS1JXgi SGmwjRLchSRIAp/lbuXHzyrsJ04UZ45m9kov4i0Bwugzhikji1DBLYsIqRPRl2nafrKC 1UCvCGaVbhHRdDJH5Vt5zd0ZenAcKS3d4PKt//rai5c9CTbDMv5/uYQ1x3BTYYBKY4J7 iFAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=mkIrPcwZ1wiHwzsUliLHcs90bPlN5vAhquBQs2H8CvM=; b=T8HA6HhW1TrH9X+kO9QTSuQzkJyJwr/VGYIi63GJ8isei7344LgIMriUhkFT+Hp+r/ uFjEW20AOR8mdv9KnxD3V1OUsR8OVyv8im/U7DVFfYmHr+1mVx9As+5D0qoMRn8spe0n hPj+HLuJSTaLyX/FbFJ00VSmmb+QcKqlrm1+5NCkvSqCfHWIjUxoB6ZveauuMqOHowck biA3R1ZvhUGx+jPeckTZ+JPYt+ovRwwdoFISWRz/PYWrgl1+K7dwnw+MsqogH2uNFc1W yvp9asDReMRaEnDOa6QMy8fnJVC63sLw4sEhpvyw+nCur99uNi3qdRanytd6YtsupMc3 pDnA== Received: by 10.60.171.174 with SMTP id av14mr40170082oec.61.1343947699667; Thu, 02 Aug 2012 15:48:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.171.174 with SMTP id av14mr40170052oec.61.1343947699423; Thu, 02 Aug 2012 15:48:19 -0700 (PDT) Received: by 10.76.6.209 with HTTP; Thu, 2 Aug 2012 15:48:19 -0700 (PDT) In-Reply-To: <81FFA4ED-CA53-406D-BE99-CFA2D9A375E0@iki.fi> References: <81FFA4ED-CA53-406D-BE99-CFA2D9A375E0@iki.fi> Date: Thu, 2 Aug 2012 15:48:19 -0700 Message-ID: From: Brandon Long To: Timo Sirainen Content-Type: multipart/mixed; boundary=bcaec54a3252388bcc04c650352e X-System-Of-Record: true X-Gm-Message-State: ALoCoQkbl0r42QO4ttuMSg10bdMfDR9lv48JMzxy+j7MJzMYBI2LwJiuP1BXbyIdig7glQR6FCNarpQJzzQgKm1btjWsOqy7PYm36s5Xnt6t09YL5B+wD4zr9uMg9rywjR0nYNIitOSsSvzieeIbNqs9itZ8n9rDPBXdAHZtnahGjhI3p4nO4CX8+Of387/RlCPYJ3xl7MCn Cc: imapext@ietf.org Subject: Re: [imapext] IMAP clients X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 22:48:22 -0000 --bcaec54a3252388bcc04c650352e Content-Type: multipart/alternative; boundary=bcaec54a3252388bbe04c650352c --bcaec54a3252388bbe04c650352c Content-Type: text/plain; charset=ISO-8859-1 Ok, attached is the list of unique-ish FETCH commands that we use to match on. They probably don't match what the client sends exactly (our logging is based on our parsing of the fetch, not on the direct client text, and then we further munge to generize the line some more, hence and <0.chunk>). Its also focused more on the state of clients ~3-4 years ago, with the uptick in usages of the ID command and the overwhelming numbers of a small set of clients, we haven't really kept it up to date. On Thu, Aug 2, 2012 at 3:04 PM, Timo Sirainen wrote: > On 3.8.2012, at 0.56, Brandon Long wrote: > > > Obviously our list of clients is skewed compared to what most servers > probably see, but most of our usage is mobile clients, followed by the most > popular desktop clients (in order), Apple Mail, Thunderbird, Outlook, > Outlook Express... then much further down we have Pine, Pegasus Mail, and > Opera. > > I'd be interested in percentages also if those aren't a secret. :) > I don't know if they're secret. I can certainly imagine some ways that bloggers could spin the data in various ways, though, and I wouldn't like to put PR through the fun of handling that. The vast majority is mobile, and the majority of that is iOS. We also see more than one device per user, on average (ie, I good portion of iPad users also have another iDevice). Note that our Android numbers are higher than expected because the Gmail app doesn't speak IMAP, it speaks its own protocol. And our Outlook numbers may be low because Google Apps Sync speaks its own protocol. But Apple Mail is about the same as both Outlook and Outlook Express combined, and Thunderbird comes in the middle of that. > > But agreed, with the top 4 mobile (iOS, Android Email, WinPhone and > Blackberry/BIS (not sure if they speak IMAP to anyone but Gmail, though)) > plus Apple Mail, Thunderbird, Outlook and Outlook Express, you're probably > talking about the top 99% of all IMAP clients. > > BIS talks IMAP to everyone. > Ok, I knew they used to use POP with us, and upgraded some of their users to IMAP, at least when they use the Gmail Blackberry extension, wasn't sure if that was general or not. > > I'm happy to share the FETCH matches we do for about 25 clients. Its > not exact, and probably unnecessary since most of those are just in the > noise. > > I'm interested of those. Maybe at some point I'll make a Dovecot plugin > doing similar statistics. There are probably also other things you can use > to detect clients. > Definitely. My solution was based on our logs analysis, which basically means individual commands with no sequence, and we didn't originally bother to store the tag. If you look at the way the tag is constructed, whether the tag is numeric and in order, whether it has sub sections (1.2) or all lower case letters, etc and the sequence of commands, you can probably do an even better job in real-time, especially if you want to tell the difference between versions of clients. Certain bugs also stand out, like Outlook which likes to do an IDLE without having a folder selected. Brandon --bcaec54a3252388bbe04c650352c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Ok, attached is the list of unique-ish FETCH commands that we use to match = on. =A0They probably don't match what the client sends exactly (our log= ging is based on our parsing of the fetch, not on the direct client text, a= nd then we further munge to generize the line some more, hence <chunk.ch= unk> and <0.chunk>).

Its also focused more on the state of clients ~3-4 years ago= , with the uptick in usages of the ID command and the overwhelming numbers = of a small set of clients, we haven't really kept it up to date.


On Thu, Aug 2= , 2012 at 3:04 PM, Timo Sirainen <tss@iki.fi> wrot= e:
On 3.8.2012, at 0.56, Brandon Long wrote:

> Obviously our list of clients is skewed compared to what most servers = probably see, but most of our usage is mobile clients, followed by the most= popular desktop clients (in order), Apple Mail, Thunderbird, Outlook, Outl= ook Express... then much further down we have Pine, Pegasus Mail, and Opera= .

I'd be interested in percentages also if those aren't a secre= t. :)

I don't know if they're s= ecret. =A0I can certainly imagine some ways that bloggers could spin the da= ta in various ways, though, and I wouldn't like to put PR through the f= un of handling that.

The vast majority is mobile, and the majority of that i= s iOS. =A0We also see more than one device per user, on average (ie, I good= portion of iPad users also have another iDevice). =A0Note that our Android= numbers are higher than expected because the Gmail app doesn't speak I= MAP, it speaks its own protocol. =A0And our Outlook numbers may be low beca= use Google Apps Sync speaks its own protocol. =A0But Apple Mail is about th= e same as both Outlook and Outlook Express combined, and Thunderbird comes = in the middle of that.
=A0
> But agreed, with the top 4 mobile (iOS, Android Email, WinPhone and Bl= ackberry/BIS (not sure if they speak IMAP to anyone but Gmail, though)) plu= s Apple Mail, Thunderbird, Outlook and Outlook Express, you're probably= talking about the top 99% of all IMAP clients.

BIS talks IMAP to everyone.

Ok, I= knew they used to use POP with us, and upgraded some of their users to IMA= P, at least when they use the Gmail Blackberry extension, wasn't sure i= f that was general or not.
=A0
> I'm happy to share the FETCH matches we do for about 25 clients. = =A0Its not exact, and probably unnecessary since most of those are just in = the noise.

I'm interested of those. Maybe at some point I'll make a Dove= cot plugin doing similar statistics. There are probably also other things y= ou can use to detect clients.

Definitel= y. =A0My solution was based on our logs analysis, which basically means ind= ividual commands with no sequence, and we didn't originally bother to s= tore the tag.

If you look at the way the tag is constructed, whether = the tag is numeric and in order, whether it has sub sections (1.2) or all l= ower case letters, etc and the sequence of commands, you can probably do an= even better job in real-time, especially if you want to tell the differenc= e between versions of clients. =A0Certain bugs also stand out, like Outlook= which likes to do an IDLE without having a folder selected.

Brandon
--bcaec54a3252388bbe04c650352c-- --bcaec54a3252388bcc04c650352e Content-Type: text/plain; charset=US-ASCII; name="imap_client_matching.txt" Content-Disposition: attachment; filename="imap_client_matching.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h5ef5bpo0 IyBUaHVuZGVyYmlyZCBtZXNzYWdlIGZldGNoZXMKICAiKFVJRCBSRkM4MjIuU0laRSBCT0RZLlBF RUtbXSkiCiAgIihVSUQgUkZDODIyLlNJWkUgQk9EWS5QRUVLW108Y2h1bmsuY2h1bms+KSIKICAi KFVJRCBSRkM4MjIuU0laRSBCT0RZLlBFRUtbXTwwLmNodW5rPikiCgojIFRodW5kZXJiaXJkIGlu ZGV4IGZldGNoCiAgIihVSUQgUkZDODIyLlNJWkUgRkxBR1MgQk9EWS5QRUVLW0hFQURFUi5GSUVM RFMgKEZyb20gVG8gQ2MgU3ViamVjdCBEYXRlICIgKwogICAgICAiTWVzc2FnZS1JRCBQcmlvcml0 eSBYLVByaW9yaXR5IFJlZmVyZW5jZXMgTmV3c2dyb3VwcyBJbi1SZXBseS1UbyAiICsKICAgICAg IkNvbnRlbnQtVHlwZSldKSIKICAiKFVJRCBSRkM4MjIuU0laRSBGTEFHUyBCT0RZLlBFRUtbSEVB REVSLkZJRUxEUyAoRnJvbSBUbyBDYyBCY2MgU3ViamVjdCAiICsKICAgICAgIkRhdGUgTWVzc2Fn ZS1JRCBQcmlvcml0eSBYLVByaW9yaXR5IFJlZmVyZW5jZXMgTmV3c2dyb3VwcyBJbi1SZXBseS1U byAiICsKICAgICAgIkNvbnRlbnQtVHlwZSldKSIKCiMgTW96aWxsYSBNYWlsIHZhcmlhbnQKICAi KFVJRCBSRkM4MjIuU0laRSBGTEFHUyBCT0RZLlBFRUtbSEVBREVSLkZJRUxEUyAoRnJvbSBUbyBD YyBTdWJqZWN0IERhdGUgIiArCiAgICAgICJNZXNzYWdlLUlEIFByaW9yaXR5IFgtUHJpb3JpdHkg UmVmZXJlbmNlcyBOZXdzZ3JvdXBzIEluLVJlcGx5LVRvKV0pIgoKIyBBcHBsZSBNYWlsIGluZGV4 IGZldGNoCiMgQWx0ZXJuYXRpdmVseSwgQXBwbGUgTWFpbCBjYW4gYmUgYWRhcHRpdmUsIGJ1dCBp dCBzZWVtcyBsaWtlbHkgdGhhdAojIGFueSBmZXRjaCBhc2tpbmcgZm9yIHgtYXBwbGUtbWFpbC0g aXMgYW4gQXBwbGUgTWFpbCBjbGllbnQuCiAgIihJTlRFUk5BTERBVEUgVUlEIFJGQzgyMi5TSVpF IEZMQUdTIEJPRFkuUEVFS1tIRUFERVIuRklFTERTIChkYXRlIHN1YmplY3QgIiArCiAgICAgICJm cm9tIHRvIGNjIG1lc3NhZ2UtaWQgaW4tcmVwbHktdG8gcmVmZXJlbmNlcyB4LXByaW9yaXR5ICIg KwogICAgICAieC1tYWlsLXJzcy1zb3VyY2UtbmFtZSB4LXVuaWZvcm0tdHlwZS1pZGVudGlmaWVy ICIgKwogICAgICAieC11bml2ZXJzYWxseS11bmlxdWUtaWRlbnRpZmllciB4LWFwcGxlLW1haWwt dG9kby1tZXNzYWdlLWlkICIgKwogICAgICAieC1hcHBsZS1tYWlsLXRvZG8taWQgcmVjZWl2ZWQt c3BmIHgtc3BhbS1zdGF0dXMgeC1zcGFtLWZsYWcgIiArCiAgICAgICJjb250ZW50LXR5cGUpXSki CgojIEFwcGxlIGlQaG9uZS9pUG9kIFRvdWNoIGluZGV4IGZldGNoCiAgIihJTlRFUk5BTERBVEUg VUlEIFJGQzgyMi5TSVpFIEZMQUdTIEJPRFkuUEVFS1tIRUFERVIuRklFTERTIChkYXRlIHN1Ympl Y3QgIiArCiAgICAgICJmcm9tIGNvbnRlbnQtdHlwZSB0byBjYyldKSIKIyBBcHBsZSBpUGhvbmUg aW5pdGlhbCBib2R5IGZldGNoLCBwcm9iYWJseSBub3QgdW5pcXVlIGVub3VnaAogICIoQk9EWVNU UlVDVFVSRSBCT0RZLlBFRUtbSEVBREVSXSkiCgojIFZpYmVhbGljaW91cyBOb3RpZnkgMgogICIo VUlEIEZMQUdTIEVOVkVMT1BFIEJPRFkuUEVFS1tIRUFERVIuRklFTERTIChSZWZlcmVuY2VzKV0p IgogICIoVUlEIEJPRFlTVFJVQ1RVUkUgRU5WRUxPUEUgQk9EWS5QRUVLW0hFQURFUi5GSUVMRFMg KFJlZmVyZW5jZXMpXSkiCgojIFBhbG0gQ2hhdHRlck1haWwsIEkgdGhpbmsgdGhpcyBpcyB1bmlx dWUgZW5vdWdoCiAgIihGTEFHUyBJTlRFUk5BTERBVEUgQk9EWSBFTlZFTE9QRSkiCgojIFBhbG0g U25hcHBlcm1haWwKICAiKFVJRCBGTEFHUyBFTlZFTE9QRSBCT0RZLlBFRUtbSEVBREVSLkZJRUxE UyAoUkVGRVJFTkNFUyldIElOVEVSTkFMREFURSAiICsKICAgICAgIlJGQzgyMi5TSVpFIEJPRFlT VFJVQ1RVUkUpIgoKIyBQYWxtIFZlcnNhbWFpbAogICIoRkxBR1MgUkZDODIyLlNJWkUgQk9EWS5Q RUVLW0hFQURFUi5GSUVMRFMgKHRvIGRhdGUgZnJvbSBjYyBzdWJqZWN0ICIgKwogICAgICAicmVw bHktdG8geC1wcmlvcml0eSBpbXBvcnRhbmNlIENvbnRlbnQtVHlwZSBDb250ZW50LURpc3Bvc2l0 aW9uICIgKwogICAgICAiQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZyldKSIKCiMgT3V0bG9vayBF eHByZXNzIDYuMCBpbmRleCBmZXRjaC4gIFRoZXJlIGFyZSBtb3JlIHZhcmlhbmNlcywgYnV0IHRo ZXkKIyBhbGwgc2VlbSB0byBpbmNsdWRlIFgtTVNNYWlsLVByaW9yaXR5CiAgIihCT0RZLlBFRUtb SEVBREVSLkZJRUxEUyAoUmVmZXJlbmNlcyBYLVJlZiBYLVByaW9yaXR5IFgtTVNNYWlsLVByaW9y aXR5ICIgKwogICAgICAiWC1NU09FU1JlYyBOZXdzZ3JvdXBzKV0gRU5WRUxPUEUgUkZDODIyLlNJ WkUgVUlEIEZMQUdTIElOVEVSTkFMREFURSkiCiAgIihCT0RZLlBFRUtbSEVBREVSLkZJRUxEUyAo UmVmZXJlbmNlcyBYLVJlZiBYLVByaW9yaXR5IFgtTVNNYWlsLVByaW9yaXR5ICIgKwogICAgICAi SW1wb3J0YW5jZSBYLU1TT0VTUmVjIE5ld3Nncm91cHMpXSBFTlZFTE9QRSBSRkM4MjIuU0laRSBV SUQgRkxBR1MgIiArCiAgICAgICJJTlRFUk5BTERBVEUpIgogICIoVUlEIEZMQUdTIEJPRFlTVFJV Q1RVUkUgQk9EWS5QRUVLW0hFQURFUi5GSUVMRFMgKFJlY2VpdmVkIERhdGUgU3ViamVjdCAiICsK ICAgICAgIkZyb20gUHJpb3JpdHkgWC1Qcmlvcml0eSBYLU1TTWFpbC1Qcmlvcml0eSBJbXBvcnRh bmNlKV0pIgogICIoVUlEIEZMQUdTIEJPRFlTVFJVQ1RVUkUgQk9EWS5QRUVLW0hFQURFUi5GSUVM RFMgKFJlY2VpdmVkIERhdGUgU3ViamVjdCAiICsKICAgICAgIkZyb20gUmVwbHktdG8gVG8gQ2Mg QmNjIE1lc3NhZ2UtSUQgUmV0dXJuLVJlY2VpcHQtVG8gIiArCiAgICAgICJYLVJldHVybi1SZWNl aXB0LVRvIERpc3Bvc2l0aW9uLU5vdGlmaWNhdGlvbi1UbyAiICsKICAgICAgIkRpc3Bvc2l0aW9u LU5vdGlmaWNhdGlvbi1PcHRpb25zIFByaW9yaXR5IFgtUHJpb3JpdHkgIiArCiAgICAgICJYLU1T TWFpbC1Qcmlvcml0eSBJbXBvcnRhbmNlKV0pIgoKIyBPdXRsb29rIEV4cHJlc3MgNi4wIHByZXZp ZXcgcGFuZSBmZXRjaCwgcHJvYmFibHkgbm90IHVuaXF1ZSBlbm91Z2gKICAiKEJPRFkuUEVFS1td IFVJRCkiCgojIE91dGxvb2sgMjAwMyBwcmV2aWV3IGZldGNoCiAgIihVSUQgRkxBR1MgQk9EWS5Q RUVLW10gSU5URVJOQUxEQVRFKSIKCiMgT3V0bG9vayAyMDAzIGluZGV4IGZldGNoCiAgIihVSUQg RkxBR1MgUkZDODIyLlNJWkUgQk9EWS5QRUVLW0hFQURFUl0gSU5URVJOQUxEQVRFKSIKCiMgT3V0 bG9vawogICIoVUlEIEZMQUdTIFJGQzgyMi5TSVpFIEJPRFkuUEVFS1tIRUFERVJdKSIKCgojIEFu ZHJvaWQgSU1BUCBDbGllbnQgKDEuMCkKICAiKFVJRCBGTEFHUyBJTlRFUk5BTERBVEUgUkZDODIy LlNJWkUgQk9EWS5QRUVLW0hFQURFUi5GSUVMRFMgKGRhdGUgc3ViamVjdCAiICsKICAgICAgImZy b20gY29udGVudC10eXBlIHRvIGNjKV0pIgojIEFuZHJvaWQgKGRvbnV0LCBtYXliZSBjdXBjYWtl KQogICIoVUlEIEZMQUdTIElOVEVSTkFMREFURSBSRkM4MjIuU0laRSBCT0RZLlBFRUtbSEVBREVS LkZJRUxEUyAoZGF0ZSBzdWJqZWN0ICIgKwogICAgICAiZnJvbSBjb250ZW50LXR5cGUgdG8gY2Mg bWVzc2FnZS1pZCldKSIKCiMgSFRDIEhlcm8vU2Vuc2UgY2xpZW50CiAgIihJTlRFUk5BTERBVEUg UkZDODIyLlNJWkUgRkxBR1MgQk9EWS5QRUVLW0hFQURFUi5GSUVMRFMgKHN1YmplY3QgZnJvbSAi ICsKICAgICAgImRhdGUgY29udGVudC10eXBlIHRvIGNjIG1lc3NhZ2UtaWQgcmVmZXJlbmNlcyld KSIKICAjIFNpbmNlIHRoaXMgaXMgbmVhcmx5IGlkZW50aWNhbCB0byB0aGUgSFRDIFNlbnNlIG9u ZSwgYXNzdW1pbmcgc2FtZQogICIoSU5URVJOQUxEQVRFIFJGQzgyMi5TSVpFIEZMQUdTIEJPRFku UEVFS1tIRUFERVIuRklFTERTIChzdWJqZWN0IGZyb20gIiArCiAgICAgICJkYXRlIHRvIGNjKV0g Qk9EWS5QRUVLW3BhcnRdPDAuY2h1bms+KSIKCiMgRXVkb3JhIDcuMQogICIoRGF0ZSBTdWJqZWN0 IFJlcGx5LXRvIEZyb20gWC1Qcmlvcml0eSBJbXBvcnRhbmNlIENvbnRlbnQtVHlwZSkiCgojIE9w ZXJhIDkuNSBpbmRleCBmZXRjaAogICIoVUlEIFJGQzgyMi5TSVpFIFJGQzgyMi5IRUFERVIgQk9E WVNUUlVDVFVSRSBGTEFHUykiCiMgT3BlcmEgOS41IGJvZHkgcHJldmlldyBmZXRjaAogICIoVUlE IEJPRFkuUEVFS1tdIEZMQUdTKSIKCiMgRXZvbHV0aW9uCiAgIihVSUQgRkxBR1MgSU5URVJOQUxE QVRFIFJGQzgyMi5TSVpFIEVOVkVMT1BFIEJPRFkuUEVFS1tIRUFERVIuRklFTERTICIgKwogICAg ICAiKENvbnRlbnQtVHlwZSBSZWZlcmVuY2VzIExpc3QtUG9zdCBMaXN0LUlkIE1haWxpbmctTGlz dCBPcmlnaW5hdG9yICIgKwogICAgICAiWC1NYWlsaW5nLUxpc3QgWC1Mb29wIFgtTGlzdCBTZW5k ZXIgRGVsaXZlcmVkLVRvIFJldHVybi1QYXRoICIgKwogICAgICAiWC1CZWVuVGhlcmUgTGlzdC1V bnN1YnNjcmliZSldKSIKCiMgS01haWwKICAiKFVJRCBSRkM4MjIuU0laRSBGTEFHUyBFTlZFTE9Q RSBCT0RZLlBFRUtbSEVBREVSLkZJRUxEUyAoUkVGRVJFTkNFUyldKSIKICAiKFVJRCBSRkM4MjIu U0laRSBGTEFHUyBCT0RZLlBFRUtbXSkiCgojIE11dHQKICAiKFVJRCBGTEFHUyBJTlRFUk5BTERB VEUgUkZDODIyLlNJWkUgQk9EWS5QRUVLW0hFQURFUi5GSUVMRFMgKERBVEUgRlJPTSAiICsKICAg ICAgIlNVQkpFQ1QgVE8gQ0MgTUVTU0FHRS1JRCBSRUZFUkVOQ0VTIENPTlRFTlQtVFlQRSBDT05U RU5ULURFU0NSSVBUSU9OICIgKwogICAgICAiSU4tUkVQTFktVE8gUkVQTFktVE8gTElORVMgTElT VC1QT1NUIFgtTEFCRUwpXSkiCgojIFBpbmUKICAiKFVJRCBFTlZFTE9QRSBCT0RZLlBFRUtbSEVB REVSLkZJRUxEUyAoTmV3c2dyb3VwcyBDb250ZW50LU1ENSAiICsKICAgICAgIkNvbnRlbnQtRGlz cG9zaXRpb24gQ29udGVudC1MYW5ndWFnZSBDb250ZW50LUxvY2F0aW9uIEZvbGxvd3VwLVRvICIg KwogICAgICAiUmVmZXJlbmNlcyldIElOVEVSTkFMREFURSBSRkM4MjIuU0laRSBGTEFHUykiCiAg IihFTlZFTE9QRSBCT0RZLlBFRUtbSEVBREVSLkZJRUxEUyAoTmV3c2dyb3VwcyBDb250ZW50LU1E NSAiICsKICAgICAgIkNvbnRlbnQtRGlzcG9zaXRpb24gQ29udGVudC1MYW5ndWFnZSBDb250ZW50 LUxvY2F0aW9uIEZvbGxvd3VwLVRvICIgKwogICAgICAiUmVmZXJlbmNlcyldIElOVEVSTkFMREFU RSBSRkM4MjIuU0laRSBGTEFHUykiCiAgIihCT0RZU1RSVUNUVVJFIEZMQUdTKSIKIyBQaW5lIGlz IGFkYXB0aXZlLCBzbyBjaGVjayBmb3IgdGhpcyBwcmVmaXggYW5kIHN1ZmZpeCB3b3JrczoKICBQ cmVmaXg6ICIoVUlEIEVOVkVMT1BFIEJPRFkuUEVFS1tIRUFERVIuRklFTERTIChOZXdzZ3JvdXBz ICIgKwogICAgICAiQ29udGVudC1NRDUgQ29udGVudC1EaXNwb3NpdGlvbiAiCiAgU3VmZml4OiAi UmVmZXJlbmNlcyldIElOVEVSTkFMREFURSBSRkM4MjIuU0laRSBGTEFHUykiCgojIFRoZSBCYXQh CiAgIihVSUQgUkZDODIyLlNJWkUgRU5WRUxPUEUgSU5URVJOQUxEQVRFIEZMQUdTKSIKCiMgUGVn YXN1cyBNYWlsIDQuNDEKICAiKEZMQUdTIFVJRCBSRkM4MjIuU0laRSBCT0RZLlBFRUtbXSkiCiAg IihGTEFHUyBVSUQgUkZDODIyLlNJWkUgQk9EWS5QRUVLW0hFQURFUi5GSUVMRFMgKEZST00gU1VC SkVDVCBUTyBEQVRFICIgKwogICAgICAiWC1QTVVVRSBNSU1FLVZFUlNJT04gQ09OVEVOVC1UWVBF IFJFU0VOVC1GUk9NIFBSSU9SSVRZIFgtUE1FTkMgIiArCiAgICAgICJYLUNPTkZJUk0tUkVBRElO Ry1UTyBYLVBNLUVOQ1JZUFRPUiBYLUNTIFgtUE0tQ0lSQ1VMQVRFLVRPKV0pIgoKIyBQb2NvTWFp bCA0LjUKICAiKFJGQzgyMi5TSVpFIEZMQUdTIEVOVkVMT1BFKSIKCiMgT3V0bG9vayBNb2JpbGUg LyBXaW5kb3dzIE1vYmlsZQogICIoSU5URVJOQUxEQVRFIFVJRCBGTEFHUyBSRkM4MjIuU0laRSBC T0RZLlBFRUtbSEVBREVSLkZJRUxEUyAoREFURSBGUk9NICIgKwogICAgICAiU1VCSkVDVCBNRVNT QUdFLUlEIENPTlRFTlQtVFlQRSBYLU1TLVRORUYtQ29ycmVsYXRvciBDT05URU5ULUNMQVNTICIg KwogICAgICAiSU1QT1JUQU5DRSBQUklPUklUWSBYLVBSSU9SSVRZKV0gQk9EWVNUUlVDVFVSRSki CiAgIihJTlRFUk5BTERBVEUgVUlEIEZMQUdTIFJGQzgyMi5TSVpFIEJPRFkuUEVFS1tIRUFERVIu RklFTERTIChEQVRFIEZST00gIiArCiAgICAgICJTVUJKRUNUIE1FU1NBR0UtSUQgQ09OVEVOVC1U WVBFIFgtTVMtVE5FRi1Db3JyZWxhdG9yIENPTlRFTlQtQ0xBU1MgIiArCiAgICAgICJJTVBPUlRB TkNFKV0gQk9EWVNUUlVDVFVSRSkiCiAgIihJTlRFUk5BTERBVEUgVUlEIEZMQUdTIFJGQzgyMi5T SVpFIEJPRFkuUEVFS1tIRUFERVIuRklFTERTIChEQVRFIEZST00gIiArCiAgICAgICJTVUJKRUNU IE1FU1NBR0UtSUQgQ09OVEVOVC1UWVBFIFgtTVMtVE5FRi1Db3JyZWxhdG9yIENPTlRFTlQtQ0xB U1MpXSAiICsKICAgICAgIkJPRFlTVFJVQ1RVUkUpIgogICIoSU5URVJOQUxEQVRFIFVJRCBGTEFH UyBSRkM4MjIuU0laRSBCT0RZLlBFRUtbSEVBREVSLkZJRUxEUyAoREFURSBGUk9NICIgKwogICAg ICAiU1VCSkVDVCBNRVNTQUdFLUlEIENPTlRFTlQtVFlQRSBYLU1TLVRORUYtQ29ycmVsYXRvciBD T05URU5ULUNMQVNTICIgKwogICAgICAiSU1QT1JUQU5DRSBQUklPUklUWSBYLVBSSU9SSVRZIFRI UkVBRC1UT1BJQyldIEJPRFlTVFJVQ1RVUkUpIgogICIoVUlEIEZMQUdTIEJPRFkuUEVFS1tIRUFE RVIuRklFTERTIChNRVNTQUdFLUlEKV0pIgogICIoUkZDODIyLkhFQURFUiBCT0RZLlBFRUtbcGFy dF0gQk9EWS5QRUVLW3BhcnRdKSIKICAiKFJGQzgyMi5IRUFERVIgQk9EWS5QRUVLW3BhcnRdPDAu Y2h1bms+KSIKICAiKFJGQzgyMi5IRUFERVIgQk9EWS5QRUVLW3BhcnRdKSIKCiMgb2xkZXIgQXBw bGUgTWFpbD8KICAiKElOVEVSTkFMREFURSBVSUQgUkZDODIyLlNJWkUgRkxBR1MgQk9EWS5QRUVL W0hFQURFUi5GSUVMRFMgKGRhdGUgc3ViamVjdCAiICsKICAgICAgImZyb20gdG8gY2MgbWVzc2Fn ZS1pZCBpbi1yZXBseS10byByZWZlcmVuY2VzIHgtcHJpb3JpdHkgeC1zcGFtLWZsYWcgIiArCiAg ICAgICJyZWNlaXZlZC1zcGYgY29udGVudC10eXBlKV0pIgogICIoSU5URVJOQUxEQVRFIFVJRCBS RkM4MjIuU0laRSBGTEFHUyBCT0RZLlBFRUtbSEVBREVSLkZJRUxEUyAoZGF0ZSBzdWJqZWN0ICIg KwogICAgICAiZnJvbSB0byBjYyBtZXNzYWdlLWlkIGluLXJlcGx5LXRvIHJlZmVyZW5jZXMgeC1w cmlvcml0eSB4LXNwYW0tZmxhZyAiICsKICAgICAgInJlY2VpdmVkLXNwZildKSIKICAiKElOVEVS TkFMREFURSBVSUQgUkZDODIyLlNJWkUgRkxBR1MgQk9EWS5QRUVLW0hFQURFUi5GSUVMRFMgKGRh dGUgc3ViamVjdCAiICsKICAgICAgImZyb20gdG8gY2MgbWVzc2FnZS1pZCBpbi1yZXBseS10byBy ZWZlcmVuY2VzIHgtcHJpb3JpdHkgcmVzZW50LXRvICIgKwogICAgICAicmVzZW50LWNjIGJjYyB4 LXNwYW0tZmxhZyByZWNlaXZlZC1zcGYgY29udGVudC10eXBlKV0pIgoKIyBQb3NzaWJseSBCSVMv QmxhY2tiZXJyeSBjbGllbnRzLCB0aGUgZmlyc3QgbWF5IG5vdCBiZSB1bmlxdWUgZW5vdWdoCiAg IihVSUQgUkZDODIyLlNJWkUgRkxBR1MpIgogICIoVUlEIEZMQUdTIFJGQzgyMi5TSVpFIEJPRFku UEVFS1tIRUFERVIuRklFTERTIChYLVByaW9yaXR5IENvbnRlbnQtVHlwZSAiICsKICAgICAgImZy b20gdG8gY2MgYmNjIHN1YmplY3QgZGF0ZSApXSkiCiAgIihVSUQgRkxBR1MgUkZDODIyLlNJWkUg Qk9EWS5QRUVLW0hFQURFUi5GSUVMRFMgKFgtUHJpb3JpdHkgQ29udGVudC1UeXBlICIgKwogICAg ICAiRnJvbSBUbyBDYyBCY2Mgc3ViamVjdCBkYXRlKV0pIgogICIoVUlEIEZMQUdTIFJGQzgyMi5T SVpFIEJPRFkuUEVFS1tIRUFERVIuRklFTERTIChYLVByaW9yaXR5IENvbnRlbnQtVHlwZSAiICsK ICAgICAgIkZyb20gVG8gQ2MgQmNjIHN1YmplY3QgZGF0ZSBNZXNzYWdlLUlEKV0pIgoKIyBUaGUg UHJlIHNvbWV0aW1lcyBkb2VzIGEgVUlEIEZFVENIIHdpdGhvdXQgYXNraW5nIGZvciB0aGUgVUlE LCBhbmQgc29tZXRpbWVzCiMgYSByZWd1bGFyIEZFVENIIHdpdGggVUlECiAgIihVSUQgRkxBR1Mg SU5URVJOQUxEQVRFIEVOVkVMT1BFIEJPRFlTVFJVQ1RVUkUgQk9EWS5QRUVLW0hFQURFUl0pIgog ICIoRkxBR1MgSU5URVJOQUxEQVRFIEVOVkVMT1BFIEJPRFlTVFJVQ1RVUkUgQk9EWS5QRUVLW0hF QURFUl0pIgoKIyBPbmUgc2VhcmNoIHJlc3VsdCBwdXRzIHRoaXMgYXMgYSBOb2tpYSBTNjAsIHRo b3VnaCBpdHMgcmVhbGx5IGNsb3NlIHRvCiMgT3V0bG9vayBFeHByZXNzCiAgIihVSUQgRkxBR1Mg Qk9EWVNUUlVDVFVSRSBCT0RZLlBFRUtbSEVBREVSLkZJRUxEUyAoRnJvbSBTdWJqZWN0IFJlcGx5 LXRvICIgKwogICAgICAiVG8gQ2MgQmNjIE1lc3NhZ2UtSUQgUmV0dXJuLVJlY2VpcHQtVG8gWC1S ZXR1cm4tUmVjZWlwdC1UbyAiICsKICAgICAgIkRpc3Bvc2l0aW9uLU5vdGlmaWNhdGlvbi1UbyBE aXNwb3NpdGlvbi1Ob3RpZmljYXRpb24tT3B0aW9ucyldKSIKCiMgU29tZSBMRyBmZWF0dXJlIHBo b25lCiAgIihVSUQgRkxBR1MgUkZDODIyLlNJWkUgRU5WRUxPUEUgQk9EWVNUUlVDVFVSRSBCT0RZ LlBFRUtbSEVBREVSLkZJRUxEUyAiICsKICAgICAgIihQcmlvcml0eSBYLVByaW9yaXR5IEltcG9y dGFuY2UgUmVjZWl2ZWQpXSkiCiAgIihVSUQgRkxBR1MgUkZDODIyLlNJWkUgRU5WRUxPUEUgQk9E WVNUUlVDVFVSRSBCT0RZLlBFRUtbSEVBREVSXSAiICsKICAgICAgIkJPRFkuUEVFS1twYXJ0XTww LmNodW5rPikiCgojIFRoZSBsYXN0IG9uZSBvZiB0aGVzZSBpcyBkZWZpbml0ZWx5IFNldmVuLCB0 aGUgb3RoZXJzIGFyZSBwcmV0dHkgc2ltaWxhciwKIyBzbyBhc3N1bWluZyBqdXN0IGRpZmZlcmVu dCB2ZXJzaW9ucyAod3d3LnNldmVuLmNvbSBtb2JpbGUgY2FycmllcgojIG1haWwgY2xpZW50KQog ICIoRU5WRUxPUEUgSU5URVJOQUxEQVRFIFJGQzgyMi5TSVpFKSIKICAiKEVOVkVMT1BFIEJPRFkg SU5URVJOQUxEQVRFIFJGQzgyMi5TSVpFKSIKICAiKEVOVkVMT1BFIEJPRFlTVFJVQ1RVUkUgSU5U RVJOQUxEQVRFIFJGQzgyMi5TSVpFKSIKICAiKEVOVkVMT1BFIElOVEVSTkFMREFURSBSRkM4MjIu U0laRSBGTEFHUyBCT0RZU1RSVUNUVVJFIFVJRCkiCiAgIihFTlZFTE9QRSBJTlRFUk5BTERBVEUg UkZDODIyLlNJWkUgRkxBR1MgVUlEKSIKICAiKFgtZmFzdG1vYmlsZS1NZXNzYWdlLUlEKSIK --bcaec54a3252388bcc04c650352e-- From ned.freed@mrochek.com Thu Aug 2 16:07:57 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAB211E818C for ; Thu, 2 Aug 2012 16:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SSW5m6vOAnd for ; Thu, 2 Aug 2012 16:07:56 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 45D0311E8120 for ; Thu, 2 Aug 2012 16:07:53 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIL06EWCZ4006KW1@mauve.mrochek.com> for imapext@ietf.org; Thu, 2 Aug 2012 16:02:48 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Thu, 2 Aug 2012 16:02:42 -0700 (PDT) Message-id: <01OIL06B1GOO0006TF@mauve.mrochek.com> Date: Thu, 02 Aug 2012 15:37:47 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 02 Aug 2012 22:29:35 +0200" <501AE32F.90903@gulbrandsen.priv.no> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <01OIK0GA2IYO0006TF@mauve.mrochek.com> <01OIKQHRTLOU0006TF@mauve.mrochek.com> <501AE32F.90903@gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:07:57 -0000 > Ned answers Adrien: > >> I agree it complicates the task for client authors, but I'm not certain > >> that this would necessarily affect end users. > > > > You have a lot of faith in client authors. Faith which appears to me to > > be supported by evidence of past behavior. > At least we can have faith that the proposal will reappear. That doesn't mean it's a good idea. > Imap move is progressing nicely. I think we can last call it in a week > or two. That draft exists because people keep asking for it, and at some > point it's better to just do a reasonable job of an extension than to > keep repeating no no no and you should be doing that not this. It's > quite clear that clients will have to continue supporting > copy/store/expunge, but still, move is wanted. > Imap submit hasn't had quite the level of requests that imap move has > had. Not even close. And besides, it's an apples to oranges comparison. Wanting to be able to submit over the same port while resuing credentials doesn't necessarily translate into doing it the way that's being proposed. Whereas wanting to move messages around in an atomic fashion in IMAP necessarily translates into something that isn't going to deviate that much from the current proposal. > But the same argument does apply, correspondingly weaker. No, not really. IMAP MOVE provides semantics that are a PITA to implement otherwise. It makes sense for clients even when they have to support servers that don't offer it - the marginal utility is that great. IMAP SUBMIT as proposed, OTOH, provides no new semantics. In fact it provides a subset, and IMO an unreasonably small subset. And then it locks you in to that subset. Very different thing. And if you're assuming that client authors are going to jump on stuff that doesn't offer them direct and obvious benefit as implementers, then I have to ask why that hasn't happened in the case of RFC 6186? > The > argument about broken packet filters does, too. And clients _have_ been > good about supporting some simple extensions. 4978 quite shocked me. > Personally I like 6186 very much. Personally. I don't. It has various problems, largely due to the wierd way DNS is accessed and/or provisioned in some environments. I'm not overly fond of the available DNS libraries or servers either. But here's the thing. When it comes to service discovery, you have to make a fundamental choice: Piggyback on an existing implemented prototol or build something new. Building something new has *huge* associated cost: Development, implementation, and most of all, deployment. And it's not like it hasn't been tried. Remember all those SRVLOC servers? (Yeah, me neither.) Reusing breaks down further into two cases: Reusing the protocol versus reusing the service. This is where HTTP falls short - you're still talking about building and deploying a new service if you use it. DNS, OTOH, is deployed and even has something in it (SRV records) with the correct basic semantics. That's why RFC 6186 was and is the right choice. Given my druthers I'd prefer something purpose-built to solve the problem, but that's not going to happen, and I'm not foolish enough to think it will. I'll also note that even if the SUBMIT problem were to magically vanish you still have the which of the four mailbox access protocols should you use. A problem which, by the way, interacts with the SUBMIT-in-IMAP situation in some interesting ways. Ned From ned.freed@mrochek.com Thu Aug 2 16:42:03 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B1721E8039 for ; Thu, 2 Aug 2012 16:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVIobgpE8VtH for ; Thu, 2 Aug 2012 16:42:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id F1A3D21E8044 for ; Thu, 2 Aug 2012 16:42:01 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIL1CQ1MC0006D38@mauve.mrochek.com> for imapext@ietf.org; Thu, 2 Aug 2012 16:36:55 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Thu, 2 Aug 2012 16:36:49 -0700 (PDT) Message-id: <01OIL1CMET3O0006TF@mauve.mrochek.com> Date: Thu, 02 Aug 2012 16:03:18 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 02 Aug 2012 15:07:42 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OIKQHRTLOU0006TF@mauve.mrochek.com> To: Brandon Long Cc: Adrien de Croy , Arnt Gulbrandsen , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 23:42:03 -0000 > On Thu, Aug 2, 2012 at 2:26 PM, Adrien de Croy wrote: > > > > ------ Original Message ------ > > From: "Ned Freed" > > > >> > >> Actually, it's far simpler and provides much more flexibility. I rather > >> suspect I could implement it in a couple of hours, whereas a properly > >> designed submit extension would take far longer and require far more > >> testing and QA. The only part that's in any way tricky is the handling of > >> disconnects. > >> > > I did think a bit about this before I replied. > > > > Any time the submission service is a different physical process to the > > IMAP service, you have a problem of transmission of credentials. This > > would require the client to tunnel auth through the IMAP server to the > > submission server, and therefore require configuration for submission > > credentials. So that problem remains. You could mandate the same creds be > > used, but that would probably cause problems, or at best place limitations > > on how submission and IMAP are deployed (must be in same auth realm). > > Maybe that's not so bad. > > > I'm confused, are there really that many systems which would have separate > trust for IMAP and SMTP? You mean IMAP and SUBMIT (even if it's done over port 25, the semantics are different from those of SMTP). In my experience the answer is no, which is why I think it makes sense to pass the credentials out of band in a tunneling scheme. And there certainly are plenty of clients that force you to enter the credentials separately instead of making that an option you have to enable. I'm fairly confident that's just obsolete, or perhaps just poor, client design. > The servers should be in the same trust domain. I would imagine the > default for most open source servers on Unix would be something like > calling /usr/lib/sendmail with -f of the user. That may work for some extremely simplistic low end cases, but there's almost always more to it than that. But it's not like this is uncharted territory. A wide variety of service proxies have been commonplace for a long time. > For us, we have "send > message" on the Gmail app server, and that server is set to trust us to > choose who to send as (or we can just pass the internal credentials, but we > have to do that for many other requests already). There's already a mail > server in the same trust domain to delivery mail to the IMAP server, after > all. > If your server really makes this hard, then don't implement SUBMIT. As > with almost every IMAP extension ever made, the clients have to support the > server not offering it. This isn't why the current proposal is a bad idea. > > I don't know how you'd avoid re-transmission of the message from the > > client though, unless the IMAP server proxied the tunneled SMTP, and > > inspected the protocol and you had a BURL-like extension that could access > > the message content. At least in this case, you wouldn't have inter-domain > > trust issues with a submit server trying to retrieve an IMAP message for > > submission. > > > It removes the re-transmission from the client to the server, which is > often over much slower/expensive links. Piping the message to > /usr/lib/sendmail hardly qualifies as the same as the client sending the > message twice over a 2G mobile connection. Um, you appear to be in agreement with the text you're arguing with. My point here (which the text you're quoting was responding to) isn't not that the general *idea* of IMAP SUBMIT is bad, but rather than the current proposal is a poor one. > > The only thing this really would solve is the TCP port access. > > > It solves the client configuration problem, complete with all the possible > error cases that are associated with every service that needs to be > configured. In fact, I imagine for the average linux user > self-installation, it also makes it easier to install, as they need to make > passwords work with only a single service (the IMAP server) and not two > services (admittedly its been a while, but smtp-auth for MSA is annoying to > configure on a bunch of the popular mail servers). I doubt if any of these proposals will alter that significantly. Even if you have a means of proxying the credentials over, that necessarily means the services have to be operating in the same authentication realm, and making that happen is a big part of the annoyance. Ned From adrien@qbik.com Thu Aug 2 17:05:41 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BEC21F8BE2 for ; Thu, 2 Aug 2012 17:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.285 X-Spam-Level: X-Spam-Status: No, score=-3.285 tagged_above=-999 required=5 tests=[AWL=-1.286, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0hgSS9xB6i5 for ; Thu, 2 Aug 2012 17:05:40 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 51A5D21F8BE1 for ; Thu, 2 Aug 2012 17:05:40 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.6 (Build 3449)) with SMTP id <0019173000@smtp.qbik.com>; Fri, 03 Aug 2012 12:05:39 +1200 From: "Adrien W. de Croy" To: "Ned Freed" , "Brandon Long" Date: Fri, 03 Aug 2012 00:05:38 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <01OIL1CMET3O0006TF@mauve.mrochek.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: Arnt Gulbrandsen , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 00:05:42 -0000 =EF=BB=BF ------ Original Message ------ From: "Ned Freed" >You mean IMAP and SUBMIT (even if it's done over port 25, the semantics= are >different from those of SMTP). In my experience the answer is no, which= is why >I think it makes sense to pass the credentials out of band in a tunneling >scheme. > To pass credentials requires either a) like you say out of band (e.g. kerberos) + AUTH=3DEXTERNAL or similar b) pre-arranged trust between the IMAP server and the submit server so=20 that the token identifying the client can be assumed trustworthy - this=20 would require an SMTP extension probably. neither of these is a problem if the submit server and IMAP server are=20 from the same vendor, but otherwise we'd want to standardise on that=20 aspect as well. >And there certainly are plenty of clients that force you to enter the >credentials separately instead of making that an option you have to enable= . I'm >fairly confident that's just obsolete, or perhaps just poor, client design= . > still see this a fair bit - esp Outlook. The checkbox for using same=20 creds is still a decision point for the user, and source of errors. I think it just reflects the fact that it's a lot less likely you'll=20 need creds for submission (< 100%) than for retrieval (100%). > > >Um, you appear to be in agreement with the text you're arguing with. > >My point here (which the text you're quoting was responding to) isn't not= that >the general *idea* of IMAP SUBMIT is bad, but rather than the current prop= osal >is a poor one. > so how would we make it a good one? I'm open to anything that=20 basically=20 a) solves port access / creds b) solves multiple transmission c) isn't over-complex d) doesn't create more/worse issues than it solves (esp=20 security-related / cred leakage) BURL fails on c and d IMO. Does anyone have any stats on support for BURL in SUBMIT servers in the=20 wild? In the end, there's really only 3 options. 1) PUSH (SUBMIT some way via IMAP connection, either tunneled, or=20 proxied or something like the current proposal) 2) PULL (BURL from SMTP/SUBMIT) 3) do nothing (leave it in the too hard / not worth it basket, and wait=20 for the next time we have this discussion :-) ). In terms of constraints, in our use-cases (again restricted), requiring=20 same auth domain for submission and IMAP is no real problem, since it's=20 most often the case anyway. Adrien From tss@iki.fi Thu Aug 2 17:54:01 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D300621F8AB2 for ; Thu, 2 Aug 2012 17:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.523 X-Spam-Level: X-Spam-Status: No, score=-110.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TC3-tDZh0ul3 for ; Thu, 2 Aug 2012 17:54:01 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id DDE5B21F8AAF for ; Thu, 2 Aug 2012 17:54:00 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 9EE291AE8359; Fri, 3 Aug 2012 03:53:59 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Fri, 3 Aug 2012 03:53:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Adrien W. de Croy" X-Mailer: Apple Mail (2.1084) Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 00:54:01 -0000 On 3.8.2012, at 3.05, Adrien W. de Croy wrote: > Does anyone have any stats on support for BURL in SUBMIT servers in = the wild? BURL was implemented by Apple as a patch for Postfix, but it never got = included. Synchronica Mobile Gateway also advertises BURL. I've seen no other servers advertise this in port 25, but I don't know = about submission port (where it obviously is more useful/likely). From adrien@qbik.com Thu Aug 2 18:29:21 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E709821F8C36 for ; Thu, 2 Aug 2012 18:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcaZq-SZM7Di for ; Thu, 2 Aug 2012 18:29:21 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id B259D21F8C33 for ; Thu, 2 Aug 2012 18:29:20 -0700 (PDT) Received: From [192.168.0.10] (unverified [192.168.0.10]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v7.2.6 (Build 3449)) with SMTP id <0019173108@smtp.qbik.com>; Fri, 03 Aug 2012 13:29:18 +1200 From: "Adrien W. de Croy" To: "Timo Sirainen" Date: Fri, 03 Aug 2012 01:29:18 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Cc: "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Adrien W. de Croy" List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 01:29:22 -0000 =EF=BB=BF so what's the general feeling about the success / worthiness of BURL=20 then? A considerable effort went into the standardisation of it. It was=20 obviously felt that the retransmission issue was worth solving. As soon as the decision was made that SMTP should pull the data from=20 another source, where it ended up was pretty much a foregone conclusion=20 dictated by the issues that need resolving. We've avoided adding it to our SMTP server for several reasons, maybe=20 my reasons are shared by other authors. =20 These are mainly: a) complexity: For a SMTP/SUBMIT server to retrieve the message, it needs to * decode the URL * check it * connect to the server * establish credentials * select a mailbox * FETCH the body/part whatever and deal with the myriad of error conditions that can arise at each of=20 these steps b) investment: I don't have any IMAP client code. I have IMAP server code, SMTP=20 server code, and SMTP client code. IMAP client code is non-trivial,=20 esp when dealing with the plethora of optional IMAP extensions that may=20 come into play. Cost to develop this is on the high side it seems for=20 this function. c) deployability It's hard for a client to pass credentials to an SMTP/SUBMIT server to=20 enable it to auth to an IMAP server in a way that doesn't offer creds=20 to passive snoopers. So, you have to secure the transport with TLS. =20 This has a bunch of deployment / customer education issues. I guess the idea was to allow BURL to fetch message content from any=20 sort of source, but for every different one, the SMTP server needs to=20 implement a protocol binding (client) of some sort. This isn't that=20 scalable, and we may not have that many current real (non-hypothetical)=20 use-cases other than IMAP. So, if we were to conclude (I don't know if we're there yet) that BURL=20 failed, and that the problem is still worth solving, that only leaves=20 some form of push via IMAP somehow. But that's a few ifs. Adrien ------ Original Message ------ From: "Timo Sirainen" To: "Adrien W. de Croy" Cc: "imapext@ietf.org" Sent: 3/08/2012 12:53:59 p.m. Subject: Re: [imapext] Mail submission over IMAP >On 3.8.2012, at 3.05, Adrien W. de Croy wrote: > > >> >>Does anyone have any stats on support for BURL in SUBMIT servers in the= wild? >> > > >BURL was implemented by Apple as a patch for Postfix, but it never got = included. > >Synchronica Mobile Gateway also advertises BURL. > >I've seen no other servers advertise this in port 25, but I don't know = about submission port (where it obviously is more useful/likely). > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext > > From ned.freed@mrochek.com Thu Aug 2 18:35:57 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1228611E80A6 for ; Thu, 2 Aug 2012 18:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, J_CHICKENPOX_48=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuyuaONhM-ir for ; Thu, 2 Aug 2012 18:35:56 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 10E7D11E8072 for ; Thu, 2 Aug 2012 18:35:56 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIL5HBH2SW002W28@mauve.mrochek.com> for imapext@ietf.org; Thu, 2 Aug 2012 18:35:09 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Thu, 2 Aug 2012 18:35:02 -0700 (PDT) Message-id: <01OIL5H6W3A20006TF@mauve.mrochek.com> Date: Thu, 02 Aug 2012 18:02:51 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 03 Aug 2012 00:05:38 +0000" References: <01OIL1CMET3O0006TF@mauve.mrochek.com> To: "Adrien W. de Croy" Cc: Brandon Long , Arnt Gulbrandsen , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 01:35:57 -0000 >  > ------ Original Message ------ > From: "Ned Freed" > >You mean IMAP and SUBMIT (even if it's done over port 25, the semantics are > >different from those of SMTP). In my experience the answer is no, which is why > >I think it makes sense to pass the credentials out of band in a tunneling > >scheme. > > > To pass credentials requires either > a) like you say out of band (e.g. kerberos) + AUTH=EXTERNAL or similar > b) pre-arranged trust between the IMAP server and the submit server so > that the token identifying the client can be assumed trustworthy - this > would require an SMTP extension probably. A simple shared secret should suffice. > neither of these is a problem if the submit server and IMAP server are > from the same vendor, but otherwise we'd want to standardise on that > aspect as well. Seems reasonable. > >And there certainly are plenty of clients that force you to enter the > >credentials separately instead of making that an option you have to enable. I'm > >fairly confident that's just obsolete, or perhaps just poor, client design. > > > still see this a fair bit - esp Outlook. The checkbox for using same > creds is still a decision point for the user, and source of errors. > I think it just reflects the fact that it's a lot less likely you'll > need creds for submission (< 100%) than for retrieval (100%). Not that it matters, but... The <100% is certainly true for SMTP used for submission, and of course there's a lot of that, albeit less and less all the time due to spam. For SUBMIT, given the main use-case for deploying it is authentication, I rather suspect that number is pretty close to 100%. There are also some odd cases where unauthenticated IMAP is useful. But again, not really relevant. > > > > > >Um, you appear to be in agreement with the text you're arguing with. > > > >My point here (which the text you're quoting was responding to) isn't not that > >the general *idea* of IMAP SUBMIT is bad, but rather than the current proposal > >is a poor one. > > > so how would we make it a good one? First and foremonst, a good proposal is necessarily future-proof. And the evidence supporting the need for this is overwhelming: Just compare what's involved with mail submission as little as 10 years ago with what is done now. Future-proofing means supporting future SMTP extensions regardless of form. The simplest way to do that is with a tunnel. An alternative would be something modelled on batch SMTP with some form of extension discovery, but that's a lot more work to implement. > I'm open to anything that basically > a) solves port access / creds > b) solves multiple transmission > c) isn't over-complex > d) doesn't create more/worse issues than it solves (esp > security-related / cred leakage) > BURL fails on c and d IMO. If you believe BURL fails on D, I think there's some misunderstanding of the security model involved. It's actually quite strong and done properly leaks nothing. As for C, the problem, as pointed out previously, is that BURL is designed for a very general case. I don't really see a difficulty with profiling BURL down to a special case where essentially regular IMAP URLs could be used with none of the BURL add-ons. > Does anyone have any stats on support for BURL in SUBMIT servers in the > wild? We support it. Don't have any more general data. > In the end, there's really only 3 options. > 1) PUSH (SUBMIT some way via IMAP connection, either tunneled, or > proxied or something like the current proposal) Right. Nothing says you can't use push in a tunneling scenario, although it does make it more complex since it can no longer be a simple modal thing. > 2) PULL (BURL from SMTP/SUBMIT) > 3) do nothing (leave it in the too hard / not worth it basket, and wait > for the next time we have this discussion :-) ). > In terms of constraints, in our use-cases (again restricted), requiring > same auth domain for submission and IMAP is no real problem, since it's > most often the case anyway. As I've said previously, I don't think that's an unreasonable restriction. In fact I don't really see it as a restriction at all, because the minute you put separate authentication into any scheme you can come up with all you're really solving is the multiple port problem. And I'm sorry, but I don't buy the whole, "Ohh, opening one more port on the firewall is soo HHHAAAARRRDDD! Waah!" argument for even a femtosecond, especially when the very same firewall that's so bloody hard to configure is the one that's does broken deep inspection and spazzes big-time on any extension being discussed here. (Did I forget to mention that crap firewalls are a *major* support headache?) The case for single port in in the mobile space, where if anything the liklihood of a common domain is higher and the need for simple configuration much greater. But I'll warn you that while a tunneling approach removes many objections, including a lot of my own, it's still going to be a major uphill slog to get it through the process. I recommend full provisions and a very tough skin. Ned P.S. I'll again repeat that while I'm a lot happier with something that's future-prooffed and which can be supported without a lot of additional code, I'm still not convinced the benefits really outweigh the costs. From ned.freed@mrochek.com Thu Aug 2 19:09:12 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B331A21F8BD7 for ; Thu, 2 Aug 2012 19:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqqXuActyUmc for ; Thu, 2 Aug 2012 19:09:12 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBA821F8650 for ; Thu, 2 Aug 2012 19:09:12 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIL6I7ZB1C006600@mauve.mrochek.com> for imapext@ietf.org; Thu, 2 Aug 2012 19:04:07 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Thu, 2 Aug 2012 19:04:01 -0700 (PDT) Message-id: <01OIL6I4H85Q0006TF@mauve.mrochek.com> Date: Thu, 02 Aug 2012 19:02:45 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 03 Aug 2012 03:53:59 +0300" MIME-version: 1.0 Content-type: TEXT/PLAIN References: To: Timo Sirainen Cc: "Adrien W. de Croy" , imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 02:09:12 -0000 > On 3.8.2012, at 3.05, Adrien W. de Croy wrote: > > Does anyone have any stats on support for BURL in SUBMIT servers in the wild? > BURL was implemented by Apple as a patch for Postfix, but it never got included. > Synchronica Mobile Gateway also advertises BURL. > I've seen no other servers advertise this in port 25, but I don't know about submission port (where it obviously is more useful/likely). Given that BURL is only supposed to be enabled on SUBMIT, and it should show up only when authenticated, it's next to impossible to scan for. Ned From blong@google.com Thu Aug 2 23:21:18 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58A721E8040 for ; Thu, 2 Aug 2012 23:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.862 X-Spam-Level: X-Spam-Status: No, score=-102.862 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB0lD+slGcxn for ; Thu, 2 Aug 2012 23:21:17 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id ACE0521E8034 for ; Thu, 2 Aug 2012 23:21:17 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so657175obb.31 for ; Thu, 02 Aug 2012 23:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=WMGvbjVEnfUr5FH/wNPiEWKoo5cBRvk7o5EO4nTRknM=; b=DPJZ5TFZzgHjuH2Z0RltPQxI2y1rbYfl9S44Qxolzjww29UtAZNVqOSGI5IuY51vc0 ukUkQbd3C+3lC+VMQvKhXi9jmatZdj/kiXzNTMayUaHw3a/lE+xzLTmXjr0mljJ+mQ40 OnLv+lI9O5migaspRT/BE76tILC/cC6zr3MFEFK9HUaJLRWQJ6GLDiH6RIuiagVVhd88 LEOOA6iHXBytjktZlo9+Q5SIhRULGyllHez81YBapfdxAowMocjXZQ9UunQ4Kgwj1FSP cbFsLJ3L2CdkaIWvLNfJz2TOPPakhbFVvKH66xy45mywKUfUpIjwq3tXA3vMMPjdxS7K Lo4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=WMGvbjVEnfUr5FH/wNPiEWKoo5cBRvk7o5EO4nTRknM=; b=jAfK9io4GHfZCjMlAOVBzbajVkWX3EugKAi0TIuJjtDPmdaSqJ5mbo5xS9DNH1Y5Ht JgQg5FAMQ/oVVwiClhVIjWqgD/eJ2bbd8VRtFSCRaWoYIQ73VDy5+po0Nxw+afX9m7or 1vx4E7HDRnzQL2LlOfVrbGI8Uma+qeO7Wdl3e8018fcpGE9GM6YZ2xrNy/t4iLZY0Xj/ gt02jTcWN5a/l50D4DMd/gsX2EpT3HuBOZsXsSiYwNxzA86YQ605r1i2+nPr8l7mlTTA zAcTCvvSx+Qr7rtB40H65UQkTlZTpzYGaE9zsHzP+WjH2ye02/mexIoPtE6lytFwC0Xw 6ukg== Received: by 10.182.131.73 with SMTP id ok9mr1662815obb.19.1343974877146; Thu, 02 Aug 2012 23:21:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.131.73 with SMTP id ok9mr1662789obb.19.1343974876988; Thu, 02 Aug 2012 23:21:16 -0700 (PDT) Received: by 10.76.6.209 with HTTP; Thu, 2 Aug 2012 23:21:16 -0700 (PDT) In-Reply-To: <01OIL5H6W3A20006TF@mauve.mrochek.com> References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> Date: Thu, 2 Aug 2012 23:21:16 -0700 Message-ID: From: Brandon Long To: Ned Freed Content-Type: multipart/alternative; boundary=e89a8f64790b2143a804c65689e2 X-System-Of-Record: true X-Gm-Message-State: ALoCoQllzkQuKJdNGsHjH7Y/4R2BAYJp/xEWtAmANFKh3mSLbL82diFO5UKW5M922nv25BnPzY7+TIMW4lZy/2fqoD5wOmvmaUmOOSuMY9gqII8ruMt32SfgG5iSN7E1XhVllCL1ty6lWpyzFjUx2y9lnBt6WiNxzWu6DHes9JvTablRPyKc8/rSyUMYC+OJRSqUdEnRij+9 Cc: "Adrien W. de Croy" , Arnt Gulbrandsen , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 06:21:18 -0000 --e89a8f64790b2143a804c65689e2 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 2, 2012 at 6:02 PM, Ned Freed wrote: > First and foremonst, a good proposal is necessarily future-proof. And the >> > evidence supporting the need for this is overwhelming: Just compare what's > involved with mail submission as little as 10 years ago with what is done > now. > Like what? I ask because smtp.gmail.com seems to be getting along fine for MSA with nothing particularly special, and nothing that isn't protocol specific. For all the complaints about our IMAP implementation, I haven't heard anyone clamoring for any smtp extensions we should implement. > Future-proofing means supporting future SMTP extensions regardless of > form. The > simplest way to do that is with a tunnel. An alternative would be something > modelled on batch SMTP with some form of extension discovery, but that's a > lot > more work to implement. I think this also focuses too much on SMTP. I don't want to embed an smtp server into my IMAP server, I don't want my IMAP server to act as a network proxy to an SMTP server. In some cases, SMTP is already a protocol conversion and its probably easier to implement this using something else anyways (ie, shell out to /usr/lib/sendmail in the most basic case, I'm sure Exchange can just call the appropriate MAPI function, we'd just call the gmail app servers send mail method). Sending mail is "send this message from me to these addresses". IMAP already has a model for what messages look like. No need for 8BITMIME or extensions like that, no need for SMTPUTF8. No need for any of the auth extensions, auth sharing would be up to the imap server to implement if necessary. DSN, sure. It would need to be optional since not all systems support it anyways. Which is basically what this proposal was. APPEND the message to the server, then tell the server to send it from foo to bar. I feel like a lot of the hand-wringing about this has been very meta without very specific use cases or problems that will occur. Might be implemented incorrectly, might not be implemented, might hit a bad stateful firewall... these are all true for each of the existing IMAP extensions... hasn't seemed to keep us from having a lot of IMAP extensions. As for future proof, assuming any new extension will have wide-spread adoption in either smtp or imap seems pretty unlikely without some huge benefits. If some great new SMTP extension comes along that just has to be used and is being adopted wildly, I can't imagine there would be that much impediment to also adopting a related extension for IMAP. Worst case, we'd be right back where we are now, with clients using two protocols. Brandon --e89a8f64790b2143a804c65689e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, A= ug 2, 2012 at 6:02 PM, Ned Freed <ned.freed@mrochek.c= om> wrote:
First and for= emonst, a good proposal is necessarily future-proof. And the
evidence supporting the need for this is overwhelming: Just compare what= 9;s
involved with mail submission as little as 10 years ago with what is done n= ow.

Like what? =A0I ask because smtp.gmail.com seems to be getting along fin= e for MSA with nothing particularly special, and nothing that isn't pro= tocol specific. =A0For all the complaints about our IMAP implementation, I = haven't heard anyone clamoring for any smtp extensions we should implem= ent.
=A0
Future-proofing means supporting future SMTP extensions regardless of form.= The
simplest way to do that is with a tunnel. An alternative would be something=
modelled on batch SMTP with some form of extension discovery, but that'= s a lot
more work to implement.

I think this also f= ocuses too much on SMTP. =A0I don't want to embed an smtp server into m= y IMAP server, I don't want my IMAP server to act as a network proxy to= an SMTP server. =A0In some cases, SMTP is already a protocol conversion an= d its probably easier to implement this using something else anyways (ie, s= hell out to /usr/lib/sendmail in the most basic case, I'm sure Exchange= can just call the appropriate MAPI function, we'd just call the gmail = app servers send mail method).

Sending mail is "send this message from me to these addresses= ". =A0IMAP already has a model for what messages look like. =A0No need= for 8BITMIME or extensions like that, no need for SMTPUTF8.=A0
<= br>
No need for any of the auth extensions, auth sharing would be up= to the imap server to implement if necessary.

DSN= , sure. =A0It would need to be optional since not all systems support it an= yways.

Which is basically what this proposal was. =A0APPEND th= e message to the server, then tell the server to send it from foo to bar.

I feel like a lot of the hand-wringing about this h= as been very meta without very specific use cases or problems that will occ= ur.

Might be implemented incorrectly, might not be implemen= ted, might hit a bad stateful firewall... these are all true for each of th= e existing IMAP extensions... hasn't seemed to keep us from having a lo= t of IMAP extensions.

As for future proof, assuming any new extension will ha= ve wide-spread adoption in either smtp or imap seems pretty unlikely withou= t some huge benefits. =A0If some great new SMTP extension comes along that = just has to be used and is being adopted wildly, I can't imagine there = would be that much impediment to also adopting a related extension for IMAP= . =A0Worst case, we'd be right back where we are now, with clients usin= g two protocols.

Brandon
--e89a8f64790b2143a804c65689e2-- From arnt@gulbrandsen.priv.no Fri Aug 3 01:41:29 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0A1221F8D76 for ; Fri, 3 Aug 2012 01:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPlrkn0tTlQC for ; Fri, 3 Aug 2012 01:41:29 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id D030921F8D75 for ; Fri, 3 Aug 2012 01:41:28 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 0FC2CF8C1C1; Fri, 3 Aug 2012 08:41:27 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1343983286-23170-23169/10/3; Fri, 3 Aug 2012 08:41:26 +0000 Message-Id: <501B8EC7.9040708@gulbrandsen.priv.no> Date: Fri, 3 Aug 2012 10:41:43 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <01OIK0GA2IYO0006TF@mauve.mrochek.com> <01OIKQHRTLOU0006TF@mauve.mrochek.com> <501AE32F.90903@gulbrandsen.priv.no> <01OIL06B1GOO0006TF@mauve.mrochek.com> In-Reply-To: <01OIL06B1GOO0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 08:41:29 -0000 On 08/03/2012 12:37 AM, Ned Freed wrote: > And if you're assuming that client authors are going to jump on stuff > that doesn't offer them direct and obvious benefit as implementers, It's a bit of a mystery to me what gains wide usage and what not. Simplicity seems to help, visible benefits too. > then I have > to ask why that hasn't happened in the case of RFC 6186? I think that hasn't happened for four reasons. 1. 6186 is late. It's also recent, so maybe a conclusion is premature. 2. Few resolver APIs offer SRV queries, so it's bothersome to implement. 3. There's a competitor which offers better answers in many cases (I forget the name, it's a combination of an algorithm and a database from mozilla.org). 4. It doesn't fit well into a popular client design: Do lookups at install time (the "discovery phase") and expect that to never ever change. Arnt From alexey.melnikov@isode.com Fri Aug 3 07:28:18 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F6721F8D15 for ; Fri, 3 Aug 2012 07:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRtOE9MQOKsS for ; Fri, 3 Aug 2012 07:28:17 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id CB06D21F8D06 for ; Fri, 3 Aug 2012 07:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1344004176; d=isode.com; s=selector; i=@isode.com; bh=t8aLQDEKtfWdHOPR5lIyL7LWl/8klTplg+hLrymI/e8=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=wSyc+cdYjL1RkStkQJgNDYGltNLY6ZTN52FRQhSsPO2wQCxvjz4lZalTuCMhBftosqN5pa B+MaCAQQTRKJtso+PtacviWF1Gq8m5Ur2k+QSen1kXwIkKmcr9SlPcbD2WKmes6IKY7GKB jBxlhbMYkNu1AtgAPQnvqAdWcOq9jnA=; Received: from [10.71.15.50] (209-207-95-33.ip.van.radiant.net [209.207.95.33]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 3 Aug 2012 15:29:35 +0100 References: <01OIK0GA2IYO0006TF@mauve.mrochek.com> <01OIKQHRTLOU0006TF@mauve.mrochek.com> <501AE32F.90903@gulbrandsen.priv.no> <01OIL06B1GOO0006TF@mauve.mrochek.com> <501B8EC7.9040708@gulbrandsen.priv.no> In-Reply-To: <501B8EC7.9040708@gulbrandsen.priv.no> Message-Id: <27AA9C8D-DAE8-4444-AB3E-102A34942143@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Fri, 3 Aug 2012 07:28:23 -0700 To: Arnt Gulbrandsen MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:28:18 -0000 On 3 Aug 2012, at 01:41, Arnt Gulbrandsen wrote: > On 08/03/2012 12:37 AM, Ned Freed wrote: >> And if you're assuming that client authors are going to jump on stuff >> that doesn't offer them direct and obvious benefit as implementers, >=20 > It's a bit of a mystery to me what gains wide usage and what not. Simplici= ty seems to help, visible benefits too. >=20 >> then I have >> to ask why that hasn't happened in the case of RFC 6186? >=20 > I think that hasn't happened for four reasons. >=20 > 1. 6186 is late. It's also recent, so maybe a conclusion is premature. I hope so. And of course this is not a good argument in favour of Mail Submission over I= MAP. >=20 > 2. Few resolver APIs offer SRV queries, so it's bothersome to implement. Stupid OSes, although this is changing. >=20 > 3. There's a competitor which offers better answers in many cases (I forge= t the name, it's a combination of an algorithm and a database from mozilla.o= rg). A static database is not going to work long term. I am also curious to know what is missing in 6186. >=20 > 4. It doesn't fit well into a popular client design: Do lookups at install= time (the "discovery phase") and expect that to never ever change. I don't agree with this. RFC 6186 allows for lookups at later times. >=20 From alexey.melnikov@isode.com Fri Aug 3 07:47:44 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A49DA21F8DD2 for ; Fri, 3 Aug 2012 07:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMcIPR3cQ7O8 for ; Fri, 3 Aug 2012 07:47:44 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id DA65C21F8D9F for ; Fri, 3 Aug 2012 07:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1344005343; d=isode.com; s=selector; i=@isode.com; bh=VMiQppFfT0cMTbyGKfFziiW7mFxc5cTHhA7eKOe+M1E=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=jGDttS9TKrInh0GvoURT/kJtTzxAVM208nCqg+31DmEt1V7h6KxPpfUEPmj/8DV3zUCnV2 zlgA4pPZuR8YDNeGPno92En5soLczNjGSavHNKqrfvtYDM0nPKSsFdKm4bprs5hYSx/D9g hZ8VoyU2AJiReGsJ5LBmW7DYxoBQCgk=; Received: from [10.71.15.50] (209-207-95-33.ip.van.radiant.net [209.207.95.33]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 3 Aug 2012 15:48:39 +0100 References: In-Reply-To: Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Fri, 3 Aug 2012 07:38:21 -0700 To: Timo Sirainen MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: "Adrien W. de Croy" , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:47:44 -0000 On 2 Aug 2012, at 17:53, Timo Sirainen wrote: > On 3.8.2012, at 3.05, Adrien W. de Croy wrote: >=20 >> Does anyone have any stats on support for BURL in SUBMIT servers in the w= ild? >=20 > BURL was implemented by Apple as a patch for Postfix, but it never got inc= luded. >=20 > Synchronica Mobile Gateway also advertises BURL. >=20 > I've seen no other servers advertise this in port 25, but I don't know abo= ut submission port (where it obviously is more useful/likely). Isode M-Switch does it on the Submission Port. From arnt@gulbrandsen.priv.no Fri Aug 3 07:48:02 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCC421F8DD6 for ; Fri, 3 Aug 2012 07:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unocG46eXLaN for ; Fri, 3 Aug 2012 07:48:02 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id DF19521F8D9F for ; Fri, 3 Aug 2012 07:48:01 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 54209F8E5B1; Fri, 3 Aug 2012 14:48:01 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1344005280-23170-23169/10/4; Fri, 3 Aug 2012 14:48:00 +0000 Message-Id: <501BE4B1.4000609@gulbrandsen.priv.no> Date: Fri, 3 Aug 2012 16:48:17 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <01OIK0GA2IYO0006TF@mauve.mrochek.com> <01OIKQHRTLOU0006TF@mauve.mrochek.com> <501AE32F.90903@gulbrandsen.priv.no> <01OIL06B1GOO0006TF@mauve.mrochek.com> <501B8EC7.9040708@gulbrandsen.priv.no> <27AA9C8D-DAE8-4444-AB3E-102A34942143@isode.com> In-Reply-To: <27AA9C8D-DAE8-4444-AB3E-102A34942143@isode.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 14:48:02 -0000 On 08/03/2012 04:28 PM, Alexey Melnikov wrote: >> >3. There's a competitor which offers better answers in many cases (I = forget the name, it's a combination of an algorithm and a database from = mozilla.org). > A static database is not going to work long term. I think it's a web thing. You query via GET to a specified URL, and the=20 server tells you what it knows about the domain that interests you. > I am also curious to know what is missing in 6186. The ability to override when the domain owner doesn't do the right thing. Overriding doesn't really scale, but if you try mail.,=20 imap. and the web database thingy has a list of a few hundred=20 big well-known exceptions, your results will be good right away. You=20 don't need to wait for site admins to add SRV records before your=20 results will be good. >> >4. It doesn't fit well into a popular client design: Do lookups at = install time (the "discovery phase") and expect that to never ever = change. > I don't agree with this. RFC 6186 allows for lookups at later times. Exactly. If a client's design doesn't, 6186 is at odds with the client. Yes, you can just look up and store, but once you start doing that=20 someone will tell you "fix the bug properly, look it up later" and then=20 it turns into a more complicated fix, and before you know it the simple=20 fix doesn't get implemented and shipped. Been there, done that, and once=20 lost a customer because various people shouted incompatibly at me and in=20 the end I didn't satisfy any of them. Arnt From ned.freed@mrochek.com Fri Aug 3 14:24:54 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E6B11E80A6 for ; Fri, 3 Aug 2012 14:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnvkhEpBVA8F for ; Fri, 3 Aug 2012 14:24:54 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 377F511E8091 for ; Fri, 3 Aug 2012 14:24:54 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIMAV2TOYO004KOU@mauve.mrochek.com> for imapext@ietf.org; Fri, 3 Aug 2012 14:19:48 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Fri, 3 Aug 2012 14:19:43 -0700 (PDT) Message-id: <01OIMAUZGUFG0006TF@mauve.mrochek.com> Date: Fri, 03 Aug 2012 05:36:27 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Thu, 02 Aug 2012 23:21:16 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> To: Brandon Long Cc: "Adrien W. de Croy" , Arnt Gulbrandsen , Ned Freed , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 21:24:54 -0000 > On Thu, Aug 2, 2012 at 6:02 PM, Ned Freed wrote: > > First and foremonst, a good proposal is necessarily future-proof. And the > >> > > evidence supporting the need for this is overwhelming: Just compare what's > > involved with mail submission as little as 10 years ago with what is done > > now. > > > Like what? 10 years ago authenticated SUBMIT, first standardized in 1998, was finally starting to roll out. The authentication situation was finally starting settle down to TLS+PLAIN, with the realization that DIGEST-MD5 wasn't working. 10 years ago it was finally becoming clear that DSNs were the way to go. Prior to that there were any number of alternate schemes in use. As a result a lot of products released around that time (and therefore designed some time before that) shipped with the wrong defaults and sometimes even the wrong things implemented. > I ask because smtp.gmail.com seems to be getting along fine for > MSA with nothing particularly special, and nothing that isn't protocol > specific. And your point is? Gmail was two years away from beta 10 years ago. Standards are supposed to be written to last a lot longer than Gmail has even existed. And not to be snarky or anything, but "getting along" is not what I'd call a ringing endorsement. > For all the complaints about our IMAP implementation, I haven't > heard anyone clamoring for any smtp extensions we should implement. Perhaps because people who want those things don't look to Gmail to provide them. There's also another factor. SMTP degrades a lot more smoothly than IMAP when an extension the client wasn't to use isn't present. But it does degrade. And people notice. But since things work, for some value of "work", they're less likely to complain. > > Future-proofing means supporting future SMTP extensions regardless of > > form. The > > simplest way to do that is with a tunnel. An alternative would be something > > modelled on batch SMTP with some form of extension discovery, but that's a > > lot > > more work to implement. > I think this also focuses too much on SMTP. I don't want to embed an smtp > server into my IMAP server, I don't want my IMAP server to act as a network > proxy to an SMTP server. In some cases, SMTP is already a protocol > conversion and its probably easier to implement this using something else > anyways (ie, shell out to /usr/lib/sendmail in the most basic case, I'm > sure Exchange can just call the appropriate MAPI function, we'd just call > the gmail app servers send mail method). Well, on this one we simply disagree, because what I don't want to do is reimplement SMTP somewhere else and then have to keep two implementations up to date. Google may have the time and money to throw at this sort of thing, a lot of others don't. > Sending mail is "send this message from me to these addresses". IMAP > already has a model for what messages look like. No need for 8BITMIME or > extensions like that, no need for SMTPUTF8. The fact that your personal model for the service message transfer offers is extremely limited is not a reason to codify those limitations into standards. And with this I'm done. If you cannot see the essential point that none of us has a crystal ball and cannot therefore predict what will happen to email as a service in the future, then there's really no sense in continuing this discussion. Ned From arnt@gulbrandsen.priv.no Fri Aug 3 15:14:49 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6846221F8DE0 for ; Fri, 3 Aug 2012 15:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93eOSBryOMuV for ; Fri, 3 Aug 2012 15:14:49 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A2A21F8DDF for ; Fri, 3 Aug 2012 15:14:48 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id B2874F8D227; Fri, 3 Aug 2012 22:14:47 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1344032085-23170-23169/10/6; Fri, 3 Aug 2012 22:14:45 +0000 Message-Id: <501C4D66.8090007@gulbrandsen.priv.no> Date: Sat, 4 Aug 2012 00:15:02 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> In-Reply-To: <01OIMAUZGUFG0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 22:14:49 -0000 On 08/03/2012 02:36 PM, Ned Freed wrote: > 10 years ago authenticated SUBMIT, first standardized in 1998, was = finally > starting to roll out. The authentication situation was finally = starting settle > down to TLS+PLAIN, with the realization that DIGEST-MD5 wasn't working. > > 10 years ago it was finally becoming clear that DSNs were the way to = go. > Prior to that there were any number of alternate schemes in use. All this sounds irrelevant to a submit command in IMAP. Arnt From ned.freed@mrochek.com Fri Aug 3 15:54:34 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B0121F8D52 for ; Fri, 3 Aug 2012 15:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OH3oDH9bigzL for ; Fri, 3 Aug 2012 15:54:34 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 23BFA21F8D51 for ; Fri, 3 Aug 2012 15:54:34 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIME09IY74006BEC@mauve.mrochek.com> for imapext@ietf.org; Fri, 3 Aug 2012 15:49:30 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Fri, 3 Aug 2012 15:49:25 -0700 (PDT) Message-id: <01OIME06I33Q0006TF@mauve.mrochek.com> Date: Fri, 03 Aug 2012 15:35:11 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 04 Aug 2012 00:15:02 +0200" <501C4D66.8090007@gulbrandsen.priv.no> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 22:54:34 -0000 > On 08/03/2012 02:36 PM, Ned Freed wrote: > > 10 years ago authenticated SUBMIT, first standardized in 1998, was finally > > starting to roll out. The authentication situation was finally starting settle > > down to TLS+PLAIN, with the realization that DIGEST-MD5 wasn't working. > > > > 10 years ago it was finally becoming clear that DSNs were the way to go. > > Prior to that there were any number of alternate schemes in use. > All this sounds irrelevant to a submit command in IMAP. Sigh. One last time... Of course it's irrelevant to IMAP SUBMIT *now*. But it would have been highly relevant had IMAP SUBMIT been designed ten years ago. Had that been done, I rather suspect that DSN support would not have been included. (In fact there were proposals for an IMAP SUBMIT around that time, and guess what? No DSN support.) Which would have kinda sucked for clients that want to use it now, don't you think? For the Nth time, the point is that we cannot predict the future. That's why we make protocols extensible, and why we spend so much time worrying over the extensibility model we've selected. We've designed plenty of non-extensible protocols in the past. And often as not we've subsequently had to go to a lot of trouble to fix them later, often at significant cost. And now we have a proposal that's basically saying, "We know for sure that the evolution of message transfer is over and we therefore need not provide for extensibility." And that's quite simply crap. And spare me your arguments about limited use cases and similar nonsense. We're nothing short of terrible at predicting how things will actualy be used once they are standardized. As such, our designs need to as robust and flexible as we can reasonably make them. And in this particular doing so is a real win, since it actually simplifies things. Ned From ned.freed@mrochek.com Fri Aug 3 18:32:03 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C3621F8CD2 for ; Fri, 3 Aug 2012 18:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PHfDd7+eYyC for ; Fri, 3 Aug 2012 18:32:02 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5592A21F8CAD for ; Fri, 3 Aug 2012 18:32:02 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIMJHIX3GW0060R2@mauve.mrochek.com> for imapext@ietf.org; Fri, 3 Aug 2012 18:26:58 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Fri, 3 Aug 2012 18:26:52 -0700 (PDT) Message-id: <01OIMJHEYXJ40006TF@mauve.mrochek.com> Date: Fri, 03 Aug 2012 18:21:52 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 03 Aug 2012 10:41:43 +0200" <501B8EC7.9040708@gulbrandsen.priv.no> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <01OIK0GA2IYO0006TF@mauve.mrochek.com> <01OIKQHRTLOU0006TF@mauve.mrochek.com> <501AE32F.90903@gulbrandsen.priv.no> <01OIL06B1GOO0006TF@mauve.mrochek.com> <501B8EC7.9040708@gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 01:32:03 -0000 > On 08/03/2012 12:37 AM, Ned Freed wrote: > > And if you're assuming that client authors are going to jump on stuff > > that doesn't offer them direct and obvious benefit as implementers, > It's a bit of a mystery to me what gains wide usage and what not. > Simplicity seems to help, visible benefits too. > > then I have > > to ask why that hasn't happened in the case of RFC 6186? > I think that hasn't happened for four reasons. > 1. 6186 is late. It's also recent, so maybe a conclusion is premature. > 2. Few resolver APIs offer SRV queries, so it's bothersome to implement. FWIW, it's not too hard to hack one out of a MX lookup routine. Only one more field, as I recall. > 3. There's a competitor which offers better answers in many cases (I > forget the name, it's a combination of an algorithm and a database from > mozilla.org). > 4. It doesn't fit well into a popular client design: Do lookups at > install time (the "discovery phase") and expect that to never ever change. Yeah, and that works swimmingly well when things do change. I've had a number of friends with the "can't access their mail" issue that boiled down to this. That's said, I'm interested in an item that wasn't on your list - the problem some enterprise-level name lookup services had (or maybe used to have) with doing SRV lookups, or for that matter anything but A and TXT records. If this is no longer an issue, that's a (small) win. Ned From ned.freed@mrochek.com Fri Aug 3 19:19:44 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CD521F8D36 for ; Fri, 3 Aug 2012 19:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pb4NwuqdFneM for ; Fri, 3 Aug 2012 19:19:43 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CC27821F8D06 for ; Fri, 3 Aug 2012 19:19:43 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIML5M7FSW006YN7@mauve.mrochek.com> for imapext@ietf.org; Fri, 3 Aug 2012 19:14:38 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Fri, 3 Aug 2012 19:14:34 -0700 (PDT) Message-id: <01OIML5K30Q40006TF@mauve.mrochek.com> Date: Fri, 03 Aug 2012 18:57:22 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 03 Aug 2012 01:29:18 +0000" MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed References: To: "Adrien W. de Croy" Cc: Timo Sirainen , "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 02:19:44 -0000 On item b: > b) investment: > I don't have any IMAP client code. I have IMAP server code, SMTP > server code, and SMTP client code. IMAP client code is non-trivial, > esp when dealing with the plethora of optional IMAP extensions that may > come into play. Cost to develop this is on the high side it seems for > this function. I wrote our BURL IMAP client from scratch using no external library. I just checked: 520 lines of fairly linear C, including comments. Both imap: and imaps: are supported. It can probably done in 2/3 of that if you don't have as much debugging code as we tend to put in. I would not call that trivial, exactly, but my rough estimate for the SMTP client code needed for IMAP SUBMIT is at least 3X that, the main difference being the error handling is much more complicated. I also don't see how IMAP extensions are a factor. The only extension you need is URLFETCH; if you don't have that, you can't implement BURL. Ned From alexey.melnikov@isode.com Fri Aug 3 21:46:11 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D8C21F87C6 for ; Fri, 3 Aug 2012 21:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6KvvXRWdh6o for ; Fri, 3 Aug 2012 21:46:10 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F63521F87AD for ; Fri, 3 Aug 2012 21:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1344055650; d=isode.com; s=selector; i=@isode.com; bh=ngZe30KDT5MaT4QfzqENNa4enozK62D4RO29TM0+g8A=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=kBYNQ7GlN4YETJAZqntW9a2Gug3XZwWAlaiGP9o07SXEJZZ3s2yNXNtEJOWzaSXBQnFWBb V+srSvhWtFm9cGFvm2rkYsqSw8PSyszCQZBPLl3okdTpaCMImniRe6rDBfTDmRT7fHOH2F 80Nc1DDQaav8837k3MuDZvOkp1GIykk=; Received: from [10.71.15.50] (209-207-95-33.ip.van.radiant.net [209.207.95.33]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 4 Aug 2012 05:47:30 +0100 References: <01OIK0GA2IYO0006TF@mauve.mrochek.com> <01OIKQHRTLOU0006TF@mauve.mrochek.com> <501AE32F.90903@gulbrandsen.priv.no> <01OIL06B1GOO0006TF@mauve.mrochek.com> <501B8EC7.9040708@gulbrandsen.priv.no> <27AA9C8D-DAE8-4444-AB3E-102A34942143@isode.com> <501BE4B1.4000609@gulbrandsen.priv.no> In-Reply-To: <501BE4B1.4000609@gulbrandsen.priv.no> Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Fri, 3 Aug 2012 21:46:19 -0700 To: Arnt Gulbrandsen MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 04:46:11 -0000 On 3 Aug 2012, at 07:48, Arnt Gulbrandsen wrote: > On 08/03/2012 04:28 PM, Alexey Melnikov wrote: >=20 >>> >4. It doesn't fit well into a popular client design: Do lookups at inst= all time (the "discovery phase") and expect that to never ever change. >> I don't agree with this. RFC 6186 allows for lookups at later times. >=20 > Exactly. If a client's design doesn't, 6186 is at odds with the client. >=20 > Yes, you can just look up and store, but once you start doing that someone= will tell you "fix the bug properly, look it up later" and then it turns in= to a more complicated fix, and before you know it the simple fix doesn't get= implemented and shipped. Been there, done that, and once lost a customer be= cause various people shouted incompatibly at me and in the end I didn't sati= sfy any of them. I fail to see how is this relevant to "6186 versa something else" discussion= .= From arnt@gulbrandsen.priv.no Sat Aug 4 02:16:07 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE29621F8771 for ; Sat, 4 Aug 2012 02:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97qomWpzLBfc for ; Sat, 4 Aug 2012 02:16:06 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 603AC21F85F9 for ; Sat, 4 Aug 2012 02:16:06 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 1349DF8E5FA; Sat, 4 Aug 2012 09:16:05 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1344071764-12213-12212/10/1; Sat, 4 Aug 2012 09:16:04 +0000 Message-Id: <501CE866.7030701@gulbrandsen.priv.no> Date: Sat, 4 Aug 2012 11:16:22 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: Ned Freed References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> In-Reply-To: <01OIME06I33Q0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 09:16:07 -0000 On 08/04/2012 12:35 AM, Ned Freed wrote: > > Of course it's irrelevant to IMAP SUBMIT *now*. But it would have been > highly > relevant had IMAP SUBMIT been designed ten years ago. I read your other mail and see what you mean. But it's not correct in my case. The submit code would 50-100 lines in my case. It would call code already written for e.g. append, sieve vacation, blah. But I can see that if you have nothing already, imap submit is hard. Arnt From arnt@gulbrandsen.priv.no Sat Aug 4 06:30:19 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6444521F86B9 for ; Sat, 4 Aug 2012 06:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR7D77qp0U9x for ; Sat, 4 Aug 2012 06:30:19 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EDD21F8454 for ; Sat, 4 Aug 2012 06:30:18 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3725BFA0671; Sat, 4 Aug 2012 13:30:18 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1344087017-12213-12212/10/2; Sat, 4 Aug 2012 13:30:17 +0000 Message-Id: <501D23FB.5010408@gulbrandsen.priv.no> Date: Sat, 4 Aug 2012 15:30:35 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> In-Reply-To: <501CE866.7030701@gulbrandsen.priv.no> Content-Type: text/plain; charset=iso-8859-1; format=flowed Cc: Jan =?ISO-8859-1?q?Kundr=E1t?= Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 13:30:19 -0000 This thread troubles me now and isn't going to lead to anything good. I'll stop paying attention. Jan, I'll implement it if you publish a specification and it's not too tricky. Arnt From cyrus@daboo.name Sat Aug 4 06:39:40 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF7721F8772 for ; Sat, 4 Aug 2012 06:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW2kv3KFPq2O for ; Sat, 4 Aug 2012 06:39:39 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3FE21F8771 for ; Sat, 4 Aug 2012 06:39:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id AE2402D28DF6; Sat, 4 Aug 2012 09:39:38 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qagc3gjQ9uKD; Sat, 4 Aug 2012 09:39:37 -0400 (EDT) Received: from [10.0.1.8] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 1AA722D28DE8; Sat, 4 Aug 2012 09:39:36 -0400 (EDT) Date: Sat, 04 Aug 2012 09:39:37 -0400 From: Cyrus Daboo To: Ned Freed , Arnt Gulbrandsen Message-ID: <369D2BEC051854D2F2777A1A@cyrus.local> In-Reply-To: <01OIMJHEYXJ40006TF@mauve.mrochek.com> References: <01OIK0GA2IYO0006TF@mauve.mrochek.com> <01OIKQHRTLOU0006TF@mauve.mrochek.com> <501AE32F.90903@gulbrandsen.priv.no> <01OIL06B1GOO0006TF@mauve.mrochek.com> <501B8EC7.9040708@gulbrandsen.priv.no> <01OIMJHEYXJ40006TF@mauve.mrochek.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=3212 Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 13:39:40 -0000 Hi Ned, --On August 3, 2012 6:21:52 PM -0700 Ned Freed wrote: >> 2. Few resolver APIs offer SRV queries, so it's bothersome to implement. > > FWIW, it's not too hard to hack one out of a MX lookup routine. Only one > more field, as I recall. Interestingly enough support for SRV service discovery on OS X has been driven by calendar and contacts clients that use it with CalDAV and CardDAV. At present the mail client still uses the traditional "try and guess a suitable host name at a domain" approach. I am doing my best to persuade them to adopt SRV. That said, the focus here is too narrow. As I mentioned before, there is a need for "account-wide" service discovery - i.e. setting up all services for a domain in one go. It is not sufficient to make setup for email easy, it needs to apply across the board for calendaring, contacts, directory, etc. One of the driving forces behind this is the fact that several vendors at CalConnect, those who offer both an IETF-standards based suite of protocols, and one other proprietary, popular suite, have found that, even though their servers offer both suites, that site admins typically favor the proprietary solution because it has a single step setup. Now one can argue this is the fault of the clients - clients could take a single identifier from the user and do the separate SRV, guess-the-hostname tricks for each service and configure those. But that is a pain on the client side, and a pain to setup on the server side (with lots of different SRVs). So we want a way to deliver a single service discovery document that the overall "account setup" UI in a client can use to populate all services. >> 3. There's a competitor which offers better answers in many cases (I >> forget the name, it's a combination of an algorithm and a database from >> mozilla.org). > >> 4. It doesn't fit well into a popular client design: Do lookups at >> install time (the "discovery phase") and expect that to never ever >> change. > > Yeah, and that works swimmingly well when things do change. I've had a > number > of friends with the "can't access their mail" issue that boiled down to > this. One thing we have been doing in CalDAV is to support in-protocol service redirection. What happens is that clients typically on startup, or at regular intervals, check a user's calendar-home property. Typically that is a absolute URI without the host portion, but when the server wants to "re-base" a user's account, that will change to include the new host. Clients are then expected to follow that URI and reconfigure their settings. For a while, the server will proxy requests from the original to the new servers, so that the whole process is transparent to the end user. Now IMAP does have something like that in the form of RLOGIN, but I guess client support is limited. If we do develop a broad service discovery mechanism, it would make sense to come up with an IMAP response code of some kind to allow for in-protocol service redirection akin to what we do in CalDAV. I am not sure whether that is sufficient to cover the use cases we have complaints about, but it may be a good start. -- Cyrus Daboo From tss@iki.fi Sat Aug 4 07:05:39 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F5B21F8607 for ; Sat, 4 Aug 2012 07:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.526 X-Spam-Level: X-Spam-Status: No, score=-110.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nd4asv3vboiQ for ; Sat, 4 Aug 2012 07:05:38 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 410F021F8501 for ; Sat, 4 Aug 2012 07:05:38 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id CBDE81AE87B3; Sat, 4 Aug 2012 17:05:36 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <369D2BEC051854D2F2777A1A@cyrus.local> Date: Sat, 4 Aug 2012 17:05:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01OIK0GA2IYO0006TF@mauve.mrochek.com> <01OIKQHRTLOU0006TF@mauve.mrochek.com> <501AE32F.90903@gulbrandsen.priv.no> <01OIL06B1GOO0006TF@mauve.mrochek.com> <501B8EC7.9040708@gulbrandsen.priv.no> <01OIMJHEYXJ40006TF@mauve.mrochek.com> <369D2BEC051854D2F2777A1A@cyrus.local> To: Cyrus Daboo X-Mailer: Apple Mail (2.1084) Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 14:05:39 -0000 On 4.8.2012, at 16.39, Cyrus Daboo wrote: > Now IMAP does have something like that in the form of RLOGIN, but I = guess client support is limited. If we do develop a broad service = discovery mechanism, it would make sense to come up with an IMAP = response code of some kind to allow for in-protocol service redirection = akin to what we do in CalDAV. I am not sure whether that is sufficient = to cover the use cases we have complaints about, but it may be a good = start. Isn't that login referrals (rfc 2221)? a login user pass a OK [REFERRAL imap://user@example.com/] Please move to another server, = but I'll proxy you for now anyway. Maybe the same reply could also be sent untagged after login. From cyrus@daboo.name Sat Aug 4 07:37:31 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07FA21F876A for ; Sat, 4 Aug 2012 07:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WR0OdxkLnQ55 for ; Sat, 4 Aug 2012 07:37:31 -0700 (PDT) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1F29221F86C6 for ; Sat, 4 Aug 2012 07:37:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 608382D29767; Sat, 4 Aug 2012 10:37:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwFVz0g2ajsp; Sat, 4 Aug 2012 10:37:29 -0400 (EDT) Received: from [10.0.1.8] (unknown [173.13.55.49]) by daboo.name (Postfix) with ESMTPSA id 3D9142D2975C; Sat, 4 Aug 2012 10:37:29 -0400 (EDT) Date: Sat, 04 Aug 2012 10:37:36 -0400 From: Cyrus Daboo To: Timo Sirainen Message-ID: <87003849A6A3188F250C7ADA@cyrus.local> In-Reply-To: References: <01OIK0GA2IYO0006TF@mauve.mrochek.com> <01OIKQHRTLOU0006TF@mauve.mrochek.com> <501AE32F.90903@gulbrandsen.priv.no> <01OIL06B1GOO0006TF@mauve.mrochek.com> <501B8EC7.9040708@gulbrandsen.priv.no> <01OIMJHEYXJ40006TF@mauve.mrochek.com> <369D2BEC051854D2F2777A1A@cyrus.local> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1334 Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 14:37:31 -0000 Hi Timo, --On August 4, 2012 5:05:36 PM +0300 Timo Sirainen wrote: >> Now IMAP does have something like that in the form of RLOGIN, but I >> guess client support is limited. If we do develop a broad service >> discovery mechanism, it would make sense to come up with an IMAP >> response code of some kind to allow for in-protocol service redirection >> akin to what we do in CalDAV. I am not sure whether that is sufficient >> to cover the use cases we have complaints about, but it may be a good >> start. > > Isn't that login referrals (rfc 2221)? > > a login user pass > a OK [REFERRAL imap://user@example.com/] Please move to another server, > but I'll proxy you for now anyway. > > Maybe the same reply could also be sent untagged after login. > All that proves is that client developers are very good at ignoring that spec! Actually, 2221 does not specifically mention the possibility of proxy on the old server. Instead it talks about "home server referral" where an OK with a [REFERRAL ...] indicates that the user's personal mailboxes have moved, but pubic mailboxes may still be available. So perhaps some clarification is needed. I am hoping that a broader service discovery solution can suggest use of this - in fact I will add something like that to the document I am working on. -- Cyrus Daboo From tss@iki.fi Sat Aug 4 07:43:12 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E6221F87B1 for ; Sat, 4 Aug 2012 07:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8M9BbuSFqpF for ; Sat, 4 Aug 2012 07:43:12 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3371521F87AD for ; Sat, 4 Aug 2012 07:43:12 -0700 (PDT) Received: from [10.217.1.118] (unknown [193.184.212.30]) by dovecot.org (Postfix) with ESMTP id 46D181AE87B3; Sat, 4 Aug 2012 17:43:11 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <87003849A6A3188F250C7ADA@cyrus.local> Date: Sat, 4 Aug 2012 17:43:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <80266541-0945-4447-89A1-ED900A94F946@iki.fi> References: <01OIK0GA2IYO0006TF@mauve.mrochek.com> <01OIKQHRTLOU0006TF@mauve.mrochek.com> <501AE32F.90903@gulbrandsen.priv.no> <01OIL06B1GOO0006TF@mauve.mrochek.com> <501B8EC7.9040708@gulbrandsen.priv.no> <01OIMJHEYXJ40006TF@mauve.mrochek.com> <369D2BEC051854D2F2777A1A@cyrus.local> <87003849A6A3188F250C7ADA@cyrus.local> To: Cyrus Daboo X-Mailer: Apple Mail (2.1084) Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 14:43:12 -0000 On 4.8.2012, at 17.37, Cyrus Daboo wrote: >> Isn't that login referrals (rfc 2221)? >>=20 >> a login user pass >> a OK [REFERRAL imap://user@example.com/] Please move to another = server, >> but I'll proxy you for now anyway. >>=20 >> Maybe the same reply could also be sent untagged after login. >>=20 >=20 > All that proves is that client developers are very good at ignoring = that spec! >=20 > Actually, 2221 does not specifically mention the possibility of proxy = on the old server. Instead it talks about "home server referral" where = an OK with a [REFERRAL ...] indicates that the user's personal mailboxes = have moved, but pubic mailboxes may still be available. So perhaps some = clarification is needed. I am hoping that a broader service discovery = solution can suggest use of this - in fact I will add something like = that to the document I am working on. Yeah. Somehow a long time ago when I read that spec I immediately = thought of it as alternative to proxying the connection. Dovecot's = default login referral string is even "Logged in, but you should use = this server instead." Of course I'm sure there are about 0 installations = which have actually enabled this. :) Client-transparent proxying is much = more commonly used everywhere. From ned.freed@mrochek.com Sat Aug 4 07:58:04 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7B2C21F87B9 for ; Sat, 4 Aug 2012 07:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49c0CMkSXB7v for ; Sat, 4 Aug 2012 07:58:03 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CAA4621F87B8 for ; Sat, 4 Aug 2012 07:58:03 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OINBMRXZKG0065LL@mauve.mrochek.com> for imapext@ietf.org; Sat, 4 Aug 2012 07:52:56 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Sat, 4 Aug 2012 07:52:50 -0700 (PDT) Message-id: <01OINBMOA6AO0006TF@mauve.mrochek.com> Date: Sat, 04 Aug 2012 07:28:04 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 04 Aug 2012 09:39:37 -0400" <369D2BEC051854D2F2777A1A@cyrus.local> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <01OIK0GA2IYO0006TF@mauve.mrochek.com> <01OIKQHRTLOU0006TF@mauve.mrochek.com> <501AE32F.90903@gulbrandsen.priv.no> <01OIL06B1GOO0006TF@mauve.mrochek.com> <501B8EC7.9040708@gulbrandsen.priv.no> <01OIMJHEYXJ40006TF@mauve.mrochek.com> <369D2BEC051854D2F2777A1A@cyrus.local> To: Cyrus Daboo Cc: Arnt Gulbrandsen , Ned Freed , imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 14:58:04 -0000 > Hi Ned, > --On August 3, 2012 6:21:52 PM -0700 Ned Freed > wrote: > >> 2. Few resolver APIs offer SRV queries, so it's bothersome to implement. > > > > FWIW, it's not too hard to hack one out of a MX lookup routine. Only one > > more field, as I recall. > Interestingly enough support for SRV service discovery on OS X has been > driven by calendar and contacts clients that use it with CalDAV and > CardDAV. At present the mail client still uses the traditional "try and > guess a suitable host name at a domain" approach. I am doing my best to > persuade them to adopt SRV. > That said, the focus here is too narrow. As I mentioned before, there is a > need for "account-wide" service discovery - i.e. setting up all services > for a domain in one go. It is not sufficient to make setup for email easy, > it needs to apply across the board for calendaring, contacts, directory, > etc. Yes, you're absolutely right - our focus is too narrow. OTOH, one of the main reasons other proposals in this area have failed is because they attempted to do too much. One boundary that IMO must not be crossed is attempting to describe service semantics or relationships in the discovery mechanism. The notion that a client could make use of a generic sort of service never made any sense to me, but that's what a lot of past attempts tried to cover. > One of the driving forces behind this is the fact that several vendors at > CalConnect, those who offer both an IETF-standards based suite of > protocols, and one other proprietary, popular suite, have found that, even > though their servers offer both suites, that site admins typically favor > the proprietary solution because it has a single step setup. Now one can > argue this is the fault of the clients - clients could take a single > identifier from the user and do the separate SRV, guess-the-hostname tricks > for each service and configure those. But that is a pain on the client > side, and a pain to setup on the server side (with lots of different SRVs). > So we want a way to deliver a single service discovery document that the > overall "account setup" UI in a client can use to populate all services. Another problem here is that you're back to having to deploy a new discovery service, with all the headaches that implies. And yes, the proprietary stuff has similar issues (and the hack of using port 80 only solves some of them), but in many cases it has the advantage of already being deployed. But I think the biggest problem if you go down this path is going to be getting it scoped correctly and keeping it focuses within those bounds. > >> 3. There's a competitor which offers better answers in many cases (I > >> forget the name, it's a combination of an algorithm and a database from > >> mozilla.org). > > > >> 4. It doesn't fit well into a popular client design: Do lookups at > >> install time (the "discovery phase") and expect that to never ever > >> change. > > > > Yeah, and that works swimmingly well when things do change. I've had a > > number > > of friends with the "can't access their mail" issue that boiled down to > > this. > One thing we have been doing in CalDAV is to support in-protocol service > redirection. What happens is that clients typically on startup, or at > regular intervals, check a user's calendar-home property. Typically that is > a absolute URI without the host portion, but when the server wants to > "re-base" a user's account, that will change to include the new host. > Clients are then expected to follow that URI and reconfigure their > settings. For a while, the server will proxy requests from the original to > the new servers, so that the whole process is transparent to the end user. On a side note, I was forced to abandon iCal because of serious bugs in this area. With depressing regularly it would lose its ability to connect to the CalDAV server. Resetting the configuration would fix it, but who wants to do that every couple of days? > Now IMAP does have something like that in the form of RLOGIN, but I guess > client support is limited. If we do develop a broad service discovery > mechanism, it would make sense to come up with an IMAP response code of > some kind to allow for in-protocol service redirection akin to what we do > in CalDAV. I am not sure whether that is sufficient to cover the use cases > we have complaints about, but it may be a good start. I wish I could be more optimistic about this approach, but I'm not. There's a long history of attempts to do this sort of redirection in protocols, going back at least as far as the 251 response in RFC 821. I can't think of a single case where this sort of thing has deployed. And I don't think the failure has been a result of security concerns either. Ned From ned.freed@mrochek.com Sat Aug 4 11:57:33 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA31321F86CA for ; Sat, 4 Aug 2012 11:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z16IPCzvCmV for ; Sat, 4 Aug 2012 11:57:33 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 34FDA21F86C6 for ; Sat, 4 Aug 2012 11:57:33 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OINK0SR2RK006CS4@mauve.mrochek.com> for imapext@ietf.org; Sat, 4 Aug 2012 11:52:30 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Sat, 4 Aug 2012 11:52:27 -0700 (PDT) Message-id: <01OINK0QJ4IK0006TF@mauve.mrochek.com> Date: Sat, 04 Aug 2012 11:26:21 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 04 Aug 2012 11:16:22 +0200" <501CE866.7030701@gulbrandsen.priv.no> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: Ned Freed , imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Aug 2012 18:57:33 -0000 > On 08/04/2012 12:35 AM, Ned Freed wrote: > > > > Of course it's irrelevant to IMAP SUBMIT *now*. But it would have been > > highly > > relevant had IMAP SUBMIT been designed ten years ago. > I read your other mail and see what you mean. But it's not correct in my > case. > The submit code would 50-100 lines in my case. It would call code > already written for e.g. append, sieve vacation, blah. But I can see > that if you have nothing already, imap submit is hard. If you see this as a relevant response, I guess I'm not being clear and need to try again. This was about standardization and deployment. Not implementation details. The current specification contains support for exactly one SMTP extension - DSN - despite the fact that there are quite a few that require input from the client and therefore cannot be done on behalf of the client by the IMAP server. (I note in passing that the DSN support as specified is broken: There needs to be a way of specifying an envelope id, there needs to be a way to specify return of content, and ORCPT is per-recipient, not per-message.) The argument has been made that other extensions aren't used very often and that this proposal is therefore justified in ignoring them. In fact it doesn't even specify a means of addiing additional what it call "submission options". I believe this is exceptionally poor design choice, but let's suppose for a moment that's not the case. But what happens when an extension appears in the future that has widespread appeal and which requires client input? As it is written now, the specification would have to be revised, yet another IMAP extension would be needed, yadda yadda yadda. You could get rid of the need to revise the specification by including some means of adding new submission options. But even then you have significantly complicated the upgrade scenario for submitting messages. This is what I mean when I say this proposal isn't future-proof. I'm talking about standardization and deployment, not how easy it is to implement the current IMAP SUBMIT proposal. Contrast this with the approach I have been, well, not advocating, but at least suggesting as an alternative: An SUBMIT tunneling approach. This removes the need for the IMAP server to be aware of these sorts of extensions, effectively removing the IMAP server as an inpediment to SUBMIT upgrades. Done correctly this approach retains the ability to forward without download, eliminates the need for a SUBMIT port, and eliminates the additional authentication step. Ned From ned.freed@mrochek.com Sat Aug 4 19:01:18 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A66D821F86CB for ; Sat, 4 Aug 2012 19:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QftwIajWtL2a for ; Sat, 4 Aug 2012 19:01:18 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 83B6321F86C8 for ; Sat, 4 Aug 2012 19:01:16 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OINYSNJ6WG006FJE@mauve.mrochek.com> for imapext@ietf.org; Sat, 4 Aug 2012 18:55:50 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Sat, 4 Aug 2012 18:55:47 -0700 (PDT) Message-id: <01OINYSLKUB20006TF@mauve.mrochek.com> Date: Sat, 04 Aug 2012 18:53:17 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 04 Aug 2012 11:26:21 -0700 (PDT)" <01OINK0QJ4IK0006TF@mauve.mrochek.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <01OINK0QJ4IK0006TF@mauve.mrochek.com> To: Ned Freed Cc: Ned Freed , Arnt Gulbrandsen , imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 02:01:18 -0000 Typo: > This was about standardization and deployment. Not implementation details. The > current specification contains support for exactly one SMTP extension - DSN - > despite the fact that there are quite a few that require input from the client > and therefore cannot be done on behalf of the client by the IMAP server. (I > note in passing that the DSN support as specified is broken: There needs to be > a way of specifying an envelope id, there needs to be a way to specify return > of content, and ORCPT is per-recipient, not per-message.) Sorry, that should have been NOTIFY, not ORCPT. Ned From barryleiba.mailing.lists@gmail.com Sun Aug 5 08:43:32 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1436921F84A5 for ; Sun, 5 Aug 2012 08:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.034 X-Spam-Level: X-Spam-Status: No, score=-103.034 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPvsRvNRh16M for ; Sun, 5 Aug 2012 08:43:31 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A4CBB21F84A2 for ; Sun, 5 Aug 2012 08:43:30 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so15096lbb.31 for ; Sun, 05 Aug 2012 08:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+N4X0aYcR3CVHiTcZdtzQzuNNvgAoP1gQ2eprjHhgrk=; b=q8zfk2C17fSKxhTAk+WjwevZrh5+daFLrxQlggSEP50kT1EnWzw+BJPfXuL7DSmP9u ezoendBRXinXQR/jGW1gBlhS+UWExnr/bUzjLbz2w9lZzVDyKFDNRvFZESULT4ISY17z 25UuQwyepHbsNeZXpaSNBrrv3l3BPZRbljTEsjpWp4MXpdZ4xGpNOR5qP4EVb7Y9fbxP JVowC5WiYsntgtjmq8gqQFAl2R4lt5zgcu2d76a53UhYT/1qbjKpkwWTYvPhCKBgrd4n EPj4/L2iPFSguUmqQEF5ZAvMYCRtB6AAdr7e93kkbe9p3aiv0CWCcavNRh5vI+TPerg+ q0hA== MIME-Version: 1.0 Received: by 10.152.103.11 with SMTP id fs11mr7781257lab.23.1344181409595; Sun, 05 Aug 2012 08:43:29 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Sun, 5 Aug 2012 08:43:29 -0700 (PDT) In-Reply-To: <501D23FB.5010408@gulbrandsen.priv.no> References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> Date: Sun, 5 Aug 2012 11:43:29 -0400 X-Google-Sender-Auth: b8_SPFDNfySWeunbiSZh7sFGfh8 Message-ID: From: Barry Leiba To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=f46d040715c56ec08204c6869f1f Cc: "imapext@ietf.org" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 15:43:32 -0000 --f46d040715c56ec08204c6869f1f Content-Type: text/plain; charset=ISO-8859-1 I've been reading this now-70-message thread with some interest: This means that MOVE is done, now? Barry, kinda-sorta poking in as AD --f46d040715c56ec08204c6869f1f Content-Type: text/html; charset=ISO-8859-1 I've been reading this now-70-message thread with some interest:
This means that MOVE is done, now?

Barry, kinda-sorta poking in as AD
--f46d040715c56ec08204c6869f1f-- From brong@fastmail.fm Sun Aug 5 11:47:15 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4EC21F8567 for ; Sun, 5 Aug 2012 11:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=-1.133, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EThfJsuYDiSp for ; Sun, 5 Aug 2012 11:47:13 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id DCB9021F8552 for ; Sun, 5 Aug 2012 11:47:13 -0700 (PDT) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E89C420355 for ; Sun, 5 Aug 2012 14:47:12 -0400 (EDT) Received: from web2.nyi.mail.srv.osa ([10.202.2.212]) by compute5.internal (MEProxy); Sun, 05 Aug 2012 14:47:12 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= message-id:from:to:mime-version:content-transfer-encoding :content-type:subject:date; s=mesmtp; bh=V5X8Jy4T7YYUfBLdnrfBU0c kBkA=; b=I6GPfoClVKnrcUzrFBjL5rm6N7jQkTHKtvqd3UonXSmQh/HNAGhXObE A0qfU6UrCBgD7+LMTSq+p8EfTf1P6QOf+nRROWT2xkKMQOAXc6Btcvi96eptDvQc KvDNF5v3B3o4BUL5gXSpd4/Xu6GffAsSSvuD9hBIFm1c8wZPwlRs= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:subject:date; s=smtpout; bh=V5X8Jy4T7YYUfBLdnrfBU0ckBkA=; b=PQXMkGzXKF2omfeBgA4g+YfBJ0IU Eb18N9SuIUdozYA/Q3pKC6FO02HtKc044Zpy3vjnEKwZh08uucGT52+GIifwJD5m i+jI2YiBJt/0b5NNcDsfVrnuMsP2GDh9olWvFFB74Gcrd1bbZNfBQjZBcS0v0Pwz TG2OSxsDoMiKE18= Received: by web2.nyi.mail.srv.osa (Postfix, from userid 99) id B170A5C2E84; Sun, 5 Aug 2012 14:47:12 -0400 (EDT) Message-Id: <1344192432.3834.140661110991537.5793E7BB@webmail.messagingengine.com> X-Sasl-Enc: V7Qm0WdNG4DdPLR/RvX5vLwtHyCR090mAYOvcoByLSRg 1344192432 From: Bron Gondwana To: imapext@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface Date: Sun, 05 Aug 2012 20:47:12 +0200 Subject: [imapext] SUBMIT proposals and "will it be used" X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 18:47:15 -0000 Look what happens when I go away for a few days! Lots of excitement. Just summarising the points I've seen so far: * Any proposed protocol needs to be extensible. I agree - we can't predict the future of messaging. Closing off extensibility is dumb. * It's going to be horribly complicated to support everything. I kind of agree, but see below. * We need to support every SMTP extension ever proposed and be everything to everybody. I strongly disagree. We have evidence that by far the most common IMAP clients are a small handful. Outlook/Outlook Express are going to be a problem of course, but they already are for any new proposal. iOS mail is quite responsive, and I suspect they will be willing to add things which make life easier for their users. Apple is into that. Thunderbird is Open Source[tm]. I'm willing to do the patching myself if necessary. I already did for COMPRESS=DEFLATE because we needed it for FastMail. And that's 99% of users covered. I really feel that we keep banging our heads on the complex use cases that <1% of users need. * Firewalling - is it or isn't it a problem The problem isn't so much firewalling at the mail server end - it's intermediate blackholes and random firewalling. The whole point of one protocol vs two here is that it is either totally blocked, in which case it's very clearly an intermediate ISP problem and the user yells at their ISP, or totally open. The hard part about SMTP (or even Submission) and IMAP is that you get stupidly configured intermediate firewalls who allow IMAP, but not SMTP or Submission. Then the users get extra confused, and bounced between two different support desks - nobody wins. Experience shows that misconfigured firewalls are going to keep happening. Two different protocols on different ports with (as also mentioned) different authentication mechanisms just means this is going to keep causing issues. * You have to deal with complicated trust relationships between IMAP and Submission server anyway. In 1% of cases. 99% of cases they're the same party, and they already have an internal trust relationship set up. If they're also running a webmail system (very common these days) then they already have a method for injecting authenticated emails into their outbound queue without an SMTP frontend - and can SUBMIT straight into that same path. * Nobody will use it because nobody is using it. This is the same uphill battle that every extension faces. As a counterpoint, I present XLIST by Gmail. It's widely supported now - so much so that Apple managed to screw up and they'll send the LIST command but expect the XLIST flags in the response still. We added an option to Cyrus to send those flags even if not asked to. There's now a standard for it, in theory, but there's a lot more support for the non-standard thing, because that was there NOW, and it was useful enough that everyone did it. We patched it into FastMail long before pushing it back to Cyrus master. I argue that a good submit is something that users want. It's something that will be jumped on as soon as it's available, in the way that BURL wasn't. I argue quite strongly that the number of times it has been proposed is a very good indication that there's a real problem which it would solve. Maybe the suggested draft isn't the right way to do it - but it needs to be be done. The triangle of IMAP server, IMAP/SMTP client and SMTP server has one more party and two more trust links than the average user wants to deal with. Maybe this won't be the perfect protocol for mail forever, but neither is what we have now. The fact that almost every program just uploads the mail twice still is a testament to something... Bron. -- Bron Gondwana brong@fastmail.fm From arnt@gulbrandsen.priv.no Sun Aug 5 12:16:04 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21ABC21F84EB for ; Sun, 5 Aug 2012 12:16:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bC+vBP-b3gXs for ; Sun, 5 Aug 2012 12:16:03 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 949D521F84EA for ; Sun, 5 Aug 2012 12:16:03 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 6144BFA06BC; Sun, 5 Aug 2012 19:16:02 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1344194161-29479-29478/11/1; Sun, 5 Aug 2012 19:16:01 +0000 User-Agent: Kaiten Mail In-Reply-To: References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Arnt Gulbrandsen Date: Sun, 5 Aug 2012 21:15:45 +0200 To: Barry Leiba Message-Id: <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> Cc: imapext@ietf.org Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 19:16:04 -0000 I perceive implementer happiness and do not expect more substantive = changes. Of course i may be wrong. I suggest WGLC when the lull after the meeting has passed. Say in a week = from now. Arnt From michael@daclubhouse.net Sun Aug 5 15:50:41 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB4A21F848B for ; Sun, 5 Aug 2012 15:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgTqq4jwH2dy for ; Sun, 5 Aug 2012 15:50:40 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE1421F84FB for ; Sun, 5 Aug 2012 15:50:40 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so5538741obb.31 for ; Sun, 05 Aug 2012 15:50:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=DH2mxEDLUgN50qm7mqMEjgxx+Y0PN7qjaY7OevXhQ2M=; b=LCxwYoOpRS+P1R3YHlA92I58qjTOmmA4rRKEQLsMtkvMttJMg9luUiDjsbZVNMocnh 13IexQ+IonpIiWMT6mTpMURjG+iUNVkP04SqtGuj934QUjzeuncPckMvIjR5+rtz3Fkr x4UjwBY9vWZbf3gnkqnR69hPcEyDY4QxcQVj/0xuUaQLUb+AqB8bjk45Zb4hKe59mMLT Uxao/frqpdz4W5d5WEAlyqVwchwmDUt1aW06Q/p++jvNAtE0NpISL2SOMNWsH5J9P37V liSBVABX3H58yEo62EqsenL/FXnrkAk90dIzzwulyTAStu5Crg2i8PAxmrUZXJ1porY5 bLPQ== MIME-Version: 1.0 Received: by 10.182.53.103 with SMTP id a7mr16373777obp.3.1344207039690; Sun, 05 Aug 2012 15:50:39 -0700 (PDT) Received: by 10.76.144.133 with HTTP; Sun, 5 Aug 2012 15:50:39 -0700 (PDT) Received: by 10.76.144.133 with HTTP; Sun, 5 Aug 2012 15:50:39 -0700 (PDT) In-Reply-To: <1344192432.3834.140661110991537.5793E7BB@webmail.messagingengine.com> References: <1344192432.3834.140661110991537.5793E7BB@webmail.messagingengine.com> Date: Sun, 5 Aug 2012 15:50:39 -0700 Message-ID: From: Michael Fair To: Bron Gondwana Content-Type: multipart/alternative; boundary=f46d044796311af67804c68c971a X-Gm-Message-State: ALoCoQmw6X1yofeq1kqJlfhhwzTeD8kbFlECBJbjcbjooV3w7EXLnjC6gsmbsUJdKxIGOUONEFme Cc: imapext@ietf.org Subject: Re: [imapext] SUBMIT proposals and "will it be used" X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 22:50:41 -0000 --f46d044796311af67804c68c971a Content-Type: text/plain; charset=ISO-8859-1 I've been watching the discussions for some time and was wondering... Has anyone considered/proposed making SUBMIT a special folder name (I like OUTBOX) like INBOX is rather than a separate command. Then using the APPEND or MOVE command to add a message to this special folder to deliver messages. This folder would be like the existing OUTBOX folder on most clients. Only minor client modifications would be needed to handle ordinary messages. Additional parameters that can't be put into the message itself can be set by new parameters added to the MOVE or APPEND commands themselves. Extensibility is handled by allowing a series of key/value flags to be sent as part of the command. Perhaps along the lines of JSON or URI encoding. It's then up to the server to actually handle the rest. Status flags on the message could be used to communicate the delivery statuses. Deleting the message from the OUTBOX would signal completion of injection into the SMTP queues. I imagine servers would typically use a smarthost to handle the submission. Thoughts, ideas, feedback? Thanks for considering the idea, Mike On Aug 5, 2012 11:47 AM, "Bron Gondwana" wrote: > Look what happens when I go away for a few days! Lots of excitement. > > Just summarising the points I've seen so far: > > * Any proposed protocol needs to be extensible. > > I agree - we can't predict the future of messaging. Closing off > extensibility is dumb. > > > * It's going to be horribly complicated to support everything. > > I kind of agree, but see below. > > > * We need to support every SMTP extension ever proposed and be everything > to everybody. > > I strongly disagree. We have evidence that by far the most common IMAP > clients > are a small handful. Outlook/Outlook Express are going to be a problem of > course, but they already are for any new proposal. > > iOS mail is quite responsive, and I suspect they will be willing to add > things > which make life easier for their users. Apple is into that. > > Thunderbird is Open Source[tm]. I'm willing to do the patching myself if > necessary. I already did for COMPRESS=DEFLATE because we needed it for > FastMail. > > And that's 99% of users covered. I really feel that we keep banging our > heads > on the complex use cases that <1% of users need. > > > * Firewalling - is it or isn't it a problem > > The problem isn't so much firewalling at the mail server end - it's > intermediate > blackholes and random firewalling. The whole point of one protocol vs two > here > is that it is either totally blocked, in which case it's very clearly an > intermediate ISP problem and the user yells at their ISP, or totally open. > > The hard part about SMTP (or even Submission) and IMAP is that you get > stupidly > configured intermediate firewalls who allow IMAP, but not SMTP or > Submission. > Then the users get extra confused, and bounced between two different > support > desks - nobody wins. > > Experience shows that misconfigured firewalls are going to keep happening. > Two > different protocols on different ports with (as also mentioned) different > authentication mechanisms just means this is going to keep causing issues. > > > * You have to deal with complicated trust relationships between IMAP and > Submission server anyway. > > In 1% of cases. 99% of cases they're the same party, and they already have > an internal trust relationship set up. If they're also running a webmail > system (very common these days) then they already have a method for > injecting > authenticated emails into their outbound queue without an SMTP frontend - > and > can SUBMIT straight into that same path. > > > * Nobody will use it because nobody is using it. > > This is the same uphill battle that every extension faces. As a > counterpoint, > I present XLIST by Gmail. It's widely supported now - so much so that > Apple > managed to screw up and they'll send the LIST command but expect the XLIST > flags in the response still. We added an option to Cyrus to send those > flags even if not asked to. There's now a standard for it, in theory, but > there's a lot more support for the non-standard thing, because that was > there NOW, and it was useful enough that everyone did it. We patched it > into > FastMail long before pushing it back to Cyrus master. > > I argue that a good submit is something that users want. It's something > that > will be jumped on as soon as it's available, in the way that BURL wasn't. > I argue quite strongly that the number of times it has been proposed is a > very good indication that there's a real problem which it would solve. > Maybe > the suggested draft isn't the right way to do it - but it needs to be be > done. > The triangle of IMAP server, IMAP/SMTP client and SMTP server has one more > party and two more trust links than the average user wants to deal with. > > Maybe this won't be the perfect protocol for mail forever, but neither is > what > we have now. The fact that almost every program just uploads the mail > twice > still is a testament to something... > > Bron. > -- > Bron Gondwana > brong@fastmail.fm > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext > --f46d044796311af67804c68c971a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I've been watching the discussions for some time and was wondering..= .

Has anyone considered/proposed making SUBMIT a special folder name (I li= ke OUTBOX) like INBOX is rather than a separate command.

Then using the APPEND or MOVE command to add a message to this special f= older to deliver messages.

This folder would be like the existing OUTBOX folder on most clients.

Only minor client modifications would be needed to handle ordinary messa= ges.

Additional parameters that can't be put into the message itself can = be set by new parameters added to the MOVE or APPEND commands themselves.

Extensibility is handled by allowing a series of key/value flags to be s= ent as part of the command.=A0 Perhaps along the lines of JSON or URI encod= ing.

It's then up to the server to actually handle the rest.=A0 Status fl= ags on the message could be used to communicate the delivery statuses.=A0 D= eleting the message from the OUTBOX would signal completion of injection in= to the SMTP queues.

I imagine servers would typically use a smarthost to handle the submissi= on.

Thoughts, ideas, feedback?

Thanks for considering the idea,
Mike

On Aug 5, 2012 11:47 AM, "Bron Gondwana&quo= t; <brong@fastmail.fm> wrote= :
Look what happens when I go away for a few days! =A0Lots of excitement.

Just summarising the points I've seen so far:

* Any proposed protocol needs to be extensible.

I agree - we can't predict the future of messaging. =A0Closing off
extensibility is dumb.


* It's going to be horribly complicated to support everything.

I kind of agree, but see below.


* We need to support every SMTP extension ever proposed and be everything =A0 to everybody.

I strongly disagree. =A0We have evidence that by far the most common IMAP c= lients
are a small handful. =A0Outlook/Outlook Express are going to be a problem o= f
course, but they already are for any new proposal.

iOS mail is quite responsive, and I suspect they will be willing to add thi= ngs
which make life easier for their users. =A0Apple is into that.

Thunderbird is Open Source[tm]. =A0I'm willing to do the patching mysel= f if
necessary. =A0I already did for COMPRESS=3DDEFLATE because we needed it for= FastMail.

And that's 99% of users covered. =A0I really feel that we keep banging = our heads
on the complex use cases that <1% of users need.


* Firewalling - is it or isn't it a problem

The problem isn't so much firewalling at the mail server end - it's= intermediate
blackholes and random firewalling. =A0The whole point of one protocol vs tw= o here
is that it is either totally blocked, in which case it's very clearly a= n
intermediate ISP problem and the user yells at their ISP, or totally open.<= br>
The hard part about SMTP (or even Submission) and IMAP is that you get stup= idly
configured intermediate firewalls who allow IMAP, but not SMTP or Submissio= n.
Then the users get extra confused, and bounced between two different suppor= t
desks - nobody wins.

Experience shows that misconfigured firewalls are going to keep happening. = =A0Two
different protocols on different ports with (as also mentioned) different authentication mechanisms just means this is going to keep causing issues.<= br>

* You have to deal with complicated trust relationships between IMAP and =A0 Submission server anyway.

In 1% of cases. =A099% of cases they're the same party, and they alread= y have
an internal trust relationship set up. =A0If they're also running a web= mail
system (very common these days) then they already have a method for injecti= ng
authenticated emails into their outbound queue without an SMTP frontend - a= nd
can SUBMIT straight into that same path.


* Nobody will use it because nobody is using it.

This is the same uphill battle that every extension faces. =A0As a counterp= oint,
I present XLIST by Gmail. =A0It's widely supported now - so much so tha= t Apple
managed to screw up and they'll send the LIST command but expect the XL= IST
flags in the response still. =A0We added an option to Cyrus to send those flags even if not asked to. =A0There's now a standard for it, in theory= , but
there's a lot more support for the non-standard thing, because that was=
there NOW, and it was useful enough that everyone did it. =A0We patched it = into
FastMail long before pushing it back to Cyrus master.

I argue that a good submit is something that users want. =A0It's someth= ing that
will be jumped on as soon as it's available, in the way that BURL wasn&= #39;t.
I argue quite strongly that the number of times it has been proposed is a very good indication that there's a real problem which it would solve. = =A0Maybe
the suggested draft isn't the right way to do it - but it needs to be b= e done.
The triangle of IMAP server, IMAP/SMTP client and SMTP server has one more<= br> party and two more trust links than the average user wants to deal with.
Maybe this won't be the perfect protocol for mail forever, but neither = is what
we have now. =A0The fact that almost every program just uploads the mail tw= ice
still is a testament to something...

Bron.
--
=A0 Bron Gondwana
=A0 brong@fastmail.fm

_______________________________________________
imapext mailing list
imapext@ietf.org
https://www.ietf.org/mailman/listinfo/imapext
--f46d044796311af67804c68c971a-- From adrien@qbik.com Sun Aug 5 16:09:30 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA44021F856D for ; Sun, 5 Aug 2012 16:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.668 X-Spam-Level: X-Spam-Status: No, score=-3.668 tagged_above=-999 required=5 tests=[AWL=-1.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLOoVMl8hVMS for ; Sun, 5 Aug 2012 16:09:29 -0700 (PDT) Received: from smtp.qbik.com (smtp.qbik.com [210.55.214.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2075721F8552 for ; Sun, 5 Aug 2012 16:09:24 -0700 (PDT) Received: From [192.168.1.25] (unverified [219.89.218.88]) by SMTP Server [210.55.214.35] (WinGate SMTP Receiver v7.2.6 (Build 3449)) with SMTP id <0019177143@smtp.qbik.com>; Mon, 06 Aug 2012 11:09:21 +1200 From: "Adrien de Croy" To: "Bron Gondwana" , "imapext@ietf.org" Date: Sun, 05 Aug 2012 23:09:12 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <1344192432.3834.140661110991537.5793E7BB@webmail.messagingengine.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/4.0.15145.0 Subject: Re: [imapext] SUBMIT proposals and "will it be used" X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Adrien de Croy List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 23:09:31 -0000 =EF=BB=BF Hi ------ Original Message ------ From: "Bron Gondwana" To: "imapext@ietf.org" Sent: 6/08/2012 6:47:12 a.m. Subject: [imapext] SUBMIT proposals and "will it be used" >Look what happens when I go away for a few days! Lots of excitement. > >Just summarising the points I've seen so far: > >* Any proposed protocol needs to be extensible. > >I agree - we can't predict the future of messaging. Closing off >extensibility is dumb. > Yes, and I don't think anyone has been arguing that any potential=20 SUBMIT extension should not in itself be extensible. Even the current draft has room in it for a certain amount of=20 extensibility. We may just need to consider more aspects of the SMTP envelope to be=20 extensible, such as forward-path (may need to become an object rather=20 than a single parameter). Etc. > >* It's going to be horribly complicated to support everything. > >I kind of agree, but see below. > As long as the skeleton is extensible, I think any future SMTP=20 extension will need to prove its worth anyway. Everyone thinks their proposed extension is invaluable, but the=20 community (developers) tend to disagree more often than not. There have basically been 2 main options proposed. 1. client provides envelope, IMAP server does submission on behalf 2. client does protocol tunneled through to submit server Personally, option 1 for me is a simple write-envelope-to-routing-slip=20 + file-copy-message-to-delivery-queue. Probably about 50 lines of=20 code. I'm pretty certain I could get it working in about 1/2 hr, so=20 it's a no brainer to adopt. If one doesn't have an SMTP client implementation with their IMAP=20 server, then sure it's going to be more difficult. Option 2 for me=20 would probably be very hard to justify writing. Option 1 for me has another main benefit. It allows the IMAP server to=20 choose how submission will be done. This has several potential=20 advantages I see. i. only 1 submission implementation to debug (in terms of why did a=20 submit fail etc - of course this only applies when an organisation has=20 migrated to IMAP SUBMIT) ii. centralises management of submission to IMAP server operator. and probably some more the downsides are potentially there is more work to do when extensions=20 come out. However, I don't know if tunneling is really a starter=20 either, since to avoid double-transmission, you'd need to proxy rather=20 than tunnel anyway, which means the IMAP server now has to be able to=20 deal with all SMTP protocol, and in fact SMTP extensions would be more=20 likely to break submission, e.g. if a client chooses to use an=20 extension which breaks message parsing / delineation in the proxy. Especially since we can't mandate any limits on SMTP to cope with=20 tunneled SMTP via IMAP. > > > >* We need to support every SMTP extension ever proposed and be everything > to everybody. > >I strongly disagree. We have evidence that by far the most common IMAP= clients >are a small handful. Outlook/Outlook Express are going to be a problem= of >course, but they already are for any new proposal. > >iOS mail is quite responsive, and I suspect they will be willing to add= things >which make life easier for their users. Apple is into that. > >Thunderbird is Open Source[tm]. I'm willing to do the patching myself = if >necessary. I already did for COMPRESS=3DDEFLATE because we needed it for= FastMail. > >And that's 99% of users covered. I really feel that we keep banging our= heads >on the complex use cases that <1% of users need. > > I agree. This being an optional extension only needs to be supported=20 by those who see value in it. As long as we don't stuff it up for the future, and for everyone else. > > >* Firewalling - is it or isn't it a problem > >The problem isn't so much firewalling at the mail server end - it's interm= ediate >blackholes and random firewalling. The whole point of one protocol vs = two here >is that it is either totally blocked, in which case it's very clearly an >intermediate ISP problem and the user yells at their ISP, or totally open. > >The hard part about SMTP (or even Submission) and IMAP is that you get = stupidly >configured intermediate firewalls who allow IMAP, but not SMTP or Submissi= on. >Then the users get extra confused, and bounced between two different suppo= rt >desks - nobody wins. > >Experience shows that misconfigured firewalls are going to keep happening.= Two >different protocols on different ports with (as also mentioned) different >authentication mechanisms just means this is going to keep causing issues. > Most firewall problems relate to firewalls that are local to the=20 client. You wouldn't believe the number of customers we have who can't=20 get a port opened on their local firewall (their own firewall!!!) due=20 to various bureacratic / administrative setups. They need to submit proposals, research etc etc. Yes, some=20 organisations (more than you'd think) are that tight. > >* You have to deal with complicated trust relationships between IMAP and > Submission server anyway. > >In 1% of cases. 99% of cases they're the same party, and they already = have >an internal trust relationship set up. If they're also running a webmail >system (very common these days) then they already have a method for inject= ing >authenticated emails into their outbound queue without an SMTP frontend= - and >can SUBMIT straight into that same path. > > >* Nobody will use it because nobody is using it. > >This is the same uphill battle that every extension faces. As a counterpo= int, >I present XLIST by Gmail. It's widely supported now - so much so that = Apple >managed to screw up and they'll send the LIST command but expect the XLIST >flags in the response still. We added an option to Cyrus to send those >flags even if not asked to. There's now a standard for it, in theory, = but >there's a lot more support for the non-standard thing, because that was >there NOW, and it was useful enough that everyone did it. We patched it= into >FastMail long before pushing it back to Cyrus master. > >I argue that a good submit is something that users want. It's something= that >will be jumped on as soon as it's available, in the way that BURL wasn't. >I argue quite strongly that the number of times it has been proposed is= a >very good indication that there's a real problem which it would solve. = Maybe >the suggested draft isn't the right way to do it - but it needs to be be= done. >The triangle of IMAP server, IMAP/SMTP client and SMTP server has one more >party and two more trust links than the average user wants to deal with. > >Maybe this won't be the perfect protocol for mail forever, but neither = is what >we have now. The fact that almost every program just uploads the mail = twice >still is a testament to something... > I agree. Adrien > > >Bron. >-- > Bron Gondwana > brong@fastmail.fm > >_______________________________________________ >imapext mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext > > From barryleiba.mailing.lists@gmail.com Sun Aug 5 20:15:54 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D26421F848B for ; Sun, 5 Aug 2012 20:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.034 X-Spam-Level: X-Spam-Status: No, score=-103.034 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EAZDmHceEjJ for ; Sun, 5 Aug 2012 20:15:53 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id EEDF321F8487 for ; Sun, 5 Aug 2012 20:15:47 -0700 (PDT) Received: by lahm15 with SMTP id m15so1357644lah.31 for ; Sun, 05 Aug 2012 20:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=35a1S7eHcZbskN59/VhGTPKR/KNXrGAwvMcbB34eZSg=; b=kQWumxENFU2+lRMXJ485xtn4OiN+mYIG8WaCUIUrWyWmN9MyTYK4Q2XBylOB5zkZt9 MDAb9sjxbN5m718l6g3Q6Fmv4//cDs+VdH7dJ2/hN5vancvEQ2AgDZyaksLR5MaGt4P7 QONlRxrSFhwWyjPP7G0xAtmiNL7yx0farURNSBgr/MUVL/g2X24A4l6jf9PgCE5QWjlQ SSRW5fvaucxA3nXDZ0nSBhwx9hEafO/k/Tw7A4Zg0cBUul4yig/ZFGfrS9ZA3glkx7Z+ XYFfsjYlx2TDZwx0hL3yq8+uR2Xh2xu7nwvNptAnPjh/ky8AcIzbvoYQtgjO4FYuZWoY XwFA== MIME-Version: 1.0 Received: by 10.112.98.231 with SMTP id el7mr3969171lbb.14.1344222946806; Sun, 05 Aug 2012 20:15:46 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.17.133 with HTTP; Sun, 5 Aug 2012 20:15:46 -0700 (PDT) In-Reply-To: <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> Date: Sun, 5 Aug 2012 23:15:46 -0400 X-Google-Sender-Auth: 7w97W1rC4OIlc9rRbg6tM26fQuU Message-ID: From: Barry Leiba To: Arnt Gulbrandsen Content-Type: text/plain; charset=ISO-8859-1 Cc: imapext@ietf.org Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 03:15:54 -0000 > I perceive implementer happiness and do not expect more substantive changes. OK. Then we should make sure we push on that conversation, to confirm this. > Of course i may be wrong. It's been known to happen. > I suggest WGLC when the lull after the meeting has passed. Say in a week from now. I suggest that we've been discussing other stuff too much, and that before the chairs step in for a call on this, we make sure we pull the conversation back in to MOVE, and stop talking about SUBMIT for a while. I know this was one of the dangers of re-using an old mailing list, and so I'm not being very picky about it. Still.... Barry, just suggesting a re-focus, as questionably responsible AD From arnt@gulbrandsen.priv.no Mon Aug 6 01:19:52 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DC521F85FF for ; Mon, 6 Aug 2012 01:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RHBbEGfYmBcI for ; Mon, 6 Aug 2012 01:19:51 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9ED21F8602 for ; Mon, 6 Aug 2012 01:19:49 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 7C650F8E7C3; Mon, 6 Aug 2012 08:19:48 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1344241187-29479-29478/10/4; Mon, 6 Aug 2012 08:19:47 +0000 Message-Id: <501F7E39.2020203@gulbrandsen.priv.no> Date: Mon, 6 Aug 2012 10:20:09 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 08:19:52 -0000 On 08/06/2012 05:15 AM, Barry Leiba wrote: > I suggest that we've been discussing other stuff too much, and that > before the chairs step in for a call on this, we make sure we pull the > conversation back in to MOVE, and stop talking about SUBMIT for a > while. Well. The recent change was: MSN-based move is now in the draft instead of being an open issue. Noone has a problem (in the first person) with MSN-based move AFAICT. Problems have been mentioned in the third person or past tense umpty times in the past decade, but when I tried to chase them down they've evaporated. Personally I think MSN-based move is just so much foo, but most similar commands have MSN-based variants and there's value on following the overall design. IMAP has too many odd rules already, omitting MSN-based move merely because I don't like and/or see no use for it would be wrong. > I know this was one of the dangers of re-using an old mailing > list, and so I'm not being very picky about it. Still.... It's happened often enough on WG lists too. Arnt From blong@google.com Mon Aug 6 14:00:10 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C97021E80B6 for ; Mon, 6 Aug 2012 14:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.039 X-Spam-Level: X-Spam-Status: No, score=-102.039 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFlHxLEEk9Qg for ; Mon, 6 Aug 2012 14:00:09 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8862A21E80B8 for ; Mon, 6 Aug 2012 14:00:09 -0700 (PDT) Received: by yenm5 with SMTP id m5so1161093yen.31 for ; Mon, 06 Aug 2012 14:00:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=5OCMtFryImXQkonU7aO+2yVQO1+sdOAqY7AjNH0hIyk=; b=X/+xoqdnNOGKKUL2bHx5t+mKD02iDq3kNZsT7d0Y8qfDXaQurhvqKz9dKPE6p93bdb oSU/5tU0qr2CUfeFn+liE3KXuclLaQOKXwzceCDF2ijv+rzccYCcSxtYPn7Aur/vK/SY Xmoae4yZRrweEE5TG1WFGTV2XHKS2q1JRcHmtcwUow5Jsdi3Bv5pmxwyFVb2iqxnTsQz ncMSkIirvrk4NccJ+43LKWlezT+Uz0zQkfZhX3atK2JGCTLmxjqYfBYmFkUTUAzleDmq OzsWwtKlRK73s9LjY8L1JXlwjNySlJVGjaCxh6ChEIjuI7Jr1xmWsUq68d7kdw3dCxaA cfKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=5OCMtFryImXQkonU7aO+2yVQO1+sdOAqY7AjNH0hIyk=; b=F8ZIo6bblVn3QQ1BWKO74KGDJ1ke4UMZAw6Nk5rFU33ybOu3iLeLdEXzqqTnwGd1l6 Uue25LMtysu5NhO9yqvCRNRwCeDeDAgASw8NXBinirXhllZfCooZY+NTW6pfnrYo3XfA MUrUX8vVAGK6TDLxymgHdW0tUMGCpzpfaZWihrox+aTGCOyVazZSMqvN9qWZHchOUOMJ uTjW52H7V8f01xYWvJ2O+APcryG7uI27arETV6yxV1ORLyYNGFwfkTiMJxO85NJaMPBQ RY3GzGH8vpNWdZ6ouVRq3JLXXuku24a3MJCGazu+79c12qNmb2Kk9dm7gwW3+xBsgspG ahOQ== Received: by 10.60.169.100 with SMTP id ad4mr21126308oec.21.1344286809106; Mon, 06 Aug 2012 14:00:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.169.100 with SMTP id ad4mr21126285oec.21.1344286808772; Mon, 06 Aug 2012 14:00:08 -0700 (PDT) Received: by 10.76.6.209 with HTTP; Mon, 6 Aug 2012 14:00:08 -0700 (PDT) In-Reply-To: <501F7E39.2020203@gulbrandsen.priv.no> References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> Date: Mon, 6 Aug 2012 14:00:08 -0700 Message-ID: From: Brandon Long To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=bcaec517a4c0b6918504c69f292e X-System-Of-Record: true X-Gm-Message-State: ALoCoQlfPEwopxgclF9zyWL5PxRzHeB8OkvSwbeWbmmUqBBZImEV9KNSIHqW03urAVY1DJGBns0aLjQxxdiKwWdprWUDziKNa+F2KgTNdxz+0riCGmVvSOsh1+ruOsyglXJeBDRT+4PW9NixqNj1JFIdvbFpQ6baM9LFPwyT8RqLy0hHSHiJIbOl0pVRD0mpkjI8IvS/t5TB Cc: imapext@ietf.org Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 21:00:10 -0000 --bcaec517a4c0b6918504c69f292e Content-Type: text/plain; charset=ISO-8859-1 Does anyone want to write up a set of tests for the new functionality? Either based on the Timo's existing test suite or something else. Brandon On Mon, Aug 6, 2012 at 1:20 AM, Arnt Gulbrandsen wrote: > On 08/06/2012 05:15 AM, Barry Leiba wrote: > >> I suggest that we've been discussing other stuff too much, and that >> before the chairs step in for a call on this, we make sure we pull the >> conversation back in to MOVE, and stop talking about SUBMIT for a >> while. >> > > Well. The recent change was: MSN-based move is now in the draft instead of > being an open issue. > > Noone has a problem (in the first person) with MSN-based move AFAICT. > Problems have been mentioned in the third person or past tense umpty times > in the past decade, but when I tried to chase them down they've evaporated. > > Personally I think MSN-based move is just so much foo, but most similar > commands have MSN-based variants and there's value on following the overall > design. IMAP has too many odd rules already, omitting MSN-based move merely > because I don't like and/or see no use for it would be wrong. > > > > I know this was one of the dangers of re-using an old mailing > >> list, and so I'm not being very picky about it. Still.... >> > > It's happened often enough on WG lists too. > > Arnt > > > ______________________________**_________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/**listinfo/imapext > --bcaec517a4c0b6918504c69f292e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Does anyone want to write up a set of tests for the new functionality?
=
Either based on the Timo's existing test suite or someth= ing else.

Brandon


On Mon, Aug 6, 2012 at 1:20 AM, Arnt Gul= brandsen <arnt@gulbrandsen.priv.no> wrote:
On 08/06/2012 05:15 AM, Barry Leiba wrote:
I suggest that we've been discussing other stuff too much, and that
before the chairs step in for a call on this, we make sure we pull the
conversation back in to MOVE, and stop talking about SUBMIT for a
while.

Well. The recent change was: MSN-based move is now in the draft instead of = being an open issue.

Noone has a problem (in the first person) with MSN-based move AFAICT. Probl= ems have been mentioned in the third person or past tense umpty times in th= e past decade, but when I tried to chase them down they've evaporated.<= br>
Personally I think MSN-based move is just so much foo, but most similar com= mands have MSN-based variants and there's value on following the overal= l design. IMAP has too many odd rules already, omitting MSN-based move mere= ly because I don't like and/or see no use for it would be wrong.


> I know this was one of the dangers of re-using an old mailing
list, and so I'm not being very picky about it. =A0Still....

It's happened often enough on WG lists too.

Arnt


_______________________________________________
imapext mailing list
imapext@ietf.org<= br> https://www.ietf.org/mailman/listinfo/imapext

--bcaec517a4c0b6918504c69f292e-- From alexey.melnikov@isode.com Thu Aug 9 06:13:08 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F2D21F8602 for ; Thu, 9 Aug 2012 06:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.384 X-Spam-Level: X-Spam-Status: No, score=-102.384 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkY0FxyN7tC2 for ; Thu, 9 Aug 2012 06:13:07 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 168A321F85E4 for ; Thu, 9 Aug 2012 06:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1344517984; d=isode.com; s=selector; i=@isode.com; bh=pZ8N0wHv2aQmD6XnC3anwov6boYIIbB3YC9ew0cssQo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=wwpiLQunXLQ2B01zeOnhIRsHM8WcLQYzd/wGHXd/5+UCWqNPn4UIqa6qvALXBTOf8TxgaH o5r0wGlDBldGaFFabgDjgQjbGed1Hx6nzBcwSPn03cefScpmF5i03wVRjYE8t7iqDfzHLY jeBySKv12FU93EKHvdcMd0Lft4442nE=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 9 Aug 2012 14:13:03 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <502362E9.1060901@isode.com> Date: Thu, 09 Aug 2012 00:12:41 -0700 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Arnt Gulbrandsen References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> In-Reply-To: <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Bron Gondwana , imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 13:13:08 -0000 On 01/08/2012 05:10, Bron Gondwana wrote: > > On Sun, Jul 29, 2012, at 10:27 PM, Arnt Gulbrandsen wrote: >> On 07/29/2012 07:54 PM, Barry Leiba wrote: >>> Yes, I very strongly prefer normative language here, rather than leaving >>> it entirely unspecified. There are too many vague implementation >>> choices in IMAP already, which cause problems for client developers. >> I very strongly dislike writing things like "servers may optimise >> unimportant corner cases" (I rephrased to bring the issue out more >> clearly). Yes, they may, but I don't think good RFCs should say things >> like that, and rewording to shroud the issue doesn't remove the problem. >> >> I thought about possible rules that would satisfy both you, Alexey and >> myself, and I changed my own position. I now think that the only >> sensible behaviour is to mandate OK. (Speaking as a developer, not as a WG co-chair) If you mean that a compliant server would have to return COPYUID with renumbered messages, than I am unhappy to implement additional code (UID renumbering) if nobody can think of a reason how this is useful. >> Arguments: >> >> First, copystoreexpunge works that way. Do we have a good reason to fail >> in cases copystoreexpunge OKs? I fail to see any. Performance in corner >> cases doesn't matter, and the locking issue Bron brings up is a cyrus bug. > I agree - it's a Cyrus bug. I'm going to fix Cyrus. Sorry I even > brought the topic up! Let's behave like COPYSTOREEXPUNGE and not > screw around. > >> Second, other move-capable systems I use support noop moves, and it's >> convenient. SQL servers do not reject an UPDATE ... WHERE when zero rows >> would be affected, they say "OK, 0 rows affected". The unix mv command >> also accepts noop moves, and many, many shell scripts and state machines >> depend on it. "mv $a $basedir/unprocessed" works even if $a happens to >> be in unprocessed already, "mv $(find ...) foo" works, etc. > What would COPYUID say? I have the same question. But if the server can just omit COPYUID in this case, I would be Ok with that. From arnt@gulbrandsen.priv.no Thu Aug 9 06:28:28 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2B121F8617 for ; Thu, 9 Aug 2012 06:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TB-jgnE8KpI for ; Thu, 9 Aug 2012 06:28:27 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9DD21F85D8 for ; Thu, 9 Aug 2012 06:28:27 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id A43EEF8D542; Thu, 9 Aug 2012 13:28:26 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1344518905-19918-19917/10/2; Thu, 9 Aug 2012 13:28:25 +0000 Message-Id: <5023BAFA.4080104@gulbrandsen.priv.no> Date: Thu, 9 Aug 2012 15:28:26 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> <502362E9.1060901@isode.com> In-Reply-To: <502362E9.1060901@isode.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 13:28:28 -0000 On 08/09/2012 09:12 AM, Alexey Melnikov wrote: > I have the same question. But if the server can just omit COPYUID in > this case, I would be Ok with that. As I see it, omitting COPYUID is acceptable. But I think that's really a UIDPLUS question. I don't see either a requirement there to send COPYUID for all UID COPY commands nor an explicit permission to omit it. Clients have to deal with servers that don't support UIDPLUS, so I would be very surprised if omitting COPYUID were to lead to interoperability problems. Arnt From alexey.melnikov@isode.com Fri Aug 10 07:16:16 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61E921F85C4 for ; Fri, 10 Aug 2012 07:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.897 X-Spam-Level: X-Spam-Status: No, score=-102.897 tagged_above=-999 required=5 tests=[AWL=-0.298, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eX5V5B6ZPucD for ; Fri, 10 Aug 2012 07:16:16 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id EA12D21F85A8 for ; Fri, 10 Aug 2012 07:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1344608175; d=isode.com; s=selector; i=@isode.com; bh=8zBU8Gf9s6BpIulrw72KaL/tcfm5HSM9SaIzhKKfH+I=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=FC72J8Nr8VZcJDXgOcyo8PMVP6et41UKnxH1h0/1ohszsgRU0MljDE6jgmMjHCeZ6QYqIb OLWRcJ1Z/XsVTfm8/ZRYLbcU+EBZ2rm8Yp4TxOmXesZex91eQayreQq04VXAnUx49P+27M ckC4wXUjtqW63gEpyl/k5as7ifDSjsQ=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 10 Aug 2012 15:16:14 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <502517DD.60806@isode.com> Date: Fri, 10 Aug 2012 15:17:01 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Brandon Long References: <81FFA4ED-CA53-406D-BE99-CFA2D9A375E0@iki.fi> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imapext@ietf.org Subject: Re: [imapext] IMAP clients X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:16:17 -0000 On 02/08/2012 15:48, Brandon Long wrote: > Certain bugs also stand out, like Outlook which likes to do an IDLE > without having a folder selected. As a side note: as much as I like complaining about Outlook and its use of IMAP, IMAP IDLE command is actually allowed when no folder is selected. The behavior is undocumented (most servers wouldn't send any updates in such case), but the command is still valid in such state. From alexey.melnikov@isode.com Fri Aug 10 07:37:19 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28AF321F8568 for ; Fri, 10 Aug 2012 07:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.893 X-Spam-Level: X-Spam-Status: No, score=-102.893 tagged_above=-999 required=5 tests=[AWL=-0.294, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjCYRQEnF-CC for ; Fri, 10 Aug 2012 07:37:18 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 703C821F84F1 for ; Fri, 10 Aug 2012 07:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1344609437; d=isode.com; s=selector; i=@isode.com; bh=ouNkOgB3vkRe/h8nFiQwmv8ai/ui3STdo93rIxu6gmA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=pTnzQMztAe41GpfFQei+5bpdYc3PphgZKtEVv29dU2nIDQtsZQi5Vjshw1wMU8oVQKorY5 tioq1anPGKp/qGeEPyFmCSZCqbZvwe9JZcL55gtaWpP2wBKHGjqiEZvs3HUge1Hz9pTryb E9T0xoGMpG7Qe69i+2nIFIPkIJV7vtk=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 10 Aug 2012 15:37:17 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <50251CC5.8000905@isode.com> Date: Fri, 10 Aug 2012 15:37:57 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Arnt Gulbrandsen References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> <502362E9.1060901@isode.com> <5023BAFA.4080104@gulbrandsen.priv.no> In-Reply-To: <5023BAFA.4080104@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 14:37:19 -0000 On 09/08/2012 14:28, Arnt Gulbrandsen wrote: > On 08/09/2012 09:12 AM, Alexey Melnikov wrote: >> I have the same question. But if the server can just omit COPYUID in >> this case, I would be Ok with that. > > As I see it, omitting COPYUID is acceptable. But I think that's really > a UIDPLUS question. I don't see either a requirement there to send > COPYUID for all UID COPY commands nor an explicit permission to omit it. > > Clients have to deal with servers that don't support UIDPLUS, so I > would be very surprised if omitting COPYUID were to lead to > interoperability problems. Ok. Can you tell me what is the currently allowed behavior (or currently allowed choices) about MOVE to the currently selected mailbox? I think this still needs clarification in the draft and I am a bit confused about where we stand on this. From arnt@gulbrandsen.priv.no Fri Aug 10 08:06:05 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 229D921F85DB for ; Fri, 10 Aug 2012 08:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kaVjv3aV-F5 for ; Fri, 10 Aug 2012 08:06:04 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F3E21F84F7 for ; Fri, 10 Aug 2012 08:06:04 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 1F1FDF8E20A; Fri, 10 Aug 2012 15:06:03 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1344611162-14582-14581/10/2; Fri, 10 Aug 2012 15:06:02 +0000 Message-Id: <5025235D.1070000@gulbrandsen.priv.no> Date: Fri, 10 Aug 2012 17:06:05 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> <502362E9.1060901@isode.com> <5023BAFA.4080104@gulbrandsen.priv.no> <50251CC5.8000905@isode.com> In-Reply-To: <50251CC5.8000905@isode.com> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 15:06:05 -0000 On 08/10/2012 04:37 PM, Alexey Melnikov wrote: > Ok. Can you tell me what is the currently allowed behavior (or currently > allowed choices) about MOVE to the currently selected mailbox? I think > this still needs clarification in the draft and I am a bit confused > about where we stand on this. The draft says MOVE works as COPYSTOREEXPUNGE. I think that's an excellent principle, and we should deviate from it only when we have good reason to. It's good that a client needs no new if() when adding MOVE. In this case, what COPYSTOREEXPUNGE does is assign new UIDs for the messages in question. It would be possible to optimise that to not assign new UIDs, but do we have any good reasons to do so? I see none. I could add some text, but I fear it would sound a little stupid. "In this case, like in all others, UID MOVE has the same effect as a sequence of UID COPY, UID STORE and UID EXPUNGE." Arnt From arnt@gulbrandsen.priv.no Fri Aug 10 08:35:06 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3931621F8787 for ; Fri, 10 Aug 2012 08:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7N9zPzBAc5b for ; Fri, 10 Aug 2012 08:35:05 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6FA21F8786 for ; Fri, 10 Aug 2012 08:35:05 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 06ED4F8C3F2; Fri, 10 Aug 2012 15:35:00 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1344612899-14582-14581/10/3; Fri, 10 Aug 2012 15:34:59 +0000 Message-Id: <50252A26.8030008@gulbrandsen.priv.no> Date: Fri, 10 Aug 2012 17:35:02 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> <502362E9.1060901@isode.com> <5023BAFA.4080104@gulbrandsen.priv.no> <50251CC5.8000905@isode.com> <5025235D.1070000@gulbrandsen.priv.no> In-Reply-To: <5025235D.1070000@gulbrandsen.priv.no> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 15:35:06 -0000 I answered Alexey: > In this case, what COPYSTOREEXPUNGE does is assign new UIDs for the > messages in question. It would be possible to optimise that to not > assign new UIDs, I thought some more about this optimisation, and I don't want to go there. Today, if a client moves a message (whether with or without the extension), the message is \recent afterwards. Preserving that rule with this optimisation is unpleasant. Complicating a one-sentence \recent rule in order to support an obscure optimisation is IMO disproportionate. It's also possible that some clients depend on UID allocation being monotonic to a somewhat higher degree than they perhaps should. Arnt From ned.freed@mrochek.com Fri Aug 10 09:26:07 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4059B21F8535 for ; Fri, 10 Aug 2012 09:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfeZT5pmizkm for ; Fri, 10 Aug 2012 09:26:06 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 58F4921F852E for ; Fri, 10 Aug 2012 09:26:06 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIVSH4C8R4006W1V@mauve.mrochek.com> for imapext@ietf.org; Fri, 10 Aug 2012 09:21:04 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OIGH28IS2O0006TF@mauve.mrochek.com>; Fri, 10 Aug 2012 09:21:02 -0700 (PDT) Message-id: <01OIVSH307JS0006TF@mauve.mrochek.com> Date: Fri, 10 Aug 2012 09:20:51 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 10 Aug 2012 17:35:02 +0200" <50252A26.8030008@gulbrandsen.priv.no> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> <502362E9.1060901@isode.com> <5023BAFA.4080104@gulbrandsen.priv.no> <50251CC5.8000905@isode.com> <5025235D.1070000@gulbrandsen.priv.no> <50252A26.8030008@gulbrandsen.priv.no> To: Arnt Gulbrandsen Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 16:26:07 -0000 > I answered Alexey: > > In this case, what COPYSTOREEXPUNGE does is assign new UIDs for the > > messages in question. It would be possible to optimise that to not > > assign new UIDs, > I thought some more about this optimisation, and I don't want to go there. > Today, if a client moves a message (whether with or without the > extension), the message is \recent afterwards. Preserving that rule with > this optimisation is unpleasant. Complicating a one-sentence \recent > rule in order to support an obscure optimisation is IMO disproportionate. > It's also possible that some clients depend on UID allocation being > monotonic to a somewhat higher degree than they perhaps should. Agreed on all points. Ned From barryleiba.mailing.lists@gmail.com Fri Aug 10 11:20:04 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4ACF21F8772 for ; Fri, 10 Aug 2012 11:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.027 X-Spam-Level: X-Spam-Status: No, score=-103.027 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GymPAoKRr++x for ; Fri, 10 Aug 2012 11:20:04 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B564C21F8771 for ; Fri, 10 Aug 2012 11:20:03 -0700 (PDT) Received: by lahm15 with SMTP id m15so1066253lah.31 for ; Fri, 10 Aug 2012 11:20:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/l9ZG4U+qnr6EFUYILwfNFGhrmIY3zYDxNlrNEHM1cc=; b=DQ5j/0TNQsIrSMR0Kg17apAn9LSdeFSCEYqGmgHPK1btYlHedy/QRkm/P+LPxdtM/0 nGIKuKF9cChgC6c5f4UgKbua+bE7ExmIx4xPyZ5KydyPFNdhUU//2gLaZ2jTiTyjzycQ eBmm+gBSe6+fY59qbxG+jaVw+5plthDBfPB85ofy3FhtlsxWL31U4HGv2jpmdTDOqtWf WR/MqMl+AYc2nKBLHEeEtVs/59iS/V+P6K8HHjOGwPQiBB4De4HbdwfRWOL69+fsuE30 eQ/wBmAwdQ79Vjy124FFgauHyMGvxks5uh5yzMuT49ELwi5yRg3lsyxibfQXKHodArea 5VxA== MIME-Version: 1.0 Received: by 10.112.43.135 with SMTP id w7mr2816648lbl.48.1344622802742; Fri, 10 Aug 2012 11:20:02 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.113.196 with HTTP; Fri, 10 Aug 2012 11:20:02 -0700 (PDT) In-Reply-To: <50252A26.8030008@gulbrandsen.priv.no> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <1343477969.18432.140661107700921.6E65C817@webmail.messagingengine.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> <502362E9.1060901@isode.com> <5023BAFA.4080104@gulbrandsen.priv.no> <50251CC5.8000905@isode.com> <5025235D.1070000@gulbrandsen.priv.no> <50252A26.8030008@gulbrandsen.priv.no> Date: Fri, 10 Aug 2012 14:20:02 -0400 X-Google-Sender-Auth: rfa38eazdejLqt2pgJ5ptqBdUkI Message-ID: From: Barry Leiba To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=e0cb4efe2ab883ad5004c6ed6417 Cc: "imapext@ietf.org" Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 18:20:04 -0000 --e0cb4efe2ab883ad5004c6ed6417 Content-Type: text/plain; charset=ISO-8859-1 > > It's also possible that some clients depend on UID allocation being > monotonic to a somewhat higher degree than they perhaps should. I'm confused: are you saying that clients should be willing to accept a new message with a UID that is *less* than those of some existing ones, and that if they don't accept that, they're being overly rigorous? The IMAP spec is very clear on this point, and there are good implementation reasons for it -- such as being able to find all new messages by remembering the highest UID seen, and then fetching n:*. Barry --e0cb4efe2ab883ad5004c6ed6417 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It's also possible that some clients dep= end on UID allocation being monotonic to a somewhat higher degree than they= perhaps should.
=A0
I'm confused: are= you saying that clients should be willing to accept a new message with a U= ID that is *less* than those of some existing ones, and that if they don= 9;t accept that, they're being overly rigorous?

The IMAP spec is very clear on this point, and there ar= e good implementation reasons for it -- such as being able to find all new = messages by remembering the highest UID seen, and then fetching n:*.

Barry
--e0cb4efe2ab883ad5004c6ed6417-- From barryleiba.mailing.lists@gmail.com Fri Aug 10 11:24:10 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA0D21F8770 for ; Fri, 10 Aug 2012 11:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.026 X-Spam-Level: X-Spam-Status: No, score=-103.026 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2FKf-Ce2Dw2 for ; Fri, 10 Aug 2012 11:24:10 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C061321F8741 for ; Fri, 10 Aug 2012 11:24:09 -0700 (PDT) Received: by lahm15 with SMTP id m15so1068063lah.31 for ; Fri, 10 Aug 2012 11:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=TVnTNJ5t0c+ys7DP0HE3w+APCYbFyAy9SoPqS7bl39Y=; b=A3l5H1O8SiMI/WHRbFuV0EdwvU+42gLoXO5ZUSFnvssmIKgU6uTSanhG0+mTmU1bh1 lQyeEZXpioIRWUsatnCmB2j6x4rbeUj/P7mk8g7FqHlE2jQ7pbqXxo8kXgba2gpGOUHJ q8jSnnRqmw2rhcS6AOKmS7EbPtJkCM2CAQNceU82TtMOH+zOBZcMO5XyZjDVCYJ4GUTE XaZSwde/kIloSiO8/PPHj2qnb8ht3Xk9oP+4aaovRtoSpJpntjxP5pco4EOFXbNmme7O /A3Q2fy4aRD3ym/6TNeMEXdlTDTQhcVAvEY+VyxQvNoQGer2dDcs4+5tFtBaEDHBVtSm A97Q== MIME-Version: 1.0 Received: by 10.152.114.3 with SMTP id jc3mr362814lab.11.1344623048776; Fri, 10 Aug 2012 11:24:08 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.113.196 with HTTP; Fri, 10 Aug 2012 11:24:08 -0700 (PDT) In-Reply-To: <502517DD.60806@isode.com> References: <81FFA4ED-CA53-406D-BE99-CFA2D9A375E0@iki.fi> <502517DD.60806@isode.com> Date: Fri, 10 Aug 2012 14:24:08 -0400 X-Google-Sender-Auth: tS2gt0YJCssvSD8dmDCfrfh3zjU Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: multipart/alternative; boundary=f46d04088c7f2ddc8904c6ed73ac Cc: Brandon Long , "imapext@ietf.org" Subject: Re: [imapext] IMAP clients X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 18:24:10 -0000 --f46d04088c7f2ddc8904c6ed73ac Content-Type: text/plain; charset=ISO-8859-1 > As a side note: as much as I like complaining about Outlook and its use of IMAP, > IMAP IDLE command is actually allowed when no folder is selected. The behavior > is undocumented (most servers wouldn't send any updates in such case), but the > command is still valid in such state. We left that open because we had talked about the possibility of unsolicited LIST responses to indicate new mailboxes, and other things like that. In practice today, alerts are the only things likely to be sent in AUTHENTICATED state. Barry --f46d04088c7f2ddc8904c6ed73ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > As a side note: as much as I li= ke complaining about Outlook and its use of IMAP,
> IMAP IDLE command is actually allowed when no= folder is selected. The behavior
> is undocumented (most serv= ers wouldn't send any updates in such case), but the
<= span class=3D"Apple-style-span" style>> command is still valid in such s= tate.

We left that o= pen because we had talked about the possibility of unsolicited LIST respons= es to indicate new mailboxes, and other things like that. =A0In practice to= day, alerts are the only things likely to be sent in AUTHENTICATED state.

Barry
--f46d04088c7f2ddc8904c6ed73ac-- From arnt@gulbrandsen.priv.no Fri Aug 10 13:21:14 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA9221F8699 for ; Fri, 10 Aug 2012 13:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqPBcZp5XcSc for ; Fri, 10 Aug 2012 13:21:14 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id DABCA21F86CF for ; Fri, 10 Aug 2012 13:21:13 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 17F14F8E746; Fri, 10 Aug 2012 20:21:13 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1344630072-14582-14581/10/4; Fri, 10 Aug 2012 20:21:12 +0000 Message-Id: <50256D3C.2020609@gulbrandsen.priv.no> Date: Fri, 10 Aug 2012 22:21:16 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> <502362E9.1060901@isode.com> <5023BAFA.4080104@gulbrandsen.priv.no> <50251CC5.8000905@isode.com> <5025235D.1070000@gulbrandsen.priv.no> <50252A26.8030008@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 20:21:14 -0000 On 08/10/2012 08:20 PM, Barry Leiba wrote: > I'm confused: are you saying that clients should be willing to accept a > new message with a UID that is *less* than those of some existing ones, > and that if they don't accept that, they're being overly rigorous? I'm saying that this optimisation isn't valuable enough that we should even be discussing the question. And it's not a new message, it's a UID mentioned in COPYUID, not quite the same thing. Do you want to discuss that difference or just skip the optimisation? Arnt From barryleiba.mailing.lists@gmail.com Fri Aug 10 13:58:49 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A8121F8623 for ; Fri, 10 Aug 2012 13:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.025 X-Spam-Level: X-Spam-Status: No, score=-103.025 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20zKAhY1ZLzc for ; Fri, 10 Aug 2012 13:58:49 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27F2521F8613 for ; Fri, 10 Aug 2012 13:58:48 -0700 (PDT) Received: by lahm15 with SMTP id m15so1131868lah.31 for ; Fri, 10 Aug 2012 13:58:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=owjZVpcdntIKwB5sjlJ67cTTZLLO15dTPYr+ESsJluY=; b=C3q0b8plqPIahWqqj28wbTbuYgAdOxZS1pvrf890SMsackFI8lJPr/zLXszBY8cf+i qJR1YfNfmgKoAQ82ZRWiljuaGkwBBuxIy+JP7UOdT1Gm3fzBfUqTMyfe7vJzpqH8mkQn Q2MzGqiN7u0YMjRqJl5aatqdN/4glW5VhCgTx9qlN6mYg/w5msgltz1ylqFhafKGbugd P3mqMTs9ivOx6l+SMGEbrp9/X7mAuBzSwB+z/lsj0CNEdXLpYnLuPNgI0W5gLAeIQR7W c/V3BhqizmqzWcWCGN+/fYvaObSCauzsqznvOp1ooUrfwxxk1SeDktwz337Xrm8DY8G2 AxcQ== MIME-Version: 1.0 Received: by 10.112.10.135 with SMTP id i7mr2967726lbb.27.1344632328001; Fri, 10 Aug 2012 13:58:48 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.113.196 with HTTP; Fri, 10 Aug 2012 13:58:47 -0700 (PDT) In-Reply-To: <50256D3C.2020609@gulbrandsen.priv.no> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <9e083ecf-3e3c-4921-9855-2fe353efc344@email.android.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> <502362E9.1060901@isode.com> <5023BAFA.4080104@gulbrandsen.priv.no> <50251CC5.8000905@isode.com> <5025235D.1070000@gulbrandsen.priv.no> <50252A26.8030008@gulbrandsen.priv.no> <50256D3C.2020609@gulbrandsen.priv.no> Date: Fri, 10 Aug 2012 16:58:47 -0400 X-Google-Sender-Auth: tcckfdOC0xk8vgOQBu6bgck-Rek Message-ID: From: Barry Leiba To: Arnt Gulbrandsen Content-Type: text/plain; charset=ISO-8859-1 Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 20:58:50 -0000 >> I'm confused: are you saying that clients should be willing to accept a >> new message with a UID that is *less* than those of some existing ones, >> and that if they don't accept that, they're being overly rigorous? > > I'm saying that this optimisation isn't valuable enough that we should even > be discussing the question. And it's not a new message, it's a UID mentioned > in COPYUID, not quite the same thing. Do you want to discuss that difference > or just skip the optimisation? No, I want to know what you mean by this, which you did not address in your answer: > It's also possible that some clients depend on UID allocation being > monotonic to a somewhat higher degree than they perhaps should. Barry From arnt@gulbrandsen.priv.no Fri Aug 10 14:09:35 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669FA11E8097 for ; Fri, 10 Aug 2012 14:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkgq2KSdM6xj for ; Fri, 10 Aug 2012 14:09:35 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB07211E808E for ; Fri, 10 Aug 2012 14:09:34 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 2876AF8E75D; Fri, 10 Aug 2012 21:09:34 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1344632972-14582-14581/10/6; Fri, 10 Aug 2012 21:09:32 +0000 Message-Id: <50257890.7040701@gulbrandsen.priv.no> Date: Fri, 10 Aug 2012 23:09:36 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> <502362E9.1060901@isode.com> <5023BAFA.4080104@gulbrandsen.priv.no> <50251CC5.8000905@isode.com> <5025235D.1070000@gulbrandsen.priv.no> <50252A26.8030008@gulbrandsen.priv.no> <50256D3C.2020609@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 21:09:35 -0000 On 08/10/2012 10:58 PM, Barry Leiba wrote: > No, I want to know what you mean by this, which you did not address in > your answer: > >> >It's also possible that some clients depend on UID allocation being >> >monotonic to a somewhat higher degree than they perhaps should. I was too oblique. Sorry. Clearly, if a server assigns a new UID, the newly assigned is has to be greater than or equal to the advertised uidnext value for that mailbox. But is a client permitted to assume that any UID mentioned in the target set of a COPYUID response code is newly assigned? I believe that most clients are either written by programmers who expect every UID there to be newly assigned, or have only been tested with newly assigned UIDs, or both. In light of this, I think that the optimisation is not worth even discussing. Arnt From barryleiba.mailing.lists@gmail.com Fri Aug 10 14:16:05 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A1321F852E for ; Fri, 10 Aug 2012 14:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.025 X-Spam-Level: X-Spam-Status: No, score=-103.025 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwPt1zIBvb8V for ; Fri, 10 Aug 2012 14:16:04 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F29D21F8526 for ; Fri, 10 Aug 2012 14:16:04 -0700 (PDT) Received: by lbbgg6 with SMTP id gg6so1177564lbb.31 for ; Fri, 10 Aug 2012 14:16:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=X9nk1wFgOn6cHdGlB54qMUtXayxCpufbgyEOegiB3kM=; b=0de7e6XJYiisKbv+B9DZ3Ow97RkUeoY/LgvSFGVykSR2KeXeBKTJ1zhVjjYQEJUnA/ lqvxY+MUgWHHRho0mdOn5G4bCewYjuthBgjjpmaGNK4wPa9ugW1zgM1kM4B+qw1yZlzv qu6K4dYYxmxuQn4r6DL8LJ+oY4pbgoRVtIIimTCW8CL+mb4D86NTgBTKqN208tjI5yVR d8laXxSJFx3K2EhZfw8jeKXiDLuElTLmsAEO47742CCDvRboXAVUSv/PcN/raeI0wiqK SZoNVkqUdFZ/infejGLqRgZkSwY7RqqLxXxSqTMzdI2rMeiq9uXoJETN7Z33fBObOYN8 NdnA== MIME-Version: 1.0 Received: by 10.112.43.135 with SMTP id w7mr3013783lbl.48.1344633363474; Fri, 10 Aug 2012 14:16:03 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.113.196 with HTTP; Fri, 10 Aug 2012 14:16:03 -0700 (PDT) In-Reply-To: <50257890.7040701@gulbrandsen.priv.no> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> <502362E9.1060901@isode.com> <5023BAFA.4080104@gulbrandsen.priv.no> <50251CC5.8000905@isode.com> <5025235D.1070000@gulbrandsen.priv.no> <50252A26.8030008@gulbrandsen.priv.no> <50256D3C.2020609@gulbrandsen.priv.no> <50257890.7040701@gulbrandsen.priv.no> Date: Fri, 10 Aug 2012 17:16:03 -0400 X-Google-Sender-Auth: Caj5ciQH5JP5f5D_jq3G_T2JgYc Message-ID: From: Barry Leiba To: Arnt Gulbrandsen Content-Type: text/plain; charset=ISO-8859-1 Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 21:16:05 -0000 > Clearly, if a server assigns a new UID, the newly assigned is has to be > greater than or equal to the advertised uidnext value for that mailbox. But > is a client permitted to assume that any UID mentioned in the target set of > a COPYUID response code is newly assigned? I believe so, yes. The sense is that the "new" copy is, indeed, new. > I believe that most clients are either written by programmers who expect > every UID there to be newly assigned, or have only been tested with newly > assigned UIDs, or both. Yes. > In light of this, I think that the optimisation is not worth even discussing. OK. Thanks for clarifying. b From blong@google.com Fri Aug 10 15:07:46 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5259411E8087 for ; Fri, 10 Aug 2012 15:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.811 X-Spam-Level: X-Spam-Status: No, score=-102.811 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMgy3bDQR2XO for ; Fri, 10 Aug 2012 15:07:45 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9305E11E8091 for ; Fri, 10 Aug 2012 15:07:45 -0700 (PDT) Received: by yenm5 with SMTP id m5so2296181yen.31 for ; Fri, 10 Aug 2012 15:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=IN4y5KF+IYMbxlp27JWoruMEPEbwDAyOYP/R1p1VxXw=; b=PWqiHpX5oSxFRGAR4eZ1QvWHm2Oox5q7f/P3PNvvOYnw3v6U0VfJ73AJh5QwYVimvp gWZbu7sbuGJf1A7IUd89KfeI6EbDr1tj6Hk3VBVQkbzn0qvJ9G2xsC6+jECFLpTbe2Cp j3rcBQLTBwu711VQyaCBy0kqEGR35Ee4Zpzw3jhYxtQQ8pUL+kBxuejHkeJuO06/ZUsW CIbeykyN7sjtSyCMjghjww2UkVGXhUjZWA7Xji15COKqViXEG6U8UFaORmcDSgydVTIJ Wy+JFkGQSvFK7g8+8CFlDOp2O9QbI6FAb9kuiHe/zDdPYcKMURchPUZjInkJt3gJTGcl eqMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=IN4y5KF+IYMbxlp27JWoruMEPEbwDAyOYP/R1p1VxXw=; b=MQJU52YCpHw7RVbDnboyQ8kr/4dtJph0DLyb1vdixoHOsya2skWT/JH93vk+uwku1P NeVpa1oup7tk4H0sYu7gyp7R99VkPkHx0PbOG9t5Tl7un/JLhC8mHzvxN2keqZ9BzUuc HXP6qGb0oIoXx/s1jBm3ZwtEZ/fIAb4FOXmn4Zy0qe/Ti8F5ljE+e0tC1xskZlHKrH3o aSYlSszQZ2uZTlZakneeA64iRkuBnJE6GsPKdFpqxSwAwL8Xv5IUMTE+6fv5TwHcaait P+yxT1zAhwDaCSeIYcGqWBXh6tjakwYCscxh5AdstE5k82Jp40Mk2vG9bQD+JG9FdaCe wZmg== Received: by 10.60.2.74 with SMTP id 10mr1424334oes.64.1344636465045; Fri, 10 Aug 2012 15:07:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.2.74 with SMTP id 10mr1424321oes.64.1344636464792; Fri, 10 Aug 2012 15:07:44 -0700 (PDT) Received: by 10.76.81.131 with HTTP; Fri, 10 Aug 2012 15:07:44 -0700 (PDT) In-Reply-To: <50257890.7040701@gulbrandsen.priv.no> References: <20120628211501.4968.42901.idtracker@ietfa.amsl.com> <50144352.7040603@gulbrandsen.priv.no> <50156C5B.2000103@gulbrandsen.priv.no> <20A1D2CC-7920-49C3-BB8B-4322DFA0AC61@isode.com> <50159CBE.3050308@gulbrandsen.priv.no> <1343823040.6281.140661109318169.304420AA@webmail.messagingengine.com> <502362E9.1060901@isode.com> <5023BAFA.4080104@gulbrandsen.priv.no> <50251CC5.8000905@isode.com> <5025235D.1070000@gulbrandsen.priv.no> <50252A26.8030008@gulbrandsen.priv.no> <50256D3C.2020609@gulbrandsen.priv.no> <50257890.7040701@gulbrandsen.priv.no> Date: Fri, 10 Aug 2012 15:07:44 -0700 Message-ID: From: Brandon Long To: Arnt Gulbrandsen Content-Type: multipart/alternative; boundary=e89a8fb20340d6063904c6f0921a X-System-Of-Record: true X-Gm-Message-State: ALoCoQn8ghEqdjqlwUJj5jXFp2c/2cL8wVqJpie2NGMsBvdQ2y6GjPp+rK5OTLVSfzaJJP62nfMW25YufR4aW5it4PRsRmofQYVVUqo3yL7jkJHhcy1fq5DeAXIH+wWvc8XtOrkwFiCJzAsuZeRse7Y+vrWi+j/f9WKKYkTnc7IXrR3lqZQL44Z6liRhJtOxX5vR/bvnjVvt Cc: imapext@ietf.org Subject: Re: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 22:07:46 -0000 --e89a8fb20340d6063904c6f0921a Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 10, 2012 at 2:09 PM, Arnt Gulbrandsen wrote: > On 08/10/2012 10:58 PM, Barry Leiba wrote: > >> No, I want to know what you mean by this, which you did not address in >> your answer: >> >> >It's also possible that some clients depend on UID allocation being >>> >monotonic to a somewhat higher degree than they perhaps should. >>> >> > I was too oblique. Sorry. > > Clearly, if a server assigns a new UID, the newly assigned is has to be > greater than or equal to the advertised uidnext value for that mailbox. But > is a client permitted to assume that any UID mentioned in the target set of > a COPYUID response code is newly assigned? > > I believe that most clients are either written by programmers who expect > every UID there to be newly assigned, or have only been tested with newly > assigned UIDs, or both. In light of this, I think that the optimisation is > not worth even discussing. I'm pretty sure that Gmail violates that. Since a COPY translates to adding a label, and there is only ever one "copy" of a message, if you copy a message to a folder that the message is already in, you'll get the original UID back. If you're copying from the same folder to itself, we will give all of the messages new UIDs. This and other reasons also mean that the destination UIDs in the COPYUID are necessarily in numeric order, either. Though, it also wasn't clear to me from the spec whether or not the source UIDs are supposed to be in the order requested or not (we re-order the source UIDs to be in numeric order). Nobody's complained yet, at least that I know of. Brandon --e89a8fb20340d6063904c6f0921a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, A= ug 10, 2012 at 2:09 PM, Arnt Gulbrandsen <arnt@gul= brandsen.priv.no> wrote:
On 08/10/2012 10:58 PM, Ba= rry Leiba wrote:
No, I want to know what you mean by this, which you did not address in
your answer:

>It's also possible that some clients depend on UID allocation being=
>monotonic to a somewhat higher degree than they perhaps should.

I was too oblique. Sorry.

Clearly, if a server assigns a new UID, the newly assigned is has to be gre= ater than or equal to the advertised uidnext value for that mailbox. But is= a client permitted to assume that any UID mentioned in the target set of a= COPYUID response code is newly assigned?

I believe that most clients are either written by programmers who expect ev= ery UID there to be newly assigned, or have only been tested with newly ass= igned UIDs, or both. In light of this, I think that the optimisation is not= worth even discussing.

I'm pretty sure that Gmail violates that. =A0Since = a COPY translates to adding a label, and there is only ever one "copy&= quot; of a message, if you copy a message to a folder that the message is a= lready in, you'll get the original UID back.

If you're copying from the same folder to itself, w= e will give all of the messages new UIDs.

This and other reas= ons also mean that the destination UIDs in the COPYUID are necessarily in n= umeric order, either. =A0Though, it also wasn't clear to me from the sp= ec whether or not the source UIDs are supposed to be in the order requested= or not (we re-order the source UIDs to be in numeric order).

Nobody's complained yet, at least that I know of.

Brandon
--e89a8fb20340d6063904c6f0921a-- From tss@iki.fi Sat Aug 11 15:55:30 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0272311E8091 for ; Sat, 11 Aug 2012 15:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.529 X-Spam-Level: X-Spam-Status: No, score=-110.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8s9pPVOxnUoq for ; Sat, 11 Aug 2012 15:55:29 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 38FBC11E808E for ; Sat, 11 Aug 2012 15:55:29 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 95FCE1AE87DA; Sun, 12 Aug 2012 01:55:27 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Sun, 12 Aug 2012 01:55:27 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> To: Brandon Long X-Mailer: Apple Mail (2.1084) Cc: imapext@ietf.org Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 22:55:30 -0000 On 7.8.2012, at 0.00, Brandon Long wrote: > Does anyone want to write up a set of tests for the new functionality? >=20 > Either based on the Timo's existing test suite or something else. I added a move test now to latest imaptest hg (requires new imaptest = because it triggered a couple of imaptest bugs): http://hg.dovecot.org/imaptest/file/tip/src/tests/move The test works the way I think we decided how the SHOULDs would be in = the next draft. I also found a bug from my implementation with it: MOVE command didn't = always send EXPUNGE before OK reply, because the code assumed that this = command didn't change the source mailbox (which was true with COPY, but = not with MOVE). From arnt@gulbrandsen.priv.no Sun Aug 12 00:11:48 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120C921F84DF for ; Sun, 12 Aug 2012 00:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JH31Nbpvz4e6 for ; Sun, 12 Aug 2012 00:11:47 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 831F821F84CD for ; Sun, 12 Aug 2012 00:11:47 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 42F2FF8C58B; Sun, 12 Aug 2012 07:11:45 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1344755504-16755-16754/10/1; Sun, 12 Aug 2012 07:11:44 +0000 Message-Id: <50275735.2070803@gulbrandsen.priv.no> Date: Sun, 12 Aug 2012 09:11:49 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0 Mime-Version: 1.0 To: imapext@ietf.org References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> In-Reply-To: Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Aug 2012 07:11:48 -0000 On 08/12/2012 12:55 AM, Timo Sirainen wrote: > The test works the way I think we decided how the SHOULDs would be in = the next draft. It's posted. Arnt From jkt@flaska.net Thu Aug 16 10:38:49 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0340821F8678 for ; Thu, 16 Aug 2012 10:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.207 X-Spam-Level: X-Spam-Status: No, score=-0.207 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPLCaEYEjKfR for ; Thu, 16 Aug 2012 10:38:48 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEF821F8668 for ; Thu, 16 Aug 2012 10:38:43 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHkvLVCT5xpZ/2dsb2JhbABFhgG0LIEHgiABAQUjDwEFQBELGAICBRYLAgIJAwIBAgFFEwgBAQWIBAunSJMlgSGKA4UrgRIDkiGDLoEUjn6CYYFd X-IronPort-AV: E=Sophos;i="4.77,780,1336341600"; d="scan'208";a="217439" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 16 Aug 2012 19:38:41 +0200 Received: from svist.flaska.net (pc069c.fzu.cz [147.231.27.69]) by freja.fzu.cz (Postfix) with ESMTPSA id 0F19C3DA82 for ; Thu, 16 Aug 2012 19:38:41 +0200 (CEST) Message-ID: <502D3008.3010508@flaska.net> Date: Thu, 16 Aug 2012 19:38:16 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120128 Thunderbird/9.0 MIME-Version: 1.0 To: imapext@ietf.org References: <01OIK0GA2IYO0006TF@mauve.mrochek.com> <01OIKQHRTLOU0006TF@mauve.mrochek.com> In-Reply-To: <01OIKQHRTLOU0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:38:49 -0000 On 08/02/12 19:54, Ned Freed wrote: > 8BITMIME. BINARY. SIZE. ENHANCEDSTATUSCODES. FUTURERELEASE. DELIVERBY. > MT-PRIORITY. CHUNKING. PIPELINING. MTRK. Dear Ned, thanks for your participation in this thread, and please accept my apologies for a late reply (it was vacation time for me). I'm happy to see someone who is signed under so many SMTP-related RFCs reviewing my proposal. First of all, your biggest complaint is about the lack of extensibility that my proposal brings. I suspect this is due to a misunderstanding -- even though the ABNF does not contain any explicit notion of future extensions at this point, the command was designed from the very start with extensibility in mind -- see the discussion about further SENDMAIL=* capabilities which serve as a way to inform the client about presence of these extensions, and the submission-option grammar non-terminal which is intended to be easily extended by future proposals. In basic IMAP, the protocol reserves the X commands for experimental use, but all of the extensions in the end ended up defining their own commands anyway. I could certainly have added a similar thing to the grammar, i.e. something like this: submission-option /= sub-option-future-use sub-option-future-use = identifier SP sub-option-any-data identifier = atom ;; MUST start with X or be registered in ... IANA registry sub-option-any-data = atom / number / ( "(" sub-option-any-data 1*(SP sub-option-any-data) ")" ) Quite frankly, this is not something which I find terribly clear, and I'm not a huge fan of adding grammar extensions without defining their meaning. At the same time, it illustrates the design idea pretty well, so I might add that in if that's the consensus. The goal of the proposal from the very start was to create a command which accepts the following data as input: * the identification of an existing IMAP message to send * the identification of recipients, if desired * a list of optional submission options Where the list of "submission options" is designed to be extensible by future extensions, as they appear in ESMTP. The DSN example shows how such an "extension" will look like, and it was my intention to allow for similar additions when they prove to be worth the effort. Now the second complaint is that each ESMTP extension will have to find its equivalent in this IMAP-SUBMIT protocol -- and that's right, but it's also a tautology. Any proposal which works in a different way than proxying an actual ESMTP session to an SMTP server *will* necessarily result in the need to re-create an extension for each relevant ESMTP addon. That's an inherent disadvantage of my proposal, yes. The third complaint was that I do not address many issues which prompted creation of several existing ESMTP extensions. Let's review each of them separately, as they appear in [1], and let's see how they are relevant to the submission over IMAP. I suspect that I might be missing some obvious things, as SMTP is not my cup of tea -- which is why I'm open to feedback and would like to learn from my mistakes. I'll be grateful if you (or anyone else, for that matter) corrects my misunderstanding or point out flaws in my ideas. - 8BITMIME tells the ESMTP clients that they can submit messages containing 8bit octets. You raise a good point in that the clients of the UID SUBMIT command SHOULD know whether the message body they're creating is actually allowed to contain 8bit data; that's something I missed in my proposal. Would it be enough if we mandate that the UID SUBMIT command MUST always accept such messages? Are there any MTAs (which could be expected to be installed along an IMAP server, i.e. no ancient versions of already deployed software) and which cannot support the 8bit MIME messages at the same time? Or shall we mandate another capability like SENDMAIL=8BITMIME? - SIZE --- the IMAP server knows the message size, and if the "real submission" takes place over the ESMTP, it can use the actual size and check the ESMTP server's constraints prior to the message delivery. Do you want me to add an explicit machine-readable code MESSAGETOOBIGFORSUBMISSION to make it possible to report back this failure in a machine-readable way? Apart from that, I don't see any further action to be necessary here. - ONEX -- I don't believe this one is relevant here. - CHUNKING, BINARYMIME -- not applicable in the context of submission-over-IMAP; they're already handled by CATENATE anyway. - CHECKPOINT -- the submission is "atomic" from the IMAP client's point of view already, and the amount of data being sent between the IMAP client and the server is minimal, so there's no point in being able to "restart" this command, IMHO. - DELIVERBY -- if MUAs want this feature, it can be added in a future extension. The grammar change would be trivial. Or is it worth defining that already in the basic proposal? - PIPELINING -- optimization of the ESMTP protocol. IMAP doesn't need that, pipelining is already supported. Just to make it absolutely clear, nothing prevents the IMAP servers from utilizing this extension *when delivering over ESMTP*, but at the same time, this is their own implementation detail which does not require any support in the submit-over-IMAP proposal. - You're right in that the DSN extension is per-recipient and not per-message. This will require further work; I'll address that in the next version of the proposal. Thanks for letting me know! However, I believe that the ORCPT is not required for e-mail submission -- please correct me if I'm wrong. The ENVID and RET look like they should be supported -- opinions about this are welcome. - ETRN, ENHANCEDSTATUSCODES, STARTTLS, NO-SOLICITING don't apply for mail submission over IMAP, AFAIK. - MTRK can be added in future if there's interest. - SUBMITTER -- I've skimmed over that experimental RFC and it appears to me that this might not necessarily apply in the context of outgoing e-mail submission. Comments welcome. - ATRN, AUTH -- not applicable, AFAIK. - BURL -- already handled by CATENATE, hence not needed. - FUTURERELEASE -- can be supported by future extension if needed. Is that worth being defined in the basic protocol? - UTF8SMTP -- would require extending the allowed domain of the addresses passing through this command. That's a material for future extension, IMHO, unless the consensus is that it shall be there from the very beginning. Shall it? I don't have an opinion here. - CONPERM, CONNEG -- based on the complete non-existence of any IMAP server supporting the CONVERT extension, I seriously doubt this one will be ever needed. If there's a need for it, though, it should be easy to support it using the usual submit-option syntax in a future extension. As usual, comments welcome. - MT-PRIORITY -- can be covered by a submit extension, if there's a need for it. Is it? I don't know, I'm honestly asking. So all in all, it seems to me that the UID SUBMIT proposal is capable of accommodating all ESMTP extensions introduced so far. Yes, there's a certain amount of work required by "porting" the extension to this IMAP command, but the amount of required work seems to be negligible. There's also a question whether these options are really needed for client-originated mail submission -- I can easily write a document for it, and IMAP servers which use ESMTP can easily support that, but is it worth the effort? Would clients actually make use of, say, MTRK or MT-PRIORITY? One of the goals I had in mind was to be able to implement this on the server-side using just the `sendmail`-compatible interface, like what Postfix offers. In its current version, it doesn't support anything besides DSN (and that on a per-message manner only), so that's what the current draft allows. I'll be happy to add more stuff to the list if that's the direction that people prefer, but I also don't prefer to design extensions which nobody would use anyway. In this mail, I just wanted to show that the proposed command in fact *can* accommodate the requirements of all of the existing ESMTP extensions. Have I managed to change your mind about the value of this proposal? With kind regards, Jan [1] http://www.iana.org/assignments/mail-parameters -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From jkt@flaska.net Sat Aug 25 10:10:55 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5893621F84DD for ; Sat, 25 Aug 2012 10:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.962 X-Spam-Level: X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ym59dWzGlMTH for ; Sat, 25 Aug 2012 10:10:54 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6F02421F84DC for ; Sat, 25 Aug 2012 10:10:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0DAM0GOVCT5xpZgWdsb2JhbABFhTxHtGgiAQEWJieCIQEFI1URCyETAwsCAgkDAgECAUUTCAEBiAkEB6kgkjuLIoNbggqBEgOOX4EghVaBFJFmgV8 X-IronPort-AV: E=Sophos;i="4.80,311,1344204000"; d="asc'?scan'208";a="264765" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 25 Aug 2012 19:10:27 +0200 Received: from svist.flaska.net (ip-89-176-26-68.net.upcbroadband.cz [89.176.26.68]) by freja.fzu.cz (Postfix) with ESMTPSA id A3A6F3DA82 for ; Sat, 25 Aug 2012 19:10:27 +0200 (CEST) Message-ID: <503906E1.8020706@flaska.net> Date: Sat, 25 Aug 2012 19:09:53 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: imapext@ietf.org References: <500AE394.3010504@flaska.net> In-Reply-To: <500AE394.3010504@flaska.net> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDC4594FBFE6A30526D9BBAA4" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 17:10:55 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDC4594FBFE6A30526D9BBAA4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, thanks for all the feedback I received. I've tried to incorporate that in the updated draft which lives on [1]. In this iteration, I tried to focus on the "it can do what ESMTP can do" aspect. I don't know whether it is a correct choice to support RET and ENVID, and I hope people will tell me the answer. These can be removed in future revisions if the consensus is that they are not needed/used. So, does this extension have any chance of getting standardized and supported? With kind regards Jan [1] http://tools.ietf.org/html/draft-kundrat-imap-submit-00 --=20 Trojita, a fast e-mail client -- http://trojita.flaska.net/ --------------enigDC4594FBFE6A30526D9BBAA4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA5BuYACgkQamXfqERyJRc+2ACglMVT9ofBCmBaOdbiJ5SoVy3L aAQAoJbdLhgwDoU/jzziVkGCyqaKYVK4 =l8hy -----END PGP SIGNATURE----- --------------enigDC4594FBFE6A30526D9BBAA4-- From jkt@flaska.net Sat Aug 25 10:49:49 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D32D21F84B9 for ; Sat, 25 Aug 2012 10:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.96 X-Spam-Level: X-Spam-Status: No, score=-0.96 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBhbib7atBOE for ; Sat, 25 Aug 2012 10:49:48 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1E021F8489 for ; Sat, 25 Aug 2012 10:49:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0DAEwPOVCT5xpZgWdsb2JhbABFhTxHtGgiAQEWJieCIQEFI1URCyETAwsCAgkDAgECAUUTCAEBiAkEB6kbkjWLIQGDW4IKgRIDjl+BIIVWgRSRZoFf X-IronPort-AV: E=Sophos;i="4.80,311,1344204000"; d="asc'?scan'208";a="264822" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 25 Aug 2012 19:49:45 +0200 Received: from svist.flaska.net (ip-89-176-26-68.net.upcbroadband.cz [89.176.26.68]) by freja.fzu.cz (Postfix) with ESMTPSA id B31213DA82 for ; Sat, 25 Aug 2012 19:49:45 +0200 (CEST) Message-ID: <5039101D.1040209@flaska.net> Date: Sat, 25 Aug 2012 19:49:17 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: imapext@ietf.org References: <50116C8A.8070609@flaska.net> In-Reply-To: <50116C8A.8070609@flaska.net> X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF190FD43593555967BFDF45D" Subject: Re: [imapext] Draft for server-side incremental threading X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 17:49:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF190FD43593555967BFDF45D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I haven't received much feedback on this incremental thread topic. The draft now lives on the IETF's web [1]. A quick recap of why it is needed: - My client issues "UID THREAD $algo $charset ALL" and relies on server-side threading. - It doesn't fetch anything but UID and FLAGS for all messages in a mailb= ox. - When new message arrives, it cannot therefore "plug" it into the threading tree without performing expensive operations. The uploaded draft has seen only some minor editing for English fixes and better style; there have been no important changes since the previous post. I'll appreciate your feedback on this draft as well. Are there any server vendors willing to implement this? With kind regards, Jan [1] http://tools.ietf.org/id/draft-kundrat-incthread-00 --=20 Trojita, a fast e-mail client -- http://trojita.flaska.net/ --------------enigF190FD43593555967BFDF45D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA5EB0ACgkQamXfqERyJRcYKwCglBULnJcJI71rTbgdzkgodRbK sDwAnitM4g/5edZL/oR6LvBieH7lK9xa =Ykn3 -----END PGP SIGNATURE----- --------------enigF190FD43593555967BFDF45D-- From barryleiba.mailing.lists@gmail.com Sat Aug 25 11:35:41 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFE521F84FB for ; Sat, 25 Aug 2012 11:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.002 X-Spam-Level: X-Spam-Status: No, score=-103.002 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gyzDpwO+tQu for ; Sat, 25 Aug 2012 11:35:41 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA8FE21F84F9 for ; Sat, 25 Aug 2012 11:35:40 -0700 (PDT) Received: by lahm15 with SMTP id m15so1848958lah.31 for ; Sat, 25 Aug 2012 11:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nrYcfoFPUibCR0AO4RuIDs2Z/Sdc9ycoHwIyAJZgvnk=; b=gjXEu3jpLnQci0pXVF9LXB16G2DdQwGetsswaOwxvwPisO2ghDzbC5uFeLZc72lTN8 w0H1E9uMDMw+Q5XPBPbhKNnLqb/CXYNlxyl9cASLQvZoc/XlGYnYWmyaQFfflkqvuBoJ 1qFNgCMBJUhXxhJGFj1VPqkAddWziFQe7u9yaC+Ehhlj2lEwlekwo5vgGR6E9NlX78nf lqc6h8JKehXLTEBdKMNWulS5RhsCC701m+Tg9OgJW8zDHny6eu5lhtSjFxDsvUfGZbtn FYk+7edqxmyoH3PRUzQaauF9hl2/OB4bY/wB92PcAteNg+vlCggdILXSOWGV+7LrcLpG h5Zw== MIME-Version: 1.0 Received: by 10.152.113.68 with SMTP id iw4mr9443362lab.50.1345919739385; Sat, 25 Aug 2012 11:35:39 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.113.196 with HTTP; Sat, 25 Aug 2012 11:35:39 -0700 (PDT) In-Reply-To: <50275735.2070803@gulbrandsen.priv.no> References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> <50275735.2070803@gulbrandsen.priv.no> Date: Sat, 25 Aug 2012 14:35:39 -0400 X-Google-Sender-Auth: vcjRgyI2or4vdsh49TBI_ErjcEA Message-ID: From: Barry Leiba To: Arnt Gulbrandsen Content-Type: text/plain; charset=ISO-8859-1 Cc: imapext@ietf.org Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 18:35:41 -0000 >> The test works the way I think we decided how the SHOULDs would be in the >> next draft. > > It's posted. The "it", here, being http://tools.ietf.org/html/draft-ietf-imapmove-command-01 Arnt posted that almost a month ago, and there have been no comments since. Does that mean it's ready to go? Barry, doing a little AD poke here From tss@iki.fi Sat Aug 25 11:38:32 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A073321F84F9 for ; Sat, 25 Aug 2012 11:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.448 X-Spam-Level: X-Spam-Status: No, score=-110.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-CxKKiGVHZp for ; Sat, 25 Aug 2012 11:38:32 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 06DBB21F845E for ; Sat, 25 Aug 2012 11:38:32 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id BA94F1AE876C; Sat, 25 Aug 2012 21:38:30 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Sat, 25 Aug 2012 21:38:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0484ACEB-2C5A-4168-83A3-A64D908D33E8@iki.fi> References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> <50275735.2070803@gulbrandsen.priv.no> To: Barry Leiba X-Mailer: Apple Mail (2.1084) Cc: Arnt Gulbrandsen , imapext@ietf.org Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 18:38:32 -0000 On 25.8.2012, at 21.35, Barry Leiba wrote: >>> The test works the way I think we decided how the SHOULDs would be = in the >>> next draft. >>=20 >> It's posted. >=20 > The "it", here, being = http://tools.ietf.org/html/draft-ietf-imapmove-command-01 > Arnt posted that almost a month ago, and there have been no comments > since. Does that mean it's ready to go? I think there were some comments after that that Arnt said he changed = already? But basically yes, I'd say it's done. From barryleiba.mailing.lists@gmail.com Sat Aug 25 11:42:04 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A343521F84D4 for ; Sat, 25 Aug 2012 11:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.852 X-Spam-Level: X-Spam-Status: No, score=-102.852 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wx5EZUPuYqAl for ; Sat, 25 Aug 2012 11:42:04 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D580421F845E for ; Sat, 25 Aug 2012 11:42:03 -0700 (PDT) Received: by lahm15 with SMTP id m15so1850722lah.31 for ; Sat, 25 Aug 2012 11:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fCCCgQjt6cUer60AvyfIwXgERCi2cSVM/CN0FuoPb0w=; b=U4ruLJjOiH2/hdRRLf0TtPdegMuyIwZZzHD4cwuDzbXE4ZHoI1EjE2wAFAOgisY7Sx 6JSK3YMbFbYozCAol8gSg1tFEI7p0lGc0A6tcDWwdEzOKGrGcNvNxGvIBhYmSuS8Fj9l ZURaWSfpMfqazDDd1Q3g7iflA7aL30dAFHnjG9kQ3EkkhOd6gZLwMlnmDwRVc4CSrIxk guYsF+e0YiloUZuUJyHCXvg0mlDVjQ0TNMWXfZxk48uCGjsNrxcLesi+hgV9cNNOgs// p+3S9sWe2R5Ws8E248xrM60OisvelD5TmBdLpTxCs6/PrW9eLdpq3nejQTRq4AsuUD5Z Gu3Q== MIME-Version: 1.0 Received: by 10.112.43.135 with SMTP id w7mr4363292lbl.48.1345920122737; Sat, 25 Aug 2012 11:42:02 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.113.196 with HTTP; Sat, 25 Aug 2012 11:42:02 -0700 (PDT) In-Reply-To: <503906E1.8020706@flaska.net> References: <500AE394.3010504@flaska.net> <503906E1.8020706@flaska.net> Date: Sat, 25 Aug 2012 14:42:02 -0400 X-Google-Sender-Auth: Bh6krivkiLg6Mi5wKCBTZfFeNdQ Message-ID: From: Barry Leiba To: =?ISO-8859-1?Q?Jan_Kundr=E1t?= Content-Type: text/plain; charset=ISO-8859-1 Cc: imapext@ietf.org Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 18:42:04 -0000 > thanks for all the feedback I received. I've tried to incorporate that > in the updated draft which lives on [1]. > [1] http://tools.ietf.org/html/draft-kundrat-imap-submit-00 ... > So, does this extension have any chance of getting standardized and > supported? ...and... > I haven't received much feedback on this incremental thread topic. The > draft now lives on the IETF's web [1]. > [1] http://tools.ietf.org/id/draft-kundrat-incthread-00 One answer to both of these is the same: right now, the focus on this mailing list is on the imapmove working group, to get the IMAP MOVE spec done. It's up to the chairs how much other discussion they want to have on the list, and so far they've allowed discussion of these other topics, but neither of these specs is going to move toward standardization at this point. After the imapmove working group's work is done, we can consider doing another fast chartering job if there's enough interest in pursuing one or both of these. You may certainly keep the drafts alive in the meantime. Just be aware that the ADs are not going to be putting them through the standards process until imapmove is done, at least. Barry, App AD From jkt@flaska.net Sat Aug 25 11:50:52 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 268C821F84FE for ; Sat, 25 Aug 2012 11:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.959 X-Spam-Level: X-Spam-Status: No, score=-0.959 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CknHcmPV8KFG for ; Sat, 25 Aug 2012 11:50:51 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 354CD21F84FC for ; Sat, 25 Aug 2012 11:50:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4DAGAdOVCT5xpZgWdsb2JhbABFhgO0aCIBARYmJ4IgAQEFI1URCxgJEwMLAgIJAwIBAgFFEwgBAYgJBKkvkiWLIoNbggqBEgOOX4EghVaBFJFmgV8 X-IronPort-AV: E=Sophos;i="4.80,311,1344204000"; d="asc'?scan'208";a="264878" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 25 Aug 2012 20:50:50 +0200 Received: from svist.flaska.net (ip-89-176-26-68.net.upcbroadband.cz [89.176.26.68]) by freja.fzu.cz (Postfix) with ESMTPSA id E00193DA82 for ; Sat, 25 Aug 2012 20:50:49 +0200 (CEST) Message-ID: <50391E6D.6030407@flaska.net> Date: Sat, 25 Aug 2012 20:50:21 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: imapext@ietf.org References: <500AE394.3010504@flaska.net> <503906E1.8020706@flaska.net> In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8B7E7072D7D8E6D7A18BB525" Subject: Re: [imapext] Mail submission over IMAP X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 18:50:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8B7E7072D7D8E6D7A18BB525 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/25/12 20:42, Barry Leiba wrote: > After the imapmove working group's work is done, we can consider doing > another fast chartering job if there's enough interest in pursuing one > or both of these. You may certainly keep the drafts alive in the > meantime. Just be aware that the ADs are not going to be putting them > through the standards process until imapmove is done, at least. I'm fine with that -- at this time, I'd like to get feedback from client vendors to see if they would use these, from the server vendors to know whether they would ever implement them, and of course also from other people to know if there are some obvious errors or shortcomings. If there's a better list to move this discussion to, I'm all ears (and sorry for disturbing the move-related discussion). I see that my question about "getting standardized" was badly-worded; I should have really added "eventually" in there. If everything gets done in a year, I'd be very happy. Sorry for confusion, this is my first time proposing an extension and I'm clearly not so familiar with the process. With kind regards, Jan --=20 Trojita, a fast e-mail client -- http://trojita.flaska.net/ --------------enig8B7E7072D7D8E6D7A18BB525 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA5Hm0ACgkQamXfqERyJRf4swCfcpQyE5pzO9arQBs2dGNpo+0f Cr8AoIS4xxibys3b80fAhBqPhPfXT+TW =M/gI -----END PGP SIGNATURE----- --------------enig8B7E7072D7D8E6D7A18BB525-- From arnt@gulbrandsen.priv.no Sat Aug 25 12:41:30 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56E621F8501 for ; Sat, 25 Aug 2012 12:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4DRxX7Ehxbm for ; Sat, 25 Aug 2012 12:41:29 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6712721F84FE for ; Sat, 25 Aug 2012 12:41:29 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 37EA6F8F364; Sat, 25 Aug 2012 19:41:28 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1345923687-27169-27168/11/4; Sat, 25 Aug 2012 19:41:27 +0000 User-Agent: Kaiten Mail In-Reply-To: <0484ACEB-2C5A-4168-83A3-A64D908D33E8@iki.fi> References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> <50275735.2070803@gulbrandsen.priv.no> <0484ACEB-2C5A-4168-83A3-A64D908D33E8@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 From: Arnt Gulbrandsen Date: Sat, 25 Aug 2012 21:41:20 +0200 Cc: imapext@ietf.org Message-Id: Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 19:41:30 -0000 Yes, I think it's done too. From arnt@gulbrandsen.priv.no Sat Aug 25 12:44:12 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6415F21F84FC for ; Sat, 25 Aug 2012 12:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=-0.606, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf3ytMHEQ1Vu for ; Sat, 25 Aug 2012 12:44:12 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4CA121F84FB for ; Sat, 25 Aug 2012 12:44:11 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4E49DF8F365; Sat, 25 Aug 2012 19:44:11 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1345923850-27169-27168/11/5; Sat, 25 Aug 2012 19:44:10 +0000 User-Agent: Kaiten Mail In-Reply-To: References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> <50275735.2070803@gulbrandsen.priv.no> <0484ACEB-2C5A-4168-83A3-A64D908D33E8@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Arnt Gulbrandsen Date: Sat, 25 Aug 2012 21:44:03 +0200 Cc: imapext@ietf.org Message-Id: <84433633-ec02-4f9a-88a7-1c646bda7876@email.android.com> Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 19:44:12 -0000 I will be back at my desk in a week and able to attend to mail properly = then. Feel free to issue a wglc any time and an lc after sep 3. From alexey.melnikov@isode.com Tue Aug 28 06:05:55 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942B621E804C for ; Tue, 28 Aug 2012 06:05:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.832 X-Spam-Level: X-Spam-Status: No, score=-102.832 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdpIy5OmIK7d for ; Tue, 28 Aug 2012 06:05:55 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id C440821E804B for ; Tue, 28 Aug 2012 06:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1346159152; d=isode.com; s=selector; i=@isode.com; bh=2+yyEN7+3cpvbl1i0YmBBcE3HI+sPMyJbNbHbawoMiA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=E954mCJdltCFk+baoRqGu0sjqDR0qXY9DGwhveomYtnvXu508JnMaAyK2lUYHXUCt8HnnX IVbexsipjGkBnSGsHlaa7Ent7GIUeXs9SoJzJWLf9r0pJWzXBJ89GZpWgQUplKNea7lQvk yCbVWIDn7GF3fkoBlqeK354cvgp70rs=; Received: from [172.16.11.4] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 28 Aug 2012 14:05:52 +0100 Message-ID: <503CC2DB.3050506@isode.com> Date: Tue, 28 Aug 2012 14:08:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Timo Sirainen , Arnt Gulbrandsen References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> <50275735.2070803@gulbrandsen.priv.no> <0484ACEB-2C5A-4168-83A3-A64D908D33E8@iki.fi> In-Reply-To: <0484ACEB-2C5A-4168-83A3-A64D908D33E8@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: imapext@ietf.org Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 13:05:55 -0000 On 25/08/2012 19:38, Timo Sirainen wrote: > On 25.8.2012, at 21.35, Barry Leiba wrote: > >>>> The test works the way I think we decided how the SHOULDs would be in the >>>> next draft. >>> It's posted. >> The "it", here, being http://tools.ietf.org/html/draft-ietf-imapmove-command-01 >> Arnt posted that almost a month ago, and there have been no comments >> since. Does that mean it's ready to go? > I think there were some comments after that that Arnt said he changed already? But basically yes, I'd say it's done. As a chair I would like to see the final editor's version before the document exits the WG (i.e. before IETF LC). But I would be personally Ok with starting WGLC on the current version (I haven't consulted with Ned, so he might disagree.) From ned.freed@mrochek.com Tue Aug 28 07:22:43 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21D3411E80E7 for ; Tue, 28 Aug 2012 07:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+nHBESjF3-a for ; Tue, 28 Aug 2012 07:22:42 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2E221F8433 for ; Tue, 28 Aug 2012 07:22:42 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJKTECWEI8007J55@mauve.mrochek.com> for imapext@ietf.org; Tue, 28 Aug 2012 07:17:40 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Tue, 28 Aug 2012 07:17:38 -0700 (PDT) Message-id: <01OJKTEBV85C0006TF@mauve.mrochek.com> Date: Tue, 28 Aug 2012 07:16:58 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 28 Aug 2012 14:08:43 +0100" <503CC2DB.3050506@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> <50275735.2070803@gulbrandsen.priv.no> <0484ACEB-2C5A-4168-83A3-A64D908D33E8@iki.fi> <503CC2DB.3050506@isode.com> To: Alexey Melnikov Cc: Timo Sirainen , Arnt Gulbrandsen , imapext@ietf.org Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 14:22:43 -0000 > On 25/08/2012 19:38, Timo Sirainen wrote: > > On 25.8.2012, at 21.35, Barry Leiba wrote: > > > >>>> The test works the way I think we decided how the SHOULDs would be in the > >>>> next draft. > >>> It's posted. > >> The "it", here, being http://tools.ietf.org/html/draft-ietf-imapmove-command-01 > >> Arnt posted that almost a month ago, and there have been no comments > >> since. Does that mean it's ready to go? > > I think there were some comments after that that Arnt said he changed already? But basically yes, I'd say it's done. > As a chair I would like to see the final editor's version before the > document exits the WG (i.e. before IETF LC). But I would be personally > Ok with starting WGLC on the current version (I haven't consulted with > Ned, so he might disagree.) Wfm. Ned From arnt@gulbrandsen.priv.no Wed Aug 29 00:13:45 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A99E11E80FF for ; Wed, 29 Aug 2012 00:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8Yvs3wH6jy8 for ; Wed, 29 Aug 2012 00:13:44 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA5211E80F9 for ; Wed, 29 Aug 2012 00:13:43 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 788DAFA115B; Wed, 29 Aug 2012 07:13:42 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1346224420-27169-27168/11/13; Wed, 29 Aug 2012 07:13:40 +0000 User-Agent: Kaiten Mail In-Reply-To: <503CC2DB.3050506@isode.com> References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> <50275735.2070803@gulbrandsen.priv.no> <0484ACEB-2C5A-4168-83A3-A64D908D33E8@iki.fi> <503CC2DB.3050506@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Arnt Gulbrandsen Date: Wed, 29 Aug 2012 09:09:39 +0200 To: Alexey Melnikov , Timo Sirainen Message-Id: Cc: imapext@ietf.org Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 07:13:45 -0000 I didn't have any diff when I left for my vacation, a far as I can = remember. Maybe I confused my two drafts? Start the wglc. My vacation ends this week. Naturally there's a business trip next week = (why does this have to happen to me?) but I will read mail. Arnt From tss@iki.fi Wed Aug 29 08:26:42 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7055B21F86D3 for ; Wed, 29 Aug 2012 08:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.453 X-Spam-Level: X-Spam-Status: No, score=-110.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RaRBggbbOG4 for ; Wed, 29 Aug 2012 08:26:42 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id D047B21F86CF for ; Wed, 29 Aug 2012 08:26:41 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id D3D191AE87C0 for ; Wed, 29 Aug 2012 18:26:39 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Timo Sirainen In-Reply-To: Date: Wed, 29 Aug 2012 18:26:39 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <44D12133-9506-4E4E-B979-83BD74A23AC5@iki.fi> References: To: imapext@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [imapext] IMAP message size limits X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 15:26:42 -0000 BTW: The BINARY extension may also increase the message size beyond = 32bit, if the server receives a Content-Type: binary part in APPEND and = encodes it. From tss@iki.fi Wed Aug 29 11:18:40 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4FB11E80E0 for ; Wed, 29 Aug 2012 11:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.458 X-Spam-Level: X-Spam-Status: No, score=-110.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYbRyaHujq7E for ; Wed, 29 Aug 2012 11:18:40 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 97D8811E80B8 for ; Wed, 29 Aug 2012 11:18:39 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 37E251AE87C0; Wed, 29 Aug 2012 21:18:29 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: Date: Wed, 29 Aug 2012 21:18:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1135CF57-5C76-48EE-B7C1-ABFE75DD1021@iki.fi> References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> <50275735.2070803@gulbrandsen.priv.no> <0484ACEB-2C5A-4168-83A3-A64D908D33E8@iki.fi> <503CC2DB.3050506@isode.com> To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.1084) Cc: Alexey Melnikov , imapext@ietf.org Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 18:18:40 -0000 On 29.8.2012, at 10.09, Arnt Gulbrandsen wrote: > I didn't have any diff when I left for my vacation, a far as I can = remember. Maybe I confused my two drafts? I think I was mainly thinking about the text for MOVE where source and = destination mailbox are the same, but I see there is already some text = in -01 for that: > Note that moving messages to the current mailbox is well-defined, = so > that MOVE is defined for all the cases where the COPY/STORE/EXPUNGE > sequence is. Although I don't think it's quite enough text for a reader to understand = what this sentence is really talking about. At the very least "current" = should be replaced with "selected" or maybe "selected mailbox itself". = Even after that I'm not sure if the reader will realize what should = happen in such situation.. From arnt@gulbrandsen.priv.no Wed Aug 29 14:28:38 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3377D11E80A5 for ; Wed, 29 Aug 2012 14:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpXGAkTJZQKb for ; Wed, 29 Aug 2012 14:28:37 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C9711E809C for ; Wed, 29 Aug 2012 14:28:37 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 60385F8CD97; Wed, 29 Aug 2012 21:28:36 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1346275715-13838-13837/11/2; Wed, 29 Aug 2012 21:28:35 +0000 Message-Id: <503E897C.4000905@gulbrandsen.priv.no> Date: Wed, 29 Aug 2012 23:28:28 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> <50275735.2070803@gulbrandsen.priv.no> <0484ACEB-2C5A-4168-83A3-A64D908D33E8@iki.fi> <503CC2DB.3050506@isode.com> <1135CF57-5C76-48EE-B7C1-ABFE75DD1021@iki.fi> In-Reply-To: <1135CF57-5C76-48EE-B7C1-ABFE75DD1021@iki.fi> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:28:38 -0000 That was one rotten paragraph. How about this? "Note that as a consequence of the definition above, moving a message to the currently selected mailbox is legal, and has the effect of assigning a new UID for the message and setting its \recent pseudo-flag." Arnt From tss@iki.fi Wed Aug 29 14:33:13 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235AC11E80EA for ; Wed, 29 Aug 2012 14:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.467 X-Spam-Level: X-Spam-Status: No, score=-110.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9BtWGGz5RuB for ; Wed, 29 Aug 2012 14:33:12 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6B22F11E80A5 for ; Wed, 29 Aug 2012 14:33:10 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 6DEFA1AE87C0; Thu, 30 Aug 2012 00:33:09 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <503E897C.4000905@gulbrandsen.priv.no> Date: Thu, 30 Aug 2012 00:33:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1803F8FB-D451-4388-BBDD-429FB341014C@iki.fi> References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> <50275735.2070803@gulbrandsen.priv.no> <0484ACEB-2C5A-4168-83A3-A64D908D33E8@iki.fi> <503CC2DB.3050506@isode.com> <1135CF57-5C76-48EE-B7C1-ABFE75DD1021@iki.fi> < 503E897C.4000905@gulbrandsen.priv.no> To: Arnt Gulbrandsen X-Mailer: Apple Mail (2.1084) Cc: imapext@ietf.org Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:33:13 -0000 On 30.8.2012, at 0.28, Arnt Gulbrandsen wrote: > That was one rotten paragraph. How about this? >=20 > "Note that as a consequence of the definition above, moving a message = to the currently selected mailbox is legal, and has the effect of = assigning a new UID for the message and setting its \recent = pseudo-flag." I like it. From arnt@gulbrandsen.priv.no Wed Aug 29 14:43:57 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921D811E80A5 for ; Wed, 29 Aug 2012 14:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQoCkwg34-kY for ; Wed, 29 Aug 2012 14:43:57 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C47B11E8099 for ; Wed, 29 Aug 2012 14:43:57 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 51746F8CD99; Wed, 29 Aug 2012 21:43:56 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1346276635-13838-13837/11/3; Wed, 29 Aug 2012 21:43:55 +0000 Message-Id: <503E8D13.9040707@gulbrandsen.priv.no> Date: Wed, 29 Aug 2012 23:43:47 +0200 From: Arnt Gulbrandsen User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 Mime-Version: 1.0 To: imapext@ietf.org References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> <50275735.2070803@gulbrandsen.priv.no> <0484ACEB-2C5A-4168-83A3-A64D908D33E8@iki.fi> <503CC2DB.3050506@isode.com> <1135CF57-5C76-48EE-B7C1-ABFE75DD1021@iki.fi> <503E897C.4000905@gulbrandsen.priv.no> <1803F8FB-D451-4388-BBDD-429FB341014C@iki.fi> In-Reply-To: <1803F8FB-D451-4388-BBDD-429FB341014C@iki.fi> Content-Type: text/plain; charset=iso-8859-1; format=flowed Subject: Re: [imapext] IMAP move X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 21:43:57 -0000 I replaced the upgefucked nonsense with that sentence. Will do the idnits chores and post when I come home, which should happen next week, but who knows which day. Arnt From alexey.melnikov@isode.com Thu Aug 30 14:17:42 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB8F11E808E for ; Thu, 30 Aug 2012 14:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.213 X-Spam-Level: X-Spam-Status: No, score=-101.213 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooI1Oz1o5QrE for ; Thu, 30 Aug 2012 14:17:41 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 3806D11E808D for ; Thu, 30 Aug 2012 14:17:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1346361460; d=isode.com; s=selector; i=@isode.com; bh=t6UKzBNFeaGZQ0kxvpe/olgTWqPfcGlqqfYTPqU87/g=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=mwMhY/N0p7+nfLJS3w+0gKOXfwL3nB4kx4Fv5ui35d8+Lu047y22ng9Oup1c+Iix9LSUPQ UKHYhXedalb5Sjz/x07haIVf9U4LcLm9fAP5eioJYVs92vYRMXWbfy4WZwF19P++8G4Oo1 tIfo8Y/GWe56fNnV6ALADGFojpWGhAk=; Received: from [188.29.13.37] (188.29.13.37.threembb.co.uk [188.29.13.37]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 30 Aug 2012 22:17:39 +0100 References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <01OIL5H6W3A20006TF@mauve.mrochek.com> <01OIMAUZGUFG0006TF@mauve.mrochek.com> <501C4D66.8090007@gulbrandsen.priv.no> <01OIME06I33Q0006TF@mauve.mrochek.com> <501CE866.7030701@gulbrandsen.priv.no> <501D23FB.5010408@gulbrandsen.priv.no> <0ab66e80-f9f9-4b4e-86e7-c2ef13ae068f@email.android.com> <501F7E39.2020203@gulbrandsen.priv.no> <50275735.2070803@gulbrandsen.priv.no> <0484ACEB-2C5A-4168-83A3-A64D908D33E8@iki.fi> <503CC2DB.3050506@isode.com> <1135CF57-5C76-48EE-B7C1-ABFE75DD1021@iki.fi> <503E897C.4000905@gulbrandsen.priv.no> In-Reply-To: <503E897C.4000905@gulbrandsen.priv.no> Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Thu, 30 Aug 2012 22:18:34 +0100 To: "imapext@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-59BC5FFC-CE75-4CF1-8C55-44EC14C5A4EF Content-Transfer-Encoding: 7bit Subject: [imapext] WG Last Call on draft-ietf-imapmove-command-01.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 21:17:42 -0000 --Apple-Mail-59BC5FFC-CE75-4CF1-8C55-44EC14C5A4EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On behalf of Ned and myself I would like to start 2 weeks WGLC (which will e= nd on September 14th) draft-ietf-imapmove-command-01.txt. Please send your comments to the mailing list or directly to Ned and myself.= Statement of support (e.g. "this document is well written and ready for pub= lication") or objections (with a reason) are also welcomed. Alexey, as a co-chair. --Apple-Mail-59BC5FFC-CE75-4CF1-8C55-44EC14C5A4EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On behalf of Ned and myself I w= ould like to start 2 weeks WGLC (which will end on September 14th) draft-ietf-imapmove-command-01.txt.

Please send your comments to the mailing list or directly to Ne= d and myself. Statement of support (e.g. "this document is well written and r= eady for publication") or objections (with a reason) are also welcomed.<= /span>

Alexey, as a co-chair.

= --Apple-Mail-59BC5FFC-CE75-4CF1-8C55-44EC14C5A4EF-- From dkarp@zimbra.com Thu Aug 30 14:50:41 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B0D21F853B for ; Thu, 30 Aug 2012 14:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i-O2cuc9c8r for ; Thu, 30 Aug 2012 14:50:41 -0700 (PDT) Received: from edge01-zcs.vmware.com (edge01-zcs.vmware.com [208.91.2.22]) by ietfa.amsl.com (Postfix) with ESMTP id 406AF21F8534 for ; Thu, 30 Aug 2012 14:50:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by edge01-zcs.vmware.com (Postfix) with ESMTP id 98794201B; Thu, 30 Aug 2012 14:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at edge01-zcs.vmware.com Received: from edge01-zcs.vmware.com ([127.0.0.1]) by localhost (edge01-zcs.vmware.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iO9AajcbxNzl; Thu, 30 Aug 2012 14:50:32 -0700 (PDT) Received: from mbs01-zcs.vmware.com (mbs01-zcs.vmware.com [10.113.162.14]) by edge01-zcs.vmware.com (Postfix) with ESMTP id A4AA21F6A; Thu, 30 Aug 2012 14:50:31 -0700 (PDT) Date: Thu, 30 Aug 2012 14:50:31 -0700 (PDT) From: Dan Karp To: Alexey Melnikov Message-ID: <1502465862.372309.1346363431158.JavaMail.root@zimbra.com> In-Reply-To: References: <01OIL1CMET3O0006TF@mauve.mrochek.com> <0484ACEB-2C5A-4168-83A3-A64D908D33E8@iki.fi> <503CC2DB.3050506@isode.com> <1135CF57-5C76-48EE-B7C1-ABFE75DD1021@iki.fi> <503E897C.4000905@gulbrandsen.priv.no> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.0_GA_5415 (ZimbraWebClient - GC21 (Mac)/8.0.0_GA_5415) Thread-Topic: WG Last Call on draft-ietf-imapmove-command-01.txt Thread-Index: HrZHDdfou8bBXePO4xJVwuSWckfjcQ== Cc: imapext@ietf.org Subject: Re: [imapext] WG Last Call on draft-ietf-imapmove-command-01.txt X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Aug 2012 21:50:42 -0000 > Please send your comments to the mailing list or directly to Ned and > myself. Statement of support (e.g. "this document is well written > and ready for publication") or objections (with a reason) are also > welcomed. The document defines UID MOVE in terms of three other commands (UID COPY, UID STORE, UID EXPUNGE). As for MOVE, it states The MOVE command performs the same actions UID MOVE. Besides the missing "as", I'm not sure if this is exactly clear. There's no sequence-set-parameterized EXPUNGE that corresponds to UID MOVE. I mean, I get what the document is saying, but do we need to specify non-UID MOVE a little more concretely? There are two section 4.3s. Both the first one (UIDPLUS) and the second one (QRESYNC) describes the extensions' interaction with this draft, but they reference only UID MOVE. Same with section 4.2 (ACL). We should clarify all of these to state that MOVE commands interact similarly. Also, the UIDPLUS section has a typo ("Servers authors"). The ABNF should probably be phrased similarly to that of RFC 3501. Thus, instead of command-select =/ ["UID "] "MOVE" SP set SP mailbox it should probably read command-select =/ move move = "MOVE" SP sequence-set SP mailbox uid = "UID" SP (copy / fetch / search / store / move) (Note that even if you don't make this change, "set" needs to be changed to "sequence-set". Also, use SP instead of including the space in the "UID " literal.) - Dan From jkt@flaska.net Fri Aug 31 08:09:55 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0901E21F85C0 for ; Fri, 31 Aug 2012 08:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.578 X-Spam-Level: X-Spam-Status: No, score=-0.578 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIX-SN+Uo7bT for ; Fri, 31 Aug 2012 08:09:52 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 04DF821F8559 for ; Fri, 31 Aug 2012 08:09:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4CALvSQFCT5xpZgWdsb2JhbABFhgS1FSIBARYmJ4JKDwEFQDYCBRYLAgsDAgECAVgIAQGICZpsjkCTFoEhigEBAoVTgRIDlViBFJFrgVcI X-IronPort-AV: E=Sophos;i="4.80,347,1344204000"; d="scan'208";a="302795" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 31 Aug 2012 17:09:48 +0200 Received: from svist.flaska.net (pc069c.fzu.cz [147.231.27.69]) by freja.fzu.cz (Postfix) with ESMTPSA id 5035A3DA82 for ; Fri, 31 Aug 2012 17:09:48 +0200 (CEST) Message-ID: <5040D39D.1000207@flaska.net> Date: Fri, 31 Aug 2012 17:09:17 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120128 Thunderbird/9.0 MIME-Version: 1.0 To: imapext@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 15:09:55 -0000 Hi Arnt et all, sorry for not responding before the WGLC. There's a problem with reusing the COPYUID in untagged responses. Consider the following example where a client uses pipelining for the UID MOVE command and moves two distinct sets of messages into two different mailboxes: C: a UID MOVE 42 foo C: b UID MOVE 66 bar S: * OK [COPYUID 123 42 123] S: * OK [COPYUID 456 66 10] S: * VANISHED 42,66 S: a OK completed S: b OK completed In this particular example, a client could probably keep track of the issued UID MOVE commands, map the "COPYUID ... 42" into mailbox "foo" and "COPYUID ... 66" into mailbox "bar". That would still require quite some amount of work. Please note that the same problem does not affect the COPY/UID COPY commands because the COPYUID is embedded in the tagged OK for these commands. And to prevent speculations -- yes, my client will happily issue pipelined UID MOVE when the user moves her mouse fast enough. When working over a slow network, one can imagine a case where there *could* be two such commands pipelined. My code can actually handle this situation reasonably well; the COPYUID is going to be processed by an object which remembers the UID of the messages being moved, so it's easy to see whether "this" COPYUID is for "this" UID MOVE or whether one should defer it to another one. However, reusing COPYUID in an untagged response leads to interesting effects when the set of UIDs of two pipelined commands overlaps and there are some failures. Please note that as a result of the UID MOVE being defined in terms of (UID COPY, UID STORE, UID EXPUNGE), it is actually OK to attempt to UID MOVE an overlapping set of messages in two pipelined commands. The result is timing and ACL-dependant, but the sequence itself is allowed. Consider the following: C: a UID MOVE 1:2 aaa C: b UID MOVE 2:3 bbb S: * OK [COPYUID 123 2 123] // for the "a" command moving into "aaa" S: * OK [COPYUID 456 2 123] // for the "b" command moving into "bbb" S: * VANISHED 1:3 S: a OK blah S: b OK blah In this (quite contrived, I admit) case, the commands failed to move any message with UID different from 2, but at the same time, messages with UIDs 1 and 3 are both expunged, maybe by a parallel session. The IMAP server for some reason decided to defer sending the EXPUNGE/VANISHED for these until the COPYUID got sent. The client code has no way to tell what happened, and a naive implementation might also try to invalidate its cached copy of mailbox aaa's state (or bbb's state, or both) by observing that the UDIVALIDITY of the target mailbox has changed. My opinion is that the draft should be changed to use a new response code (like MOVEUID) which would work like this: C: a UID MOVE 1:2 aaa C: b UID MOVE 2:3 bbb S: * OK [MOVEUID a 123 2 123] // for the "a" command moving into "aaa" S: * OK [MOVEUID a 456 2 123] // for the "b" command moving into "bbb" S: * VANISHED 1:3 S: a OK blah S: b OK blah If this gets changed, section 4.3 will need a rewrite. In addition, I have troubles understanding section 4.1: "This may be user-visible, but should not be MUA-visible.". I haven't read the QUOTA RFC carefuly, though, so I might be missing something. With kind regards, Jan -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From arnt@gulbrandsen.priv.no Fri Aug 31 12:14:56 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7529421F8574 for ; Fri, 31 Aug 2012 12:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAWwC0mVItIs for ; Fri, 31 Aug 2012 12:14:56 -0700 (PDT) Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB7321F856C for ; Fri, 31 Aug 2012 12:14:55 -0700 (PDT) Received: from fri.gulbrandsen.priv.no (unknown [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5C600F945D9; Fri, 31 Aug 2012 19:14:54 +0000 (UTC) Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.1.4) with esmtpsa id 1346440493-13838-13837/11/12; Fri, 31 Aug 2012 19:14:53 +0000 User-Agent: Kaiten Mail In-Reply-To: <5040D39D.1000207@flaska.net> References: <5040D39D.1000207@flaska.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Arnt Gulbrandsen Date: Fri, 31 Aug 2012 21:14:41 +0200 To: Jan =?ISO-8859-1?q?Kundr=E1t?= , imapext@ietf.org Message-Id: <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 19:14:56 -0000 Show me a case where this is a problem? As far as i can understand, if uid 2 I'd moved to aaa, it cannot = subsequently be moved to bbb, because it is not there to be referenced = anymore. This works even for concurrent commands, because the server = moves each message atomically, so one command has to be the first to = move each particular message. If you issue two moves for overlapping sets, you will get disjoint = copyuid responses. If the second command uses msns this could be a problem, I suppose. Arnt From dkarp@zimbra.com Fri Aug 31 12:21:45 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3157121F858A for ; Fri, 31 Aug 2012 12:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2spXZsx6XFs for ; Fri, 31 Aug 2012 12:21:44 -0700 (PDT) Received: from edge02-zcs.vmware.com (edge02-zcs.vmware.com [208.91.2.23]) by ietfa.amsl.com (Postfix) with ESMTP id A5B8F21F8577 for ; Fri, 31 Aug 2012 12:21:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by edge02-zcs.vmware.com (Postfix) with ESMTP id E4A3F1E53; Fri, 31 Aug 2012 12:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at edge02-zcs.vmware.com Received: from edge02-zcs.vmware.com ([127.0.0.1]) by localhost (edge02-zcs.vmware.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Xn-imZ7DLAox; Fri, 31 Aug 2012 12:21:31 -0700 (PDT) Received: from mbs01-zcs.vmware.com (mbs01-zcs.vmware.com [10.113.162.14]) by edge02-zcs.vmware.com (Postfix) with ESMTP id D112C1E93; Fri, 31 Aug 2012 12:21:18 -0700 (PDT) Date: Fri, 31 Aug 2012 12:21:18 -0700 (PDT) From: Dan Karp To: Arnt Gulbrandsen Message-ID: <195857373.541921.1346440878117.JavaMail.root@zimbra.com> In-Reply-To: <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailer: Zimbra 8.0.0_GA_5415 (ZimbraWebClient - GC21 (Mac)/8.0.0_GA_5415) Thread-Topic: Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE Thread-Index: 1AY7ydrzv96qq1VHc+0o/vr9duzSmQ== Cc: Jan =?utf-8?Q?Kundr=C3=A1t?= , imapext@ietf.org Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 19:21:45 -0000 > If the second command uses msns this could be a problem, I suppose. As far as I understand it, two overlapping MOVEs are not allowed by the ambiguity rules of RFC 3501 section 5.5 (Multiple Commands in Progress). - Dan From jkt@flaska.net Fri Aug 31 12:53:56 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921A721F8532 for ; Fri, 31 Aug 2012 12:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.958 X-Spam-Level: X-Spam-Status: No, score=-0.958 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3+azjIPGV4F for ; Fri, 31 Aug 2012 12:53:56 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id A212A21F8517 for ; Fri, 31 Aug 2012 12:53:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQCAD0VQVCT5xpZgWdsb2JhbABFhgS1GyIBARYmJ4IgAQEEASMVQAYLCxgCAgUTAwsCAgkDAgECAUUTCAEBG4doBgSnYJMHgSGKAoNLggqBEgOVWIEUkWuBXw X-IronPort-AV: E=Sophos;i="4.80,349,1344204000"; d="scan'208";a="304057" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 31 Aug 2012 21:53:53 +0200 Received: from svist.flaska.net (ip-89-176-26-68.net.upcbroadband.cz [89.176.26.68]) by freja.fzu.cz (Postfix) with ESMTPSA id 5CCF73DA82 for ; Fri, 31 Aug 2012 21:53:53 +0200 (CEST) Message-ID: <5041162F.5090704@flaska.net> Date: Fri, 31 Aug 2012 21:53:19 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120128 Thunderbird/9.0 MIME-Version: 1.0 To: imapext@ietf.org References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> In-Reply-To: <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 19:53:56 -0000 On 08/31/12 21:14, Arnt Gulbrandsen wrote: > Show me a case where this is a problem? > > As far as i can understand, if uid 2 I'd moved to aaa, it cannot > subsequently be moved to bbb, because it is not there to be > referenced anymore. The problem is that if two UID MOVE are started in parallel, there's no guarantee that the server will actually fully process the first one before the second one, and therefore clients have no idea which one has won. Consider the following: C: a UID MOVE 1 aaa C: b UID MOVE 1 bbb S: * OK [COPYUID 123 1 1] S: * VANISHED 1 S: a OK completed S: b OK completed Where's the message now, in aaa, or in bbb? > This works even for concurrent commands, because the server moves > each message atomically, so one command has to be the first to move > each particular message. My understanding of the draft's wording is that there's only a SHOULD on the atomicity -- i.e. it is allowed for servers to actually copy the message into both mailboxes before it gets expunged from the source one. This interpretation is somehow confirmed by the UID MOVE's definition which relies on UID COPY/UID STORE/UID EXPUNGE; there's nothing saying that this sequence should/must be atomic (and probably for a good reason). The draft also contains a section called Open Issues (which should both be addressed, IMHO) -- the atomicity explanation might confirm or reject my claim that a message can actually be copied into two mailboxes. With kind regards, Jan -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From ned.freed@mrochek.com Fri Aug 31 14:02:28 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAC621F855A for ; Fri, 31 Aug 2012 14:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0rmpdusErwq for ; Fri, 31 Aug 2012 14:02:27 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 74FD621F8523 for ; Fri, 31 Aug 2012 14:02:27 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJPE8ZR43400849X@mauve.mrochek.com> for imapext@ietf.org; Fri, 31 Aug 2012 13:57:26 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Fri, 31 Aug 2012 13:57:23 -0700 (PDT) Message-id: <01OJPE8YAE9M0006TF@mauve.mrochek.com> Date: Fri, 31 Aug 2012 13:52:39 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 31 Aug 2012 12:21:18 -0700 (PDT)" <195857373.541921.1346440878117.JavaMail.root@zimbra.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> To: Dan Karp Cc: Jan =?utf-8?Q?Kundr=C3=A1t?= , Arnt Gulbrandsen , imapext@ietf.org Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 21:02:28 -0000 > > If the second command uses msns this could be a problem, I suppose. > As far as I understand it, two overlapping MOVEs are not allowed by the > ambiguity rules of RFC 3501 section 5.5 (Multiple Commands in Progress). I agree. It's clear that streaming two moves of the same messge can produce ambiguous results, so by section 5.5 rules it is not allowed. That said, I think the draft needs to state this explicitly rather than relying on everyone's full and deep understanding of all the nuances of IMAP command semantics. I note in passing that section 5.5 does exactly this for some less than obvious ambiguous cases. Ned From tss@iki.fi Fri Aug 31 14:09:56 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F9C21F8567 for ; Fri, 31 Aug 2012 14:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.471 X-Spam-Level: X-Spam-Status: No, score=-110.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1LEW0MoyTKZ for ; Fri, 31 Aug 2012 14:09:55 -0700 (PDT) Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 04E3821F855B for ; Fri, 31 Aug 2012 14:09:53 -0700 (PDT) Received: from [192.168.10.101] (a88-112-255-76.elisa-laajakaista.fi [88.112.255.76]) by dovecot.org (Postfix) with ESMTP id 6E4D51AE87BF; Sat, 1 Sep 2012 00:09:51 +0300 (EEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Timo Sirainen In-Reply-To: <01OJPE8YAE9M0006TF@mauve.mrochek.com> Date: Sat, 1 Sep 2012 00:09:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <7C514DB2-4787-437B-9B37-8A863E079CC1@iki.fi> References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> To: Ned Freed X-Mailer: Apple Mail (2.1084) Cc: =?iso-8859-1?Q?Jan_Kundr=E1t?= , Arnt Gulbrandsen , imapext@ietf.org, Dan Karp Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 21:09:56 -0000 On 31.8.2012, at 23.52, Ned Freed wrote: >>> If the second command uses msns this could be a problem, I suppose. >=20 >> As far as I understand it, two overlapping MOVEs are not allowed by = the >> ambiguity rules of RFC 3501 section 5.5 (Multiple Commands in = Progress). >=20 > I agree. It's clear that streaming two moves of the same messge can = produce > ambiguous results, so by section 5.5 rules it is not allowed. >=20 > That said, I think the draft needs to state this explicitly rather = than relying > on everyone's full and deep understanding of all the nuances of IMAP = command > semantics. >=20 > I note in passing that section 5.5 does exactly this for some less > than obvious ambiguous cases. It's definitely not obvious that 5.5 applies in this case, and I = wouldn't really even agree that it does apply (for MOVE yes, for UID = MOVE I think not). But if it's explicitly mentioned I guess that's = fine.. The other possibility would be to do it similar to ESEARCH = replies and include the tag (as in Jan's suggestion, although it would = need to be done differently). From jkt@flaska.net Fri Aug 31 14:55:05 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9589021F847F for ; Fri, 31 Aug 2012 14:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.193 X-Spam-Level: X-Spam-Status: No, score=0.193 tagged_above=-999 required=5 tests=[AWL=-1.157, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MANGLED_TOOL=2.3, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xc02u+qY5fNk for ; Fri, 31 Aug 2012 14:55:05 -0700 (PDT) Received: from ipo2-out.fzu.cz (ipo2-out.fzu.cz [147.231.27.21]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE3221F8474 for ; Fri, 31 Aug 2012 14:55:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMCADsyQVCT5xpZgWdsb2JhbABFhgS1GyIBARYmJ4IgAQEFIw8BBUARCxgCAgUTAwsCAgkDAgECAUUTCAEBiAkEp2mSeIEhigEBg0uCCoESA5VYgRSRa4Ff X-IronPort-AV: E=Sophos;i="4.80,349,1344204000"; d="scan'208";a="304574" Received: from freja.fzu.cz ([147.231.26.89]) by ipo2-out.fzu.cz with ESMTP; 31 Aug 2012 23:55:02 +0200 Received: from svist.flaska.net (ip-89-176-26-68.net.upcbroadband.cz [89.176.26.68]) by freja.fzu.cz (Postfix) with ESMTPSA id 7D3DD3DA82 for ; Fri, 31 Aug 2012 23:55:02 +0200 (CEST) Message-ID: <50413296.7050808@flaska.net> Date: Fri, 31 Aug 2012 23:54:30 +0200 From: =?UTF-8?B?SmFuIEt1bmRyw6F0?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20120128 Thunderbird/9.0 MIME-Version: 1.0 To: imapext@ietf.org References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> In-Reply-To: <01OJPE8YAE9M0006TF@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 21:55:05 -0000 On 08/31/12 22:52, Ned Freed wrote: > I agree. It's clear that streaming two moves of the same messge can produce > ambiguous results, so by section 5.5 rules it is not allowed. You are right that one can interpret that section to mean roughly "if any future extension defines something which can be used in an ambiguous way, clients cannot use that". The problem is that this restriction has only been ever used to restrict commands using sequence numbers and not those which operate on and return just the UIDs, AFAIK. So you might be right, but it's a stretch of an old rule, in my opinion. I would find it surprising that this rule would ever apply to UID MOVE, and this observation is supported by UID MOVE's definition in terms of (UID COPY, UID STORE and UID EXPUNGE) which are fine with being pipelined in the manner I've shown in my earlier e-mails. If this definition holds, I believe that 5.5 cannot apply to UID MOVE. So let's decide whether we want to allow for pipelined UID MOVE at all. If that is going to be allowed, let's use this opportunity to make the extension as easy to implement -- for both servers and clients -- as possible. What's the cost of adding a MOVEUID referring either to the command tag or the target mailbox? In the current version of the draft, clients would have to do roughly the following if pipelined UID MOVE is allowed: def handle_untagged_COPYUID: for each UID_MOVE_command in active_commands: for each uid in COPYUID.source_UIDs: if uid in UID_MOVE_command.source_UIDs: # now we're sure that it is our command process_copyuid_here() # processes all UIDs in the COPYUID return # definitely not our command, do nothing It is doable, but it's very non-obvious that such a convoluted handling is in fact required to catch all the corner cases (like some messages failing to move). It is also an O(n^2) in the worst case compared to O(1) with a MOVEUID variant which refers to a mailbox/command. With kind regards, Jan -- Trojita, a fast e-mail client -- http://trojita.flaska.net/ From ned.freed@mrochek.com Fri Aug 31 23:11:29 2012 Return-Path: X-Original-To: imapext@ietfa.amsl.com Delivered-To: imapext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1652921F84A1 for ; Fri, 31 Aug 2012 23:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=-1.275, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, MANGLED_TOOL=2.3, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1VkVTaDjxFh for ; Fri, 31 Aug 2012 23:11:28 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 12EE021F84AF for ; Fri, 31 Aug 2012 23:11:28 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJPXEMDG0W0076Q4@mauve.mrochek.com> for imapext@ietf.org; Fri, 31 Aug 2012 23:06:22 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OJFFFOH4280006TF@mauve.mrochek.com>; Fri, 31 Aug 2012 23:06:21 -0700 (PDT) Message-id: <01OJPXELHPKK0006TF@mauve.mrochek.com> Date: Fri, 31 Aug 2012 19:24:35 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 31 Aug 2012 23:54:30 +0200" <50413296.7050808@flaska.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <5040D39D.1000207@flaska.net> <703929f4-254d-45d6-8ea5-793b27290235@email.android.com> <195857373.541921.1346440878117.JavaMail.root@zimbra.com> <01OJPE8YAE9M0006TF@mauve.mrochek.com> <50413296.7050808@flaska.net> To: =?UTF-8?B?SmFuIEt1bmRyw6F0?= Cc: imapext@ietf.org Subject: Re: [imapext] Problem with reusing untagged COPYUID in pipelined UID MOVE or MOVE X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Sep 2012 06:11:29 -0000 > On 08/31/12 22:52, Ned Freed wrote: > > I agree. It's clear that streaming two moves of the same messge can produce > > ambiguous results, so by section 5.5 rules it is not allowed. > You are right that one can interpret that section to mean roughly "if > any future extension defines something which can be used in an ambiguous > way, clients cannot use that". The problem is that this restriction has > only been ever used to restrict commands using sequence numbers and not > those which operate on and return just the UIDs, AFAIK. First, there's nothing in the section that excludes UID commmands from its restriction. Such an interpretation might make sense if UID commands were introduced in a different document, but that's rather obviously not the case. Second, the reason such considerations may not apply to UID commands is because those commands have different semantics that eliminate such concerns. > So you might be > right, but it's a stretch of an old rule, in my opinion. Absent a much more compelling argument than has been given so far I reject the notion that this is any sort of stretch. That would be true even if there isn't a single case where this restriction has applied to a UID-based command. But in a way this is all moot. Even if this section didn't exist we can apply whatever restrictions we want to MOVE. The fact that this section exists is only an indication that there is ample precedent in IMAP for having such restrictions. > I would find it > surprising that this rule would ever apply to UID MOVE, and this > observation is supported by UID MOVE's definition in terms of (UID COPY, > UID STORE and UID EXPUNGE) which are fine with being pipelined in the > manner I've shown in my earlier e-mails. If this definition holds, I > believe that 5.5 cannot apply to UID MOVE. Doesn't follow. If the semantics and capabilities of a COPY/STORE/EXPUNGE sequence were identical to MOVE, there would be no need for MOVE. But the semantics rather obviously aren't the same. > So let's decide whether we want to allow for pipelined UID MOVE at all. Then the first question that needs to be asked is whether or not pipelining overlapping moves is a capability with a either a significant use-case of its own or is something that comes up willy-nilly and is also difficult for clients to avoid. Once that is asssed the costs of addressing the issue can be weighed against the benefits that will accrue in the client space. And no, I don't care if there is concern that it might come up sometime or somewhere. The IMAP extensions space has quite a few examples of extensions that were made overly complex precisely because of this sort of vague concern. That's why this work was chartered as a narrowly focused effort. > If that is going to be allowed, let's use this opportunity to make the > extension as easy to implement -- for both servers and clients -- as > possible. > What's the cost of adding a MOVEUID referring either to the command tag > or the target mailbox? Benefits first. Then costs. > In the current version of the draft, clients would have to do roughly > the following if pipelined UID MOVE is allowed: > def handle_untagged_COPYUID: > for each UID_MOVE_command in active_commands: > for each uid in COPYUID.source_UIDs: > if uid in UID_MOVE_command.source_UIDs: > # now we're sure that it is our command > process_copyuid_here() # processes all UIDs in the COPYUID > return > # definitely not our command, do nothing > It is doable, but it's very non-obvious that such a convoluted handling > is in fact required to catch all the corner cases (like some messages > failing to move). It is also an O(n^2) in the worst case compared to > O(1) with a MOVEUID variant which refers to a mailbox/command. All this assumes that a client would actually want to do it. Ned