add imap-protocol list archives folder
parent
b35047690e
commit
6331317b58
GPG Key ID:
73627C2F690DF710
@ -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>
|
||||
@ -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-)
|
||||
@ -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
|
||||
@ -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.
|
||||
@ -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>
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
@ -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
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -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>
|
||||
@ -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.
|
||||
@ -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>
|
||||
@ -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?
|
||||
|
||||
|
||||
@ -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>
|
||||
@ -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>
|
||||
@ -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>
|
||||
@ -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
|
||||
|
||||
|
||||
|
||||
|
||||
@ -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).
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
@ -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).
|
||||
|
||||
@ -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
|
||||
--------------------------------------------------------------
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
@ -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
|
||||
@ -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>
|
||||
@ -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>
|
||||
@ -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>
|
||||
@ -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>
|
||||
@ -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>
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -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
|
||||
@ -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>
|
||||
@ -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>
|
||||
@ -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
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@ -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>
|
||||
|
||||