Browse Source

add imap-protocol list archives folder

tags/v2
Manos Pitsidianakis 11 months ago
parent
commit
6331317b58
Signed by: epilys GPG Key ID: 73627C2F690DF710
  1. 39
      demo/ermis-f/imap-protocol/cur/1600094967.22507.mbox:2,S
  2. 24
      demo/ermis-f/imap-protocol/cur/1600094968.22507.mbox:2,S
  3. 28
      demo/ermis-f/imap-protocol/cur/1600094968.22511.mbox:2,S
  4. 30
      demo/ermis-f/imap-protocol/cur/1600094969.22507.mbox:2,S
  5. 53
      demo/ermis-f/imap-protocol/cur/1600094969.22514.mbox:2,S
  6. 33
      demo/ermis-f/imap-protocol/cur/1600094970.22507.mbox:2,S
  7. 87
      demo/ermis-f/imap-protocol/cur/1600094970.22514.mbox:2,S
  8. 55
      demo/ermis-f/imap-protocol/cur/1600094970.22518.mbox:2,S
  9. 36
      demo/ermis-f/imap-protocol/cur/1600094971.22507.mbox:2,S
  10. 90
      demo/ermis-f/imap-protocol/cur/1600094971.22514.mbox:2,S
  11. 84
      demo/ermis-f/imap-protocol/cur/1600094971.22518.mbox:2,S
  12. 17
      demo/ermis-f/imap-protocol/cur/1600094971.22523.mbox:2,S
  13. 95
      demo/ermis-f/imap-protocol/cur/1600094972.22507.mbox:2,S
  14. 94
      demo/ermis-f/imap-protocol/cur/1600094972.22518.mbox:2,S
  15. 32
      demo/ermis-f/imap-protocol/cur/1600094972.22523.mbox:2,S
  16. 42
      demo/ermis-f/imap-protocol/cur/1600094972.22526.mbox:2,S
  17. 41
      demo/ermis-f/imap-protocol/cur/1600094973.22507.mbox:2,S
  18. 38
      demo/ermis-f/imap-protocol/cur/1600094973.22518.mbox:2,S
  19. 33
      demo/ermis-f/imap-protocol/cur/1600094973.22526.mbox:2,S
  20. 25
      demo/ermis-f/imap-protocol/cur/1600094973.22529.mbox:2,S
  21. 50
      demo/ermis-f/imap-protocol/cur/1600094974.22507.mbox:2,S
  22. 81
      demo/ermis-f/imap-protocol/cur/1600094974.22518.mbox:2,S
  23. 52
      demo/ermis-f/imap-protocol/cur/1600094975.22507.mbox:2,S
  24. 16
      demo/ermis-f/imap-protocol/cur/1600094975.22518.mbox:2,S
  25. 31
      demo/ermis-f/imap-protocol/cur/1600094975.22532.mbox:2,S
  26. 72
      demo/ermis-f/imap-protocol/cur/1600094976.22507.mbox:2,S
  27. 40
      demo/ermis-f/imap-protocol/cur/1600094976.22518.mbox:2,S
  28. 46
      demo/ermis-f/imap-protocol/cur/1600094976.22532.mbox:2,S
  29. 44
      demo/ermis-f/imap-protocol/cur/1600094976.22535.mbox:2,S
  30. 18
      demo/ermis-f/imap-protocol/cur/1600094977.22532.mbox:2,S
  31. 13
      demo/ermis-f/imap-protocol/cur/1600094977.22535.mbox:2,S
  32. 49
      demo/ermis-f/imap-protocol/cur/1600094977.22538.mbox:2,S
  33. 13
      demo/ermis-f/imap-protocol/cur/1600094978.22532.mbox:2,S
  34. 31
      demo/ermis-f/imap-protocol/cur/1600094978.22535.mbox:2,S
  35. 37
      demo/ermis-f/imap-protocol/cur/1600094978.22538.mbox:2,S
  36. 65
      demo/ermis-f/imap-protocol/cur/1600094978.22541.mbox:2,S
  37. 38
      demo/ermis-f/imap-protocol/cur/1600094979.22535.mbox:2,S
  38. 50
      demo/ermis-f/imap-protocol/cur/1600094979.22538.mbox:2,S
  39. 16
      demo/ermis-f/imap-protocol/cur/1600094979.22541.mbox:2,S
  40. 14
      demo/ermis-f/imap-protocol/cur/1600094979.22544.mbox:2,S
  41. 52
      demo/ermis-f/imap-protocol/cur/1600094980.22538.mbox:2,S
  42. 25
      demo/ermis-f/imap-protocol/cur/1600094980.22544.mbox:2,S
  43. 52
      demo/ermis-f/imap-protocol/cur/1600094981.22538.mbox:2,S
  44. 48
      demo/ermis-f/imap-protocol/cur/1600094981.22544.mbox:2,S
  45. 27
      demo/ermis-f/imap-protocol/cur/1600094981.22548.mbox:2,S
  46. 34
      demo/ermis-f/imap-protocol/cur/1600094982.22538.mbox:2,S
  47. 46
      demo/ermis-f/imap-protocol/cur/1600094982.22548.mbox:2,S
  48. 17
      demo/ermis-f/imap-protocol/cur/1600094982.22553.mbox:2,S
  49. 87
      demo/ermis-f/imap-protocol/cur/1600094983.22538.mbox:2,S
  50. 45
      demo/ermis-f/imap-protocol/cur/1600094983.22548.mbox:2,S
  51. 37
      demo/ermis-f/imap-protocol/cur/1600094983.22553.mbox:2,S
  52. 37
      demo/ermis-f/imap-protocol/cur/1600094983.22563.mbox:2,S
  53. 38
      demo/ermis-f/imap-protocol/cur/1600094984.22538.mbox:2,S
  54. 64
      demo/ermis-f/imap-protocol/cur/1600094984.22548.mbox:2,S
  55. 57
      demo/ermis-f/imap-protocol/cur/1600094984.22553.mbox:2,S
  56. 71
      demo/ermis-f/imap-protocol/cur/1600094984.22563.mbox:2,S
  57. 70
      demo/ermis-f/imap-protocol/cur/1600094984.22566.mbox:2,S
  58. 74
      demo/ermis-f/imap-protocol/cur/1600094985.22538.mbox:2,S
  59. 64
      demo/ermis-f/imap-protocol/cur/1600094985.22548.mbox:2,S
  60. 67
      demo/ermis-f/imap-protocol/cur/1600094985.22553.mbox:2,S
  61. 31
      demo/ermis-f/imap-protocol/cur/1600094985.22563.mbox:2,S
  62. 51
      demo/ermis-f/imap-protocol/cur/1600094985.22566.mbox:2,S
  63. 33
      demo/ermis-f/imap-protocol/cur/1600094985.22569.mbox:2,S
  64. 67
      demo/ermis-f/imap-protocol/cur/1600094986.22538.mbox:2,S
  65. 24
      demo/ermis-f/imap-protocol/cur/1600094986.22548.mbox:2,S
  66. 114
      demo/ermis-f/imap-protocol/cur/1600094986.22553.mbox:2,S
  67. 39
      demo/ermis-f/imap-protocol/cur/1600094986.22566.mbox:2,S
  68. 34
      demo/ermis-f/imap-protocol/cur/1600094986.22569.mbox:2,S
  69. 42
      demo/ermis-f/imap-protocol/cur/1600094986.22572.mbox:2,S
  70. 111
      demo/ermis-f/imap-protocol/cur/1600094987.22538.mbox:2,S
  71. 24
      demo/ermis-f/imap-protocol/cur/1600094987.22548.mbox:2,S
  72. 21
      demo/ermis-f/imap-protocol/cur/1600094987.22553.mbox:2,S
  73. 34
      demo/ermis-f/imap-protocol/cur/1600094987.22566.mbox:2,S
  74. 38
      demo/ermis-f/imap-protocol/cur/1600094987.22569.mbox:2,S
  75. 56
      demo/ermis-f/imap-protocol/cur/1600094987.22572.mbox:2,S
  76. 152
      demo/ermis-f/imap-protocol/cur/1600094988.22538.mbox:2,S
  77. 44
      demo/ermis-f/imap-protocol/cur/1600094988.22548.mbox:2,S
  78. 47
      demo/ermis-f/imap-protocol/cur/1600094988.22553.mbox:2,S
  79. 27
      demo/ermis-f/imap-protocol/cur/1600094988.22569.mbox:2,S
  80. 75
      demo/ermis-f/imap-protocol/cur/1600094988.22572.mbox:2,S
  81. 65
      demo/ermis-f/imap-protocol/cur/1600094988.22575.mbox:2,S
  82. 89
      demo/ermis-f/imap-protocol/cur/1600094989.22538.mbox:2,S
  83. 30
      demo/ermis-f/imap-protocol/cur/1600094989.22548.mbox:2,S
  84. 46
      demo/ermis-f/imap-protocol/cur/1600094989.22553.mbox:2,S
  85. 46
      demo/ermis-f/imap-protocol/cur/1600094989.22569.mbox:2,S
  86. 59
      demo/ermis-f/imap-protocol/cur/1600094989.22572.mbox:2,S
  87. 48
      demo/ermis-f/imap-protocol/cur/1600094989.22575.mbox:2,S
  88. 35
      demo/ermis-f/imap-protocol/cur/1600094989.22578.mbox:2,S
  89. 100
      demo/ermis-f/imap-protocol/cur/1600094990.22538.mbox:2,S
  90. 56
      demo/ermis-f/imap-protocol/cur/1600094990.22548.mbox:2,S
  91. 29
      demo/ermis-f/imap-protocol/cur/1600094990.22553.mbox:2,S
  92. 58
      demo/ermis-f/imap-protocol/cur/1600094990.22572.mbox:2,S
  93. 61
      demo/ermis-f/imap-protocol/cur/1600094990.22575.mbox:2,S
  94. 51
      demo/ermis-f/imap-protocol/cur/1600094990.22583.mbox:2,S
  95. 33
      demo/ermis-f/imap-protocol/cur/1600094991.22538.mbox:2,S
  96. 16
      demo/ermis-f/imap-protocol/cur/1600094991.22548.mbox:2,S
  97. 61
      demo/ermis-f/imap-protocol/cur/1600094991.22553.mbox:2,S
  98. 99
      demo/ermis-f/imap-protocol/cur/1600094991.22572.mbox:2,S
  99. 28
      demo/ermis-f/imap-protocol/cur/1600094991.22575.mbox:2,S
  100. 36
      demo/ermis-f/imap-protocol/cur/1600094991.22583.mbox:2,S

39
demo/ermis-f/imap-protocol/cur/1600094967.22507.mbox:2,S

