http://blog.gmane.org/gmane.mail.imap.general hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.mail.imap.general/3006 <pre>Just to make sure I'm interpreting the spec correctly... The spec says of a FETCH BODY request: Any partial fetch that attempts to read beyond the end of the text is truncated as appropriate. A partial fetch that starts at octet 0 is returned as a partial fetch, even if this truncation happened. The spec says of a FETCH BODY response: If the origin octet is specified, this string is a substring of the entire body contents, starting at that origin octet. This means that BODY[]&lt;0&gt; MAY be truncated, but BODY[] is NEVER truncated. It's not clear whether the truncation being talked about is the same in both cases. If it were only allowed to truncate the response at the end of the data, "BODY[]" would be allowed to be truncated as well, so it seems that it must be talking about truncation for some other reason. If I do "FETCH 2 (BODY[]&lt;0.16384&gt;)" and the server responds "2 FETCH (BODY[]&lt;0&gt; {2817}", can I assume that that's the end of the data or not? What if I request "FETCH 2 (BODY[]&lt;16384.16384&gt;)" and the response is "2 FETCH (BODY[]&lt;16384&gt; {2817}"? Is that a different case than above, since the request doesn't start at octet 0? If I do "FETCH 2 (BODY[]&lt;2817.16384&gt;)" and the server responds "2 FETCH (BODY[]&lt;2817&gt; {0}" I know I'm at the end of the data. Is "2 FETCH (BODY[]&lt;2817&gt; NIL)" semantically equivalent? The spec says: ... If the starting octet is beyond the end of the text, an empty string is returned. Is "NIL" equivalent to an empty string in this case? It would appear not, according to this part of the spec: The special form "NIL" represents the non-existence of a particular data item that is represented as a string or parenthesized list, as distinct from the empty string "" or the empty parenthesized list (). Even though the syntax specifies "nstring", is "NIL" a valid response in this case? Thanks. _______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol </pre> Bill Shannon 2012-05-12T07:21:35 http://comments.gmane.org/gmane.mail.imap.general/2996 <pre>I wonder if any IMAP client developers have had problems using the SELECT statement against Google Gmail "folders" (labels). I thought this was working fine but today I was given access to a customer's account where some folders work and some do not. When they do not, the response from the SELECT command is "NO System error (Failure)". I don't see any difference between working and non-working folders. All the folders have messages and work fine using the web client. I get the folder names from the LIST command. An example of a failed SELECT would be: &lt;send 25&gt;A101 SELECT "Clearwell" &lt;recv 32&gt;A101 NO System error (Failure) A working example would be: &lt;send 24&gt;A101 SELECT "Intransa" &lt;recv 336&gt;* FLAGS (\Answered \Flagged \Draft \Deleted \Seen $Forwarded $MDNSent) * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen $Forwarded $MDNSent \*)] Flags permitted. * OK [UIDVALIDITY 1315401400] UIDs valid. * 11 EXISTS * 0 RECENT * OK [UIDNEXT 12] Predicted next UID. Anybody have an idea about this problem? _______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol </pre> Jeff McKay 2012-05-02T23:28:47 http://comments.gmane.org/gmane.mail.imap.general/2995 <pre>I don't think IMAP RFCs actually require any specific behavior for this, so this is more of a "any recommendations?" type of a question: Clients C1 and C2 send: C1: a FETCH 1 FLAGS S1: * 1 FETCH (FLAGS (\Seen \Answered)) S1: a OK C2: b STORE 1 +FLAGS (\Flagged) S2: * 1 FETCH (FLAGS (\Seen \Flagged)) S2: b OK At this point C1 still thinks that 1's flags are (\Seen), and being a little bit stupid it unsets the \Seen flag by sending: C1: c STORE 1 FLAGS (\Answered) Now, I think the possible replies are either of these: S1: * 1 FETCH (FLAGS (\Answered)) S1: * 1 FETCH (FLAGS (\Answered \Flagged)) Dovecot currently sends the first reply, but I've started thinking that perhaps I should change it to the second one. The question is really: Should STORE FLAGS be thought of as a) Reset all the flags that you have currently, whatever they are, and only set these flags. or b) Atomically add these flags I've listed, and remove those that I used to see previously in this session but aren't listed here. In the case of actual IMAP clients doing this, this is probably almost irrelevant. But it becomes more relevant if you have two IMAP servers doing a 2-way mailbox synchronization after a possibly long disconnection, and the same message's flags are changed in both of them. I haven't really looked at how many of the real world clients are using STORE FLAGS. For those I'd think b) is what they really intend to do. But are there perhaps some specialized clients / use cases assuming a)?_______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol </pre> Timo Sirainen 2012-05-02T21:28:46 http://comments.gmane.org/gmane.mail.imap.general/2992 <pre>I think I may be dealing with a buggy server but I wanted to verify my assumptions first. upon making this request to a particular server, I'm seeing this kind of response: C: 3 fetch 1 body.peek[header] S: * 1 FETCH (BODY[HEADER] {2006} S: &lt;data&gt; S: &lt;data&gt; S: S: S: ) S: 3 OK FETCH complete this seems like one newline too many in the response, but I can't find anything specific that dictates how many newlines are acceptable at the end of a BODY[HEADER] request. when doing the same request against a Dovecot server I see only one trailing newline pair: C: 3 fetch 1 body.peek[header] S: * 1 FETCH (BODY[HEADER] {2004} S: &lt;data&gt; S: &lt;data&gt; S: S: ) S: 3 OK FETCH complete but is that just convention or is this server breaking some part of the spec? if so, which part? Ashley_______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol</pre> Ashley Clark 2012-04-19T00:32:45 http://comments.gmane.org/gmane.mail.imap.general/2989 <pre>Hi list, I'm trying to understand what is the more efficient way to maintain the number of unseen messages of the currently selected mailbox. RFC3501 says a client must not issue a STATUS command to a selected mailbox and that information sent by a SELECT is enough. My current idea follows these steps : * Issue a STATUS before the mailbox is selected =&gt; I know how many unseen messages it contains * SELECT the mailbox =&gt; I got the eventual first unseen message in this mailbox but I don't understand how this info can be useful * Maintain the unseen counter (on client side) according to what the user do * Send a NOOP command every X minutes and look at the RECENT response to see if there are new messages I think it works pretty well when the mailbox is opened only once. Let's imagine this mailbox is opened twice, by different clients. If one client marks a message as \Seen, how can the second client know about this change? Thanks for your help, Antoine Nguyen http://modoboa.org/ _______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol </pre> Antoine Nguyen 2012-04-15T07:40:46 http://comments.gmane.org/gmane.mail.imap.general/2973 <pre>The RFC states that the mod-sequence represents the highest modification to a given mailbox. If a mailstore only stored a global (account-wide, across all mailboxes) mod-sequence, could one simply return the current value of such a global mod-sequence when the HIGHESTMODSEQ is called for (SELECT/EXAMINE/STATUS)? Obviously using this value would trigger the client to followup with a request to find out what has changed since it last sync'd, even if nothing has changed. Should a client be expected to behave reasonably if it's FETCH CHANGEDSINCE or SEARCH MODSEQ returned items where the highest mod-sequence was less than the advertised HIGHESTMODSEQ or worse, there were no results at all when some were expected? Thanks, John _______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol</pre> John Galton 2012-03-27T21:49:55 http://comments.gmane.org/gmane.mail.imap.general/2928 <pre>Hello, command performed on the same mailbox ... will get a different mod-sequence value." Can someone explain why the uniqueness requirement is necessary for the modification sequence? If two metadata items/messages are modified transactionally and share the same mod-sequence I don't really see any way that will break any of the proposed IMAP protocol changes for CONDSTORE (as long as they are updated atomically and a client can't sync between when a first item gets a mod-sequence and a second item gets the same mod-sequence). Thanks for your time, John _______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol</pre> John Galton 2012-03-20T18:34:17 http://comments.gmane.org/gmane.mail.imap.general/2919 <pre>Hello, Bellow is a preview of a diminutive IMAP server implemented in Lua [1]: imap://lua:lua&lt; at &gt;svr225.stepx.com:1143/inbox For these brave enough to give it a try, the user name and password is lua (plain login, no starttls, nor ssl). For example: $ telnet svr225.stepx.com 1143 Trying 212.55.219.225... Connected to svr225.stepx.com. Escape character is '^]'. * ok imap4rev1 123 login lua lua 123 ok login 123 select inbox * 1000 exists * 0 recent * flags (\answered \deleted \draft \flagged \seen) * ok [permanentflags ()] done * ok [uidnext 88836] done * ok [uidvalidity 15986] done 123 ok [read-only] select 123 fetch * fast * 1000 fetch (flags (\seen) internaldate "27-Feb-2012 01:31:18 +0000" rfc822.size 13981) 123 ok fetch 123 logout * bye imap4rev1 123 ok logout The demo server sports the content of the Lua mailing list since its inception until February 2012. About 88K messages. The server is read only and fronts an email archive stored in SQLite. The server side implementation details can be found bellow: http://dev.alt.textdrive.com/browser/Mail/IMAP.lua#L523 http://dev.alt.textdrive.com/browser/Mail/IMAPFetch.lua#L747 http://dev.alt.textdrive.com/browser/Mail/IMAPSearch.lua#L498 The server has been tested for interoperability with the following libraries: - uw-imap c-client - JavaMail - Perl Mail::IMAPClient - Python imaplib - Ruby Net::IMAP And the following email clients: - alpine - Apple Mail Mac OS X - Apple Mail iOS - Mozilla Thunderbird - Mulberry - GyazMail - Sparrow As the IMAP protocol is rather, hmm, "challenging", help with interoperability testing would be much appreciated :) If you manage to connect (or not) to the demo server, could you report back what client or library did or didn't work as expected? Thanks in advance. Cheers, -- [1] http://www.lua.org/about.html _______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol </pre> PA 2012-03-19T20:02:38 http://comments.gmane.org/gmane.mail.imap.general/2918 <pre>Hallo Howto copy cert into imapd.pem that works SSL with uw-imap-2007f? details s. following tests. regards Heiko --------------------------------------------------------------- - test5 rm imapd.pem cat /tmp/deutsche-telekom-root-ca-2.pem&gt;&gt; imapd.pem cat /tmp/cacert_global_root_ca.pem &gt;&gt; imapd.pem cat ~/server.key &gt;&gt; imapd.pem cat cert-mydn.pem &gt;&gt; imapd.pem result: SSL negotiation failed --------------------------------------------------------------- - test6 rm imapd.pem cat ~/server.key &gt;&gt; imapd.pem cat cert-mydn.pem &gt;&gt; imapd.pem cat /tmp/cacert_global_root_ca.pem &gt;&gt; imapd.pem cat /tmp/deutsche-telekom-root-ca-2.pem&gt;&gt; imapd.pem result: unable to get local issuer certificate (details) _______________________________________________ Imap-use mailing list Imap-use&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-use </pre> Heiko L. 2012-03-13T21:43:35 http://comments.gmane.org/gmane.mail.imap.general/2913 <pre> Hi all, I'm working on improving IMAP compliance in DBMail, using Timo's test-suite. One thing has me stumped in the 'append' test Comment in the test reads # Two connections have mailbox SELECTed, one doesn't. # The \recent flags can be given to either one of the SELECTed connections, # but never for the 3rd. We rely on mailbox state tracking to catch duplicate # \recent flags (which is why there are two FETCH FLAGS commands). I don't understand why a status command on a 3rd session should be able to see the updated number of recent messages. The 3rd session selecting the mailbox and fetching the flags *before* one of the selected sessions fetch them seems perfectly valid to me. To me the test reads as if the recent status of all mailboxes should be frozen at authentication, until a mailbox is selected or examined - but that would defeat the purpose of the status command as I understand it. If someone could shed some light on this I would appreciate it. thanks. </pre> Paul J Stevens 2012-03-04T11:30:20 http://comments.gmane.org/gmane.mail.imap.general/2912 <pre>Hi Does anyone know how to do imap connection with Oauth authentication? I see the zend library, but the performance are very bad compare to the standard imap lib. So I am trying to user the standard imap lib to do a gmail backup tool. Regards; *--* *Thomas* _______________________________________________ Imap-use mailing list Imap-use&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-use </pre> Thomas SAGNIMORTE (CAMPUS 2012-02-21T12:37:04 http://comments.gmane.org/gmane.mail.imap.general/2911 <pre>Hello, Given a multipart message without any actual parts [sic], what would be a reasonable thing for bodystructure to do? E.g., given the following message: --8&lt;-- Message-ID: &lt;ICFJPQSDGQIGWGNKNYQXI&lt; at &gt;yahoo.com&gt; From: "Ray Reagan" &lt;adelinablasrod&lt; at &gt;indian-magic.net&gt; Reply-To: "Ray Reagan" &lt;adelinablasrod&lt; at &gt;indian-magic.net&gt; To: lua-l&lt; at &gt;tecgraf.puc-rio.br Date: Wed, 16 Jun 2004 23:30:30 -0500 X-Mailer: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3413593125195075" Subject: (spam) The contents of this message was spam. --&gt;8-- What should bodystructure return for the non-existing parts? NIL? An empty list? Or? Thanks in advance. _______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol </pre> Petite Abeille 2012-02-16T21:12:31 http://comments.gmane.org/gmane.mail.imap.general/2909 <pre>Is there a good way to identify the first message that is &gt;= a UID, or that does not have a flag set? It's possible to SEARCH for all messages that satisfy those criteria, but in a large mailbox the response may be large. So it seems desirable to limit the response to the first, or at least to a small subset. http://tools.ietf.org/html/rfc2683 recommends, e.g., FETCH 1:50; FETCH 51:100 to break requests into chunks. While that will work with SEARCH too, if the first relevant message has sequence number 14,000, the search will waste effort getting empty results. Or is this unnecessary, it being safe to ask for and receive a large list of UIDs? I will eventually want to process them all, and I could break into chunks when I FETCH without doing so when I SEARCH. Thanks for any advice. Ross Boylan _______________________________________________ Imap-use mailing list Imap-use&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-use </pre> Ross Boylan 2012-02-14T19:07:08 http://comments.gmane.org/gmane.mail.imap.general/2906 <pre>I've given up on the IMAP5 mailing list going endlessly around in circles, though I'm definitely going to read through the backlogs and remind myself again what everyone spoke about, because there was some excellent discussion. So - I will build something and prove that it's good by showing improved user experiences. And I'm happy to keep talking here on these mailing lists too. I've started a wiki page: http://imapwiki.org/ReplacementProtocol and plan to blog about what I'm doing on our own (Opera's) blogging platform, to practice using it: http://my.opera.com/brongondwana/blog/ I plan to make on a protocol which can replace IMAP in most of its current uses. I want to get (at least) two working server implementations, and two working clients. I have at least in-principle support from enough project maintainers to do that. My strong philosophical ideals are: * Simple to build clients - morons welcome. If it's not clear the right way to do something to someone just reading a protocol dump, we haven't done a good enough job. We can't expect you to read 30 RFCs and resolve their conflicts yourself before starting coding, and we won't insult you if you didn't get it right. Where there is necessary complexity, the server authors bear the brunt. * Server side data model compatible with IMAP4 + extensions; we need to be able to co-exist. * Handle disconnection more gracefully - able to cheaply resync state (I plan to reuse the QRESYNC/CONDSTORE logic here - the model is sane). Getting reliable updates on mailbox state changes should not require a continuous connection. * Easy to proxy - regular syntax (UTF-8 for all communications where possible, but won't screw about trying to "fix" MIME - message file format will remain unchanged) * NO MAGIC - everything is explicitly requested. No UNSELECT/CLOSE/ SELECT another mailbox special behaviours, no implicit FETCH + SET \Seen, no pre-calculated "UNSEEN X" that wasn't asked for. (This probably means some way to compose actions and fetches, but it's better than being complex and magical. Remember our friends the morons.) * COMPLETE TEST SUITE that exercises every constraint in the spec, both positive and negative constraints. An implementation which passes the tests is compliant. An implementation which doesn't is not. This is much more likely to produce inter-operable implementations than a wordy spec ... ... if the authors want inter-operability that is. Nothing can protect against a deliberate embrace and extend - though negative constraint tests (MUST NOT) should help. I would love input. I spent most of the time at FOSDEM this year talking to other people involved in email about these ideas. I quite like the mailbox model behind IMAP, but I want to address the pain points I have seen so many times over the years. Snide comments from those who don't agree with the goals are welcome too... I just won't listen to you. These goals are very important to me. Regards, Bron. </pre> Bron Gondwana 2012-02-08T20:15:26 http://comments.gmane.org/gmane.mail.imap.general/2905 <pre>I'm curious to know what the implementation limits are on servers that support the Metadata extension. I would appreciate it if the server authors out there could take a minute to fill out this survey. I will send a summary to the list once the responses trickle off. (If you want your results to be anonymous, say so in the comments.) Thanks, --lyndon Implementation name and version: Do you support /private?: Do you support /private/vendor?: Do you support unsolicited Metadata responses without values?: Do you support unsolicited Metadata responses with values?: Maximum number of annotations per mailbox: Maximum size of an &lt;entry&gt;: Maximum size of a &lt;value&gt;: Maximum depth supported in &lt;entries&gt;: Other comments:_______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol </pre> Lyndon Nerenberg 2012-02-07T19:55:50 http://comments.gmane.org/gmane.mail.imap.general/2900 <pre>I have just come across an IMAP client, ibisMail, that sends FETCH n BODY[1.MIME] commands for single-part messages. If memory serves, this is the first time I have seen such behavior and I find myself unclear as to how a server should handle it. It seems especially unclear because, according to RFC 3501, "MIME" in a FETCH BODY is disallowed without a part specifier but, in this case, it seems that a BODY[1.MIME] would be equivalent to BODY[MIME] were that allowed. One could read this as indicating that BODY[1.MIME] in this context is not considered a proper use of the protocol. And, while I do not recall, that may be how I interpreted matters when I wrote my server because it responds with NIL. But that, evidently, is not what this client expects. Considering the case when the MIME part is anything bar a message, it seems reasonable either to send the full header section of the message (as I observe the Cyrus server does) or to send just the MIME headers extracted from the lot. But if the latter is appropriate then, if I extract all "MIME-Version:" and "Content-&lt;anything&gt;:" headers, is that guaranteed to be inclusive enough? And what about the case when the single part is, say, of type "message/rfc822"? There I am completely lost! Pete Maclean _______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol </pre> Pete Maclean 2012-01-24T15:39:30 http://comments.gmane.org/gmane.mail.imap.general/2893 <pre>I have been tasked to identify which IMAP servers support the SASL concept of authorization vs. authentication ID and if it is suitable to allow impersonation; that is to proxy to various user accounts. I have the following data: Panda IMAP:Yes ;; Authenticated userids in system group "mailadm" may authorize ;; to any other userid. UW IMAP:Yes, in newer versions ;; Same as Panda Probably yes, but not sure and need details: Cyrus: Dovecot: Communigate Pro: Sendmail: Zimbra: </pre> Mark Crispin 2012-01-13T15:44:13 http://comments.gmane.org/gmane.mail.imap.general/2888 <pre>I'm re-implementing my threading code, and I had a question about the language about "normalized message IDs" found in RFC 5256. That seems to refer to section 3.6.4 of RFC 2822: the implication is that the DQUOTEs in "no-fold-quote" and the "[" and "]" brackets in "no-fold-literal" should be removed before comparing message-ids. Is that correct? Is this spelled out anywhere else? Bill _______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol </pre> Bill Janssen 2012-01-10T00:02:29 http://comments.gmane.org/gmane.mail.imap.general/2888 <pre>I'm re-implementing my threading code, and I had a question about the language about "normalized message IDs" found in RFC 5256. That seems to refer to section 3.6.4 of RFC 2822: the implication is that the DQUOTEs in "no-fold-quote" and the "[" and "]" brackets in "no-fold-literal" should be removed before comparing message-ids. Is that correct? Is this spelled out anywhere else? Bill _______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol </pre> Bill Janssen 2012-01-10T00:02:29 http://comments.gmane.org/gmane.mail.imap.general/2886 <pre>Hello, What's body[n.mime] suppose to return, and when? Given the following message: http://pastebin.com/raw.php?i=M2tTnLEm With the following parts (as reported by reformime [1]): 1 multipart/mixed 1.1 text/plain 1.2 message/rfc822 1.2.1 multipart/report 1.2.1.1 text/plain 1.2.1.2 message/delivery-status 1.2.1.3 message/rfc822 1.2.1.3.1 text/plain When does body[n.mime] apply, and what is it suppose to return? For example, what should one return when asked for body[1.2.mime] vs. body[1.2.header]? Also, is the part numbering as performed by reformime in line with what IMAP part specifiers expects? Thanks in advance. [1] http://www.courier-mta.org/reformime.html _______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol </pre> Petite Abeille 2011-12-21T12:05:23 http://comments.gmane.org/gmane.mail.imap.general/2883 <pre>I'm re-implementing my existing threading per RFC 5256, and I'm looking for some test data sets to test the threading on. That is, collections of messages along with the correct thread structure for both ORDEREDSUBJECT and REFERENCES. Anyone know of such a thing? Bill _______________________________________________ Imap-protocol mailing list Imap-protocol&lt; at &gt;u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol </pre> Bill Janssen 2011-12-16T00:29:01 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.mail.imap.general