Re: Self compiled Cyrus 2.4.16 does not talk to self compiled Cyrus SASL 2.1.25
On Tue, June 19, 2012 3:55 pm, Dan White wrote: On 06/19/12 11:17 +0200, Eric Luyten wrote: Folks, (hitting the same wall over and over again when upgrading) Cyrus SASL is working/looking in /var/state/saslauthd all right, but Cyrus 2.4 appears to be writing elsewhere, and we cannot find out where exactly. Have tried 'saslauthd_path' option in /etc/imapd.conf to no avail. I pretty much copied our Cyrus 2.3 configuration files over to the test environment. What does your sasl_* configuration look like in imapd.conf? Dan, Switching to the Blastwave-packaged Cyrus-SASL 2.1.25 and adding sasl_saslauthd_path: /var/opt/csw/saslauthd/mux to /etc/imapd.conf did the trick. Cyrus 2.4.16 and SASL 2.1.25 now happily communicating. Eric Luyten. Are you authenticating with an appropriate mechanism (either PLAIN or LOGIN)? On 06/19/12 13:34 +0200, Eric Luyten wrote: On Tue, June 19, 2012 12:05 pm, Adam Tauno Williams wrote: On Tue, 2012-06-19 at 11:17 +0200, Eric Luyten wrote: (hitting the same wall over and over again when upgrading) Cyrus SASL is working/looking in /var/state/saslauthd all right, but Cyrus 2.4 appears to be writing elsewhere, and we cannot find out where exactly. Are you sure it is loading your compiled libraries and not your distributions 'defacto' ones? [ldd /usr/lib/cyrus/bin/imapd - your should see a reference to your SASL libraries] mcs1dev# ldd /usr/local/sbin/saslauthd | fgrep sasl libsasl2.so.2 = /opt/csw/lib/libsasl2.so.2 mcs1dev# ldd /usr/cyrus/bin/imapd | fgrep sasl libsasl2.so.2 = /opt/csw/lib/libsasl2.so.2 mcs1dev# The location of the shared libraries for the saslauthd should not be important (unless you're using the sasldb or ldap backends), because it runs within its own process. If testsaslauthd is working then your saslauthd installation is likely ok. Try running testsaslauthd as your cyrus user to rule out any permissions problems. BTW - why are you self-compiling? Really good packages exist for lots of distributions. Solaris10/Intel. Have tried 'saslauthd_path' option in /etc/imapd.conf to no avail. So when you run testsaslauthd it works? Yes, it certainly does. Your saslauthd_path configuration should include the trailing '/mux'. I believe it should be identical to the '-f' option that you would pass to testsaslauthd. Try increasing your sasl logging to further troubleshoot. In imapd.conf: sasl_log_level: 7 And configure your syslog daemon to log 'auth.*'. -- Dan White 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: I/O error moving mailbox
Hi again!
Nobody have any idea about how to solve this problem?
I'm confused about the real state of the database and I have no idea
about how to solve this issue.
Does anybody have any idea about how to help me?
Than you very much in advance.
On 21/06/2012 12:50, Javier
Snchez-Arvalo Daz wrote:
On 21/06/2012 12:18, Adam Tauno
Williams wrote:
On Thu, 2012-06-21 at 11:57 +0200, Javier Snchez-Arvalo Daz wrote:
I'm experiencing some problems moving a mailbox from one partition
("default") to another ("part3").
I have already moved more than 19000 mailboxes from "default" to
"part3" but I don't know why I'm unable to move
"user.col1901"
If you tail your mail / messages log do you see any messages when you
try to move the mailbox?
Yes.
This is what I receive in /var/log/messages:
[...]
Jun 21 12:33:43 pcocol01 imap[19914]: DBERROR: error fetching
user.col1901: cyrusdb error
[...]
And this is the result of executing ctl_mboxlist for this
partition:
[...]
cyrus@pcocol01:~ ctl_mboxlist -d -p default
user.col1901 default col1901 lrswipcda
user.col1901.Drafts default col1901 lrswipcda
user.col1901.PosibleSPAM default col1901 lrsipd cyrus
lrswipcda
user.col1901.Sent default col1901 lrswipcda
user.col1901.Trash default col1901 lrswipcda
[...]
When I try to do It I receive the next error:
[...]
localhost renm user.col1901 user.col1901 part3
renamemailbox: System I/O error
[...]
I have checked permissions and even I have given 777 to this mailbox:
It probably isn't a good idea to mess with filesystem permissions. As
long as everything is owned by your cyrus user it should be just fine.
I agree. It was just for test purposes.
Thank you for your help Adam.
--
Javier Sanchez-Arevalo
Dpto. de Informatica
web:www.coam.es
mail:javier.sanc...@coam.org
Hortaleza 63
28004 Madrid
T. 915 951 536
Este correo electronico y, en su caso, cualquier fichero anexo
al mismo, contiene informacion de caracter confidencial
exclusivamente dirigida a su destinatario o destinatarios.
Queda prohibida su divulgacion, copia o distribucion a
terceros sin la previa autorizacion escrita del COLEGIO
OFICIAL DE ARQUITECTOS DE MADRID.
En el caso de haber recibido este correo electronico por
error, se ruega notifiquese inmediatamente esta circunstancia
mediante reenvio a la direccion electronica del remitente o al
telefono 915 951 500 1903
De conformidad con lo establecido en la L.O.P.D. 15/1999, EL
COLEGIO OFICIAL DE ARQUITECTOS DE MADRID garantiza la adopcion
de las medidas necesarias para asegurar el tratamiento
confidencial de los datos de caracter personal. Asi mismo le
informamos de la posibilidad de ejercer los derechos de
acceso, rectificacion, cancelacion y oposicion en la siguiente
direccion: Hortaleza 63. Madrid 28004
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
--
Javier Sanchez-Arevalo
Dpto. de Informatica
web:www.coam.es
mail:javier.sanc...@coam.org
Hortaleza 63
28004 Madrid
T. 915 951 536
Este correo electronico y, en su caso, cualquier fichero anexo
al mismo, contiene informacion de caracter confidencial
exclusivamente dirigida a su destinatario o destinatarios. Queda
prohibida su divulgacion, copia o distribucion a terceros sin la
previa autorizacion escrita del COLEGIO OFICIAL DE ARQUITECTOS
DE MADRID.
En el caso de haber recibido este correo electronico por error,
se ruega
Re: I/O error moving mailbox
On Mon, June 25, 2012 10:30 am, Javier Sánchez-Arévalo Díaz wrote: Hi again! Nobody have any idea about how to solve this problem? I'm confused about the real state of the database and I have no idea about how to solve this issue. Does anybody have any idea about how to help me? Javier, What is the output of : 'grep partition /etc/imapd.conf' 'mbpath user.col1901' and what happens if you 'cd' into the result of the second command and execute 'pwd' and 'ls' there ? Does 'chk_cyrus -M user.col1901' return something weird ? Regards, Eric Luyten, Computing Centre VUB/ULB. On 21/06/2012 12:50, Javier Sánchez-Arévalo Díaz wrote: On 21/06/2012 12:18, Adam Tauno Williams wrote: On Thu, 2012-06-21 at 11:57 +0200, Javier Sánchez-Arévalo Díaz wrote: I'm experiencing some problems moving a mailbox from one partition (default) to another (part3). I have already moved more than 19000 mailboxes from default to part3 but I don't know why I'm unable to move user.col1901 If you tail your mail / messages log do you see any messages when you try to move the mailbox? Yes. This is what I receive in /var/log/messages: [...] Jun 21 12:33:43 pcocol01 imap[19914]: DBERROR: error fetching user.col1901: cyrusdb error [...] And this is the result of executing ctl_mboxlist for this partition: [...] cyrus@pcocol01:~ ctl_mboxlist -d -p default user.col1901default col1901 lrswipcda user.col1901.Drafts default col1901 lrswipcda user.col1901.PosibleSPAMdefault col1901 lrsipd cyrus lrswipcda user.col1901.Sent default col1901 lrswipcda user.col1901.Trash default col1901 lrswipcda [...] When I try to do It I receive the next error: [...] localhost renm user.col1901 user.col1901 part3 renamemailbox: System I/O error [...] I have checked permissions and even I have given 777 to this mailbox: It probably isn't a good idea to mess with filesystem permissions. As long as everything is owned by your cyrus user it should be just fine. I agree. It was just for test purposes. Thank you for your help Adam. -- *Javier Sanchez-Arevalo* Dpto. de Informatica web:*www.coam.es* http://www.coam.es mail:*javier.sanc...@coam.org* mailto:javier.sanc...@coam.org Hortaleza 63 28004 Madrid T. 915 951 536 Este correo electronico y, en su caso, cualquier fichero anexo al mismo, contiene informacion de caracter confidencial exclusivamente dirigida a su destinatario o destinatarios. Queda prohibida su divulgacion, copia o distribucion a terceros sin la previa autorizacion escrita del COLEGIO OFICIAL DE ARQUITECTOS DE MADRID. En el caso de haber recibido este correo electronico por error, se ruega notifiquese inmediatamente esta circunstancia mediante reenvio a la direccion electronica del remitente o al telefono 915 951 500 1903 De conformidad con lo establecido en la L.O.P.D. 15/1999, EL COLEGIO OFICIAL DE ARQUITECTOS DE MADRID garantiza la adopcion de las medidas necesarias para asegurar el tratamiento confidencial de los datos de caracter personal. Asi mismo le informamos de la posibilidad de ejercer los derechos de acceso, rectificacion, cancelacion y oposicion en la siguiente direccion: Hortaleza 63. Madrid 28004 http://www.coam.es 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 -- *Javier Sanchez-Arevalo* Dpto. de Informatica web:*www.coam.es* http://www.coam.es mail:*javier.sanc...@coam.org* mailto:javier.sanc...@coam.org Hortaleza 63 28004 Madrid T. 915 951 536 Este correo electronico y, en su caso, cualquier fichero anexo al mismo, contiene informacion de caracter confidencial exclusivamente dirigida a su destinatario o destinatarios. Queda prohibida su divulgacion, copia o distribucion a terceros sin la previa autorizacion escrita del COLEGIO OFICIAL DE ARQUITECTOS DE MADRID. En el caso de haber recibido este correo electronico por error, se ruega notifiquese inmediatamente esta circunstancia mediante reenvio a la direccion electronica del remitente o al telefono 915 951 500 1903 De conformidad con lo establecido en la L.O.P.D. 15/1999, EL COLEGIO OFICIAL DE ARQUITECTOS DE MADRID garantiza la adopcion de las medidas necesarias para asegurar el tratamiento confidencial de los datos de caracter personal. Asi mismo le informamos de la posibilidad de ejercer los derechos de acceso, rectificacion, cancelacion y oposicion en la siguiente direccion: Hortaleza 63. Madrid 28004 http://www.coam.es 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
Migrating to Office 365
Hello list, I need to migrate mailboxes from a few different Cyrus servers to Microsoft Office 365 and am looking for a few tips. The migration process requires a CSV file to be prepared with a single username and password that has access to every student mailbox. Is it possible to create such a superuser account in Cyrus? Microsoft provide some tips on the required formatting of the CSV file for other IMAP servers here, but I am struggling to find a format that works. http://help.outlook.com/en-us/140/Ee730334.aspx Anyone have any ideas on how to accomplish this? Cheers, Simon 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: Migrating to Office 365
On 06/25/12 15:38 +0100, Simon Geary wrote: Hello list, I need to migrate mailboxes from a few different Cyrus servers to Microsoft Office 365 and am looking for a few tips. The migration process requires a CSV file to be prepared with a single username and password that has access to every student mailbox. Is it possible to create such a superuser account in Cyrus? Microsoft provide some tips on the required formatting of the CSV file for other IMAP servers here, but I am struggling to find a format that works. http://help.outlook.com/en-us/140/Ee730334.aspx Anyone have any ideas on how to accomplish this? I would guess that the Dovecot example should work. What's referred to as an Administrator should be the equivalent of a proxyservers entry in imapd.conf. e.g.: proxyservers: mailadmin For the proxy authentication to work, you will need to enable sasl authentication, and offer a mechanism which supports it: http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/mechanisms.php -- Dan White 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
MIgrating 2.3.16 spool to 2.4.16 : reconstruct (sometimes) changes ACL to old 2.2 value.
Hello, I copied part of our 2.3 production mail spool to a 2.4 test environment. When running 'reconstruct -r' on a subset of those test data, I noticed a number of mailbox ACLs being changed from 'lrswipkxtecda' to 'lrswipcda', the latter being the Cyrus 2.2 default. We started creating mailboxes in Cyrus 2.2 and some mailboxes still have that ACL applied. So I thought ... must be cases where the ACL stored in the cyrus.header file diverges from the ACL stored in the mailboxes.db, but (used 'mbexamine' on the production server to inspect the Cyrus metadata indexes) this was not the case. The code responsible for this can be found in imap/mailbox.c, lines 3553-3574 Clues ? Eric Luyten, Computing Centre VUB/ULB. 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: IMAP error reported by server. Invalid body section.
In case you want to know my cyrus verion is 2.2. Just an update: I
configured the same horde 4 installation to use yahoo servers and then
forwarded the message to my yahoo mail and watched in horde, the image
showed up normally.
--
Rodrigo Abrantes Antunes
Técnico em Tecnologia da Informação
Coordenadoria de Manutenção e Redes
Instituto Federal Sul-rio-grandense - Campus Pelotas
Quoting Simon Matter simon.mat...@invoca.ch:
On Jun 22, 2012, at 5:10 PM, Simon Matter simon.mat...@invoca.ch wrote:
On 06/22/2012 09:43 AM, Dave McMurtrie wrote:
On 06/22/2012 06:35 AM, Adam Tauno Williams wrote:
On Thu, 2012-06-21 at 13:07 -0300, Rodrigo Abantes Antunes wrote:
The source from horde3 is exactly the same as horde4
That is expected. It isn't the message but the interpretation of the
message. These evil messages contain many named parts separated by a
boundry (the boundry value is declared in the header of the message).
Then parts of a message can refer to other parts of the message. So
either H4 can't correctly [or incorrectly!] parse the message into
parts
by boundry or one part references another part that isn't found.
It would be useful to ask this question on the Horde / IMP mail list.
I think this originated as a bug report to Horde and they think it's
the
IMAP server's fault.
Rodrigo, can you forward the message to me?
Hi. Rodrigo sent me the message. I wanted to confirm that the MIME
structure was correct so I used munpack which was able to successfully
unpack all the message parts. This isn't a guarantee that the MIME
structure is correct, but at the very least I can't definitely say the
message is malformed.
I then imported the message into my mailstore. reconstruct was not
pleased with it from the start:
Jun 22 15:29:48 cyrusbe-d04 reconstruct[28021]: ERROR: message has more
than 1000 header lines, not caching any more
I did the same test on my box and reconstruct worked fine and I can view
the message with Squirrelmail and Thunderbird without any problems.
What's your version of cyrus-imapd you tested with? I have tested with a
2.4.16 server.
Interesting. The server I'm testing on isn't a released version, but
rather a snapshot build from the caldav-2.4 Git branch. It should be
Without looking at it closely, I have two things in my setup which could
make the difference?
1) I have set lmtp_strict_rfc2821: 0
2) I have this patch:
--- cyrus-imapd-2.3.7/imap/message.c2006-10-28 22:18:08.0 +0200
+++ cyrus-imapd-2.3.7/imap/message.c.nobarenewlinescheck2006-10-28
22:21:55.0 +0200
@@ -256,8 +256,9 @@
r = IMAP_MESSAGE_CONTAINSNULL;
}
else if (*p == '\n') {
- if (!sawcr (inheader || !allow_null))
- r = IMAP_MESSAGE_CONTAINSNL;
+ /* Do *NOT* check for RFC compliant line breaks (bare
newlines) */
+ /* if (!sawcr (inheader || !allow_null))
+ r = IMAP_MESSAGE_CONTAINSNL; */
sawcr = 0;
if (blankline) {
inheader = 0;
Regards,
Simon
fairly close to 2.4.16. Can you grab telemetry and see what
Squirrelmail/tbird is requesting?
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: GSSAPI for various murder component setups
On Sat, Jun 23, 2012 at 10:55 PM, Stephen Ingram sbing...@gmail.com wrote: On Thu, Jun 14, 2012 at 9:14 PM, Dan White dwh...@olp.net wrote: ...snip... You can control whether clients will get referrals via the proxyd_disable_mailbox_referrals option. When proxying, you would configure the 'cyrus-hostname' user within the proxyservers option on the backend. When the frontend authenticates to the backend, it will send an authorization identity of the previously authenticated frontend user. Like: authcid: none (derived from your kerberos identity) authzid: jsmith Then, from the backend's perspective, jsmith performed the authentication, and gets all the proper ACL permissions applied. The frontend *might* have all the appropriate service principals in place to support client gssapi authentication, however that's not necessary. The client authentication to the frontend, and the frontend's proxy authentication to the backend are distinct authentications. The frontend *will* need to have a non-service principal ticket initialized when performing gssapi authentication to the backend. Well, while I'm still not sure which way to go on the issue of where to place the service keytabs, your assertion that one *must* use a user to authenticate from the frontend to the backend in order to proxy the user authentication through seems to be correct. However, I'm not sure exactly why. When I test with imtest as user cyrus using the service principals in the same credential cache as fetched by the program, it works great. Even when testing with the service principals in place with the processes running, examining the caches, all the tickets appear to be properly granted and in the cache, however, every time there is a: couldn't authenticate to backend server: authentication failure error. Is there something specific in the cyrus-imapd code the ensures only a user principal will work? Is there some rationale to this? I've been told by everyone I've asked that there is no difference between user and service principals. Is it as something as silly as the / you alluded to omitting from your user principals before so you could satisfy libsasl2? After a little more testing, yes, it appears as though the / is disallowed. But Dave you said you are using imap/`hostname`@ANDREW.CMU.EDU. What happens if you want to use an admin instance of a user principal (e.g. steve/ad...@andrew.cmu.edu)? Has this changed and Dave, you are using a different version than Dan and I? Sorry to keep pounding on this issue, but I don't want to write documentation unless I really understand what is going on. BTW, the service principal works perfectly with the mupdate client to server auth. I have a feeling that the sync would work too. It seems to have something to do with the user proxy that Dan was describing. Maybe only a user can proxy another user and not a service? Steve 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
