Re: Cyrus IMAP-3.0.7 - listmailbox user/* does not report all mailboxes
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... ;) On Tue, Jul 17, 2018, at 2:09 AM, James B. Byrne via Info-cyrus wrote: > I We recently moved our imap service from CentOS and IMAP-2.11 to > FreeBSD and IMAP 3.0.7. At the time we followed the upgrade path and > at the same time updated our mailboxes to the latest version: > > sudo -u cyrus /usr/local/cyrus/sbin/reconstruct -f -r -G -V max user/* > # Reconstruct and upgrade the mailbox folders > > Since the conversion everything has been running fine and we have no > reported problems with mailbox administration, message receipt, or > anything else having to do with IMAP. > > However, this morning I had cause to check for the existence of a > particular mailbox folder. When I logged into cyradm and ran > 'listmmailbox' I only received listings for three of our users, none > of which showed the entire mailbox folder tree for any of those > reported. > > This anomaly gives me great concern. Are there any known issues with > cyrus-imapd that might cause this problem? Is it necessary to run > reconstruct on a regular basis? > > > -- > *** 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 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
On Tue, Jul 17, 2018, at 3:37 AM, Heiler Bemerguy wrote:
> Em 06/07/2018 00:10, ellie timoney escreveu:
>
>> Hi,
>>
>> The "defaultdomain" is the domain that's assumed by Cyrus for users
>> that are uid only. Any other domain needs to be explicitly specified
>> in the user (this applies to login, delivery, etc). So, if you have:>>
>> defaultdomain: foo.com
>>
>> then "user" and "u...@foo.com" are the same account (and can login
>> using either variation), but "u...@bar.com" is some other account and
>> can only login as "u...@bar.com".>>
>> It's not clear to me how you wish to use the extra domains. Do you
>> want your existing users to be able to send/receive from multiple
>> different domains? (e.g. user "anne" has both email addresses
>> "a...@foo.com", "a...@bar.com").>
> We used to have some domains that represented the same mailbox. Like
> @cinbesa.com.br being the same as @belem.pa.gov.br.. but now we want
> to create some other domains (while *maintaining* those we already
> had), which will point to totally different mailboxes, like
> @semad.belem.pa.gov.br and @sesma.belem.pa.gov.br :)>
>
>
>>
>> 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.
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* 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.
>
>
>>
>> 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
>> imapd.conf.5). For example you should be able to use
>> "autocreate_users" to limit it only to certain LDAP groups rather
>> than every valid login (if that is useful to you).>>
>> But if you set up your LDAP directory and Cyrus such that each user
>> only has a single "primary" email address that they can use in Cyrus,
>> and map delivery to aliases outside of Cyrus, then people won't be
>> able to login with the "wrong" alias, and therefore autocreate won't
>> accidentally make new accounts for them. :)>>
> Right now I think they can login with the "uid" only OR with the
> complete mail ("mail" field)>
If you still have your ldap_filter set to*
Re: Moving from single to multi-domain. Mailboxes from default domain not being the same as before
Em 06/07/2018 00:10, ellie timoney escreveu:
Hi,
The "defaultdomain" is the domain that's assumed by Cyrus for
users that are uid only. Any other domain needs to be
explicitly specified in the user (this applies to login,
delivery, etc). So, if you have:
defaultdomain: foo.com
then "user" and "u...@foo.com" are the same account
(and can login using either variation), but "u...@bar.com"
is some other account and can only login as "u...@bar.com".
It's not clear to me how you wish to use the extra domains.
Do you want your existing users to be able to send/receive from
multiple different domains? (e.g. user "anne" has both email
addresses "a...@foo.com",
"a...@bar.com").
We used to have some domains that represented the same mailbox. Like
@cinbesa.com.br being the same as @belem.pa.gov.br.. but now we want
to create some other domains (while *maintaining* those we already
had), which will point to totally different mailboxes, like
@semad.belem.pa.gov.br and @sesma.belem.pa.gov.br :)
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?!
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
imapd.conf.5). For example you should be able to use
"autocreate_users" to limit it only to certain LDAP groups
rather than every valid login (if that is useful to you).
But if you set up your LDAP directory and Cyrus such that
each user only has a single "primary" email address that they
can use in Cyrus, and map delivery to aliases outside of Cyrus,
then people won't be able to login with the "wrong" alias, and
therefore autocreate won't accidentally make new accounts for
them. :)
Right now I think they can login with the "uid" only OR with the
complete mail ("mail" field)
--
Atenciosamente,
Heiler Bensimon Bemerguy - CINBESA
Analista de Redes, Wi-Fi,
Virtualização e Serviços Internet
(55) 91 98151-4894
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Cyrus IMAP-3.0.7 - listmailbox user/* does not report all mailboxes
I We recently moved our imap service from CentOS and IMAP-2.11 to FreeBSD and IMAP 3.0.7. At the time we followed the upgrade path and at the same time updated our mailboxes to the latest version: sudo -u cyrus /usr/local/cyrus/sbin/reconstruct -f -r -G -V max user/* # Reconstruct and upgrade the mailbox folders Since the conversion everything has been running fine and we have no reported problems with mailbox administration, message receipt, or anything else having to do with IMAP. However, this morning I had cause to check for the existence of a particular mailbox folder. When I logged into cyradm and ran 'listmmailbox' I only received listings for three of our users, none of which showed the entire mailbox folder tree for any of those reported. This anomaly gives me great concern. Are there any known issues with cyrus-imapd that might cause this problem? Is it necessary to run reconstruct on a regular basis? -- *** 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
Help! Cyrus 2.5.11 segmentation fault
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=) 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=out>, envp=0x7ffccb27a9e0) at master/service.c:606 (gdb) Any suggestions or support? Greetings, Marco -- Marco Chesi Ufficio Esercizio e Tecnologie Area Organizzazione e Sistemi Informativi Università degli Studi di Siena 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
