Re: setting acl on autocreate folders
> Something like: autocreate_acl (multiple > autocreate_acl entries could be specified) That's roughly what I'd expect such a feature to look like (without having thought about it in much depth). It seems like it would be very useful for admins who don't already have their own provisioning infrastructure. > Ellie, do you think this is something of low complexity? In my opinion, any new feature for ACL's is inherently high complexity -- even if it's just a two line patch -- just because of the amount of work involved in checking for side effects, error handling, and making sure the documentation is up to scratch (so that people don't accidentally configure it wrong and get into trouble). That said, the code for reading config settings already exists, as does the code for parsing and applying ACL's. So in theory it should be a "simple" matter of bolting these bits together in the right place(s). I'd be happy to review/advise on a pull request along these lines! Cheers, ellie On Sat, May 12, 2018, at 7:40 AM, Anatoli wrote: > > I think it's good that you have to explicitly set "anyone p", > > because otherwise people would be able to send plus+adressed mails > > to any mailbox whose name they can guess.> > As the default behavior, I agree. > > I've just made a couple of tests: remove "anyone p" then add "postman > p" or add postman as "admins: postman" but none of these worked for > plus+addressing (P+A), so the *postman* user appears to be some > hardcoded way of dealing with LMTP delivery and has nothing in common > with the normal users and operations.> > If my assumptions are correct, I guess what Chen (OP) was asking > would be useful, i.e. to be able to define "anyone p" (either as a > toggle aimed at P+A or as a free-form for any user/ACL) for some auto- > created folders along the other auto-configuration features > (autocreate_XXX, x-list, etc.). The idea is to be able to setup most > common settings for new users without any external scripts talking to > cyradm or imtest. In my case the "anyone p" permission is the only > thing pending.> > Something like: autocreate_acl (multiple > autocreate_acl entries could be specified)> > Ellie, do you think this is something of low complexity? > > *From:* Sebastian Hagedorn > *Sent:* Friday, May 11, 2018 04:36 > *To:* Anatoli > *Cc:* Info-cyrus > *Subject:* Re: setting acl on autocreate folders > > >> So what I'm observing in practice is that the "-a" option is >> not enough>> to deliver plus+addressed mails without the "anyone p" ACL >> permission in>> the folder, which makes me think that the user for "-a" >> option >> is not>> from the admins group, though it probably should be, right? I.e. >> lmtpd -a>> should be delivering plus+addressed mails without the "anyone >> p" ACL>> permission? > > I think it's good that you have to explicitly set "anyone p", because > otherwise people would be able to send plus-adressed mails to any > mailbox whose name they can guess.> -- > Sebastian Hagedorn - Weyertal 121, Zimmer 2.02 > Regionales Rechenzentrum (RRZK) > Universität zu Köln / Cologne University - Tel. +49-221-470-89578 > 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: Virtual domain admin login behaviour
On 2018/04/30 12:22 PM, Dan White wrote: > On 04/30/18 12:00 -0600, Nels Lindquist wrote: >> I have a mail server still running an older version of Cyrus IMAPD >> (version 2.3.16) on CentOS 6 with virtual domains, using OpenLDAP as >> an authentication backend with saslauthd for LOGIN/PLAIN when SSL/TLS >> is used. >> >> I recently set up a domain admin account for one of the virtual >> domains in order to facilitate transfer of mail from that domain to a >> different mail host, and while I was testing the setup I noticed some >> inconsistent behaviour. >> >> Using "imtest -m PLAIN -u u...@example.ca -a ad...@example.ca >> mail.example.ca", I'm successfully able to login. >> >> Executing ". list *.*" produces the expected list of u...@example.ca's >> INBOX and subfolders. >> >> Using "imtest -u u...@example.ca -a ad...@example.ca" (Note: no >> mechanism override) it defaults to using the LOGIN method rather than >> PLAIN, and I'm successfully able to log in. >> >> However, the ". list *.*" command now produces a list of every folder >> in the example.ca subdomain, not just the specified user's mailbox. >> >> Anyone know what's going on here? > > The LOGIN mech does not support proxy authentication: > > https://www.sendmail.org/~ca/email/cyrus2/mechanisms.html Ah, that makes perfect sense. Thanks! Nels Lindquist 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
how can I check (and change) the owner of a mailbox ?
Hi, How can I check who the mailbox owner is ? How can I change it ? I'd like to change owner john.doe to john@example.net Here's why : I'm currently testing the migration of a single-domain Cyrus IMAP server to a multi-domain one. I'm doing the migration on the filesystem level, copying files from the old to the new server. It works fine, except for the mailbox owner, it seems to be the old one, without the e-mail domain. Here is what I did : - 1/ First I created user/john.doe on domain example.net on the new server, using autocreate (so it created /var/spool/cyrus/mail/domain/e/example.net/j/user/john.doe) - 2/ The I checked this mailbox's ACLs : $ cyradm --user cy...@example.net localhost localhost> lam user/john.doe user/john.doe: john@example.net lrswipkxtecdan - 3/ Then I stopped cyrus - 4/ Then I copied /var/spool/cyrus/mail/j/john.doe/* from the old (single domain) server to /var/spool/cyrus/mail/domain/e/example.net/j/user/john.doe on the new (multi-domain) server - 5/ Then a little reconstruct : su -c "/usr/lib/cyrus/bin/reconstruct -r -f user/john@example.net" cyrus -s /bin/bash - 6/ Starting cyrus - 7/ Checking ACLs : $ cyradm --user cy...@example.net localhost Password: localhost> lam user/john.doe user/john.doe: john.doe lrswipkxtecda - 8/ OK, so now john.doe (and not john@example.net like before) seems to be the owner of user/john.doe - 9/ When I try to log in (with my webmail for example), it doesn't work. From the logfiles : May 14 21:40:04 sogod [1596]: [ERROR] <0x0x5648006b5480[NGImap4Connection]> could not select URL: imaps://john.doe%40example.net@mail/INBOX/: {RawResponse = "{ResponseResult = {description = \"Mailbox does not exist\"; result = no; tagId = 6; }; }"; reason = "Mailbox does not exist"; result = 0; } - 10/ Back to cyradm, and granting full rights to john@example.net : $ cyradm --user cy...@example.net localhost Password: localhost> sam user/john.doe* john@example.net lrswipkxtecdan - 11/ OK, after that webmail works fine. - 12/ Back to cyradm, where my ACLs now look like : $ cyradm --user cy...@example.net localhost Password: localhost> lam user/john.doe user/john.doe: john.doe lrswipkxtecda john@example.net lrswipkxtecdan So, I though I don't need the john.doe ACL anymore, and tried to remove it : localhost> dam user/john.doe john.doe But I still have "lkxca" ACLs, which are the owner's implicit ACLs : localhost> lam user/john.doe john@example.net lrswipkxtecdan john.doe lkxca So I guess after the migration the owner of the mailbox is john.doe, and not john@example.net like before the migration. How can I change this ? How can I get rid of john.doe's ACLs ? Thanks, Chen 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: Sieve stopped working after updating cyrus-imapd to 3.0.5
Hello, just for information, the update to version 3.0.6 did not fix the problem for me, I'm still having the same issue. I had to apply my workaround (create symbolic links) to make it work again. Regards, Ralf Am 02.03.2018 um 20:11 schrieb rfk: Hi Ken, my distribution is Gentoo and my previous cyrus version was 2.5.10. Then I upgraded to 3.0.4 but this ebuild (though marked stable by the Gentoo devs) was terminating "abnormally" all the time. Finally I upgraded to 3.0.5 which is running fine until now - well, except for sieve. Regards, Ralf Am 02.03.2018 um 16:50 schrieb Ken Murchison: I've done some investigating this morning and it appears that you are correct in that lmtpd and timsieved differ in how they handle the hierarchy separator. But I'm not sure just yet when this split happened. Did you upgrade from 3.0.4 or from 2.x? On 03/01/2018 03:36 PM, rfk wrote: Hey Sebastian, thanks a lot for your feedback, seems like we're coming closer. Although I'm not sure what port 24 is supposed to be in your swaks command I just sent myself an e-mail while strace was attached to cyrusmaster. The log revealed the following: readlink("/var/imap/sieve/u/user^domain^de/defaultbc", 0x7fff7fa31d00, 4096) = -1 ENOENT (No such file or directory) Then I recognized that the users in /var/imap/sieve/ are actually separated by a dot ('.') instead of a caret ('^') as opposed to /var/spool/imap/ where the users are separated by a caret. After manually renaming the sieve directory of my user to the caret notation the filtering was finally working. However Roundcube then tells me that no filters are available. Once I used Roundcube (or sieveshell) my sieve user directory is existing twice, once empty in dot notation and once with the filters in caret notation. My conclusion: 1. lmtpd (?) is using the caret notation when looking up sieve scripts. 2. timsieved (?) is using the dot notation when creating sieve scripts. Which configuration parameters affect this behaviour? Regards, Ralf Am 01.03.2018 um 13:52 schrieb Sebastian Hagedorn: Not really. My best suggestion would be to strace the lmtp process to see if the sieve scripts are even found and opened. On a test system I did it like this: strace -f -ff -o /tmp/lmtptrace -p It might be better to prefork an lmtpd and to specifically strace that pid, but in my case it didn't matter. Then I ran swaks: swaks --protocol lmtp -t name-of-a-user-with-sieve -s localhost -p 24 In the resulting files I could see the script being accessed: lmtptrace.43344:open("/lib64/libcyrus_sieve.so.0", O_RDONLY|O_CLOEXEC) = 5 lmtptrace.43344:readlink("/var/lib/imap/sieve/E/xxx/defaultbc", "smartsieve.bc", 4096) = 13 lmtptrace.43344:open("/var/lib/imap/sieve/E/xxx/smartsieve.script", O_RDWR) = 12 lmtptrace.43344:stat("/var/lib/imap/sieve/E/xxx/smartsieve.bc", {st_mode=S_IFREG|0600, st_size=604, ...}) = 0 lmtptrace.43344:stat("/var/lib/imap/sieve/E/xxx/smartsieve.bc", {st_mode=S_IFREG|0600, st_size=604, ...}) = 0 lmtptrace.43344:open("/var/lib/imap/sieve/E/xxx/smartsieve.bc", O_RDONLY) = 13 lmtptrace.43344:stat("/var/lib/imap/sieve/E/xxx/defaultbc", {st_mode=S_IFREG|0600, st_size=604, ...}) = 0 lmtptrace.43344:open("/var/lib/imap/sieve/E/xxx/defaultbc", O_RDONLY) = 12 Maybe try that and report back what happens on your system. --On 28. Februar 2018 um 19:18:55 +0100 rfk wrote: Hello, still no other ideas? Ralf Am 15.02.2018 um 19:37 schrieb rfk: Hi, I'm so sorry, don't know how this could happen, but the last line of my configuration was lost during copy and paste: altnamespace: 0 So it is already disabled. Ralf Am 15.02.2018 um 19:32 schrieb Michael Menge: Hi, Quoting rfk : Hi, thanks for your feedback. Unfortunately sievec reports nothing: # grep -v ^# roundcube.script require ["imapflags","fileinto"]; if anyof (header :contains "Subject" "test") { setflag "\\Seen"; fileinto "INBOX/Trash"; stop; } # sievec roundcube.script test # Here's my configuration in case it helps: # grep -vE "^#|^$" /etc/imapd.conf admins: cyrus configdirectory: /var/imap proc_path: /run/cyrus/proc mboxname_lockpath: /run/cyrus/lock duplicate_db_path: /run/cyrus/deliver.db ptscache_db_path: /run/cyrus/ptscache.db statuscache_db_path: /run/cyrus/statuscache.db tls_sessions_db_path: /run/cyrus/tls_sessions.db defaultpartition: default partition-default: /var/spool/imap sievedir: /var/imap/sieve lmtpsocket: /var/imap/socket/lmtp idlesocket: /var/imap/socket/idle notifysocket: /var/imap/socket/notify syslog_prefix: cyrus httpmodules: caldav carddav hashimapspool: true virtdomains: no defaultdomain: localhost popminpoll: 1 allowplaintext: yes sasl_pwcheck_method: saslauthd sasl_mech_list: PLAIN LOGIN sasl_auto_transition: no sieve_extensions: fileinto reject vacation imapflags notify include envelope body relational regex subaddress copy tls_session_timeout: 1440 tls_client_ca_file: /.../ca_file.pem
Re: Moving from cIMAP-2.3.16 to 3.0.5
On Mon, May 14, 2018 10:18, Savvas Karagiannidis wrote: > Hi James, > note that you will probably fall into this bug on the new system: > https://github.com/cyrusimap/cyrus-imapd/issues/2208 > Try running "reconstruct -G -V max" on the new system before switching > to > it. This will upgrade the mailboxes avoiding the issue. > Thank you very much for the heads-up. I have had so many niggling issues respecting this conversion that one more would have a traumatic effect on me far beyond its material implications. Regards. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 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: Moving from cIMAP-2.3.16 to 3.0.5
Hi James, note that you will probably fall into this bug on the new system: https://github.com/cyrusimap/cyrus-imapd/issues/2208 Try running "reconstruct -G -V max" on the new system before switching to it. This will upgrade the mailboxes avoiding the issue. Regards, Savvas Karagiannidis On Mon, May 14, 2018 at 4:15 PM James B. Byrne via Info-cyrus < info-cyrus@lists.andrew.cmu.edu> wrote: > > On Sat, May 12, 2018 19:47, Nic Bernstein wrote: > > James, > > Patrick is entirely correct. As explained in the man page for > > ctl_mboxlist(8) the "-f" flag is to specify an alternative input file > > (mailbox database) not an output file. Output is via standard out, > > and > > can redirected into the file of your choice, or piped to the new host, > > like so: > > > > Thank you both. I will try this approach and report if I somehow > manage to get it wrong again. > > Regards, > > -- > *** e-Mail is NOT a SECURE channel *** > Do NOT transmit sensitive data via e-Mail > Do NOT open attachments nor follow links sent by e-Mail > > James B. Byrnemailto:byrn...@harte-lyne.ca > Harte & Lyne Limited http://www.harte-lyne.ca > 9 Brockley Drive vox: +1 905 561 1241 <(905)%20561-1241> > Hamilton, Ontario fax: +1 905 561 0757 <(905)%20561-0757> > Canada L8E 3C3 > > > Cyrus Home Page: http://www.cyrusimap.org/ > List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ > To Unsubscribe: > https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus > Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: Moving from cIMAP-2.3.16 to 3.0.5
On Sat, May 12, 2018 19:47, Nic Bernstein wrote: > James, > Patrick is entirely correct. As explained in the man page for > ctl_mboxlist(8) the "-f" flag is to specify an alternative input file > (mailbox database) not an output file. Output is via standard out, > and > can redirected into the file of your choice, or piped to the new host, > like so: > Thank you both. I will try this approach and report if I somehow manage to get it wrong again. Regards, -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 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: Xapian/Cyrus/Thunderbird
On Fri, May 11, 2018, at 14:25, Sebastian Hagedorn wrote: --On 11. Mai 2018 um 13:32:29 +0200 Robert Stepanek wrote: > For non-FUZZY text SEARCH, Cyrus attempts to match the string on its > own [1]. That sounds strange to me, because Cyrus 2.4 and earlier don't support FUZZY, and there the SQUAT index was used, if present. Only messages that were added after the last squatter run were searched directly. Why would that have changed? Right, it hasn't. SQUAT is still the backend for non-FUZZY text search. But search_engine is either squat or xapian. That would mean that one would have to run squatter with two separate configurations in order to cover both search types. That's at the very least counterintuitive ... Should I open a Github issue for that topic? I see more than one approach to solve that. I think if Xapian only does fuzzy, some searches may be *slower* than using a SQUAT index. That seems counterintuitive, at the least. Do you have internal search benchmarks? Without metrics it's hard to say if any of this actually matters ... I don't know of any benchmarks for this. It hasn't popped up as a performance issue. I thought Xapian was added to improve all IMAP BODY searches, but I guess the only reason was to enable IMAP FUZZY searches. In my opinion this needs to be stated explicitly in the documentation, if that's the way it will be going forward. Cheers Sebastian -- Sebastian Hagedorn - Weyertal 121, Zimmer 2.02 Regionales Rechenzentrum (RRZK) Universität zu Köln / Cologne University - Tel. +49-221-470-89578 pgp8MhgaSkgjC.pgp Description: PGP signature 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: Xapian/Cyrus/Thunderbird
On Fri, May 11, 2018, at 14:25, Sebastian Hagedorn wrote: > --On 11. Mai 2018 um 13:32:29 +0200 Robert Stepanek > wrote: > > For non-FUZZY text SEARCH, Cyrus attempts to match the string on its own > > [1]. > > That sounds strange to me, because Cyrus 2.4 and earlier don't support > FUZZY, and there the SQUAT index was used, if present. Only messages that > were added after the last squatter run were searched directly. Why would > that have changed? Right, it hasn't. SQUAT is still the backend for non-FUZZY text search. > I think if Xapian only does fuzzy, some searches may be *slower* than using > a SQUAT index. That seems counterintuitive, at the least. Do you have > internal search benchmarks? Without metrics it's hard to say if any of this > actually matters ... I don't know of any benchmarks for this. It hasn't popped up as a performance issue. Cheers, Robert 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