Re: 2.5.x RPMs from KolabSys?
On 2016-02-12 03:38, Nicola Nye wrote: Hi folks, On a quick uneducated tour around the obs.kolabsys.com site, I get to https://obs.kolabsys.com/package/show/cyrus-imapd:2.5-next/cyrus-imapd and if you follow the links per platform on on the right hand side, it does take you to a page which seems to have downloadable tarballs. They don't seem to have been rebuilt in a long while, and many platforms have build errors, so YMMV with how much use it is. Jeroen is listed as the maintainer; he may know more. Hey folks, I do know more; I run both the OBS, do the packaging and such and so forth. It's therefore also my fault that I'm not paying as much to these branches. I wasn't under the impression anyone was actually interested in using these packages, and it was originally created as a verification step in development, more than the intended distribution channel for Cyrus IMAP. That is to say, we ship some of the latest and greatest with our own product, which is also where I spend most of my time. 2.4-next, 2.5-next and master project builds are supposed to be triggered as part of Continuous Integration -> Continuous Delivery. I have, since I've started with all of this, written a variety of scripts necessary to check stuff back in to the build system -- but I have not applied that to the cyrus-imapd build projects. Leaves me to wonder whether these packages are actually used by some or the other significant number of deployments? Kind regards, Jeroen van Meeuwen -- Senior Solutions Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +41 79 951 9003 w: https://kolabsystems.com pgp: 9342 BF08 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: The admins key on imapd.conf
On 2015-03-10 20:25, Niels Dettenbach wrote:
Am Dienstag, 10. März 2015, 17:48:44 schrieb Manuel Vazquez:
I understand by the official documentation,this users described there
are
can see the mailboxes of the all the users present in the server.
Do it is correct?
Beside this, the admin user(s) are able to create mailboxes / folders
and
maintaining access rights and quotas including delete folders after
setting
the appropiate rights to it.
It is important to understand the role of the admin user - without i
assume it
would be nearly impossible to set up and maintain a cyrus setup.
True, but for the autocreate feature set we have today ;-)
It needs to be understood that any user listed in `admins` setting has
-- implicitly -- the 'a' right on *all* mailboxes.
The 'a' right does not imply any other rights ('l', 'r', 's' most
prominently, though an admin doesn't require 'l' specifically in order
to be able to have a mailbox appear in a list of mailboxes), but does
impose the right to SETACL (including 'l', 'r' and 's', and whichever
other ones!).
`admins` should be limited very, *very* much, to a rather select group
of people/services with a proverbial ``$surname-admin`` account -- it is
the sysadmin/root equivalent of a system otherwise normally a sealed
system.
Kind regards,
Jeroen van Meeuwen
--
Systems Architect, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
m: +41 79 951 9003
w: https://kolabsystems.com
pgp: 9342 BF08
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 archive?
On 2015-03-05 16:02, Dan White wrote: On 03/05/15 13:53 +0100, Marco wrote: I read in docs that with Cyrus-Imapd I can create a folder Archive with no quota for each user, using a dedicated partition. Assuming you have a quota root set for each user's INBOX, you would need to explicitly set a higher quota value for any such archive folder, if it exists hierarchically underneath the INBOX. More specifically, you need to create a quota root on the Archive folder (however it be named) so that it is no longer a part of the original INBOX quota root, and you could set the Archive folder's quota root storage quota to be '-1', aka. 'unlimited'. Separately, you could make the Archive folder (however it be named) end up on a separate partition or even a separate server/partition, so that it is abundantly less resource-rich than your average INBOX server(s)/partition(s). You would typically restrict your users to, say, 1GB of storage space, and hence force them to archive mail at a reasonable point in time -- or risk run out of storage quota. If the only place they can archive *to* just so happens to be this Archive folder that is located on a cheaper/slower set of disks, then maybe that's just what you wanted. Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +41 79 951 9003 w: https://kolabsystems.com pgp: 9342 BF08 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
Documentation on Other Linux Distros
Hi there, Please pardon the cross-posting, but I'm going to need as broad an audience I can get. My personal corner of the universe is squarely within the RPM(4) based systems on this globe, and as such I've written up the bare necessities to get from a yum install to a successful IMAP login: https://docs.cyrus.foundation/imap/installation/distributions/centos.html Some of you will have noticed that Linux distros like Debian, Ubuntu and openSUSE have not (at all) been documented to the same standard (I use this term loosely). The same, in fact, goes for the DIY installation guide [1] (where all dependency names are RPM(4)-based platform package names) and the custom version guide(s) for each platform -- as well as the hints for packagers for that matter. I would like to not be as ignorant as I seem, and therefore I'm asking for your help in composing the notes on what is necessary to get from an apt-get or zypper install to a successful IMAP login for your favourite platform -- including those not currently listed. I'll take anything from a few scribbles on the mailing-list to a patch review in Phabricator, and I think the CentOS/RHEL guide is quite that bare minimum effort we're looking to document (based on the current codebase). Thanks in advance, Kind regards, Jeroen van Meeuwen [1] https://docs.cyrus.foundation/imap/installation/diy.html -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +41 79 951 9003 w: https://kolabsystems.com pgp: 9342 BF08 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 IMAP 2.5.0 released
The Cyrus team is proud to announce the immediate availability of a new version of Cyrus IMAP: 2.5.0. This release introduces a new product series, and marks the start of the team using new tooling to facilitate our continued development and support for Cyrus IMAP. Of many major highlights, this release includes: - CalDAV and CardDAV support - Event Notifications Download URLs: http://www.cyrusimap.org/releases/cyrus-imapd-2.5.0.tar.gz http://www.cyrusimap.org/releases/cyrus-imapd-2.5.0.tar.gz.sig ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.5.0.tar.gz ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.5.0.tar.gz.sig Please consult the release notes before upgrading to 2.5.0: https://docs.cyrus.foundation/imap/release-notes/2.5-current.html And join us at https://git.cyrus.foundation/ to report issues, join in the deliberations of new features for the next Cyrus IMAP release, and to contribute to the documentation. On behalf of the Cyrus team, Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +41 79 915 9003 w: http://www.kolabsys.com pgp: 9342 BF08 signature.asc Description: This is a digitally signed message part. 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: Possible TLS dir option name discrepancy?
On 2015-01-12 13:23, Patrick Goetz wrote: The 2.5 documentation here (http://www.cyrusimap.org/~vanmeeuwen/imap/release-notes/2.5.0.html) states that some of the TLS options will change in 2.5, namely tls_client_ca_dir (was: tls_ca_dir) However, there is no tls_ca_dir option given here (https://cyrusimap.org/docs/cyrus-imapd/2.4.17/man/imapd.conf.5.php). I've been using tls_ca_path as per the 2.4.17 man page. Am I missing something, or is this just a typo in the 2.5 documentation? Typo. Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +41 79 951 9003 w: https://kolabsystems.com pgp: 9342 BF08 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: POLL: per-domain shared folder/sieve/etc
On 2014-11-01 21:29, Bron Gondwana wrote: We already have one at FastMail to stop users setting an 'anyone' ACL. I think this may already be in upstream, unless you're talking about a different implementation/solution? http://git.cyrusimap.org/cyrus-imapd/tree/lib/imapoptions#n179 This is all, obviously, Cyrus 3.0 stuff. In the multi-domain environments we typically run, while sharing between domains is indeed an often requested feature, we love the inability to share cross-realm -- preventing accidentally sharing your @company.com content with @competitor.com people. Yes, that's pretty dangerous, isn't it. If the new way of doing things is to allow cross-realm sharing, I would like to ensure some sort mandatory access policy is in place, where one has to specify @something can in fact share with @else. This is tricky, particularly for FastMail where multiple companies can have addresses in the shared domains (e.g. fastmail.com) as well. It sounds like the right general approach is to allow an external daemon to be queried for policy responses. I suppose the level of complexity depends on the level of flexibility / features required. Suppose that the default is to not have any realm be allowed to use any other realm (no other realm's mailboxes are visible, no ACL subject identifiers validate). This, I would say, represents the current situation most accurately. Suppose a list of source realms (the authenticated user is in this realm) is used as a lookup key, and for any other realm that realm must have presence in the lookup value) -- admittedly a very simplistic view: company.com: subsidiary.com partner.com subsidiary.com: company.com partner.com: company.com competitor.com competitor.com: partner.com Suppose this means that @company.com people (source, lookup key) can share @company.com mailboxes (source, lookup key, must match logged in account?) with @subsidiary.com and with @partner.com ACL subject identifiers. Suppose this means @partner.com (target lookup value) can therefore see @company.com mailboxes -- but cannot share with @company.com because of the first rule, but because of the third rule. I do not suppose there is any use-case to nesting such rules to the tune to, in the above list, allow subsidiary to partner descending to company authorizations (or any other way). I suppose in the case of FastMail, you would list fastmail.com as a lookup key and perhaps use a regular expression .* to ensure @fastmail.com mailboxes are visible to all other realms? Of course, to a certain degree this is trying to make a technical solution to a human problem. If it's that vital that they can't see each other, they should be on separate Cyrus instances at the very least, if not entirely separate infrastructure. There's nothing to stop mall...@example.org just adding a sieve rule to forward a copy of everything to j...@company.com, or handing over credentials, or any number of things. I agree with the general sentiment, but disagree with such separation on the infrastructure level being that kind of a must (for that level of vital). There are other considerations that could require an organization to have infrastructure isolated from a multi-customer hosted environment, but such are in the gut-feeling-more-so-than-technical-literacy, compliance and telco regulatory domains. While to share or not is certainly a social problem, and to enable sharing or not probably is so too, to allow sharing or not is definitely a more technical one if the implementation thereof leaves behind a Free-for-All. For Sieve rules forwarding content, cross-realm ACLs are rather irrelevant. One could (define to) forward content using Sieve regardless, unless Cyrus IMAP's Sieve implementation is extended to allow a similar level of access control. The current methodology to prevent this from happening lays in limiting the user interfaces, not including Sieve extensions, MTA configuration and Data-Loss Prevention systems -- neither of which are helped or negated by introducing cross-realm ACLs, and neither of which requires a given customer to run off of completely separate infrastructure. Should sharing across domains be allowed, but without mandatory access control, however, then you move Cyrus IMAP from the perfect for hosted environments with multiple customers universe to the it's such a Free-for-All you require separate infrastructure for each customer. On 2014-10-24 02:59, Bron Gondwana wrote: No, the per-user namespace is still fine - users can still share with other users in their own domain - just currently it is technically impossible to share with users in other domains right now - because the mailbox naming is not RFC compliant, so it's not compatible with real IMAP client, only with Cyrus management tools. You mentioned in another post (quote above) that the current naming of mailboxes is not necessarily
Re: POLL: per-domain shared folder/sieve/etc
On 2014-10-22 23:02, Bron Gondwana wrote: Yes, that means a massive change, instead of internally: example.com!user.foo.bar = user/foo/b...@example.com (which is a million ways of bogus) we would have: user.foo@example^com.bar = user/f...@example.com/bar Or in alt namspace: Other Users/f...@example.com/bar This means we will finally be able to share things across domains. It creates a single consistent way to access everything. The domain used to be used as an authorization realm, where a user j...@example.com would only see Other Users/foo/bar -- without the domain. How would this translate to the new way? If the external name (the new default) uses unix hierarchy separators, would it be reasonable to update the internal format to that as well, and translate user/foo/b...@example.org or user/f...@example.org/bar back to using the netnews hierarchy separator if so configured? The problem is, it means you can't set quotas per domain, you can't have sieve scripts per domain, and most of all - you can't have shared folders in a domain. example.com!shared.stuff worked fine, but shared.example^com.stuff would be weird. It's just a folder, and wouldn't be treated specially in any way. The domain would have no special meaning. This is now shared/st...@example.org, I suppose a hierarchy of such folders would lead to shared/st...@example.org/something? This is all, obviously, Cyrus 3.0 stuff. In the multi-domain environments we typically run, while sharing between domains is indeed an often requested feature, we love the inability to share cross-realm -- preventing accidentally sharing your @company.com content with @competitor.com people. If the new way of doing things is to allow cross-realm sharing, I would like to ensure some sort mandatory access policy is in place, where one has to specify @something can in fact share with @else. On 2014-10-24 02:59, Bron Gondwana wrote: No, the per-user namespace is still fine - users can still share with other users in their own domain - just currently it is technically impossible to share with users in other domains right now - because the mailbox naming is not RFC compliant, so it's not compatible with real IMAP client, only with Cyrus management tools. You mentioned in another post (quote above) that the current naming of mailboxes is not necessarily RFC-compliant, and that only the Cyrus tooling is compatible. I may be misunderstanding what this means, because only an administrator without a realm (as part of its login username) is currently able to view lists of mailboxes across realms -- bear with me while I transcribe from the top of my head: Settings: virtdomains: userid admins: cyrus-admin ad...@example.org cyrus-admin: C: . LIST * S: * user/j...@company.com S: * user/j...@example.org S: * user/m...@example.org ad...@example.org: C: . LIST * S: * user/jane S: * user/max j...@example.org: C: . LIST * S: * INBOX S: * Other Users/max Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +41 79 951 9003 w: http://www.kolabsys.com pgp: 9342 BF08 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: Patch for adding tls_honor_cipher_order
On 2014-10-23 16:04, Wolfgang Breyha wrote:
Kristian Kræmmer Nielsen wrote on 17/10/14 15:13:
The more important part of my previous mail are that there are issues
with
the patches that now have been merged into git. E.g. compression is
not
merged correctly and it is recommended to do negative list and not
positive lists of protocols.
Yes, you're right. The patches in master tree have broken logic...
Option documentation says:
tls_versions: ssl2 ssl3 tls1_0 tls1_1 tls1_2
Disable SSL/TLS protocols not in this list.
Code says:
+ if (strstr(tls_versions, tls1_2) == NULL) {
+#if (OPENSSL_VERSION_NUMBER = 0x1000105fL)
+ off |= SSL_OP_NO_TLSv1_2;
+#else
+ syslog(LOG_ERR, ERROR: TLSv1.2 configured, OpenSSL 1.0.1e
insufficient);
+#endif
+ }
Setting the NO_TLSv1_2 option does the opposite of the expected/wanted
behavior.
You're aware though, that for the code to set NO_TLSv1_2 you would need
to explicitly set a list of TLS versions that does not include tls1_2,
such as:
tls_versions: sslv2 sslv3 tls1_0 tls1_1
Let's not forget the code starts off with SSL_OP_ALL -- probably also
not the best of ideas.
Should newer versions arrive (say, tls1_3), it would not be suppressed
(the corresponding NO_TLSv1.3 flag would not be set) until after *both*;
imap/tls.c is updated to handle a new value for the setting, and your
configuration is not updated (to include the new value tls1_3 for it
would otherwise be suppressed).
I also would prefer a negative list as most other daemons like
apache, exim, ... use. Maybe a more generic
tls_openssl_options: no_ssl2 no_ssl3 no_compression
prefer_server_cipher_order
would be better?
A better way of specifying TLS versions would certainly be appreciated,
especially if the list of options translates to openssl flags directly,
so we don't have to patch/rebuild every time the flags change in order
to allow newer/better versions.
I recall needing to upgrade Apache httpd from version 2.2 to 2.4 in
order to be able to add -TLSv1.1:
SSLOptions all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
or, for that matter:
SSLOptions TLSv1.2
as neither flags were supported by httpd 2.2 -- admittedly, I could have
backported the fix/enhancement rather than upgrade.
Anyway, it's one of the things I wanted to prevent having to do in Cyrus
IMAP.
And yes, you're also right with mentioning that functionality is
missing.
tls_compression: 0
Enable TLS compression. Disabled by default.
This has been an oversight on my part.
tls_eccurve: prime256v1
Select the elliptic curve used for ECDHE.
description is there, but there is no code doing it actually. Support
for ECDH
auto mode in Openssl 1.2+ as provided in
https://bugzilla.cyrusimap.org/attachment.cgi?id=1535
is missing in the documentation as well.
This patch and various other patches from different people in different
tickets did not really mix well. Along with the tls_compression having
been omitted, I did not consider documenting auto as a valid
configuration value.
I'm also not sure what you mean by OpenSSL 1.2+ -- do you mean OpenSSL
1.0.2+?
Kind regards,
Jeroen van Meeuwen
--
Systems Architect, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
m: +41 79 951 9003
w: http://www.kolabsys.com
pgp: 9342 BF08
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: Patch for adding tls_honor_cipher_order
On 2014-10-16 19:32, Kristian Kræmmer Nielsen wrote: Hi, Patch attached. Something similar is already in cyrus-imapd-2.4: http://git.cyrusimap.org/cyrus-imapd/commit/?h=cyrus-imapd-2.4id=4b26d2d7244eeaa481871c337e57cd393fd76dfe For master / 2.5, I have a push pending of a similar nature, while it also addresses some client vs. server certificate chain configuration options (i.e. Internet-facing public CA, verify client certificates against private CA, offer client certificates between Cyrus IMAP servers, and allow requiring certs to be set to optional or required). Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +41 79 951 9003 w: http://www.kolabsys.com pgp: 9342 BF08 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: Administrative Interfaces
On 2013-06-22 06:53, Marc Fournier wrote: Hi … I've been using cyrus-imapd forever now … at least since '98 … one of the things that has always seemed lacking, and after searching Google the past couple of days, still seems to be either lacking, or well hidden, is a *good* web based administrative interface … As far as I am aware, there's no publicly available / Free Software web administration panel for Cyrus IMAP specifically. As with many other setups you could find elsewhere or build yourself, a web administration panel is an intricate part of any solution that attempts to (or actually does) give you the full experience - as part of Kolab Groupware[1] for example (which certainly at this moment is very much LDAP oriented) we ship a web admin interface[2] that interfaces with LDAP, and not IMAP. We make the rest of the groupware deployment speak LDAP as well, including a daemon[3] that synchronizes the changes one makes in LDAP to Cyrus IMAP (and vice-versa if necessary), such as mailbox creation, deletion, renames and transfers. The suite of which the daemon is a part contains a lot more, but I reckon that's out of scope for the OT. Kind regards, Jeroen van Meeuwen [1] http://kolab.org/ [2] http://kolab.org/about/kolab-wap [3] http://kolab.org/about/pykolab -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 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: Squatter crash with statusdb
On 2013-06-24 13:24, Simon Matter wrote: Hi Andy, could you file a bug for this? Then it will not be forgotten... Or, could you check this bug here http://bugzilla.cyrusimap.org/show_bug.cgi?id=3757 The patch below was the fix, could you verify if it also fixes your issue? Thanks, Simon From 1661683d453ea444aae5832b4a2cb7fd54489672 Mon Sep 17 00:00:00 2001 From: Bron Gondwana br...@opera.com Date: Sun, 09 Dec 2012 19:42:17 + Subject: Bug #3757 - don't segfault on mailbox close with no user This seems to still apply indeed, barring a DB-foreach() = cyrusdb_foreach() merge conflict. I have it in: [master 9766afa] Bug #3757 - don't segfault on mailbox close with no user so it'll be in Cyrus IMAP 2.5 when I push (I have a couple of other things to push as well). Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 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
multi-domain/multi-rootdn for ptclient/ldap.c
Hi there,
I've previously (a long time ago, actually, too long if you ask me) made
inquiries as to who might be using ptclient/ldap.c[1,2], and in which
fashion; I got three points from the responses;
- Everything should be configurable as LDAP deployments typically vary
widely and often pre-date a Cyrus IMAP deployment[3],
- It should handle groups better[4], namely nested/recursive groups,
the 'memberOf' attribute,
- It should handle memberUrls[5].
While these are all valid points and worth working on for me as well,
today I have another aspect; the handling of multi-domain deployments,
with isolated root dns for each parent domain. A very ugly and
presumptuous patch is attached, that needs extra careful checking and a
nice cleanup.
This scenario (of multiple domains separated in to multiple, different
root DNs) is widely in use with Kolab Groupware, while canonification
nor group ACLs would work.
The scenario for such a deployment could be described as follows:
- A list of objectClass=domainRelatedObject LDAP objects exists in
cn=kolab,cn=config.
- A domain example.org may have a root dn of dc=example,dc=org,
and would be an LDAP entry as follows:
dn: associatedDomain=example.org,cn=kolab,cn=config
objectClass: top
objectClass: domainRelatedObject
associatedDomain: example.org
- To translate example.org to dc=example,dc=org in this particular
case, the C equivalent of:
$root_dn = 'dc=' . implode(',dc=', explode('.', example.org));
can be used.
- Another domain example.com mayhave a root dn of o=example,c=de,
and could be an LDAP entry as follows:
dn: associatedDomain=example.com,cn=kolab,cn=config
objectClass: top
objectClass: domainRelatedObject
objectClass: inetDomain
associatedDomain: example.com
inetDomainBaseDN: o=example,dc=de
- Here, the inetDomainBaseDN attribute should be used to translate a
user login of lucy.me...@example.com to a search against
o=example,dc=de.
This leads me to believe the following items should be configurable:
- domain_base_dn
The base dn to use when searching for domains or domain name
spaces.
For Kolab Groupware deployments, this is a default of
cn=kolab,cn=config, but could of course be
ou=Domains,dc=domain,dc=tld as well.
- domain_filter
The filter to use.
Perhaps something like
((objectClass=domainRelatedObject)(inetDomainStatus=on)(associatedDomain=%s))
- domain_scope
The search scope. sub, one or base, with a default of sub.
- domain_name_attribute
The attribute name for actual domain name spaces, such as
associatedDomain.
For LDAP deployments without the Netscape schemas I suppose this
attribute name might be cn.
For situations in which a domainRelatedObject does not contain one,
but multiple values for the domain_name_attribute, the first value
returned by LDAP is used (this typically corresponds with the relative
DN attribute value, and should be consistent).
- domain_result_attribute
Name of the attribute to look for, for example inetDomainBaseDN.
If no such attribute exists (for the object found), fall back to the
standard root dn described above (the implode over explode thing).
I would appreciate your thoughts and feedback.
Thanks, in advance,
Kind regards,
Jeroen van Meeuwen
[1]
http://lists.andrew.cmu.edu/pipermail/cyrus-devel/2011-August/001923.html
[2]
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2011-August/035257.html
[3]
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2011-August/035259.html
[4]
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2011-August/035262.html
[5]
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2011-August/035294.html
--
Systems Architect, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com
pgp: 9342 BF08diff --git a/lib/imapoptions b/lib/imapoptions
index ecb54ef..0725fd9 100644
--- a/lib/imapoptions
+++ b/lib/imapoptions
@@ -597,6 +597,21 @@ Blank lines and lines beginning with ``#'' are ignored.
{ ldap_deref, never, STRINGLIST(search, find, always, never) }
/* Specify how aliases dereferencing is handled during search. */
+{ ldap_domain_base_dn, , STRING }
+/* Base DN to search for domain name spaces. */
+
+{ ldap_domain_filter, ((objectclass=domainrelatedobject)(associateddomain=%s)), STRING }
+/* Filter to use searching for domains */
+
+{ ldap_domain_name_attribute, associateddomain, STRING }
+/* The attribute name for domains. */
+
+{ ldap_domain_scope, sub, STRINGLIST(sub, one, base) }
+/* Search scope */
+
+{ ldap_domain_result_attribute, inetdomainbasedn, STRING }
+/* Result attribute */
+
{ ldap_filter, (uid=%u), STRING }
/* Specify a filter that searches user identifiers. The following tokens can be
used in the filter string:
diff --git a/ptclient/ldap.c b/ptclient/ldap.c
index beb31d9..e16e74a 100644
--- a/ptclient/ldap.c
+++ b/ptclient/ldap.c
@@ -131,42
Re: uppercase usernames
On 2013-03-11 22:55, Julien Coloos wrote: I don't know who is in charge of this patch, but maybe Jeroen can help fix the issue on RedHat side. Hi, thanks for pointing this one out. I can fix the Cyrus IMAP RPM and APT packages I provide[1,2], and those that are shipped as part of Fedora[3], but I cannot make the call for Red Hat Enterprise Linux/Ubuntu/Debian. Please also note this patch does not apply cleanly to cyrus-imapd git master, and could possibly not be necessary either. Kind regards, Jeroen van Meeuwen [1] http://git.kolabsys.com/rpm/cyrus-imapd/ [2] http://git.kolabsys.com/apt/cyrus-imapd/ [3] http://pkgs.fedoraproject.org/cgit/cyrus-imapd.git/ -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 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
In preparation of Cyrus IMAP 2.5: autoconf and automake
Hello there, With many thanks to Дилян Палаузов dilyan.palau...@aegee.org, we would like to let you know about one particular feature now definitely included for a pending Cyrus IMAP 2.5 release. As a feature for the upcoming 2.5 release of Cyrus IMAP, though the exact schedule is yet unknown, we have merged into master the grand overhaul to using autoconf / automake. This marks a first significant milestone closing in on actually producing a 2.5 series release, but, and this is very important: NOT without your help. We would like those of you that have a need to or experience with building Cyrus IMAP from source to let us know whether the autoconf and automake (or, as I like to call it, autofu) Works For You(TM). To this end, we encourage you to clone the GIT repository master branch and attempt a build, or, alternatively, download the following snapshot release: http://git.cyrusimap.org/cyrus-imapd/snapshot/cyrus-imapd-2.5-snapshot- autoconf-and-automake.tar.gz The canonical build process we think applies, generally speaking, is: $ autoreconf -v $ ./configure [your-options] $ make This process currently requires autoconf = 2.67. We would appreciate you let us know whether or not such process works for you, preferrably though Bugzilla (please use product 'Cyrus IMAP' and component 'Distribution'). Thank you, in advance, On behalf of the Cyrus team, Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 signature.asc Description: This is a digitally signed message part. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Cyrus IMAP 2.4.14 released
We are pleased to announce the release of Cyrus IMAPd 2.4.14. This is a stable release in the 2.4.x series. The release mainly contains bug fixes, mostly small but significant. Please find an overview of all bugs resolved in this release at: http://www.cyrusimap.org/mediawiki/index.php/Bugs_Resolved_in_2.4.14 You can download via HTTP or FTP: http://cyrusimap.org/releases/cyrus-imapd-2.4.14.tar.gz ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.14.tar.gz Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 signature.asc Description: This is a digitally signed message part. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus IMAP 2.4.14 released
On 2012-03-12 12:56, OBATA Akio wrote: doc/changes.html and doc/text/changes in released tarball are not updated to 2.4.14? (I don't know about other document files) Hi, You are right, these files have not been updated with 2.4.14 release information - we're missing a piece in our release process. These docs have not been updated for 2.4.13 either, now that I examine them a little closer. The information normally contained within those pages is available though; - http://www.cyrusimap.org/mediawiki/index.php/Bugs_Resolved_in_2.4.14 - http://www.cyrusimap.org/mediawiki/index.php/Bugs_Resolved_in_2.4.13 Kind regards, Jeroen van Meeuwen -- Systems Architect, Kolab Systems AG e: vanmeeuwen at kolabsys.com m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Newbe: Help on cyrus-imapd mailbox listing...
On 2011-12-20 9:40, Klaus Tachtler wrote: How can i see all mailboxes, when i come from localhost OR server80.dmz.my.domain? Is that possible? What configuration do you have for virtual domains? Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Enabling IDLE with murder configuration
On 2011-11-24 16:37, Jean-Christophe Delaye wrote: Hi, I am testing IDLE feature in our murder configuration (2 murder hosts + 4 backend servers). I understand I have to compile imapd with --enable-idled option. But I wonder on which server(s) i have to start the idled daemon in cyrus.conf ? on murder frontend only or imap backend only or both ? Of course mail clients are all connected to murder frontends only. Hi, it should suffice to enable IDLE on the frontends only. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Newbe: Help on cyrus-imapd mailbox listing...
On 2011-12-20 10:47, Klaus Tachtler wrote: virtdomains: on When i stop using virtdomains, solves this the problem? Would you try with setting your virtdomains setting to userid please? Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Never-ending bug with recontruct - MISSING FOLDERS
On 14.09.2011 09:42, Denis BUCHER wrote: Dear all, Hi Denis, I think I've posted already here about this some years ago about this problem and I'm disappointed that cyrus reconstruct seems to still have the same bug. You wouldn't happen to have a ticket in bugzilla.cyrusimap.org about this problem you are experiencing, do you? Let me explain : I have to switch to a new server and moved the cyrus mailboxes on it. Most of the migration is working, but some folders are missing !!! Could you please state the version of Cyrus IMAP on both the old as well as the new server? In fact all data is on the disk, but cyrus reconstruct decided (still this absolutely STUPID bug) do ignore folders containing only subfolders !!! I tried everything I think : 1. cyradm reconstruct user.psmith.archives.2...@domain.com Have you tried appending '-r' to this command, to indicate the reconstruct should be performed recursively? 2. delete cyrus.header and restart cyrus Have you executed reconstruct from the command-line as opposed to through the 'cyradm' utility? Please see the output of 'man -k reconstruct' for the appropriate man page on your platform. -- Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus 2.4.11 Released
Bron Gondwana wrote: We are pleased to announce the release of Cyrus IMAPd 2.4.11. This is a stable release in the 2.4.x series. It contains a security fix to issue CVE-2011-3208, a remotely exploitable buffer overflow in the nntpd daemon. This release also contains fixes for quite a few bugs found since the release of 2.4.10, and adds some new features. Packaged up and pushed out to Fedora 15, Fedora 16 and Fedora Rawhide. Also available for Enterprise Linux 5 -by the end of the day- through; http://mirror.kolabsys.com/pub/redhat/kolab-2.4/el5/development/ And for Enterprise Linux 6 -by the end of the day- through; http://mirror.kolabsys.com/pub/redhat/kolab-2.4/el6/development/ Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Problem setting up murder
Daniel Mueller wrote: Hi, I tried to stage cyrus imap with two backends (replication) and one frontend with the mupdate master on the frontend for testing. Is the replica a part of the same murder? Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Usage of a user with unlimited quota.
Ashay Chitnis wrote: Hi all, I am using cyrus-imapd-2.3.7 on a CentOS 5 32 bit platform. There are some users with unlimited quota and some with limited quota. My problem is when I issue a GETQUOTAROOT command for an unlimited quota user it returns nothing. This may be a standard. But I need to update the IMAP usage of a user irrespective of whether the user has limited quota or unlimited quota without having to manually calculate the data of the user. Is there a way to get the IMAP usage of a user with unlimited quota without having to manually calculate it? The '/vendor/cmu/cyrus-imapd/size' annotation should give you the size of the mailfolder. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Configuration options: tls_ca_path vs tls_ca_file
Dmitry Katsubo wrote: Dear Cyrus community, Hi Dmitry, I would like to ask about this report in log: cyrus/imap[5705]: TLS server engine: No CA file specified. Client side certs may not work What version of Cyrus IMAP are you running exactly? Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Deliverdb in a memcached
Øyvind Kolbu wrote: On 2011-08-23 at 14:01, Ram wrote: On a very busy Imap server , duplicate suppression sometimes becomes the bottleneck I have seen that If I disable duplicate suppression , my lmtp deliveries are speeded up. Duplicate suppression is important , but the database need not persist for very long. I have seen in most of the cases if there is a duplicate mail ( due to forwards , groups etc ), it arrives within 10 minutes of the first mail ( Any exception to this is too minor and can be ignored ) IMHO There should be a configuration that the deliverdb can be, optionally, stored in memcached or directly in memory. Of course there are cons .. like loss of data on restart etc. But these are OK. A number of cyrus' databases are volatile and can be placed on tmpfs. I agree. memcached seems overkill, and as of cyrus version 2.4.8 there are options to specify the location of most databases, In the future, however, with master-master replication, perhaps the duplicate delivery database (as well as other databases such as tls_sessions) may need to be shared between backend servers for a fully transparent and functional experience. I'm interested in exploring memcached for this purpose - a technology I have very positive experiences with in terms of reliability and performance FWIW. That said, I'm not the guy that can come up with a patch... anyone? Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Fwd: Problem with messages in mailbox
Manuel Vazquez wrote: Sorry, i confuse the location of the inbox subfolder. The location of messages is the user/nameUser. Any idea of error? Is possible the bad format of the one messages? Hi Manuel, I'm going to assume this may be as simple as the client not being subscribed to said user/nameUser/cur folder, or said user not being authorized to look up / read said folder - until you can confirm differently. If you have any questions on how to confirm differently, please don't hesitate! :P Use cyradm with administrative privileges against the appropriate IMAP server, and issue a 'listaclmailbox user/nameUser/cur' to get the Access Control List. Use an LSUB in an imtest session in which you authenticate (-u option) as the cyrus administrator (see /etc/imapd.conf's admins: setting), but authorize your session as the target user (-a option). Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Invalid partition
Dudi Goldenberg wrote: Another clue, mail.log shows: Aug 27 10:14:43 mail cyrus/imap[18594]: user.dudi.Backup Reports: can't find acl Aug 27 10:14:43 mail cyrus/imap[18594]: user.dudi.Deleted Items: can't find acl This could give someone a clue. Hi Dudi, Cyrus IMAP 2.2 is like really, really old. It's not that I won't support it, it's... I just can't. It's quite an embarrasing to admit, I know, but I was like being breast-feeded still during the release of Cyrus IMAP 2.2. Since your mails have had zero response on the mailing list so far, may I *strongly* suggest you use the Debian issue tracker so that they can attempt to resolve the issue you are experiencing on the very old version they ship and you are using, or have them recommend you where to obtain a proper Debian package for a later release? Give my regards to Ondrej and Henrique (in that Debian bug report)! I know work has been going underway for quite some time to make that 2.4 series available to Debian consumers, great work! Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Mapping a login(uid) to different mailbox
Dan White wrote: On 27/08/11 09:47 -0300, Lucas Zinato Carraro wrote: Hi, I have several users that will change your login(LDAP uid). How to map a login to another mailbox ? Use a sasl canonicalization plugin to (re)map an authentication identity. The mapped identity returned by sasl will be used when opening the user's mailbox. There is an ldapdb canon_user plugin available in sasl CVS, and a sql plugin available in bugzilla. Documentation can be found in doc/options.html in the sasl source. Hi Dan, I'm sorry to respond to this thread so late, ... I fail to recognize the RFC definition of SASL allowing the return of OK: authorization ID, but perhaps I'm completely looking in the wrong direction... Could you elaborate on where SASL is allowed / providing said canonification? For Cyrus IMAP implementations I've done so far, I've needed a patch against the application(!, Cyrus IMAP in this case) to use a ptclient method/client library capable of handling the desired (LDAP) functionality. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Bulk deletion of mailbox ACLs under Cyrus 2.4.4
Bron Gondwana wrote:
The correct way[tm] is to iterate over all the mailboxes and do a
setacl for each one you want to change, probably using an external
script that talks IMAP.
While obviously needing some work, I've attached a script that -I think- does
just that.
Kind regards,
Jeroen van Meeuwen
--
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +44 144 340 9500
m: +44 74 2516 3817
w: http://www.kolabsys.com
pgp: 9342 BF08
import sys
sys.path.append('..')
import pykolab
conf = pykolab.getConf()
conf.debuglevel = 9
conf.read_config(../conf/kolab-shc.conf)
imap = pykolab.imap
imap.connect()
# List the shared and user folders
shared_folders = imap.lm(shared/*@mydomain.com)
user_folders = imap.lm(user/*@mydomain.com)
# Placeholder for valid ACL entries
valid_acls = {
# These are special keywords used in ACLs
'anyone': True
}
# Loop through the user folders found, ...
for user_folder in user_folders:
# ... and distill the user@domain ACL qualifier.
folder_parts = imap.parse_mailbox(user_folder)
if folder_parts['domain']:
valid_acl = %s@%s %(folder_parts['path_parts'][1],folder_parts['domain'])
else:
valid_acl = %s %(folder_parts['path_parts'])
# 'valid_acl' now contains the fully qualified user identifier (i.e.
# u...@domain.tld), which may be used in the ACL entries on the other
# folders. Store the valid ACL entry.
if not valid_acls.has_key(valid_acl):
valid_acls[valid_acl] = True
# For all folders (shared and user), ...
folders = user_folders + shared_folders
print Iterating over %d folders %(len(folders))
# ... loop through them and ...
for folder in folders:
# ... list the ACL entries
acls = imap.lam(folder)
# For each ACL entry, see if we think it is a current, valid entry
for acl_entry in acls.keys():
# If the key 'acl_entry' does not exist in the dictionary of valid
# ACL entries, this ACL entry has got to go.
if not valid_acls.has_key(acl_entry):
# Set the ACL to '' (effectively deleting the ACL entry)
imap.sam(folder, acl_entry, '')
signature.asc
Description: This is a digitally signed message part.
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Bulk deletion of mailbox ACLs under Cyrus 2.4.4
Jeroen van Meeuwen (Kolab Systems) wrote: Bron Gondwana wrote: The correct way[tm] is to iterate over all the mailboxes and do a setacl for each one you want to change, probably using an external script that talks IMAP. While obviously needing some work, I've attached a script that -I think- does just that. Uch, mind where I said just that, I neglected to mention the attached script only removes ACL entries for which the identifier (assuming it's an individual identifier, admittedly) has no corresponding mailbox. My apologies for pressing send too fast! Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cpu and cyrus
John Madden wrote: It's well worth your time to maintain your own compiles and even packages of Cyrus because the package maintainers can't keep up. Stating as if it were fact packagers are not able to keep up is somewhat of a faux pas, and seriously frowned upon by yours sincerely. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Cyrus IMAP Packaging (was: Re: cpu and cyrus)
John Madden wrote: Stating as if it were fact packagers are not able to keep up is somewhat of a faux pas, and seriously frowned upon by yours sincerely. It's not that you can't keep up, it's that you don't keep up. The reasons behind the lag are usually quite understandable, but regardless, those who need the most recent versions of these packages often have to look outside the distribution's packages. Faux pas or not, it's the truth. :) I'm afraid you're confusing the package that is available in the 'stable' repository or repositories for a 'stable' distribution version or release with the latest version released upstream not being packaged. Distributor's policies often do not permit the type of change(s) the latest and greatest may bring along with it, to occur in their 'stable' releases. Note that I'm using the term 'stable' very lightly here, because Fedora is my turf. This would be a distributor problem more so then a packager problem. With Debian for example, in my experience, the problem has always been (different people on this mailing list can correct me if I'm wrong here) that packagers have wanted the update/upgrade/dist-upgrade database conversion and deb-conf scripting to be what could be defined as providing a seemless upgrade path. Meanwhile it seemed everyone was OK with the status quo, such resulting in little contributions to develop/test solutions to said (perceived) problems. Overall, though, I think you'll find this particular area of packaging Cyrus IMAP for OS distributions has vastly improved over the past year or so. To say packagers can't I do consider a faux pas. To say packagers don't or won't may perhaps give you reason to start doing what you need to get done in the canonical location for such efforts, from where everybody else consumes the fruits of your labour; upstream. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: autocreate / autosieve patches on 2.4.10
Simon Matter wrote: seems the patches at http://email.uoa.gr/projects/cyrus/ don't have anything for any 2.4.x version and looking at the man page for imapd.conf, there is only autocreatequota which I think has always been a base cyrus implementation and not part of the other patches. I have always been spoiled by Simon's packages but I have moved to Ubuntu server so I've been building from source but deeply miss the autocreate autosieve patches. Is it just a choice of use 2.3.16 or live without? Hi, Did you try the patches from here http://blog.vx.sk/index.php?archives/13-German.htmluser_language=en Currently, as it stands, one of the remaining items for upstream inclusion is the compatibility with running a murder; IIRC, the auto* patches are not compatible. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: autocreate / autosieve patches on 2.4.10
Bron Gondwana wrote: On Sun, Aug 07, 2011 at 12:13:31PM -0700, Craig White wrote: seems the patches at http://email.uoa.gr/projects/cyrus/ don't have anything for any 2.4.x version and looking at the man page for imapd.conf, there is only autocreatequota which I think has always been a base cyrus implementation and not part of the other patches. I have always been spoiled by Simon's packages but I have moved to Ubuntu server so I've been building from source but deeply miss the autocreate autosieve patches. Is it just a choice of use 2.3.16 or live without? So far, yes - sorry, I've been meaning to integrate them to 2.4.x for a while and keep getting side-tracked! Bron, is this something you'd be able to and willing to look at for 2.5-next perhaps? If other people can help you do the leg-work I suppose that's great but I want to make sure the requirements to any patches people work on are clearly outlined... perhaps along the lines of; - must be compatible with running in a murder, - must be configurable (already is!), - ... Thoughts? Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus IMAP and SASL on replicated machines
J. Pilfold-Bagwell wrote: Hi All, I have a Cyrus box that I set up about 3 years ago that's been running flawlessly. Recently though, as we're becoming increasingly reliant on email, it was decided that we're going to set up a DRBD replicated system. While I'm not trying to negate that decision having been made, as I too, amongst many other people, enjoy the existence and purpose of DRBD, I have to ask whether or not the contradiction / distinction between storage-level and application-level replication has been taken into account. Please note that what I'm about to say, hopefully generating some feedback from other people as well, would mean more baggage for me to put into all sorts of Cyrus IMAP Deployment Guides and such. An example scenario is where the 'master' (SQL, IMAP) server is the active server; it's DRBD replicated storage segment cannot just be live (locking, (a)synchronous filesystem operations, etc.); This type of scenario says 'warm failover' at best, I recon. With application-level replication however, noted that master-master (round- about) or multi-master replication has to be a replication scenario the application is capable of dealing with, both systems could be active (doesn't matter which one you hit). I suppose the point is DRBD is ideal for Disaster Recovery, and insert a remark on synchronizing new (large) volumes over little bandwidth if you like, whereas application-level replication may just bring you high-availability, load-balancing and disaster-recovery. Just a few of my thoughts, I hope you appreciate and if you feel like it, don't hesitate to question! ;-) Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: autocreate / autosieve patches on 2.4.10
Dave McMurtrie wrote: On Aug 8, 2011, at 7:13 PM, Jeroen van Meeuwen (Kolab Systems) vanmeeu...@kolabsys.com wrote: ...snipped... - must be compatible with running in a murder, In theory, this should be much less work in the 2.4 code since creates can be blindly issued to any frontend in a murder now. I can only hope so ;-) That said from where I'm sitting it would still need to happen... Especially the check on whether the mailbox already exists somewhere else in the murder I think can create quite the confusion if a mail for a NEW mailbox arrives at two backends at the same time... And then I suppose there's inter-backend communication on backend1 that was first and backend2 that now realizes there was no mailbox for the message, but there is now, presumably though LMTP. Excuse my rambling ;-) Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Input on patch for ptclient/ldap requested
Hi there, I wanted to ask who is actively using ptclient/ldap, as I have some inhouse patch pending on the canonification using some sort of result_attribute, if you will. We currently have under consideration whether everything, life and the universe should be configurable before the patch is accepted upstream, which is to say (pardon my postfix lingo); - result_attribute_format, - leaf_result_attribute, but also; - group_filter_scope, - group_result_attribute Which is to say, we have a deployment extensively using 'nsroledn' -which functionally behaves like a 'memberOf', and the question then becomes if you want to use the 'cn' attribute for groups -which most often is not enforced to be a unique attribute value for groups, but is automatically unique is the search scope for groups is 'one' and the 'cn' attribute builds the 'rdn'. Long story short, I would like to know of other people who use ptclient/ldap, or have attempted to do so but failed, and the various use-case / deployment scenarios. Thanks in advance, Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Migrating language encoded folders from cyrus 2.2.12 to 2.3.11
Josef Karliak wrote: Folders on the disk has the same name: drwx-- 2 cyrus mail 848 12. čec 03.01 Kamil AQw-ernAP0-/ So it is up to squirrelmail to deencode it ? Yes. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus 2.4.X delete mailbox oddities
Bron Gondwana wrote: Unfortunately, I can't see what NOOP can do to tell the client that the mailbox has gone away, because RFC3501 says it ALWAYS SUCCEEDS[tm]. Maybe we should ask Mark. Hey Bron, we had discussed this over IRC for a bit... Since a NOOP can result in the server returning some untagged status information along with the OK Completed, but can also return BAD for 'command unknown' or 'invalid arguments' types of errors, and liberally interpreting the selected folder having been purged as an invalid context (thus invalid argument?) this could be worked around, no? Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus 2.4.9 doesn't run on none standard ports
cy...@puri.jet2web.at wrote: Klemens Puritscher schrieb: Now, I've already found the bug. The init.d script by Simon Matter makes the problem. When I use `/usr/lib/cyrus-imapd/cyrus-master -C /etc/imapd.conf -M /etc/cyrus.conf -p /var/run/cyrus-master.pid -d` at the CLI, then is no problem: the lmtpd listen on port 26. Now I must check the init-script... The problem was solved. There was no bug in the init script! Disabling selinux solve the problem... Consider labelling port 26... semanage port -a -t lmtp_port_t -p tcp 26 semanage port -a -t lmtp_port_t -p udp 26 This needs to be done while SELinux is enabled though. As an intermediate solution, run SELinux in permissive mode against the targetted policy. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus 2.4.10 Released
Sebastian Hagedorn wrote: --On 6. Juli 2011 09:53:14 +0100 Jeroen van Meeuwen (Kolab Systems) vanmeeu...@kolabsys.com wrote: Bron Gondwana wrote: We are pleased to announce the release of Cyrus IMAPd 2.4.10. Thank you Bron, for all your great work on this and past 2.4 releases! Agreed! RPM packages for 2.4.10 have now been made available for; - Fedora Rawhide, - Enterprise Linux 5, through [1] I haven't been following this properly ... how do these RPMs compare to the ones that Simon Matter provides? They are related in the sense that Simon Matter has a long-standing history in maintaining Cyrus IMAP packages, on which all of the RPMs for Fedora / Red Hat have been based. Since quite some time, however, Fedora / Red Hat has been maintaining their own version(s). I co-maintain the version in Fedora. As an ISV, Kolab Systems has yet a little bit of different requirements, such as being able to release product series (2.3, 2.4, 3.0) with a different duration for support, different update policies, and such and so forth, and thus builds its own packages; these are what I make available through the packages I referred to in my previous message. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeuwen at kolabsys.com t: +44 144 340 9500 m: +44 74 2516 3817 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: POLL: what should reconstruct -f do?
Bron Gondwana wrote: 3) add the mailbox if there's a directory, don't require cyrus.header. This one has my preference. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +44 144 340 9500 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Tuning defaults for 2.5
Simon Matter wrote: I've checked the options you suggest and here is where I don't agree: Thanks Simon for your feedback! - altnamespace to 1 I don't remember any problems with altnamespace = 0 so why change it? I prefer to have the nontranslated namespace everywhere by default, which is the one also seen with the admin tools. Please note that it is merely a change of the default value, and not an elimination of the option; one can still change this option to match the desired behaviour. We are certainly not seeking the one solution that fits all. Adjusting the default may give new deployments the best starting position, or may not, and I think that's why we're reviewing these. That said, one of the cases I'm offering for your consideration is user interaction (presumably much more prominent that admin interaction). - An altnamespace: 0 environment would nest all folders inside the INBOX. It's like it's represented in admin tools, and it doesn't require translation of the namespace, I agree these are valid points. Users however would, in most if not all client applications, I presume - you tell me please, still be presented with 'New subfolder' options to be created 'next to' INBOX; effectively a dead corner since folders can only be created as subfolders of INBOX. Additionally, it seems unnatural to create 'Sent' as a subfolder for 'INBOX' if you now what I mean. - An altnamespace: 1 environment does not show this problem; the upper account folder can have new subfolders created (e.g. 'next to' the INBOX folder), but then again does not allow subfolders in INBOX -creating another problem for the user experience. As you can see, each has their own little user interaction challenge, and perhaps the real, ultimate fix is to be sought in the client side rather then the server side. Now, presumably, each and every one of us has already picked his/her favorite and would probably like the default changed or unchanged to reflect that. That's OK but while it also does provide only limited perspective on what the *default* should be for *new* environments, I would want to urge you all to consider 1) we can't find a set of defaults that Just Works(TM) for everyone, and 2) we might try to figure out what the best set of defaults is for any new Cyrus IMAP user (e.g. an administrator new to Cyrus), as opposed to the impact on run-time environments changing this option - concerns wrt. the latter are great if they give us extra checklist items and TODOs, but won't really stand in the way of *aiming* for the change of the default value, it'll merely change the timeline and effort required to do so. I hope that better explains 'why' a change of the default value for these settings is under (my) consideration, and what I'm looking for. I apologize if the aforementioned is preaching to the chior and/or suggests you did not understand what I was looking for because obviously you do, or that your comments are somehow wrong because they are not; rest assured these additional considerations will make it into a pros/cons table for final evaluation and into documentation as well. - hashimapspool to 1 I have also used hashed spool on large servers in the past but I really don't like it to be the default. Hashed spool is only needed on large systems which lack decent filesystems. More and more modern systems have no issues with the number of directories. Hashed spool is just a hack for those who need it. Understood; personally I change this default on deployments because I like the ability to navigate through the filesystem side, and environments are more likely to grow and have use for hashimapspool, then they are to shrink and have use for no hashing of the imap spool. I was throwing this default up for consideration - improved_mboxlist_sort to 1 I don't know about this one but it hurts reading we have to dump/convert/undump their mailboxes.db :( That is not what is required on an upgrade or update; What would be required if we were to change the default for this option, is to either; 1) set improved_mboxlist_sort back to 0 in /etc/imapd.conf, 2) convert mailboxes.db, for which I would need to provide a script, possibly packaging included, before I would be allowed to touch the default ;-) - normalizeuid to 1 Is this in 2.5 now? Because it has been in out RPMS just as a patch. Sorry, if this is an RPM only thing, its my mistake to have included it here; I went through man imapd.conf on one of my systems, instead of using lib/imapoptions from the upstream GIT repository - I realize that only now. Perhaps inclusion of this patch upstream would be considered (we'll make that a different topic for now), in which case whether having the option and what the default should be would become relevant. - unixhierarchysep to 1 It's a constant source of confusion and like for altnamespace, I prefer to have the nontranslated hierarchy separator
Re: custom notifications
Wolfgang Hennerbichler wrote: On Tue, Feb 15, 2011 at 07:33:41AM -0500, Dave McMurtrie wrote: * does notifyd need to be running in order to make the notify-socket readable, or is the notify-socket filled by the cyrus-master process? * where would I find instructions on that? You want to set the notify_external option in imapd.conf and point that at a program (script, binary, whatever) that you write. notifyd will fork/exec your program and pass it -c, -p, -u and -m command line arguments. Your program can then to whatever custom notification you want it to. This was added in the 2.4.x series. The imapd.conf option is documented in the imapd.conf manpage ... thanks! too bad I do still have 2.2 running (debian squeeze), and I was too lazy for now to find a good package maintainer or compile by myself. So I guess I'm stuck by now. I have some vanilla packaging effort for Debian ongoing on http://git.kolabsys.com/apt/cyrus-imapd/log/?h=cyrus-imapd-2.4, in case you're interested. Though I'm dealing with a small backlog, compiled packages may be found at http://mirror.kolabsys.com/pub/debian/kolab-3.0/pool/development/c/cyrus- imapd/ Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: SIEVE Scripts on a shared folder
Adam Tauno Williams wrote: cyrus-imapd-2.3.14-8 I've done this before, but now I'm stumped [possibly Friday induced brain fade]. I'm trying to set a SIEVE script on a shared folder. Now that you mention it, I find that indeed the sieve script I was trying to use does not work... ;-) 2.3.16 for me. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Tuning some defaults for 2.5: lmtp_downcase_rcpt
Hi there, (This is a re-posted message from our development mailing list.) In our IRC channel, it was suggested to look at RFC 2821, section 2.4, quoted as saying: However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged. The problem statement is as follows: The recipient is u...@domain.de, and while the mailbox name is u...@domain.de, or even user, the mail bounced. Not completely aware of the full implications and/or codebase, I wanted to put the topic on switching the default to be relaxed in the case of case sensitivity out there for discussion. Long story short; the proposal is to ship with a default lmtp_downcase_rcpt of 1. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Tuning some defaults for 2.5: lmtp_downcase_rcpt
André Schild wrote: Hello, Am 11.02.2011 14:11, schrieb Jeroen van Meeuwen (Kolab Systems): Long story short; the proposal is to ship with a default lmtp_downcase_rcpt of 1. Sound OK for me. When chaning upper/lowercases we always have to consider character sets. For the user part it's no problem because here only basic characters are allowed, but what about a mailbox like: user@BÜCHER.CH ? I don't think these characters are allowed in DNS / KRB, so hopefully that addresses that concern. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: 2.3's future?
Jukka Huhta wrote: I filed a bug 3397 (replication partitions), also reported in http://www.mail-archive.com/info-cyrus@lists.andrew.cmu.edu/msg39940.html. What are the odds to have it fixed in 2.3 or will it just be closed with WONTFIX? If we don't count these few replication related bugs, 2.3 appears to be fairly stable compared to 2.4, IMHO. I'm still waiting for 2.4 to grow up a bit before upgrading our production servers, even though I may be overly cautious. Our abilities right now only stretch so far; for the 2.5 series, Bron, Ken and Greg put in some serious effort. For the 2.4 series, is primarily me and Bron looking at bugs reported against 2.4, which we will first atempt to solve in 2.5, porting them back as necessary/possible, with lots of help from Bron (again). That said, 2.3 at this point is not getting an awful lot of attention. It's leaning towards maintenance mode, if you will, and no further developments are likely to take place. I'd say 2.4 is leaning towards stable, as fewer and fewer (serious) bug reports are being reported against it. If you have a special interest in 2.3 (and I know some people who have), please do feel free to contribute your efforts, they are most welcome! Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Tuning some defaults for 2.5: lmtp_downcase_rcpt
André Schild wrote: @bücher.ch is allowed. In dns this is represented as a IDN encoded name in the form of*** xn--bcher-kva.ch* is the ACE string, and it is this string that is entered in the DNS. Fine, let me rephrase; The IDN-ACE string conversion, while ASCII-only not being a limitation in the DNS specifications itself, is restrained by protocol-by-protocol compatibility (or, lifting of restrictions to 7-bit ASCII, if you will). SMTP, as far as I'm aware, has not yet been made fully compatible, and have continued -for the past decade or so- to use the ACE representation, while applications such as MUAs do the conversion. Continuing this down the path to DNS, it is not actually DNS supporting this at this moment, but applications which are DNS clients (including the web administration / registration utilities), which do the conversion before the query (and probably the same conversion on the return). Just for fun, and to illustrate the point the IDN-ACE conversion is actually an application exercise, try the rather new 'dig' vs. the rather old 'mail' utilities; $ dig +short bücher.ch 82.210.242.149 $ date | mail -s test somethingthatdoesnotexist@bücher.ch somethingthatdoesnotexist@bücher.ch contains invalid character '\303' Send options without primary recipient specified. Usage: mail -eiIUdEFntBDNHRV~ -T FILE -u USER -h hops -r address -s SUBJECT -a FILE -q FILE -f FILE -A ACCOUNT -b USERS -c USERS -S OPTION users The latter illustrates that, as opposed to just off-loading the conversion task to the MTA or SMTP layer(s). Similarly, a TCP dump on your SMTP(S) / MSA will show you the conversion is done before you hit any actual mail infrastructure. The same can be shown using named's named-checkzone utility. Continuing on the path forward, I suppose the really interesting part is what happens if a user@bücher.ch mailbox is created, versus a mail being delivered, versus a user logging in, versus sieve scripts. However, I somehow doubt it has anything to do with the original point of lowercasing the recipient in LMTP's handling by default. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Shared mailboxes doc
Andy Bennett wrote: Does anyone know the option that needs to be set (and how to set it) in order to do a bulletin board. i.e. have a separate SEEN state for each user? Do the imapd.conf sharedseenstate option (disabled) and setting the anyone 's' ACL help? Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Shared mailboxes doc
Julien Vehent wrote: Hi list, I was experimenting with shared mailboxes today. That's something new I've never used before. I wrote a wiki page of my setup on debian squeeze (still on cyrus 2.2) and was wondering if that was the state of the art, or if there were any better way to do it. http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:cyrus:shared_mai lbox Also, I didn't find any documentation on the subject on the website. Did I miss something ? Seeing as how you are interested in keeping some level of documentation, would you care to work with me on upstream's documentation as well? I have a git repository at: http://git.cyrusimap.org/cyrus-imapd-docs/ and some output I regulary generate on: http://www.cyrusimap.org/~vanmeeuwen/cyrus-imapd-2.4-docs/ Really, at this point, *any* feedback is most appreciated ;-)) Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Shared mailboxes doc
Dan White wrote: On 07/01/11 16:23 +, Jeroen van Meeuwen (Kolab Systems) wrote: Julien Vehent wrote: Hi list, I was experimenting with shared mailboxes today. That's something new I've never used before. I wrote a wiki page of my setup on debian squeeze (still on cyrus 2.2) and was wondering if that was the state of the art, or if there were any better way to do it. http://wiki.linuxwall.info/doku.php/en:ressources:dossiers:cyrus:shared_ mai lbox Also, I didn't find any documentation on the subject on the website. Did I miss something ? Seeing as how you are interested in keeping some level of documentation, would you care to work with me on upstream's documentation as well? I have a git repository at: http://git.cyrusimap.org/cyrus-imapd-docs/ and some output I regulary generate on: http://www.cyrusimap.org/~vanmeeuwen/cyrus-imapd-2.4-docs/ Really, at this point, *any* feedback is most appreciated ;-)) What are your plans with this documentation? Are you intending to use this build system to generate the contents of the /doc documentation? Assuming I'm understanding the question correctly; My intention is to make it easier to provide *more* content then is suitable for a man-page, or the doc/ directory, in a way that enables us to spit out the documentation in different formats, versioned and all. Publican (read: DocBook wrapper) enables us to do this, amongst other things (translation, theming). If it results in doc/ becoming obsolete, I don't know. For now, I'm merely building the general content of the books in a very superficial manner. The pregenerated content at the second link looks very nice (or at least the structure of it, since the content seems to be in the works). When I attempt to perform a make on the git tree, it seems to want to perform an rsync over ssh. It that ssh account open to wiki users or just developers? The rsync over ssh it attempts to do is my little 'release to www' thing; It's only available to people with a shell on www.cyrusimap.org and requires you have set up a ~/public_html/cyrus-imapd-X.Y-docs/ directory. The command you are looking at to execute would be: $ publican build --langs=en-US --formats=html,html-single,pdf The results would then be in tmp/en-US/ Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: RFC 5464 : IMAP METADATA extension
On Sunday, November 21, 2010 09:41:58 pm Bron Gondwana wrote: On Sun, Nov 21, 2010 at 07:24:02PM +0100, kael wrote: Hello, I've installed Cyrus 2.4.4 and looking at the METADATA extension, I realized only draft-daboo-imap-annotatemore-07 is implemented. Yeah, it still does. There's a patch from the Kolab folks (haven't tried yet), and according to a discussion on the list from November 2009 a patch has been developed by Fastmail devs. Not precisely - I had a play with it, but it's languished for a while. I had hoped to do it for 2.4, but the priority was getting the underlying mailbox models done. If Kolab already has a patch I'd definitely like to start with that. Jeroen - do you have one? What state is it in? I'm not aware of a patch against cyrus-imapd from within the Kolab universe, that is related to RFC 5464. The only patch I can think of, that relates to this message is the ability to set arbitrary annotations through Cyrus[1,2]. Both (remotely) annotation-related patches have been applied in Cyrus IMAP upstream. That said, I have to warn you that the other patches listed on the page referred to are not necessarily feasible technical implementations of the functionality requested. What's the state of Cyrus implementation ? Is there any plan to implement the RFC version (can't find a ticket on Bugzilla) ? Yes, there certainly is. I want to add CONDSTORE support to the annotations DB at the same time (at least the HIGHESTMODSEQ on the mailbox at the time a particular annotation was last touched - and bump the HIGHESTMODSEQ too) so that replication can transfer them efficiently. I suppose what we need to have is a master RFC-5464 bugzilla ticket, possibly split out over the several tasks completing the full implementation -Bron can best be the judge on which RFC 5464 components to implement at the same time while touching the code, as well as determine what is feasible to implement *now* vs. what is feasible to target for a future release -in the 2.5 series? Kind regards, Jeroen van Meeuwen [1] http://wiki.kolab.org/Kolab-major-app-patches#Cyrus_IMAPD [2] http://hg.kolab.org/server/file/3c2a460e7e78/imapd/patches/cyrus- imapd-2.3.15/KOLAB_cyrus-imapd-2.3.15_Annotations2.patch -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Does anyone allow unlimited or extremely large quotas?
On Tuesday, November 16, 2010 02:53:44 pm Simon Amor wrote: On 16 Nov 2010, at 13:38, Adam Tauno Williams wrote: Our largest quota's a 4GB; without any issues. I think the issue you will encounter first is clients will start to fall down when folders exceed a 'reasonable' number of messages. Common IMAP clients I've seen start to exhibit severe performance issues beyond a few hundred thousand messages. Is that with the server and client on the same LAN or with the client on a low speed WAN connection? We find that 50,000 messages in a folder is more than enough to make Thunderbird/Outlook unresponsive for minutes at a time when connecting to a remote server. You may like Kontact, in these cases. Having a 36 GB online email archive myself... I find Kontact to work best with the large numbers. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Bugzilla does not handle locales well
On Monday, November 15, 2010 01:56:13 pm Michal Hlavinka wrote: Hi all, I have prefered language in firefox set to 'cs' so I get czech localized bugzilla pages. These pages use utf-8 encoding but page headers nor server itself do not mention any information about encoding so default content encoding iso-8859-1 is used, which is wrong and results in broken and hard to read text. Could you fix that? We'll have to migrate and convert, which is perfectly reasonable, but does take some testing, planning, downtime and thus, overall some time. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Cyrus IMAPd 2.4.4 Released
We are pleased to announce the immediate availability of Cyrus IMAPd version 2.4.4. This is a stable released in the 2.4 series, containing a mere 5 bug-fixes since version 2.4.3, released two days ago. Particular focus of this release has been paid to upgrade paths, for which many of our users have contributed feedback -with a special thanks to Bron Gondwana for making the fixes happen. The URL for this release is: ftp://ftp.cyrusimap.org/cyrus-imapd/cyrus-imapd-2.4.4.tar.gz We recommend that all users of earlier Cyrus IMAP versions in 2.4.x series update to this release. We also recommend users of earlier Cyrus IMAP versions (2.2.x, 2.3.x) test the upgrade path to version 2.4.4 for its seemless upgrade capabilities, and report issues to us through Bugzilla: http://bugzilla.cyrusimap.org/enter_bug.cgi?product=Cyrus%20IMAPversion=2.4.4 A list of bugs logged and fixed in version 2.4.4 can be found on our Wiki: http://cyrusimap.org/mediawiki/index.php/Bugs_Resolved_in_2.4.4 Questions and comments can be directed to our mailing lists: info-cyrus@lists.andrew.cmu.edu (public list) or cyrus-de...@lists.andrew.cmu.edu (development) We also like to invite you to join us on IRC: #cyrus on the FreeNode network. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 signature.asc Description: This is a digitally signed message part. Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: duplicatedeliver annotation
On Monday, November 01, 2010 08:23:49 pm Paul Engle wrote: All, We've never had cause to try it out until now, but I can't seem to get the annotation set to suppress duplicate delivery for a single mailbox. We're running 2.3.16 on RHEL5, and I'm using cyradmin. But whenever I try to do mboxconfig mailbox duplicatedeliver true on a mailbox, I keep getting permission denied. I'm connecting as an admin user. I've also tried using on and 1 as the value, but nothing takes. Is there additional configuration that needs to be set up to allow this? Hi Paul, I suppose you (the admin user) still needs to have the appropriate permissions on the mailbox. Also, the duplicatedeliver annotation -or so I think- is actually /vendor/cmu/cyrus-imapd/duplicatedeliver -but I'm not a 100% certain and I have not checked the code. Let me know if it works out for you, I'll sink my teeth into it a little deeper should it not. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: cyrus-imapd v2.4.2 on CentOS issue with deleting users
On Tuesday, November 02, 2010 05:56:31 pm Robert Spellman wrote: Here's the output from a ls -lR starting in the user's mailbox. In this case, the Junk folder was left. Sometimes other folders are left around, so it's not consistent. [cy...@mailstore04 frodo]$ pwd /home/imap/f/user/frodo [cy...@mailstore04 frodo]$ ls -lR .: total 40 -rw--- 2 cyrus mail 1066 Nov 2 12:32 1. -rw--- 1 cyrus mail 940 Nov 2 12:32 cyrus.cache -rw--- 1 cyrus mail 196 Nov 2 12:31 cyrus.header -rw--- 1 cyrus mail 224 Nov 2 12:32 cyrus.index drwx-- 2 cyrus mail 4096 Nov 2 12:31 Junk ./Junk: total 24 -rw--- 1 cyrus mail 4 Nov 2 12:31 cyrus.cache -rw--- 1 cyrus mail 196 Nov 2 12:31 cyrus.header -rw--- 1 cyrus mail 128 Nov 2 12:32 cyrus.index Could it have anything to do with delayed expunges being set? Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: duplicatedeliver annotation
On Tuesday, November 02, 2010 07:04:25 pm Paul Engle wrote: Jeroen, Thanks for the reply. The admin user does have full permissions to all mailboxes; we set that upon inbox creation. I was ultimately able to manually set the annotation using raw IMAP commands. When I looked at the source for the Cyrus::IMAP::Admin.pm and Cyrus::IMAP::Shell.pm modules, I saw that the duplicatedeliver annotation doesn't appear to be in there at all. So, while the server understands it, the admin tools don't. Once I got a free moment this afternoon, I was going to submit a patch to the list to provide support for it. It looks like a simple thing to add in. It does indeed. Would you mind submitting the original issue + patch through Bugzilla? FWIW, cyradm in 2.4 supports the use of /explicit/annotation to be used, so that the following would work for us: $ mboxcfg user/vanmeeuwen/calen...@kolabsys.com /vendor/kolab/folder-type event.default Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Odd problem: IMAP/S suddenly not working, but no errors, and IMAP still works
On Monday, November 01, 2010 03:46:38 pm Simon Matter wrote: Bron, My Cyrus is from RPM, and I am just nursing it along until my users finish migrating off and FastMail manages to complete my own migration, so I don't want to build from source. Why would IMAP/S block on empty /dev/random, while IMAP+STARTTLS works? FWIW, SASL2 seems to use urandom. If this is really stock CentOS 5 then I think everything Cyrus related should use /dev/urandom and not /dev/random. But, could it be that other software you installed uses /dev/random and makes it empty? I think the stock CentOS packages do in fact use /dev/urandom. Kind regards, Jeroen van Meeuwen -- Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: 2.4.2 on Solaris - Crashes in mailbox_unlock_index
On Sunday, October 31, 2010 02:02:19 pm Andy Fiddaman wrote: On Sun, 31 Oct 2010, Bron Gondwana wrote: ; On Sat, Oct 30, 2010 at 11:19:14PM +, Andy Fiddaman wrote: ; On Sun, 31 Oct 2010, Bron Gondwana wrote: ; ; ; ; I don't suppose the stacktrace went any further up than that? I'm ; ; more interested in the call-site of mailbox_close, because that's ; ; where a dirty mailbox will be being closed. ; ; Here are a couple: ; ; Ok - that's all I needed. This is a bug. I'll push a fix ; to master straight away, and it will be in 2.4.3. Thanks, superb support as always. I'll apply the patch and look at rolling out 2.4.2 to production this week then go to 2.4.3 when it's out. Can we make sure this ends up in Bugzilla as well? Referring to the mailing list thread/post would suffice. Kind regards, Jeroen van Meeuwen Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
#cyrus IRC Channel on FreeNode
We found chatting on IRC has just that little more bandwidth available for a conversation as opposed to mailing lists and/or bugzilla, so we would like to invite you to join us on IRC if you're interested; Network: FreeNode (irc.freenode.net) Channel: #cyrus Talk to you later! ;-) Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: v2.4.2 warning IOERROR: opening /var/imap/user_deny.db: No such file or directory
Rosenbaum, Larry M. wrote: I'm seeing the following error in the IMAP log file: IOERROR: opening /var/imap/user_deny.db: No such file or directory How do I set up the user_deny.db file? This error occurs but once, correct? Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: v2.4.2 warning IOERROR: opening /var/imap/user_deny.db: No such file or directory
Rosenbaum, Larry M. wrote: From: Jeroen van Meeuwen (Kolab Systems) [mailto:vanmeeu...@kolabsys.com] Sent: Thursday, October 28, 2010 11:37 AM To: info-cyrus@lists.andrew.cmu.edu Cc: Rosenbaum, Larry M. Subject: Re: v2.4.2 warning IOERROR: opening /var/imap/user_deny.db: No such file or directory Rosenbaum, Larry M. wrote: I'm seeing the following error in the IMAP log file: IOERROR: opening /var/imap/user_deny.db: No such file or directory How do I set up the user_deny.db file? This error occurs but once, correct? I think it occurs once for every imapd process started up. Euh, bingo! Sorry ;-) You should be able to simply touch the file and go from there. Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus RPM
JC Putter wrote: Hi, i tried to compile and install cyrus 2.4 but when i telnet to localhost 110 i still see 2.3 is there an rpm available? While it depends on which RPM distribution you are using; yes, RPMs are available. If you use autocreate/autosieve (which can not be applied to 2.4 yet), please mind the RPMs do not include autocreate/autosieve. You can find a full directory tree for fedora redhat at: http://mirror.kolabsys.com/pub/ Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Got cyrus to compile but now it's not working.
Frank Pittel wrote: Oct 27 12:48:03 cyrus-int imap[4393]: [ID 914338 local6.notice] badlogin: localhost [127.0.0.1] plaintext cyrus SASL(-1): generic failure: checkpass failed What does your SASL configuration look like, and does testsaslauthd work for any of the users you know are available to SASL using the configuration you have in place now? Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus IMAP server
Dan White wrote: On 21/10/10 16:43 +0200, JC Putter wrote: we are running cyrus-imapd 2.3 on centos 5.5 we are getting complains from users getting error messages saying Mailbox locked by POP Server, i understand that pop3 server can handle only 1 concurrent connection, can cyrus be configured to support more connection? We're getting a lot more of these complaints as well as our ISP customers start configuring email access on their phones and handhelds. The solution for us has been to encourage customers to reconfigure both devices (PC and phone) to use IMAP. The POP3 standard (RFC 1939) requires each connection to obtain an exclusive lock on a maildrop before continuing operations. It lacks the proper semantics to handle simultaneous access to a mailbox. Hi there, I went ahead and put this protocol limitation in my work-in-progress Deployment Guide document ;-) Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus IMAP server
Bron Gondwana wrote: Actually in Cyrus 2.4 you will find that it allows multiple concurrent pop connections. Each one gets a snapshot of the mailbox at the time it connects. All operations are to this snapshot. This is safe because the namelocking semantics ensure the message files won't be deleted until all open connections are closed, and the snapshot includes uids to let the pop3d find and delete the correct messages. So you'll be good in 2.4 :) Worth noting and putting in the documentation ;-) Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Bugzilla Cleanup - Your Help Needed and Much Appreciated!
Hello there, The Cyrus Bugzilla is a very important component for all of us, community users and Cyrus developers alike! I suppose most of us have, at least once or twice, logged a new report in Bugzilla, but then what happens with that report? From the other side, the Cyrus team sometimes doesn't sort through the series of legacy tickets to see what (in terms of tickets) it is they are supposed to be working on or which tickets they need to close. As a result, reports quickly back up in the queue and are soon to be rarely paid sufficient attention to. Similarly, I can imagine, it must sometimes be... confusing to see a large number of tickets still be open, or a large list of versions you never know existed, and the version or milestone of a ticket be set to something that doesn't really make sense. Ergo; something needs to be cleaned up. While some things I can just go ahead and do (after short deliberation within the Cyrus team, of course), *WE NEED YOUR HELP!* Let me emphasize that point; Without your help, all I can do is close the tickets and wait for people (probably some of you) to reopen them... Here's some of the things I can do and have done to make it easier on all of us; - I've cleaned up the list of versions by accumulating versions the Cyrus team is unlikely to pay much attention to, into series of versions. Ergo, 2.1.1 through 2.1.13 have all become one single '2.1.x' entry. Note that this includes the 2.2 series, while 2.3 has been released ~5 years ago. Same goes for milestones. - I've installed the BugzillaReports extension for Mediawiki, so we can easily create lists of bugs and share those lists. See, for example, the following Mediawiki page; http://www.cyrusimap.org/mediawiki/index.php/Bugs_Resolved_in_2.4.1 You can help us make Bugzilla just a little bit more accessible! Here's how (the contents of lists are updated instantly); - A list of Open Bugs per legacy version has been created: http://www.cyrusimap.org/mediawiki/index.php/Bugzilla_Cleanup - A description of what you can do with such reports is described here; http://www.cyrusimap.org/mediawiki/index.php/Bugzilla_Cleanup_Guidelines We're talking a list of 174 bugs at the time of this writing. What we would like to see, is have this list be smaller. If you have any questions (like, any, whatsoever, somewhat related to Cyrus), please feel free to drop me a line, or contact my directly in the #cyrus IRC channel on irc.freenode.net. Thank you, in advance or in retrospect or both, for your contribution(s), Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus Add-ons
Reinaldo de Carvalho wrote: On Sat, Oct 16, 2010 at 2:11 PM, Henrique de Moraes Holschuh h...@debian.org wrote: On Sat, 16 Oct 2010, Reinaldo de Carvalho wrote: RCS is local version control, isn't a network service. It is also per-file. Think CVS with even less features. I also have some stuff in RCS, mostly LyX documents without any external material. Reinaldo, any reason why you don't use git or mercurial? That would make it much easier for cooperative work. sf.net supports git, and it will NOT increase your dependency on the network even a bit, as it is fully distributed. No reason. Can you point me a git howto? I would love to help you developing / maintaining the Python Cyrus package you did as well. We have some infrastructure on cyrusimap.org which we could use, too, if desirable (wiki, bugzilla, git repo, web browsing, email notifications for commits, and of course a number of contributors already known/authorized). Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus Add-ons
Reinaldo de Carvalho wrote: On Fri, Oct 15, 2010 at 2:20 PM, Henrique de Moraes Holschuh h...@debian.org wrote: On Fri, 15 Oct 2010, Reinaldo de Carvalho wrote: On Fri, Oct 15, 2010 at 11:12 AM, Jeroen van Meeuwen (Kolab Systems) vanmeeu...@kolabsys.com wrote: Hi Reinaldo, You have an interesting project going on there. One question; where is the source code repository? Source code is the program code (is python). I think he meant where is the version-control repository (i.e. git, subversion, mercurial, bazaar, or whatever you use for version control). I'am using RCS (newest SCCS). Can you tell us where the repository is? Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus IMAPd 2.4.0 Released
Per olof Ljungmark wrote: On 10/13/10 18:44, Simon Matter wrote: Simon Matter wrote: On Tue, Oct 12, 2010 at 02:23:18PM -0700, David Lang wrote: (...) IIRC autocreate is on the official todo list, isn't it? That would solve it forever. Simon Excuse my ignorance, but where can I find the Official ToDo list? Our official todo list is everything that is not in CLOSED status in Bugzilla on http://bugzilla.cyrusimap.org. I'm working to clean that up. You can help, if you want; - Examine old bug reports logged against a version prior to 2.3, and determine whether this report still applies to a more recent release (2.3.x, 2.4.x). Here's a list (you require editbugs privileges for this list): http://bugzilla.cyrusimap.org/bugzilla3/buglist.cgi?cmdtype=runnamednamedcmd=legacy- review a) When you know it's resolved you can correct the target milestone (set it to the most recent release when in doubt), and close the bug with CLOSED FIXED. b) If you know the problem still exists, update the version number the bug is logged against to the most recent version number you know the problem still exists in. c) When in doubt, make the changes that represent your best guess, but do not close it, and assign it to me (vanmeeu...@kolabsys.com). Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: user_deny.db, very high load and Apple-Spotlight
Ralf Haferkamp wrote: On Thursday 14 October 2010 13:30:22 Marc Patermann wrote: Hi, Mark Heisterkamp schrieb am 12.04.2010 09:03 Uhr: [..] I think we shouldn't advise 5000 users not to use Spotlight, we should deactivate user_deny.db. By the way, what is this database really good for? If we want someone not to use cyrus-service we deny this person by ldap for example. Kenneth Murchison stated in some mail on this list that user_deny.db is used once per login, that's definitely not true, it is used every time the client 'uses' an IMAP-folder and that can be pretty often! Maybe we can change this behaviour by some config? Is it possible to deactivate fetching user_deny.db-entries by some config-option or do we have to patch the sources? I have this issue, too. But there is no Mac involved. It is just Thunderbird on the client (Win*/Linux) side. I created user_deny.db with touch to make the one error message go away. Now I have lots of fetching ... messages in the log (2.3.16). Is there anything to do about this? You could either upgrade to 2.4.0 as the user_deny.db code has been changed there to only try to open the database once. Or I guess you could just backport these two patches to your 2.3.16 release: http://git.cyrusimap.org/cyrus-imapd/commit/?id=e82c657e2f6a3d304d19d737104 cec4782da15c0 http://git.cyrusimap.org/cyrus-imapd/commit/?id=3a755fac0d4b43071774af2a64 6ac4fa51aba8f3 Could any of you please submit a bug-report in our Bugzilla? I can then go through the motions of backporting those to the 2.3 branch if appropriate (e.g. if Bron and/or Ken agree). You may just get a 2.3.17 out of it. Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: user_deny.db, very high load and Apple-Spotlight
Ralf Haferkamp wrote: On Friday 15 October 2010 11:47:15 Jeroen van Meeuwen (Kolab Systems) You could either upgrade to 2.4.0 as the user_deny.db code has been changed there to only try to open the database once. Or I guess you could just backport these two patches to your 2.3.16 release: http://git.cyrusimap.org/cyrus-imapd/commit/?id=e82c657e2f6a3d304d19 d737104 cec4782da15c0 http://git.cyrusimap.org/cyrus-imapd/commit/?id=3a755fac0d4b43071774 af2a64 6ac4fa51aba8f3 Could any of you please submit a bug-report in our Bugzilla? Acutally there is one already :), that's want resulted in the 2.4 change: http://bugzilla.cyrusimap.org/bugzilla3/show_bug.cgi?id=3206 Sorry, let me rephrase: Should there be a bug-report already, would you please comment on it with the extra information you provided? Anyway, I've done so accordingly. Thanks for the references! Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus Add-ons
Reinaldo de Carvalho wrote: Hi Guys, Can you add reference to Korreio on new cyrus website? Korreio provide a GUI for cyrus, like a cyradm. If possible add a link to Korreio, the URL is: http://korreio.sf.net (the Cyrus Admin GUI), Thanks. Hi Reinaldo, You have an interesting project going on there. One question; where is the source code repository? Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Problem with Cyrus 2.4.0 when subscribe to folders in other backends
Bron Gondwana wrote: On Wed, Oct 13, 2010 at 05:27:32PM -0300, Lucas Zinato Carraro wrote: With Thunderbird 3.1.3 i can subscribe only in folders located in Backend1 where my account lucas.carraro exist. The other folder in backend2 are not avaiable for me: Actually, you're subscribing fine - we're just not showing them. Oops. I know exactly which change fixed this - it's an obviously over-eager patch that I applied for FastMail because users were complaining about non-existant mailboxes appearing in their list view - things that were subscribed ages ago, and appearing despite not being real. I don't have a one-line patch for you I'm afraid - I'll have to talk to Ken about this one and come up with a real fix. Definitely a bug though, in the way murdered imapds handle lsub. Lucas, could you submit this to bugzilla so that I can set a blocker bug for 2.4- next? That will make absolutely sure it is resolved before we release 2.4.1. If you put me in CC: (vanmeeu...@kolabsys.com), that'd make it pop up on my radar the sooner. Thanks in advance, Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus IMAPd 2.4.0 Released
Simon Matter wrote: On Tue, Oct 12, 2010 at 02:23:18PM -0700, David Lang wrote: I'm happy to see this. Is there anyone packaging this up for the common linux distros? David Lang We're planning to reach out to the distributions and convince them to package it - as well as integrating any patches they're applying that are still worthwhile. We want everyone to be running the same codebase as much as possible. Of course I'll update our RHEL/CentOS RPMs but it may take a bit more time than the usual hours or days because of the many changes in the new release. Some of the stuff which has been done in the RPM automagically - like converting databases on startup - has now been integrated in the main code and I have to look at things in detail. Hey Simon, you've always done a great job on the RPMs, thank you! While we are at it, I have your 0012-Clean-Shutdown.patch in the RPM, from what I see in the changelogs this has not been integrated with 2.4, right? Is this patch listed in bugzilla somewhere? I seem unable to digg it up. If it's not yet in Bugzilla, would you please add it? This ensures that at least someone like me (volunteers please step up! :P) looks at it. The other thing I'm wondering now is how to go on with the autocreate feature. I'm not sure I'll be able to recreate the patches for 2.4 and I don't know if the nice people from University of Athens will be going to do it. Hm, I won't be happy to release a new RPM with this feature missing. We are in contact with the dear people at UOA.gr to discuss how to proceed. Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Cyrus IMAPd 2.4.0 Released
David Lang wrote: I'm happy to see this. Is there anyone packaging this up for the common linux distros? Yes, I am. Packages will be / are available through http://mirror.kolabsys.com/pub/ Look at the kolab-3.0 product branch repositories, where what is now still called kolab-cyrus-imapd is actually just cyrus-imapd (this is a legacy thing I'm sorry). I've started with Enterprise Linux 5 (RHEL / CentOS / Scientific), and later this week I should be able to turn up with some packages for Debian Lenny, Squeeze, Fedora 12-rawhide and Ubuntu 9.04+. The former not withstanding, help is greatly appreciated! Contact me if you're interested (the packaging all goes through GIT repositories at http://git.kolabsys.com/). Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Tcpwrapper does not work?
Paul van der Vlis wrote: Hello, When I put in my /etc/hosts.deny this: imapd: 192.168.0.41 And /etc/hosts.allow is empty. Then I still get my mail over IMAP from this IP with Cyrus. I use Cyrus 2.2.13 from Debian stable, so far I know this is compiled with tcpwrapper support. Does somebody understand this? Does ldd on imapd show you a link against libwrap? Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: competition
Adam Tauno Williams wrote: On Wed, 2010-09-22 at 18:18 +0200, Jeroen van Meeuwen (Kolab Systems) wrote: The scenario is integration, not extension of Cyrus -which in and of itself works perfecly fine and reliable for us. We're not seeking to improve Cyrus' performance with *SQL db backends. But, this assumes the data that Cyrus stores in that DB would be useful outside the context of the Cyrus' processes. I've lightly played with the idea, and not gone any further - the data available isn't really very useful. Well, for one, our ActiveSync implementation wants the following information; - List of (subscribed) IMAP folders, - Annotations, per IMAP folder, - Current status of the contents of such IMAP folder, such as new messages or deleted messages, in comparison to what the client currently holds, - Message contents. While connecting through the IMAP server and have Cyrus hand over the answers, and correlate such information on the side of the 3rd party application is perfectly feasible, I think it may be more efficient to correlate the requested information from a database directly, as opposed to attempting to cache the results handed over by Cyrus by each 3rd party application. Imagine the following scenario; a client polls 3rd party application for a list of mailboxes and the content's status very regularly -basically what it's interested in knowing is whether anything changed. Doesn't condstore solve this issue inexpensively? [maybe I misunderstand condstore]. I thought it was equivalent to WebDAV/CalDAV ctags (which are mightily nice). I'm not sure whether the IMAP server's capabilities with regards to modification sequences has anything to do with this thread, but maybe I'm misunderstanding the IMAP CONDSTORE extension. Each 3rd party app will seek to cache the results somehow, for improved performance interacting with its clients and as to not continuously put load on the Cyrus server. Which is what WebDAV/CalDAV ctags are for. The WebDAV/CalDAV scenario doesn't really fly with mailboxes. For one, mailboxes tend to have plenty more folders and plenty more messages. The question is not how the 3rd party app *can* get the needed information, the question is how many 3rd party apps can be integrated *most efficiently* (both in terms of performance/lower overhead, as well as architecture and 3rd party app's design -DYI cache for each 3rd party app?). Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: competition
Andy Bennett andy...@ashurst.eu.org wrote: Hi, Kolab Systems is thinking of such SQL databases for integration purposes, where the performance penalty now lies within having to use the IMAP protocol to gain access to the underlying metadata (seen status, message indexes) in distributed groupware environments where Cyrus itself is not the only component that needs access to such information (but would still remain authoritative, of course, and would be the only component with write access to most tables). While not necessarily the best approach, it seems worth exploring. What makes you think the query parsing and other overheads of SQL will be faster than IMAP? I'd be interested in any numbers that you might have to support the effort. The scenario is integration, not extension of Cyrus -which in and of itself works perfecly fine and reliable for us. We're not seeking to improve Cyrus' performance with *SQL db backends. Imagine the following scenario; a client polls 3rd party application for a list of mailboxes and the content's status very regularly -basically what it's interested in knowing is whether anything changed. Each 3rd party app will seek to cache the results somehow, for improved performance interacting with its clients and as to not continuously put load on the Cyrus server. Our idea is to prevent that caching from needing to happen, and needlessly be duplicated technology across 3rd party apps, by using what Cyrus would consider it's live data in SQL as the 3rd party app's cache. Now, I don't have any numbers to compare while there is no Cyrus SQL db backend for the relevant databases. I'm just thinking that a single database query -if it could provide accurate status info- can be more efficient -to the Cyrus server(s) itself as well as the 3rd party app- then folderlist, iterate, request status info, parse, only to ultimately throw back at the client there's no changes -which is the result most of the time. It'd also eliminate duplicating attempts to cache folderlist and status results somehow, and would ultimately improve the scalability of such 3rd party apps as part of the infra they require to be shared..., since its cache is in SQL, etc. etc. The big downside to using an SQL database is the enormous temptation to point all the Cyrus servers at the same Database server and lose the redundancy and scalability inherent in a multi node or Murder setup. One would set up the database backend server infrastructure just as much conform to H/A and L/B requirements as the rest of the Cyrus/groupware infrastructure, not unlike how you would set up a sustainable database backend server infrastructure in any other type of critical environment. -- Jeroen Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Repos [Was: competition]
Adam Tauno Williams wrote: On Tue, 2010-09-21 at 12:25 +0200, Syren Baran wrote: Am Dienstag, den 21.09.2010, 11:48 +0200 schrieb André Schild: Am 21.09.2010 11:35, schrieb Simon Matter: I don't know, where this bad karma is coming from - I'm still happy with I guess it's simply because for many years there were no clean packages for the most used operating systems. Debian is still stuck on 2.2 and there seems to be no progress in that area. Most people like to use versions from repositories. For obvious reasons. Might make sense for cyrus to host their own repository. If it's just a simple entry in sources.list(.d) more people would use the recent version. The OBS supports just about every distro there is; why not host there? It'll build *something* for all distributions, but it does definitely not *support* all distributions. In fact, as a premier packager for Fedora + derivatives including but not limited to Red Hat Enterprise Linux and CentOS, and add-on repositories such as Extra Packages for Enterprise Linux as well as RPM Fusion, I can tell you I would hate to have to work with and around OBS; The OBS builds based on what SUSE thinks is an upstream version of RPM, while it's not. Undoubtedly, the build tools they use for APT-based distributions are much closer to what is in the actual distributions. Either way, in relation to my domain, RPM-based systems, as such, it is simply fundamentally flawed. The results stretch from allowed packaging foo that would never be accepted by any actual distribution, to retraceable steps during builds resulting in non-reproducible build products nonetheless. If I were to draw an analogy it would have to be; fixing your car with only a hammer If you want to build native packages for a distribution, I very, very strongly recommend to use the methods of such distribution (whether in your own repositories or not), stick to their specific packaging guidelines, and use their packaging efforts as well as your own to move both forward. For APT- based systems, this means git/svn/cvs/hg-buildpackage w/ pbuilder/cowbuilder (if not distributed), for RPM-based distributions this means dist-git and Koji. Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: competition
Kolab Systems is thinking of such SQL databases for integration purposes, where the performance penalty now lies within having to use the IMAP protocol to gain access to the underlying metadata (seen status, message indexes) in distributed groupware environments where Cyrus itself is not the only component that needs access to such information (but would still remain authoritative, of course, and would be the only component with write access to most tables). While not necessarily the best approach, it seems worth exploring. Kind regards, Jeroen van Meeuwen -From his Android André Schild an...@schild.ws wrote: Am 22.09.2010 16:17, schrieb Lucas Zinato Carraro: For me it would be very interesting a option to save cyrus tables in a traditional database. ( mysql, postgresql, etc... ) Beside interesting what would you get for a real benefit from this ? They are ver verly likely to be slower. André Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: CVS to GIT (was: New Cyrus project site and bugzilla)
Mark Cave-Ayland wrote: Bron Gondwana wrote: The main criticism I have from a developer point of view is, well, CVS. Enough said. Please please can we have an official git mirror? It makes maintaining out-of-tree patches so much easier in the long run, and therefore much more likely that we can pass the patches back upstream. We're working on it! I'm hoping to chat with Jeroen from Kolab about it again tonight. We've got a partial merge into git - but we just want to make sure all the tags and authors and stuff are imported properly before cutting over. And to give people enough warning to change :) Excellent news! FWIW the PostgreSQL team have been trying to switch to git for the past month, and in the process have involved the cvs2git maintainers and had some fixes committed over the past few weeks to improve the migration process (note that they have also suffered from having to hand-tweak the repository to fix various bugs in CVS). The thread about the entire process is very long, but for those interested the latest summary is here: http://archives.postgresql.org/pgsql-hackers/2010-09/msg00636.php. We have a working sample, with a documented procedure, to move three CVS modules (cmulocal, cyrus and sieve) into one GIT repository: http://www.cyrusimap.org/mediawiki/index.php/Drafts/CVS_to_GIT_Conversion#Stab_.232 There some about branch and tag conversions as well. You can find the result (which is preliminary!!) at http://git.kolabsys.com/cyrus-imapd.git. I'll be working with Dave to get this setup over on cyrusimap.org as soon as possible as well, but meanwhile, feedback is more then welcome! Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Draft: Bugzilla Work Flow
Jeroen van Meeuwen (Kolab Systems) wrote: Hello there, Nudging ;-) CC:'ing the info list as well. I'm working on a documented Bugzilla work flow, in an attempt to streamline how we all work with it and what the average consumer may or may not expect. To allow some early feedback, I'm putting the page on the list now as opposed to when I feel like I'm done documenting everything in full ;-) http://www.cyrusimap.org/mediawiki/index.php/User:Jeroen_van_Meeuwen/Drafts/Bugzilla_Work_Flow Please note that these would, in any case, be guidelines, not law. There's no intention to make anyone's life any more difficult ;-) The attempt is to document what mere mortals like myself, and those people that are on the reporting end of bugs might expect, and to allow new contributors like myself to read up on what is an agreeable approach to handling Bugzilla issues. -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Draft: Bugzilla Work Flow
Bron Gondwana wrote: That looks really good actually. I guess the side question is Is Bugzilla the ideal tool for this? I've seen setups where commit messages in the change management tool can be tied directly to tickets. It's probably not essential though - if we have a process and we all know how to follow it. There's git-bugzilla for this purpose. I haven't actually worked with it though. There's also a python-bugzilla CLI client, which we could (possibly) use as a commit hook to update any tickets referred to in the commit message. Speaking of which - the auto bugzilla reminder emails are great :) Occasional annoyances that go away when you do the right thing are very useful. Yeah, so is the automagically put someone in CC: on bug update, having someone as a QA contact, or workflow enhancements (somebody patches some bug, closes the bug and release engineering looks to forward/backporting it). Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: CVS to GIT
Mark Cave-Ayland wrote: Oooh very nice. It seems to be a common issue that projects have to tweak their CVS repositories by hand to get a reasonable conversion to git. I'll try and take a closer look when I get a spare moment. Thanks! My other point, of course, was that since the PostgreSQL guys worked to fix a couple of bugs in cvs2git over the past couple of weeks, you may get a better result if you grab the tip version of cvs2git and re-run the conversion. If we were using cvs2git, sure! But we're not using cvs2git, we're using git- cvsimport ;-) Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: CVS to GIT
Brian Awood wrote: On Mon, 13 Sep 2010 16:34:02 +0200, Jeroen van Meeuwen (Kolab Systems) vanmeeu...@kolabsys.com wrote: Mark Cave-Ayland wrote: My other point, of course, was that since the PostgreSQL guys worked to fix a couple of bugs in cvs2git over the past couple of weeks, you may get a better result if you grab the tip version of cvs2git and re-run the conversion. If we were using cvs2git, sure! But we're not using cvs2git, we're using git-cvsimport ;-) I would highly recommend cvs2git over git-cvsimport for reproducing an accurate history of the cvs repository. cvs2git doesn't do incremental imports like cvsimport, but I don't think that is needed in this situation. You may want to give it a try, just for a comparison anyway. I'm not sure what I am to understand from this. I've done thousands of conversions both with cvs2git as well as git-cvsimport. If you think there is a problem with git-cvsimport I may be unaware of, or there is a solution cvs2git has implemented that may or may not have been an actual problem with git-cvsimport, please point those out. Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: [PATCH] Disable reverse DNS lookups
Guilherme Manika wrote: This patch adds a disablereverselookups option to imapd.conf that disables reverse DNS lookups in imapd and pop3d. It doesn't affect other services (lmtp, mupdate, etc.) because they are not Internet-facing services and so do not rely on external DNS to work. That's probably acceptable. Mind sharing with us what the purpose of this patch is? Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: A beginner question about Murder
Bron Gondwana wrote: On Wed, Sep 08, 2010 at 11:17:00PM +0200, Jeroen van Meeuwen (Kolab Systems) wrote: - For autocreate/autosieve (patches for which Cyrus is not upstream but they are shipped with Fedora and Red Hat Enterprise Linux packages), the frontend servers must be disabled for local direct delivery through the lmtp proxy, and instead relay through the backend server's MTA for autocreate to create the mailbox on a backend server (and not a frontend server which would then loop back to itself). The same goes for autocreate on login, which would cause the frontend to create a mailbox on the local default partition rather then on one of the backends in the Murder. Sounds to me like a case for fixing the autocreate/autosieve patches! Bron ( hey - what timezone are you in, and do you use instant messaging? ) Hey, I'm in UTC+2 sometimes, and UTC+1 some other times, and then DST and such and so forth... the Netherlands, Switzerland and the UK ;-) My Google Talk username is kana...@gmail.com Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: A beginner question about Murder
Bron Gondwana wrote: On Wed, Sep 08, 2010 at 11:17:00PM +0200, Jeroen van Meeuwen (Kolab Systems) wrote: - For autocreate/autosieve (patches for which Cyrus is not upstream but they are shipped with Fedora and Red Hat Enterprise Linux packages), the frontend servers must be disabled for local direct delivery through the lmtp proxy, and instead relay through the backend server's MTA for autocreate to create the mailbox on a backend server (and not a frontend server which would then loop back to itself). The same goes for autocreate on login, which would cause the frontend to create a mailbox on the local default partition rather then on one of the backends in the Murder. Sounds to me like a case for fixing the autocreate/autosieve patches! Uh oh, I forgot that went back to the list as well. Ohw well. To answer the remark; yes it does mean that. I'm going to have to do that / make that happen, and other miscellaneous stuff. It is well-known the autocreate patches are not really compatible with a traditional Murder setup. I have a branch in my GIT repository, but I'm not fully up to speed as to the exact implementation details yet. I'm not at all that well a coder anyways. Maybe we can discuss in a chat session sometime? Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: A beginner question about Murder
Clement Hermann (nodens) wrote: In traditional murder (no autocreate/autosieve patch), the murder process can run on a frontend. However, it cannot run on a backend. We have a webmail running on our murder (2.2.x) server, and it uses localhost as imap server, so it acts as a frontend. However, we don't use autocreate or autosieve, so I couldn't says if it is the same on a patched setup. When you say traditional murder, do you also mean one single mupdate server? I'm sure it's possible, the documentation states it as well. I just haven't managed to actually get it implemented (with the patches that have been shipped for about 5-6 years, in at least 4 generations of Enterprise Linux products and 13 Fedora releases). That's not implemented besides maintaining the actual functionality of the autocreation of mailboxes or sieve scripts or implementation details thereof; the cyrus master process just wouldn't start. Thank you in advance, Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: New Cyrus project site and bugzilla
Adam Tauno Williams wrote: I'm updating the Freshmeat entry to point to the shiney new stuff. 1.) I noticed the previous Wiki link now redirects to the home page [I assume that is intentional] 2.) I assume the CVS is still the 'official' SCM for people looking to check out code? Yup, it still is! Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: Domain support in masssievec missing ?
André Schild wrote: Ok, I attached the modified script and also a udiffversion of it. Where should I post/submit this to be included i the main distribution ? Either here, or in bugzilla, I think. I like it, so I'm just going to state my +1 here. It could take a while for the changes to be actually committed to the upstream SCM system since there's few people with access. Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: Domain support in masssievec missing ?
André Schild wrote: Hello Matt, Am 03.09.2010 17:19, schrieb Matt Selsky: Andre, Please submit your patch to bugzilla so that it doesn't get lost. I can't access bugzilla at all. (Tested several times this week) The address is (according to the wiki) http://bugzilla.andrew.cmu.edu/ Firefox just tells me, that it could not connect to that server. Bugzilla, it seems, is being moved to new infrastructure today. -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: New Cyrus project site and bugzilla
Jeroen van Meeuwen (Kolab Systems) wrote: Dave McMurtrie wrote: Good morning, I'm pleased to announce that we are migrating over to a new website and bugzilla server today. Hi Dave, I'm missing CLOSED - DEFERRED bug statuses, for bugs that just have insufficient follow-up. I'm not sure it was there on the old infrastructure, but I would certainly like to have it. Further down the road; - I cannot go to CLOSED immediately, but have to go through RESOLVED, which is wrong of sorts in some cases. - I notice there is no RESOLVED/CLOSED - NEXTRELEASE for RFE tickets. - Between NEW and ASSIGNED can be CONFIRMED - for people like me who can take a NEW bug and confirm it, but cannot actually be ASSIGNED the task of committing the fix. I see there's UNCONFIRMED, which would be reasonable as well, but the initial state for a new bug though is... NEW ;-) Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: New Cyrus project site and bugzilla
Dave McMurtrie wrote: On 9/3/10 4:25 PM, Jeroen van Meeuwen (Kolab Systems) wrote: Further down the road; - I cannot go to CLOSED immediately, but have to go through RESOLVED, which is wrong of sorts in some cases. - I notice there is no RESOLVED/CLOSED - NEXTRELEASE for RFE tickets. - Between NEW and ASSIGNED can be CONFIRMED - for people like me who can take a NEW bug and confirm it, but cannot actually be ASSIGNED the task of committing the fix. I see there's UNCONFIRMED, which would be reasonable as well, but the initial state for a new bug though is... NEW ;-) Hi Jeroen, I gave you admin and tweakparams rights in bugzilla. There's a fancy interface for Bug Status Workflow under the Administration menu that should allow you to set this up however you think is best. Apologies that I did not copy this configuration over from the old server, but I completely missed it. If you have issues, or simply don't have the time to work on it, I can try again to copy the params from the old server. Hi Dave, I don't think I had these permissions on the old system, but I thank you, and I'll make sure to propose documented work flows on the list before I actually implement them. Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html ^^ You may want to update the list signature as well ;-) Kind regards, -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: shared \seen flags on shared folders
Dan White wrote: On 12/08/10 14:17 +0100, Gavin McCullagh wrote: we have a kolab server here which as you probably know uses Cyrus for its IMAP/POP/LMTP services. One issue we come across now and then is with a group who share a generic incoming email address as well as each having their own personal address. This email may take general customer queries for example. They want to be able to share the \seen flag between them, so that if one user reads the email and deals with it, the others no longer see it as unread in their clients. Gavin, The /vendor/cmu/cyrus-imapd/sharedseen annotation will share the seen state for a given mailbox. In cyradm, you enable it with: mboxconfig mailbox sharedseen true See the cyradm man page. This feature was introduced in version 2.3.9. Note that setting flushseenstate may come in handy here as well. -- Jeroen van Meeuwen Senior Engineer, Kolab Systems AG e: vanmeeu...@kolabsys.com t: +316 42 801 403 w: http://www.kolabsys.com pgp: 9342 BF08 Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
