Re: Subscriptions and sieve filters lost after upgrade to Cyrus 3.0
Hi, This was an lmtpd bug in earlier versions of 3.0. It was fixed in 3.0.6, and this was noted in the release notes: https://www.cyrusimap.org/imap/download/release-notes/3.0/x/3.0.6.html: > Fixed Issue #2303: lmtpd(8) now looks for sieve scripts in the same > directories as the rest of cyrus (including timsieved(8)). > Please note that if you had manually installed sieve scripts to the > directories lmtpd used to look in, these will need to be moved. It sounds like your setup was taking the bug into account (using the '^' paths that lmtpd expected), and since lmtpd has been fixed to use dots, you're now seeing the reverse of the problem. You should be able to rename the name^with^dots paths to name.with.dots and things will work normally for you. This behaviour will probably change again in a future major release, but when it does so it will do so correctly, and with upgrade path documentation! The ^ notation is what _should_ be used, eventually, but the implementation that slipped into 3.0 was incomplete and incorrect, and the fix was to back it out and restore the older behaviour. Sorry about the inconvenience, ellie On Thu, Jul 19, 2018, at 12:57 AM, Martin Svec wrote: > Hello, > > after upgrade from Cyrus 2.5.7 to 3.0.6, we noticed that some users lost > their IMAP subscriptions > and all sieve filters. After some investigation, we've found that this > happens if the user's name > contains dot(s). For sieve directories and .sub files, version 2.5.x > uses names with dots replaced > with "^". But 3.0.x series expects the names with dots. > > Note that we've altnamespace and unixhierarchysep turned _on_ in both > versions, so no namespace > transformations should be needed. > > Names in 2.5.x: > /var/imap/sieve/domain/s/somedomain.com/n/name^with^dots/defaultbc > /var/imap/domain/s/somedomain.com/user/n/name^with^dots.sub > > Names in 3.0.x: > /var/imap/sieve/domain/s/somedomain.com/n/name.with.dots/defaultbc > /var/imap/domain/s/somedomain.com/user/n/name.with.dots.sub > > Surprisingly, other metadata files like .lock files and quota files > still use the format with "^" > characters. > > I've found no information regarding this incompatible change in 3.0 > upgrade documentation. Is this > an expected behavior or a bug? > > Best regards > > Martin Svec > > > 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: [SOLVED] Cyrus IMAP-3.0.7 - listmailbox user/* does not report all mailboxes
On Thu, Jul 19, 2018, at 12:27 AM, James B. Byrne via Info-cyrus wrote: > > On Mon, July 16, 2018 22:23, ellie timoney wrote: > > Starting with the obvious, but did the user you login to cyradm as > > have admin privileges? Are they listed in "admins:" in your > > imapd.conf? > > > > If you logged into cyradm as a regular user, you would only see > > mailboxes that your user had been granted access to... ;) > > > > I was logged on as the cyrus administrator via sudo. However, I > discovered that the problem does not really exist. What happened is > that the terminal manager I was using (tmux) was helpfully only > showing the first few lines returned and the last few, leaving out the > vast majority of the report. > > I had run into tmux's extraordinary behaviour previously with output > from the cat utility. But I was not expecting it to be encountered in > this case. > > Anyway, everything WRT IMAP is as it should be and my heart rate has > returned to its normally elevated state. > Yikes, I can see how that would cause palpitations, glad it's sorted! 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 single to multi-domain. Mailboxes from default domain not being the same as before
Em 16/07/2018 22:55, ellie timoney escreveu: Or do you want accounts in different domains to be not related to each other? (e.g. "a...@foo.com" and "a...@bar.com" are two totally different accounts) In either case, I would think about having one LDAP attribute (single-value, unique) to represent a user's "primary" email address, and a separate LDAP attribute (multi-value, unique) to represent their "aliases". You would set up Cyrus to only consider the "primary" attribute, and then set up your SMTP server to deliver email destined for "alias" addresses to the "primary" address for the matching account. I believe this is a common enough configuration that it shouldn't be hard to find information online. I have managed (non-Cyrus) systems that worked like this in the past, but it was a long time ago so I can't offer much specific help. humm. so the existing "mail" field on ldap would always contain the @defaultdomain (as setup on cyrus), but another field for aliases where Postfix would look up?! The "mail" attribute wouldn't need to always contain the @defaultdomain, but it would always need to match the account that Cyrus knows about. And then the aliases attribute (I've seen "mailalternateaddress" used for this) would contain any other addresses that need to deliver to the same account. Right now Cyrus is using mailboxes without any domain.. just a plain "/var/spool/cyrus/mail/h/user/heiler^bemerguy".. defaultdomain is just for telling Cyrus what to assume when no domain is specified, none of your accounts need to actually use it, and in fact this domain doesn't even need to exist (unless accounts use it). At FastMail, I believe our defaultdomain is set to some nonsense value like "internal" or "invalid" or something, which none of our accounts use, and the side effect of this is that every account must always have a (real) domain explicitly specified. I'd recommend doing something similar, just to avoid confusion from Cyrus making assumptions. Basically what I'm saying here is, if you: * set it up in LDAP so that each account has exactly one "mail" attribute which matches their Cyrus account, and as many aliases as they need, and I think this will be the problem. Our ldap's "mail" attribute is mixed with @cinbesa.com.br or @belem.pa.gov.br.. but as our saslauth ldap_filter uses UID instead of MAIL for searching accounts they all use the same mailbox! If I change that to use the "mail" attribute instead, and the "mail" attribute is @defaultdomain, it will work, but if it's not, it will create another mailbox.. I don't know how can I write a ldap_filter to return only uid in that case. Or should I rewrite all users' "mail" attribute that are using domain aliases? * set up Postfix to handle the alias rewriting on delivery, and * set up Cyrus to look up the "mail" attribute (only) for authentication (as you have already done), and if necessary, instruct your users to use their full "mail" address as their login name then: * your defaultdomain doesn't really matter, because everything in Cyrus will use the full "mail" address, and * Cyrus won't autocreate multiple inboxes for people, because it never sees their aliases If you provide a webmail interface to your users, it will also need to know about their LDAP attributes so that they can send mail "from" an alias if they need to. But if your users just use IMAP, they can just be set up in the client. We use a roundcube Webmail, which uses smtp to send emails.. As for autocreate, it is not compiled in by default, it needs to be turned on at build time with the --enable-autocreate argument to configure. If you installed Cyrus from a distribution, your distribution may have done this for you. If you don't want to recompile to remove the feature, you can control it using the autocreate_* options in imapd.conf (see man
Subscriptions and sieve filters lost after upgrade to Cyrus 3.0
Hello, after upgrade from Cyrus 2.5.7 to 3.0.6, we noticed that some users lost their IMAP subscriptions and all sieve filters. After some investigation, we've found that this happens if the user's name contains dot(s). For sieve directories and .sub files, version 2.5.x uses names with dots replaced with "^". But 3.0.x series expects the names with dots. Note that we've altnamespace and unixhierarchysep turned _on_ in both versions, so no namespace transformations should be needed. Names in 2.5.x: /var/imap/sieve/domain/s/somedomain.com/n/name^with^dots/defaultbc /var/imap/domain/s/somedomain.com/user/n/name^with^dots.sub Names in 3.0.x: /var/imap/sieve/domain/s/somedomain.com/n/name.with.dots/defaultbc /var/imap/domain/s/somedomain.com/user/n/name.with.dots.sub Surprisingly, other metadata files like .lock files and quota files still use the format with "^" characters. I've found no information regarding this incompatible change in 3.0 upgrade documentation. Is this an expected behavior or a bug? Best regards Martin Svec 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
Invalid user returned from quota -f command
Hi, many users have been complaining about their quota usage being displayed wrongly. When trying to solve that using QUOTA -F, the command returned a System I/O Error due to the nonexistence of some invalid mailboxes that are not even listed under CTL_MBOXLIST -D, such as: '' (empty string) and DELETED.user.teste3cyrus.5A902111EFJulho 2017.5B2E7DCF4DE7725F3314. Here is the full output of the command: > failed opening header for mailbox > 'domain.com!DELETED.user.teste3cyrus.5A902111EFJulho > 2017.5B2E7DCF4DE7725F3314': System I/O error: No such file or directory > processing mbox list for '': System I/O error: No such file or directory Can anyone that has ever faced something like this help me? -- Hiago Prata Graduando em Engenharia da Computação DataCenter da UFPA - CTIC Faculdade de Engenharia da Computação e Telecomunicações - ITEC Universidade Federal do Pará 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
[SOLVED] Cyrus IMAP-3.0.7 - listmailbox user/* does not report all mailboxes
On Mon, July 16, 2018 22:23, ellie timoney wrote: > Starting with the obvious, but did the user you login to cyradm as > have admin privileges? Are they listed in "admins:" in your > imapd.conf? > > If you logged into cyradm as a regular user, you would only see > mailboxes that your user had been granted access to... ;) > I was logged on as the cyrus administrator via sudo. However, I discovered that the problem does not really exist. What happened is that the terminal manager I was using (tmux) was helpfully only showing the first few lines returned and the last few, leaving out the vast majority of the report. I had run into tmux's extraordinary behaviour previously with output from the cat utility. But I was not expecting it to be encountered in this case. Anyway, everything WRT IMAP is as it should be and my heart rate has returned to its normally elevated state. -- *** 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: Help! Cyrus 2.5.11 segmentation fault
Hi, Quoting Marco Chesi : Hello, we have a Cyrus 2.5.11 on Debian 7 using murder (2 frontends, 3 backends, 1 mupdate, about 5000 mailboxes) in production environment, hosted by a VMware cluster 6.5. Suddenly, ALL mailboxes have becomed inaccessible. In the log, we found many messages like this: master[5965]: process type:SERVICE name:imaps path:/usr/cyrus/bin/proxyd age:82.255s pid:5987 signaled to death by signal 11 (Segmentation fault) I tried many times to restart the cyrus service on all servers without success. Users are authenticated correctly, error occurs when they try to access the mailbox (trying with a manual connection using telnet, client dies on a "SELECT INBOX" command after a successfull login) This is the output of one core dump: Core was generated by `proxyd -s'. Program terminated with signal 11, Segmentation fault. #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:32 32 ../sysdeps/x86_64/multiarch/../strlen.S: File o directory non esistente. (gdb) bt #0 __strlen_sse2 () at ../sysdeps/x86_64/multiarch/../strlen.S:32 #1 0x7f58caffa656 in xstrdup (str=0x0) at lib/xmalloc.c:95 #2 0x7f58cb574b93 in parse_capability (s=s@entry=0x2223580, str=) at imap/backend.c:282 #3 0x7f58cb576362 in parse_capability (str=, s=0x2223580) at imap/backend.c:279 #4 backend_login (noauth=6486368, auth_status=0x0, cb=0x2233b20, userid=0x2235360 "", ret=0x2223580) at imap/backend.c:833 #5 backend_connect (ret_backend=ret_backend@entry=0x0, server=0xc , server@entry=0x2233d90 "imap2", prot=0x7ffccb275a40, prot@entry=0x62f840, userid=userid@entry=0x2235360 "", cb=0x2233b20, cb@entry=0x0, auth_status=auth_status@entry=0x0, logfd=logfd@entry=-1) at imap/backend.c:1027 #6 0x00425915 in proxy_findserver (server=0x2233d90 "imap2", prot=prot@entry=0x62f840, userid=0x2235360 "", cache=0x62fb70, current=0x62fb78, inbox=0x62fb80, clientin=0x21ed470) at imap/proxy.c:173 #7 0x00417a0d in proxy_findinboxserver (userid=out>) at imap/imap_proxy.c:129 #8 0x00412f63 in cmd_list (tag=0x221ad00 "6", listargs=listargs@entry=0x7ffccb276a60) at imap/imapd.c:6728 #9 0x00420afc in cmdloop () at imap/imapd.c:1638 #10 0x00424f4e in service_main (argc=, argv=, envp=envp@entry=0x7ffccb27a9e0) at imap/imapd.c:984 #11 0x00416962 in main (argc=, argv=, envp=0x7ffccb27a9e0) at master/service.c:606 (gdb) Any suggestions or support? As far as i can tell is that the frontend imapd-proxy process is receiving the SIGSEGV after it connected and authenticate to the backend. The imapd-proxy is parsing the the capability output of the backend. What is strange is that the parse_cpability is called with a NULL pointer (str=0x0) which is then used in xstrdup. So a check to ensure that str != NULL would help to prevent the SIGSEGV, but a am not sure what should be done in the str == NULL case. The other question is why is str == NULL in the first place? Can you try to manual connect to the backend using telnet, and check the CAPABILITY output. And as always the frustrating question: Did something change on your backends? Regards, Michael Menge M.MengeTel.: (49) 7071/29-70316 Universität Tübingen Fax.: (49) 7071/29-5912 Zentrum für Datenverarbeitung mail: michael.me...@zdv.uni-tuebingen.de Wächterstraße 76 72074 Tübingen Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