@ -0,0 +1,39 @@
MBOX-Line: From andris.reinman at gmail.com Wed Sep 9 00:27:14 2020
To: imap-protocol@u.washington.edu
From: Andris Reinman <andris.reinman@gmail.com>
Date: Wed Sep 9 00:27:54 2020
Subject: [Imap-protocol] Any valid use case for COPY besides moving messages?
Message-ID: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
Hi,
As the subject states, is there actually any valid use case these days for
COPY to just copy messages instead of being a poor substitute for MOVE
(that is COPY+EXPUNGE)?
If an IMAP server would mark COPYied messages with \Delete and
expunge these immediately after a message has been copied, would it break
any real-use expectations?
Why I'm asking is that I'm building a database backed email server (
https://wildduck.email), we have a moderately sized cluster of emails
(100k+ users, ~50TB+ of data, few hundred million emails) and when an IMAP
client tries to copy all messages from one large folder to another then
copying takes a lot of time (eg 'COPY 1:* target' where * is 10 000) as
listing the database entries and copying these around takes time. And as
there is no response until messages have been fully copied the client might
think that TCP connection has been lost and retries the same action, ending
up doing multiple COPY calls.
So I was wondering if we could simply delete the already copied message
from the source folder, as most probably the client would do it anyway once
COPY is fully completed. Basically COPY would be an alias for MOVE.
Obviously non-standard behavior but would we actually break something
client side by doing this?
Regards,
Andris Reinman
https://wildduck.email
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20200909/7621c931/attachment.html>

24
demo/ermis-f/imap-protocol/cur/1600094968.22507.mbox:2,S

@ -0,0 +1,24 @@
MBOX-Line: From grschmidt at acm.org Wed Sep 9 01:49:43 2020
To: imap-protocol@u.washington.edu
From: "Gary R. Schmidt" <grschmidt@acm.org>
Date: Wed Sep 9 01:50:13 2020
Subject: [Imap-protocol] Any valid use case for COPY besides moving
messages?
In-Reply-To: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
References: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
Message-ID: <cf5ca346-0ff8-831d-7dc4-4027803f6e82@acm.org>
On 09/09/2020 17:27, Andris Reinman wrote:
> Hi,
>
> As the subject states, is there actually any valid use case these days
> for COPY to just copy messages instead of being a poor substitute for
> MOVE (that is COPY+EXPUNGE)?
>
I often copy bunches of email to other folders, to other users accounts,
and to various archive accounts, after which the messages are *not*
deleted, so I would say, "Yes, there are valid use cases for COPY doing
*exactly* what the word says."
Cheers,
Gary B-)

28
demo/ermis-f/imap-protocol/cur/1600094968.22511.mbox:2,S

@ -0,0 +1,28 @@
MBOX-Line: From gds at chartertn.net Fri Sep 13 00:21:21 2019
To: imap-protocol@u.washington.edu
From: Gene Smith <gds@chartertn.net>
Date: Fri Sep 13 00:21:43 2019
Subject: [Imap-protocol] Errors on imap APPEND with gmail server.
Message-ID: <296d9a9a-a6d3-d50a-ebf4-07550c1c2e6d@chartertn.net>
Often Thunderbird users have the need to copy many message from local
storage to an imap folder and have reported problems. Thunderbird uses a
separate imap append command for each message to accomplish this. But
occasionally, for example when the destination server is gmail, a BAD
response will occur to the append, e.g., 6249 BAD Invalid Arguments:
Unable to parse message.
However, if the exact same append command is repeated, it succeeds.
I have checked to verify that exactly the same data and data length is
sent when the append fails and when it succeeds. I verified this by
saving the command transactions with wireshark.
I've seen this occur at random points in the copy, such as after
approximately 4000 messages, about 400 messages etc, but so far, on the
retry the append succeeds.
Not sure if the problem is specific to gmail. But since it is very
commonly used, I have tested with it first.
Gene

30
demo/ermis-f/imap-protocol/cur/1600094969.22507.mbox:2,S

@ -0,0 +1,30 @@
MBOX-Line: From dpc22 at cam.ac.uk Wed Sep 9 02:30:35 2020
To: imap-protocol@u.washington.edu
From: David Carter <dpc22@cam.ac.uk>
Date: Wed Sep 9 02:31:09 2020
Subject: [Imap-protocol] Any valid use case for COPY besides moving
messages?
In-Reply-To: <cf5ca346-0ff8-831d-7dc4-4027803f6e82@acm.org>
References: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
<cf5ca346-0ff8-831d-7dc4-4027803f6e82@acm.org>
Message-ID: <5109ccf6cec7384b014f594e29e6d3f9@cam.ac.uk>
On 2020-09-09 09:49, Gary R. Schmidt wrote:
> On 09/09/2020 17:27, Andris Reinman wrote:
>> Hi,
>>
>> As the subject states, is there actually any valid use case these days
>> for COPY to just copy messages instead of being a poor substitute for
>> MOVE (that is COPY+EXPUNGE)?
>>
> I often copy bunches of email to other folders, to other users
> accounts, and to various archive accounts, after which the messages
> are *not* deleted, so I would say, "Yes, there are valid use cases for
> COPY doing *exactly* what the word says."
I frequently COPY mail which has been filtered into a folder on delivery
back to my inbox if there is something odd that I need to investigate
and/or action.
Roundcube has "drag and drop" for MOVE, and Shift+"drag and drop" for
COPY, which is quite convenient of it.

53
demo/ermis-f/imap-protocol/cur/1600094969.22514.mbox:2,S

@ -0,0 +1,53 @@
MBOX-Line: From brong at fastmail.fm Mon Apr 1 18:07:05 2019
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Mon Apr 1 18:07:17 2019
Subject: [Imap-protocol] CLIENTID capability for IMAP (and SMTP)
In-Reply-To: <CABa8R6ufcJ9GimEoLrFkKnMCh14n5+VK3uN-++f4tE-qfPW-7g@mail.gmail.com>
References: <8cade395-864a-9039-6bfa-874c26e5967e@chartertn.net>
<CABa8R6ufcJ9GimEoLrFkKnMCh14n5+VK3uN-++f4tE-qfPW-7g@mail.gmail.com>
Message-ID: <fd8e452a-a4e9-4123-aa54-e026735269d6@www.fastmail.com>
For what it's worth, this work was brought to the EXTRA working group at IETF at Montreal last year, and the group decided that it wasn't the right level in the stack for this kind of ID - that it would be better placed in the SASL layer.
The OAUTH technique also strikes me as a better long-term solution, because it means that users aren't entering their own selected password to be stored on disk by clients.
On the flip side, I'm sensitive to the argument from Linux Magic that this solves a problem RIGHT NOW which a perfect future solution might solve better, but a future solution doesn't fix anything for the current environment.
Regarding the discussion on bugzilla - I would agree that it's quite important that the same ID MUST NOT be sent to different servers - the CLIENTID should be generated as a unique hash over ('deviceid', 'username', 'domain').
Bron.
On Mon, Apr 1, 2019, at 03:51, Brandon Long wrote:
> Although I don't work on the Gmail imap anymore, I will say that we implemented a competing idea (AUTH LOGIN-CLIENTTOKEN), though we eventually decided to concentrate on OAUTHBEARER. OAUTH authorizes each client separately, so provides the same client based benefits.
>
> If this became standard, we could implement it, but I haven't really seen consensus on it yet, or adoption by a working group. When it matures, we would need to look at how many 'legacy' auth users we have , and the benefits to that population.
>
> Brandon
>
> On Sat, Mar 30, 2019, 11:11 AM Gene Smith <gds@chartertn.net> wrote:
>> Thunderbird has recently received a patch to add a CLIENTID capability
>> which can be seen here:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1532388.
>>
>> This includes links to the draft RFCs for IMAP and SMTP. I have been
>> unable to find any other information on this feature. Is it supported or
>> plaanned to be supported on any other IMAP or SMTP server?
>>
>> -gene
>> _______________________________________________
>> Imap-protocol mailing list
>> Imap-protocol@u.washington.edu
>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
--
Bron Gondwana
brong@fastmail.fm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20190401/843d2247/attachment.html>

33
demo/ermis-f/imap-protocol/cur/1600094970.22507.mbox:2,S

@ -0,0 +1,33 @@
MBOX-Line: From ptao at apple.com Wed Sep 9 12:01:51 2020
To: imap-protocol@u.washington.edu
From: Phillip Tao <ptao@apple.com>
Date: Wed Sep 9 12:02:13 2020
Subject: [Imap-protocol] Any valid use case for COPY besides moving
messages?
In-Reply-To: <cf5ca346-0ff8-831d-7dc4-4027803f6e82@acm.org>
References: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
<cf5ca346-0ff8-831d-7dc4-4027803f6e82@acm.org>
Message-ID: <9E1B3336-9D01-4B3C-A86E-6532A4EB8190@apple.com>
> On Sep 9, 2020, at 1:49 AM, Gary R. Schmidt <grschmidt@acm.org> wrote:
>
> On 09/09/2020 17:27, Andris Reinman wrote:
>> Hi,
>> As the subject states, is there actually any valid use case these days for COPY to just copy messages instead of being a poor substitute for MOVE (that is COPY+EXPUNGE)?
> I often copy bunches of email to other folders, to other users accounts, and to various archive accounts, after which the messages are *not* deleted, so I would say, "Yes, there are valid use cases for COPY doing *exactly* what the word says."
For the latter two examples, a copy to another account would almost certainly be an APPEND, and not actually a COPY.
But, I can't imagine that you wouldn't break someone's workflow almost immediately if you implemented this "COPY as alias for MOVE" behavior.
- Phillip
>
> Cheers,
> Gary B-)
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol

87
demo/ermis-f/imap-protocol/cur/1600094970.22514.mbox:2,S

