From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/83306 Path: news.gmane.org!not-for-mail From: Leonidas Tsampros Newsgroups: gmane.emacs.gnus.general Subject: Re: [PATCH] gmail and X-GM-EXT1 extensions Date: Mon, 10 Jun 2013 08:46:26 +0300 Message-ID: <87obbewma5.fsf@kepler.lan> References: <874nf1k0je.fsf@kepler.lan> <87ip3ffpqs.fsf@kepler.lan> <87wqq7tgvy.fsf@lifelogs.com> <87zjuzw1xe.fsf@kepler.lan> Reply-To: ltsampros@upnet.gr NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1370843258 18602 80.91.229.3 (10 Jun 2013 05:47:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Jun 2013 05:47:38 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M31572@lists.math.uh.edu Mon Jun 10 07:47:38 2013 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ulux7-0004py-K5 for ding-account@gmane.org; Mon, 10 Jun 2013 07:47:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1Uluw9-0000I1-3p; Mon, 10 Jun 2013 00:46:37 -0500 Original-Received: from mx2.math.uh.edu ([129.7.128.33]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Uluw1-0000Hl-9h for ding@lists.math.uh.edu; Mon, 10 Jun 2013 00:46:29 -0500 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx2.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Uluvz-0005UW-69 for ding@lists.math.uh.edu; Mon, 10 Jun 2013 00:46:28 -0500 Original-Received: from mail-ee0-f48.google.com ([74.125.83.48]) by quimby.gnus.org with esmtp (Exim 4.72) (envelope-from ) id 1Uluvx-0004gu-Ft for ding@gnus.org; Mon, 10 Jun 2013 07:46:25 +0200 Original-Received: by mail-ee0-f48.google.com with SMTP id b47so2038305eek.7 for ; Sun, 09 Jun 2013 22:46:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=b10F13gQ9dvfdJ3SHu8XO23Krbob3TgIwbd/sQd3y+c=; b=RYQXhk/7SJALVEhkSZ8R9ZM+djMMHdbO6ouMPW14NQq3iZcv+RCHe1Jgm3skrgUDK6 axiIQbzgjJLcz0sDxnLq7nxFeH9/Hy3cS76Peym3TBvhVUGvYjBd/Xh3+xdTEdIHigKF Z2+wYINIRpZrSI416N3HU5tnfFrHgrfC1bFv6+kWi4sUQYkdFWsI+peS5HoUb8M4jQ/r f9R1qqAlbJ9rhV7kGXdksk/12floOSm6nveWZ391P4izdKGWQUJjo37h19p0R1M7NrNt iw82Zpqa6FDodhA9Hy7UjbWv6mNsTfsobCVTsrh/6F5KBQY+P2or+V3apNaas6Z6f+th OFPw== X-Received: by 10.14.203.194 with SMTP id f42mr9287644eeo.53.1370843179991; Sun, 09 Jun 2013 22:46:19 -0700 (PDT) Original-Received: from kepler.lan (178.128.11.7.dsl.dyn.forthnet.gr. [178.128.11.7]) by mx.google.com with ESMTPSA id y44sm20504050eel.10.2013.06.09.22.46.17 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 09 Jun 2013 22:46:18 -0700 (PDT) In-Reply-To: (Ted Zlatanov's message of "Sun, 09 Jun 2013 23:30:47 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-Spam-Score: -2.9 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:83306 Archived-At: Ted Zlatanov writes: > On Sun, 09 Jun 2013 21:53:49 +0300 Leonidas Tsampros wrote: > > LT> Ted Zlatanov writes: >>> On Mon, 22 Apr 2013 02:06:19 +0300 Leonidas Tsampros wrote: >>> > LT> That was easier than I thought. Please take a look at the patch attached > LT> and send me your comments. >>> >>> Looks OK to me. Can the behavior be made optional? > > LT> Yes, I have added a per server nnimap switch nnimap-x-gm-ext-1 with the > LT> default value set to nil. For example a gmail server configuration would > LT> look like this: > > (setq gnus-secondary-select-methods '((nnimap "gmail" > (nnimap-address "imap.gmail.com") > (nnimap-server-port 993) > (nnimap-stream ssl) > (nnimap-x-gm-ext-1 t)))) > > LT> So, nnmail-split-incoming-mail behaviour is togglable by the > LT> nnimap-x-gm-ext1 switch. However, I don't have a setup with multiple > LT> imap servers to test it. > > OK. It feels like a pretty special one-off so maybe it could be > > (nnimap-ext x-gm-ext-1) > > instead, to accomodate other weird future extensions and to avoid > special defvoos? Ok. Sounds rational. > LT> Do we need point 4 (INTERNALDATE of APPENDed messages) to be an optional > LT> behaviour as well? > > Erm.... yes? :) Can you fit it into the nnimap-ext style I suggested? I'll do that, but technically it's not an extension. According to RFC3501 (2.3.3 and 6.3.11) INTERNALDATE is optional during APPEND. My interpretation is that is legal to set INTERNALDATE using the value of the 'date' header and we could do it because: a) there is no other way to manipulate the INTERNALDATE of a message. b) servers MUST use the current date/time if INTERNALDATE is not defined during APPEND. Thunderbird got this fixed in 2006 https://bugzilla.mozilla.org/show_bug.cgi?id=332626#c31 and they had a discussion here as well: http://forums.mozillazine.org/viewtopic.php?p=2757812#2757812 Is there really a use case were we don't want the INTERNALDATE to be set during APPEND?