add imap-protocol list archives folder

Manos Pitsidianakis 2020-09-16 13:41:15 +03:00
parent f12f8d2ae5
commit 041d62e610
Signed by: Manos Pitsidianakis
GPG Key ID: 73627C2F690DF710
2669 changed files with 129339 additions and 61 deletions

View File

@ -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>

View File

@ -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-)

View File

@ -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

View File

@ -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.

View File

@ -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>

View File

@ -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

View File

@ -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>

View File

@ -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

View File

@ -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>

View File

@ -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.

View File

@ -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>

View File

@ -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?

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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

View File

@ -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).

View File

@ -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.

View File

@ -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

View File

@ -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>

View File

@ -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).

View File

@ -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
--------------------------------------------------------------

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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>

View File

@ -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>

View File

@ -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

View File

@ -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>

View File

@ -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).

View File

@ -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

View File

@ -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.

View File

@ -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>

View File

@ -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
>

View File

@ -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

View File

@ -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

View File

@ -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.?

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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>

View File

@ -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>

View File

@ -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.

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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

View File

@ -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

View File

@ -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>

View File

@ -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>

View File

@ -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

View File

@ -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

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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/

View File

@ -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>

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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...
.

View File

@ -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

View File

@ -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>

View File

@ -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
>

View File

@ -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>

View File

@ -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>

View File

@ -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".

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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.

View File

@ -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>

View File

@ -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

View File

@ -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>

View File

@ -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

View File

@ -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

View File

@ -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>

View File

@ -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>

View File

@ -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>

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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."

View File

@ -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

View File

@ -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

View File

@ -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

View File

@ -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>

View File

@ -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

View File

@ -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