@ -0,0 +1,87 @@
MBOX-Line: From dave at cridland.net Tue Apr 2 08:35:00 2019
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Tue Apr 2 08:35:44 2019
Subject: [Imap-protocol] CLIENTID capability for IMAP (and SMTP)
In-Reply-To: <fd8e452a-a4e9-4123-aa54-e026735269d6@www.fastmail.com>
References: <8cade395-864a-9039-6bfa-874c26e5967e@chartertn.net>
<CABa8R6ufcJ9GimEoLrFkKnMCh14n5+VK3uN-++f4tE-qfPW-7g@mail.gmail.com>
<fd8e452a-a4e9-4123-aa54-e026735269d6@www.fastmail.com>
Message-ID: <CAKHUCzyjLH2NmaLY=XyRAiuVTce7+D8Rfmh3pqN4O-UQmBrO6w@mail.gmail.com>
See also: https://tools.ietf.org/html/draft-cridland-kitten-clientkey-00
I implemented this in XMPP for various reasons, but there's no particular
reason it couldn't be used for IMAP et al.
On Tue, 2 Apr 2019 at 02:08, Bron Gondwana <brong@fastmail.fm> wrote:
> For what it's worth, this work was brought to the EXTRA working group at
> IETF at Montreal last year, and the group decided that it wasn't the right
> level in the stack for this kind of ID - that it would be better placed in
> the SASL layer.
>
> The OAUTH technique also strikes me as a better long-term solution,
> because it means that users aren't entering their own selected password to
> be stored on disk by clients.
>
> On the flip side, I'm sensitive to the argument from Linux Magic that this
> solves a problem RIGHT NOW which a perfect future solution might solve
> better, but a future solution doesn't fix anything for the current
> environment.
>
> Regarding the discussion on bugzilla - I would agree that it's quite
> important that the same ID MUST NOT be sent to different servers - the
> CLIENTID should be generated as a unique hash over ('deviceid', 'username',
> 'domain').
>
> Bron.
>
> On Mon, Apr 1, 2019, at 03:51, Brandon Long wrote:
>
> Although I don't work on the Gmail imap anymore, I will say that we
> implemented a competing idea (AUTH LOGIN-CLIENTTOKEN), though we eventually
> decided to concentrate on OAUTHBEARER. OAUTH authorizes each client
> separately, so provides the same client based benefits.
>
> If this became standard, we could implement it, but I haven't really seen
> consensus on it yet, or adoption by a working group. When it matures, we
> would need to look at how many 'legacy' auth users we have , and the
> benefits to that population.
>
> Brandon
>
> On Sat, Mar 30, 2019, 11:11 AM Gene Smith <gds@chartertn.net> wrote:
>
> Thunderbird has recently received a patch to add a CLIENTID capability
> which can be seen here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1532388.
>
> This includes links to the draft RFCs for IMAP and SMTP. I have been
> unable to find any other information on this feature. Is it supported or
> plaanned to be supported on any other IMAP or SMTP server?
>
> -gene
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
>
> --
> Bron Gondwana
> brong@fastmail.fm
>
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20190402/10ab392f/attachment.html>

55
demo/ermis-f/imap-protocol/cur/1600094970.22518.mbox:2,S

@ -0,0 +1,55 @@
MBOX-Line: From gds at chartertn.net Mon Mar 4 18:13:09 2019
To: imap-protocol@u.washington.edu
From: Gene Smith <gds@chartertn.net>
Date: Mon Mar 4 18:13:26 2019
Subject: [Imap-protocol] gmail fails "tag uid fetch 123 (BODY.PEEK[2.1.1])",
most others OK
Message-ID: <ebb06b9a-bd6b-7f7a-8a74-a0c8aa1591d1@chartertn.net>
I have been trying to fix Thunderbird so it properly accesses a large
mailing list digest message when fetching parts only on demand (no
inline display of attachments or local storage to disk of the entire
mesage).
The message can be found here:
https://bugzilla.mozilla.org/attachment.cgi?id=10149
I have it working OK for several servers (Dovecot, MDaemon, Cyrus) but
am unable to get to work with gmail.
The bodystructure numbering of the message parts is like this:
1 Top level message.
2 Container for the 107 rfc822 message attachments
2.1 The 1st message
2.1.1 Body of 1st message
2.2.The 2nd message
2.2.1 Body of 2nd message
:
:
2.66 The 66th message having attachments (example)
2.66.1 Body of 66th message
2.66.2 Attachment of 66th message (text)
2.66.3 2nd attachment
2.66.4 3rd (last) attachment of 66th message
:
:
2.107 The 107th (last) message
2.107.1 Body of 107th message
Thunderbird accesses the body of an attachment like this (uid 123):
tag uid fetch 123 (BODY.PEEK[2.33.1])
Several servers respond OK and return the email body of the 33th
attachment. But gmail responds like this:
48 NO Some messages could not be FETCHed (Failure)
-gene

36
demo/ermis-f/imap-protocol/cur/1600094971.22507.mbox:2,S

@ -0,0 +1,36 @@
MBOX-Line: From burrows.labs at gmail.com Wed Sep 9 12:45:26 2020
To: imap-protocol@u.washington.edu
From: Aaron Burrow <burrows.labs@gmail.com>
Date: Wed Sep 9 12:45:56 2020
Subject: [Imap-protocol] Any valid use case for COPY besides moving
messages?
In-Reply-To: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
References: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
Message-ID: <49C6D280-1110-4545-B7DE-303C98F98A71@gmail.com>
What does the db data model look like? Is the email data in the database, are there pointers?
> On Sep 9, 2020, at 3:28 AM, Andris Reinman <andris.reinman@gmail.com> wrote:
>
> ?
> Hi,
>
> As the subject states, is there actually any valid use case these days for COPY to just copy messages instead of being a poor substitute for MOVE (that is COPY+EXPUNGE)?
>
> If an IMAP server would mark COPYied messages with \Delete and expunge these immediately after a message has been copied, would it break any real-use expectations?
>
> Why I'm asking is that I'm building a database backed email server (https://wildduck.email), we have a moderately sized cluster of emails (100k+ users, ~50TB+ of data, few hundred million emails) and when an IMAP client tries to copy all messages from one large folder to another then copying takes a lot of time (eg 'COPY 1:* target' where * is 10 000) as listing the database entries and copying these around takes time. And as there is no response until messages have been fully copied the client might think that TCP connection has been lost and retries the same action, ending up doing multiple COPY calls.
>
> So I was wondering if we could simply delete the already copied message from the source folder, as most probably the client would do it anyway once COPY is fully completed. Basically COPY would be an alias for MOVE. Obviously non-standard behavior but would we actually break something client side by doing this?
>
> Regards,
> Andris Reinman
> https://wildduck.email
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20200909/03a5adbf/attachment.html>

90
demo/ermis-f/imap-protocol/cur/1600094971.22514.mbox:2,S

@ -0,0 +1,90 @@
MBOX-Line: From michael at linuxmagic.com Fri Apr 5 14:36:49 2019
To: imap-protocol@u.washington.edu
From: Michael Peddemors <michael@linuxmagic.com>
Date: Fri Apr 5 14:37:17 2019
Subject: [Imap-protocol] CLIENTID capability for IMAP (and SMTP)
Message-ID: <1a8a4997-1edc-6567-7cc3-1f2450b0e49d@linuxmagic.com>
From Bron's email..
"For what it's worth, this work was brought to the EXTRA working group
at IETF at Montreal last year, and the group decided that it wasn't the
right level in the stack for this kind of ID - that it would be better
placed in the SASL layer."
For the record, and correct me if I am wrong, the only "consensus" there
was that since it was for both SMTP and IMAP, it wasn't really in the
mandate of the working group.. albeit now there is discussion about the
'extra' including some SMTP items.
It was also suggested that more discussions should happen, and a 'home'
(eg working group) to take this on might be found ..
There WERE some comments that SASL might be preferred, to which we
responding that CLIENTID is 'not' authentication, but identification, so
belongs at a higher level, albeit it can be made available to any and
all SASL implementations by the SMTP/IMAP implementation, as well as to
any other identification or ACL systems that are not part of the
authentication layer..
Also, feedback was provided that the term CLIENTID (rather than the
original moniker of simply CID) was preferred which was incorporated
into the DRAFT, as well as the suggestion that client implementations
should take into the consideration whether CLIENTID should be presented
on a per client, or per service.
But Bron thank you for the following..
"On the flip side, I'm sensitive to the argument from Linux Magic that
this solves a problem RIGHT NOW which a perfect future solution might
solve better, but a future solution doesn't fix anything for the current
environment."
Thanks, because that is exactly the reason for it's inception, and why
others are open to adopting it now. We are trying to 'change' SMTP/IMAP,
simply make it easier to prevent the kind of abuse that is increasing
worldwide right now..
IT IS easier than many other ideas, easier to understand, adopt, and
implement, and is 100% backwards compatible until all email clients
support this, and it sure stops brute force attacks, and/or leaked
password from 3rd party data breaches. And allows the little players to
be able to implement what until now was really only available to the big
boys.
There is a fundamental problem today, for which this (CLIENTID) is "a"
solution, and our team has been working hard with partners, open source
projects, and other commercial vendors to expand on the adoption of this
worldwide.
And it is something that has proven already very successfully in our
implementations. Looking forward to more email clients and more servers
supporting CLIENTID, to widen the available number of email clients that
can be used when customers want to better secure their in-boxes.
"Lock Your Mailbox" ;)
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

84
demo/ermis-f/imap-protocol/cur/1600094971.22518.mbox:2,S

@ -0,0 +1,84 @@
MBOX-Line: From blong at google.com Tue Mar 5 09:14:56 2019
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Tue Mar 5 09:15:57 2019
Subject: [Imap-protocol] gmail fails "tag uid fetch 123
(BODY.PEEK[2.1.1])", most others OK
In-Reply-To: <ebb06b9a-bd6b-7f7a-8a74-a0c8aa1591d1@chartertn.net>
References: <ebb06b9a-bd6b-7f7a-8a74-a0c8aa1591d1@chartertn.net>
Message-ID: <CABa8R6uNSk1QYME2-StLDUusPLo3oSCzyOEpaubx9LuUKm9gaQ@mail.gmail.com>
Ugh, that is probably evil to our server. I don't recall if we succeeded
in optimizing the specific attachment requests, hopefully, otherwise we'd
have to reassemble the whole message, fetching all 100 plus parts and then
getting you what you want... With a little caching it would have to do this
on every fetch. That's still the fallback when the individual item fetch
fails for some reason (message our system didn't handle right or we have
bad offsets at least)
How big is the message that caching it on your end is bad?
Anyways, I've forwarded to the new team. Obviously it should work even if
it's a lot of work on our side. Is it a consistent one that doesn't work,
or any of them?
Brandon
On Mon, Mar 4, 2019, 6:14 PM Gene Smith <gds@chartertn.net> wrote:
> I have been trying to fix Thunderbird so it properly accesses a large
> mailing list digest message when fetching parts only on demand (no
> inline display of attachments or local storage to disk of the entire
> mesage).
>
> The message can be found here:
> https://bugzilla.mozilla.org/attachment.cgi?id=10149
>
> I have it working OK for several servers (Dovecot, MDaemon, Cyrus) but
> am unable to get to work with gmail.
>
> The bodystructure numbering of the message parts is like this:
>
> 1 Top level message.
> 2 Container for the 107 rfc822 message attachments
> 2.1 The 1st message
> 2.1.1 Body of 1st message
> 2.2.The 2nd message
> 2.2.1 Body of 2nd message
> :
> :
> 2.66 The 66th message having attachments (example)
> 2.66.1 Body of 66th message
> 2.66.2 Attachment of 66th message (text)
> 2.66.3 2nd attachment
> 2.66.4 3rd (last) attachment of 66th message
> :
> :
> 2.107 The 107th (last) message
> 2.107.1 Body of 107th message
>
> Thunderbird accesses the body of an attachment like this (uid 123):
>
> tag uid fetch 123 (BODY.PEEK[2.33.1])
>
> Several servers respond OK and return the email body of the 33th
> attachment. But gmail responds like this:
>
> 48 NO Some messages could not be FETCHed (Failure)
>
> -gene
>
>
>
>
>
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20190305/a36e7ce6/attachment.html>

