similar to: 1.0-test23 and caching decisions

Hi there, We're trying to convert users from Maildir to sdbox at present; I'm using dsync to achieve this (2.0.16) however when the user's have been converted we only get minimal information in the caching files. Is there some way to preserve all the caching decisions that were previously made so that when the user logs in to the new mailbox we don't have to cause an io storm

Hello, It looks like the "mail_always_cache_fields" and "mail_never_cache_fields" can be used to control dovecot's caching decisions. I cannot seem to find any documentation regarding how these fields should be used. What are acceptable values for these fields? I am quite new to this so any help would be much appreciated. Regards, Siva -------------- next part

On 19.03.2018 05:14, Sivathmican Sivakumaran wrote: > Hello, > > It looks like the "mail_always_cache_fields" and > "mail_never_cache_fields" can be used to control dovecot's caching > decisions. I cannot seem to find any documentation regarding how these > fields should be used. > > What are acceptable values for these fields? I am quite new to this

http://dovecot.org/test/ Pretty much the only change since test24 is a redesign of how cache file writing works. Reading works as before - without locks. Before (in 1.0-tests, 0.99 was worse) we used to just try to lock it. If it failed, we just didn't update cache. If it didn't fail, the lock could have been kept a long time. For example if a user was downloading a 10MB mail, the

I am moving from and old FC2 system to a new RHEL5 system and am having trouble getting the UIDLs to move over right, mainly the UID. I copy over the mailbox, and see the x-uid in the message is what it was on the old server, but when I telnet in to check pop, it rewrites x-uid in the message to something new, causing old messages to get downloaded again, which is not what we want I have tried

In in-place mode, the decisions on which interfaces to use are made and the source configuration is created by the outside entity. So in that case v2v needs to look it up in the source configuraion, and try to follow. For that, the source configuration is used to populate requested caps object which is then passed to the convert routine. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>

In in-place mode, the decisions on which interfaces to use are made and the source configuration is created by the outside entity. So in that case v2v needs to look it up in the source configuraion, and try to follow. For that, the source configuration is used to populate requested caps object which is then passed to the convert routine. Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>

Hello guys, Should the following configuration: mail_cache_fields = flags,imap.body,imap.bodystructure mail_always_cache_fields = imap.body,imap.bodystructure have an effect on the following command? doveadm index -u bob INBOX It seems to have no effect for some reason. Regards, Siva -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 06/10/2015 01:54 AM, Ady via Syslinux wrote: > > Hi Peter, > > Thank you. > > Moving from gitweb-caching to cgit causes most http(s) links that are > already pointing to git.zytor.com to fail with the message "Invalid > request". > > Such links might exist in bug reports, mailing lists, documentation, > and wiki pages; certainly in those that

On Sat, Feb 20, 2016 at 11:26:10AM +0300, Roman Kagan wrote: > In in-place mode, the decisions on which interfaces to use are made and > the source configuration is created by the outside entity. So in that > case v2v needs to look it up in the source configuraion, and try to > follow. > > For that, the source configuration is used to populate requested caps > object which

Hi Milo?, unfortunately, I have no X-UIDL header in my mailboxes. Thank you >----Messaggio originale---- >Da: ghostlovescorebg at gmail.com >Data: 13/12/2014 10.25 >A: "absolutely_free at libero.it"<absolutely_free at libero.it>, <dovecot at dovecot. org> >Ogg: Re: Duplicate messages > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA256 > >On

Hello, I am in the process of migrating a hosting setup from UW-IMAP to Dovecot. The protocols available to mail clients are IMAP and POP3 both before and after migration. I also wanted to change the mail storage format from MBOX to Maildir. However, at this point I hit a major snag with Dovecot and POP3 UIDL (unique identification listing for POP3 mailboxes). Several of the customers connecting

Hello, I have a serious problem with dovecot and mbox format. dovecot returns the same UIDL for new messages and as result some MUAs don't retrieve new mail. UIDs returned by UIDL command look like 000000*1c*49006cec And there is a moment when dovecot stops incrementing marked digits. In other words when new message arrive to mbox, UIDL command returns used UID. I'll show with example:

On Mon, Feb 22, 2016 at 03:04:57PM +0000, Richard W.M. Jones wrote: > On Sat, Feb 20, 2016 at 11:26:10AM +0300, Roman Kagan wrote: > > In in-place mode, the decisions on which interfaces to use are made and > > the source configuration is created by the outside entity. So in that > > case v2v needs to look it up in the source configuraion, and try to > > follow. >

Hi, I'm trying to migrate from maildir to mdbox while preserving the pop3 UIDL (and the imap UID). The problem is, for maildir we use (for compatiblity with qpopper): pop3_uidl_format = %f Problem is, as soon as I convert that to mdbox, then whenever a client issues the UIDL command via a POP connection, the connection is closed and this error is displayed in the log: Error: UIDL: File

I've got a weird split setup where POP3 is currently handled by Courier (courier-imap-3.0.2 distribution), and IMAP is currently handled by the RHEL 5 version of Dovecot (1.0.7) I'm trying to figure out a way to convert the POP3 UIDLs (in cases where the courierpop3dsizelist is newer than dovecot-uidlist, at least) to something that Dovecot will read, or to configure Dovecot's pop3 to

Hi all, attached is a patch against 0.99.10.4 that fixes the STAT, LIST and UIDL POP3 command output in the case that they're issued after one or more messages have been deleted. Examples of incorrect behavior (bad spots marked with '***') C: STAT S: +OK 2 806 C: LIST S: +OK 2 messages: S: 1 403 S: 2 403 S: . C: UIDL S: +OK S: 1 1076749908.12

Hi, We're upgrading a cluster of servers from v1.0.15 to v1.1.x or v1.2.x. It appears that the UIDL generation mechanism has changed, and thus we'll be getting POP3 dups with users that leave mail on server (which is a nasty practice, I know). From checking the sources, and performing a number of controlled tests in various scenarios, here is the outcome: upgrade from 1.0.15 to

hi all, this is needed to make the pop3_reuse_xuidl option work in 1.0alpha4. I am using maildir and I noticed that for each message which doesn't have an indexed X-UIDL header, the entire message is read from disk. as this is reading only headers, it is probably reasonable to stop reading at the end of the headers. it would also be neat if dovecot could be configured to only try reading

Hello All! I am new to this list so I hope I'm not in the wrong list with my question. First, I have to say that dovecot is (in my opinion) one of the best POP3/IMAP servers arround. I especialy like its' simplicity (configuration) and powerfullness (speed, auth mechs). In my production environment I would like to cange from tpop3d to dovecot, but I have only one little problem :).