Gnus development mailing list
 help / color / mirror / Atom feed
From: Leonidas Tsampros <ltsampros@upnet.gr>
To: ding@gnus.org
Subject: Re: [PATCH] gmail and X-GM-EXT1 extensions
Date: Mon, 10 Jun 2013 08:46:26 +0300	[thread overview]
Message-ID: <87obbewma5.fsf@kepler.lan> (raw)
In-Reply-To: <m28v2ifxqw.fsf@lifelogs.com> (Ted Zlatanov's message of "Sun, 09 Jun 2013 23:30:47 -0400")

Ted Zlatanov <tzz@lifelogs.com> writes:
> On Sun, 09 Jun 2013 21:53:49 +0300 Leonidas Tsampros <ltsampros@upnet.gr> wrote: 
>
> LT> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> On Mon, 22 Apr 2013 02:06:19 +0300 Leonidas Tsampros <ltsampros@upnet.gr> 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?



  reply	other threads:[~2013-06-10  5:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-20  9:35 Leonidas Tsampros
2013-04-21 23:06 ` [PATCH] " Leonidas Tsampros
2013-06-06 15:09   ` Ted Zlatanov
2013-06-09 18:53     ` Leonidas Tsampros
2013-06-10  3:30       ` Ted Zlatanov
2013-06-10  5:46         ` Leonidas Tsampros [this message]
2013-06-10  6:28           ` Ted Zlatanov
2013-07-18  4:11             ` Leonidas Tsampros
2013-08-01 15:27               ` Lars Magne Ingebrigtsen
2013-08-01 16:22                 ` Leonidas Tsampros
2013-08-01 16:35                   ` Lars Magne Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87obbewma5.fsf@kepler.lan \
    --to=ltsampros@upnet.gr \
    --cc=ding@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).