similar to: Retrieving unread message count

On Fri, Jul 22, 2016 at 10:18 PM, Corinna Vinschen <vinschen at redhat.com> wrote: [...] > Hmm. If that only affects Cygwin, and if defines.h is not synced anyway, > what about getting rid of the configure stuff entirely? > > Tested counterproposal: Looks reasonable. It's late here so I'm going to look at it tomorrow. > As for the comment preceeding the definition,

On Saturday 04 October 2008 17:05, Chris Lattner wrote: > Looking more closely at the approach, I infer that the (logical in > hindsight) issue are cases where mem2reg scans a BB to see the > relative ordering of two instructions. For example, the single store Correct. > case. I could imagine that if you saw lots of single store allocas in > the middle of a large BB that

RFC 4731: " IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned" https://tools.ietf.org/html/rfc4731 I do this (telnet session): """ a select proveedores/TUHS * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. * 8330 EXISTS * 0 RECENT

On Oct 4, 2008, at 2:51 PM, Chris Lattner wrote: >>> I like your approach of using the use lists but I'm not sure the >>> ordering >>> is guaranteed. If it is, your approach is superior. >> >> I got my patch updated to work with TOT. Here it is. Comments >> welcome. > > Hi Dave, > > Great. I'd like to get this in, but would

I am executing this command below to dovecot-2.3.5-6.cp1178.x86_64 server Notice that some status responses are missing (For folders INBOX.Archive, INBOX.spam.&-BD0EOQQ9BDkEPQ-). I wonder If this is a bug or working as expected In rfc5819 there is this: If the server runs into unexpected problems while trying to look up the STATUS information, it MAY drop the corresponding STATUS reply. In

Hi list, this question is related to the IMAP protocol itself, not really to Dovecot. 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 the selected mailbox and that information sent by a SELECT is enough. My current idea follows these steps : * Issue a

Trying to clean out old undead messages from users to reduce disk space. Need a script that will recurse all the user directories and delete all unread email that is over 90 days old. Anyone have that?

On Monday 06 October 2008 11:47, David Greene wrote: > > As far as the approach goes, here's a counterproposal that is a bit > > less complex. I suggest adding a single DenseMap<Instruction*, > > unsigned> to Mem2reg. If there is an entry in this map for a load/ > > store instruction, it would store the instruction's index in its basic > > block.

On May 1, 2015, at 12:31 PM, Rui Ueyama <ruiu at google.com> wrote: > Proposal > Re-architect the linker based on the section model where it’s appropriate. > Stop simulating different linker semantics using the Unix model. Instead, directly implement the native behavior. Preface: I have never personally contributed code to LLD, so don’t take anything I’m about to say too seriously.

Hello List, I have a problem with the client Roundcube. Whenever I save a draft to the Folder INBOX.Drafts a old mail in my INBOX will be marked as unread. Here are the IMAP Logs from Roundcube and Dovecot debug logs. I have no idea why it happens. The IMAP protocol looks normal to me but as you can see in the second to last line in the Dovecot log Dovecot is changing the flag of an old E-Mail

There is no error in the server logs. I checked those particular folders on the server and they don?t seems to have anything special about them, like permission or etc. Yes, calling STATUS on those particular folders returns the status. The folders can be opened and they have emails in them so nothing special about those folders. # 2.3.5 (513208660): /etc/dovecot/dovecot.conf # OS: Linux

I'm sorry if my suggestion gave an impression that I disregard the Mach-O port of the LLD linker. I do care about Mach-O. I do not plan to break or remove any functionality from the current Mach-O port of the LLD. I don't propose to remove the atom model from the linker as long as it seems to be a good fit for the port (and looks like it is). As to the proposal to have two different

From: Matt Hyclak <hyclak at math.ohiou.edu> > Actually, the more direct replacement would be Dovecot. > Cyrus can be complicated to set up and get running. I actually modified the old UW IMAP 2002 SPEC file from RHL9/FC1, and modified a few config files, to support UW IMAP 2004b. I made one with both RFC3501 (no text passwords over SSL) and non-RFC3501 (legacy, text passwords

Hello, When I upgraded my servers to dovecot 2.2.13 the monitoring tool monit started to send out warnings that it couldn't reach my imap/pop3 servers through ssl any more. The same problem didn't happen on non-ssl-connections. According to people on the monit list this is likely a dovecot issue: https://lists.gnu.org/archive/html/monit-general/2014-06/msg00031.html Let me quote: >

On Fri, Jul 22, 2016 at 12:05:53PM +0200, Corinna Vinschen wrote: [...] > This version doesn't build on Cygwin anymore. The reason is that > various configure tests fail. > > The culprit is the new definition of IPPORT_RESERVED to 0 in configure.ac. Sigh. How about putting it in defines.h instead? includes.h includes netinet/in.h from whence the definition of IPPORT_RESERVED

Hi Timo, We are sitting here wondering if this difference in behaviour between dovecot 2.0.17 and 2.1.3 is intended. When you create a folder, subscribe to it and rename it (without changing the subscription) these are the behaviours: For 2.0.17: . list (SUBSCRIBED) "" "*" RETURN (STATUS (MESSAGES)) * LIST (\Subscribed \NonExistent) "." "INBOX.test"

On 16 Jul 2019, at 9.51, Emil Kalchev via dovecot <dovecot at dovecot.org> wrote: > > I am executing this command below to dovecot-2.3.5-6.cp1178.x86_64 server > > Notice that some status responses are missing (For folders INBOX.Archive, INBOX.spam.&-BD0EOQQ9BDkEPQ-). I wonder If this is a bug or working as expected > > In rfc5819 there is this: > > If the

On Thu, May 7, 2015 at 12:58 PM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Rui, > > Thank you for clarifying. This is very helpful. > > It’s unfortunate that you’re not seeing benefits from the increased > semantic knowledge the atom based model can provide. I know you’ve explored > the issue thoroughly, though, so I understand why you’re wanting to move a >

As suggested by Nir, here: https://www.redhat.com/archives/libguestfs/2019-November/thread.html#00220

Hello Timo, I have scheduled some time to carry through the test requested by Aki. I will add responding to you as part of that process. Not sure if I have said or done anything to offend you, as your tone appears quite abrasive, even where you do not have an actual response to an observation. It is my view that it is a privilege to provide an open source platform, and therefore a