Re: imap impersonate
wow...I just found that in Java is already implemented:
Properties props=System.getProperties();
props.setProperty("mail.imap.sasl.authorizationid","targetmail...@domain.tld" );
Session session=Session.getInstance(props);
Store store=session.getStore("imap");
store.connect("host",143,"adminuser","adminpass");
there you go with the session on the targetmailbox ;)
Thanks a lot!
Gabriele
Sonicle S.r.l.
:
http://www.sonicle.com
Music:
http://www.gabrielebulfon.com
Quantum Mechanics :
http://www.cdbaby.com/cd/gabrielebulfon
--
Da: Michael Menge
A: Gabriele Bulfon
Cc: info-cyrus@lists.andrew.cmu.edu
Data: 19 gennaio 2017 13.14.13 CET
Oggetto: Re: imap impersonate
Quoting Gabriele Bulfon
:
Thanks,
my imapd.conf has already :
admins: sonicle
sasl_mech_list: plain
if I try an imap session with:
A01 AUTHENTICATE PLAIN
+
xxx
where xxx comes from 'echo -en "\0sonicle\0pass" | base64' , I
get authenticated as sonicle.
Now, how do I switch to the desired user?
Once I understand how to do it via imap protocol, I need to
replicate it in java code through:
store.connect(host,143,user,pass);
Thanks in advance!
Gabriele
Quoting from https://tools.ietf.org/html/rfc4616
2. PLAIN SASL Mechanism
The mechanism consists of a single message, a string of [UTF-8]
encoded [Unicode] characters, from the client to the server. The
client presents the authorization identity (identity to act as),
followed by a NUL (U+) character, followed by the authentication
identity (identity whose password will be used), followed by a NUL
(U+) character, followed by the clear-text password. As with
other SASL mechanisms, the client does not provide an authorization
identity when it wishes the server to derive an identity from the
credentials and use that as the authorization identity.
so it is UserID\0AdminID\0AdminPass
M.MengeTel.: (49) 7071/29-70316
Universität Tübingen Fax.: (49) 7071/29-5912
Zentrum für Datenverarbeitung mail:
michael.me...@zdv.uni-tuebingen.de
Wächterstraße 76
72074 Tübingen
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: imap impersonate
Thanks, my imapd.conf has already : admins: sonicle sasl_mech_list: plain if I try an imap session with: A01 AUTHENTICATE PLAIN + xxx where xxx comes from 'echo -en "\0sonicle\0pass" | base64' , I get authenticated as sonicle. Now, how do I switch to the desired user? Once I understand how to do it via imap protocol, I need to replicate it in java code through: store.connect(host,143,user,pass); Thanks in advance! Gabriele Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon -- Da: Michael Menge via Info-cyrus A: info-cyrus@lists.andrew.cmu.edu Data: 19 gennaio 2017 9.53.51 CET Oggetto: Re: imap impersonate Quoting Gabriele Bulfon via Info-cyrus : Hi, is there any mechanism with Cyrus imap to impersonate another user? I've seen other imap servers scenarios where one may use plain authentication and sending user as mailboxuser plus a separator plus adminuser and use only adminpassword, to get access to the mailboxuser as is (dovecot, exchange). Anything like this in Cyrus? Gabriele Cyrus can use the PLAIN mech to allow admin access as the user. You need to add plain to sasl_mech_list in imapd.conf And the "admin" account has to be listed in admins or proxyservers in imapd.conf Regards, Michael M.MengeTel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.de Wächterstraße 76 72074 Tübingen Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
imap impersonate
Hi, is there any mechanism with Cyrus imap to impersonate another user? I've seen other imap servers scenarios where one may use plain authentication and sending user as mailboxuser plus a separator plus adminuser and use only adminpassword, to get access to the mailboxuser as is (dovecot, exchange). Anything like this in Cyrus? Gabriele Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: thread=refs
Moving to 2.5 at the moment The it's a little bit to much work. I will consider
it later.
So I'm trying to backport your patches to 2.4.12.
The function index_msgdata_free is not a "for" cycle in 2.4.12, but a single
call to one md instance:
/* * Free a msgdata node. */static void index_msgdata_free(MsgData *md){#define
FREE(x) if (x) free(x)int i;if (!md)return;FREE(md-cc);
FREE(md-from);FREE(md-to);FREE(md-displayfrom);FREE(md-displayto);
FREE(md-xsubj);FREE(md-msgid);for (i = 0; i
nref; i++)free(md-ref[i]);FREE(md-ref);for (i = 0; i
nannot; i++)free(md-annot[i]);FREE(md-annot);
}
where should I place the "if (!md) continue;" in this case?
I cannot find any other similar for cycle calling this function.
Thanks for your help
Gabriele
Sonicle S.r.l.
:
http://www.sonicle.com
Music:
http://www.gabrielebulfon.com
Quantum Mechanics :
http://www.cdbaby.com/cd/gabrielebulfon
Da:
Ken Murchison
A:
gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu
Data:
19 luglio 2016 18.00.28 CEST
Oggetto:
Re: thread=refs
On 07/19/2016 11:49 AM, Gabriele Bulfon wrote:
I found thatexpecially the function "_index_thread_ref" is quite
different(arguments and implementation) in 2.4.12, while it's very
similar in 2.5.8 : is it safe to upgrade binaries from 2.4.12 to2.5.8
on a running system, or do I need any kind of conversion?
doc/install-upgrade.html
Also, the diffaround "index_msgdata_free" where "if (!md) continue;" is
added,is quite different from 2.5.8 too, but it's probably not
necessary, as far as I can see...can you check this?
It is necessary. It would be necessary in 2.5.8 if this patch wereto be
backported.
Sonicle S.r.l.
:
http://www.sonicle.com
Music:
http://www.gabrielebulfon.com
Quantum Mechanics :
http://www.cdbaby.com/cd/gabrielebulfon
Da:
Ken Murchison
A:
gbul...@sonicle.com
info-cyrus@lists.andrew.cmu.edu
Data:
19 luglio 2016 15.02.36 CEST
Oggetto:
Re: thread=refs
I don't think much has changed in the threading code for a while. I
would expect that the patch would apply pretty cleanly to 2.4.x.
On 07/19/2016 02:58 AM, GabrieleBulfon wrote:
Wow! Thisis really interesting!
Whatminimum version of cyrus sources can I use for these
changes?
At themoment I'm running servers with 2.4.12, on our illumos
based distro XStreamOS.
Sonicle S.r.l.
:
http://www.sonicle.com
Music:
http://www.gabrielebulfon.com
Quantum Mechanics :
http://www.cdbaby.com/cd/gabrielebulfon
Da:
Ken Murchison
A:
gbul...@sonicle.com
info-cyrus@lists.andrew.cmu.edu
Data:
14 luglio 2016 17.14.18 CEST
Oggetto:
Re: thread=refs
I went ahead andcommitted an implementation of THREAD-REFS:
https://github.com/cyrusimap/cyrus-imapd/commit/16747e608f32f9dd9348988d3f83cb8f1b037ff6
Per the draft, grouping by subject is skipped andthreads
(toplevel messages) are sorted by INTERNALDATE,while the
messages within the threads are still sortedby SENTDATE.
I confirmed that THREAD=REFERENCES is still correct, butI have
nothing to compare THREAD=REFS results to. Thecurrent threading
in Thunderbird is close, but it mightbe using INTERNALDATE
throughout.
On 07/12/2016 04:44 PM, Ken Murchison via Info-cyrus wrote:
Gabriele,
The attached patch is what I was thinking in terms of
implementation. It skips the grouping by subject for REFS, but
I didn't do the REFS-specific date handling. Contrary to what
the THREAD=REFS draft says, I'm not sure if the special date
handling should be done in step 4 or 6. I would have to did
deeper into the code to see where is belongs.
On 07/08/2016 11:36 AM,Gabriele Bulfon via Info-cyrus wrote:
Mainly web clients, installed clients usually implements
threading internally to overcome problems with the
original references algorithm that is often
confusing.
The problem with references is that it includes
subject grouping, that is an old netscape model of
the 90s: today, we just need references within the
headers ids, or we may take a wrong message in the thread
just because it has a similar subject (for
Re: thread=refs
I found that expecially the function "_index_thread_ref" is quite different (arguments and implementation) in 2.4.12, while it's very similar in 2.5.8 : is it safe to upgrade binaries from 2.4.12 to 2.5.8 on a running system, or do I need any kind of conversion? Also, the diff around "index_msgdata_free" where "if (!md) continue;" is added, is quite different from 2.5.8 too, but it's probably not necessary, as far as I can see...can you check this? Gabriele Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu Data: 19 luglio 2016 15.02.36 CEST Oggetto: Re: thread=refs I don't think much has changed in the threading code for a while. Iwould expect that the patch would apply pretty cleanly to 2.4.x. On 07/19/2016 02:58 AM, Gabriele Bulfon wrote: Wow! This is really interesting! What minimum version of cyrus sources can I use for these changes? At the moment I'm running servers with 2.4.12, on our illumos based distro XStreamOS. Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu Data: 14 luglio 2016 17.14.18 CEST Oggetto: Re: thread=refs I went ahead and committed an implementation of THREAD-REFS: https://github.com/cyrusimap/cyrus-imapd/commit/16747e608f32f9dd9348988d3f83cb8f1b037ff6 Per the draft, grouping by subject is skipped and threads (toplevel messages) are sorted by INTERNALDATE, while the messages within the threads are still sorted by SENTDATE. I confirmed that THREAD=REFERENCES is still correct, but I have nothing to compare THREAD=REFS results to. The current threading in Thunderbird is close, but it might be using INTERNALDATE throughout. On 07/12/2016 04:44 PM, KenMurchison via Info-cyrus wrote: Gabriele, The attached patch is what I was thinking in terms of implementation. It skips the grouping by subject for REFS,but I didn't do the REFS-specific date handling. Contrary towhat the THREAD=REFS draft says, I'm not sure if the specialdate handling should be done in step 4 or 6. I would have todid deeper into the code to see where is belongs. On 07/08/2016 11:36 AM, Gabriele Bulfon via Info-cyrus wrote: Mainly webclients, installed clients usually implements threadinginternally to overcome problems with the original references algorithm that is often confusing. Theproblem with references is that it includes subject grouping, that is an old netscape model of the 90s:today, we just need references within the headers ids,or we may take a wrong message in the thread justbecause it has a similar subject (for example automaticmails with same subjects would be treated as a thread,which is wrong). Now, we'restaring to implement threading view on our web collaboration software, running on cyrus. So we areinvestigating how RoundCube is doing threading on a dovecot installation, and we found it to be the same as the client algrithm of Thunderbird, which is fine.Looking at the protocol, it uses REFS first, probablybecause it has no subject grouping by definition, and itshould have a better date sorting. Should, because Ifound that Dovecot does not sort it reversed... Maybe Iwill ask Dovecot guys why they choose to keep sort same as references: I suspect that claim to support refs, but actually the do the same references functions, but never do subject grouping. Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu Data: 8 luglio 2016 17.17.32 CEST Oggetto: Re: thread=refs On 07/08/2016 11:08 AM,Gabriele Bulfon wrote: Ok, sure, but still two issues remain other than the draft: - we need to get rid of subject grouping in REFS, it only
Re: thread=refs
Wow! This is really interesting! What minimum version of cyrus sources can I use for these changes? At the moment I'm running servers with 2.4.12, on our illumos based distro XStreamOS. Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu Data: 14 luglio 2016 17.14.18 CEST Oggetto: Re: thread=refs I went ahead and committed an implementation of THREAD-REFS: https://github.com/cyrusimap/cyrus-imapd/commit/16747e608f32f9dd9348988d3f83cb8f1b037ff6 Per the draft, grouping by subject is skipped and threads (toplevel messages) are sorted by INTERNALDATE, while the messages within thethreads are still sorted by SENTDATE. I confirmed that THREAD=REFERENCES is still correct, but I havenothing to compare THREAD=REFS results to. The current threading inThunderbird is close, but it might be using INTERNALDATE throughout. On 07/12/2016 04:44 PM, Ken Murchison via Info-cyrus wrote: Gabriele, The attached patch is what I was thinking in terms of implementation. It skips the grouping by subject for REFS, but I didn't do the REFS-specific date handling. Contrary to what the THREAD=REFS draft says, I'm not sure if the special date handling should be done in step 4 or 6. I would have to did deeper into the code to see where is belongs. On 07/08/2016 11:36 AM, GabrieleBulfon via Info-cyrus wrote: Mainly web clients, installed clients usually implements threading internally to overcome problems with the original references algorithm that is often confusing. The problem with references is that it includes subject grouping, that is an old netscape model of the 90s: today, we just need references within the headers ids, or we may take a wrong message in the thread just because it has a similar subject (for example automatic mails with same subjects would be treated as a thread, which is wrong). Now, we're staring to implement threading view on our web collaboration software, running on cyrus. So we are investigating how RoundCube is doing threading on a dovecot installation, and we found it to be the same as the client algrithm of Thunderbird, which is fine. Looking at the protocol, it uses REFS first, probably because it has no subject grouping by definition, and it should have a better date sorting. Should, because I found that Dovecot does not sort it reversed... Maybe I will ask Dovecot guys why they choose to keep sort same as references: I suspect that claim to support refs, but actually the do the same references functions, but never do subject grouping. Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu Data: 8 luglio 2016 17.17.32 CEST Oggetto: Re: thread=refs On 07/08/2016 11:08 AM, Gabriele Bulfon wrote: Ok, sure,but still two issues remain other than the draft: - we needto get rid of subject grouping in REFS, it only brings disorder, merging stuff that is not related I believe that the parameterization of the core functionsshould be able to handle this. - I wouldtry to guess why dovecot does not change sorting in REFS, keeping it same as REFERENCES I would contact that Dovecot authors and find out whichversion of the THREAD=REFS draft they based their work on. BTW, which clients use THREAD=REFS? Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu Data: 8 luglio 2016 16.39.17 CEST Oggetto: Re: thread=refs Is there an actual RFC? All I find is draft-ietf-morg-inthread-01. Looking at that draft,the only difference between REFS ad REFERENCES isthis: THREAD=REFS sorts threads by the most recent INTERNALDATE in eachthread, replacing THREAD=REFERENCES step (4). This means that when anew message arrives, its thread becomes the latest thread. (Notethat while threads are sorted by arrival date, messages within athread are sorted by sent date, just as for THREAD=REFERENCES.) This being the case, I don't think we need two
Re: thread=refs
Mainly web clients, installed clients usually implements threading internally to overcome problems with the original references algorithm that is often confusing. The problem with references is that it includes subject grouping, that is an old netscape model of the 90s: today, we just need references within the headers ids, or we may take a wrong message in the thread just because it has a similar subject (for example automatic mails with same subjects would be treated as a thread, which is wrong). Now, we're staring to implement threading view on our web collaboration software, running on cyrus. So we are investigating how RoundCube is doing threading on a dovecot installation, and we found it to be the same as the client algrithm of Thunderbird, which is fine. Looking at the protocol, it uses REFS first, probably because it has no subject grouping by definition, and it should have a better date sorting. Should, because I found that Dovecot does not sort it reversed... Maybe I will ask Dovecot guys why they choose to keep sort same as references: I suspect that claim to support refs, but actually the do the same references functions, but never do subject grouping. Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu Data: 8 luglio 2016 17.17.32 CEST Oggetto: Re: thread=refs On 07/08/2016 11:08 AM, Gabriele Bulfon wrote: Ok, sure, butstill two issues remain other than the draft: - we need to getrid of subject grouping in REFS, it only brings disorder,merging stuff that is not related I believe that the parameterization of the core functions should beable to handle this. - I would try toguess why dovecot does not change sorting in REFS, keeping itsame as REFERENCES I would contact that Dovecot authors and find out which version ofthe THREAD=REFS draft they based their work on. BTW, which clients use THREAD=REFS? Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu Data: 8 luglio 2016 16.39.17 CEST Oggetto: Re: thread=refs Is there an actual RFC? All I find isdraft-ietf-morg-inthread-01. Looking at that draft, the onlydifference between REFS ad REFERENCES is this: THREAD=REFS sorts threads by the most recent INTERNALDATE in eachthread, replacing THREAD=REFERENCES step (4). This means that when anew message arrives, its thread becomes the latest thread. (Notethat while threads are sorted by arrival date, messages within athread are sorted by sent date, just as for THREAD=REFERENCES.) This being the case, I don't think we need two copies of the threading functions. I'd modify the exiting functions to take an additional parameter to specify whether we're doing REFS or REFERENCES and then have 2 wrapper functions which call the main function with the parameter set appropriately for the given algorithm. On 07/08/2016 10:03 AM, GabrieleBulfon wrote: Ok, it works :) but checking against dovecot implementation, it looks like they have refs order same as references, but without subject grouping. AFAIK the RFC on refs says ordering of dates within the group should be reversed. Am I wrong? Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Gabriele Bulfon via Info-cyrus A: Ken Murchison info-cyrus@lists.andrew.cmu.edu Data: 8 luglio 2016 15.22.56 CEST Oggetto: Re: thread=refs Testing ;) and checking against a dovecot machine with refs and same messages. Will let you know Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com QuantumMechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu Data: 8 luglio 2016 15.02.38 CEST Oggetto: Re: thread=refs On 07/07/2016 02:03 PM, Gabriele Bulfon via Info-cyrus wrote: Ican finally get back to this after so many months! Ichecked the sources, and I actually see it doesn't look very hard. Lookslike
Re: thread=refs
Ok, sure, but still two issues remain other than the draft: - we need to get rid of subject grouping in REFS, it only brings disorder, merging stuff that is not related - I would try to guess why dovecot does not change sorting in REFS, keeping it same as REFERENCES Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu Data: 8 luglio 2016 16.39.17 CEST Oggetto: Re: thread=refs Is there an actual RFC? All I find is draft-ietf-morg-inthread-01. Looking at that draft, the only difference between REFS ad REFERENCES is this: THREAD=REFS sorts threads by the most recent INTERNALDATE in eachthread, replacing THREAD=REFERENCES step (4). This means that when anew message arrives, its thread becomes the latest thread. (Notethat while threads are sorted by arrival date, messages within athread are sorted by sent date, just as for THREAD=REFERENCES.) This being the case, I don't think we need two copies of thethreading functions. I'd modify the exiting functions to take anadditional parameter to specify whether we're doing REFS orREFERENCES and then have 2 wrapper functions which call the mainfunction with the parameter set appropriately for the givenalgorithm. On 07/08/2016 10:03 AM, Gabriele Bulfon wrote: Ok, it works :)but checking against dovecot implementation, it looks like theyhave refs order same as references, but without subject grouping. AFAIK the RFC on refs says ordering of dates withinthe group should be reversed. Am I wrong? Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Gabriele Bulfon via Info-cyrus A: Ken Murchison info-cyrus@lists.andrew.cmu.edu Data: 8 luglio 2016 15.22.56 CEST Oggetto: Re: thread=refs Testing ;) andchecking against a dovecot machine with refs and same messages. Will let youknow Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu Data: 8 luglio 2016 15.02.38 CEST Oggetto: Re: thread=refs On 07/07/2016 02:03 PM,Gabriele Bulfon via Info-cyrus wrote: I can finally get back to this after so many months! I checked the sources, and I actually see it doesn't look very hard. Looks like: - renaming all functions like "index_thread_ref" into "index_thread_references" - duplicate them as "index_thread_refs" - let "references" alg call the "references" funcs - add support for "refs" in thread_algs and let them call the "refs" funcs Makes sense. then: - completely remove the call to "ref_group_subjects", we don't want it at all in refs - change the sortcrit to use the SORT_REVERSE modifier As long as you mean making these changes for just the "refs" variant and not both. what do you think? may be fine? Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com QuantumMechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: info-cyrus@lists.andrew.cmu.edu Data: 5 ottobre 2015 14.04.02 CEST Oggetto: Re: thread=refs As far as Ican tell, the last specification for thread=refs washere: https://tools.ietf.org/html/draft-ietf-morg-inthread-01 To implement this you want to look at index.c in theCyrus source and add another entry to thethread_algs[] array. I'm guessing that you can reusea lot of the existing index_thread_ref() code (whichis probably needs to be renamed toindex_thread_references()). On 10/05/2015 06:07 AM, Gabriele Bulfon wrote: Great, Ken. Can you give me some advice / pointer to the sources I should look at? Gabriele Da: Ken Murchison A: info-cyrus@lists.andrew.cmu.edu Data: 2 ottobre 2015 19.08.04 CEST Oggetto: Re: thread=refs On 10/02/201510:53
Re: thread=refs
Ok, it works :) but checking against dovecot implementation, it looks like they have refs order same as references, but without subject grouping. AFAIK the RFC on refs says ordering of dates within the group should be reversed. Am I wrong? Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Gabriele Bulfon via Info-cyrus A: Ken Murchison info-cyrus@lists.andrew.cmu.edu Data: 8 luglio 2016 15.22.56 CEST Oggetto: Re: thread=refs Testing ;) and checking against a dovecot machine with refs and same messages. Will let you know Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu Data: 8 luglio 2016 15.02.38 CEST Oggetto: Re: thread=refs On 07/07/2016 02:03 PM, Gabriele Bulfon via Info-cyrus wrote: I can finally getback to this after so many months! I checked thesources, and I actually see it doesn't look very hard. Looks like: - renaming allfunctions like "index_thread_ref" into "index_thread_references" - duplicate themas "index_thread_refs" - let "references"alg call the "references" funcs - add support for"refs" in thread_algs and let them call the "refs" funcs Makes sense. then: - completelyremove the call to "ref_group_subjects", we don't want it at allin refs - change thesortcrit to use the SORT_REVERSE modifier As long as you mean making these changes for just the "refs" variantand not both. what do you think?may be fine? Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: info-cyrus@lists.andrew.cmu.edu Data: 5 ottobre 2015 14.04.02 CEST Oggetto: Re: thread=refs As far as I can tell, the last specification for thread=refs was here: https://tools.ietf.org/html/draft-ietf-morg-inthread-01 To implement this you want to look at index.c in the Cyrus source and add another entry to the thread_algs[] array. I'm guessing that you can reuse a lot of the existing index_thread_ref() code (which is probably needs to be renamed to index_thread_references()). On 10/05/2015 06:07 AM, GabrieleBulfon wrote: Great, Ken. Can you give me someadvice / pointer to the sources I should look at? Gabriele Da: Ken Murchison A: info-cyrus@lists.andrew.cmu.edu Data: 2 ottobre 2015 19.08.04 CEST Oggetto: Re: thread=refs On 10/02/2015 10:53 AM, Gabriele Bulfon wrote: Nice, it's not a big deal for us to upgrade to new versions, surely easier than porting to Dovecot! ;) So, maybe we can help with the implementation. In my mind, it's almost about changing the "thread=reference" and let it omit the subject matching, change sorting and...maybe just this? How much hard do you think it is? That sounds about right from what I remember of THREAD=REFERENCES (which I co-authored and implemented)and THREAD=REFS (which I think was last documented in2010). Da: Bron Gondwana A: info-cyrus@lists.andrew.cmu.edu Data: 2 ottobre 2015 12.59.08 CEST Oggetto: Re: thread=refs No, there isn't. The conversations work in3.0 beta contains a lot of what would berequired to efficiently implement THREAD=REFS,but nobody has done the work to implement it. It certainly will never be backported to the2.4 series, which is only getting securityupdates and fixes for major bugs now. Regards, Bron. On Fri, Oct 2, 2015, at 18:40, GabrieleBulfon wrote: Hi, we have systems running cyrus 2.4.12, where thread algorithms are only references and orderedsubject. Is there support for the thread=refs algorithm? Thanks Gabriele Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Bron Gondwana br...@fastmail.fm Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.ed
Re: thread=refs
Testing ;) and checking against a dovecot machine with refs and same messages. Will let you know Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: gbul...@sonicle.com info-cyrus@lists.andrew.cmu.edu Data: 8 luglio 2016 15.02.38 CEST Oggetto: Re: thread=refs On 07/07/2016 02:03 PM, Gabriele Bulfon via Info-cyrus wrote: I can finally getback to this after so many months! I checked thesources, and I actually see it doesn't look very hard. Looks like: - renaming allfunctions like "index_thread_ref" into "index_thread_references" - duplicate themas "index_thread_refs" - let "references"alg call the "references" funcs - add support for"refs" in thread_algs and let them call the "refs" funcs Makes sense. then: - completelyremove the call to "ref_group_subjects", we don't want it at allin refs - change thesortcrit to use the SORT_REVERSE modifier As long as you mean making these changes for just the "refs" variantand not both. what do you think?may be fine? Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: info-cyrus@lists.andrew.cmu.edu Data: 5 ottobre 2015 14.04.02 CEST Oggetto: Re: thread=refs As far as I can tell, the last specification for thread=refs was here: https://tools.ietf.org/html/draft-ietf-morg-inthread-01 To implement this you want to look at index.c in the Cyrus source and add another entry to the thread_algs[] array. I'm guessing that you can reuse a lot of the existing index_thread_ref() code (which is probably needs to be renamed to index_thread_references()). On 10/05/2015 06:07 AM, GabrieleBulfon wrote: Great, Ken. Can you give me someadvice / pointer to the sources I should look at? Gabriele Da: Ken Murchison A: info-cyrus@lists.andrew.cmu.edu Data: 2 ottobre 2015 19.08.04 CEST Oggetto: Re: thread=refs On 10/02/2015 10:53 AM, Gabriele Bulfon wrote: Nice, it's not a big deal for us to upgrade to new versions, surely easier than porting to Dovecot! ;) So, maybe we can help with the implementation. In my mind, it's almost about changing the "thread=reference" and let it omit the subject matching, change sorting and...maybe just this? How much hard do you think it is? That sounds about right from what I remember of THREAD=REFERENCES (which I co-authored and implemented)and THREAD=REFS (which I think was last documented in2010). Da: Bron Gondwana A: info-cyrus@lists.andrew.cmu.edu Data: 2 ottobre 2015 12.59.08 CEST Oggetto: Re: thread=refs No, there isn't. The conversations work in3.0 beta contains a lot of what would berequired to efficiently implement THREAD=REFS,but nobody has done the work to implement it. It certainly will never be backported to the2.4 series, which is only getting securityupdates and fixes for major bugs now. Regards, Bron. On Fri, Oct 2, 2015, at 18:40, GabrieleBulfon wrote: Hi, we have systems running cyrus 2.4.12, where thread algorithms are only references and orderedsubject. Is there support for the thread=refs algorithm? Thanks Gabriele Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Bron Gondwana br...@fastmail.fm Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Kenneth MurchisonPrincipal Systems Software EngineerCarnegie Mellon University Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Kenneth MurchisonPrincipal Systems Software EngineerCarnegie Mellon University Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Kenneth MurchisonPrincipal Systems Softwa
Re: thread=refs
I can finally get back to this after so many months! I checked the sources, and I actually see it doesn't look very hard. Looks like: - renaming all functions like "index_thread_ref" into "index_thread_references" - duplicate them as "index_thread_refs" - let "references" alg call the "references" funcs - add support for "refs" in thread_algs and let them call the "refs" funcs then: - completely remove the call to "ref_group_subjects", we don't want it at all in refs - change the sortcrit to use the SORT_REVERSE modifier what do you think? may be fine? Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Da: Ken Murchison A: info-cyrus@lists.andrew.cmu.edu Data: 5 ottobre 2015 14.04.02 CEST Oggetto: Re: thread=refs As far as I can tell, the last specification for thread=refs washere: https://tools.ietf.org/html/draft-ietf-morg-inthread-01 To implement this you want to look at index.c in the Cyrus sourceand add another entry to the thread_algs[] array. I'm guessing thatyou can reuse a lot of the existing index_thread_ref() code (whichis probably needs to be renamed to index_thread_references()). On 10/05/2015 06:07 AM, Gabriele Bulfon wrote: Great, Ken. Can you give me some advice / pointer to the sources I should look at? Gabriele Da: Ken Murchison A: info-cyrus@lists.andrew.cmu.edu Data: 2 ottobre 2015 19.08.04 CEST Oggetto: Re: thread=refs On 10/02/2015 10:53 AM, GabrieleBulfon wrote: Nice, it's not a big deal for us toupgrade to new versions, surely easier than porting toDovecot! ;) So, maybe we can help with the implementation. In my mind, it's almost aboutchanging the "thread=reference" and let it omit thesubject matching, change sorting and...maybe just this? How much harddo you think it is? That sounds about right from what I remember of THREAD=REFERENCES (which I co-authored and implemented) and THREAD=REFS (which I think was last documented in 2010). Da: Bron Gondwana A: info-cyrus@lists.andrew.cmu.edu Data: 2 ottobre 2015 12.59.08 CEST Oggetto: Re: thread=refs No, there isn't. The conversations work in 3.0 beta contains a lot of what would be required to efficiently implement THREAD=REFS, but nobody has done the work to implement it. It certainly will never be backported to the 2.4 series, which is only getting security updates and fixes for major bugs now. Regards, Bron. On Fri, Oct 2, 2015, at 18:40, Gabriele Bulfon wrote: Hi, we have systems running cyrus 2.4.12, wherethread algorithms are only references andorderedsubject. Is there support for the thread=refs algorithm? Thanks Gabriele Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Bron Gondwana br...@fastmail.fm Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Kenneth MurchisonPrincipal Systems Software EngineerCarnegie Mellon University Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus -- Kenneth MurchisonPrincipal Systems Software EngineerCarnegie Mellon University Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
disable starttls, ssl only
Hi, is it possible to disable completely the starttls option on cyrus imapd? I want just connections on 993 over ssl, no starttls at all. I noticed a number of "Fatal error: tls_start_servertls() failed" and noticed a slow down of the entire machine during these errors. I wouldn't like to have some kind of ddos attak using starttls on 993 or something. Gabriele Sonicle S.r.l. : http://www.sonicle.com Music: http://www.gabrielebulfon.com Quantum Mechanics : http://www.cdbaby.com/cd/gabrielebulfon Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
residual moved folders
Hi, we noticed that when a user moves a big folder in a different tree position, that is shared among many connected users, the original moved folder will be unvisible via imap commands to new connections, but will stay in the filesystem until old connections get closed. All fine. Then, we noticed that sometimes the original moved folders may stay there forever in the filesystem, with all the emails and cyrus files. Dates on files and the folders themselves show that they are not being touched since the moving date, and do not show anymore via imap. Even restarting all the server, those folders remain. How can avoid this situation? What is the possibility of this event? At the moment I am scripting to find all folders that has no "lm" via cyradm. May I feel safe removing physically the residuals found folders? Thanks for any help. Gabriele Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
2.4.12 and folders with spaces and same prefix double
Hi, I don't know if this is is related to bug 3628 ( https://bugzilla.cyrusimap.org/show_bug.cgi?id=3628 ). If I have two main folders: "Test" "Test_2016" I get correct list with LIST "" "%". If I have : "Test" "Test 2016" I get this wrong answer with LIST "" "%": * LIST (\HasNoChildren) "/" Test * LIST (\HasChildren) "/" "Test 2016" * LIST (\HasChildren) "/" Test where some imap tree code may be misleaded by the presence of a double "Test" folder, one with and one without children. Any clue? Gabriele Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
