Re: Self compiled Cyrus 2.4.16 does not talk to self compiled Cyrus SASL 2.1.25

2012-06-25 Thread Eric Luyten
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

2012-06-25 Thread Javier Sánchez-Arévalo Díaz

  
  

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

2012-06-25 Thread Eric Luyten
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

2012-06-25 Thread Simon Geary
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

2012-06-25 Thread Dan White
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.

2012-06-25 Thread Eric Luyten
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.

2012-06-25 Thread Rodrigo Abantes Antunes
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

2012-06-25 Thread Stephen Ingram
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