add imap-protocol list archives folder
parent
f12f8d2ae5
commit
041d62e610
|
@ -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>
|
||||
|
||||
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>
|
|
@ -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).
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
MBOX-Line: From gds at chartertn.net Fri Jul 14 17:17:25 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?
|
||||
In-Reply-To: <b24db758-00b8-a80a-1e5c-58b831f1451c@chartertn.net>
|
||||
References: <b24db758-00b8-a80a-1e5c-58b831f1451c@chartertn.net>
|
||||
Message-ID: <40bbab51-5f5a-324b-329c-6bf7c3eb4702@chartertn.net>
|
||||
|
||||
Maybe an easier question would be what is the correct ways to send a
|
||||
LIST and LSUB when the reference is empty string, the prefix is / and
|
||||
the hierarchy separator is also / ?
|
||||
|
||||
-gene
|
||||
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
MBOX-Line: From jjmckay at comaxis.com Fri May 12 12:14:14 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Jeff McKay <jjmckay@comaxis.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Authenticating with iCloud
|
||||
Message-ID: <f5c54374-6858-92e3-3ea6-1b02c9df65f6@comaxis.com>
|
||||
|
||||
Does the server imap.mail.me.com not support a standard IMAP logon with
|
||||
a user id and password? I use port 993,
|
||||
just a simple login command: LOGIN "username@icloud.com" "password"
|
||||
but get back "Authentication failed". My customer claims the user name
|
||||
and password are valid.
|
||||
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
MBOX-Line: From tjs at psaux.com Sun Oct 8 18:40:26 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: <abb75221-a38a-3317-86a2-98a8340e55d3@chartertn.net>
|
||||
References: <38137c2b-f1f1-2bed-e22f-2aea7fa50ac3@chartertn.net>
|
||||
<CAByav=gBnVkLg+4z90ewBvKRVtOrEQ7XESfirEQ1dyx=Sb0MXw@mail.gmail.com>
|
||||
<abb75221-a38a-3317-86a2-98a8340e55d3@chartertn.net>
|
||||
Message-ID: <CAByav=gfGNd2KHyx8kb9GQ-XEfs3L0LzqJuQGJRwDXg9x9mdMA@mail.gmail.com>
|
||||
|
||||
On Sun, Oct 8, 2017 at 3:26 PM, Gene Smith <gds@chartertn.net> wrote:
|
||||
>
|
||||
> 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)
|
||||
>
|
||||
>
|
||||
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.
|
||||
>
|
||||
|
||||
Recovering a used UID is never permitted*. If there is no EXPUNGE, there
|
||||
should be two copies of the message in Inbox in this example. (Setting
|
||||
\Deleted is reversible.)
|
||||
|
||||
The design of the specification is concerned with what happens when a
|
||||
separate client connects before and after this exchange. Because UIDNEXT
|
||||
has not been used correctly, clients that have cached state wouldn't see
|
||||
changes to the mailbox correctly.
|
||||
|
||||
I guess the server might have an optimization (aka hack) for this, but it
|
||||
doesn't appear to be properly protocol compliant.
|
||||
|
||||
* unless the UIDVALIDITY is reset, which trashes everyone's caches anyway.
|
||||
|
||||
Tim
|
||||
?
|
||||
-------------- next part --------------
|
||||
An HTML attachment was scrubbed...
|
||||
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20171008/831bdddd/attachment.html>
|
|
@ -0,0 +1,25 @@
|
|||
MBOX-Line: From davew at hireahit.com Fri May 12 12:26:02 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Dave Warren <davew@hireahit.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Authenticating with iCloud
|
||||
In-Reply-To: <f5c54374-6858-92e3-3ea6-1b02c9df65f6@comaxis.com>
|
||||
References: <f5c54374-6858-92e3-3ea6-1b02c9df65f6@comaxis.com>
|
||||
Message-ID: <1494617162.302895.974862968.74D8B3D4@webmail.messagingengine.com>
|
||||
|
||||
Two-factor authentication, perhaps requiring an App Specific password?
|
||||
|
||||
On Fri, May 12, 2017, at 12:14, Jeff McKay wrote:
|
||||
> Does the server imap.mail.me.com not support a standard IMAP logon with
|
||||
> a user id and password? I use port 993,
|
||||
> just a simple login command: LOGIN "username@icloud.com" "password"
|
||||
> but get back "Authentication failed". My customer claims the user name
|
||||
> and password are valid.
|
||||
>
|
||||
> _______________________________________________
|
||||
> Imap-protocol mailing list
|
||||
> Imap-protocol@u.washington.edu
|
||||
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
||||
>
|
||||
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
MBOX-Line: From gds at chartertn.net Sun Oct 8 19:51:43 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=gfGNd2KHyx8kb9GQ-XEfs3L0LzqJuQGJRwDXg9x9mdMA@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>
|
||||
Message-ID: <1a206274-8bce-f789-4dc9-638ed20e9372@chartertn.net>
|
||||
|
||||
On 10/8/17 9:40 PM, Tim Showalter wrote:
|
||||
> On Sun, Oct 8, 2017 at 3:26 PM, Gene Smith <gds@chartertn.net
|
||||
> <mailto:gds@chartertn.net>>?wrote:
|
||||
>
|
||||
|
||||
Tim,
|
||||
Thanks for your help.
|
||||
|
||||
> Recovering a used UID is never permitted*.?If there is no EXPUNGE, there
|
||||
> should be two copies of the message in Inbox in this example. (Setting
|
||||
> \Deleted is reversible.)
|
||||
|
||||
Yes, for other IMAP servers I have tested, if I copy message "A" 10
|
||||
times into Inbox I see 10 identical copies of message A in Inbox. For
|
||||
this openwave server, I see only 1 (and uid fetch 1:* (FLAGS) shows only 1).
|
||||
|
||||
>
|
||||
> The design of the specification is concerned with what happens when a
|
||||
> separate client connects before and after this exchange. Because UIDNEXT
|
||||
> has not been used correctly, clients that have cached state wouldn't see
|
||||
> changes to the mailbox correctly.
|
||||
|
||||
If the server would clear the \deleted flag at the destination uid and
|
||||
did no actual copy in response to this uid copy it would produce an
|
||||
acceptable result (message visible in client again). This would be no
|
||||
different than changing flags with uid store it would seem (e.g., what
|
||||
happen when a deleted message is undeleted with crtl-z in client). Not
|
||||
sure how other/separate clients would be confused by this.
|
||||
|
||||
>
|
||||
> I guess the server might have an optimization (aka hack) for this, but
|
||||
> it doesn't appear to be properly protocol compliant.
|
||||
|
||||
So in summary, you are saying that the server should always use the
|
||||
UIDNEXT or greater when messages are copied to a mbox, even if the
|
||||
server determines there is an identical message at a lower UID. To do
|
||||
otherwise violates rfc 3501.
|
||||
|
||||
-gene
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
MBOX-Line: From kmansoft at gmail.com Fri May 12 12:55:26 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Kostya Vasilyev <kmansoft@gmail.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Authenticating with iCloud
|
||||
In-Reply-To: <1494617162.302895.974862968.74D8B3D4@webmail.messagingengine.com>
|
||||
References: <f5c54374-6858-92e3-3ea6-1b02c9df65f6@comaxis.com>
|
||||
<1494617162.302895.974862968.74D8B3D4@webmail.messagingengine.com>
|
||||
Message-ID: <CAN7dqjDDUnvX81RjY+pn1UcXA9Zhe8V6K9dX1nuOgFwamm9quw@mail.gmail.com>
|
||||
|
||||
Another potential reason:
|
||||
|
||||
The @mac.com / @me.com IMAP servers advertise SASL PLAIN but it
|
||||
doesn't actually work with a full email address (user@mac.com or
|
||||
user@me.com), only works with "user".
|
||||
|
||||
So two possible workarounds:
|
||||
|
||||
- Do not use SASL PLAIN for imap.mail.me.com / mac.com
|
||||
|
||||
- Or strip the domain part from the login
|
||||
|
||||
PS - at least the above was the case 2-3 years ago when we ran into
|
||||
this with our email app and had to add a workaround.
|
||||
|
||||
-- K
|
||||
|
||||
2017-05-12 22:26 GMT+03:00 Dave Warren <davew@hireahit.com>:
|
||||
> Two-factor authentication, perhaps requiring an App Specific password?
|
||||
>
|
||||
> On Fri, May 12, 2017, at 12:14, Jeff McKay wrote:
|
||||
>> Does the server imap.mail.me.com not support a standard IMAP logon with
|
||||
>> a user id and password? I use port 993,
|
||||
>> just a simple login command: LOGIN "username@icloud.com" "password"
|
||||
>> but get back "Authentication failed". My customer claims the user name
|
||||
>> and password are valid.
|
||||
>>
|
||||
>> _______________________________________________
|
||||
>> 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
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
MBOX-Line: From jjmckay at comaxis.com Tue Mar 7 16:44:12 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Jeff McKay <jjmckay@comaxis.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Strange behavior of Dwarf IMAP
|
||||
Message-ID: <c5f4fa80-5df3-b937-6039-757128711c2a@comaxis.com>
|
||||
|
||||
I am dealing with a customer's IMAP server, which identifies itself as
|
||||
Dwarf 2.0.0 (part of Gnome I guess) that seems to be acting
|
||||
strangely. My code sends this command:
|
||||
|
||||
A746 FETCH 1 (FLAGS UID INTERNALDATE BODY.PEEK[])
|
||||
|
||||
I expect to get back a single message, however after the last line of
|
||||
the first message, I then get the line:
|
||||
|
||||
* 2 FETCH (FLAGS (\Seen) UID 2290456508 INTERNALDATE "20-Jan-2017
|
||||
07:55:29 -0500" BODY[] {76009}
|
||||
|
||||
and on and on... In other words it just keeps blasting messages at me,
|
||||
beyond the single message I asked for. I've never seen this
|
||||
behavior before with any other server. At first I thought it was some
|
||||
screw up in my lower level tcp code, but I am quite certain that
|
||||
I never sent out a FETCH 2 command, so how could I be getting message 2,
|
||||
3, etc.?
|
||||
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
MBOX-Line: From arnt at gulbrandsen.priv.no Mon Oct 9 07:39:18 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] Is server re-use of UID OK?
|
||||
In-Reply-To: <1a206274-8bce-f789-4dc9-638ed20e9372@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>
|
||||
Message-ID: <d0bd4b95-90bb-4fae-937e-f4ad0c2ebd09@gulbrandsen.priv.no>
|
||||
|
||||
Gene Smith writes:
|
||||
> Yes, for other IMAP servers I have tested, if I copy message
|
||||
> "A" 10 times into Inbox I see 10 identical copies of message A
|
||||
> in Inbox. For this openwave server, I see only 1 (and uid fetch
|
||||
> 1:* (FLAGS) shows only 1).
|
||||
|
||||
Have you tested with gmail?
|
||||
|
||||
The server doesn't seem to reuse a UID, if I understand you correctly. The
|
||||
message has a UID before the COPY command and nothing changes. The UID is
|
||||
in continuous use for a particular message, so there's no reuse going on,
|
||||
and the ban on reuse does not apply.
|
||||
|
||||
Can you find out whether flags apply to the message or to references? Ie.
|
||||
if you copy a message into two mailboxes and set flag "foobar" on the
|
||||
message in one mailbox, does the flag appear on the message in the other
|
||||
mailbox?
|
||||
|
||||
Arnt
|
||||
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
MBOX-Line: From jguthrie at brokersys.com Wed Mar 8 08:30:57 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Jonathan Guthrie <jguthrie@brokersys.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Strange behavior of Dwarf IMAP
|
||||
In-Reply-To: <c5f4fa80-5df3-b937-6039-757128711c2a@comaxis.com>
|
||||
References: <c5f4fa80-5df3-b937-6039-757128711c2a@comaxis.com>
|
||||
Message-ID: <7e831cbb-da19-6e45-5990-1c8a641bb00c@brokersys.com>
|
||||
|
||||
It doesn't appear to be part of Gnome, that is it doesn't appear to be
|
||||
part of the Gnome desktop environment, but rather a commercial Slovakian
|
||||
enterprise called "Gnome ltd". It also appears that the latest version
|
||||
is 5 years old, with no known defects or similar in their documentation
|
||||
page.
|
||||
|
||||
With that said, it looks like an error to me. You can't get the source
|
||||
code without jumping through hoops, so I can't look at it to see what
|
||||
it's doing. At least, I'm not willing to jump through the hoops.
|
||||
|
||||
On 3/7/2017 6:44 PM, Jeff McKay wrote:
|
||||
> I am dealing with a customer's IMAP server, which identifies itself as
|
||||
> Dwarf 2.0.0 (part of Gnome I guess) that seems to be acting
|
||||
> strangely. My code sends this command:
|
||||
>
|
||||
> A746 FETCH 1 (FLAGS UID INTERNALDATE BODY.PEEK[])
|
||||
>
|
||||
> I expect to get back a single message, however after the last line of
|
||||
> the first message, I then get the line:
|
||||
>
|
||||
> * 2 FETCH (FLAGS (\Seen) UID 2290456508 INTERNALDATE "20-Jan-2017
|
||||
> 07:55:29 -0500" BODY[] {76009}
|
||||
>
|
||||
> and on and on... In other words it just keeps blasting messages at
|
||||
> me, beyond the single message I asked for. I've never seen this
|
||||
> behavior before with any other server. At first I thought it was some
|
||||
> screw up in my lower level tcp code, but I am quite certain that
|
||||
> I never sent out a FETCH 2 command, so how could I be getting message
|
||||
> 2, 3, etc.?
|
||||
>
|
||||
> _______________________________________________
|
||||
> Imap-protocol mailing list
|
||||
> Imap-protocol@u.washington.edu
|
||||
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
MBOX-Line: From gds at chartertn.net Sat Feb 18 13:51:55 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 SELECT required before FETCH to detect new mail?
|
||||
Message-ID: <bb8d0ae1-dda0-dbce-186a-2a668946ec7b@chartertn.net>
|
||||
|
||||
I have been seeing a problem with mozilla Thunderbird client when using
|
||||
the charter.net imap server. When thunderbird checks for new messages it
|
||||
just does a FETCH since the inbox was already SELECTed at startup. It
|
||||
does not detect new messages unless another mailbox is SELECTed and
|
||||
inbox is re-SELECTED and then FETCHed. I think thunderbird is following
|
||||
the IMAP spec but charter.net server is not since it requires a
|
||||
re-SELECT on and already selected mailbox to signal new email. Am I right?
|
||||
|
||||
-gene
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
MBOX-Line: From gds at chartertn.net Mon Oct 9 13:41:24 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: <d0bd4b95-90bb-4fae-937e-f4ad0c2ebd09@gulbrandsen.priv.no>
|
||||
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>
|
||||
Message-ID: <5dff705c-130c-ac73-fae4-b5ba1b9b0cc2@chartertn.net>
|
||||
|
||||
On 10/9/17 10:39 AM, Arnt Gulbrandsen wrote:
|
||||
> Gene Smith writes:
|
||||
>> Yes, for other IMAP servers I have tested, if I copy message "A" 10
|
||||
>> times into Inbox I see 10 identical copies of message A in Inbox. For
|
||||
>> this openwave server, I see only 1 (and uid fetch 1:* (FLAGS) shows
|
||||
>> only 1).
|
||||
>
|
||||
> Have you tested with gmail?
|
||||
|
||||
Just tried gmail and and if I copy a message multiple times there
|
||||
remains only one copy of the message in the destination folder. I
|
||||
haven't looked at the imap transactions to to see what is actually
|
||||
happening.
|
||||
|
||||
With imap.outlook.com it does allow multiple duplicate messages to be
|
||||
copied in so I assume it is assigning new and higher UID to each duplicate.
|
||||
|
||||
imap.yahoo seems different. When I copy in a duplicate, at the
|
||||
destination folder that message seems to disappear in my client for
|
||||
about 1/2 second or so and then come back. I did look at the imap
|
||||
transaction for yahoo to see what is happening. Yahoo is assigning a new
|
||||
and higher UID each time the duplicate message is copied to a
|
||||
destination but it seems to be silently expunging the previous UID for
|
||||
the message. I see nothing being "stored", such as \deleted, to the
|
||||
message's previous UID and I see no expunge responses. As multiple
|
||||
duplicate copies occur, the gap between the highest UID and the next to
|
||||
highest UID grows (based on uid fetch 1, *).
|
||||
|
||||
Zimbra and mDaemon allow multiple duplicates to be copied in like
|
||||
outlook. Haven't looked at transaction details.
|
||||
|
||||
>
|
||||
> The server doesn't seem to reuse a UID, if I understand you correctly.
|
||||
> The message has a UID before the COPY command and nothing changes. The
|
||||
> UID is in continuous use for a particular message, so there's no reuse
|
||||
> going on, and the ban on reuse does not apply.
|
||||
|
||||
Yes, in the mbox where the message was deleted, its UID is still present
|
||||
but with the \deleted flag set. The same message but with a different
|
||||
UID is in Trash. When I try to copy it back to the original mbox from
|
||||
Trash, the server indicates that it is copying it to the original UID
|
||||
(not >= UIDNEXT). The main problem I see is that this copy doesn't clear
|
||||
the \deleted flag for the UID in the original folder so the message
|
||||
remain invisible in the client.
|
||||
|
||||
>
|
||||
> Can you find out whether flags apply to the message or to references?
|
||||
> Ie. if you copy a message into two mailboxes and set flag "foobar" on
|
||||
> the message in one mailbox, does the flag appear on the message in the
|
||||
> other mailbox?
|
||||
|
||||
Actually, this is what happens when I delete a message from openwave
|
||||
server. In the original folder the message's UID gets marked with
|
||||
\deleted flag and the message is not expunged. In the Trash folder where
|
||||
the client copies it on delete, the \deleted flag is *not* set. So the
|
||||
exact same message resides in two folders with differing flags.
|
||||
|
||||
As an additional test on openwave, I copied a message from Inbox to two
|
||||
different folders. In one folder I set several attributes (Important,
|
||||
Starred, Junk, Unread). In the other folder these flags don't appear for
|
||||
the exact same message. I then copied the this highly-flagged message
|
||||
back to Inbox attempting to overwrite the original. These attributes did
|
||||
not appear in the original message in Inbox.
|
||||
|
||||
>
|
||||
> Arnt
|
||||
>
|
||||
> _______________________________________________
|
||||
> Imap-protocol mailing list
|
||||
> Imap-protocol@u.washington.edu
|
||||
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
||||
|
||||
|
|
@ -0,0 +1,45 @@
|
|||
MBOX-Line: From gilles.lamiral at laposte.net Wed Mar 8 11:01:21 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Gilles LAMIRAL <gilles.lamiral@laposte.net>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Gmail - OAUTH2 - failures since Feb 23
|
||||
In-Reply-To: <CABa8R6tF-pTrGrs_oisvsxq8ewnwarA5fmaZGum2T2EO7AFgqw@mail.gmail.com>
|
||||
References: <CAN7dqjB3uUeos7hEA0A5Kiad1VZT4JY=8y2t_ig_L+YzGXu5ug@mail.gmail.com>
|
||||
<alpine.DEB.2.11.1702241225170.23062@grey.csi.cam.ac.uk>
|
||||
<CABa8R6tF-pTrGrs_oisvsxq8ewnwarA5fmaZGum2T2EO7AFgqw@mail.gmail.com>
|
||||
Message-ID: <5a39008c-b64b-5a0e-bffb-1163d76aa6cc@laposte.net>
|
||||
|
||||
Hi all,
|
||||
|
||||
Isn't it the last Apache patch that now disallow "broken" (not strict RFC7230 compliant)
|
||||
http clients that still use \n instead of \r\n as end of lines?
|
||||
|
||||
Using only \n now generates an Apache (2.2) 400 HTTP error, it looks like some
|
||||
sort of error code mapping with what described Kostya Vasilyev:
|
||||
"using this token to log into Gmail would get "status code 400,
|
||||
bad request" from Gmail's IMAP and SMTP servers."
|
||||
|
||||
I saw this happening in Debian last apache 2.2 patch:
|
||||
https://tracker.debian.org/news/839792
|
||||
* Security: CVE-2016-8743:
|
||||
Enforce HTTP request grammar corresponding to RFC7230 for request lines
|
||||
and request headers, to prevent response splitting and cache pollution by
|
||||
malicious clients or downstream proxies.
|
||||
* The stricter HTTP enforcement may cause compatibility problems with
|
||||
non-conforming clients. Fine-tuning is possible with the new
|
||||
HttpProtocolOptions directive.
|
||||
|
||||
It's not strictly imap related but it shows again that http is almost everywhere now.
|
||||
|
||||
Le 24/02/2017 ? 17:55, Brandon Long a ?crit :
|
||||
> https://twitter.com/Google/status/834993667911737345
|
||||
>
|
||||
> We had some issues with account login yesterday for oauth, it should all be resolved now.
|
||||
>
|
||||
|
||||
--
|
||||
Au revoir,
|
||||
Gilles Lamiral. France, Baulon (35580)
|
||||
mob 06 19 22 03 54
|
||||
tel 09 51 84 42 42
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
MBOX-Line: From blong at google.com Sat Feb 18 14:00:05 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Brandon Long <blong@google.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Is SELECT required before FETCH to detect new
|
||||
mail?
|
||||
In-Reply-To: <bb8d0ae1-dda0-dbce-186a-2a668946ec7b@chartertn.net>
|
||||
References: <bb8d0ae1-dda0-dbce-186a-2a668946ec7b@chartertn.net>
|
||||
Message-ID: <CABa8R6tLdckvJ9c-UHHijbvJ95fBGBN41fxhypO1yWzt0tGOMQ@mail.gmail.com>
|
||||
|
||||
Didn't the old UW IMAP server act that way with certain mailbox formats?
|
||||
It locked the mailbox and it couldn't receive new mail.
|
||||
|
||||
In any case, I don't think the spec precludes implementing it that way, but
|
||||
it's certainly not the normal implemention.
|
||||
|
||||
Brandon
|
||||
|
||||
On Feb 18, 2017 1:52 PM, "Gene Smith" <gds@chartertn.net> wrote:
|
||||
|
||||
> I have been seeing a problem with mozilla Thunderbird client when using
|
||||
> the charter.net imap server. When thunderbird checks for new messages it
|
||||
> just does a FETCH since the inbox was already SELECTed at startup. It does
|
||||
> not detect new messages unless another mailbox is SELECTed and inbox is
|
||||
> re-SELECTED and then FETCHed. I think thunderbird is following the IMAP
|
||||
> spec but charter.net server is not since it requires a re-SELECT on and
|
||||
> already selected mailbox to signal new email. Am I right?
|
||||
>
|
||||
> -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/20170218/2fba8ecf/attachment.html>
|
|
@ -0,0 +1,37 @@
|
|||
MBOX-Line: From comicpilsen at gmail.com Wed Dec 28 04:36:42 2016
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: comicpilsen <comicpilsen@gmail.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] is IMAP still the protocol to use to read emails???
|
||||
Message-ID: <7b8b6e00-3396-2c08-f58e-290d619214ea@gmail.com>
|
||||
|
||||
I am a little confused. I code in Python ( 3.5.1) and I am "trying" to read the body of
|
||||
messages from a gmail account. The issue is that I see a lot of POP3 activity on stack
|
||||
exchange and google but very little for IMAP. So is IMAP dead? If so what should I be
|
||||
looking at?
|
||||
|
||||
All I want to do is read in my email body and do something with it. I really am having
|
||||
issues like the one below.
|
||||
|
||||
Using python 3.5.1 and its throwing this trace
|
||||
|
||||
|TypeError:initial_value must be str orNone,notbytes|
|
||||
|
||||
on the line
|
||||
|
||||
|text_msg =email.message_from_string(data[0][1])|
|
||||
|
||||
I know the text of the message is stashed in data[0][1] but can't seem to find the correct
|
||||
code to convert from bytes to string for the RFC822 in python 3.5.1 what is the line
|
||||
please? here is the code I found to read my IMAP box which works well for getting the
|
||||
messages, formatting the date and showing the subject.
|
||||
|
||||
|rv,data =M.fetch(num,'(RFC822)')ifrv !='OK':print("ERROR getting message",num)returnmsg
|
||||
=email.message_from_bytes(data[0][1])text_msg
|
||||
=email.message_from_string(data[0][1])hdr=mail.header.make_header(email.header.decode_header(msg['Subject']))subject
|
||||
=str(hdr)print('Message %s: %s'%(num,subject))print("text = ",text_msg)|
|
||||
|
||||
|
||||
-------------- next part --------------
|
||||
An HTML attachment was scrubbed...
|
||||
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20161228/83f781fd/attachment.html>
|
|
@ -0,0 +1,38 @@
|
|||
MBOX-Line: From davew at hireahit.com Mon Oct 9 14:32:32 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Dave Warren <davew@hireahit.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Is server re-use of UID OK?
|
||||
In-Reply-To: <5dff705c-130c-ac73-fae4-b5ba1b9b0cc2@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>
|
||||
<5dff705c-130c-ac73-fae4-b5ba1b9b0cc2@chartertn.net>
|
||||
Message-ID: <1611d170-ea34-1adf-8cd6-090e571cf12c@hireahit.com>
|
||||
|
||||
On 2017-10-09 14:41, Gene Smith wrote:
|
||||
> Yes, in the mbox where the message was deleted, its UID is still present
|
||||
> but with the \deleted flag set. The same message but with a different
|
||||
> UID is in Trash. When I try to copy it back to the original mbox from
|
||||
> Trash, the server indicates that it is copying it to the original UID
|
||||
> (not >= UIDNEXT). The main problem I see is that this copy doesn't clear
|
||||
> the \deleted flag for the UID in the original folder so the message
|
||||
> remain invisible in the client.
|
||||
|
||||
I think it might reduce confusion if we stop saying "Message was
|
||||
deleted". "Deleted" doesn't have a clear definition in this context
|
||||
because it isn't really a thing in IMAP (although it is how IMAP clients
|
||||
present multiple different behaviours to users). At the protocol level,
|
||||
you can set the \Deleted flag or you can EXPUNGE.
|
||||
|
||||
Since a \Deleted flag can be trivially removed, there is no "reuse" of a
|
||||
UID, the UID was still being reused and the COPY was just returning an
|
||||
accurate (if unusual) result. Expunging and then reusing the UID
|
||||
(assuming an unchanged UIDVALIDITY) would be a very significant problem
|
||||
with regards to clients maintaining the validity of their caches, but
|
||||
simply changing a flag is perfectly valid.
|
||||
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
MBOX-Line: From blong at google.com Wed Mar 8 11:07:13 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Brandon Long <blong@google.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Strange behavior of Dwarf IMAP
|
||||
In-Reply-To: <7e831cbb-da19-6e45-5990-1c8a641bb00c@brokersys.com>
|
||||
References: <c5f4fa80-5df3-b937-6039-757128711c2a@comaxis.com>
|
||||
<7e831cbb-da19-6e45-5990-1c8a641bb00c@brokersys.com>
|
||||
Message-ID: <CABa8R6sBy8R8t0ZObq4ONz1XWzvGHOTL4_v1sGAbPfHoQQDerw@mail.gmail.com>
|
||||
|
||||
Is technically in spec, as in they can send as many untagged fetch
|
||||
responses as they want.
|
||||
|
||||
Probably not what they intended or anyone wants, though.
|
||||
|
||||
Brandon
|
||||
|
||||
On Mar 8, 2017 8:31 AM, "Jonathan Guthrie" <jguthrie@brokersys.com> wrote:
|
||||
|
||||
> It doesn't appear to be part of Gnome, that is it doesn't appear to be
|
||||
> part of the Gnome desktop environment, but rather a commercial Slovakian
|
||||
> enterprise called "Gnome ltd". It also appears that the latest version is
|
||||
> 5 years old, with no known defects or similar in their documentation page.
|
||||
>
|
||||
> With that said, it looks like an error to me. You can't get the source
|
||||
> code without jumping through hoops, so I can't look at it to see what it's
|
||||
> doing. At least, I'm not willing to jump through the hoops.
|
||||
>
|
||||
> On 3/7/2017 6:44 PM, Jeff McKay wrote:
|
||||
>
|
||||
>> I am dealing with a customer's IMAP server, which identifies itself as
|
||||
>> Dwarf 2.0.0 (part of Gnome I guess) that seems to be acting
|
||||
>> strangely. My code sends this command:
|
||||
>>
|
||||
>> A746 FETCH 1 (FLAGS UID INTERNALDATE BODY.PEEK[])
|
||||
>>
|
||||
>> I expect to get back a single message, however after the last line of the
|
||||
>> first message, I then get the line:
|
||||
>>
|
||||
>> * 2 FETCH (FLAGS (\Seen) UID 2290456508 INTERNALDATE "20-Jan-2017
|
||||
>> 07:55:29 -0500" BODY[] {76009}
|
||||
>>
|
||||
>> and on and on... In other words it just keeps blasting messages at me,
|
||||
>> beyond the single message I asked for. I've never seen this
|
||||
>> behavior before with any other server. At first I thought it was some
|
||||
>> screw up in my lower level tcp code, but I am quite certain that
|
||||
>> I never sent out a FETCH 2 command, so how could I be getting message 2,
|
||||
>> 3, etc.?
|
||||
>>
|
||||
>> _______________________________________________
|
||||
>> 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
|
||||
>
|
||||
-------------- next part --------------
|
||||
An HTML attachment was scrubbed...
|
||||
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20170308/91644aeb/attachment.html>
|
|
@ -0,0 +1,57 @@
|
|||
MBOX-Line: From gds at chartertn.net Sat Feb 18 14:29:04 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 SELECT required before FETCH to detect new
|
||||
mail?
|
||||
In-Reply-To: <CABa8R6tLdckvJ9c-UHHijbvJ95fBGBN41fxhypO1yWzt0tGOMQ@mail.gmail.com>
|
||||
References: <bb8d0ae1-dda0-dbce-186a-2a668946ec7b@chartertn.net>
|
||||
<CABa8R6tLdckvJ9c-UHHijbvJ95fBGBN41fxhypO1yWzt0tGOMQ@mail.gmail.com>
|
||||
Message-ID: <3e01f804-163d-cda3-f5bb-b495fa5a1d50@chartertn.net>
|
||||
|
||||
The charter IMAP server is openwave according the login response. So are
|
||||
you saying it is OK for the IMAP server to require a new SELECT before
|
||||
doing a FETCH on an already selected mailbox for the FETCH response to
|
||||
indicate new email? If so, this is a bug in thunderbird.
|
||||
|
||||
I have noticed that at least one client (kmail) always does SELECT and
|
||||
FETCH when checking for new mail (even when inbox is already selected).
|
||||
However, thunderbird and claws-mail only do a FETCH and don't re-do the
|
||||
SELECT and, therefore, don't detect new mail unless another folder is
|
||||
looked at first and then inbox is returned to.
|
||||
|
||||
-gene
|
||||
|
||||
On 02/18/2017 05:00 PM, Brandon Long wrote:
|
||||
> Didn't the old UW IMAP server act that way with certain mailbox
|
||||
> formats? It locked the mailbox and it couldn't receive new mail.
|
||||
>
|
||||
> In any case, I don't think the spec precludes implementing it that
|
||||
> way, but it's certainly not the normal implemention.
|
||||
>
|
||||
> Brandon
|
||||
>
|
||||
> On Feb 18, 2017 1:52 PM, "Gene Smith" <gds@chartertn.net
|
||||
> <mailto:gds@chartertn.net>> wrote:
|
||||
>
|
||||
> I have been seeing a problem with mozilla Thunderbird client when
|
||||
> using the charter.net <http://charter.net> imap server. When
|
||||
> thunderbird checks for new messages it just does a FETCH since the
|
||||
> inbox was already SELECTed at startup. It does not detect new
|
||||
> messages unless another mailbox is SELECTed and inbox is
|
||||
> re-SELECTED and then FETCHed. I think thunderbird is following the
|
||||
> IMAP spec but charter.net <http://charter.net> server is not since
|
||||
> it requires a re-SELECT on and already selected mailbox to signal
|
||||
> new email. Am I right?
|
||||
>
|
||||
> -gene
|
||||
> _______________________________________________
|
||||
> Imap-protocol mailing list
|
||||
> Imap-protocol@u.washington.edu <mailto:Imap-protocol@u.washington.edu>
|
||||
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
||||
> <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/20170218/398e1ecc/attachment.html>
|
|
@ -0,0 +1,71 @@
|
|||
MBOX-Line: From blong at google.com Wed Dec 28 08:02:07 2016
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Brandon Long <blong@google.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] is IMAP still the protocol to use to read
|
||||
emails???
|
||||
In-Reply-To: <7b8b6e00-3396-2c08-f58e-290d619214ea@gmail.com>
|
||||
References: <7b8b6e00-3396-2c08-f58e-290d619214ea@gmail.com>
|
||||
Message-ID: <CABa8R6t-+S4R7V=4eK8_A+8HLFcUqHLF=ncsToz_J2fi_kK5NA@mail.gmail.com>
|
||||
|
||||
this is a Python 3 thing, you need to call decode on the bytes to get a
|
||||
string.
|
||||
|
||||
The IMAP spec would say that the bytes returned are ASCII, but we return
|
||||
the raw message as is, which may include 8bit characters. In general, the
|
||||
8bit characters are mostly in utf8, but could be in latin1 or other
|
||||
non-embedded null encodings.
|
||||
|
||||
So, the simplest is to assume utf8, the most correct would be to use some
|
||||
code to guess the encoding.
|
||||
|
||||
strb = bodybytes.decode('utf-8')
|
||||
|
||||
On Dec 28, 2016 4:37 AM, "comicpilsen" <comicpilsen@gmail.com> wrote:
|
||||
|
||||
> I am a little confused. I code in Python ( 3.5.1) and I am "trying" to
|
||||
> read the body of messages from a gmail account. The issue is that I see a
|
||||
> lot of POP3 activity on stack exchange and google but very little for IMAP.
|
||||
> So is IMAP dead? If so what should I be looking at?
|
||||
>
|
||||
> All I want to do is read in my email body and do something with it. I
|
||||
> really am having issues like the one below.
|
||||
>
|
||||
> Using python 3.5.1 and its throwing this trace
|
||||
>
|
||||
> TypeError: initial_value must be str or None, not bytes
|
||||
>
|
||||
> on the line
|
||||
>
|
||||
> text_msg = email.message_from_string(data[0][1])
|
||||
>
|
||||
> I know the text of the message is stashed in data[0][1] but can't seem to
|
||||
> find the correct code to convert from bytes to string for the RFC822 in
|
||||
> python 3.5.1 what is the line please? here is the code I found to read my
|
||||
> IMAP box which works well for getting the messages, formatting the date and
|
||||
> showing the subject.
|
||||
>
|
||||
> rv, data = M.fetch(num, '(RFC822)')
|
||||
> if rv != 'OK':
|
||||
> print("ERROR getting message", num)
|
||||
> return
|
||||
> msg = email.message_from_bytes(data[0][1])
|
||||
>
|
||||
> text_msg = email.message_from_string(data[0][1])
|
||||
>
|
||||
> hdr=mail.header.make_header(email.header.decode_header(msg['Subject']))
|
||||
> subject = str(hdr)
|
||||
> print('Message %s: %s' % (num, subject))
|
||||
>
|
||||
> print("text = ",text_msg)
|
||||
>
|
||||
>
|
||||
>
|
||||
> _______________________________________________
|
||||
> 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/20161228/faf35273/attachment.html>
|
|
@ -0,0 +1,70 @@
|
|||
MBOX-Line: From osandov at osandov.com Mon Jan 25 15:15:28 2016
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Omar Sandoval <osandov@osandov.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Selected mailbox deleted by another client
|
||||
Message-ID: <20160125231528.GA21616@mew>
|
||||
|
||||
Hi,
|
||||
|
||||
While working on an IMAP client, I seem to have encountered an edge-case
|
||||
in the IMAP protocol, and I can't find any clarification elsewhere. In
|
||||
particular, I'm talking about the following scenario where two clients
|
||||
C1 and C2 are accessing the same server S:
|
||||
|
||||
C1: A002 SELECT foo
|
||||
...
|
||||
S: A002 OK [READ-WRITE] foo selected. (Success)
|
||||
C2: A002 DELETE foo
|
||||
S: A002 OK Success
|
||||
C1: A003 UID FETCH 1 ENVELOPE
|
||||
S: ???
|
||||
|
||||
That is, when C2 deletes the mailbox that C1 currently has selected,
|
||||
what happens when C1 tries to access that mailbox? There's a previous
|
||||
discussion here [1] about what should happen in the case that a client
|
||||
attempts to delete the mailbox that it has selected which briefly talks
|
||||
about the case I'm asking about here. Here's one proposal from that
|
||||
thread:
|
||||
|
||||
> Or, you can pretend the mailbox is deleted, but still allow all FETCH
|
||||
> operations, actually physically deleteing it when the last client
|
||||
> leaves the selected state on it. This is similar to the situation of
|
||||
> deleting an open file on UNIX, say - the file still exists, but has
|
||||
> no name anymore, no applications with it open can still use it, no no
|
||||
> new applications can open it.
|
||||
|
||||
I tried this out on Gmail to see what would happen and got some weird
|
||||
results:
|
||||
|
||||
C1: A003 UID FETCH 1 ENVELOPE
|
||||
S: A003 OK Success
|
||||
C1: A004 NOOP
|
||||
S: A004 OK Success
|
||||
C1: A005 UID FETCH 1 ENVELOPE
|
||||
S: A005 BAD UID FETCH not allowed now.
|
||||
|
||||
At first, Gmail seemed to be exhibiting the behavior described in my
|
||||
quote. But, inexplicably, after issuing a NOOP, the connection
|
||||
apparently left the Selected state and entered the Authenticated state.
|
||||
|
||||
I dusted off an old Yahoo mail account and got an even weirder result:
|
||||
|
||||
C1: A003 UID FETCH 1 ENVELOPE
|
||||
S: A003 OK UID FETCH completed
|
||||
C1: A004 NOOP
|
||||
S: A004 NO [SERVERBUG] NOOP Server error - Please try again later
|
||||
|
||||
I haven't actually tried it, but Dovecot apparently disconnects the
|
||||
client [2].
|
||||
|
||||
So, what's the correct behavior here? I'm a fan of the behavior I quoted
|
||||
above, and the Dovecot behavior also seems sane. Gmail's behavior seems
|
||||
utterly incorrect, however. NOOP is definitely not supposed to change
|
||||
the connection state, so this appears to be a bug. Any thoughts?
|
||||
|
||||
1: http://mailman13.u.washington.edu/mailman/htdig/imap-protocol/2005-September/000021.html
|
||||
2: http://hg.dovecot.org/dovecot-2.1/rev/81a659ab9183
|
||||
--
|
||||
Omar
|
||||
|
|
@ -0,0 +1,74 @@
|
|||
MBOX-Line: From gds at chartertn.net Mon Oct 9 15:59: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?
|
||||
In-Reply-To: <1611d170-ea34-1adf-8cd6-090e571cf12c@hireahit.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>
|
||||
<5dff705c-130c-ac73-fae4-b5ba1b9b0cc2@chartertn.net>
|
||||
<1611d170-ea34-1adf-8cd6-090e571cf12c@hireahit.com>
|
||||
Message-ID: <2e246450-3dca-0522-6cb5-72016def70a9@chartertn.net>
|
||||
|
||||
On 10/9/17 5:32 PM, Dave Warren wrote:
|
||||
>
|
||||
> I think it might reduce confusion if we stop saying "Message was
|
||||
> deleted". "Deleted" doesn't have a clear definition in this context
|
||||
> because it isn't really a thing in IMAP (although it is how IMAP clients
|
||||
> present multiple different behaviours to users). At the protocol level,
|
||||
> you can set the \Deleted flag or you can EXPUNGE.
|
||||
|
||||
OK, s/Message was deleted/Message was deleted in the client program/ :)
|
||||
|
||||
>
|
||||
> Since a \Deleted flag can be trivially removed, there is no "reuse" of a
|
||||
> UID, the UID was still being reused and the COPY was just returning an
|
||||
> accurate (if unusual) result. Expunging and then reusing the UID
|
||||
> (assuming an unchanged UIDVALIDITY) would be a very significant problem
|
||||
> with regards to clients maintaining the validity of their caches, but
|
||||
> simply changing a flag is perfectly valid.
|
||||
|
||||
Openwave has no problem if the copy destination mbox is first expunged
|
||||
or if the original UID now having the \deleted flag is expunged with
|
||||
"uid expunge <uid>" since openwave has UIDPLUS capability. In that case
|
||||
the server copies to a new UID >= UIDNEXT with \deleted not set so the
|
||||
copied-in message is visible in the client program.
|
||||
|
||||
So I think if there is a bug in the openwave server it because it
|
||||
somewhat violates this requirement for the COPY command from rfc 3501:
|
||||
|
||||
"The COPY command copies the specified message(s) to the end of the
|
||||
specified destination mailbox. The flags and internal date of the
|
||||
message(s) SHOULD be preserved, and the Recent flag SHOULD be set,
|
||||
in the copy."
|
||||
|
||||
1.The copy does not always copy messages to the "end" of specified
|
||||
destination mbox. (I don't see an explicit definition for "end" in the
|
||||
rfc but I am sure it means at UID >=UIDNEXT or at the next greater
|
||||
sequence number.)
|
||||
|
||||
2.When it does a copy to an existing and unexpunged UID not at the "end"
|
||||
it does not preserve the flag states from the source mbox/UID. Also, the
|
||||
Recent flag is not set. Of course, this is a SHOULD requirement so maybe
|
||||
there are valid reasons for not doing these that I'm not aware of.
|
||||
|
||||
-gene
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
>
|
||||
> _______________________________________________
|
||||
> Imap-protocol mailing list
|
||||
> Imap-protocol@u.washington.edu
|
||||
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
||||
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
MBOX-Line: From blong at google.com Wed Mar 8 11:10:03 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Brandon Long <blong@google.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Gmail - OAUTH2 - failures since Feb 23
|
||||
In-Reply-To: <5a39008c-b64b-5a0e-bffb-1163d76aa6cc@laposte.net>
|
||||
References: <CAN7dqjB3uUeos7hEA0A5Kiad1VZT4JY=8y2t_ig_L+YzGXu5ug@mail.gmail.com>
|
||||
<alpine.DEB.2.11.1702241225170.23062@grey.csi.cam.ac.uk>
|
||||
<CABa8R6tF-pTrGrs_oisvsxq8ewnwarA5fmaZGum2T2EO7AFgqw@mail.gmail.com>
|
||||
<5a39008c-b64b-5a0e-bffb-1163d76aa6cc@laposte.net>
|
||||
Message-ID: <CABa8R6uae0FYdM8OfM7h_Xq9waq2pYaD+L5+WRmhUCUrP9ygbQ@mail.gmail.com>
|
||||
|
||||
We don't use Apache, and the cause was quite a bit different, involving the
|
||||
storage of the token info on our side.
|
||||
|
||||
Brandon
|
||||
|
||||
On Mar 8, 2017 11:01 AM, "Gilles LAMIRAL" <gilles.lamiral@laposte.net>
|
||||
wrote:
|
||||
|
||||
> Hi all,
|
||||
>
|
||||
> Isn't it the last Apache patch that now disallow "broken" (not strict
|
||||
> RFC7230 compliant)
|
||||
> http clients that still use \n instead of \r\n as end of lines?
|
||||
>
|
||||
> Using only \n now generates an Apache (2.2) 400 HTTP error, it looks like
|
||||
> some
|
||||
> sort of error code mapping with what described Kostya Vasilyev:
|
||||
> "using this token to log into Gmail would get "status code 400,
|
||||
> bad request" from Gmail's IMAP and SMTP servers."
|
||||
>
|
||||
> I saw this happening in Debian last apache 2.2 patch:
|
||||
> https://tracker.debian.org/news/839792
|
||||
> * Security: CVE-2016-8743:
|
||||
> Enforce HTTP request grammar corresponding to RFC7230 for request
|
||||
> lines
|
||||
> and request headers, to prevent response splitting and cache
|
||||
> pollution by
|
||||
> malicious clients or downstream proxies.
|
||||
> * The stricter HTTP enforcement may cause compatibility problems with
|
||||
> non-conforming clients. Fine-tuning is possible with the new
|
||||
> HttpProtocolOptions directive.
|
||||
>
|
||||
> It's not strictly imap related but it shows again that http is almost
|
||||
> everywhere now.
|
||||
>
|
||||
> Le 24/02/2017 ? 17:55, Brandon Long a ?crit :
|
||||
>
|
||||
>> https://twitter.com/Google/status/834993667911737345
|
||||
>>
|
||||
>> We had some issues with account login yesterday for oauth, it should all
|
||||
>> be resolved now.
|
||||
>>
|
||||
>>
|
||||
> --
|
||||
> Au revoir,
|
||||
> Gilles Lamiral. France, Baulon (35580)
|
||||
> mob 06 19 22 03 54
|
||||
> tel 09 51 84 42 42
|
||||
>
|
||||
-------------- next part --------------
|
||||
An HTML attachment was scrubbed...
|
||||
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20170308/77718ec4/attachment.html>
|
|
@ -0,0 +1,67 @@
|
|||
MBOX-Line: From blong at google.com Sat Feb 18 14:36:28 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Brandon Long <blong@google.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Is SELECT required before FETCH to detect new
|
||||
mail?
|
||||
In-Reply-To: <3e01f804-163d-cda3-f5bb-b495fa5a1d50@chartertn.net>
|
||||
References: <bb8d0ae1-dda0-dbce-186a-2a668946ec7b@chartertn.net>
|
||||
<CABa8R6tLdckvJ9c-UHHijbvJ95fBGBN41fxhypO1yWzt0tGOMQ@mail.gmail.com>
|
||||
<3e01f804-163d-cda3-f5bb-b495fa5a1d50@chartertn.net>
|
||||
Message-ID: <CABa8R6tSevQ7kda5usVW-DuKO68Kdukgf7USZ=eTCWpvY-Nobw@mail.gmail.com>
|
||||
|
||||
You shouldn't have to reselect, and doing so is really inefficient on some
|
||||
servers, so I wouldn't recommend it as the default mechanism.
|
||||
|
||||
Seems like for this server there is no benefit to keeping the connection
|
||||
open.
|
||||
|
||||
I would consider a modern server which does this as pretty broken, but it
|
||||
may not violate the spec.
|
||||
|
||||
On Feb 18, 2017 2:29 PM, "Gene Smith" <gds@chartertn.net> wrote:
|
||||
|
||||
> The charter IMAP server is openwave according the login response. So are
|
||||
> you saying it is OK for the IMAP server to require a new SELECT before
|
||||
> doing a FETCH on an already selected mailbox for the FETCH response to
|
||||
> indicate new email? If so, this is a bug in thunderbird.
|
||||
>
|
||||
> I have noticed that at least one client (kmail) always does SELECT and
|
||||
> FETCH when checking for new mail (even when inbox is already selected).
|
||||
> However, thunderbird and claws-mail only do a FETCH and don't re-do the
|
||||
> SELECT and, therefore, don't detect new mail unless another folder is
|
||||
> looked at first and then inbox is returned to.
|
||||
>
|
||||
> -gene
|
||||
>
|
||||
> On 02/18/2017 05:00 PM, Brandon Long wrote:
|
||||
>
|
||||
> Didn't the old UW IMAP server act that way with certain mailbox formats?
|
||||
> It locked the mailbox and it couldn't receive new mail.
|
||||
>
|
||||
> In any case, I don't think the spec precludes implementing it that way,
|
||||
> but it's certainly not the normal implemention.
|
||||
>
|
||||
> Brandon
|
||||
>
|
||||
> On Feb 18, 2017 1:52 PM, "Gene Smith" <gds@chartertn.net> wrote:
|
||||
>
|
||||
>> I have been seeing a problem with mozilla Thunderbird client when using
|
||||
>> the charter.net imap server. When thunderbird checks for new messages it
|
||||
>> just does a FETCH since the inbox was already SELECTed at startup. It does
|
||||
>> not detect new messages unless another mailbox is SELECTed and inbox is
|
||||
>> re-SELECTED and then FETCHed. I think thunderbird is following the IMAP
|
||||
>> spec but charter.net server is not since it requires a re-SELECT on and
|
||||
>> already selected mailbox to signal new email. Am I right?
|
||||
>>
|
||||
>> -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/20170218/c54cf5e9/attachment.html>
|
|
@ -0,0 +1,31 @@
|
|||
MBOX-Line: From johnl-imap at iecc.com Wed Dec 28 08:13:05 2016
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: John Levine <johnl-imap@iecc.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] is IMAP still the protocol to use to read
|
||||
emails???
|
||||
In-Reply-To: <7b8b6e00-3396-2c08-f58e-290d619214ea@gmail.com>
|
||||
Message-ID: <20161228161305.29711.qmail@ary.lan>
|
||||
|
||||
In article <7b8b6e00-3396-2c08-f58e-290d619214ea@gmail.com> you write:
|
||||
>I am a little confused. I code in Python ( 3.5.1) and I am "trying" to read the body of
|
||||
>messages from a gmail account. The issue is that I see a lot of POP3 activity on stack
|
||||
>exchange and google but very little for IMAP. So is IMAP dead? If so what should I be
|
||||
>looking at?
|
||||
|
||||
IMAP is very much alive. Approximately every smartphone in the world uses it to
|
||||
handle their users' email accounts.
|
||||
|
||||
The reason you see so much more about POP3 is that POP is about 1/100 as complex
|
||||
as IMAP, so if can do what you want, it's much easier to use.
|
||||
|
||||
>All I want to do is read in my email body and do something with it. I really am having
|
||||
>issues like the one below.
|
||||
|
||||
I've found that the third party python imapclient library is a lot
|
||||
easier to use than the standard imaplib. It deals with many of the
|
||||
datatype strangenesses you've been running into.
|
||||
|
||||
R's,
|
||||
John
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
MBOX-Line: From brong at fastmail.fm Mon Jan 25 15:41:35 2016
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Bron Gondwana <brong@fastmail.fm>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Selected mailbox deleted by another client
|
||||
In-Reply-To: <20160125231528.GA21616@mew>
|
||||
References: <20160125231528.GA21616@mew>
|
||||
Message-ID: <1453765295.487330.502398698.1C26076F@webmail.messagingengine.com>
|
||||
|
||||
On Tue, Jan 26, 2016, at 10:15, Omar Sandoval wrote:
|
||||
> I haven't actually tried it, but Dovecot apparently disconnects the
|
||||
> client [2].
|
||||
>
|
||||
> So, what's the correct behavior here? I'm a fan of the behavior I quoted
|
||||
> above, and the Dovecot behavior also seems sane. Gmail's behavior seems
|
||||
> utterly incorrect, however. NOOP is definitely not supposed to change
|
||||
> the connection state, so this appears to be a bug. Any thoughts?
|
||||
|
||||
Cyrus has a switch called 'disconnect_on_vanished_mailbox' which gives
|
||||
the same behaviour as Dovecot. It defaults to off, but my testing just now
|
||||
showed an immediate disconnect without even running the NOOP when I
|
||||
ran the command, so I'll be investigating that (and adding a test case to
|
||||
our testing framework)
|
||||
|
||||
Thanks for bringing this up :)
|
||||
|
||||
What Cyrus is supposed to do is to issue an EXPUNGE for every existing
|
||||
message (or a VANISHED if QRESYNC is turned on) and then a NO in
|
||||
response to the command. You would remain "selected" though.
|
||||
|
||||
I guess you could return:
|
||||
|
||||
<tag> NO [CLOSED] Mailbox no longer exists
|
||||
|
||||
If QRESYNC is enabled...
|
||||
|
||||
https://tools.ietf.org/html/rfc5162#section-3.7
|
||||
|
||||
Another possible thing (and what Cyrus IMAP used to do for a little while
|
||||
in the 2.4 series when I added long-lived index locks) is to say
|
||||
"NO Mailbox is locked" to the session which tries to delete an open
|
||||
mailbox. This was bad because the situation actually occurs quite often
|
||||
in practice that someone's phone or desktop is sitting there with a mailbox
|
||||
open for hours or days just NOOPing away.
|
||||
|
||||
Bron.
|
||||
|
||||
--
|
||||
Bron Gondwana
|
||||
brong@fastmail.fm
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
MBOX-Line: From gullo at m4ss.net Wed Dec 23 08:51:22 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Davide Gullo <gullo@m4ss.net>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] UID fetch command error on Gmail servers
|
||||
Message-ID: <CANVPb6u2nUYoi3+U7hhj17YiN-bNXKiHV3xRmUTyLckxu4WXaA@mail.gmail.com>
|
||||
|
||||
Hello,
|
||||
someone can help me to understand what exactly could be wrong in this UID
|
||||
fetch command?
|
||||
|
||||
I receive an error from Gmail server:
|
||||
|
||||
12/12/15, 10:06 PM >>> >>>>>>> send >>>>>>
|
||||
12/12/15, 10:06 PM >>> *103 UID FETCH 829907:830028 (UID X-GM-MSGID FLAGS
|
||||
RFC822.SIZE ENVELOPE BODY.PEEK[HEADER.FIELDS (References)] BODYSTRUCTURE
|
||||
RFC822)*
|
||||
12/12/15, 10:06 PM >>> >>>>>>> end send >>>>>>
|
||||
12/12/15, 10:06 PM <<< <<<<<<< read <<<<<<
|
||||
12/12/15, 10:06 PM <<< 103 NO *System Error (Failure)*
|
||||
12/12/15, 10:06 PM <<< <<<<<<< end read <<<<<<
|
||||
12/12/15, 10:06 PM messagesFullFrom: NIL - ERROR: Error Domain=mailcore
|
||||
Code=24 "*UID fetch command error*" UserInfo={NSLocalizedDescription=UID
|
||||
fetch command error}
|
||||
|
||||
Thank you very much!
|
||||
|
||||
|
||||
--
|
||||
Davide Gullo
|
||||
-------------- next part --------------
|
||||
An HTML attachment was scrubbed...
|
||||
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20151223/b3a4fb5a/attachment.html>
|
|
@ -0,0 +1,67 @@
|
|||
MBOX-Line: From blong at google.com Mon Oct 9 16:30:33 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Brandon Long <blong@google.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Is server re-use of UID OK?
|
||||
In-Reply-To: <d0bd4b95-90bb-4fae-937e-f4ad0c2ebd09@gulbrandsen.priv.no>
|
||||
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>
|
||||
Message-ID: <CABa8R6ucJXxUp9kAQ+_fDvtEAwmAYtJ6Hmr60J5=SW48SLvmig@mail.gmail.com>
|
||||
|
||||
On Mon, Oct 9, 2017 at 7:39 AM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
|
||||
wrote:
|
||||
|
||||
> Gene Smith writes:
|
||||
>
|
||||
>> Yes, for other IMAP servers I have tested, if I copy message "A" 10 times
|
||||
>> into Inbox I see 10 identical copies of message A in Inbox. For this
|
||||
>> openwave server, I see only 1 (and uid fetch 1:* (FLAGS) shows only 1).
|
||||
>>
|
||||
>
|
||||
> Have you tested with gmail?
|
||||
|
||||
|
||||
Since Gmail considers a COPY operation as an "add label" operation, it's
|
||||
usually a no-op if the message already has that label, which is what would
|
||||
happen in this case.
|
||||
|
||||
There are cases where Gmail does "reassign UID" on a COPY, ie it bumps the
|
||||
UID of a message to the UIDNEXT. It does this if the user is calling COPY
|
||||
with a source/target folder that are the same, on the assumption that the
|
||||
user is trying to make an actual copy of the message in the same folder.
|
||||
Clients doing this tend to be confused if the message isn't the latest UID
|
||||
in that case. We also reassign UIDs when messages are moved to/from the
|
||||
spam/trash folders, for similar reasons. (Note that APPEND always bumps
|
||||
the UID when it detects an attempt to APPEND a duplicate message for
|
||||
similar reasons to the COPY to the same folder)
|
||||
|
||||
Most IMAP flags are also implemented as labels, and so are consistent
|
||||
across all "copies" of a message. The exception is \Deleted, so doing
|
||||
something like a COPY/Deleted as a MOVE operation without an EXPUNGE and
|
||||
then doing it back will leave both "copies" with a \Deleted flag and both
|
||||
will be removed with EXPUNGE. That said, the default is for the user to be
|
||||
in auto-expunge mode, in which case storing a \Deleted flag will result in
|
||||
the message being EXPUNGED (that label removed) at the next sync point.
|
||||
|
||||
IE, from the given example:
|
||||
C: aaa UID COPY 1267 "Mbox"
|
||||
S: aaa OK [COPYUID 123456789 1267 1007] UID COPY completed
|
||||
C: bbb UID store 1267 +Flags (\Deleted)
|
||||
|
||||
The UID store is a sync point, so the message will be auto-expunged at this
|
||||
point, so the COPY back will get a new UID.
|
||||
|
||||
You'd need to change the user using the advanced IMAP options to a
|
||||
different deletion mode to see the UID maintained.
|
||||
|
||||
Also, Gmail offers the MOVE extension, so you should really use that
|
||||
instead of COPY\Deleted\EXPUNGE.
|
||||
|
||||
Brandon
|
||||
-------------- next part --------------
|
||||
An HTML attachment was scrubbed...
|
||||
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20171009/ea8f1474/attachment.html>
|
|
@ -0,0 +1,24 @@
|
|||
MBOX-Line: From andris.reinman at gmail.com Fri Mar 10 13:42:09 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] What is the current consensus on the Recent flag?
|
||||
Message-ID: <CAPacwgx6aqYdp01-CA0k_saiYmLmCFOizs3TNg4R_PJcMt0WpA@mail.gmail.com>
|
||||
|
||||
Hi all,
|
||||
|
||||
I'm building a new open source IMAP server (
|
||||
https://github.com/wildduck-email/wildduck) and was wondering about the
|
||||
\Recent flag. Is it even needed today? I would like to keep my server as
|
||||
standards compliant as possible but the ephemeral nature of \Recent makes
|
||||
it a bit difficult to sync between sessions in multiple hosts. It would be
|
||||
doable but the complexity needed does not make it seem worth it.
|
||||
|
||||
Is there even any major client using this flag in a sane way? I don't think
|
||||
I have even ever encountered it outside the RFCs.
|
||||
|
||||
Best regards,
|
||||
Andris Reinman
|
||||
-------------- next part --------------
|
||||
An HTML attachment was scrubbed...
|
||||
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20170310/03ef6d99/attachment.html>
|
|
@ -0,0 +1,114 @@
|
|||
MBOX-Line: From brong at fastmail.fm Sat Feb 18 14:44:11 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Bron Gondwana <brong@fastmail.fm>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Is SELECT required before FETCH to detect new
|
||||
mail?
|
||||
In-Reply-To: <CABa8R6tSevQ7kda5usVW-DuKO68Kdukgf7USZ=eTCWpvY-Nobw@mail.gmail.com>
|
||||
References: <bb8d0ae1-dda0-dbce-186a-2a668946ec7b@chartertn.net>
|
||||
<CABa8R6tLdckvJ9c-UHHijbvJ95fBGBN41fxhypO1yWzt0tGOMQ@mail.gmail.com>
|
||||
<3e01f804-163d-cda3-f5bb-b495fa5a1d50@chartertn.net>
|
||||
<CABa8R6tSevQ7kda5usVW-DuKO68Kdukgf7USZ=eTCWpvY-Nobw@mail.gmail.com>
|
||||
Message-ID: <1487457851.3495664.885450568.157A4E2A@webmail.messagingengine.com>
|
||||
|
||||
Surely a noop should work to cause an update?
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
On Sun, 19 Feb 2017, at 09:36, Brandon Long wrote:
|
||||
|
||||
> You shouldn't have to reselect, and doing so is really inefficient on
|
||||
> some servers, so I wouldn't recommend it as the default mechanism.
|
||||
>
|
||||
|
||||
> Seems like for this server there is no benefit to keeping the
|
||||
> connection open.
|
||||
>
|
||||
|
||||
> I would consider a modern server which does this as pretty broken, but
|
||||
> it may not violate the spec.
|
||||
>
|
||||
|
||||
> On Feb 18, 2017 2:29 PM, "Gene Smith" <gds@chartertn.net> wrote:
|
||||
|
||||
>> The charter IMAP server is openwave according the login response. So
|
||||
>> are you saying it is OK for the IMAP server to require a new SELECT
|
||||
>> before doing a FETCH on an already selected mailbox for the FETCH
|
||||
>> response to indicate new email? If so, this is a bug in thunderbird.
|
||||
>>
|
||||
|
||||
>> I have noticed that at least one client (kmail) always does SELECT
|
||||
>> and FETCH when checking for new mail (even when inbox is already
|
||||
>> selected). However, thunderbird and claws-mail only do a FETCH and
|
||||
>> don't re-do the SELECT and, therefore, don't detect new mail unless
|
||||
>> another folder is looked at first and then inbox is returned to.
|
||||
>>
|
||||
|
||||
>> -gene
|
||||
|
||||
>>
|
||||
|
||||
>> On 02/18/2017 05:00 PM, Brandon Long wrote:
|
||||
|
||||
>>> Didn't the old UW IMAP server act that way with certain mailbox
|
||||
>>> formats? It locked the mailbox and it couldn't receive new mail.
|
||||
>>>
|
||||
|
||||
>>> In any case, I don't think the spec precludes implementing it that
|
||||
>>> way, but it's certainly not the normal implemention.
|
||||
>>>
|
||||
|
||||
>>> Brandon
|
||||
|
||||
>>>
|
||||
|
||||
>>> On Feb 18, 2017 1:52 PM, "Gene Smith" <gds@chartertn.net> wrote:
|
||||
|
||||
>>>
|
||||
|
||||
>>>> I have been seeing a problem with mozilla Thunderbird client when
|
||||
>>>> using the charter.net imap server. When thunderbird checks for new
|
||||
>>>> messages it just does a FETCH since the inbox was already SELECTed
|
||||
>>>> at startup. It does not detect new messages unless another mailbox
|
||||
>>>> is SELECTed and inbox is re-SELECTED and then FETCHed. I think
|
||||
>>>> thunderbird is following the IMAP spec but charter.net server is
|
||||
>>>> not since it requires a re-SELECT on and already selected mailbox
|
||||
>>>> to signal new email. Am I right?
|
||||
>>>>
|
||||
|
||||
>>>> -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/20170219/fac5e25f/attachment.html>
|
|
@ -0,0 +1,39 @@
|
|||
MBOX-Line: From jkt at flaska.net Mon Jan 25 15:43:06 2016
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: =?iso-8859-1?Q?Jan_Kundr=E1t?= <jkt@flaska.net>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Selected mailbox deleted by another client
|
||||
In-Reply-To: <20160125231528.GA21616@mew>
|
||||
References: <20160125231528.GA21616@mew>
|
||||
Message-ID: <4435a78f-3e95-4f3c-9a76-95cdabce95d7@flaska.net>
|
||||
|
||||
On Tuesday, 26 January 2016 00:15:28 CET, Omar Sandoval wrote:
|
||||
> That is, when C2 deletes the mailbox that C1 currently has selected,
|
||||
> what happens when C1 tries to access that mailbox? There's a previous
|
||||
> discussion here [1] about what should happen in the case that a client
|
||||
> attempts to delete the mailbox that it has selected which briefly talks
|
||||
> about the case I'm asking about here. Here's one proposal from that
|
||||
> thread:
|
||||
|
||||
There's also an RFC which outlines some possibilities, see
|
||||
https://tools.ietf.org/html/rfc2180#section-3 .
|
||||
|
||||
> C1: A003 UID FETCH 1 ENVELOPE
|
||||
> S: A003 OK Success
|
||||
> C1: A004 NOOP
|
||||
> S: A004 OK Success
|
||||
> C1: A005 UID FETCH 1 ENVELOPE
|
||||
> S: A005 BAD UID FETCH not allowed now.
|
||||
>
|
||||
> At first, Gmail seemed to be exhibiting the behavior described in my
|
||||
> quote. But, inexplicably, after issuing a NOOP, the connection
|
||||
> apparently left the Selected state and entered the Authenticated state.
|
||||
|
||||
Sounds like NO would be better reply (even for the A003), indeed.
|
||||
|
||||
Cheers,
|
||||
Jan
|
||||
|
||||
--
|
||||
Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
MBOX-Line: From alexey.melnikov at isode.com Wed Dec 23 09:01:27 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Alexey Melnikov <alexey.melnikov@isode.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] UID fetch command error on Gmail servers
|
||||
In-Reply-To: <CANVPb6u2nUYoi3+U7hhj17YiN-bNXKiHV3xRmUTyLckxu4WXaA@mail.gmail.com>
|
||||
References: <CANVPb6u2nUYoi3+U7hhj17YiN-bNXKiHV3xRmUTyLckxu4WXaA@mail.gmail.com>
|
||||
Message-ID: <567AD367.8000207@isode.com>
|
||||
|
||||
On 23/12/2015 16:51, Davide Gullo wrote:
|
||||
> Hello,
|
||||
> someone can help me to understand what exactly could be wrong in this
|
||||
> UID fetch command?
|
||||
>
|
||||
> I receive an error from Gmail server:
|
||||
>
|
||||
> 12/12/15, 10:06 PM >>> >>>>>>> send >>>>>>
|
||||
> 12/12/15, 10:06 PM >>> *103 UID FETCH 829907:830028 (UID X-GM-MSGID
|
||||
> FLAGS RFC822.SIZE ENVELOPE BODY.PEEK[HEADER.FIELDS (References)]
|
||||
> BODYSTRUCTURE RFC822)*
|
||||
> 12/12/15, 10:06 PM >>> >>>>>>> end send >>>>>>
|
||||
> 12/12/15, 10:06 PM <<< <<<<<<< read <<<<<<
|
||||
> 12/12/15, 10:06 PM <<< 103 NO *System Error (Failure)*
|
||||
> 12/12/15, 10:06 PM <<< <<<<<<< end read <<<<<<
|
||||
> 12/12/15, 10:06 PM messagesFullFrom: NIL - ERROR: Error
|
||||
> Domain=mailcore Code=24 "*UID fetch command error*"
|
||||
> UserInfo={NSLocalizedDescription=UID fetch command error}
|
||||
>
|
||||
> Thank you very much!
|
||||
What does the server returns on SELECT of the mailbox?
|
||||
|
||||
-------------- next part --------------
|
||||
An HTML attachment was scrubbed...
|
||||
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20151223/631123b2/attachment.html>
|
|
@ -0,0 +1,42 @@
|
|||
MBOX-Line: From dshaw at jabberwocky.com Tue Nov 17 15:11:00 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: David Shaw <dshaw@jabberwocky.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] UID MOVE and untagged OKs
|
||||
Message-ID: <25069F83-83C9-4130-B0D0-6C4FCC37A292@jabberwocky.com>
|
||||
|
||||
Hello,
|
||||
|
||||
I'm currently beating my head against a problem with a particular server implementation. The problem, as best I can work out from the outside, is in UID MOVE.
|
||||
|
||||
My understanding from RFC-6851 is that a UID MOVE transaction should look something like this (cut and paste from the RFC):
|
||||
|
||||
C: a UID MOVE 42:69 foo
|
||||
S: * OK [COPYUID 432432 42:69 1202:1229]
|
||||
S: * 22 EXPUNGE
|
||||
S: (more expunges)
|
||||
S: a OK Done
|
||||
|
||||
The relevant piece of this for my question is that the COPYUID response is in an untagged OK. Again, from the RFC: "Servers implementing UIDPLUS are also advised to send the COPYUID response code in an untagged OK before sending EXPUNGE or moved responses."
|
||||
|
||||
This seems straightforward.
|
||||
|
||||
The server I'm having a problem (outlook.office365.com) with has a UID MOVE transaction like this (actual transaction captured from my client):
|
||||
|
||||
C: 14 UID MOVE 7599 "Deleted Items"
|
||||
S: [COPYUID 12 7599 4788]
|
||||
S: * 373 EXPUNGE
|
||||
S: * 372 EXISTS
|
||||
S: 14 OK MOVE completed.
|
||||
|
||||
The concern is with the second line (the COPYUID response). There is no untagged OK / "* OK" there, which seems incorrect to me and perhaps more significantly, seems to cause the Apple iOS mail program to throw an error every time a message is moved from folder to folder (which of course includes the "delete this message" function).
|
||||
|
||||
I've spent (literally) weeks trying to get Microsoft Office365 support to acknowledge the problem, without success. The most recent response insists that they are following the RFC, and in fact quoted the "Servers implementing UIDPLUS are also advised to send the COPYUID response code in an untagged OK before sending EXPUNGE or moved responses." line from RFC-6851 as what they are doing.
|
||||
|
||||
Could the experts on this list help me understand what is going on here? I have no particular need to be "right" - I just want to be able to delete messages without getting errors every single time.
|
||||
|
||||
Thanks,
|
||||
|
||||
David
|
||||
|
||||
|
|
@ -0,0 +1,111 @@
|
|||
MBOX-Line: From gds at chartertn.net Thu Oct 12 21:46:22 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: <CABa8R6ucJXxUp9kAQ+_fDvtEAwmAYtJ6Hmr60J5=SW48SLvmig@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>
|
||||
Message-ID: <b60bb28d-a16d-397d-784b-830265501279@chartertn.net>
|
||||
|
||||
On 10/9/17 7:30 PM, Brandon Long wrote:
|
||||
>
|
||||
>
|
||||
> On Mon, Oct 9, 2017 at 7:39 AM, Arnt Gulbrandsen
|
||||
> <arnt@gulbrandsen.priv.no <mailto:arnt@gulbrandsen.priv.no>> wrote:
|
||||
>
|
||||
> Gene Smith writes:
|
||||
>
|
||||
> Yes, for other IMAP servers I have tested, if I copy message "A"
|
||||
> 10 times into Inbox I see 10 identical copies of message A in
|
||||
> Inbox. For this openwave server, I see only 1 (and uid fetch 1:*
|
||||
> (FLAGS) shows only 1).
|
||||
>
|
||||
>
|
||||
> Have you tested with gmail?
|
||||
>
|
||||
>
|
||||
> Since Gmail considers a COPY operation as an "add label" operation, it's
|
||||
> usually a no-op if the message already has that label, which is what
|
||||
> would happen in this case.
|
||||
>
|
||||
> There are cases where Gmail does "reassign UID" on a COPY, ie it bumps
|
||||
> the UID of a message to the UIDNEXT.? It does this if the user is
|
||||
> calling COPY with a source/target folder that are the same, on the
|
||||
> assumption that the user is trying to make an actual copy of the message
|
||||
> in the same folder.? Clients doing this tend to be confused if the
|
||||
> message isn't the latest UID in that case.? We also reassign UIDs when
|
||||
> messages are moved to/from the spam/trash folders, for similar reasons.
|
||||
> (Note that APPEND always bumps the UID when it detects an attempt to
|
||||
> APPEND a duplicate message for similar reasons to the COPY to the same
|
||||
> folder)
|
||||
>
|
||||
> Most IMAP flags are also implemented as labels, and so are consistent
|
||||
> across all "copies" of a message.? The exception is \Deleted, so doing
|
||||
> something like a COPY/Deleted as a MOVE operation without an EXPUNGE and
|
||||
> then doing it back will leave both "copies" with a \Deleted flag and
|
||||
|
||||
To simulate a MOVE, wouldn't you COPY the message to a destination
|
||||
folder and then set the \Deleted on the source message/folder. So the
|
||||
\deleted flag is not on both copies? Then you would uid expunge the
|
||||
source message.
|
||||
|
||||
> both will be removed with EXPUNGE.? That said, the default is for the
|
||||
> user to be in auto-expunge mode, in which case storing a \Deleted flag
|
||||
> will result in the message being EXPUNGED (that label removed) at the
|
||||
> next sync point.
|
||||
>
|
||||
> IE, from the given example:
|
||||
> C: aaa UID COPY 1267 "Mbox"
|
||||
> S: aaa OK [COPYUID 123456789 1267 1007] UID COPY completed
|
||||
> C: bbb UID store 1267 +Flags (\Deleted)
|
||||
>
|
||||
> The UID store is a sync point, so the message will be auto-expunged at
|
||||
> this point, so the COPY back will get a new UID.
|
||||
|
||||
Thanks for the info on gmail. One thing I didn't understand is why gmail
|
||||
has the "auto-expunge on \Deleted" default feature. You have provide a
|
||||
rationale for it. But it seems to be a violation of rfc 3501. It also
|
||||
causes problem for clients that use the "Just mark it as deleted" delete
|
||||
method that just sets the \Deleted flag and leaves a deleted email
|
||||
summary in place but indicates it is deleted by drawing a line though
|
||||
the summary. With default gmail, the crossed-out message vanishes from
|
||||
the summary list since it auto-expunged. This can be fixed in the gmail
|
||||
imap settings, fortunately. The outlook imap server also does the
|
||||
auto-expunge but doesn't seem to have a way to disable it. I haven't yet
|
||||
seen other imap servers that do auto-expunge.
|
||||
|
||||
>
|
||||
> You'd need to change the user using the advanced IMAP options to a
|
||||
> different deletion mode to see the UID maintained.
|
||||
|
||||
Advanced IMAP option == not auto-expunge? I think that's what you mean.
|
||||
|
||||
OK, if I do this with auto-expunge set to false:
|
||||
Copy message "test" (uid 5604) from Inbox to [Gmail]/f1
|
||||
Message test is visible in Inbox and f1. Not crossed-out.
|
||||
In Inbox, mark test with \deleted. It becomes crossed-out.
|
||||
In f1 copy test to Inbox. Goes to uid 5604 in Inbox.
|
||||
test in Inbox keeps \Deleted flag and remain crossed-out.
|
||||
|
||||
So gmail imap behaving same as openwave imap! It copies back to the
|
||||
original UID and doesn't clear the \Deleted flag on UID 5604 in Inbox
|
||||
and message remains crossed-out in client.
|
||||
|
||||
Why doesn't \Deleted on UID 5604 in Inbox get cleared after copy back?
|
||||
|
||||
>
|
||||
> Also, Gmail offers the MOVE extension, so you should really use that
|
||||
> instead of COPY\Deleted\EXPUNGE.
|
||||
|
||||
Yes, no problem when MOVE used since it expunges the message after it
|
||||
copies it to the destination. That's typically what is used.
|
||||
|
||||
>
|
||||
> Brandon
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
MBOX-Line: From arnt at gulbrandsen.priv.no Sat Mar 11 00:50:05 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] What is the current consensus on the Recent
|
||||
flag?
|
||||
In-Reply-To: <CAPacwgx6aqYdp01-CA0k_saiYmLmCFOizs3TNg4R_PJcMt0WpA@mail.gmail.com>
|
||||
References: <CAPacwgx6aqYdp01-CA0k_saiYmLmCFOizs3TNg4R_PJcMt0WpA@mail.gmail.com>
|
||||
Message-ID: <d0a13d3d-4e4c-4132-a069-ce9da2efe5c3@gulbrandsen.priv.no>
|
||||
|
||||
Hi,
|
||||
|
||||
I've never seen it in real use either.
|
||||
|
||||
But it's simplish to implement along with MSNs. You keep a UID
|
||||
persistently, "the last UID for which some session has seen \recent". In
|
||||
the code where you assign MSNs for each session, you look at whether each
|
||||
message has UID>that, and if so, you set \recent in that session only and
|
||||
increase the threshold.
|
||||
|
||||
Simple to do, but worthless. Your call ;)
|
||||
|
||||
Arnt
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
MBOX-Line: From gds at chartertn.net Sat Feb 18 14:56:49 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 SELECT required before FETCH to detect new
|
||||
mail?
|
||||
In-Reply-To: <1487457851.3495664.885450568.157A4E2A@webmail.messagingengine.com>
|
||||
References: <bb8d0ae1-dda0-dbce-186a-2a668946ec7b@chartertn.net>
|
||||
<CABa8R6tLdckvJ9c-UHHijbvJ95fBGBN41fxhypO1yWzt0tGOMQ@mail.gmail.com>
|
||||
<3e01f804-163d-cda3-f5bb-b495fa5a1d50@chartertn.net>
|
||||
<CABa8R6tSevQ7kda5usVW-DuKO68Kdukgf7USZ=eTCWpvY-Nobw@mail.gmail.com>
|
||||
<1487457851.3495664.885450568.157A4E2A@webmail.messagingengine.com>
|
||||
Message-ID: <a36e24bf-e4b1-3733-9ea3-e84100391bdf@chartertn.net>
|
||||
|
||||
On 02/18/2017 05:44 PM, Bron Gondwana wrote:
|
||||
> Surely a noop should work to cause an update
|
||||
|
||||
I don't see thunderbird sending periodic NOOPs when idle. But I will
|
||||
check again...
|
||||
.
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
MBOX-Line: From davew at hireahit.com Tue Jan 26 00:44:22 2016
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Dave Warren <davew@hireahit.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Selected mailbox deleted by another client
|
||||
In-Reply-To: <1453765295.487330.502398698.1C26076F@webmail.messagingengine.com>
|
||||
References: <20160125231528.GA21616@mew>
|
||||
<1453765295.487330.502398698.1C26076F@webmail.messagingengine.com>
|
||||
Message-ID: <56A731E6.60104@hireahit.com>
|
||||
|
||||
On 2016-01-25 15:41, Bron Gondwana wrote:
|
||||
> Another possible thing (and what Cyrus IMAP used to do for a little while
|
||||
> in the 2.4 series when I added long-lived index locks) is to say
|
||||
> "NO Mailbox is locked" to the session which tries to delete an open
|
||||
> mailbox. This was bad because the situation actually occurs quite often
|
||||
> in practice that someone's phone or desktop is sitting there with a mailbox
|
||||
> open for hours or days just NOOPing away.
|
||||
|
||||
From a user perspective, this is probably the least desired
|
||||
possibility, although it certainly would avoid any further complications :)
|
||||
|
||||
Another possibility would be to block any further attempt to SELECT, or
|
||||
add messages into the mailbox and queue the delete for the next time the
|
||||
lock is released. I know of one server that does this in certain
|
||||
circumstances, and it seems minimally harmful from a end-user and client
|
||||
perspective.
|
||||
|
||||
--
|
||||
Dave Warren
|
||||
http://www.hireahit.com/
|
||||
http://ca.linkedin.com/in/davejwarren
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
MBOX-Line: From dinh.viet.hoa at gmail.com Wed Dec 23 09:08:57 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: =?utf-8?Q?Vi=C3=AAt_Ho=C3=A0_DINH?= <dinh.viet.hoa@gmail.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] UID fetch command error on Gmail servers
|
||||
In-Reply-To: <CANVPb6u2nUYoi3+U7hhj17YiN-bNXKiHV3xRmUTyLckxu4WXaA@mail.gmail.com>
|
||||
Message-ID: <58569bae-5cd1-4526-ab36-a98753b9d75b@dvh-mbp>
|
||||
|
||||
I think that Gmail is faling on you (I guess that's a Gmail server).
|
||||
The mailbox of the user is probably unusable.
|
||||
|
||||
|
||||
On December 23, 2015 at 8:51 AM, Davide Gullo wrote:
|
||||
> Hello,
|
||||
>
|
||||
> someone can help me to understand what exactly could be wrong in this UID fetch command?
|
||||
>
|
||||
>
|
||||
> I receive an error from Gmail server:
|
||||
>
|
||||
> 12/12/15, 10:06 PM>>>>>>>>>>send>>>>>>
|
||||
> 12/12/15, 10:06 PM>>>103 UID FETCH 829907:830028 (UID X-GM-MSGID FLAGS RFC822.SIZE ENVELOPE BODY.PEEK[HEADER.FIELDS (References)] BODYSTRUCTURE RFC822)
|
||||
>
|
||||
> 12/12/15, 10:06 PM>>>>>>>>>>end send>>>>>>
|
||||
>
|
||||
> 12/12/15, 10:06 PM<<<<<<<<<<read<<<<<<
|
||||
>
|
||||
> 12/12/15, 10:06 PM<<<103 NOSystem Error (Failure)
|
||||
>
|
||||
> 12/12/15, 10:06 PM<<<<<<<<<<end read<<<<<<
|
||||
>
|
||||
> 12/12/15, 10:06 PM messagesFullFrom: NIL - ERROR: Error Domain=mailcore Code=24 "UID fetch command error" UserInfo={NSLocalizedDescription=UID fetch command error}
|
||||
>
|
||||
>
|
||||
> Thank you very much!
|
||||
-------------- next part --------------
|
||||
An HTML attachment was scrubbed...
|
||||
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20151223/f89c1c28/attachment.html>
|
|
@ -0,0 +1,56 @@
|
|||
MBOX-Line: From jjmckay at comaxis.com Tue Nov 17 15:39:34 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Jeff McKay <jjmckay@comaxis.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] UID MOVE and untagged OKs
|
||||
In-Reply-To: <25069F83-83C9-4130-B0D0-6C4FCC37A292@jabberwocky.com>
|
||||
References: <25069F83-83C9-4130-B0D0-6C4FCC37A292@jabberwocky.com>
|
||||
Message-ID: <564BBAB6.8070609@comaxis.com>
|
||||
|
||||
I don't have an answer but if you don't mind my asking a question, what
|
||||
is the relationship between your client and iOS Mail? Why should
|
||||
something you are doing in your own client cause it to fail? Or if you
|
||||
are the author of iOS Mail, then why don't you adjust as necessary?
|
||||
|
||||
On 11/17/2015 3:11 PM, David Shaw wrote:
|
||||
> Hello,
|
||||
>
|
||||
> I'm currently beating my head against a problem with a particular server implementation. The problem, as best I can work out from the outside, is in UID MOVE.
|
||||
>
|
||||
> My understanding from RFC-6851 is that a UID MOVE transaction should look something like this (cut and paste from the RFC):
|
||||
>
|
||||
> C: a UID MOVE 42:69 foo
|
||||
> S: * OK [COPYUID 432432 42:69 1202:1229]
|
||||
> S: * 22 EXPUNGE
|
||||
> S: (more expunges)
|
||||
> S: a OK Done
|
||||
>
|
||||
> The relevant piece of this for my question is that the COPYUID response is in an untagged OK. Again, from the RFC: "Servers implementing UIDPLUS are also advised to send the COPYUID response code in an untagged OK before sending EXPUNGE or moved responses."
|
||||
>
|
||||
> This seems straightforward.
|
||||
>
|
||||
> The server I'm having a problem (outlook.office365.com) with has a UID MOVE transaction like this (actual transaction captured from my client):
|
||||
>
|
||||
> C: 14 UID MOVE 7599 "Deleted Items"
|
||||
> S: [COPYUID 12 7599 4788]
|
||||
> S: * 373 EXPUNGE
|
||||
> S: * 372 EXISTS
|
||||
> S: 14 OK MOVE completed.
|
||||
>
|
||||
> The concern is with the second line (the COPYUID response). There is no untagged OK / "* OK" there, which seems incorrect to me and perhaps more significantly, seems to cause the Apple iOS mail program to throw an error every time a message is moved from folder to folder (which of course includes the "delete this message" function).
|
||||
>
|
||||
> I've spent (literally) weeks trying to get Microsoft Office365 support to acknowledge the problem, without success. The most recent response insists that they are following the RFC, and in fact quoted the "Servers implementing UIDPLUS are also advised to send the COPYUID response code in an untagged OK before sending EXPUNGE or moved responses." line from RFC-6851 as what they are doing.
|
||||
>
|
||||
> Could the experts on this list help me understand what is going on here? I have no particular need to be "right" - I just want to be able to delete messages without getting errors every single time.
|
||||
>
|
||||
> Thanks,
|
||||
>
|
||||
> David
|
||||
>
|
||||
> _______________________________________________
|
||||
> Imap-protocol mailing list
|
||||
> Imap-protocol@u.washington.edu
|
||||
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
||||
>
|
||||
|
||||
|
|
@ -0,0 +1,152 @@
|
|||
MBOX-Line: From blong at google.com Fri Oct 13 00:19:59 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Brandon Long <blong@google.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Is server re-use of UID OK?
|
||||
In-Reply-To: <b60bb28d-a16d-397d-784b-830265501279@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>
|
||||
Message-ID: <CABa8R6sMcLPOF2gbv-EYAOzwVMVi5CwZC_GZ2aHmuu2xFpovGw@mail.gmail.com>
|
||||
|
||||
On Oct 12, 2017 9:46 PM, "Gene Smith" <gds@chartertn.net> wrote:
|
||||
|
||||
On 10/9/17 7:30 PM, Brandon Long wrote:
|
||||
|
||||
|
||||
>
|
||||
> On Mon, Oct 9, 2017 at 7:39 AM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no
|
||||
> <mailto:arnt@gulbrandsen.priv.no>> wrote:
|
||||
>
|
||||
> Gene Smith writes:
|
||||
>
|
||||
> Yes, for other IMAP servers I have tested, if I copy message "A"
|
||||
> 10 times into Inbox I see 10 identical copies of message A in
|
||||
> Inbox. For this openwave server, I see only 1 (and uid fetch 1:*
|
||||
> (FLAGS) shows only 1).
|
||||
>
|
||||
>
|
||||
> Have you tested with gmail?
|
||||
>
|
||||
>
|
||||
> Since Gmail considers a COPY operation as an "add label" operation, it's
|
||||
> usually a no-op if the message already has that label, which is what would
|
||||
> happen in this case.
|
||||
>
|
||||
> There are cases where Gmail does "reassign UID" on a COPY, ie it bumps the
|
||||
> UID of a message to the UIDNEXT. It does this if the user is calling COPY
|
||||
> with a source/target folder that are the same, on the assumption that the
|
||||
> user is trying to make an actual copy of the message in the same folder.
|
||||
> Clients doing this tend to be confused if the message isn't the latest UID
|
||||
> in that case. We also reassign UIDs when messages are moved to/from the
|
||||
> spam/trash folders, for similar reasons. (Note that APPEND always bumps
|
||||
> the UID when it detects an attempt to APPEND a duplicate message for
|
||||
> similar reasons to the COPY to the same folder)
|
||||
>
|
||||
> Most IMAP flags are also implemented as labels, and so are consistent
|
||||
> across all "copies" of a message. The exception is \Deleted, so doing
|
||||
> something like a COPY/Deleted as a MOVE operation without an EXPUNGE and
|
||||
> then doing it back will leave both "copies" with a \Deleted flag and
|
||||
>
|
||||
|
||||
To simulate a MOVE, wouldn't you COPY the message to a destination folder
|
||||
and then set the \Deleted on the source message/folder. So the \deleted
|
||||
flag is not on both copies? Then you would uid expunge the source message.
|
||||
|
||||
|
||||
both will be removed with EXPUNGE. That said, the default is for the user
|
||||
> to be in auto-expunge mode, in which case storing a \Deleted flag will
|
||||
> result in the message being EXPUNGED (that label removed) at the next sync
|
||||
> point.
|
||||
>
|
||||
> IE, from the given example:
|
||||
> C: aaa UID COPY 1267 "Mbox"
|
||||
> S: aaa OK [COPYUID 123456789 1267 1007] UID COPY completed
|
||||
> C: bbb UID store 1267 +Flags (\Deleted)
|
||||
>
|
||||
> The UID store is a sync point, so the message will be auto-expunged at
|
||||
> this point, so the COPY back will get a new UID.
|
||||
>
|
||||
|
||||
Thanks for the info on gmail. One thing I didn't understand is why gmail
|
||||
has the "auto-expunge on \Deleted" default feature. You have provide a
|
||||
rationale for it. But it seems to be a violation of rfc 3501. It also
|
||||
causes problem for clients that use the "Just mark it as deleted" delete
|
||||
method that just sets the \Deleted flag and leaves a deleted email summary
|
||||
in place but indicates it is deleted by drawing a line though the summary.
|
||||
With default gmail, the crossed-out message vanishes from the summary list
|
||||
since it auto-expunged. This can be fixed in the gmail imap settings,
|
||||
fortunately. The outlook imap server also does the auto-expunge but doesn't
|
||||
seem to have a way to disable it. I haven't yet seen other imap servers
|
||||
that do auto-expunge.
|
||||
|
||||
|
||||
What is the utility of the leave in folder marked as deleted?
|
||||
|
||||
Most clients moved to a trash folder concept, which doesn't require the
|
||||
leave deleted state.
|
||||
|
||||
Gmail added auto-expunge as soon as we started testing imap, since people
|
||||
would delete messages... And they'd still be there in the web interface.
|
||||
We had no interest in adding the weird deleted still there mode to the
|
||||
Gmail client. We debated a couple different modes, and they basically
|
||||
wound up as advanced settings, but just expunging made the most sense,
|
||||
especially since most mobile clients at the time never called expunge, and
|
||||
the main use case of imap for Gmail was for mobile clients.
|
||||
|
||||
It is not a violation of RFC 3501, since another client could be connected
|
||||
and issue an expunge, as long as it's only visible at a sync point.
|
||||
|
||||
It did cause the occasional issue with clients that couldn't handle it in
|
||||
all cases, but those were all client bugs.
|
||||
|
||||
|
||||
> You'd need to change the user using the advanced IMAP options to a
|
||||
> different deletion mode to see the UID maintained.
|
||||
>
|
||||
|
||||
Advanced IMAP option == not auto-expunge? I think that's what you mean.
|
||||
|
||||
OK, if I do this with auto-expunge set to false:
|
||||
Copy message "test" (uid 5604) from Inbox to [Gmail]/f1
|
||||
Message test is visible in Inbox and f1. Not crossed-out.
|
||||
In Inbox, mark test with \deleted. It becomes crossed-out.
|
||||
In f1 copy test to Inbox. Goes to uid 5604 in Inbox.
|
||||
test in Inbox keeps \Deleted flag and remain crossed-out.
|
||||
|
||||
So gmail imap behaving same as openwave imap! It copies back to the
|
||||
original UID and doesn't clear the \Deleted flag on UID 5604 in Inbox and
|
||||
message remains crossed-out in client.
|
||||
|
||||
Why doesn't \Deleted on UID 5604 in Inbox get cleared after copy back?
|
||||
|
||||
|
||||
What is the proper thing to do? We're mixing two mailbox models which
|
||||
aren't entirely compatible.
|
||||
|
||||
I agree that clearing the flag is probably the right choice. Most likely,
|
||||
this is a fairly unlikely scenario that only occurs with a really small
|
||||
number of clients when a very unused setting is enabled, so no one ran into
|
||||
it and made a decision. I could probably file a bug for it.
|
||||
|
||||
Brandon
|
||||
|
||||
|
||||
> Also, Gmail offers the MOVE extension, so you should really use that
|
||||
> instead of COPY\Deleted\EXPUNGE.
|
||||
>
|
||||
|
||||
Yes, no problem when MOVE used since it expunges the message after it
|
||||
copies it to the destination. That's typically what is used.
|
||||
|
||||
|
||||
> Brandon
|
||||
>
|
||||
-------------- next part --------------
|
||||
An HTML attachment was scrubbed...
|
||||
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20171013/00ca0530/attachment.html>
|
|
@ -0,0 +1,44 @@
|
|||
MBOX-Line: From blong at google.com Mon Mar 13 12:33:22 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Brandon Long <blong@google.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] What is the current consensus on the Recent
|
||||
flag?
|
||||
In-Reply-To: <d0a13d3d-4e4c-4132-a069-ce9da2efe5c3@gulbrandsen.priv.no>
|
||||
References: <CAPacwgx6aqYdp01-CA0k_saiYmLmCFOizs3TNg4R_PJcMt0WpA@mail.gmail.com>
|
||||
<d0a13d3d-4e4c-4132-a069-ce9da2efe5c3@gulbrandsen.priv.no>
|
||||
Message-ID: <CABa8R6vAXuhR-80Pzc4hLcb8u3VFT8nFtm0D1BdqWFXrLWYStQ@mail.gmail.com>
|
||||
|
||||
Simultaneous access does make it more complicated, you have to maintain a
|
||||
lock across or at least issue a locked RMW to wherever you're storing that
|
||||
value.
|
||||
|
||||
Never seemed all that worth it to me, especially trying to sync with
|
||||
non-IMAP access in our case.
|
||||
|
||||
Brandon
|
||||
|
||||
On Sat, Mar 11, 2017 at 12:50 AM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no
|
||||
> wrote:
|
||||
|
||||
> Hi,
|
||||
>
|
||||
> I've never seen it in real use either.
|
||||
>
|
||||
> But it's simplish to implement along with MSNs. You keep a UID
|
||||
> persistently, "the last UID for which some session has seen \recent". In
|
||||
> the code where you assign MSNs for each session, you look at whether each
|
||||
> message has UID>that, and if so, you set \recent in that session only and
|
||||
> increase the threshold.
|
||||
>
|
||||
> Simple to do, but worthless. Your call ;)
|
||||
>
|
||||
> Arnt
|
||||
> _______________________________________________
|
||||
> 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/20170313/223a4a20/attachment.html>
|
|
@ -0,0 +1,47 @@
|
|||
MBOX-Line: From David.Harris at pmail.gen.nz Sat Feb 18 15:12:42 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: David Harris <David.Harris@pmail.gen.nz>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Is SELECT required before FETCH to detect new
|
||||
mail?
|
||||
In-Reply-To: <3e01f804-163d-cda3-f5bb-b495fa5a1d50@chartertn.net>
|
||||
References: <bb8d0ae1-dda0-dbce-186a-2a668946ec7b@chartertn.net>,
|
||||
<CABa8R6tLdckvJ9c-UHHijbvJ95fBGBN41fxhypO1yWzt0tGOMQ@mail.gmail.com>,
|
||||
<3e01f804-163d-cda3-f5bb-b495fa5a1d50@chartertn.net>
|
||||
Message-ID: <58A8D4EA.24417.4193CD74@David.Harris.pmail.gen.nz>
|
||||
|
||||
On 18 Feb 2017 at 17:29, Gene Smith wrote:
|
||||
|
||||
> The charter IMAP server is openwave according the login response. So
|
||||
> are you saying it is OK for the IMAP server to require a new SELECT
|
||||
> before doing a FETCH on an already selected mailbox for the FETCH
|
||||
> response to indicate new email? If so, this is a bug in thunderbird.
|
||||
|
||||
One of the major reasons IMAP has such detailed provision for unsolicited
|
||||
responses is so that the server can report the arrival of new messages in a
|
||||
mailbox *without* the client having to re-select it. Depending on the back-end,
|
||||
SELECT can be a fantastically "expensive" operation, and even on servers
|
||||
where it's well-optimized, it's probably going to incur significant overhead.
|
||||
|
||||
Speaking without any pretence of being authoritative, I'd say that if the only way
|
||||
the server can report new messages in a mailbox is through reselection, then it's
|
||||
broken, if only because there's no way for a client to learn procedurally that
|
||||
that's what the server wants.
|
||||
|
||||
In my own client code, I issue periodic NOOP commands and expect to see new
|
||||
messages reported as part of the response sequence to that command: that's
|
||||
how I would have expected most clients would do it.
|
||||
|
||||
Cheers!
|
||||
|
||||
-- David --
|
||||
|
||||
------------------ David Harris -+- Pegasus Mail ----------------------
|
||||
Box 5451, Dunedin, New Zealand | e-mail: David.Harris@pmail.gen.nz
|
||||
Phone: +64 3 453-6880 | Fax: +64 3 453-6612
|
||||
|
||||
Real newspaper headlines from US Papers:
|
||||
"Thieves steal burglar alarm".
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,27 @@
|
|||
MBOX-Line: From arnt at gulbrandsen.priv.no Wed Dec 23 14:02:55 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] UID fetch command error on Gmail servers
|
||||
In-Reply-To: <CANVPb6u2nUYoi3+U7hhj17YiN-bNXKiHV3xRmUTyLckxu4WXaA@mail.gmail.com>
|
||||
References: <CANVPb6u2nUYoi3+U7hhj17YiN-bNXKiHV3xRmUTyLckxu4WXaA@mail.gmail.com>
|
||||
Message-ID: <c297eeef-da1a-4c99-8181-89d55ba15104@gulbrandsen.priv.no>
|
||||
|
||||
Davide Gullo writes:
|
||||
> Hello,
|
||||
> someone can help me to understand what exactly could be wrong
|
||||
> in this UID fetch command?
|
||||
>
|
||||
> I receive an error from Gmail server:
|
||||
...
|
||||
> 12/12/15, 10:06 PM <<< 103 NO System Error (Failure)
|
||||
|
||||
This is a NO, which means that the command is fine, the server just
|
||||
wouldn't or couldn't carry it out.
|
||||
|
||||
My guess is a backend problem. Someone at Google is busy restoring from
|
||||
backup now.
|
||||
|
||||
Arnt
|
||||
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
MBOX-Line: From brong at fastmail.fm Tue Nov 17 15:52:32 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Bron Gondwana <brong@fastmail.fm>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] UID MOVE and untagged OKs
|
||||
In-Reply-To: <25069F83-83C9-4130-B0D0-6C4FCC37A292@jabberwocky.com>
|
||||
References: <25069F83-83C9-4130-B0D0-6C4FCC37A292@jabberwocky.com>
|
||||
Message-ID: <1447804352.3226866.442714569.1280F540@webmail.messagingengine.com>
|
||||
|
||||
Office 365 is being totally bogus here. An untagged OK is "* OK " stuff CRLF.
|
||||
|
||||
a01 UID MOVE 1 INBOX.Archive
|
||||
* OK [COPYUID 1400482663 1 1] Completed
|
||||
* 1 EXPUNGE
|
||||
a01 OK Completed
|
||||
|
||||
From a real live server (Cyrus IMAPd) right now.
|
||||
|
||||
Response lines in IMAP _always_ either start with '*' if they're an untagged response, or a tag.
|
||||
|
||||
2.2.2. Server Protocol Sender and Client Protocol Receiver
|
||||
|
||||
Data transmitted by the server to the client and status responses
|
||||
that do not indicate command completion are prefixed with the token
|
||||
"*", and are called untagged responses.
|
||||
|
||||
If the line doesn't start with '*' or a tag for a command that you have already sent in this connection, that is a server bug (modulo continuation lines which start with '+' or data within a literal of course).
|
||||
|
||||
Bron.
|
||||
|
||||
On Wed, Nov 18, 2015, at 10:11, David Shaw wrote:
|
||||
> Hello,
|
||||
>
|
||||
> I'm currently beating my head against a problem with a particular server implementation. The problem, as best I can work out from the outside, is in UID MOVE.
|
||||
>
|
||||
> My understanding from RFC-6851 is that a UID MOVE transaction should look something like this (cut and paste from the RFC):
|
||||
>
|
||||
> C: a UID MOVE 42:69 foo
|
||||
> S: * OK [COPYUID 432432 42:69 1202:1229]
|
||||
> S: * 22 EXPUNGE
|
||||
> S: (more expunges)
|
||||
> S: a OK Done
|
||||
>
|
||||
> The relevant piece of this for my question is that the COPYUID response is in an untagged OK. Again, from the RFC: "Servers implementing UIDPLUS are also advised to send the COPYUID response code in an untagged OK before sending EXPUNGE or moved responses."
|
||||
>
|
||||
> This seems straightforward.
|
||||
>
|
||||
> The server I'm having a problem (outlook.office365.com) with has a UID MOVE transaction like this (actual transaction captured from my client):
|
||||
>
|
||||
> C: 14 UID MOVE 7599 "Deleted Items"
|
||||
> S: [COPYUID 12 7599 4788]
|
||||
> S: * 373 EXPUNGE
|
||||
> S: * 372 EXISTS
|
||||
> S: 14 OK MOVE completed.
|
||||
>
|
||||
> The concern is with the second line (the COPYUID response). There is no untagged OK / "* OK" there, which seems incorrect to me and perhaps more significantly, seems to cause the Apple iOS mail program to throw an error every time a message is moved from folder to folder (which of course includes the "delete this message" function).
|
||||
>
|
||||
> I've spent (literally) weeks trying to get Microsoft Office365 support to acknowledge the problem, without success. The most recent response insists that they are following the RFC, and in fact quoted the "Servers implementing UIDPLUS are also advised to send the COPYUID response code in an untagged OK before sending EXPUNGE or moved responses." line from RFC-6851 as what they are doing.
|
||||
>
|
||||
> Could the experts on this list help me understand what is going on here? I have no particular need to be "right" - I just want to be able to delete messages without getting errors every single time.
|
||||
>
|
||||
> Thanks,
|
||||
>
|
||||
> David
|
||||
>
|
||||
> _______________________________________________
|
||||
> Imap-protocol mailing list
|
||||
> Imap-protocol@u.washington.edu
|
||||
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
||||
|
||||
|
||||
--
|
||||
Bron Gondwana
|
||||
brong@fastmail.fm
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
MBOX-Line: From gilles.lamiral at laposte.net Wed Oct 28 07:48:40 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Gilles LAMIRAL <gilles.lamiral@laposte.net>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Automap feature when rfc6154 is not supported (for
|
||||
imapsync).
|
||||
Message-ID: <5630E048.7060001@laposte.net>
|
||||
|
||||
Hello imap folks,
|
||||
|
||||
I'm currently working on automapping folders on both sides,
|
||||
for example:
|
||||
|
||||
Sent <-> Sent Messages
|
||||
|
||||
I've done the part where both sides support rfc6154, like Gmail or
|
||||
Dovecot imap servers. Foe example, it simplifies Gmail to Gmail migrations
|
||||
when the language is not the same on both sides, it's the case when one
|
||||
side is configured by default, in English. This automapping works
|
||||
fine.
|
||||
|
||||
But not all imap server softwares support rfc6154. So I add also an
|
||||
automap hardcoded when one side or both don't support special folders
|
||||
as described in rfc6154.
|
||||
|
||||
This way it will minimize headaches of playing with manual mapping
|
||||
(--regextrans2 imapsync option) in most of the cases.
|
||||
Email sysadmins for many different languages should appreciate.
|
||||
|
||||
I need a list of common folders names used for special folders
|
||||
described in https://tools.ietf.org/html/rfc6154
|
||||
|
||||
I start with:
|
||||
|
||||
\All => "All" "All Mail"
|
||||
|
||||
\Archive => "Archive"
|
||||
|
||||
\Drafts => "Drafts"
|
||||
|
||||
\Flagged => "Flagged" "Starred"
|
||||
|
||||
\Junk => "Junk" "Spam"
|
||||
|
||||
\Sent => "Sent" "Sent Messages" "Sent Items"
|
||||
|
||||
\Trash => "Trash"
|
||||
|
||||
Any comment or suggestion will be appreciated.
|
||||
English, German, Italian, Spanish, French or any language are welcome!
|
||||
|
||||
I don't know what are the imap server softwares supporting rfc6154.
|
||||
Exchange, Zimbra, Office365 aren't seem to support it.
|
||||
|
||||
PS: If there is a better place to talk about this feature, just tell
|
||||
me, I will switch the discussion there.
|
||||
|
||||
Thanks in advance.
|
||||
|
||||
|
||||
--
|
||||
Au revoir, 09 51 84 42 42
|
||||
Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06
|
||||
|
||||
|
|
@ -0,0 +1,89 @@
|
|||
MBOX-Line: From gds at chartertn.net Fri Oct 13 17:40:36 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: <CABa8R6sMcLPOF2gbv-EYAOzwVMVi5CwZC_GZ2aHmuu2xFpovGw@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>
|
||||
Message-ID: <20430a7a-eeda-a60b-bf79-d55f1289f17a@chartertn.net>
|
||||
|
||||
On 10/13/17 3:19 AM, Brandon Long wrote:
|
||||
>
|
||||
>
|
||||
> What is the utility of the leave in folder marked as deleted?
|
||||
>
|
||||
> Most clients moved to a trash folder concept, which doesn't require the
|
||||
> leave deleted state.
|
||||
|
||||
Well, I prefer the move to trash concept but some Thunderbird users
|
||||
still prefer the "Just mark it as deleted" non-default mode where a
|
||||
Trash folder is not involved and deleted messages just get crossed out
|
||||
in the UI after the \Deleted flag is set.
|
||||
|
||||
>
|
||||
> Gmail added auto-expunge as soon as we started testing imap, since
|
||||
> people would delete messages... And they'd still be there in the web
|
||||
> interface.? We had no interest in adding the weird deleted still there
|
||||
> mode to the Gmail client.? We debated a couple different modes, and they
|
||||
> basically wound up as advanced settings, but just expunging made the
|
||||
> most sense, especially since most mobile clients at the time never
|
||||
> called expunge, and the main use case of imap for Gmail was for mobile
|
||||
> clients.
|
||||
>
|
||||
> It is not a violation of RFC 3501, since another client could be
|
||||
> connected and issue an expunge, as long as it's only visible at a sync
|
||||
> point.
|
||||
|
||||
You're right, I looked at the rfc again and nowhere does it say an
|
||||
auto-expunge can't occur; but, it never really mentions the concept.
|
||||
|
||||
>
|
||||
> It did cause the occasional issue with clients that couldn't handle it
|
||||
> in all cases, but those were all client bugs.
|
||||
>
|
||||
|
||||
Since you can turn off auto-expunge at gmail it works around the problem
|
||||
in Thunderbird when using "just mark deleted" mode.
|
||||
|
||||
>
|
||||
> OK, if I do this with auto-expunge set to false:
|
||||
> Copy message "test" (uid 5604) from Inbox to [Gmail]/f1
|
||||
> Message test is visible in Inbox and f1. Not crossed-out.
|
||||
> In Inbox, mark test with \deleted. It becomes crossed-out.
|
||||
> In f1 copy test to Inbox. Goes to uid 5604 in Inbox.
|
||||
> test in Inbox keeps \Deleted flag and remain crossed-out.
|
||||
>
|
||||
> So gmail imap behaving same as openwave imap! It copies back to the
|
||||
> original UID and doesn't clear the \Deleted flag on UID 5604 in
|
||||
> Inbox and message remains crossed-out in client.
|
||||
>
|
||||
> Why doesn't \Deleted on UID 5604 in Inbox get cleared after copy back?
|
||||
>
|
||||
>
|
||||
> What is the proper thing to do?? We're mixing two mailbox models which
|
||||
> aren't entirely compatible.
|
||||
>
|
||||
> I agree that clearing the flag is probably the right choice.? Most
|
||||
> likely, this is a fairly unlikely scenario that only occurs with a
|
||||
> really small number of clients when a very unused setting is enabled, so
|
||||
> no one ran into it and made a decision.? I could probably file a bug for it.
|
||||
>
|
||||
|
||||
This is also what I observed for the openwave server that I thought was
|
||||
a bug. So it sounds like you agree a copy back to the same UID should
|
||||
result in the same flag states at the destination that are present at
|
||||
the source.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
MBOX-Line: From njhaveri at apple.com Tue Mar 14 08:49:39 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Neil Jhaveri <njhaveri@apple.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] What is the current consensus on the Recent
|
||||
flag?
|
||||
In-Reply-To: <CAPacwgx6aqYdp01-CA0k_saiYmLmCFOizs3TNg4R_PJcMt0WpA@mail.gmail.com>
|
||||
References: <CAPacwgx6aqYdp01-CA0k_saiYmLmCFOizs3TNg4R_PJcMt0WpA@mail.gmail.com>
|
||||
Message-ID: <B0977B48-3C1E-4872-BA3A-E2B92CDA3B6C@apple.com>
|
||||
|
||||
I agree, and we aren?t using it in iOS/macOS Mail. We?ve thought about it several times, though? but every time, the semantics proved to not be reliable enough.
|
||||
|
||||
On Mar 10, 2017, at 1:42 PM, Andris Reinman <andris.reinman@gmail.com<mailto:andris.reinman@gmail.com>> wrote:
|
||||
|
||||
Hi all,
|
||||
|
||||
I'm building a new open source IMAP server (https://github.com/wildduck-email/wildduck) and was wondering about the \Recent flag. Is it even needed today? I would like to keep my server as standards compliant as possible but the ephemeral nature of \Recent makes it a bit difficult to sync between sessions in multiple hosts. It would be doable but the complexity needed does not make it seem worth it.
|
||||
|
||||
Is there even any major client using this flag in a sane way? I don't think I have even ever encountered it outside the RFCs.
|
||||
|
||||
Best regards,
|
||||
Andris Reinman
|
||||
_______________________________________________
|
||||
Imap-protocol mailing list
|
||||
Imap-protocol@u.washington.edu<mailto: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/20170314/78f79acd/attachment.html>
|
|
@ -0,0 +1,46 @@
|
|||
MBOX-Line: From gds at chartertn.net Sat Feb 18 15:19:49 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 SELECT required before FETCH to detect new
|
||||
mail?
|
||||
In-Reply-To: <58A8D4EA.24417.4193CD74@David.Harris.pmail.gen.nz>
|
||||
References: <bb8d0ae1-dda0-dbce-186a-2a668946ec7b@chartertn.net>
|
||||
<CABa8R6tLdckvJ9c-UHHijbvJ95fBGBN41fxhypO1yWzt0tGOMQ@mail.gmail.com>
|
||||
<3e01f804-163d-cda3-f5bb-b495fa5a1d50@chartertn.net>
|
||||
<58A8D4EA.24417.4193CD74@David.Harris.pmail.gen.nz>
|
||||
Message-ID: <d6d36078-ac6e-459e-619c-1cfee1dc703b@chartertn.net>
|
||||
|
||||
On 02/18/2017 06:12 PM, David Harris wrote:
|
||||
> On 18 Feb 2017 at 17:29, Gene Smith wrote:
|
||||
>
|
||||
>> The charter IMAP server is openwave according the login response. So
|
||||
>> are you saying it is OK for the IMAP server to require a new SELECT
|
||||
>> before doing a FETCH on an already selected mailbox for the FETCH
|
||||
>> response to indicate new email? If so, this is a bug in thunderbird.
|
||||
>
|
||||
> One of the major reasons IMAP has such detailed provision for unsolicited
|
||||
> responses is so that the server can report the arrival of new messages in a
|
||||
> mailbox *without* the client having to re-select it. Depending on the back-end,
|
||||
> SELECT can be a fantastically "expensive" operation, and even on servers
|
||||
> where it's well-optimized, it's probably going to incur significant overhead.
|
||||
>
|
||||
> Speaking without any pretence of being authoritative, I'd say that if the only way
|
||||
> the server can report new messages in a mailbox is through reselection, then it's
|
||||
> broken, if only because there's no way for a client to learn procedurally that
|
||||
> that's what the server wants.
|
||||
>
|
||||
> In my own client code, I issue periodic NOOP commands and expect to see new
|
||||
> messages reported as part of the response sequence to that command: that's
|
||||
> how I would have expected most clients would do it.
|
||||
|
||||
Thunderbird sends a NOOP when get mail timer expires on "get new mail"
|
||||
button is clicked, before doing the FETCH. However, the charter IMAP
|
||||
server always just responds with "OK NOOP completed" and provides no
|
||||
additional update info even when new email is definitely present on the
|
||||
server.
|
||||
(Note: other IMAP servers that I access with thunderbird have no
|
||||
problem, e.g., gmail, yahoo, and cyrus.)
|
||||
|
||||
-gene
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
MBOX-Line: From blong at google.com Wed Dec 23 22:21:33 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Brandon Long <blong@google.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] UID fetch command error on Gmail servers
|
||||
In-Reply-To: <c297eeef-da1a-4c99-8181-89d55ba15104@gulbrandsen.priv.no>
|
||||
References: <CANVPb6u2nUYoi3+U7hhj17YiN-bNXKiHV3xRmUTyLckxu4WXaA@mail.gmail.com>
|
||||
<c297eeef-da1a-4c99-8181-89d55ba15104@gulbrandsen.priv.no>
|
||||
Message-ID: <CABa8R6ssEXbdaqhmPqgaNRCPso5OuvZNJYhZNWA0rpkni5rEGA@mail.gmail.com>
|
||||
|
||||
Yeah, probably bad state either for that message or the account, if you can
|
||||
pass me more details offlist, I can have someone take a look.
|
||||
|
||||
Brandon
|
||||
On Dec 23, 2015 2:03 PM, "Arnt Gulbrandsen" <arnt@gulbrandsen.priv.no>
|
||||
wrote:
|
||||
|
||||
> Davide Gullo writes:
|
||||
>
|
||||
>> Hello,
|
||||
>> someone can help me to understand what exactly could be wrong in this UID
|
||||
>> fetch command?
|
||||
>>
|
||||
>> I receive an error from Gmail server:
|
||||
>>
|
||||
> ...
|
||||
>
|
||||
>> 12/12/15, 10:06 PM <<< 103 NO System Error (Failure)
|
||||
>>
|
||||
>
|
||||
> This is a NO, which means that the command is fine, the server just
|
||||
> wouldn't or couldn't carry it out.
|
||||
>
|
||||
> My guess is a backend problem. Someone at Google is busy restoring from
|
||||
> backup now.
|
||||
>
|
||||
> Arnt
|
||||
>
|
||||
> _______________________________________________
|
||||
> 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/20151223/478d3ef9/attachment.html>
|
|
@ -0,0 +1,59 @@
|
|||
MBOX-Line: From stuart.brandt at teamaol.com Tue Nov 17 15:58:01 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Stu Brandt <stuart.brandt@teamaol.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] UID MOVE and untagged OKs
|
||||
In-Reply-To: <25069F83-83C9-4130-B0D0-6C4FCC37A292@jabberwocky.com>
|
||||
References: <25069F83-83C9-4130-B0D0-6C4FCC37A292@jabberwocky.com>
|
||||
Message-ID: <564BBF09.7050804@teamaol.com>
|
||||
|
||||
David -
|
||||
|
||||
My read matches yours. Their 2nd line is neither a tagged or untagged
|
||||
response, rfc6851 section 3.3 has a specific example covering COPYUID in
|
||||
the response, and rfc6851 section 4.3 seems pretty clear when it says to
|
||||
send the COPYUID response code in an untagged OK.
|
||||
|
||||
- Stuart
|
||||
|
||||
On 11/17/15 6:11 PM, David Shaw wrote:
|
||||
> Hello,
|
||||
>
|
||||
> I'm currently beating my head against a problem with a particular server implementation. The problem, as best I can work out from the outside, is in UID MOVE.
|
||||
>
|
||||
> My understanding from RFC-6851 is that a UID MOVE transaction should look something like this (cut and paste from the RFC):
|
||||
>
|
||||
> C: a UID MOVE 42:69 foo
|
||||
> S: * OK [COPYUID 432432 42:69 1202:1229]
|
||||
> S: * 22 EXPUNGE
|
||||
> S: (more expunges)
|
||||
> S: a OK Done
|
||||
>
|
||||
> The relevant piece of this for my question is that the COPYUID response is in an untagged OK. Again, from the RFC: "Servers implementing UIDPLUS are also advised to send the COPYUID response code in an untagged OK before sending EXPUNGE or moved responses."
|
||||
>
|
||||
> This seems straightforward.
|
||||
>
|
||||
> The server I'm having a problem (outlook.office365.com) with has a UID MOVE transaction like this (actual transaction captured from my client):
|
||||
>
|
||||
> C: 14 UID MOVE 7599 "Deleted Items"
|
||||
> S: [COPYUID 12 7599 4788]
|
||||
> S: * 373 EXPUNGE
|
||||
> S: * 372 EXISTS
|
||||
> S: 14 OK MOVE completed.
|
||||
>
|
||||
> The concern is with the second line (the COPYUID response). There is no untagged OK / "* OK" there, which seems incorrect to me and perhaps more significantly, seems to cause the Apple iOS mail program to throw an error every time a message is moved from folder to folder (which of course includes the "delete this message" function).
|
||||
>
|
||||
> I've spent (literally) weeks trying to get Microsoft Office365 support to acknowledge the problem, without success. The most recent response insists that they are following the RFC, and in fact quoted the "Servers implementing UIDPLUS are also advised to send the COPYUID response code in an untagged OK before sending EXPUNGE or moved responses." line from RFC-6851 as what they are doing.
|
||||
>
|
||||
> Could the experts on this list help me understand what is going on here? I have no particular need to be "right" - I just want to be able to delete messages without getting errors every single time.
|
||||
>
|
||||
> Thanks,
|
||||
>
|
||||
> David
|
||||
>
|
||||
> _______________________________________________
|
||||
> Imap-protocol mailing list
|
||||
> Imap-protocol@u.washington.edu
|
||||
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
||||
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
MBOX-Line: From Neil_Hunsperger at symantec.com Wed Oct 28 10:59:14 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Neil Hunsperger <Neil_Hunsperger@symantec.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Automap feature when rfc6154 is not supported
|
||||
(for imapsync).
|
||||
In-Reply-To: <5630E048.7060001@laposte.net>
|
||||
References: <5630E048.7060001@laposte.net>
|
||||
Message-ID: <14D026C7F297AD44AC82578DD818CDD047B9AC7BAC@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM>
|
||||
|
||||
Hi Gilles,
|
||||
|
||||
> From: Imap-protocol [mailto:imap-protocol-
|
||||
> bounces@mailman13.u.washington.edu] On Behalf Of Gilles LAMIRAL
|
||||
|
||||
> I need a list of common folders names used for special folders
|
||||
> described in https://tools.ietf.org/html/rfc6154
|
||||
|
||||
> Any comment or suggestion will be appreciated.
|
||||
> English, German, Italian, Spanish, French or any language are welcome!
|
||||
|
||||
The case-insensitive names I've seen for the sent folder are:
|
||||
SENT
|
||||
SENT ITEMS
|
||||
SENT MESSAGES
|
||||
GESENDETE ELEMENTE
|
||||
GESENDETE OBJEKTE
|
||||
????????
|
||||
|
||||
This covers English, German, and Japanese versions of:
|
||||
Outlook Express
|
||||
Outlook 2003
|
||||
Outlook 2007
|
||||
Windows Mail
|
||||
Thunderbird 2.x
|
||||
Apple Mail 3.x
|
||||
|
||||
French language testing of the current versions of that software a few years later added:
|
||||
?l?ments envoy?s
|
||||
Envoy?
|
||||
|
||||
Similarly, Spanish language testing added:
|
||||
Elementos enviados
|
||||
|
||||
If this weren't complicated enough, many versions of Outlook prompt the user to type their own sent folder name when turning on server-side copies.
|
||||
|
||||
Cheers,
|
||||
-Neil
|
|
@ -0,0 +1,35 @@
|
|||
MBOX-Line: From nicolson at google.com Mon Aug 3 15:37:04 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Jamie Nicolson <nicolson@google.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Gmail LIST-EXTENDED bug
|
||||
In-Reply-To: <20150723204653.Horde.nTSGq462CvKEHJ8L-R7hEVB@bigworm.curecanti.org>
|
||||
References: <20150723130430.Horde.SA97i23HR6ui9hH7OsaY6OS@bigworm.curecanti.org>
|
||||
<CACU8CfTAgfJXZ4VNZqNXZGnFtmiyNh1hwjuYUbQjkjciqxmOew@mail.gmail.com>
|
||||
<CACU8CfQvtX7PmGc3-A02qsx6s6Md-=BE-arwEtNZmDNLMEA4pg@mail.gmail.com>
|
||||
<20150723204653.Horde.nTSGq462CvKEHJ8L-R7hEVB@bigworm.curecanti.org>
|
||||
Message-ID: <CACU8CfSvckoaP41iaEGB5UygzH6=0de1xV1monxmUS=k4gyAmA@mail.gmail.com>
|
||||
|
||||
This should be fixed now. Thanks for reporting it.
|
||||
|
||||
On Thu, Jul 23, 2015 at 7:46 PM, Michael M Slusarz <slusarz@curecanti.org>
|
||||
wrote:
|
||||
|
||||
> Quoting Jamie Nicolson <nicolson@google.com>:
|
||||
>
|
||||
> We can probably fix this in a week or so. Is it causing big problems for
|
||||
>> any clients to have LIST-EXTENDED enabled with this flaw? If it's causing
|
||||
>> serious pain we could turn off LIST-EXTENDED until it's fixed.
|
||||
>>
|
||||
>
|
||||
> Can't speak for anyone else, but this doesn't really affect us. We
|
||||
> fallback to RFC 3501 compliant LIST commands if a LIST-EXTENDED command
|
||||
> fails, so this is simply adding additional round-trips and/or additional
|
||||
> processing on the client side.
|
||||
>
|
||||
> michael
|
||||
>
|
||||
>
|
||||
-------------- next part --------------
|
||||
An HTML attachment was scrubbed...
|
||||
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150803/622e6e7d/attachment.html>
|
|
@ -0,0 +1,100 @@
|
|||
MBOX-Line: From blong at google.com Fri Oct 13 18:13:31 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Brandon Long <blong@google.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Is server re-use of UID OK?
|
||||
In-Reply-To: <20430a7a-eeda-a60b-bf79-d55f1289f17a@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>
|
||||
Message-ID: <CABa8R6uN09NiGww5LC_Aiv_E9UrLW1wHE7sH4iPBo9bwYJNTvA@mail.gmail.com>
|
||||
|
||||
On Oct 13, 2017 5:40 PM, "Gene Smith" <gds@chartertn.net> wrote:
|
||||
|
||||
On 10/13/17 3:19 AM, Brandon Long wrote:
|
||||
|
||||
>
|
||||
>
|
||||
> What is the utility of the leave in folder marked as deleted?
|
||||
>
|
||||
> Most clients moved to a trash folder concept, which doesn't require the
|
||||
> leave deleted state.
|
||||
>
|
||||
|
||||
Well, I prefer the move to trash concept but some Thunderbird users still
|
||||
prefer the "Just mark it as deleted" non-default mode where a Trash folder
|
||||
is not involved and deleted messages just get crossed out in the UI after
|
||||
the \Deleted flag is set.
|
||||
|
||||
|
||||
|
||||
> Gmail added auto-expunge as soon as we started testing imap, since people
|
||||
> would delete messages... And they'd still be there in the web interface.
|
||||
> We had no interest in adding the weird deleted still there mode to the
|
||||
> Gmail client. We debated a couple different modes, and they basically
|
||||
> wound up as advanced settings, but just expunging made the most sense,
|
||||
> especially since most mobile clients at the time never called expunge, and
|
||||
> the main use case of imap for Gmail was for mobile clients.
|
||||
>
|
||||
> It is not a violation of RFC 3501, since another client could be connected
|
||||
> and issue an expunge, as long as it's only visible at a sync point.
|
||||
>
|
||||
|
||||
You're right, I looked at the rfc again and nowhere does it say an
|
||||
auto-expunge can't occur; but, it never really mentions the concept.
|
||||
|
||||
|
||||
|
||||
> It did cause the occasional issue with clients that couldn't handle it in
|
||||
> all cases, but those were all client bugs.
|
||||
>
|
||||
>
|
||||
Since you can turn off auto-expunge at gmail it works around the problem in
|
||||
Thunderbird when using "just mark deleted" mode.
|
||||
|
||||
|
||||
|
||||
> OK, if I do this with auto-expunge set to false:
|
||||
> Copy message "test" (uid 5604) from Inbox to [Gmail]/f1
|
||||
> Message test is visible in Inbox and f1. Not crossed-out.
|
||||
> In Inbox, mark test with \deleted. It becomes crossed-out.
|
||||
> In f1 copy test to Inbox. Goes to uid 5604 in Inbox.
|
||||
> test in Inbox keeps \Deleted flag and remain crossed-out.
|
||||
>
|
||||
> So gmail imap behaving same as openwave imap! It copies back to the
|
||||
> original UID and doesn't clear the \Deleted flag on UID 5604 in
|
||||
> Inbox and message remains crossed-out in client.
|
||||
>
|
||||
> Why doesn't \Deleted on UID 5604 in Inbox get cleared after copy back?
|
||||
>
|
||||
>
|
||||
> What is the proper thing to do? We're mixing two mailbox models which
|
||||
> aren't entirely compatible.
|
||||
>
|
||||
> I agree that clearing the flag is probably the right choice. Most likely,
|
||||
> this is a fairly unlikely scenario that only occurs with a really small
|
||||
> number of clients when a very unused setting is enabled, so no one ran into
|
||||
> it and made a decision. I could probably file a bug for it.
|
||||
>
|
||||
>
|
||||
This is also what I observed for the openwave server that I thought was a
|
||||
bug. So it sounds like you agree a copy back to the same UID should result
|
||||
in the same flag states at the destination that are present at the source.
|
||||
|
||||
|
||||
I think that severs could implement either, the usage isn't write to spec
|
||||
or quite against. That said, leaving \Deleted can result in the unexpected
|
||||
behavior of message loss, which should be avoided, so the user friendly
|
||||
choice is to not leave \Deleted in that case.
|
||||
|
||||
Brandon
|
||||
-------------- next part --------------
|
||||
An HTML attachment was scrubbed...
|
||||
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20171013/9aa917b0/attachment.html>
|
|
@ -0,0 +1,56 @@
|
|||
MBOX-Line: From andris.reinman at gmail.com Mon Mar 20 11:41:39 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] What is the current consensus on the Recent
|
||||
flag?
|
||||
In-Reply-To: <B0977B48-3C1E-4872-BA3A-E2B92CDA3B6C@apple.com>
|
||||
References: <CAPacwgx6aqYdp01-CA0k_saiYmLmCFOizs3TNg4R_PJcMt0WpA@mail.gmail.com>
|
||||
<B0977B48-3C1E-4872-BA3A-E2B92CDA3B6C@apple.com>
|
||||
Message-ID: <CAPacwgxo7p6iwFTBEasQV_aDq4aN5ycfQw-hvsze3i5V_OGx=Q@mail.gmail.com>
|
||||
|
||||
Awesome, thanks for the feedback! If \Recent in practice only matters for
|
||||
the Dovecot ImapTest then I won't waste any time with it. The server I'm
|
||||
building is a distributed one (run many instances, connect to any of these
|
||||
(mailbox updates between server instances are propagated using a journal))
|
||||
and ensuring \Recent to be seen by just a single session would mean some
|
||||
kind of extra locking and extra overhead for no gains whatsoever.
|
||||
|
||||
Best regards,
|
||||
Andris Reinman
|
||||
http://wildduck.email/
|
||||
|
||||
|
||||
On Tue, Mar 14, 2017 at 5:49 PM, Neil Jhaveri <njhaveri@apple.com> wrote:
|
||||
|
||||
> I agree, and we aren?t using it in iOS/macOS Mail. We?ve thought about it
|
||||
> several times, though? but every time, the semantics proved to not be
|
||||
> reliable enough.
|
||||
>
|
||||
> On Mar 10, 2017, at 1:42 PM, Andris Reinman <andris.reinman@gmail.com>
|
||||
> wrote:
|
||||
>
|
||||
> Hi all,
|
||||
>
|
||||
> I'm building a new open source IMAP server (https://github.com/wildduck-
|
||||
> email/wildduck) and was wondering about the \Recent flag. Is it even
|
||||
> needed today? I would like to keep my server as standards compliant as
|
||||
> possible but the ephemeral nature of \Recent makes it a bit difficult to
|
||||
> sync between sessions in multiple hosts. It would be doable but the
|
||||
> complexity needed does not make it seem worth it.
|
||||
>
|
||||
> Is there even any major client using this flag in a sane way? I don't
|
||||
> think I have even ever encountered it outside the RFCs.
|
||||
>
|
||||
> Best regards,
|
||||
> Andris Reinman
|
||||
> _______________________________________________
|
||||
> 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/20170320/9dd414e9/attachment.html>
|
|
@ -0,0 +1,29 @@
|
|||
MBOX-Line: From gds at chartertn.net Sat Feb 18 15:56:12 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 SELECT required before FETCH to detect new
|
||||
mail?
|
||||
In-Reply-To: <a36e24bf-e4b1-3733-9ea3-e84100391bdf@chartertn.net>
|
||||
References: <bb8d0ae1-dda0-dbce-186a-2a668946ec7b@chartertn.net>
|
||||
<CABa8R6tLdckvJ9c-UHHijbvJ95fBGBN41fxhypO1yWzt0tGOMQ@mail.gmail.com>
|
||||
<3e01f804-163d-cda3-f5bb-b495fa5a1d50@chartertn.net>
|
||||
<CABa8R6tSevQ7kda5usVW-DuKO68Kdukgf7USZ=eTCWpvY-Nobw@mail.gmail.com>
|
||||
<1487457851.3495664.885450568.157A4E2A@webmail.messagingengine.com>
|
||||
<a36e24bf-e4b1-3733-9ea3-e84100391bdf@chartertn.net>
|
||||
Message-ID: <eb43ca0c-bcd5-9f7f-0767-bf3780a1a7fb@chartertn.net>
|
||||
|
||||
On 02/18/2017 05:56 PM, Gene Smith wrote:
|
||||
> On 02/18/2017 05:44 PM, Bron Gondwana wrote:
|
||||
>> Surely a noop should work to cause an update
|
||||
>
|
||||
> I don't see thunderbird sending periodic NOOPs when idle. But I will
|
||||
> check again...
|
||||
|
||||
Tb does send NOOP in response to the get new mail timer or if get mail
|
||||
is clicked. However, charter server only returns OK, thank you and
|
||||
provides no unsolicited info, even when new email is definitely present
|
||||
in INBOX.
|
||||
|
||||
-gene
|
||||
|
|
@ -0,0 +1,58 @@
|
|||
MBOX-Line: From brong at fastmail.fm Tue Nov 17 15:59:21 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Bron Gondwana <brong@fastmail.fm>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] UID MOVE and untagged OKs
|
||||
In-Reply-To: <564BBAB6.8070609@comaxis.com>
|
||||
References: <25069F83-83C9-4130-B0D0-6C4FCC37A292@jabberwocky.com>
|
||||
<564BBAB6.8070609@comaxis.com>
|
||||
Message-ID: <1447804761.3611730.442717985.7EC5626B@webmail.messagingengine.com>
|
||||
|
||||
|
||||
|
||||
On Wed, Nov 18, 2015, at 10:39, Jeff McKay wrote:
|
||||
> I don't have an answer but if you don't mind my asking a question, what
|
||||
> is the relationship between your client and iOS Mail? Why should
|
||||
> something you are doing in your own client cause it to fail? Or if you
|
||||
> are the author of iOS Mail, then why don't you adjust as necessary?
|
||||
|
||||
My laptop's stupid "double tap shift is capslock" tried to get me to shout this. Maybe it's right.
|
||||
|
||||
BECAUSE THAT WAY LIES MADNESS. IMAP is almost impossible to proxy already, but if you start allowing the most basic parts of the line protocol syntax to be ignored, then it becomes even more of an unparsable soup that it already is.
|
||||
|
||||
This whole discussion is convincing me even more that standards as we do them now are useless - what you need is a compliance test suite. Any half descent test suite would pick this up in an instant.
|
||||
|
||||
Oh look, there is one. http://www.imapwiki.org/ImapTest
|
||||
|
||||
Let's see what it does:
|
||||
|
||||
1447804537.510135 O: 1.12 move 1 imaptest2
|
||||
1447804537.511239 I: * OK [COPYUID 1447804538 1 1] Completed
|
||||
1447804537.511239 I: * 1 EXPUNGE
|
||||
1447804537.511239 I: 1.12 OK Completed
|
||||
|
||||
1447804537.511842 O: 1.15 uid move 2 imaptest2
|
||||
1447804537.512686 I: * OK [COPYUID 1447804538 2 2] Completed
|
||||
1447804537.512686 I: * 1 EXPUNGE
|
||||
1447804537.512686 I: 1.15 OK Completed
|
||||
|
||||
OK, let's fudge my local server to be dumb and output the wrong COPYUID data:
|
||||
|
||||
1447804659.929754 O: 1.12 move 1 imaptest2
|
||||
1447804659.930822 I: [COPYUID 1447804660 1 1] Completed
|
||||
1447804659.930822 I: * 1 EXPUNGE
|
||||
1447804659.930822 I: 1.12 OK Completed
|
||||
|
||||
|
||||
Cyrus::ImapTest.move [FAILED]
|
||||
|
||||
=====> Cyrus::ImapTest[168] Error: cassandane[1]: Unexpected tagged reply: [COPYUID: [COPYUID 1447804660 1 1] Completed
|
||||
|
||||
|
||||
|
||||
Looks like this whole thing would be trivially solved if Microsoft used the test suite that Timo has already made the effort to write.
|
||||
|
||||
--
|
||||
Bron Gondwana
|
||||
brong@fastmail.fm
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
MBOX-Line: From gilles.lamiral at laposte.net Thu Oct 29 04:33:02 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Gilles LAMIRAL <gilles.lamiral@laposte.net>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Automap feature when rfc6154 is not supported
|
||||
(for imapsync).
|
||||
In-Reply-To: <14D026C7F297AD44AC82578DD818CDD047B9AC7BAC@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM>
|
||||
References: <5630E048.7060001@laposte.net>
|
||||
<14D026C7F297AD44AC82578DD818CDD047B9AC7BAC@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM>
|
||||
Message-ID: <563203EE.6060603@laposte.net>
|
||||
|
||||
Hi Neil,
|
||||
|
||||
>> I need a list of common folders names used for special folders
|
||||
>> described in https://tools.ietf.org/html/rfc6154
|
||||
>
|
||||
> The case-insensitive names I've seen for the sent folder are:
|
||||
> SENT
|
||||
> SENT ITEMS
|
||||
> ...
|
||||
|
||||
Ok. Do you really encountered different cases writings or all are in
|
||||
fact only uppercase for the first characters like in "Sent Messages"?
|
||||
|
||||
I want to be sure I have to support case-insensitive search.
|
||||
|
||||
> ????????
|
||||
|
||||
Ok, you I think you mean &kAFP4W4IMH8wojCkMMYw4A-
|
||||
|
||||
> This covers English, German, and Japanese versions of:
|
||||
> Outlook *.*, Thunderbird 2.x, Apple Mail 3.x
|
||||
|
||||
Looks like 95% of the market is now covered! Thanks!
|
||||
|
||||
> French language testing of the current versions of that software a few years later added:
|
||||
> ?l?ments envoy?s
|
||||
> Envoy?
|
||||
>
|
||||
> Similarly, Spanish language testing added:
|
||||
> Elementos enviados
|
||||
|
||||
Very good!
|
||||
Any Russian or Portuguese in the room?
|
||||
We'll be near 99% coverage.
|
||||
|
||||
> If this weren't complicated enough, many versions of Outlook prompt the user to type
|
||||
>their own sent folder name when turning on server-side copies.
|
||||
|
||||
This is the 1% I don't care for now. I'll send the idea of then supporting
|
||||
rfc6154 in that case to Microsoft.
|
||||
|
||||
Asking the user to choose something else that what is known
|
||||
to work well without question, is perversion.
|
||||
Asking the user to solve something known to work bad
|
||||
is incompetence.
|
||||
|
||||
--
|
||||
Au revoir, 09 51 84 42 42
|
||||
Gilles Lamiral. France, Baulon (35580) 06 20 79 76 06
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
MBOX-Line: From David.Harris at pmail.gen.nz Thu Jul 16 20:50:57 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: David Harris <David.Harris@pmail.gen.nz>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] MIME parsing and part numbering
|
||||
Message-ID: <55A87BA1.25167.5CD5348F@David.Harris.pmail.gen.nz>
|
||||
|
||||
As I mentioned last week, I'm in the process of replacing my existing MIME parser.
|
||||
|
||||
I'm putting together a commandline version of this parser that spits out a full MIME
|
||||
parse including all IMAP-specific parts and part numbers, offsets, and octet and line
|
||||
counts. I propose to make this application publicly available in the hope that it might
|
||||
assist new IMAP developers to come to terms with the way MIME and IMAP
|
||||
interact with each other, particularly in regard to part numbering.
|
||||
|
||||
I have a library of over a million mail messages I can use to test it out, but if you
|
||||
have a few interesting boundary-case messages, or hugely complex messages that
|
||||
you would be willing to share with me for testing purposes only, I'd be glad to
|
||||
receive them (although please be aware that I run my mail server with a 4MB per
|
||||
message limit). Please zip them if possible.
|
||||
|
||||
I have the bulk of the process sorted out, but would be grateful for quick
|
||||
confirmation of two points:
|
||||
|
||||
1: In IMAP terms, for a part that is of type MESSAGE/RFC822 and which is not
|
||||
itself multipart, "<partnum>.TEXT" and "<partnum>.1" should yield the same data
|
||||
when fetched.
|
||||
|
||||
2: For a non-multipart message of any type, a request to fetch part "1.MIME" should
|
||||
synthesize a return containing all headers starting with "Content-" from the
|
||||
message's headers and terminate them with a CRLF.
|
||||
|
||||
For point (2), are there any other headers I should be including in the synthesis?
|
||||
|
||||
Cheers!
|
||||
|
||||
-- David --
|
||||
|
||||
------------------ David Harris -+- Pegasus Mail ----------------------
|
||||
Box 5451, Dunedin, New Zealand | e-mail: David.Harris@pmail.gen.nz
|
||||
Phone: +64 3 453-6880 | Fax: +64 3 453-6612
|
||||
|
||||
Newspaper misprints from around the world:
|
||||
"After the boat had been secured above the wrecked galleon the
|
||||
apparatus was set in motion by the captain's 18-year old daughter,
|
||||
Veronica. Within an hour, she was yielding her treasure to the
|
||||
excited crew."
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,33 @@
|
|||
MBOX-Line: From gds at chartertn.net Fri Oct 13 18:41:48 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: <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: <b2315146-26ca-a78d-2e7e-165ab4cd3804@chartertn.net>
|
||||
|
||||
On 10/13/17 9:13 PM, Brandon Long wrote:
|
||||
>
|
||||
> > I think that severs could implement either, the usage isn't write to
|
||||
> spec or quite against.? That said, leaving \Deleted can result in the
|
||||
> unexpected behavior of message loss, which should be avoided, so the
|
||||
> user friendly choice is to not leave \Deleted in that case.
|
||||
|
||||
Yeah, you're right again. The rfc only say copy SHOULD preserve the
|
||||
flags and date and SHOULD set the Recent flag. Not mandatory.
|
||||
|
||||
Again, thanks for the info.
|
||||
|
||||
-gene
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
MBOX-Line: From arnt at gulbrandsen.priv.no Mon Mar 20 14:33:03 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] What is the current consensus on the Recent
|
||||
flag?
|
||||
References: <CAPacwgx6aqYdp01-CA0k_saiYmLmCFOizs3TNg4R_PJcMt0WpA@mail.gmail.com>
|
||||
<B0977B48-3C1E-4872-BA3A-E2B92CDA3B6C@apple.com>
|
||||
<CAPacwgxo7p6iwFTBEasQV_aDq4aN5ycfQw-hvsze3i5V_OGx=Q@mail.gmail.com>
|
||||
Message-ID: <4kodMXgo62S28KBTeecQpMvl8FsUlee+YzxYpLzzzL8=.sha-256@antelope.email>
|
||||
|
||||
Strange, but pleasant, when several people agree except for details,
|
||||
and then none of them start arguing about the details.
|
||||
|
||||
Arnt
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
MBOX-Line: From kmansoft at gmail.com Fri Feb 24 04:09:08 2017
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Kostya Vasilyev <kmansoft@gmail.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Gmail - OAUTH2 - failures since Feb 23
|
||||
Message-ID: <CAN7dqjB3uUeos7hEA0A5Kiad1VZT4JY=8y2t_ig_L+YzGXu5ug@mail.gmail.com>
|
||||
|
||||
Hi,
|
||||
|
||||
My apologies to everyone for a message about Gmail that has nothing to
|
||||
do with IMAP specifically.
|
||||
|
||||
Hoping someone from Google (perhaps Brandon Long who I've seen lurk
|
||||
here?) can respond and we can take the discussion off the list.
|
||||
|
||||
---
|
||||
|
||||
Since Feb 23, we're seeing login / auth failures affecting a good
|
||||
number of users.
|
||||
|
||||
We support OAUTH2 and get the token through Google Play Services.
|
||||
|
||||
I saw the issue on one of my phones and was able to debug it:
|
||||
|
||||
- Most of the time, our code would get a valid looking token from
|
||||
Google Play Services
|
||||
|
||||
- A web API request using this token to get the user's name, email and
|
||||
profile photo would work fine
|
||||
|
||||
- And yet, using this token to log into Gmail would get "status code
|
||||
400, bad request" from Gmail's IMAP and SMTP servers.
|
||||
|
||||
At other times, there'd be a failure inside GoogleAuthUtil.getToken
|
||||
with GoogleAuthException: Unknown
|
||||
|
||||
So this looks to me like some back-end failure on Google's side,
|
||||
specific to Gmail (by comparison, the user profile API is just fine).
|
||||
|
||||
We found a workaround:
|
||||
|
||||
Removing our app from "authorized apps" in "your Google account", and
|
||||
the user re-authorizing the app seems to work.
|
||||
|
||||
But until this is done, authentication keeps failing, even if our code
|
||||
refreshes the token again.
|
||||
|
||||
Is this a known issue?
|
||||
|
||||
Are there changes we need to make or is this a bug (looks like a bug to me)?
|
||||
|
||||
If this is confirmed as a bug on Google's side, when can we and our
|
||||
users expect a fix?
|
||||
|
||||
Thanks, and my apologies again to the IMAP list!
|
||||
|
||||
PS - the app is called Aqua Mail, not sure if the issue is affecting
|
||||
only our app.
|
||||
|
||||
-- K
|
||||
|
|
@ -0,0 +1,99 @@
|
|||
MBOX-Line: From blong at google.com Tue Nov 17 16:06:39 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Brandon Long <blong@google.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] UID MOVE and untagged OKs
|
||||
In-Reply-To: <564BBF09.7050804@teamaol.com>
|
||||
References: <25069F83-83C9-4130-B0D0-6C4FCC37A292@jabberwocky.com>
|
||||
<564BBF09.7050804@teamaol.com>
|
||||
Message-ID: <CABa8R6tSWdWpSc2Xxfp+tWVk=GGRHYsdX-YmGXPVoAGCBBdPQw@mail.gmail.com>
|
||||
|
||||
Or his client is eating the '* ' in some fashion, it would be good for
|
||||
someone with an account to verify the bad behavior.
|
||||
|
||||
They obviously think they're sending the right response, let's not assume
|
||||
that they are sending the wrong one.
|
||||
|
||||
Brandon
|
||||
|
||||
On Tue, Nov 17, 2015 at 3:58 PM, Stu Brandt <stuart.brandt@teamaol.com>
|
||||
wrote:
|
||||
|
||||
> David -
|
||||
>
|
||||
> My read matches yours. Their 2nd line is neither a tagged or untagged
|
||||
> response, rfc6851 section 3.3 has a specific example covering COPYUID in
|
||||
> the response, and rfc6851 section 4.3 seems pretty clear when it says to
|
||||
> send the COPYUID response code in an untagged OK.
|
||||
>
|
||||
> - Stuart
|
||||
>
|
||||
>
|
||||
> On 11/17/15 6:11 PM, David Shaw wrote:
|
||||
>
|
||||
>> Hello,
|
||||
>>
|
||||
>> I'm currently beating my head against a problem with a particular server
|
||||
>> implementation. The problem, as best I can work out from the outside, is
|
||||
>> in UID MOVE.
|
||||
>>
|
||||
>> My understanding from RFC-6851 is that a UID MOVE transaction should look
|
||||
>> something like this (cut and paste from the RFC):
|
||||
>>
|
||||
>> C: a UID MOVE 42:69 foo
|
||||
>> S: * OK [COPYUID 432432 42:69 1202:1229]
|
||||
>> S: * 22 EXPUNGE
|
||||
>> S: (more expunges)
|
||||
>> S: a OK Done
|
||||
>>
|
||||
>> The relevant piece of this for my question is that the COPYUID response
|
||||
>> is in an untagged OK. Again, from the RFC: "Servers implementing UIDPLUS
|
||||
>> are also advised to send the COPYUID response code in an untagged OK before
|
||||
>> sending EXPUNGE or moved responses."
|
||||
>>
|
||||
>> This seems straightforward.
|
||||
>>
|
||||
>> The server I'm having a problem (outlook.office365.com) with has a UID
|
||||
>> MOVE transaction like this (actual transaction captured from my client):
|
||||
>>
|
||||
>> C: 14 UID MOVE 7599 "Deleted Items"
|
||||
>> S: [COPYUID 12 7599 4788]
|
||||
>> S: * 373 EXPUNGE
|
||||
>> S: * 372 EXISTS
|
||||
>> S: 14 OK MOVE completed.
|
||||
>>
|
||||
>> The concern is with the second line (the COPYUID response). There is no
|
||||
>> untagged OK / "* OK" there, which seems incorrect to me and perhaps more
|
||||
>> significantly, seems to cause the Apple iOS mail program to throw an error
|
||||
>> every time a message is moved from folder to folder (which of course
|
||||
>> includes the "delete this message" function).
|
||||
>>
|
||||
>> I've spent (literally) weeks trying to get Microsoft Office365 support to
|
||||
>> acknowledge the problem, without success. The most recent response insists
|
||||
>> that they are following the RFC, and in fact quoted the "Servers
|
||||
>> implementing UIDPLUS are also advised to send the COPYUID response code in
|
||||
>> an untagged OK before sending EXPUNGE or moved responses." line from
|
||||
>> RFC-6851 as what they are doing.
|
||||
>>
|
||||
>> Could the experts on this list help me understand what is going on here?
|
||||
>> I have no particular need to be "right" - I just want to be able to delete
|
||||
>> messages without getting errors every single time.
|
||||
>>
|
||||
>> Thanks,
|
||||
>>
|
||||
>> David
|
||||
>>
|
||||
>> _______________________________________________
|
||||
>> 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
|
||||
>
|
||||
-------------- next part --------------
|
||||
An HTML attachment was scrubbed...
|
||||
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20151117/bad4d19a/attachment.html>
|
|
@ -0,0 +1,28 @@
|
|||
MBOX-Line: From Neil_Hunsperger at symantec.com Thu Oct 29 10:30:58 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Neil Hunsperger <Neil_Hunsperger@symantec.com>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] Automap feature when rfc6154 is not supported
|
||||
(for imapsync).
|
||||
In-Reply-To: <563203EE.6060603@laposte.net>
|
||||
References: <5630E048.7060001@laposte.net>
|
||||
<14D026C7F297AD44AC82578DD818CDD047B9AC7BAC@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM>
|
||||
<563203EE.6060603@laposte.net>
|
||||
Message-ID: <14D026C7F297AD44AC82578DD818CDD047BA8080A1@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM>
|
||||
|
||||
Hi Gilles,
|
||||
|
||||
> Ok. Do you really encountered different cases writings or all are in
|
||||
> fact only uppercase for the first characters like in "Sent Messages"?
|
||||
|
||||
Looking back at the earliest notes I can find, I see only initial capitals for English folder names like "Sent Items" and not "Sent items" or "SENT ITEMS". French and Spanish used lower case second words. I can't find a record of the original capitalization of the two German versions.
|
||||
|
||||
>
|
||||
> > ????????
|
||||
>
|
||||
> Ok, you I think you mean &kAFP4W4IMH8wojCkMMYw4A-
|
||||
|
||||
These were converted from mod UTF-7 back to Unicode before being recorded.
|
||||
|
||||
Cheers,
|
||||
-Neil
|
|
@ -0,0 +1,36 @@
|
|||
MBOX-Line: From Pidgeot18 at verizon.net Thu Jul 16 22:10:09 2015
|
||||
To: imap-protocol@u.washington.edu
|
||||
From: Joshua Cranmer <Pidgeot18@verizon.net>
|
||||
Date: Fri Jun 8 12:34:55 2018
|
||||
Subject: [Imap-protocol] MIME parsing and part numbering
|
||||
In-Reply-To: <55A87BA1.25167.5CD5348F@David.Harris.pmail.gen.nz>
|
||||
References: <55A87BA1.25167.5CD5348F@David.Harris.pmail.gen.nz>
|
||||
Message-ID: <55A88E31.7000002@verizon.net>
|
||||
|
||||
On 7/16/2015 10:50 PM, David Harris wrote:
|
||||
> As I mentioned last week, I'm in the process of replacing my existing MIME parser.
|
||||
>
|
||||
> I'm putting together a commandline version of this parser that spits out a full MIME
|
||||
> parse including all IMAP-specific parts and part numbers, offsets, and octet and line
|
||||
> counts. I propose to make this application publicly available in the hope that it might
|
||||
> assist new IMAP developers to come to terms with the way MIME and IMAP
|
||||
> interact with each other, particularly in regard to part numbering.
|
||||
>
|
||||
> I have a library of over a million mail messages I can use to test it out, but if you
|
||||
> have a few interesting boundary-case messages, or hugely complex messages that
|
||||
> you would be willing to share with me for testing purposes only, I'd be glad to
|
||||
> receive them (although please be aware that I run my mail server with a 4MB per
|
||||
> message limit). Please zip them if possible.
|
||||
|
||||
Several years ago, I tested a message where the body was a
|
||||
message/rfc822 part. On four different IMAP servers, I got four
|
||||
different results for the part numbering. I don't have an actual copy of
|
||||
it as an evil message, but it is an evil edge case worth considering.
|
||||
|
||||
It's also worth considering as potential edge cases TNEF, uuencode,
|
||||
message/news, message/global.
|
||||
|
||||
--
|
||||
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
|
||||
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue