From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 6I8eBUpjm2BxrwAAgWs5BA (envelope-from ) for ; Wed, 12 May 2021 07:10:34 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id IP3IAEpjm2A+IQAA1q6Kng (envelope-from ) for ; Wed, 12 May 2021 05:10:34 +0000 Received: from mail.notmuchmail.org (nmbug.tethera.net [IPv6:2607:5300:201:3100::1657]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 4AFD721B3D for ; Wed, 12 May 2021 07:10:33 +0200 (CEST) Received: from nmbug.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id 3AFAB27180; Wed, 12 May 2021 01:10:24 -0400 (EDT) Received: from mariecurie.labrat.space (mariecurie.labrat.space [116.203.185.229]) by mail.notmuchmail.org (Postfix) with ESMTPS id 844D72717A for ; Wed, 12 May 2021 01:10:20 -0400 (EDT) Received: from labrat.space (adsl-178-38-36-59.adslplus.ch [178.38.36.59]) by mariecurie.labrat.space (Postfix) with ESMTPSA id A7AD61F335D8; Wed, 12 May 2021 07:09:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=labrat.space; s=201904; t=1620796146; bh=q9C5W5ybu01dVm9L+iBtHfNijzhCMGUX3lkOTkyL5Ac=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To:From:To:CC:Date: Subject:Content-Type:Content-Disposition:Reply-To:In-Reply-To: MIME-Version:Message-ID:References; b=kjr5wTZLruGttOprOM7gOObZ5BaBvTgzn4Pz8KtPj7vSSEQM1wKU0/Ah6LCAKF137 I0q5jVNo1f2ybHMid6NqsBuN/oP9leA9/mxrxM9Hp5Jb6+YTIWO4WhZx4rodTva87U 9mn7twe8dlMgmXh6A5qZ8cQBkffVsEUcqC6bPwvpOLCYE4aT6oNecZjJ+EuCS/tmyq q231s3T47/lqFqw/9MbP0LvCeqWbdH6guqgWMLqlet8gZmpsKRYA6PSXqc1RTQ+A+B 2H4CRg909nheR7HbRfH5enCvTioZyOnvh/ePD3QJB9lmtQN9lbAF1vzTGfqiRhEMUr L4bLQ0QgQvWaA== Date: Wed, 12 May 2021 07:10:13 +0200 From: Reto To: Michael J Gruber Subject: Re: Is there a reason why the trashed flag is not synced? Message-ID: <20210512051013.bfrqx236n36bvqt6@feather> Mail-Followup-To: Michael J Gruber , David Bremner , Felipe Contreras , notmuch@notmuchmail.org References: <60971dc77decb_22cb620817@natae.notmuch> <87bl9kjlgo.fsf@tethera.net> <8735uukd6c.fsf@tethera.net> <162065351282.5824.14225420932746058853.git@grubix.eu> <20210511062321.7rp3g64qfopaxedj@feather> <162071572578.3234.2579434453077254635.git@grubix.eu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <162071572578.3234.2579434453077254635.git@grubix.eu> Message-ID-Hash: WNP7FJIROFNQXLPR7E5QNJWKMWPRBR7K X-Message-ID-Hash: WNP7FJIROFNQXLPR7E5QNJWKMWPRBR7K X-MailFrom: reto@labrat.space X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header CC: notmuch@notmuchmail.org X-Mailman-Version: 3.2.1 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1620796233; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=c+2tuYzjzUkCIzbZ5wUdIt9f8/WmR2GnPoGTstLXc4A=; b=F1Pt8baARyo3Ott9LlbHVcXmaKUU6ixVZJTdR2pV1IzKINa/Hy/fcmVbEv+Xib84W14iMf 5D2xm1TZZRcdogvMlTwhOZAbp5u55tsI+ZAoty4NMcaSlHEEUmtFNSkc9opJVmHh7k+7GL KNLEGLCqC5cz6FxgDj8+1dTDHl7RScIAnqKzm4jMUudeRM1Fo6vUTr9DqOG4B2dAeaQusQ 18xl0Uo8Uhili6s55fOC1juP2/+7a3KVR3XS1zuweHmuEtHacO3h8A6l44Z44quBlQ9gm+ U4bRQfN2WlFthPKtdV5AVdjmOGog8X20zQBsPAFYIc8WCzPn9h4aS259Huc9Iw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1620796233; a=rsa-sha256; cv=none; b=Hfk1xVGiLg/Uqg4W5ev8H5A25ZKQ5FC6peR6O+cfaFslS7EzAagszvaqDyBjLHt6iUAQI2 JOrR5ONY+oIqVUmxyp2TUgixinSuqf9BKw9cwc4l+LSY2mQhHJU6YPDCwYgFfwzIHhlvot uWb3clmnkrSM0liDpjaF0L32FKNl/QSxdTVoNiZK9cOldVoZL04Yun/4RhoP+QsKL+d6r/ DzERBxFZiEojUjz20B41N0W0KvGBLU2QcDzQw/8bnkreu8azRmyJsYs5b0Kp7lkDSMDByW FkrAyi0dYlYRJPJS+7j6lSQVRqFC5Erv/jB+hrhwFOwYpTZRQZ/T4DhXR+kfQw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=labrat.space header.s=201904 header.b=kjr5wTZL; dmarc=fail reason="SPF not aligned (strict)" header.from=labrat.space (policy=none); spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 2607:5300:201:3100::1657 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Spam-Score: 0.56 Authentication-Results: aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=labrat.space header.s=201904 header.b=kjr5wTZL; dmarc=fail reason="SPF not aligned (strict)" header.from=labrat.space (policy=none); spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 2607:5300:201:3100::1657 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: 4AFD721B3D X-Spam-Score: 0.56 X-Migadu-Scanner: scn0.migadu.com X-TUID: tj2XWVCdDuFy On Tue, May 11, 2021 at 08:48:45AM +0200, Michael J Gruber wrote: > If you sync gmail labels to exact copies in different folders then you're not > holding it right, sorry ;) > Gmail is not an IMAP service; it has an IMAP API which exposes labels as > folders, with all the caveats which this implies. That's why there are > better ways to sync Gmail with a notmuch mail store (gmailieer). Better is always a relative term. I prefer a standardized protocol over some homebrew stuff. > I don't think notmuch should break its design principle (1 message id, 1 > message) just to work around a problem caused by a wrong sync procedure: > that "delete instruction" is a result (merely: artifact) of speaking IMAP to Gmail. It's not only gmail, really any IMAP server. If you have a message in multiple folders at the same time (which is entirely reasonable, think "todo" + where it actually should go after processing). They all have the same message ID. Only because you delete the copy from todo doesn't mean that you want it gone from other places as well. Sure, you could move instead of copying... But that means that you may now need to hunt through multiple folders instead of being able to grab the message from the actual mbox it should be in. IMAP doesn't impose a workflow, just because yours happens to be a certain way doesn't make it the gold standard ;) Cheers, Reto