17
demo/ermis-f/imap-protocol/cur/1600094971.22523.mbox:2,S

@ -0,0 +1,17 @@
MBOX-Line: From jjmckay at comaxis.com Mon Feb 18 15:03:55 2019
To: imap-protocol@u.washington.edu
From: Jeff McKay <jjmckay@comaxis.com>
Date: Mon Feb 18 15:04:16 2019
Subject: [Imap-protocol] Gmail IMAP server session timeout
Message-ID: <87f58114-8169-d911-2e2b-e1679c598941@comaxis.com>
I've got an application that puts messages into Gmail via IMAP.
Sometimes the application will have to sit there for a considerable
time, while logged in, waiting for processing to catch up on the source
end.? I am seeing Gmail shutdown, giving me "BYE session expired, please
login again".? I tried to prevent this by issuing NOOP commands every 5
minutes.? The server accepts the NOOP but that doesn't seem to reset its
timer.? Is that expected behavior?? Is there something else I need to do
to prevent the session from timing out?

95
demo/ermis-f/imap-protocol/cur/1600094972.22507.mbox:2,S

@ -0,0 +1,95 @@
MBOX-Line: From andris.reinman at gmail.com Wed Sep 9 13:39:28 2020
To: imap-protocol@u.washington.edu
From: Andris Reinman <andris.reinman@gmail.com>
Date: Wed Sep 9 13:39:52 2020
Subject: [Imap-protocol] Any valid use case for COPY besides moving
messages?
In-Reply-To: <49C6D280-1110-4545-B7DE-303C98F98A71@gmail.com>
References: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
<49C6D280-1110-4545-B7DE-303C98F98A71@gmail.com>
Message-ID: <CAPacwgz-aLLPmM_5ubesXRrqjsCvkMtYLvmMV7nM2yAs_yWJcA@mail.gmail.com>
> What does the db data model look like? Is the email data in the database,
> are there pointers?
>
It is a sharded MongoDB cluster. Messages are parsed into structured
documents, attachments are decoded and deduplicated and stored separately.
All email documents are stored in the same large collection (currently at
250M documents) and include a "mailbox id" value that is used to filter out
messages that belong to the same IMAP mailbox.
Around 30M FETCH commands are run every day against that collection so it
is quite busy as well.
Doing a copy for messages means
1. getting a cursor for the result set of matching messages
2. processing the cursor one message at a time
3. reading the entire message entry from DB to application (without
attachments as these are stored separately)
4. modifying the "folder id" and UID, MODSEQ etc values of the record in
memory
5. inserting the record to the collection as a new document
Copying each message also triggers notifications about added messages to
IMAP clients, modseq updates for the mailbox etc.
So obviously this is not very fast and may take a lot of time (in computer
terms).
I wanted to use a different approach at first where there would be just a
single email document and that document would contain a list of mailbox ids
where it is currently stored (and also what are the UID/MODSEQ values in
these mailboxes). I was not able to figure out proper database indexing for
that so went with the more simplistic approach where every email document
is dedicated to a specific mailbox.
Regards,
Andris Reinman
Kontakt Aaron Burrow (<burrows.labs@gmail.com>) kirjutas kuup?eval K, 9.
september 2020 kell 22:45:
>
> On Sep 9, 2020, at 3:28 AM, Andris Reinman <andris.reinman@gmail.com>
> wrote:
>
> ?
> Hi,
>
> As the subject states, is there actually any valid use case these days for
> COPY to just copy messages instead of being a poor substitute for MOVE
> (that is COPY+EXPUNGE)?
>
> If an IMAP server would mark COPYied messages with \Delete and
> expunge these immediately after a message has been copied, would it break
> any real-use expectations?
>
> Why I'm asking is that I'm building a database backed email server (
> https://wildduck.email), we have a moderately sized cluster of emails
> (100k+ users, ~50TB+ of data, few hundred million emails) and when an IMAP
> client tries to copy all messages from one large folder to another then
> copying takes a lot of time (eg 'COPY 1:* target' where * is 10 000) as
> listing the database entries and copying these around takes time. And as
> there is no response until messages have been fully copied the client might
> think that TCP connection has been lost and retries the same action, ending
> up doing multiple COPY calls.
>
> So I was wondering if we could simply delete the already copied message
> from the source folder, as most probably the client would do it anyway once
> COPY is fully completed. Basically COPY would be an alias for MOVE.
> Obviously non-standard behavior but would we actually break something
> client side by doing this?
>
> Regards,
> Andris Reinman
> https://wildduck.email
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20200909/342aafb5/attachment.html>

94
demo/ermis-f/imap-protocol/cur/1600094972.22518.mbox:2,S

@ -0,0 +1,94 @@
MBOX-Line: From blong at google.com Tue Mar 5 10:55:33 2019
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Tue Mar 5 10:56:03 2019
Subject: [Imap-protocol] gmail fails "tag uid fetch 123
(BODY.PEEK[2.1.1])", most others OK
In-Reply-To: <CABa8R6uNSk1QYME2-StLDUusPLo3oSCzyOEpaubx9LuUKm9gaQ@mail.gmail.com>
References: <ebb06b9a-bd6b-7f7a-8a74-a0c8aa1591d1@chartertn.net>
<CABa8R6uNSk1QYME2-StLDUusPLo3oSCzyOEpaubx9LuUKm9gaQ@mail.gmail.com>
Message-ID: <CABa8R6t79-k0uwNL=j1+5FZxh8sgcmh5XUSmTaMkKnkHztMdhg@mail.gmail.com>
Also interesting if it can fetch the full message, since that again might
require a lot of individual fetches to reassemble, which might time out if
we don't handle that correctly.
Brandon
On Tue, Mar 5, 2019 at 9:14 AM Brandon Long <blong@google.com> wrote:
> Ugh, that is probably evil to our server. I don't recall if we succeeded
> in optimizing the specific attachment requests, hopefully, otherwise we'd
> have to reassemble the whole message, fetching all 100 plus parts and then
> getting you what you want... With a little caching it would have to do this
> on every fetch. That's still the fallback when the individual item fetch
> fails for some reason (message our system didn't handle right or we have
> bad offsets at least)
>
> How big is the message that caching it on your end is bad?
>
> Anyways, I've forwarded to the new team. Obviously it should work even if
> it's a lot of work on our side. Is it a consistent one that doesn't work,
> or any of them?
>
> Brandon
>
>
> On Mon, Mar 4, 2019, 6:14 PM Gene Smith <gds@chartertn.net> wrote:
>
>> I have been trying to fix Thunderbird so it properly accesses a large
>> mailing list digest message when fetching parts only on demand (no
>> inline display of attachments or local storage to disk of the entire
>> mesage).
>>
>> The message can be found here:
>> https://bugzilla.mozilla.org/attachment.cgi?id=10149
>>
>> I have it working OK for several servers (Dovecot, MDaemon, Cyrus) but
>> am unable to get to work with gmail.
>>
>> The bodystructure numbering of the message parts is like this:
>>
>> 1 Top level message.
>> 2 Container for the 107 rfc822 message attachments
>> 2.1 The 1st message
>> 2.1.1 Body of 1st message
>> 2.2.The 2nd message
>> 2.2.1 Body of 2nd message
>> :
>> :
>> 2.66 The 66th message having attachments (example)
>> 2.66.1 Body of 66th message
>> 2.66.2 Attachment of 66th message (text)
>> 2.66.3 2nd attachment
>> 2.66.4 3rd (last) attachment of 66th message
>> :
>> :
>> 2.107 The 107th (last) message
>> 2.107.1 Body of 107th message
>>
>> Thunderbird accesses the body of an attachment like this (uid 123):
>>
>> tag uid fetch 123 (BODY.PEEK[2.33.1])
>>
>> Several servers respond OK and return the email body of the 33th
>> attachment. But gmail responds like this:
>>
>> 48 NO Some messages could not be FETCHed (Failure)
>>
>> -gene
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Imap-protocol mailing list
>> Imap-protocol@u.washington.edu
>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20190305/3bfc6963/attachment.html>

32
demo/ermis-f/imap-protocol/cur/1600094972.22523.mbox:2,S

@ -0,0 +1,32 @@
MBOX-Line: From blong at google.com Tue Feb 19 12:00:59 2019
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Tue Feb 19 12:01:49 2019
Subject: [Imap-protocol] Gmail IMAP server session timeout
In-Reply-To: <87f58114-8169-d911-2e2b-e1679c598941@comaxis.com>
References: <87f58114-8169-d911-2e2b-e1679c598941@comaxis.com>
Message-ID: <CABa8R6uMZFFs_x0chivVUsj0ZFD4DqR7cLCZzoL11V=8AwH9YA@mail.gmail.com>
What time frame are you seeing this in?
There's a bunch of different reasons that the server will close a
connection. There's a maximum number of connections allowed, for example,
or if the user's primary/secondary servers flip, or if you're connected to
a secondary because the primary was down and the primary comes back, or the
primary moves for load balancing, or the servers are restarted for new
versions. The connection also travels through at least three proxies, and
those can restart as well (though those won't say BYE). That's all
relatively rare but can cause connection closes on average daily.
If you're seeing consistent closes after an hour or 24h, that's probably
the auth refresh threshold. I don't recall the specific time frames, and
it varies between using oauth and regular login, but basically the auth
time has a limit because we can't easily tell in some circumstances if the
auth has been revoked, so we close the connection to force a re-login to
prove you still should have access. It's been a couple years, so I don't
recall the details.
Brandon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20190219/41ef75cc/attachment.html>

42
demo/ermis-f/imap-protocol/cur/1600094972.22526.mbox:2,S

@ -0,0 +1,42 @@
MBOX-Line: From gds at chartertn.net Thu Nov 29 11:34:19 2018
To: imap-protocol@u.washington.edu
From: Gene Smith <gds@chartertn.net>
Date: Thu Nov 29 11:34:45 2018
Subject: [Imap-protocol] Unsolicited server responses
In-Reply-To: <CADExsvHONmhx4uj1bkZXJg8UHHjGh=4bdtf0U3D1iO5-Xckpyg@mail.gmail.com>
References: <CADExsvHONmhx4uj1bkZXJg8UHHjGh=4bdtf0U3D1iO5-Xckpyg@mail.gmail.com>
Message-ID: <f3131ad7-bfdb-895e-2938-0a03962b91cd@chartertn.net>
On 10/17/18 20:17, Aaron Burrow wrote:
>
> Given that the server can unilaterally send updates to the client, why
> was the IDLE extension useful/necessary?
I'm no expert but I don't think I have seen an IMAP server that sends
unsolicited EXISTS or EXPUNGE responses when not in IDLE mode. These
untagged responses only occur in idle or when a client request occurs
first, e.g., NOOP. But you are right, RFC 3501 does say that the server
MAY send untagged messages at any time without a client request
occurring first.
The IDLE RFC 2177 gives a hint as to why IDLE is needed with this
statement:
"While the spec [RFC3501 I assume] actually does allow a server to push
EXISTS responses asynchronously, a client can't expect this behavior and
must poll."
So the IDLE capability and command provide a way for the client to know
for sure that asynchronous responses can occur and prepare to receive
them and not have to poll.
I have recently been contributing to the Thunderbird imap code. I am not
sure that it will correctly respond to unsolicited/asynchronous (out of
the blue) EXISTS responses unless idle mode has been entered, although
per RFC 3501 all clients should.
-gene

41
demo/ermis-f/imap-protocol/cur/1600094973.22507.mbox:2,S

@ -0,0 +1,41 @@
MBOX-Line: From dw at thedave.ca Wed Sep 9 19:45:39 2020
To: imap-protocol@u.washington.edu
From: Dave Warren <dw@thedave.ca>
Date: Wed Sep 9 19:46:07 2020
Subject: [Imap-protocol] Any valid use case for COPY besides moving
messages?
In-Reply-To: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
References: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
Message-ID: <e4a7a54e-9b62-e245-6aff-9f21697fd03c@thedave.ca>
On 2020-09-09 01:27, Andris Reinman wrote:
> As the subject states, is there actually any valid use case these days
> for COPY to just copy messages instead of being a poor substitute for
> MOVE (that is COPY+EXPUNGE)?
The use case is copying a message, rather than moving it.
I admit many/most users just move messages and in fact some mail
interfaces don't have an easy copy button, some omit it completely. If
you control the interface and want to drop the copy button, I wouldn't
be thrilled but I could accept it. But I believe you're talking about
silently and unexpectedly deleting a user's email.
I will sometimes copy a bunch of messages into a temporary folder for a
specific purpose. Perhaps they're related to something I am working on
but not part of a single thread (or selected parts of a much larger
thread), perhaps they're all requiring action/attention, maybe I'm going
to share that folder. But I *always* want the original content sorted in
the longterm place they live and I'll nuke that temporary folder once
I'm done with it. And admittedly this is not something I do especially
frequently either.
If my messages were silently discarded from their original folder, I
would be both logging it as a defect and very quickly switching to a
email service that doesn't lose email unexpectedly.
(Full disclosure: $DAYJOB has a product that only stores a single
instance of a message within a mailbox -- But there is no risk because
there is no copy action that fails silently, it simply doesn't exist,
and nothing other than an obvious "X" delete button will delete a message).

38
demo/ermis-f/imap-protocol/cur/1600094973.22518.mbox:2,S

@ -0,0 +1,38 @@
MBOX-Line: From gds at chartertn.net Tue Mar 5 11:46:44 2019
To: imap-protocol@u.washington.edu
From: Gene Smith <gds@chartertn.net>
Date: Tue Mar 5 11:47:35 2019
Subject: [Imap-protocol] gmail fails "tag uid fetch 123
(BODY.PEEK[2.1.1])", most others OK
In-Reply-To: <CABa8R6t79-k0uwNL=j1+5FZxh8sgcmh5XUSmTaMkKnkHztMdhg@mail.gmail.com>
References: <ebb06b9a-bd6b-7f7a-8a74-a0c8aa1591d1@chartertn.net>
<CABa8R6uNSk1QYME2-StLDUusPLo3oSCzyOEpaubx9LuUKm9gaQ@mail.gmail.com>
<CABa8R6t79-k0uwNL=j1+5FZxh8sgcmh5XUSmTaMkKnkHztMdhg@mail.gmail.com>
Message-ID: <36148fc1-25ba-b3bc-b34f-1da2a4bde55c@chartertn.net>
On 3/5/19 1:55 PM, Brandon Long wrote:
> Also interesting if it can fetch the full message, since that again
> might require a lot of individual fetches to reassemble, which might
> time out if we don't handle that correctly.
I don't see a problem when the whole message is fetched. That's the
default tb mode and the message is stored/cached to a disk file.
> How big is the message that caching it on your end is bad?
This message itself is just 350K. But if you configure the folder so
that the message is only cached to memory (not to a file) and not
showing attachments inline, then tb fetches attachment on demand when
clicked using the part number.
>
> Anyways, I've forwarded to the new team.? Obviously it should work
> even if it's a lot of work on our side.? Is it a consistent one that
> doesn't work, or any of them?
I haven't tested tb a lot with gmail using fetch by parts, mostly
Dovecot. I'll let you know if I see other problems.
I hope I understand and answered your questions. Thanks.

33
demo/ermis-f/imap-protocol/cur/1600094973.22526.mbox:2,S

@ -0,0 +1,33 @@
MBOX-Line: From arnt at gulbrandsen.priv.no Fri Nov 30 03:56:24 2018
To: imap-protocol@u.washington.edu
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Date: Fri Nov 30 03:56:52 2018
Subject: [Imap-protocol] Unsolicited server responses
In-Reply-To: <f3131ad7-bfdb-895e-2938-0a03962b91cd@chartertn.net>
References: <CADExsvHONmhx4uj1bkZXJg8UHHjGh=4bdtf0U3D1iO5-Xckpyg@mail.gmail.com>
<f3131ad7-bfdb-895e-2938-0a03962b91cd@chartertn.net>
Message-ID: <4d4d7b4f-5744-492f-8bac-1622e92ab59d@gulbrandsen.priv.no>
>> Given that the server can unilaterally send updates to the
>> client, why was the IDLE extension useful/necessary?
>
> I'm no expert but I don't think I have seen an IMAP server that
> sends unsolicited EXISTS or EXPUNGE responses when not in IDLE
> mode.
I've co-written one that sends a sends a very small number of responses and
then stops, which hasn't caused problems. I've heard that another server
sent an unlimited number of responses using blocking i/o, and that would
cause problems if the client wasn't listening.
IIRC more servers send unsolicited responses occasionally, to keep NAT
middleboxes from discarding the connection.
> "While the spec [RFC3501 I assume] actually does allow a server
> to push EXISTS responses asynchronously, a client can't expect
> this behavior and must poll."
That's the key.
Arnt

25
demo/ermis-f/imap-protocol/cur/1600094973.22529.mbox:2,S

@ -0,0 +1,25 @@
MBOX-Line: From burrows.labs at gmail.com Wed Oct 17 17:17:57 2018
To: imap-protocol@u.washington.edu
From: Aaron Burrow <burrows.labs@gmail.com>
Date: Wed Oct 17 17:18:30 2018
Subject: [Imap-protocol] Unsolicited server responses
Message-ID: <CADExsvHONmhx4uj1bkZXJg8UHHjGh=4bdtf0U3D1iO5-Xckpyg@mail.gmail.com>
When can and should a server send data the client hasn?t requested?
RFC3501#2.2.2 says ?A client MUST be prepared to accept any server response
at all times. This includes server data that was not requested.? Looking at
the semantics of the server responses, only EXISTS, RECENT, EXPUNGE and
FETCH stipulate sending ?unrequested? data.
Should this be interpreted, ?In theory the server can send whatever
responses whenever it wants. In practice, it just sends those four
piggybacked on command completion responses if there?s an unreported
mailbox update.?
Given that the server can unilaterally send updates to the client, why was
the IDLE extension useful/necessary?
Aaron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20181017/2982282f/attachment.html>

50
demo/ermis-f/imap-protocol/cur/1600094974.22507.mbox:2,S

@ -0,0 +1,50 @@
MBOX-Line: From tony at att.com Wed Sep 9 20:34:10 2020
To: imap-protocol@u.washington.edu
From: "HANSEN, TONY L" <tony@att.com>
Date: Wed Sep 9 20:34:43 2020
Subject: [Imap-protocol] Any valid use case for COPY besides moving
messages?
In-Reply-To: <e4a7a54e-9b62-e245-6aff-9f21697fd03c@thedave.ca>
References: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
<e4a7a54e-9b62-e245-6aff-9f21697fd03c@thedave.ca>
Message-ID: <239E8611-FA90-49DF-BE34-416F60D2172B@att.com>
I'll second what Dave says below.
99% of the time I want move semantics. But then there IS that 1% where I truly do want to make a copy of a message into a second folder, and it had better be a copy and the original had better not get lost from wherever else it might happen to live.
Tony
?On 9/9/20, 10:46 PM, "Imap-protocol on behalf of Dave Warren" <imap-protocol-bounces@mailman13.u.washington.edu on behalf of dw@thedave.ca> wrote:
On 2020-09-09 01:27, Andris Reinman wrote:
> As the subject states, is there actually any valid use case these days
> for COPY to just copy messages instead of being a poor substitute for
> MOVE (that is COPY+EXPUNGE)?
The use case is copying a message, rather than moving it.
I admit many/most users just move messages and in fact some mail
interfaces don't have an easy copy button, some omit it completely. If
you control the interface and want to drop the copy button, I wouldn't
be thrilled but I could accept it. But I believe you're talking about
silently and unexpectedly deleting a user's email.
I will sometimes copy a bunch of messages into a temporary folder for a
specific purpose. Perhaps they're related to something I am working on
but not part of a single thread (or selected parts of a much larger
thread), perhaps they're all requiring action/attention, maybe I'm going
to share that folder. But I *always* want the original content sorted in
the longterm place they live and I'll nuke that temporary folder once
I'm done with it. And admittedly this is not something I do especially
frequently either.
If my messages were silently discarded from their original folder, I
would be both logging it as a defect and very quickly switching to a
email service that doesn't lose email unexpectedly.
(Full disclosure: $DAYJOB has a product that only stores a single
instance of a message within a mailbox -- But there is no risk because
there is no copy action that fails silently, it simply doesn't exist,
and nothing other than an obvious "X" delete button will delete a message).

81
demo/ermis-f/imap-protocol/cur/1600094974.22518.mbox:2,S

@ -0,0 +1,81 @@
MBOX-Line: From gds at chartertn.net Tue Mar 5 12:36:10 2019
To: imap-protocol@u.washington.edu
From: Gene Smith <gds@chartertn.net>
Date: Tue Mar 5 12:36:43 2019
Subject: [Imap-protocol] gmail fails "tag uid fetch 123
(BODY.PEEK[2.1.1])", most others OK
In-Reply-To: <CABa8R6uNSk1QYME2-StLDUusPLo3oSCzyOEpaubx9LuUKm9gaQ@mail.gmail.com>
References: <ebb06b9a-bd6b-7f7a-8a74-a0c8aa1591d1@chartertn.net>
<CABa8R6uNSk1QYME2-StLDUusPLo3oSCzyOEpaubx9LuUKm9gaQ@mail.gmail.com>
Message-ID: <fcaae80f-f4eb-80db-133a-931ef75a9855@chartertn.net>
On 3/5/19 12:14 PM, Brandon Long wrote:
> Is it a consistent one that doesn't
> work, or any of them?
I wrote:
> Thunderbird accesses the body of an attachment like this (uid 123):
> tag uid fetch 123 (BODY.PEEK[2.33.1])
Maybe you are asking about the index? The index 1 to 107 produces the
error, i.e.,
tag uid fetch 123 (BODY.PEEK[2.1.1])
tag uid fetch 123 (BODY.PEEK[2.2.1])
:
tag uid fetch 123 (BODY.PEEK[2.107.1])
But the error only occur if the message indexed does not itself have
attachments.
I noticed that when there is an attachement on the rfc822 message, the
index does work. Like in my example, these do work and return the body
and the attachments OK:
tag uid fetch 123 (BODY.PEEK[2.66.1]) // body of 66th rfc822 attachment
tag uid fetch 123 (BODY.PEEK[2.66.2]) // 1st attachment on 66th
tag uid fetch 123 (BODY.PEEK[2.66.3]) // 2nd attachment on 66th
tag uid fetch 123 (BODY.PEEK[2.66.4]) // 3rd attachment on 66th
Here's a real fetch of the 3rd rfc822 attachment that itself has no
attachments:
-------------------------------------------------------------
. uid fetch 370 (BODY.PEEK[2.3.1])
. NO Some messages could not be FETCHed (Failure)
-------------------------------------------------------------
Here's a fetch of the 66th rfc822 attachment that has 3 attachment that
are base64 encoded text files:
-------------------------------------------------------------
. uid fetch 370 (BODY.PEEK[2.66.1])
* 1 FETCH (UID 370 BODY[2.66.1] {99}
I've attached gameserv.patch, gameserv.c and gameserv.c
Comments please..........
--James
)
. OK Success
----------------------------------------------------------------
Fetch of 3rd attachment of index 66:
. uid fetch 370 (BODY.PEEK[2.66.4])
* 1 FETCH (UID 370 BODY[2.66.4] {3728}
SW5kZXg6IE1ha2VmaWxlLmluDQo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpS
:
:
cnYsICpDaGFuU2VydiwgKk1lbW9TZXJ2LCAqSW5mb1NlcnYsICpHYW1lU2Vy
djsNCg==)
. OK Success
--------------------------------------------------------------

52
demo/ermis-f/imap-protocol/cur/1600094975.22507.mbox:2,S

@ -0,0 +1,52 @@
MBOX-Line: From brendan at kublai.com Wed Sep 9 23:08:46 2020
To: imap-protocol@u.washington.edu
From: Brendan Cully <brendan@kublai.com>
Date: Wed Sep 9 23:09:03 2020
Subject: [Imap-protocol] Any valid use case for COPY besides moving
messages?
In-Reply-To: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
References: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
Message-ID: <20200910060846.GA32325@3c22fbbbbb47.ant.amazon.com>
I also use COPY to COPY and would be upset if the messages in my
source folder disappeared withou my asking them to :)
I think you'd be better off implementing https://tools.ietf.org/html/rfc6851
even though it relies on clients to notice and use the implementation.
On Wednesday, 09 September 2020 at 10:27, Andris Reinman wrote:
> Hi,
>
> As the subject states, is there actually any valid use case these days for
> COPY to just copy messages instead of being a poor substitute for MOVE
> (that is COPY+EXPUNGE)?
>
> If an IMAP server would mark COPYied messages with \Delete and
> expunge these immediately after a message has been copied, would it break
> any real-use expectations?
>
> Why I'm asking is that I'm building a database backed email server (
> https://wildduck.email), we have a moderately sized cluster of emails
> (100k+ users, ~50TB+ of data, few hundred million emails) and when an IMAP
> client tries to copy all messages from one large folder to another then
> copying takes a lot of time (eg 'COPY 1:* target' where * is 10 000) as
> listing the database entries and copying these around takes time. And as
> there is no response until messages have been fully copied the client might
> think that TCP connection has been lost and retries the same action, ending
> up doing multiple COPY calls.
>
> So I was wondering if we could simply delete the already copied message
> from the source folder, as most probably the client would do it anyway once
> COPY is fully completed. Basically COPY would be an alias for MOVE.
> Obviously non-standard behavior but would we actually break something
> client side by doing this?
>
> Regards,
> Andris Reinman
> https://wildduck.email
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol

16
demo/ermis-f/imap-protocol/cur/1600094975.22518.mbox:2,S

@ -0,0 +1,16 @@
MBOX-Line: From gds at chartertn.net Sat Mar 30 11:10:21 2019
To: imap-protocol@u.washington.edu
From: Gene Smith <gds@chartertn.net>
Date: Sat Mar 30 11:10:57 2019
Subject: [Imap-protocol] CLIENTID capability for IMAP (and SMTP)
Message-ID: <8cade395-864a-9039-6bfa-874c26e5967e@chartertn.net>
Thunderbird has recently received a patch to add a CLIENTID capability
which can be seen here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1532388.
This includes links to the draft RFCs for IMAP and SMTP. I have been
unable to find any other information on this feature. Is it supported or
plaanned to be supported on any other IMAP or SMTP server?
-gene

31
demo/ermis-f/imap-protocol/cur/1600094975.22532.mbox:2,S

@ -0,0 +1,31 @@
MBOX-Line: From gds at chartertn.net Fri Sep 7 20:25:36 2018
To: imap-protocol@u.washington.edu
From: Gene Smith <gds@chartertn.net>
Date: Fri Sep 7 20:26:05 2018
Subject: [Imap-protocol] QRESYNC capability in gmail
In-Reply-To: <CABa8R6uN09NiGww5LC_Aiv_E9UrLW1wHE7sH4iPBo9bwYJNTvA@mail.gmail.com>
References: <38137c2b-f1f1-2bed-e22f-2aea7fa50ac3@chartertn.net>
<CAByav=gBnVkLg+4z90ewBvKRVtOrEQ7XESfirEQ1dyx=Sb0MXw@mail.gmail.com>
<abb75221-a38a-3317-86a2-98a8340e55d3@chartertn.net>
<CAByav=gfGNd2KHyx8kb9GQ-XEfs3L0LzqJuQGJRwDXg9x9mdMA@mail.gmail.com>
<1a206274-8bce-f789-4dc9-638ed20e9372@chartertn.net>
<d0bd4b95-90bb-4fae-937e-f4ad0c2ebd09@gulbrandsen.priv.no>
<CABa8R6ucJXxUp9kAQ+_fDvtEAwmAYtJ6Hmr60J5=SW48SLvmig@mail.gmail.com>
<b60bb28d-a16d-397d-784b-830265501279@chartertn.net>
<CABa8R6sMcLPOF2gbv-EYAOzwVMVi5CwZC_GZ2aHmuu2xFpovGw@mail.gmail.com>
<20430a7a-eeda-a60b-bf79-d55f1289f17a@chartertn.net>
<CABa8R6uN09NiGww5LC_Aiv_E9UrLW1wHE7sH4iPBo9bwYJNTvA@mail.gmail.com>
Message-ID: <e0110fb1-faf4-89c2-fd5e-28fee5316cd3@chartertn.net>
I have been researching the CONDSTORE feature in Thunderbird that is
currently disabled by default due to some unresolved bugs. Several bug
reports mention the QRESYNC extension to CONDSTORE as something that
would be helpful but is not supported in Thunderbird at all. One reason
listed is because gmail imap didn't support it and still doesn't the
last time I checked. Pending support for QRESYNC by gmail was last
mentioned several years ago on this list. Does anyone know the current
status of QRESYNC support in gmail imap, i.e., are there still plans to
support it and, if so, when?
Thanks,
Gene Smith

72
demo/ermis-f/imap-protocol/cur/1600094976.22507.mbox:2,S

@ -0,0 +1,72 @@
MBOX-Line: From andris.reinman at gmail.com Wed Sep 9 23:30:20 2020
To: imap-protocol@u.washington.edu
From: Andris Reinman <andris.reinman@gmail.com>
Date: Wed Sep 9 23:31:04 2020
Subject: [Imap-protocol] Any valid use case for COPY besides moving
messages?
In-Reply-To: <20200910060846.GA32325@3c22fbbbbb47.ant.amazon.com>
References: <CAPacwgy_1WJd5TLRDbykTnzfwv9hgcTLzBQZte5=bMRK-RUFLQ@mail.gmail.com>
<20200910060846.GA32325@3c22fbbbbb47.ant.amazon.com>
Message-ID: <CAPacwgzpvKVNRei2GQp-wKox00ekk5Cuch-d+eCMc7CTS_847Q@mail.gmail.com>
There is MOVE support but usage between COPY and MOVE is pretty even. For
example, I checked, and yesterday 3,500 distinct users issued 31,000 MOVE
commands and 3,300 distinct users issued 32,000 COPY commands, so it is
around 50%-50%. Users on the latest iOS Mail App use MOVE and users on
Outlook use COPY + UID STORE \Deleted.
Kontakt Brendan Cully (<brendan@kublai.com>) kirjutas kuup?eval N, 10.
september 2020 kell 09:08:
> I also use COPY to COPY and would be upset if the messages in my
> source folder disappeared withou my asking them to :)
>
> I think you'd be better off implementing
> https://tools.ietf.org/html/rfc6851
> even though it relies on clients to notice and use the implementation.
>
> On Wednesday, 09 September 2020 at 10:27, Andris Reinman wrote:
> > Hi,
> >
> > As the subject states, is there actually any valid use case these days
> for
> > COPY to just copy messages instead of being a poor substitute for MOVE
> > (that is COPY+EXPUNGE)?
> >
> > If an IMAP server would mark COPYied messages with \Delete and
> > expunge these immediately after a message has been copied, would it break
> > any real-use expectations?
> >
> > Why I'm asking is that I'm building a database backed email server (
> > https://wildduck.email), we have a moderately sized cluster of emails
> > (100k+ users, ~50TB+ of data, few hundred million emails) and when an
> IMAP
> > client tries to copy all messages from one large folder to another then
> > copying takes a lot of time (eg 'COPY 1:* target' where * is 10 000) as
> > listing the database entries and copying these around takes time. And as
> > there is no response until messages have been fully copied the client
> might
> > think that TCP connection has been lost and retries the same action,
> ending
> > up doing multiple COPY calls.
> >
> > So I was wondering if we could simply delete the already copied message
> > from the source folder, as most probably the client would do it anyway
> once
> > COPY is fully completed. Basically COPY would be an alias for MOVE.
> > Obviously non-standard behavior but would we actually break something
> > client side by doing this?
> >
> > Regards,
> > Andris Reinman
> > https://wildduck.email
>
> > _______________________________________________
> > Imap-protocol mailing list
> > Imap-protocol@u.washington.edu
> > http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20200910/597ba6ea/attachment.html>

40
demo/ermis-f/imap-protocol/cur/1600094976.22518.mbox:2,S

@ -0,0 +1,40 @@
MBOX-Line: From blong at google.com Sun Mar 31 09:44:23 2019
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Sun Mar 31 09:44:40 2019
Subject: [Imap-protocol] CLIENTID capability for IMAP (and SMTP)
In-Reply-To: <8cade395-864a-9039-6bfa-874c26e5967e@chartertn.net>
References: <8cade395-864a-9039-6bfa-874c26e5967e@chartertn.net>
Message-ID: <CABa8R6ufcJ9GimEoLrFkKnMCh14n5+VK3uN-++f4tE-qfPW-7g@mail.gmail.com>
Although I don't work on the Gmail imap anymore, I will say that we
implemented a competing idea (AUTH LOGIN-CLIENTTOKEN), though we eventually
decided to concentrate on OAUTHBEARER. OAUTH authorizes each client
separately, so provides the same client based benefits.
If this became standard, we could implement it, but I haven't really seen
consensus on it yet, or adoption by a working group. When it matures, we
would need to look at how many 'legacy' auth users we have , and the
benefits to that population.
Brandon
On Sat, Mar 30, 2019, 11:11 AM Gene Smith <gds@chartertn.net> wrote:
> Thunderbird has recently received a patch to add a CLIENTID capability
> which can be seen here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1532388.
>
> This includes links to the draft RFCs for IMAP and SMTP. I have been
> unable to find any other information on this feature. Is it supported or
> plaanned to be supported on any other IMAP or SMTP server?
>
> -gene
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20190331/a3933c8d/attachment.html>

46
demo/ermis-f/imap-protocol/cur/1600094976.22532.mbox:2,S

@ -0,0 +1,46 @@
MBOX-Line: From blong at google.com Sat Sep 8 07:10:55 2018
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Sat Sep 8 07:11:37 2018
Subject: [Imap-protocol] QRESYNC capability in gmail
In-Reply-To: <e0110fb1-faf4-89c2-fd5e-28fee5316cd3@chartertn.net>
References: <38137c2b-f1f1-2bed-e22f-2aea7fa50ac3@chartertn.net>
<CAByav=gBnVkLg+4z90ewBvKRVtOrEQ7XESfirEQ1dyx=Sb0MXw@mail.gmail.com>
<abb75221-a38a-3317-86a2-98a8340e55d3@chartertn.net>
<CAByav=gfGNd2KHyx8kb9GQ-XEfs3L0LzqJuQGJRwDXg9x9mdMA@mail.gmail.com>
<1a206274-8bce-f789-4dc9-638ed20e9372@chartertn.net>
<d0bd4b95-90bb-4fae-937e-f4ad0c2ebd09@gulbrandsen.priv.no>
<CABa8R6ucJXxUp9kAQ+_fDvtEAwmAYtJ6Hmr60J5=SW48SLvmig@mail.gmail.com>
<b60bb28d-a16d-397d-784b-830265501279@chartertn.net>
<CABa8R6sMcLPOF2gbv-EYAOzwVMVi5CwZC_GZ2aHmuu2xFpovGw@mail.gmail.com>
<20430a7a-eeda-a60b-bf79-d55f1289f17a@chartertn.net>
<CABa8R6uN09NiGww5LC_Aiv_E9UrLW1wHE7sH4iPBo9bwYJNTvA@mail.gmail.com>
<e0110fb1-faf4-89c2-fd5e-28fee5316cd3@chartertn.net>
Message-ID: <CABa8R6sVgYiJJWLPP_8f9U=gj+1F1m-mLbuiW2bXay8D-1odJg@mail.gmail.com>
I don't think there are any plans to support qresync on Gmail at this time.
Brandon
On Fri, Sep 7, 2018, 8:26 PM Gene Smith <gds@chartertn.net> wrote:
> I have been researching the CONDSTORE feature in Thunderbird that is
> currently disabled by default due to some unresolved bugs. Several bug
> reports mention the QRESYNC extension to CONDSTORE as something that
> would be helpful but is not supported in Thunderbird at all. One reason
> listed is because gmail imap didn't support it and still doesn't the
> last time I checked. Pending support for QRESYNC by gmail was last
> mentioned several years ago on this list. Does anyone know the current
> status of QRESYNC support in gmail imap, i.e., are there still plans to
> support it and, if so, when?
>
> Thanks,
> Gene Smith
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20180908/8b7a5c24/attachment.html>

44
demo/ermis-f/imap-protocol/cur/1600094976.22535.mbox:2,S

@ -0,0 +1,44 @@
MBOX-Line: From andris.reinman at gmail.com Fri Dec 29 18:15:14 2017
To: imap-protocol@u.washington.edu
From: Andris Reinman <andris.reinman@gmail.com>
Date: Fri Jun 8 12:34:55 2018
Subject: [Imap-protocol] Deleting selected mailbox
Message-ID: <CAPacwgy_nVaePkawv3r2SVOM3yADyRjaX-=mfY_djevPSaV-Zw@mail.gmail.com>
Hi,
I'm wondering that if a client issues a DELETE against the mailbox that is
currently SELECTed then what should be the correct way to handle this. In
most cases it seems that servers respond with untagged BYE. Would it be
correct to send the BYE before tagged response for DELETE or not?
I have a race condition in WildDuck IMAP server where sometimes the
notification about deleted folder gets processed before tagged response is
sent to the client, so while in most cases this happens:
C: A SELECT FOLDER
S: (mailbox info)
S: A OK [READ-WRITE] SELECT completed
C: A DELETE FOLDER
C: A OK DELETE completed
C: * BYE Selected mailbox was deleted, have to disconnect
(connection is closed by server)
Then sometimes it is like this (no response for DELETE):
C: A SELECT FOLDER
S: (mailbox info)
S: A OK [READ-WRITE] SELECT completed
C: A DELETE FOLDER
C: * BYE Selected mailbox was deleted, have to disconnect
(connection is closed by server)
Is the latter a violation of IMAP RFCs? I mean that once the client
reconnects the folder is not there anymore anyway?
Regards,
Andris Reinman
https://github.com/nodemailer/wildduck#wild-duck-mail-server
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20171230/b759abf8/attachment.html>

18
demo/ermis-f/imap-protocol/cur/1600094977.22532.mbox:2,S

@ -0,0 +1,18 @@
MBOX-Line: From forest37 at foxmail.com Sun Sep 9 20:32:48 2018
To: imap-protocol@u.washington.edu
From: =?ISO-8859-1?B?Zm9yZXN0?= <forest37@foxmail.com>
Date: Sun Sep 9 20:33:17 2018
Subject: [Imap-protocol] when will occur BadServerResponseException
Message-ID: <tencent_88376FBC5600AE5CEC0700EC8E62A08B4207@qq.com>
hello everyone,
when I connect to the server, I get the exception BadServerResponseException
I don't know how to proceed.
------------------
Best regards
Senlin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20180910/abea1d54/attachment.html>

13
demo/ermis-f/imap-protocol/cur/1600094977.22535.mbox:2,S

@ -0,0 +1,13 @@
MBOX-Line: From arnt at gulbrandsen.priv.no Sat Dec 30 01:04:46 2017
To: imap-protocol@u.washington.edu
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Date: Fri Jun 8 12:34:55 2018
Subject: [Imap-protocol] Deleting selected mailbox
References: <CAPacwgy_nVaePkawv3r2SVOM3yADyRjaX-=mfY_djevPSaV-Zw@mail.gmail.com>
Message-ID: <vIPNOWMw3/S8yusfY1XTWtxFzSHnlx6wF6r6znWNDV0=.sha-256@antelope.email>
I at lest do not know any reason why that would not be permitted. An
untagged BYE is legal at any time, and they means any time.
Arnt

49
demo/ermis-f/imap-protocol/cur/1600094977.22538.mbox:2,S

@ -0,0 +1,49 @@
MBOX-Line: From gds at chartertn.net Sun Oct 8 13:58:53 2017
To: imap-protocol@u.washington.edu
From: Gene Smith <gds@chartertn.net>
Date: Fri Jun 8 12:34:55 2018
Subject: [Imap-protocol] Is server re-use of UID OK?
Message-ID: <38137c2b-f1f1-2bed-e22f-2aea7fa50ac3@chartertn.net>
Copy a message with UID 1267 from Inbox to Mbox and deleted it in Inbox.
With Inbox selected:
C: aaa UID COPY 1267 "Mbox"
S: aaa OK [COPYUID 123456789 1267 1007] UID COPY completed
C: bbb UID store 1267 +Flags (\Deleted)
:
This works fine and message appears gone from Inbox and is now visible
in Mbox at UID 1007. Now with Mbox selected, attempt to copy the message
UID 1007 back to Inbox:
C: ccc UID COPY 1007 "Inbox"
S: ccc OK [COPYUID 987654321 1007 1267] UID COPY completed
C: ddd UID store 1007 +Flags (\Deleted)
:
This occurs with no error and the message appears gone from Mbox.
However, it does not appear in Inbox. The problem is that the server
doesn't use the UIDNEXT of Inbox, which is 1270. Instead it reuses and
copies to the UID that the message originally had in Inbox, 1267. Also,
the \deleted flag on 1267 remains set and does not get cleared after the
copy, causing the message to remain not visible in Inbox.
Does this seem like acceptable imap server behavior?
Note: If Inbox is expunged before the message is copied back, the server
copies to Inbox's UIDNEXT (1270) and the the message appears correctly
in Inbox with \delete flag cleared.
Thanks,
-gene

13
demo/ermis-f/imap-protocol/cur/1600094978.22532.mbox:2,S

@ -0,0 +1,13 @@
MBOX-Line: From arnt at gulbrandsen.priv.no Mon Sep 10 09:18:40 2018
To: imap-protocol@u.washington.edu
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Date: Mon Sep 10 09:47:32 2018
Subject: [Imap-protocol] when will occur BadServerResponseException
In-Reply-To: <tencent_88376FBC5600AE5CEC0700EC8E62A08B4207@qq.com>
References: <tencent_88376FBC5600AE5CEC0700EC8E62A08B4207@qq.com>
Message-ID: <1bcd1914-3b35-4eeb-8d5d-f6e16b62d861@gulbrandsen.priv.no>
That exception occurs when S22imap connects to something that is not an
IMAP server.
Arnt

31
demo/ermis-f/imap-protocol/cur/1600094978.22535.mbox:2,S

@ -0,0 +1,31 @@
MBOX-Line: From andris.reinman at gmail.com Sat Dec 30 12:16:25 2017
To: imap-protocol@u.washington.edu
From: Andris Reinman <andris.reinman@gmail.com>
Date: Fri Jun 8 12:34:55 2018
Subject: [Imap-protocol] Deleting selected mailbox
In-Reply-To: <vIPNOWMw3/S8yusfY1XTWtxFzSHnlx6wF6r6znWNDV0=.sha-256@antelope.email>
References: <CAPacwgy_nVaePkawv3r2SVOM3yADyRjaX-=mfY_djevPSaV-Zw@mail.gmail.com>
<vIPNOWMw3/S8yusfY1XTWtxFzSHnlx6wF6r6znWNDV0=.sha-256@antelope.email>
Message-ID: <CAPacwgxtf2soqi0yKrvR0r35dCHw5uq2E5zx=xqjxr9=JzEvXQ@mail.gmail.com>
Thanks, that's something I was assuming as well. The only problem I could
think of would be clients that keep multiple connections for the same user
account open. One connection tries to delete a mailbox, gets BYE and
disconnects. The other one sees that DELETE was not properly answered and
thus assumes that the mailbox is still there. Though I'd guess that clients
that are able to keep multiple connections open are smart enough to not
delete mailboxes that are currently selected.
Regards,
Andris
2017-12-30 11:04 GMT+02:00 Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>:
> I at lest do not know any reason why that would not be permitted. An
> untagged BYE is legal at any time, and they means any time.
>
> Arnt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20171230/5a04e512/attachment.html>

37
demo/ermis-f/imap-protocol/cur/1600094978.22538.mbox:2,S

@ -0,0 +1,37 @@
MBOX-Line: From tjs at psaux.com Sun Oct 8 14:43:59 2017
To: imap-protocol@u.washington.edu
From: Tim Showalter <tjs@psaux.com>
Date: Fri Jun 8 12:34:55 2018
Subject: [Imap-protocol] Is server re-use of UID OK?
In-Reply-To: <38137c2b-f1f1-2bed-e22f-2aea7fa50ac3@chartertn.net>
References: <38137c2b-f1f1-2bed-e22f-2aea7fa50ac3@chartertn.net>
Message-ID: <CAByav=gBnVkLg+4z90ewBvKRVtOrEQ7XESfirEQ1dyx=Sb0MXw@mail.gmail.com>
On Sun, Oct 8, 2017 at 1:58 PM, Gene Smith <gds@chartertn.net> wrote:
> Copy a message with UID 1267 from Inbox to Mbox and deleted it in Inbox.
> With Inbox selected:
>
> C: aaa UID COPY 1267 "Mbox"
> S: aaa OK [COPYUID 123456789 1267 1007] UID COPY completed
> C: bbb UID store 1267 +Flags (\Deleted)
>
> C: ccc UID COPY 1007 "Inbox"
> S: ccc OK [COPYUID 987654321 1007 1267] UID COPY completed
> C: ddd UID store 1007 +Flags (\Deleted)
>
> Does this seem like acceptable imap server behavior?
>
No, this is a violation. Both messages have UID 1267, and if there is no
intervening EXPUNGE, the first message still exists when the second one
overwrites it. Neither behavior is remotely permissible.
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20171008/2e02a247/attachment.html>

65
demo/ermis-f/imap-protocol/cur/1600094978.22541.mbox:2,S

@ -0,0 +1,65 @@
MBOX-Line: From gds at chartertn.net Wed Jul 12 16:14:21 2017
To: imap-protocol@u.washington.edu
From: Gene Smith <gds@chartertn.net>
Date: Fri Jun 8 12:34:55 2018
Subject: [Imap-protocol] LSUB server bug or not a bug?
Message-ID: <b24db758-00b8-a80a-1e5c-58b831f1451c@chartertn.net>
I see this when I send client command LIST with telnet:
3 list "" "/*"
* LIST () "/" "/SUSPECTED SPAM"
3 OK LIST completed
When I do LSUB with the same parameters I see this:
3 lsub "" "/*"
* LSUB () "/" "Trash"
* LSUB () "/" "Inbox"
* LSUB () "/" "&BCcENQRABD0EPgQyBDgEOgQ4-"
* LSUB () "/" "&BB4EQgQ,BEAEMAQyBDsENQQ9BD0ESwQ1-"
* LSUB () "/" "/SUSPECTED SPAM"
* LSUB () "/" "Junk E-Mail"
* LSUB () "/" "Junk"
* LSUB () "/" "&BCMENAQwBDsENQQ9BD0ESwQ1-ZZZ"
* LSUB () "/" "SUSPECTED HAM"
* LSUB () "/" "INBOX/Testing"
* LSUB () "/" "gds"
* LSUB () "/" "gds/eds"
* LSUB () "/" "gds/sdg"
3 OK LSUB completed
I expected to see only /SUSPECTED SPAM in the lsub response just like
list returns instead of all the mailboxes.
However, if I do this:
3 OK LIST completed
3 lsub "" "//*"
* LSUB () "/" "/SUSPECTED SPAM"
3 OK LSUB completed
I see only the /SUSPECTED SPAM now.
Why are two slashes required for lsub but not for list?
The "/SUSPECTED SPAM" mailbox, I am told, is configured as a public
folder in the MDaemon IMAP server. I don't have direct access to the
server and don't know why the name starts with a slash.
Additional info: The namespace command reports as follows:
3 namespace
* NAMESPACE (("" "/")) NIL (("/" "/"))
3 OK NAMESPACE completed
Note also that the unreadable mailbox names are Russian encodings.
Thanks,
-gene

38
demo/ermis-f/imap-protocol/cur/1600094979.22535.mbox:2,S

@ -0,0 +1,38 @@
MBOX-Line: From tjs at psaux.com Sun Dec 31 10:46:57 2017
To: imap-protocol@u.washington.edu
From: Tim Showalter <tjs@psaux.com>
Date: Fri Jun 8 12:34:55 2018
Subject: [Imap-protocol] Deleting selected mailbox
In-Reply-To: <CAPacwgxtf2soqi0yKrvR0r35dCHw5uq2E5zx=xqjxr9=JzEvXQ@mail.gmail.com>
References: <CAPacwgy_nVaePkawv3r2SVOM3yADyRjaX-=mfY_djevPSaV-Zw@mail.gmail.com>
<vIPNOWMw3/S8yusfY1XTWtxFzSHnlx6wF6r6znWNDV0=.sha-256@antelope.email>
<CAPacwgxtf2soqi0yKrvR0r35dCHw5uq2E5zx=xqjxr9=JzEvXQ@mail.gmail.com>
Message-ID: <CAByav=gR8a4vLVuQntxx476HdE4itGuVLYroNYgTjSve0-AuFw@mail.gmail.com>
On Sat, Dec 30, 2017 at 12:16 PM, Andris Reinman <andris.reinman@gmail.com>
wrote:
> Thanks, that's something I was assuming as well. The only problem I could
> think of would be clients that keep multiple connections for the same user
> account open. One connection tries to delete a mailbox, gets BYE and
> disconnects. The other one sees that DELETE was not properly answered and
> thus assumes that the mailbox is still there. Though I'd guess that clients
> that are able to keep multiple connections open are smart enough to not
> delete mailboxes that are currently selected.
>
Clients can't make this assumption. There is no reason to believe that only
one type of clients are accessing a mailbox, and the other type clients
have no responsibility (or ability) to "play nice".
I believe RFC 2180 discusses this in some detail. The document is pretty
old now, but was a topic of some discussion a few years back. I think that
it's very difficult to be really "smart" in any of these scenarios, and
probably the best practice is to keep it simple. I have seen a lot of
interesting interpretations from clients, but this one seems like the one
most likely to cause least confusion.
Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20171231/7dcffdb4/attachment.html>

50
demo/ermis-f/imap-protocol/cur/1600094979.22538.mbox:2,S

@ -0,0 +1,50 @@
MBOX-Line: From gds at chartertn.net Sun Oct 8 15:26:59 2017
To: imap-protocol@u.washington.edu
From: Gene Smith <gds@chartertn.net>
Date: Fri Jun 8 12:34:55 2018
Subject: [Imap-protocol] Is server re-use of UID OK?
In-Reply-To: <CAByav=gBnVkLg+4z90ewBvKRVtOrEQ7XESfirEQ1dyx=Sb0MXw@mail.gmail.com>
References: <38137c2b-f1f1-2bed-e22f-2aea7fa50ac3@chartertn.net>
<CAByav=gBnVkLg+4z90ewBvKRVtOrEQ7XESfirEQ1dyx=Sb0MXw@mail.gmail.com>
Message-ID: <abb75221-a38a-3317-86a2-98a8340e55d3@chartertn.net>
On 10/8/17 5:43 PM, Tim Showalter wrote:
> On Sun, Oct 8, 2017 at 1:58 PM, Gene Smith <gds@chartertn.net
> <mailto:gds@chartertn.net>> wrote:
>
> Copy a message with UID 1267 from Inbox to Mbox and deleted it in
> Inbox. With Inbox selected:
>
> C: aaa UID COPY 1267 "Mbox"
> S: aaa OK [COPYUID 123456789 1267 1007] UID COPY completed
> C: bbb UID store 1267 +Flags (\Deleted)
>
> C: ccc UID COPY 1007 "Inbox"
> S: ccc OK [COPYUID 987654321 1007 1267] UID COPY completed
> C: ddd UID store 1007 +Flags (\Deleted)
>
> Does this seem like acceptable imap server behavior?
>
>
> No, this is a violation. Both messages have UID 1267, and if there is no
> intervening EXPUNGE, the first message still exists when the second one
> overwrites it. Neither behavior is remotely permissible.
>
> Tim
>
I think the server is thinking, "its the same message I am copying back
to Inbox (how does it knows? Same Message-ID or maybe checksum?) so I
don't have to do anything." If the server had at least reset the
\deleted flag on message at UID 1267 in Inbox I think it would be OK.
The rfc says COPY must preserve the flags. It also says messages added
to a mailbox must have UID >= UIDNEXT. But if the server is copying in a
message that is already present but just flagged as \deleted, maybe RFC
doesn't say you can't COPYUID to the original UID which is < UIDNEXT?
But I think the server should reset \deleted at the destination.
FYI, the server is a product called "openwave" used by a fairly large
ISP (charter/spectrum).