Re: segfaults with cyrus-imapd 3.0.9 on latest arch linux
Hi Andreas - Jakob has already updated the AUR package, which appears to have resolved this issue. The related upstream bug is #2629. Regarding the dependencies in the cyrus-imapd PKGBUILD. I recommend starting with Jakob's PKGBUILD and just stripping out the stuff you don't need. I've spent so much time looking at it at this point, if you tell me what you don't want, I can probably post a PKGBUILD that works for your requirements. In any case, please try cyrus-imapd 3.0.9-2 and let me know if this resolves the issue for you, too. Here is an explanation (provided by the AUR package maintainer) of the purpose of the various dependencies he's included (also the ones listed as requirements which he did not include). We had pre-agreed that there is no harm in compiling in all the authentication hooks and CalDAV/CalCard dependencies. Without the authentication hooks, the package isn't really general purpose. - gperf seems to be useful for development only (maintainer mode) - libbsd is only required for krb5afspts which is disabled (because IIRC it looks for static libraries which Arch doesn’t package) - ICU: This seems to be genuinely missing, though as you noticed it is already required indirectly. It is probably still a good idea to make that dependency explicit. But since it’s a relatively minor problem I’ll wait to see if anything else comes up in our conversation so I can “bundle” the changes. - clamav is in fact already in optdepends, however in order to build against it it needs to be in makedepends as well - xapian-core provides efficient indexed search, which I’d argue is quite a useful feature to have in a mail server. It is linked into libcyrus_imap.so though, which is in turn linked into imapd (unlike clamav), therefore it is a hard dependency. - libcap allows Cyrus’s services to restrict their own capabilities(7) for enhanced security - libnghttp2 and brotli add support for HTTP/2 and Brotli compression of HTTP responses, respectively; which is relevant to CalDAV, CardDAV and other HTTP services (including JMAP in future versions) - shapelib allows Cyrus’s Time Zone Distribution Service[2] to associate time zones with geographical locations - python-sphinx, perl-pod-pom-view-restructured: required for generation of some manpages (which are included in the regular package, not the -docs one. I’d argue that manpages are actually useful to have around). These are only needed at buildtime and need not be present on the actual server system. On 3/19/19 5:37 PM, Andreas Piesk wrote: Am 19.03.19 um 22:00 schrieb Patrick Goetz: Have you tried the 3.0.9 AUR package? https://aur.archlinux.org/packages/cyrus-imapd Once you get the dependencies down, this one compiles and runs. I noticed the package, it's good to see a recent version in AUR but it has too many dependecies for my taste, I need a stripped down version. Unfortunately the AUR package doesn't work for me either, i build it in a VM with a fresh installed arch and it has the same problem: Starting program: /usr/bin/cyrdump user/test [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x77c76205 in re_compile_internal () from /usr/lib/libc.so.6 (gdb) bt #0 0x77c76205 in re_compile_internal () from /usr/lib/libc.so.6 #1 0x77c77511 in regcomp () from /usr/lib/libc.so.6 #2 0x77e3d980 in glob_init () from /usr/lib/libcyrus.so.0 #3 0x77f38276 in ?? () from /usr/lib/libcyrus_imap.so.0 #4 0x77f3e5b7 in mboxlist_findallmulti () from /usr/lib/libcyrus_imap.so.0 #5 0x61aa in ?? () #6 0x77bbb223 in __libc_start_main () from /usr/lib/libc.so.6 #7 0x61ee in ?? () Best Regards, -ap 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: segfaults with cyrus-imapd 3.0.9 on latest arch linux
Hi - I can confirm this segmentation fault on my own Arch VM with cyrus installed from the AUR package. As an experiment, I tried building the package with --disable-pcre but then I can't even get the program to compile: In file included from lib/glob.c:50: lib/glob.h:57:5: error: unknown type name ‘regex_t’ regex_t regex; ^~~ lib/glob.c: In function ‘glob_init’: lib/glob.c:112:5: warning: implicit declaration of function ‘regcomp’; did you mean ‘memcmp’? [-Wimplicit-function-declaration] regcomp(>regex, buf_cstring(), REG_EXTENDED); ^~~ memcmp lib/glob.c:112:43: error: ‘REG_EXTENDED’ undeclared (first use in this function) regcomp(>regex, buf_cstring(), REG_EXTENDED); ^~~~ It would appear that --disable-pcre is a configuration option you can't actually use. On 3/19/19 5:37 PM, Andreas Piesk wrote: Am 19.03.19 um 22:00 schrieb Patrick Goetz: Have you tried the 3.0.9 AUR package? https://aur.archlinux.org/packages/cyrus-imapd Once you get the dependencies down, this one compiles and runs. I noticed the package, it's good to see a recent version in AUR but it has too many dependecies for my taste, I need a stripped down version. Unfortunately the AUR package doesn't work for me either, i build it in a VM with a fresh installed arch and it has the same problem: Starting program: /usr/bin/cyrdump user/test [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x77c76205 in re_compile_internal () from /usr/lib/libc.so.6 (gdb) bt #0 0x77c76205 in re_compile_internal () from /usr/lib/libc.so.6 #1 0x77c77511 in regcomp () from /usr/lib/libc.so.6 #2 0x77e3d980 in glob_init () from /usr/lib/libcyrus.so.0 #3 0x77f38276 in ?? () from /usr/lib/libcyrus_imap.so.0 #4 0x77f3e5b7 in mboxlist_findallmulti () from /usr/lib/libcyrus_imap.so.0 #5 0x61aa in ?? () #6 0x77bbb223 in __libc_start_main () from /usr/lib/libc.so.6 #7 0x61ee in ?? () Best Regards, -ap 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-imapd build dependencies
This page on compiling cyrus-imapd: https://www.cyrusimap.org/imap/developer/compiling.html shows a number of build dependencies; however I was just able to compile cyrus-imapd without these installed: gperf libbsd Are these actually necessary? Later in the page, under "Alternate database formats" it shows the configure flags to use in order to use mysql/mariadb as a backend for cyrus databases. I think this is needed if one plans to use virtual domains, but I couldn't get a confirmation on this. In any case, the configure options are given as --with-mysql, --with-mysql-incdir, --with-mysql-libdir with no clear indication of what each of these does. For example, is the --with-mysql all inclusive, or does one need to set all 3? Finally a couple of items in the "Other" category are a real head scratcher. For example, what is the purpose of net-snmp? libnghttp2 is listed as needed for "HTTP/2 support for httpd" -- what's using httpd? Is this to faciliate CalDAV/CardDAV?
Re: Unifying the Cyrus World
Was this issue ever resolved? I'm still finding the documentation split between cyrus.foundation and cyrusimap.org, and it's incomplete in both places. On 09/16/2015 08:50 PM, Nicola Nye wrote: Dear Cyrus folks, After nominally completing the migration of the docs from the wiki at cyrusimap.org onto the sphinx repository at docs.cyrus.foundation, I worked out there was a whole bunch of existing services at cyrusimap.org that were non-trivial to relocate. Which, after some discussion at the Cyrus hangout, we felt that retaining cyrusimap.org as our primary (and sole) presence made more sense. Equally, there are some documentation issues that are affected by our current straddling of two worlds. Read on for a discussion of the issues and down to the options and recommendation. I'd love to have your input (particularly Nic Bernstein on the docs angle!) if you agree or disagree so we can make for a more unified Cyrus presence. *Issues* 1) Branding We are currently split across two internet presences: cyrus.foundation and cyrusimap.org. This is confusing. We should only have one. The cyrus.foundation domain name is not of real use as there is a pre-existing entity (The Cyrus Foundation) of the same name. Swapping our internet domain name presence from cyrusimap.org to cyrus.foundation is no longer a significant driver as a result, especially as cyrusimap.org is already indexed and linked to around the net and is unambiguous. (Yes, Cyrus does so much more than just imap, but it's the primary association) Currently services are split across the two domains - git repos, phabricator and authoritative online docs on cyrus.foundation, while downloads, bugzilla and generated docs are on cyrusimap.org. 2) Docs logistics The docs repo is separate to source which is causing friction keeping man pages updated. We want man pages in two formats: *nix for actual man pages to ship and install with cyrus, and html for web presentation. Nice to have: ship a snapshot of all current docs (not just man pages) along with source distribution. 3) Sphinx vs wiki We have been working towards making the content on cyrus.foundation to be the most up to date. This is using Sphinx, which allows us to generate, from the same source, man pages as well as web pages. (And even pdf or single page html). So we get nicer output format options. Clearer history in the git log than you get from wiki. Cyrusimap docs are held in mediawiki. Not so great for man pages. But it's much easier for third party contributor to pitch in and help out: they don't need to learn rst, they don't need a phabricator account, they don't need to navigate git. *Possible solutions* In all cases it seems clear that we should stop using the cyrus.foundation domain and ideally services that are hosted there be shifted to live alongside cyrusimap.org for ease of access. There are a number of @cyrus.foundation email accounts that would need to be dealt with for Chris Davies' testing. Option 1: Single domain, unify git repos, use sphinx everywhere Moving the git repo to cyrusimap (or anywhere) isn't hard. (a job for Bron) Get rid of separate cyrus-docs repo. Put cyrus-docs stuff back inside cyrus-imapd/docs for easier man page generation and tagging of docs versions with source, and shipping of current docs with source. Put sphinx on cyrusimap to replace the wiki. This requires either: 1. working out how to set up the existing generated docs for use with sphinx, 2. or make all the stuff in cyrus-imapd/doc into rst so it works with sphinx. We can still ship the built html. Option 2: Single domain, unify git repos, use wiki for docs - Put sphinx on cyrusimap.org just for generating man page html. Leave the existing wiki where it is for documentation. (Requires porting the page updates I made from cyrus.foundation onto the wiki). This means the only thing left in the cyrus-docs git repo would be the man pages, at which point it makes more sense to put them back into the cyrus-source repo. We can still ship docs with the release if we tie in a wiki export into the release-building process. (A job for Ellie and I) Option 3: Single domain, separate git repos, use sphinx for docs -- Move all services to cyrusimap.org, but still leaves us with all the docs logistics and sphinx and wiki chafe points. Not recommended. *Recommendation* I am leaning towards suggesting option 2. Anything that makes documentation support easier is a good! But we'd still like to retain the usefulness of sphinx for generating two output formats from single source man pages. *What Now? * Discuss! I imagine those folks who come to the Hangout in the next few meetings will kick it around and we'll come to a decision next week. Nicola
virtdomains
It seems that everyone is using virdomains now, and I need to start doing this soon myself. 2 questions: 1. Can I use virtdomain accounts alongside the existing non-domain-specific accounts; or more precisely 2. Can I just add the virtdomain functionality to my existing install without disrupting the existing mail service in any way? Or does this become a management headache? Thanks.
Re: 2.5.3: Inconsistency in subscription list separator?
If you can figure out what the issue is from the telemetry files, let me know. This user in contacting me every day freaking out because he can't get to these email folders (or transfer message to others). Also, can I get confirmation that reconstructing the mailboxes with reconstruct -r -f /user/djones should solve the problem, or is this way off base? I love cyrus best when I'm not thinking about it at all. <:) On 9/24/2015 8:46 PM, Bron Gondwana wrote: Telemetry at the Cyrus end. I can see that we really need to get docs for this somewhere logical (CC Nicola: how to do telemetry logging is pretty much a FAQ) To enable telemetry logging for a user, you need to create a directory on disk. The directory path is $confdir/log/$userid/ - for example /var/imap/log/brong If you have virtdomains enabled, then the username is the login name, so if you login as br...@fastmail.fm, then the path is .../log/br...@fastmail.fm/ IMPORTANT: user cyrus needs to be able to write to this directory, so 'chown cyrus /var/imap/log/brong' or whatever. Also - only new connections will be logged. You don't need to restart Cyrus, just entirely closing Thunderbird and restarting it will do the trick. The folder will contain files called imapd-$pid, e.g. imapd-12345. It might also have pop3 files, httpd files, whatever other daemons you're running. The first part of the name is the service name from cyrus.conf. These log files won't contain passwords (cyrus avoids writing those), but may contain other confidential user data - for example the content of emails - so check them over before sharing publicly! Cheers, Bron. On Fri, Sep 25, 2015, at 11:21, Patrick Goetz wrote: Hi - I see how to enable telemetry, but I'm clueless as to how to collect the dumps. I thought there might be a plugin for this, but a search for "telemetry" under Add-ons brought up nothing. On 9/24/2015 7:04 PM, Bron Gondwana wrote: Can you get telemetry dumps please, of Thunderbird connecting and getting the folder listing and trying to access On Thu, Sep 24, 2015, at 23:08, Patrick Goetz wrote: Hi Bron - Just a quick clarification: - The folder exists - The subscription exists - The ACLS on the folder correspond to full permissions for the user: pgoetz@www:~$ cyradm --user administrator localhost verify error:num=18:self signed certificate IMAP Password: localhost> localhost> lam user/djones/Archives\ Staff djones lrswipkxtecd localhost> However, after the upgrade to 2.5.3 from 2.4.17 the user can no longer access this folder or the sub-folders under it. In Thunderbird, he can see the folders, but they are grayed out; in Roundcube they aren't visible. I thought it might be an MUA issue and ask him to delete his local Thunderbird configuration/data, but that didn't resolve the problem He also has a few other folders with similar problems; i.e. in one case the folder name isn't grayed out, but the messages in the folder are invisible. Clicking on the folder using Thunderbird he gets an error message "the action cannot be completed because the account does not exist" or something like this. I'm completely mystified at how such a state can exist. When I go to the physical mail spool the folders and messages are definitely all there. On 09/24/2015 05:11 AM, Bron Gondwana wrote: On Thu, Sep 24, 2015, at 19:54, Patrick Goetz wrote: I posted a question about this to the info list, but think it might be more of a devel issue. Yeah, I saw it there and almost replied, but I got busy with a support ticket and forgot to get back to you. I recently upgraded from 2.4.17 to 2.5.3. This went more of less smoothly; however, one user appears to have lost access to some of his mail sub-folders. They're grayed out in Thunderbird and don't even show up when using Roundcube. Someone on the info list suggested that I check the user's subscription list, where I noticed this: user.djones.Archives Staff user.djones.Archives Staff.1Amy Smith user.djones.Archives Staff.David Jones user.djones.Archives Staff.Delia Burton user.djones.Archives Staff.Drew Patterson user.djones.Archives Staff.Eleanor Smythe user.djones.Archives Staff.Former Staff user.djones.Archives Staff.Julia Moscovy user.djones.Archives Staff.Kate Ooldfield user.djones.Archives Staff.Amy Smith This, by the way, is one of the sub-folders no longer accessible to the user. That's OK - subscription items can exist without the folder existing. The standard basically requires it.
2.5.3: Inconsistency in subscription list separator?
I posted a question about this to the info list, but think it might be more of a devel issue. I recently upgraded from 2.4.17 to 2.5.3. This went more of less smoothly; however, one user appears to have lost access to some of his mail sub-folders. They're grayed out in Thunderbird and don't even show up when using Roundcube. Someone on the info list suggested that I check the user's subscription list, where I noticed this: user.djones.Archives Staff user.djones.Archives Staff.1Amy Smith user.djones.Archives Staff.David Jones user.djones.Archives Staff.Delia Burton user.djones.Archives Staff.Drew Patterson user.djones.Archives Staff.Eleanor Smythe user.djones.Archives Staff.Former Staff user.djones.Archives Staff.Julia Moscovy user.djones.Archives Staff.Kate Ooldfield user.djones.Archives Staff.Amy Smith This, by the way, is one of the sub-folders no longer accessible to the user. I've been using unixhierarchysep: yes since version 2.4.17, yet the subscription list is still formatted using a "." as a separator? What happens if there is a "." in the mailbox folder name? Second, this would appear to be a permissions problem, but the permissions on that mailbox look absolutely normal. Maybe I just need to run cyrreconstruct to rebuild the indexes for the affected mailbox folders? I've never seen this problem before and am clueless as to how to address it. localhost> lam user/djones djones lrswipkxtecd localhost> lam user/djones/Archives\ Staff djones lrswipkxtecd localhost> lam user/djones/Archives\ Staff/1Amy\ Smith djones lrswipkxtecd
Re: 2.5.3: Inconsistency in subscription list separator?
Hi Bron - Just a quick clarification: - The folder exists - The subscription exists - The ACLS on the folder correspond to full permissions for the user: pgoetz@www:~$ cyradm --user administrator localhost verify error:num=18:self signed certificate IMAP Password: localhost> localhost> lam user/djones/Archives\ Staff djones lrswipkxtecd localhost> However, after the upgrade to 2.5.3 from 2.4.17 the user can no longer access this folder or the sub-folders under it. In Thunderbird, he can see the folders, but they are grayed out; in Roundcube they aren't visible. I thought it might be an MUA issue and ask him to delete his local Thunderbird configuration/data, but that didn't resolve the problem He also has a few other folders with similar problems; i.e. in one case the folder name isn't grayed out, but the messages in the folder are invisible. Clicking on the folder using Thunderbird he gets an error message "the action cannot be completed because the account does not exist" or something like this. I'm completely mystified at how such a state can exist. When I go to the physical mail spool the folders and messages are definitely all there. On 09/24/2015 05:11 AM, Bron Gondwana wrote: On Thu, Sep 24, 2015, at 19:54, Patrick Goetz wrote: I posted a question about this to the info list, but think it might be more of a devel issue. Yeah, I saw it there and almost replied, but I got busy with a support ticket and forgot to get back to you. I recently upgraded from 2.4.17 to 2.5.3. This went more of less smoothly; however, one user appears to have lost access to some of his mail sub-folders. They're grayed out in Thunderbird and don't even show up when using Roundcube. Someone on the info list suggested that I check the user's subscription list, where I noticed this: user.djones.Archives Staff user.djones.Archives Staff.1Amy Smith user.djones.Archives Staff.David Jones user.djones.Archives Staff.Delia Burton user.djones.Archives Staff.Drew Patterson user.djones.Archives Staff.Eleanor Smythe user.djones.Archives Staff.Former Staff user.djones.Archives Staff.Julia Moscovy user.djones.Archives Staff.Kate Ooldfield user.djones.Archives Staff.Amy Smith This, by the way, is one of the sub-folders no longer accessible to the user. That's OK - subscription items can exist without the folder existing. The standard basically requires it.
Re: 2.5.3: Inconsistency in subscription list separator?
Hi - I see how to enable telemetry, but I'm clueless as to how to collect the dumps. I thought there might be a plugin for this, but a search for "telemetry" under Add-ons brought up nothing. On 9/24/2015 7:04 PM, Bron Gondwana wrote: Can you get telemetry dumps please, of Thunderbird connecting and getting the folder listing and trying to access On Thu, Sep 24, 2015, at 23:08, Patrick Goetz wrote: Hi Bron - Just a quick clarification: - The folder exists - The subscription exists - The ACLS on the folder correspond to full permissions for the user: pgoetz@www:~$ cyradm --user administrator localhost verify error:num=18:self signed certificate IMAP Password: localhost> localhost> lam user/djones/Archives\ Staff djones lrswipkxtecd localhost> However, after the upgrade to 2.5.3 from 2.4.17 the user can no longer access this folder or the sub-folders under it. In Thunderbird, he can see the folders, but they are grayed out; in Roundcube they aren't visible. I thought it might be an MUA issue and ask him to delete his local Thunderbird configuration/data, but that didn't resolve the problem He also has a few other folders with similar problems; i.e. in one case the folder name isn't grayed out, but the messages in the folder are invisible. Clicking on the folder using Thunderbird he gets an error message "the action cannot be completed because the account does not exist" or something like this. I'm completely mystified at how such a state can exist. When I go to the physical mail spool the folders and messages are definitely all there. On 09/24/2015 05:11 AM, Bron Gondwana wrote: On Thu, Sep 24, 2015, at 19:54, Patrick Goetz wrote: I posted a question about this to the info list, but think it might be more of a devel issue. Yeah, I saw it there and almost replied, but I got busy with a support ticket and forgot to get back to you. I recently upgraded from 2.4.17 to 2.5.3. This went more of less smoothly; however, one user appears to have lost access to some of his mail sub-folders. They're grayed out in Thunderbird and don't even show up when using Roundcube. Someone on the info list suggested that I check the user's subscription list, where I noticed this: user.djones.Archives Staff user.djones.Archives Staff.1Amy Smith user.djones.Archives Staff.David Jones user.djones.Archives Staff.Delia Burton user.djones.Archives Staff.Drew Patterson user.djones.Archives Staff.Eleanor Smythe user.djones.Archives Staff.Former Staff user.djones.Archives Staff.Julia Moscovy user.djones.Archives Staff.Kate Ooldfield user.djones.Archives Staff.Amy Smith This, by the way, is one of the sub-folders no longer accessible to the user. That's OK - subscription items can exist without the folder existing. The standard basically requires it.
2.4.17 --> 2.5.3
I recall Bron telling us that the upgrade from 2.4.x to 2.5.x would be completely painless. That was mostly, but not completely true. A bunch of variable names in /etc/cyrus/imapd.conf changed (OK, that was easy to fix), and the upgrade did mostly work out of the box. There was one issue, however, and there are some new and improved error messages in the logs that I'm sufficiently OCD to have questions about. One one of my installs, I had this line in /etc/cyrus.conf: squatter_a cmd="/usr/sbin/squatter" at=0517 This worked for 2.4.17, but caused cyrus-master to fail to start with this error message: Sep 19 05:27:58 www cyrus/master[29646]: configuration file /etc/cyrus/cyrus.conf: bad character '_' in name on line 57 Sep 19 05:27:58 www systemd[1]: cyrus-master.service: Main process exited, code=exited, status=78/n/a For the time being, I just commented out the squatter line. I'm unclear on how necessary it is to re-index the mailboxes every day. If necessary/useful, did the syntax for this command change? Also, I'm now getting these warnings (maybe some were there for 2.4.17, I can't remember): --- Sep 19 05:44:54 toad systemd[1]: Starting Cyrus IMAP mail server... Sep 19 05:44:54 toad cyrus/master[22860]: setrlimit: Unable to set file descriptors limit to -1: Operation not permitted Sep 19 05:44:54 toad cyrus/master[22860]: retrying with 4096 (current max) Sep 19 05:44:54 toad systemd[1]: Started Cyrus IMAP mail server. Sep 19 05:44:54 toad cyrus/ctl_cyrusdb[22861]: skiplist: clean shutdown file missing, updating recovery stamp Sep 19 05:44:54 toad cyrus/ctl_cyrusdb[22861]: recovering cyrus databases Sep 19 05:44:54 toad cyrus/ctl_cyrusdb[22861]: done recovering cyrus databases Sep 19 05:44:54 toad cyrus/master[22860]: unable to open imap/ipv6 socket: Address family not supported by protocol Sep 19 05:44:54 toad cyrus/master[22860]: unable to open imaps/ipv6 socket: Address family not supported by protocol Sep 19 05:44:54 toad cyrus/master[22860]: unable to open sieve/ipv6 socket: Address family not supported by protocol Sep 19 05:44:54 toad cyrus/master[22860]: unable to setsocketopt(IP_TOS) service lmtpunix/unix: Operation not supported - We're not using ipv6 -- is there any way to let cyrus know so that it doesn't freak out? Second, where is this coming from? Sep 19 05:44:54 toad cyrus/master[22860]: setrlimit: Unable to set file descriptors limit to -1: Operation not permitted Finally, should I worry about this? setsocketopt(IP_TOS) service lmtpunix/unix: Operation not supported Thanks.
Possible TLS dir option name discrepancy?
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?
usenet
excerpted from my /etc/cyrus/cyrus.conf file: # these are only necessary if receiving/exporting usenet via NNTP # nntp cmd=nntpd listen=nntp prefork=0 # nntpscmd=nntpd -s listen=nntps prefork=0 I wonder if it's finally time to trim all the usenet/news cruft out of cyrus? Are all the old-timers willing to let go, or is this a backup plan just in case Skynet actually happens and takes over google?
backing up a cyrus mail store?
Hi - I'm sure I've asked about this before, but is there an approved/canonical way to backup a cyrus mailstore? It's not clear from the documentation what cyrdump does (if anything) and short of stopping the server in order to backup the mailboxes and /var/lib/cyrus with guaranteed synchrony. Pending suggestions from this list, my current plan is to set up cyrus on another host just for the purpose of using imapsync to copy mail from the main mail server to the backup server, say, every night using a cron job.
Re: Coding standards / spaces vs tabs
On 10/20/2010 9:05 PM, Bron Gondwana wrote: P.S. Here's what I use in vim to make life worth living. It makes tabs visible, and lets me indent blocks quickly by 4 characters while creating the correct tabs. If everyone uses vim, then this problem is easily resolved: :) set tabstop=3 set expandtab -- Patrick Goetz
Re: Coding standards / spaces vs tabs
On 10/21/2010 7:10 AM, Bron Gondwana wrote: set tabstop=3 set expandtab 3? Why three? Einstein said make everything as simple as possible, but not too simple. I think a similar principle applies to indentation: indent as little as possible, but not too little. When I first started coding again 10 years ago because both the programmers I was working with abruptly quit for personal reasons, leaving me (and the client) in the lurch, I inherited a bunch of code where tab was used exclusively to indent. In my opinion, tab = 8 characters indentation is ridiculously unreadable. With just 3 or 4 nested blocks your lines start halfway across the page, increasing line breaks. When I discovered tabstop and expandtab in vim, I realized that I could make the indentation anything I damn well pleased and it would automatically be invoked in any file I edited. And since I was the only one working on the code at this point, my opinion was the only one that mattered. After playing around a bit, glancing at a bunch of code to make sure nested blocks jumped out visually, etc., I determined that -- at least for me -- 3 spaces was the optimal number; 2 wasn't enough, 4 excessive. Re: using 8 space tabs. This is the point where someone says what are you talking about? Everyone has 24 1900x1200 monitors these days; you can have a terminal which is 300 characters wide! Yes, and I can also go blind staring at it 8 hours a day -- I'll pass. Re: using tabs for indentation at all: especially given the somewhat disturbing growing ubiquity of python, getting in the habit of using tabs for indentation is like giving a box of matches and a stick of dynamite to your pet monkey. It seems innocuous enough, but sooner or later a tragedy will occur. Mixing tabs and spaces;especially given that the width of tabs is user-definable? Add to the preceding showing the monkey how to light the matches and throw in a couple of liters of gasoline. And yes, I'm aware that Makefiles require tabs; this is just one more indication that make is obsolete and needs to be rewritten from scratch using modern programming paradigms. I know talking about indentation is like starting a vi vs. emacs -- which is better? discussion, but you asked. -- Patrick Goetz
Re: Reconstruct behaviour on IO error
On 10/04/2010 02:07 PM, Bron Gondwana wrote: Keep going and remove entires for messages with IO errors reading their file, or bail and make the administrator fix the underlying permissions first? I can see arguments for both - though remember that once you've removed the index record you can never go back under strict UID existence semantics, so if the admin fixes the files later then reconstruct will actually give them new UIDs. Definitely bail. It's too easy to miss things like this when lots of characters are being piped to the screen, resulting in mail being silently lost. I recently had a user complain about missing sent messages from 2004. He was working on a project that went on hold for a very long time, but now needed to be revisited. I checked the backups and his 2004 sent mail has been gone for at least 5 years (as far back as my backups went). This didn't prevent him from throwing a fit about unreliable systems.
Re: Wiki, information on database back ends.
On 09/14/2010 04:06 PM, Jeroen van Meeuwen (Kolab Systems) wrote:
This file is also written out by the same script. The location of the script
(the mentioning of 'rpm/' in the path) is completely arbitrary (for all the
script cares the file lives in /boot/).
Small correction: created while compiling; from the comments in the
script and the actual lines of code the file appears in:
# The format of current db files is determined using the 'file' command
# with a magic file added for skiplist db, the new format is read from
# a config file usually in /usr/share/cyrus-imapd/rpm/db.cfg, which is
# created while compiling. After converting, the db.cfg file is
...
db_cfg=${data_dir}/db.cfg
db_current=${imap_prefix}/rpm/db.cfg.current
db_cache=${imap_prefix}/rpm/db.cfg.cache
# source default db backend config
. $db_cfg
Re: master process handling patch
On 07/21/2010 05:12 PM, Bron Gondwana wrote:
We decided to pull map_stupidshared. Are you on the cyrus-devel
mailing list?
Yeah, but I've only been on it for a couple of months -- maybe this was
discussed previously.
Trying to evaluate C code that consists of lots of little functions with
no documentation is like playing nethack (you just entered a maze of
twisty little tunnels).
For example, one of the debian package maintainers introduced this patch
to ~/master/master.c:
@ -195,13 +195,17 @@
free(a);
}
-void get_prog(char *path, unsigned size, char *const *cmd)
+void get_prog(char *path, unsigned int size, char *const *cmd)
{
if (cmd[0][0] == '/') {
/* master lacks strlcpy, due to no libcyrus */
snprintf(path, size, %s, cmd[0]);
+ path[size-1] = '\0';
+}
+else {
+ snprintf(path, size, %s/%s, SERVICE_PATH, cmd[0]);
+ path[size-1] = '\0';
}
-else snprintf(path, size, %s/%s, SERVICE_PATH, cmd[0]);
}
The parameter type correction at the top fixes a bug, but what the code
null terminating path? If path is used as a string then this is OK, but
otherwise it could be overwriting a necessary character. To properly
check if this is an OK patch to submit to the bugzilla, I have to track
down every use of the get_prog function.
They're both being removed in Cyrus 2.4. GUID is now compulsary,
so sha1s will be calculated on append.
Not sure what GUID is now compulsory means, but it turns out I was
wrong and that sha1 has also been compromised
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
so hopefully this is just being used to generate checksums and not for
actually security
Re: master process handling patch
On 07/15/2010 05:23 PM, Henrique de Moraes Holschuh wrote: Heh, you can already use whatever we have in the experimental branch, it is good enough for limited use :) This isn't entirely true. This patch, which I mentioned previously, looks like it could lead to header corruption in the saved header stored in ibuf: --- 10-fix_potential_overflows.dpatch: --- git~/imap/message.c 2010-01-16 19:22:57.0 -0200 +++ git/imap/message.c 2010-01-16 19:27:30.915091898 -0200 @@ -996,7 +996,7 @@ /* Save header value */ len = hdrend - hdr; message_ibuf_ensure(ibuf, len+2); -strncpy(ibuf-end, hdr, len); +strncpy(ibuf-end, hdr, len+1); ibuf-end += len; *(ibuf-end)++ = '\r'; *(ibuf-end)++ = '\n'; -- This is kind of an insane situation that there are bug fix patches hanging around that have been in the debian source package since 2.3.8 which haven't been pushed upstream. As a result, I don't trust any of the patches until I've checked them myself. And since I don't understand what patches 12,13 are doing, I'm hoping you'll have time to go over them soon. Meanwhile, I'm going over the patches the redhat people added to cyrus-imapd-2.3.16-5.src (actually, first comparing the differences between this newer version and cyrus-imapd-2.3.16-3.fc13.src) to see if there's anything there that needs to be migrated to the debian package. I haven't done any C programming in a lng time, so part of the delay on my part was getting back up to speed in C. Now that that's done, I hope to be through this in a few days (modulo being out of town all next week).
Re: master process handling patch
On 07/21/2010 02:35 PM, Wesley Craig wrote: On 21 Jul 2010, at 15:27, Patrick Goetz wrote: Meanwhile, I'm going over the patches the redhat people added to cyrus-imapd-2.3.16-5.src (actually, first comparing the differences between this newer version and cyrus-imapd-2.3.16-3.fc13.src) to see if there's anything there that needs to be migrated to the debian package. And pass along anything that hasn't been upstream! What about stuff that's a bug but not really a bug? Recently I asked about some custom memory mapping routines (~/lib/map_stupidshared.c) designed to work around DEC stupidity, incredulous that anyone was still using DEC systems, and didn't get a response. In the case of redhat (cyrus-imapd-2.3.16-5.src), one of the patches fixes ~/imap/make_md5.c by replacing the md5 stuff with sha1. Technically, this isn't a bug fix, but given that md5 is insecure, is it really a good idea not to convert this to make_sha1.c?
Re: master process handling patch
On 07/02/2010 10:11 PM, Henrique de Moraes Holschuh wrote:
+int read_msg(int fd, struct notify_message *msg)
+{
+ssize_t r;
+size_t off = 0;
+size_t s = sizeof(struct notify_message);
No. As I said in the debian cyrus devel list, either ssize_t s =, or
leave it as int. No reason to have signed/unsigned math for something
like that.
OK, this is something of a gray area, as far as I can tell, but since
the theoretical underflow here:
+s -= r;
can't happen because of the context, ssize_t works
(otherwise max size_t = 2 * max ssize_t)
I'm not an expert, but ssize_t is usually used in the context where the
return value might be negative due to an error condition; e.g.
ssize_t read(int fd, void *buf, size_t len)
Several hours of researching this in the glibc manual, etc.. didn't
offer any further elucidation. People seem to use it like this: use
ssize_t instead of size_t when you need to allow for negative values.
The underflow problem mentioned above is known and unresolved, AFAIK.
Also, how do I get on the Debian cyrus devel list?
Also, we have metadata for why this thing exists, it was added by me to
Debian Cyrus 2.1 because of problems seen in the field. We have the
problem documented, and the name of the reporter and tester, changelog
entries of that time, etc. I didn't have time to send it in yet.
Where is this documented?
Comments on the patch are welcome, but please don't merge it as is. I
will clean it up a bit and add the relevant metadata on why it exists
and what it attempts to do.
Thanks, and no problem! I've looked at the code in
13-master_process_handling.dpatch and decided it would take me too long
to figure out what it's supposed to be doing. My time right now is
probably better spent going over the Redhat cyrus 2.3.16 rpm patches to
see if there is anything relevant in there that needs to also be
addressed in the Debian package. Hmmm, if this drags on too much longer
maybe we could just create the next debian version of cyrus like this? :)
alien cyrus-imapd-2.3.16-3.fc13.i686.rpm
They even include a nice howto on reconstructing mailboxes. :)
While you're working on 13-master_process_handling.dpatch, this line
looks suspicious to me:
+ Services[i].babysit = 0;
since I don't see any context for setting this equal to 0 (but again,
I'm not following what this code does, either.
Re: below: presumably you'll do this when you clean up these patches?
diff -urNad git~/master/master.h git/master/master.h
--- git~/master/master.h 2010-01-16 19:21:09.0 -0200
+++ git/master/master.h2010-01-16 19:28:14.289091714 -0200
@@ -45,6 +45,7 @@
extern struct service *Services;
extern int allocservices;
extern int nservices;
+void sighandler_setup(void);
/*
* Description of multiple address family support from
This hunk can be dropped.
master process handling patch
This is another debian patch with lots of changes (see attached). I'm
running out of time for tracing the validity of these and am hoping that
someone else will take a look. This seems to apply to a rather important
part of the whole system, so is probably worth a look.
(Yes, I can submit this to bugzilla, too, if it makes sense to do so.)
Note one minor bug fix in the patch:
+int read_msg(int fd, struct notify_message *msg)
+{
+ssize_t r;
+size_t off = 0;
+int s = sizeof(struct notify_message);
should be
-- --
+int read_msg(int fd, struct notify_message *msg)
+{
+ssize_t r;
+size_t off = 0;
+size_t s = sizeof(struct notify_message);
#! /bin/sh /usr/share/dpatch/dpatch-run
## 13-master_process_handling.dpatch by Sven Mueller deb...@incase.de
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Fixes process (child) handling in master process
@DPATCH@
diff -urNad git~/lib/util.c git/lib/util.c
--- git~/lib/util.c 2010-01-16 19:21:09.0 -0200
+++ git/lib/util.c 2010-01-16 19:28:14.288091659 -0200
@@ -365,9 +365,9 @@
int become_cyrus(void)
{
struct passwd *p;
-int newuid, newgid;
+uid_t newuid, newgid;
int result;
-static int uid = 0;
+static uid_t uid = 0;
if (uid) return setuid(uid);
diff -urNad git~/master/master.c git/master/master.c
--- git~/master/master.c2010-01-16 19:28:14.145091738 -0200
+++ git/master/master.c 2010-01-16 19:28:14.289091714 -0200
@@ -174,6 +174,8 @@
static struct centry *ctable[child_table_size];
static struct centry *cfreelist;
+static int child_mourning_time = 2;/* Time in seconds to remember child
+ after processing SIGCHLD */
static int janitor_frequency = 1; /* Janitor sweeps per second */
static int janitor_position; /* Entry to begin at in next sweep */
static struct timeval janitor_mark;/* Last time janitor did a sweep */
@@ -908,7 +910,7 @@
}
}
c-service_state = SERVICE_STATE_DEAD;
- c-janitor_deadline = time(NULL) + 2;
+ c-janitor_deadline = time(NULL) + child_mourning_time;
} else {
/* weird. Are we multithreaded now? we don't know this child */
syslog(LOG_WARNING,
@@ -917,7 +919,7 @@
c = get_centry();
c-pid = pid;
c-service_state = SERVICE_STATE_DEAD;
- c-janitor_deadline = time(NULL) + 2;
+ c-janitor_deadline = time(NULL) + child_mourning_time;
c-si = SERVICE_NONE;
c-next = ctable[pid % child_table_size];
ctable[pid % child_table_size] = c;
@@ -1073,6 +1075,36 @@
}
}
+/*
+ * Receives a message from a service.
+ *
+ * Returns zero if all goes well
+ * 1 if no msg available
+ * 2 if bad message received (incorrectly sized)
+ * -1 on error (errno set)
+ */
+int read_msg(int fd, struct notify_message *msg)
+{
+ssize_t r;
+size_t off = 0;
+int s = sizeof(struct notify_message);
+
+while (s 0) {
+do
+r = read(fd, msg + off, s);
+while ((r == -1) (errno == EINTR));
+if (r = 0) break;
+s -= r;
+off += r;
+}
+if ( ((r == 0) (off == 0)) ||
+ ((r == -1) (errno == EAGAIN)) )
+return 1;
+if (r == -1) return -1;
+if (s != 0) return 2;
+return 0;
+}
+
void process_msg(const int si, struct notify_message *msg)
{
struct centry *c;
@@ -1398,8 +1430,9 @@
snprintf(buf, sizeof(buf),
cannot find executable for service '%s', name);
- /* if it is not, we're misconfigured, die. */
- fatal(buf, EX_CONFIG);
+ /* if it is not, we just skip it */
+ syslog(LOG_WARNING, WARNING: %s -- ignored, buf);
+ return;
}
Services[i].maxforkrate = maxforkrate;
@@ -1411,7 +1444,7 @@
Services[i].desired_workers = prefork;
Services[i].babysit = babysit;
Services[i].max_workers = atoi(max);
- if (Services[i].max_workers == -1) {
+ if (Services[i].max_workers 0) {
Services[i].max_workers = INT_MAX;
}
} else {
@@ -1419,6 +1452,7 @@
if (prefork 1) prefork = 1;
Services[i].desired_workers = prefork;
Services[i].max_workers = 1;
+ Services[i].babysit = 0;
}
free(max);
@@ -1458,7 +1492,7 @@
if (!strcmp(cmd,)) {
char buf[256];
snprintf(buf, sizeof(buf),
-unable to find command or port for event '%s', name);
+unable to find command for event '%s', name);
if (ignore_err) {
syslog(LOG_WARNING, WARNING: %s -- ignored, buf);
@@ -1514,7 +1548,7 @@
rl.rlim_cur = x;
rl.rlim_max = x;
-if (setrlimit(RLIMIT_NUMFDS, rl) 0) {
+if (setrlimit(RLIMIT_NUMFDS, rl) 0 x != RLIM_INFINITY) {
syslog(LOG_ERR, setrlimit: Unable to set file
Fwd: RE: {Spam?} master process handling patch (verification)
Hopefully it's clear to (almost) everyone that this is the wrong way to
solve the problem, inconveniencing legitimate users and creating a lot
of backscatter otherwise.
Original Message
Subject:RE: {Spam?} master process handling patch (verification)
Date: Fri, 2 Jul 2010 16:32:25 -0500 (CDT)
From: Gordon gmdo...@spamarrest.com
To: pgo...@mail.utexas.edu
http://www.spamarrest.com/a2?AQNjBGN3ZGb6pTqiMKE6DT1unJjhqKEyrTSmYzIxqGcUo3Wxo24j
Sender Verification
Gordon here,
I'm protecting myself from receiving junk mail.
Please click the link below to complete the verification process.
You have to do this only once.
http://www.spamarrest.com/a2?AQNjBGN3ZGb6pTqiMKE6DT1unJjhqKEyrTSmYzIxqGcUo3Wxo24j
You are receiving this message in response to your email to Gordon, a
Spam Arrest customer.
Spam Arrest requests that senders verify themselves before their email
is delivered.
When you click the above link, you will be taken to a page with a
graphic on it. Simply read the word in the graphic, type it into the
form, and you're verified.
You have to do this only once per Spam Arrest customer.
Below are the complete headers of the message that this email was
generated in response to.
Received: from localhost by bx146.blacksun.ca
with SpamAssassin (version 3.2.5);
Fri, 02 Jul 2010 15:31:55 -0600
From: Patrick Goetzpgo...@mail.utexas.edu
To: cyrus-devel@lists.andrew.cmu.edu
Date: Fri, 02 Jul 2010 16:31:08 -0500
Message-Id:4c2e5a9c.3000...@mail.utexas.edu
X-Spam-Flag: YES
X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bx146.blacksun.ca
X-Spam-Level:
X-Spam-Status: Yes, score=8.4 required=4.0 tests=J_CHICKENPOX_41,
J_CHICKENPOX_42,J_CHICKENPOX_53,J_CHICKENPOX_63,J_CHICKENPOX_64,
J_CHICKENPOX_66,J_CHICKENPOX_83,LOCAL_HOST,MATCH_SCANNER,RCVD_IN_DNSWL_MED
autolearn=disabled version=3.2.5
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=--=_4C2E5ACB.9CA955A0
Subject: {Spam?} master process handling patch
X-UIDL: 22%#!dQZ!aa!,!
Re: ~/lib/map_stupidshared.c
On 06/30/2010 11:10 AM, Wesley Craig wrote:
I don't think the people reading the developer list can necessarily
answer that question. The existence of a patch (depending on what the
patch is about) implies that someone cared enough about it to patch it.
Asking on the user list might turn up an answer, but the fact that no
one says yes I'm using it doesn't mean no one is using it.
Sorry, I guess I wasn't being clear. There is a file in the cyrus
2.3.16 source code tree called:
cyrus-imapd-2.3.16/lib/map_stupidshared.c
The comment at the top of this code states:
* map_stupidshared.c -- memory-mapping routines working around DEC
stupidity.
i.e. this is part of the cyrus code base. The debian patch adds
+#include xmalloc.h
which is fairly innocuous.
However, my question is are customized memory mapping routines designed
to work around DEC stupidity still necessary or even desirable in the
current code base?
And speaking of style, the first function in this file is still using
the old pre-ANSI KR style for parameters:
map_refresh(fd, onceonly, base, len, newlen, name, mboxname)
int fd;
int onceonly;
const char **base;
unsigned long *len;
unsigned long newlen;
const char *name;
const char *mboxname;
{
...
Re: Putting cyrus-future code in CVS. Also, code style
Bron Gondwana wrote:
How do you feel about:
if (a) function_one(a);
else function_two();
This is hard to read. My rule is one liner only if it's really a one
liner. Otherwise:
if (a)
{
function_one(a);
} else {function_two();}
is a reasonable compromise between brevity and readability.
minor bug in ~/tools/masssievec
Unused variable in this script (can be dangerous in perl) -- see attached.
#! /bin/sh /usr/share/dpatch/dpatch-run
## 35_masssievec_remove_unused_variable.dpatch by Sven Mueller
deb...@incase.de
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Remove the $nosievedir variable which is set once but never used.
@DPATCH@
diff -urNad git~/tools/masssievec git/tools/masssievec
--- git~/tools/masssievec 2010-01-16 19:33:57.355091520 -0200
+++ git/tools/masssievec2010-01-16 19:33:57.482091059 -0200
@@ -84,7 +84,6 @@
push @configs, $1;
}
if (/^sieveusehomedir:\s+(1|t|yes|on)/) {
- $nosievedir = 1;
print you are storing sieve scripts in user's home directories,
this script cannot deal with that\n;
exit;
}
imapparse.c / getnum
On 06/16/2010 10:09 PM, Bron Gondwana wrote: I'm also replacing everywhere that we advance a character pointer through a string and do the same algorithm with parsenum in lib/util.c. It will have the same logic. No more MAXLITERAL. The getnum code looks basically the same as the bit that used MAXLITERAL (with MAXLITERAL =~ INT_MAX/10 - 10). Of course now the question is why the minus 10?). The patch you sent previously appears to be incompatible with the 2.3.16 tree; for example, the 2.3.16 ~/lib/libconfig.h doesn't have the line extern int config_auditlog; diff --git a/lib/libconfig.h b/lib/libconfig.h index de40784..d70ce31 100644 --- a/lib/libconfig.h +++ b/lib/libconfig.h @@ -79,6 +79,7 @@ extern int config_implicitrights; extern enum enum_value config_virtdomains; extern enum enum_value config_mupdate_config; extern int config_auditlog; +extern int config_maxliteral; I didn't check beyond this, but we'll just go ahead and patch imapparse.c with the existing /20 -- /10 patch and wait for the next release to fix up the patch set. I gave myself a headache trying to figure out how config_getenum() works and am probably going to work on something else for the rest of the day. (Who says that perl is harder to maintain than C? :)) Thanks for working on this stuff and responding to my questions!
debian patches to Shell.pm and sieveshell.pl
This time I'm just attaching a patch file (unified diff format) for
reference -- hopefully it's relatively clear how to read it. I've never
used Shell.pm, but I do know perl. With the exception of the first
patch (Shell.pm, line 127), which I don't understand, these all seem
fairly reasonable (I've included my notes below the patch line numbers)
~/perl/imap/IMAP/Shell.pm git/perl/imap/IMAP/Shell.pm
-
@@ -127,7 +127,7 @@
I'm not sure what this one does..
@@ -439,7 +439,7 @@
Most people/distros don't seem to use /usr/local much any more, which
lsb reserves for machine-local files (don't know about BSD or Solaris,
which probably uses /opt). The patch + location (/etc/cyradmrc.pl) is
not so great, either. Maybe this file should go here:
/etc/cyrus/cyradmrc.pl? Seems like any hardwired rc file location is
probably a bad idea.
@@ -472,7 +472,7 @@
check to see if $mech is defined for a better error message when not.
@@ -1437,7 +1437,7 @@
@@ -1446,7 +1446,7 @@
these are related to the first patch on Line 127
~/perl/sieve/scripts/sieveshell.pl
-
(there should probably be a separate patch file for each file being
patched, especially when there are only 2 and they live in different
trees; I'll fix this when the patches get updated)
@@ -61,7 +61,9 @@
@@ -69,7 +71,9 @@
@@ -84,20 +88,24 @@
@@ -122,6 +130,8 @@
All these patches deal with adding the ability to pass a password and/or
execution file on the command line
@@ -172,6 +182,8 @@
@@ -198,6 +210,9 @@
@@ -207,6 +222,9 @@
...
@@ -256,25 +283,32 @@
These set and use a local exitcode variable for clearer/cleaner exit
code handling.
@@ -284,7 +318,8 @@
etc
update perldoc strings to reflect adding command line password and
execution file options.
#! /bin/sh /usr/share/dpatch/dpatch-run
## 65-sieveshell-enhancements.dpatch by Sven Mueller deb...@incase.de
## Hacked up to 2.3.13 by Duncan Gibb duncan.g...@siriusit.co.uk
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Adds some enhancements to sieveshell and fixes some paths.
@DPATCH@
diff -urNad git~/perl/imap/IMAP/Shell.pm git/perl/imap/IMAP/Shell.pm
--- git~/perl/imap/IMAP/Shell.pm2010-01-16 19:21:09.0 -0200
+++ git/perl/imap/IMAP/Shell.pm 2010-01-16 19:34:33.976091619 -0200
@@ -127,7 +127,7 @@
[\_sc_info, '[mailbox]',
'display mailbox/server metadata'],
mboxcfg =
- [\_sc_mboxcfg, 'mailbox
[comment|condstore|expire|news2mail|sharedseen|sieve|squat] value',
+ [\_sc_mboxcfg, 'mailbox
[comment|condstore|expire|news2mail|sharedseen|sieve|squat|/explicit
annotation] value',
'configure mailbox'],
mboxconfig = 'mboxcfg',
reconstruct =
@@ -439,7 +439,7 @@
sub shell {
my ($server, $port, $authz, $auth, $systemrc, $userrc, $dorc, $mech, $pw,
$tlskey, $notls) =
-('', 143, undef, $ENV{USER} || $ENV{LOGNAME}, '/usr/local/etc/cyradmrc.pl',
+('', 143, undef, $ENV{USER} || $ENV{LOGNAME}, '/etc/cyradmrc.pl',
$ENV{HOME}/.cyradmrc.pl, 1, undef, undef, undef, undef);
GetOptions('user|u=s' = \$auth,
'authz|z=s' = \$authz,
@@ -472,7 +472,7 @@
$cyradm-authenticate(-authz = $authz, -user = $auth,
-mechanism = $mech, -password = $pw,
-tlskey = $tlskey, -notls = $notls)
- or die cyradm: cannot authenticate to server with $mech as $auth\n;
+ or die cyradm: cannot authenticate to server . (defined($mech)? with
$mech:) . as $auth\n;
}
my $fstk = [*STDIN, *STDOUT, *STDERR];
if ($dorc $systemrc ne '' -f $systemrc) {
@@ -1437,7 +1437,7 @@
while (defined ($opt = shift(@argv))) {
last if $opt eq '--';
if ($opt =~ /^-/) {
- die usage: mboxconfig mailbox
[comment|condstore|expire|news2mail|sharedseen|sieve|squat] value\n;
+ die usage: mboxconfig mailbox
[comment|condstore|expire|news2mail|sharedseen|sieve|squat|/explicit
annotation] value\n;
}
else {
push(@nargv, $opt);
@@ -1446,7 +1446,7 @@
}
push(@nargv, @argv);
if (@nargv 2) {
-die usage: mboxconfig mailbox
[comment|condstore|expire|news2mail|sharedseen|sieve|squat] value\n;
+die usage: mboxconfig mailbox
[comment|condstore|expire|news2mail|sharedseen|sieve|squat|/explicit
annotation] value\n;
}
if (!$cyrref || !$$cyrref) {
die mboxconfig: no connection to server\n;
diff -urNad git~/perl/sieve/scripts/sieveshell.pl
git/perl/sieve/scripts/sieveshell.pl
--- git~/perl/sieve/scripts/sieveshell.pl 2010-01-16 19:34:33.822091652
-0200
+++ git/perl/sieve/scripts/sieveshell.pl2010-01-16 19:34:33.976091619
-0200
@@ -61,7 +61,9 @@
my $username = $ENV{USER};
my $authname = $ENV{USER};
my $realm = ;
+my $password;
my $ex = ;
+my $exfile = ;
my $help = 0;
my $man = 0;
my $ret;
@@ -69,7
Re: debian patches to Shell.pm and sieveshell.pl
Michael Loftis wrote: Just documents the ability to set an (arbitrary) annotation with a specific value on a mailbox. That totally lost me -- any documentation available to look at? Or where in the code is this functionality realized?
