Re: setting acl on autocreate folders

[ellie timoney]

> 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

[Nels Lindquist]

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 ?

[Chentao Credungtao via Info-cyrus]

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

[rfk]

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: 

Re: Moving from cIMAP-2.3.16 to 3.0.5

[James B. Byrne via Info-cyrus]

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

[Savvas Karagiannidis]

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

[James B. Byrne via Info-cyrus]

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

[Sebastian Hagedorn]

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

[Robert Stepanek]

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