From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id 4K6XBuQommBVVAEAgWs5BA (envelope-from ) for ; Tue, 11 May 2021 08:49:08 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id OKY4AuQommAJaAAAbx9fmQ (envelope-from ) for ; Tue, 11 May 2021 06:49:08 +0000 Received: from mail.notmuchmail.org (nmbug.tethera.net [144.217.243.247]) (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 CA4251CAF4 for ; Tue, 11 May 2021 08:49:07 +0200 (CEST) Received: from nmbug.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id 09F962717A; Tue, 11 May 2021 02:49:04 -0400 (EDT) Received: from mailproxy03.manitu.net (mailproxy03.manitu.net [217.11.48.67]) by mail.notmuchmail.org (Postfix) with ESMTPS id D51C420017 for ; Tue, 11 May 2021 02:49:01 -0400 (EDT) Received: from localhost (200116b86017d900ae2f9e0a625a9927.dip.versatel-1u1.de [IPv6:2001:16b8:6017:d900:ae2f:9e0a:625a:9927]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: michael@grubix.eu) by mailproxy03.manitu.net (Postfix) with ESMTPSA id ECCC0D4219E; Tue, 11 May 2021 08:48:46 +0200 (CEST) MIME-Version: 1.0 In-Reply-To: <20210511062321.7rp3g64qfopaxedj@feather> References: <60971dc77decb_22cb620817@natae.notmuch> <87bl9kjlgo.fsf@tethera.net> <8735uukd6c.fsf@tethera.net> <162065351282.5824.14225420932746058853.git@grubix.eu> <20210511062321.7rp3g64qfopaxedj@feather> Subject: Re: Is there a reason why the trashed flag is not synced? From: Michael J Gruber To: Reto Message-ID: <162071572578.3234.2579434453077254635.git@grubix.eu> Date: Tue, 11 May 2021 08:48:45 +0200 User-Agent: alot/0.9.1 Message-ID-Hash: U3N2PM7DX7KVTXRXMTHVVH6M3C4G4ATY X-Message-ID-Hash: U3N2PM7DX7KVTXRXMTHVVH6M3C4G4ATY X-MailFrom: michael@grubix.eu 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=1620715747; 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; bh=Dj6JorALZKIM7CIVBwD/AcxKIMIm9ICn7UA4APNxLOg=; b=hAMBTUGAWXao5AHDmVfxv+ILK2IT2QEDrI5BxnmQBdJFhDJhd4DrMdgSTpQmvS+geHSaPG J3cEMxTI8GlDVc3FAwHFOsPW/+kkrobDdTBkc2e37KABljG2vxv1I5DkATTY+ARlwBt0e9 0ga50QMIz7gh0agP2IqQyE4UNUyHrApzUvBMQOUbfVRMm9wfL20NtbOn8joX+p1qaNQcpB dm6b5HekejEr5owGmsHqkaY58sRHFyJYa9myEA5BO5CEQKMZ6haDBOoxEPCeAtcsimJCDa 6nv7YI3kX0/uQx0eNMTTkevIdWKF/Fcl95SrbumtDmtPFTDBjQbwwfGRIca0jw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1620715747; a=rsa-sha256; cv=none; b=uNdSb4pQhreYvIdOxFcBn9suCNY1AaLOOcH55Enrir1/vR58X9tctLtOb3H1M8q5613Kat m0KQaXBeeAXYzAxMJidMXS/0RINiYfVKqgQz3DVmW8nWsmPHfZGGhZnu1pBa9uhbKLQajw 73FwO0fmr9DEwINxS6YWKk0r3P/2jK0gsEoeVk1w2zkobTzvK6HoYdWbM00o7TwGTk5v4U 2d/VUV+UnfrKAvl+pN3BxIxDZQ3hPqnGbCuwY7n73p3QeC/oprPbRFIZxLwddwR9Sm7bHA UI7msaOdIBpYcozeBTIAg9e+TqDuUiFIJVpNZYaVWA4PBVsxcDcL7kGKJElTag== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 144.217.243.247 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Spam-Score: 1.43 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 144.217.243.247 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: CA4251CAF4 X-Spam-Score: 1.43 X-Migadu-Scanner: scn0.migadu.com X-TUID: PHc4fOnjb6OU Reto venit, vidit, dixit 2021-05-11 08:23:21: > On Mon, May 10, 2021 at 03:31:52PM +0200, Michael J Gruber wrote: > > Deleting by chance is more harmful, yes. But is it more typical to clear > > out duplicate files using "T" or to delete a message (i.e. all it's file > > copies)? > > You have to be a bit careful here... imap is a relatively strange protocol. > Consider a provider like gmail that uses a label system over normal imap folders. > If you assign a message "inbox" and "vacation" and maybe "archive" and then want > to remove the message from inbox and vacation folders you execute delete instructions. > That however, certainly shouldn't propagate to the "archive" copy. > > So I'd argue that in fact no, what you mention is not the "typical" thing to do. > At least not with those providers. > Not all MUAs behave the same in regards to whether or not they set the trash flag > first. > Yes, you can tell neomutt to do almost anything, but if setting the Trash flag > on one message starts deleting all other copies I'd be very much surprised. If you sync gmail labels to exact copies in different folders then you're not holding it right, sorry ;) Gmail does not "execute a delete instruction" when it removes a label from a message, and if you sync 1 e-mail to several copies with the same message id then they are in fact not copies but identical from the point of view of any programme that identifies messages by message id - such as notmuch. 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). 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. Michael