Re: mbox operations performance issue
Hi, Quoting Miguel Mucio Santos Moreira via Info-cyrus : Dears, I've had a problem for some days with mailboxes operations like sam, dam etc. Those operations are too slow, I have some mailboxes with many subfolders when I applied a sam command to allow other user access it, the command spends too much time (e.g 20hours). There's nothing weird in logs or etc. We have murder environment with cyrus-.4.16-4 on Debian 7. mailbox operations need to be acknowledged by/committed on the MUPDATE server. Is the mupdate server still running? Do you see connections from the backends to the mupdate on port 3905? Can you create new mailboxes? Did you try restarting cyrus on mupdate server 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
Re: imap impersonate
Quoting Gabriele Bulfon : Thanks, my imapd.conf has already : admins: sonicle sasl_mech_list: plain if I try an imap session with: A01 AUTHENTICATE PLAIN + xxx where xxx comes from 'echo -en "\0sonicle\0pass" | base64' , I get authenticated as sonicle. Now, how do I switch to the desired user? Once I understand how to do it via imap protocol, I need to replicate it in java code through: store.connect(host,143,user,pass); Thanks in advance! Gabriele Quoting from https://tools.ietf.org/html/rfc4616 2. PLAIN SASL Mechanism The mechanism consists of a single message, a string of [UTF-8] encoded [Unicode] characters, from the client to the server. The client presents the authorization identity (identity to act as), followed by a NUL (U+) character, followed by the authentication identity (identity whose password will be used), followed by a NUL (U+) character, followed by the clear-text password. As with other SASL mechanisms, the client does not provide an authorization identity when it wishes the server to derive an identity from the credentials and use that as the authorization identity. so it is UserID\0AdminID\0AdminPass 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
Re: imap impersonate
Quoting Gabriele Bulfon via Info-cyrus : Hi, is there any mechanism with Cyrus imap to impersonate another user? I've seen other imap servers scenarios where one may use plain authentication and sending user as mailboxuser plus a separator plus adminuser and use only adminpassword, to get access to the mailboxuser as is (dovecot, exchange). Anything like this in Cyrus? Gabriele Cyrus can use the PLAIN mech to allow admin access as the user. You need to add plain to sasl_mech_list in imapd.conf And the "admin" account has to be listed in admins or proxyservers in imapd.conf Regards, Michael 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
Re: Problems with SSL
Hi, Quoting Infraestructura TIC - UNNOBA via Info-cyrus : Hello! I'm using cyrus on Debian vm for several years but now, SSL starts to fail: Nov 29 13:05:58 server1 cyrus/imaps[9595]: inittls: Loading hard-coded DH parameters Nov 29 13:05:58 server1 cyrus/imaps[9595]: imaps TLS negotiation failed: [2801:0:140:f42:f3fa:b0b2:4ab1:8d10] I tried with self-signed certificates, and third-party ones, but the result is the same. I spent two days trying to figure out what happened, without results. #openssl s_client -connect mail.server.test:993 -crlf -state CONNECTED(0003) SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL3 alert read:fatal:handshake failure SSL_connect:error in SSLv3/TLS write client hello 140019483313280:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1388:SSL alert number 40 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 176 bytes Verification: OK --- New, (NONE), Cipher is (NONE) I believe the server and client have no SSL/TLS version and/or Cipher in common and therefore can't establish an encrypted connection. Some time ago i found an ssl server test suite https://github.com/drwetter/testssl.sh witch tries to do what https://www.ssllabs.com/ does for web servers but for all protocols and server not reachable form the internet. You might want to check your server with ./testssl.sh mail.server.test:993 Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: Session-ID: Session-ID-ctx: Master-Key: PSK identity: None PSK identity hint: None SRP username: None Start Time: 1480435442 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- I'm using this versions: cyrus-admin 2.5.10-2 cyrus-clients 2.5.10-2 cyrus-common 2.5.10-2 cyrus-doc 2.5.10-2 cyrus-imapd 2.5.10-2 cyrus-murder 2.5.10-2 cyrus-pop3d 2.5.10-2 cyrus-replication 2.5.10-2 Both, certificate and key, are accesibles by user cyrus. Certificate is up-to-date. This is the config: $sudo -u cyrus /usr/lib/cyrus/bin/cyr_info conf [...] tls_ciphers: TLSv1+HIGH:!aNULL:@STRENGTH tls_client_ca_dir: /etc/ssl/certs tls_client_ca_file: /etc/ssl/certs/cyrus.pem tls_server_cert: /etc/ssl/certs/cyrus.pem tls_server_key: /etc/ssl/private/cyrus.key tls_session_timeout: 0 [...] And before I declared myself "I'm completely lost", I was watching entropy ... but is ok. #cat /proc/sys/kernel/random/entropy_avail 2354 ¿Any suggestions? Thanks in advance! Javier.- 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 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
Bugs in cyrus murder 2.5 (was: Front End not forwarding requests to the backend)
Hi, Quoting Wolfgang Breyha via Info-cyrus : Michael Menge via Info-cyrus wrote on 07/11/16 10:30: Quoting Alberto Cardenas via Info-cyrus : I'm trying to setup Cyrus Murder for testing and have three virtual machines for this purpose (frontend, mupdate and backend). The three machines are running Centos 6.5, SASL 2.1.23 and Cyrus 2.3.16 you might want to consider using a more recent cyrus Version. Cyrus 2.3.16 is about 7 years old. 2.5.10 is the latest stable, 3.0 will be coming out soon. I don't think it has something to do with your problems but, there have been many bugfixes and improvements since 2.3. And if you set up a new system it would make things easier in the future. For murder I recommend the latest 2.4.x release. 2.5 has still several issues open with murder and I can not recommend using it without in deep knowledge how to handle them (eg. maintain your own patches). 2.4 simply works compared to 2.5. Thanks for the info, we are also still running cyrus 2.4 on our production environment. But mostly because that was the stable version at the time we migrated from stand alone to murder setup and the "never touch a running system" mentality. I was not aware that there was decreased stability for murder setup in the cyrus 2.5 version. Do you have some specific bugs in mind? Greetings Michael Greetings, Wolfgang -- Wolfgang Breyha | http://www.blafasel.at/ Vienna University Computer Center | Austria 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 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
Re: Front End not forwarding requests to the backend
Hi,
Quoting Alberto Cardenas via Info-cyrus :
Hello,
I'm trying to setup Cyrus Murder for testing and have three virtual
machines for this purpose (frontend, mupdate and backend). The three
machines are running Centos 6.5, SASL 2.1.23 and Cyrus 2.3.16
you might want to consider using a more recent cyrus Version. Cyrus 2.3.16
is about 7 years old. 2.5.10 is the latest stable, 3.0 will be coming out
soon. I don't think it has something to do with your problems but, there
have been many bugfixes and improvements since 2.3. And if you set up a
new system it would make things easier in the future.
Looks like communication from frontend to muptade and from backend
to mupdate is working fine since I can list the mailboxes created in
the backend using the “cyradm -u cyrus localhost” and “lm” commands,
which shows the same user’s mailboxes result on the three boxes.
The problem seems to be between the frontend and the backend since
the frontend is not forwarding the imap requests to the backend. To
test this, I am using the command “telnet localhost 143” on the
frontend server. Once that I get connected and authenticated, I
issue the command “select inbox”, but I receive the message “NO
Server(s) unavailable to complete operation”. In the
/usr/log/maillog file there is an error message that says “failed:
Connection timed out”
I have not configured yet the smtp server, not sure if it is
required, so I am trying to focus to get the imap part working.
The smtp server is needed to for the mail delivery and sieve redirects
and vacation but not for the imap access, so you can configure it later.
Any guidance would be appreciated. I have spent several days
working in this problem without getting any progress at all.
First, you din't set servername in you backend imapd.conf, which could lead
to the problem that the wrong name is used in the mailbox.db on the
mupdate server.
You can check that name used to register the created mailboxes on the
mupdate by
mupdate> ctl_mboxlist -d
The 3. column is the name of the backend follwod by the partition name
seperated by !
Make sure that the name used resolves to the correct ip address and
the the backend
is listening on the imap port on this ip
The forndend needs to be able to connect to the backend on the imap
port. You can test this
with telnet, but you can also use imtest which can help you to speak starttls.
Also check your audit logs on the frontend, selinux tends to block
wanted connections.
also "netstat -tupen | grep :143" can help to check the connection
between frontend and backend.
Here are my configuration files:
Frontend’s imap.conf
configdirectory: /var/lib/imap
partition-default: /var/spool/imap
admins: cyrus murder
sievedir: /var/lib/imap/sieve
sendmail: /usr/sbin/sendmail
hashimapspool: true
sasl_pwcheck_method: auxprop
sasl_mech_list: PLAIN
#tls_cert_file: /etc/pki/cyrus-imapd/cyrus-imapd.pem
#tls_key_file: /etc/pki/cyrus-imapd/cyrus-imapd.pem
#tls_ca_file: /etc/pki/tls/certs/ca-bundle.crt
allowplaintext: yes
mupdate_server: cyrus-mupdate.cvacyrus.com
mupdate_port: 3905
mupdate_username: murder
mupdate_authname: murder
mupdate_password: cvacva
cyrus-backend2_password: cvacva
proxy_authname: murder
Frontend’s cyrus.conf
START {
recover cmd="ctl_cyrusdb -r"
idled cmd="idled"
}
SERVICES {
mupdate cmd="mupdate" listen=3905 prefork=1
imap cmd="proxyd" listen="imap" prefork=5
}
EVENTS {
checkpointcmd="ctl_cyrusdb -c" period=30
delprune cmd="cyr_expire -E 3" at=0400
tlsprune cmd="tls_prune" at=0400
}
Backend’s imap.conf
configdirectory: /var/lib/imap
partition-default: /var/spool/imap
admins: cyrus murder
sievedir: /var/lib/imap/sieve
sendmail: /usr/sbin/sendmail
hashimapspool: true
sasl_pwcheck_method: auxprop
sasl_mech_list: PLAIN
altnamespace: yes
allowplaintext: yes
proxyservers: murder
mupdate_server: cyrus-mupdate.cvacyrus.com
mupdate_port: 3905
mupdate_username: murder
mupdate_authname: murder
mupdate_password: cvacva
Backend’s cyrus.conf
START {
recover cmd="ctl_cyrusdb -r"
idled cmd="idled"
mupdatepush cmd="ctl_mboxlist -m"
}
SERVICES {
imap cmd="imapd" listen="imap" prefork=5
}
EVENTS {
checkpointcmd="ctl_cyrusdb -c" period=30
delprune cmd="cyr_expire -E 3" at=0400
tlsprune cmd="tls_prune" at=0400
}
Mupdate’s imap.conf
configdirectory: /var/lib/imap
partition-default: /var/spool/imap
admins: cyrus murder
sievedir: /var/lib/imap/sieve
sendmail: /usr/sbin/sendmail
hashimapspool: true
sasl_pwcheck_method: auxprop
sasl_mech_list: PLAIN
allowplaintext: 1
Mupsate’s cyrus.conf
START {
recover cmd="ctl_cyrusdb -r"
idled cmd="idled"
}
SERVICES {
imap cmd="imapd" listen="imap" prefork=5
mupdate cmd="mupdate -m" listen="mupdate" prefork=1
}
EVENTS {
checkpointcmd="ctl_cyrusdb -c" period=30
delprune cmd="cyr_expire -E 3" at=0400
tlsprune cmd="
Re: Sieve login issue. Please help.
Hi,
Quoting Müfit Eribol via Info-cyrus :
Hello,
I am a happy user of cyrus-imapd for years without any major problem
for small user base.
Currently, I am having login problem for sieve. I have been trying
to find the problem for days.
Please find below information about my configuration:
1. Installed software: cyrus-imapd-2.4.17, postfix-2.10.1,
cyrus-sasl-2.1.26, cyrus-sasl-plain-2.1.26, cyrus-sasl-lib-2.1.26 on
CentOS 7.
2. Authentication is done through saslauthd, pam and mysql.
3. pwcheck_method: saslauthd, mech_list: plain login
4. There is no problem with login to imapd or smtpd.
5. cyrus.conf
SERVICES {
imaplocal cmd="imapd -C /etc/imapd-local.conf"
listen="127.0.0.1:imap" prefork=0
imaps cmd="imapd -s" listen="imaps" prefork=1
imapslocalcmd="imapd -C /etc/imapd-local.conf"
listen="127.0.0.1:imaps" prefork=0
sieve cmd="timsieved" listen="sieve" prefork=0
You did not define an ip address here, so sieve will use 0.0.0.0:sieve
sievelocal cmd="timsieved -C /etc/imapd-local.conf"
listen="127.0.0.1:sieve" prefork=0
this will likely fail, as the "sieve" service above will is already
listening on 0.0.0.0
and blocking 127.0.0.1
lmtpunix cmd="lmtpd" listen="/var/lib/imap/socket/lmtp" prefork=1
}
6. imapd.conf
postmaster: postmaster
configdirectory: /var/lib/imap
partition-default: /var/spool/imap
#admins: cyrus
allowanonymouslogin: no
allowplaintext: no
#tls_require_cert: 1
sasl_minimum_layer: 128
servername: mail.x.com
autocreatequota: 20
maxmessagesize: 0
reject8bit: 0
munge8bit: 0
quotawarn: 90
timeout: 30
poptimeout: 10
dracinterval: 0
drachost: localhost
sasl_pwcheck_method: saslauthd
sasl_mech_list: PLAIN
sievedir: /var/lib/imap/sieve
sieve_maxscriptsize: 32
sieve_maxscripts: 5
sieve_allowplaintext: 1
sendmail: /usr/sbin/sendmail
tls_cert_file: /etc/pki/tls/certs/imap.pem
tls_key_file: /etc/pki/tls/certs/imap.pem
tls_ca_file: /etc/pki/tls/certs/imap.pem
7. imapd-local.conf
postmaster: postmaster
configdirectory: /var/lib/imap
partition-default: /var/spool/imap
admins: cyrus
allowanonymouslogin: no
allowplaintext: yes
servername: mail.xx.com
autocreatequota: 100
maxmessagesize: 0
reject8bit: no
quotawarn: 90
timeout: 30
poptimeout: 10
dracinterval: 0
drachost: localhost
sasl_pwcheck_method: saslauthd
sasl_mech_list: PLAIN
sievedir: /var/lib/imap/sieve
sieve_maxscriptsize: 32
sieve_maxscripts: 5
sendmail: /usr/sbin/sendmail
8. shell:
[root@server ~]# sieveshell -u user1 -a user1 localhost
connecting to localhost
unable to connect to server at /usr/bin/sieveshell line 170.
maillog:
Sep 22 10:34:45 server sieve[15050]: Lost connection to client -- exiting
9. shell:
[root@server ~]# telnet localhost sieve
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
"IMPLEMENTATION" "Cyrus timsieved v2.4.17-Fedora-RPM-2.4.17-8.el7_1"
"SASL" ""
"SIEVE" "comparator-i;ascii-numeric fileinto reject vacation
imapflags notify envelope relational regex subaddress copy"
"STARTTLS"
"UNAUTHENTICATE"
OK
10. When I try to login using smartsieve
maillog:
Sep 22 10:38:32 server sieve[16029]: STARTTLS failed: localhost[127.0.0.1]
you are not connecting to sievelocal but to sieve and therefore
"allowplaintext: no" from
imapd.conf is preventing auth:login and auth:plain from showing
without usage of startls
I don't understand why STARTTLS is being called when connecting from
localhost? Is it normal? Obviously, I am doing something wrong.
I would appreciate any help. Thank you.
Cheers,
Michael
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
Re: Invalid mailbox name
Quoting Paul van der Vlis via Info-cyrus : Op 21-09-16 om 14:11 schreef Michael Menge via Info-cyrus: Hi, Quoting Paul van der Vlis via Info-cyrus : Hello, I am syncing many mailboxes from one IMAP server to another. Now I get sometimes errors on mailbox names. I found out that Cyrus does not accept brackets in a mailbox name. Is there documentation about what characters are accepted in mailbox names?? The allowed ASCII-Chars are defined in the macro GOODCHARS in imap/mboxname.c (https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/mboxname.c#L1495). non-ASCII-Chars are handled by RFC 3501 5.1.3. This subject has been discussed a few years ago on this list, and GOODCHARS has been changed between cyrus versions. 2.2:#define GOODCHARS " +,-.0123456789:=@ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz~" 2.3:#define GOODCHARS " #$'+,-.0123456789:=@ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz~" Master: #define GOODCHARS " #$'()*+,-.0123456789:=?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_abcdefghijklmnopqrstuvwxyz~" Thanks for your answer! I am wondering about the dot. So far I know I cannot use it in a mailbox name, but it is in the list. I suspect that your cyrus is configured to use the . as hierarchy seperator. see "unixhierarchysep:" in imapd.conf manpage for details. And what's "master" exactly? So far I see, I cannot use e.g. brackets in a mailbox name. Master is the name of the main development branch in git. A new branch for cyrus imapd 3.0 will be forked from the master branch with the release of the new version. 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
Re: Invalid mailbox name
Hi, Quoting Paul van der Vlis via Info-cyrus : Hello, I am syncing many mailboxes from one IMAP server to another. Now I get sometimes errors on mailbox names. I found out that Cyrus does not accept brackets in a mailbox name. Is there documentation about what characters are accepted in mailbox names?? The allowed ASCII-Chars are defined in the macro GOODCHARS in imap/mboxname.c (https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/mboxname.c#L1495). non-ASCII-Chars are handled by RFC 3501 5.1.3. This subject has been discussed a few years ago on this list, and GOODCHARS has been changed between cyrus versions. 2.2:#define GOODCHARS " +,-.0123456789:=@ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz~" 2.3:#define GOODCHARS " #$'+,-.0123456789:=@ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz~" Master: #define GOODCHARS " #$'()*+,-.0123456789:=?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[]^_abcdefghijklmnopqrstuvwxyz~" 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
Re: unable to delete corrupted mail box on cyrus v2.3.16
Quoting Sophie Loewenthal via Info-cyrus : Hi! I have a broken mailbox that I would like to delete. This is Cyrus v2.3.16 on CentOS 6. I tried reconstructing the mailbox from scratch ( Because I suspect this was manually deleted from disc ). mkdir imap-store/spool/imap/domain/example.com/user/kat^long cd imap-store/spool/imap/domain/example.com/user/kat^long chmod 755 . chown cyrus:mail . touch cyrus.header chown cyrus:mail cyrus.header log into cyradm: localhost> lam user/kat.long kat.l...@example.com lrswipkxtecda localhost> reconstruct -r user/kae.long reconstruct: Mailbox has an invalid format localhost> dm user/kat.long deletemailbox: Permission denied you must give your admin account the permission to delete the mailbox localhost> sam user/kat.long cyrus all localhost> dm user/kat.long Names and domain names replaced with false entries. How could I remove this? Kind regards, Sophie. 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 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
Re: migrating mails between two cyrus servers keeping seen states
Quoting Marcus Schopen : Am Freitag, den 18.12.2015, 14:09 +0100 schrieb Michael Menge via Info-cyrus: Hi, Quoting Marcus Schopen via Info-cyrus : > Hi, > > I'm planning to move some mailboxes from a cyrus server (2.1.18 - which > is a kind of mail archive) to another one (2.4.17+caldav~beta9-3). > Playing around on a test system with copying a user's mailbox and doing > a following "reconstruct -r" came out with a mailbox without seen states > on read mails on the new system; all mails unread. Normally I move > mailboxes using imapsync to keep states etc., but on a number of really > large mailboxes the initial sync takes days. Any other suggestions than > (slow) imapsync tools? > Befor 2.4.x the seen information was stored in extra files in /var/imap/user Did you copy these files too? Ah, it's an old Debian system. These files are stored in eg. /var/lib/cyrus/user/t/testuser.seen. Where do I have to copy this file on the new server to? And there is a testuser.sub in the same dir, which contains the subfolders. What about this file? The seen information is now included in the cyrus.* files (i think in the index file), but upgrading form an older version with reconstruct should check the .seen file at the old location. The location depends on your setting of configdirectory, fulldirhash and hashimapspool in impad.conf. The handling of the sub file has not changed. But you should copy them to the new server, if you want to keep the subscription information. You should check https://cyrusimap.org/docs/cyrus-imapd/2.4.17/install-upgrade.php 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
Re: migrating mails between two cyrus servers keeping seen states
Hi, Quoting Marcus Schopen via Info-cyrus : Hi, I'm planning to move some mailboxes from a cyrus server (2.1.18 - which is a kind of mail archive) to another one (2.4.17+caldav~beta9-3). Playing around on a test system with copying a user's mailbox and doing a following "reconstruct -r" came out with a mailbox without seen states on read mails on the new system; all mails unread. Normally I move mailboxes using imapsync to keep states etc., but on a number of really large mailboxes the initial sync takes days. Any other suggestions than (slow) imapsync tools? Befor 2.4.x the seen information was stored in extra files in /var/imap/user Did you copy these files too? 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
Re: Pb with automatically sort emails
Hi, Quoting Masson Christophe via Info-cyrus : Hello, I try to sort automatically emails into subdirectories with a adress like commission.ce...@new.enssat.fr. I have a internal error with lmtp [/var/run/cyrus/socket/lmtp] said: 451 4.3.0 Unexpected internal error (in reply to end of DATA command)). When i try to a subdirectories wich don't exist, i have a error message, ok its' right. I have try to put acl for postman. Where is the pb? There are 2 ways to sort mails to subfolders, one is the plus-addressing feature. 1. Mails send to testuser+testfol...@testdomain.bla will be stored in the folter "testfolder" of the testuser if the p acl is set for 'anyone'. If this acl is not set the mail will be delivered normaly, as if the foldername was not present (to the INBOX) if no sieve script is configured. 2. You can use sieve scripts to store mails in different folders. At the moment it is not possible to filter based on the display name of an email-address, but filtering based on the email-addres itself works fine. " 451 4.3.0 Unexpected internal error" indicates that something else is wrong, you should check your cyrus log for more details. 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
Re: Replication problem do_folders(): failed to rename
Hi, Quoting Patrick Boutilier via Info-cyrus : On 12/14/2015 06:25 AM, Marcus Schopen via Info-cyrus wrote: Am Freitag, den 11.12.2015, 19:10 +0100 schrieb Marcus Schopen via Info-cyrus: Hi, I have a problem with a single mailbox. The user's Outlook crashed and since then the sync_client is running wild on this user account and produces high load on the master. I stopped sync_client on master side for the moment. When I try to sync the user by hand /bin/su - cyrus -c "/usr/lib/cyrus/bin/sync_client -S replicaserver -v -u testuser I do get the following error. Dec 11 17:54:48 master cyrus/sync_client[22727]: RENAME received NO response: Operation is not supported on mailbox Dec 11 17:54:48 master cyrus/sync_client[22727]: do_folders(): failed to rename: user.elsa-secgen -> user.testuser.Archives.Gesch&AOQ-ftsjahr 2014-15.25-Jahr-Feier Dec 11 17:54:48 master cyrus/sync_client[22727]: IOERROR: The remote Server(s) denied the operation Dec 11 17:54:48 master cyrus/sync_client[22727]: Error in do_user(testuser): bailing out! Comparing master and slave on filesystem I do see the subfolder "25-Jahr-Feier" in "user.testuser.Archives.Gesch&AOQ-ftsjahr 2014-15.", but only on master but not on slave side. And why does sync_client want to rename and where does it get this order from? I can login into the users' mailbox on master side and new message are shown in the INBOX. How can I fix it? Should I try a "reconstruct -r user.testuser" on master and slave or just on slave? (do I have to shutdown cyrus for a reconstruct -r on a user box?) Or can I delete the complete mailbox on slave side start an "sync_client -S replicaserver -v -u testuser"? Thanks for helping Marcus I did a reconstruct on the replica whichs runs through on the 12 GB mailbox ot the user within a second (too fast?). /bin/su - cyrus -c "/usr/lib/cyrus/bin/reconstruct -r user.testuser" A following sync ended up with the same error: /bin/su - cyrus -c "/usr/lib/cyrus/bin/sync_client -S replicaserver -v -u testuser Any ideas? No, but this seems weird. Was this user ever renamed? user.elsa-secgen -> user.testuser.Archives.Gesch&AOQ-ftsjahr Cyrus uses the folder "Unique ID" for syncronisation. If this "Unique ID" is NOT unique it will confuse syncronisation. Ciao Marcus 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 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
Re: Cyrus imap 2.3.11-xx with postfix 2.9.4
Quoting Josef Karliak via Info-cyrus : Good morning, we had some issue tomorow's morning - some users couldn't login to an email system. We use ypages for distributing passwd maps, authorizing daemon is saslauthd. Some users logged in, some not. "Unauthorized" users made a record to the syslog: Nov 24 08:01:23 email1 saslauthd[10396]: DEBUG: auth_pam: pam_authenticate failed: User not known to the underlying authentication module Nov 24 08:01:23 email1 saslauthd[10396]: do_auth : auth failure: [user=username] [service=imap] [realm=] [mech=pam] [reason=PAM auth error] Nov 24 08:01:23 email1 imap[26411]: badlogin: localhost [127.0.0.1] plaintext username SASL(-13): authentication failure: checkpass failed About this time +/- seconds I see in the mail log this complains of the postfix to the cyrus's lmtp: Nov 24 08:01:25 email1 postfix/lmtp[29859]: warning: 19535581B: non-LMTP response from email1.fnhk.cz[public/lmtp]: do_ypcall: clnt_call: RPC: Timed out Nov 24 08:01:25 email1 postfix/lmtp[29859]: warning: to prevent loss of mail, turn off command pipelining for public/lmtp with the lmtp_discard_lhlo_keyword_address_maps parameter Nov 24 08:01:50 email1 postfix/lmtp[29859]: warning: 19535581B: non-LMTP response from email1.fnhk.cz[public/lmtp]: do_ypcall: clnt_call: RPC: Timed out Nov 24 08:01:50 email1 postfix/lmtp[29859]: warning: to prevent loss of mail, turn off command pipelining for public/lmtp with the lmtp_discard_lhlo_keyword_address_maps parameter The username was in all 3 hosts maps, another users logged in, there is no complains about network connections. This worked fine for an years, but this issue happened twice within 2 weeks. An administrators of the ypages servers don't see any problem or logs about theirs server. What caused this issue ? What can I do to prevent it. The errors "User not known to the underlying authentication module" and "do_ypcall: clnt_call: RPC: Timed out" indicate that your system is unable to query the ypages in time. As this happens to postfix and cyrus I think it is not a problem in postfix or cyrus but in your ypages client, ypages server or the network connection. 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
Re: PATCH for lmtp was [frontend lmtp connections to mupdate master]
Hi, https://cyrusimap.org/mediawiki/index.php/Cyrus_Murder_Failure_Modes "2. Mail delivery via the frontends is deferred (lmtpproxyd cannot locate mailbox). " should be updated too Quoting Ken Murchison : Done. On 11/17/2015 03:29 AM, Michael Menge wrote: Hi Ken thanks. Do you intend to patch 2.4.x and 2.5.x ? I am a bit confused by the recent changes of cyrusimap and cyrus.fondation. Is the bugtracker https://bugzilla.cyrusimap.org still used by the project? If yes, you should close https://bugzilla.cyrusimap.org/show_bug.cgi?id=3866, if not, someone should add some information where the new bugtracker can be found Regards Michael Quoting Ken Murchison : I committed a revised version just a little while ago: https://git.cyrus.foundation/rI0fd86ca759ffa32e8d22dbdde78ea82d63650827 On 11/16/2015 04:41 AM, Michael Menge via Info-cyrus wrote: Hi, is there anything missing from my side, or something that I can do to help that my patch can be included? Regards Michael Quoting Nic Bernstein via Info-cyrus : Bron, We're starting to run into this same issue -- lmtp proxies fail to deliver mail when mupdate master craps -- and so started to investigate this thread. However, it doesn't look like Michael Menge's patch made it in. Your thoughts? -nic On 10/07/2014 08:17 AM, Bron Gondwana wrote: I'm convinced :) I'll probably add it with Ken while we're at CMU in a couple of weeks when we can test it together. This is precisely the kind of thing we love to see! Thanks. Bron. On Tue, Oct 7, 2014, at 10:23 PM, Michael Menge wrote: Hi, as we have had an other crash of mupdate master last week, we used the patch on our production system. After the patch was added the load on mupdate master was dropping form about 10 to about 1. After one week of using it we have not found any problems. As I have not received any other feedback, I added it to the bugtracker. https://bugzilla.cyrusimap.org/show_bug.cgi?id=3866 Pleas consider adding it to 2.5 and 2.4.next Regards Michael Quoting Michael Menge : Hi, Quoting Michael Menge : Quoting Michael Menge : By thew way, the reason I was so surprised in the first place was, that I have been fooled by the documentation: Quoting https://cyrusimap.org/docs/cyrus-imapd/2.4.17/install-murder.php Configuring the frontends [...] However, because the frontends only talk to the mupdate master via a slave running on the local machine, you will also need to set up a slave on the same machine, in the SERVICES section of cyrus.conf, like so And an other misleading DOC ! Quoting http://www.cyrusimap.org/mediawiki/index.php/Cyrus_Murder_Mail_Delivery UMich patch Patch Patches are against 2.2 but are being moved to 2.3 Lmtpproxyd will now use the local mailboxes.db Quoting Wesley Craig : On 29 Sep 2014, at 10:08, Michael Menge wrote: thanks for your mail. By any chance do you still have the patch? In fact, I don't. Dusting off my notes, I recall now that instead of patching this (bogus) code, we instead decided to configure the frontends as "unified", while leaving the backends "standard". The only downside of this approach was that a naive admin could potentially create a user's mailbox on a frontend. Sorry I said that we ported that code forward: in fact we simply got the effect of consulting mailboxes.db without porting forward. :wes I have patched my lmtpd to use the local mailbox.db in all cases, unified Murder, and standalone cyrus already did this. I tested it with a few testmails on my test system, but as i don't have a unified setup or a standalone test system at the moment i didn't test these setups. I would appreciate a review. 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 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 Email had 1 attachment: + smime.p7s 7k (application/pkcs7-signature) -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073
Re: Advise needed for new mail server
Hi Mufit, Quoting Mufit Eribol via Info-cyrus : Hello, I have been successfully using postfix+cyrus-imapd (2.4.17) for our small company for years on our local server. The emails are now accounting to a size of some 160GB. As we are having power and internet problems quite often, I rented a VPS from a world renowned hosting company and installed postfix+cyrus-imapd there. My question is, as I have limited hard disk space (40GB) on VPS, I can't (and don't want to) copy all of my local emails to the VPS. The new mail server will have a fresh start. But old emails needs to be accessible on the local server as well. Currently, I am planning to change the names of local domains to some non-existent name just for the internal lookup (example.com --> example2.com), so that we can setup example2.com on our email clients on lan. The real domain example.com will be setup on our desktop email clients as usual. I think, using example2.com on local lan just for reading mails by cyrus will work, but it is not an elegant solution. I would appreciate any ideas. Cyrus Murder my be the solution for you. https://cyrusimap.org/mediawiki/index.php/Cyrus_Murder The Clients will only connect to one server (VPS), and the mails can be stored on different backend servers. There is only minimal configuration change needed on your old server, but you would need to rename the folders. 1 backend (VPS) for the INBOX and folders with new Mail 1 backend (old System) with all old folders in an archive subfolder for each user 1 mupdate master (VPS) 1 frontend (VPS) 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
Re: PATCH for lmtp was [frontend lmtp connections to mupdate master]
Hi Ken thanks. Do you intend to patch 2.4.x and 2.5.x ? I am a bit confused by the recent changes of cyrusimap and cyrus.fondation. Is the bugtracker https://bugzilla.cyrusimap.org still used by the project? If yes, you should close https://bugzilla.cyrusimap.org/show_bug.cgi?id=3866, if not, someone should add some information where the new bugtracker can be found Regards Michael Quoting Ken Murchison : I committed a revised version just a little while ago: https://git.cyrus.foundation/rI0fd86ca759ffa32e8d22dbdde78ea82d63650827 On 11/16/2015 04:41 AM, Michael Menge via Info-cyrus wrote: Hi, is there anything missing from my side, or something that I can do to help that my patch can be included? Regards Michael Quoting Nic Bernstein via Info-cyrus : Bron, We're starting to run into this same issue -- lmtp proxies fail to deliver mail when mupdate master craps -- and so started to investigate this thread. However, it doesn't look like Michael Menge's patch made it in. Your thoughts? -nic On 10/07/2014 08:17 AM, Bron Gondwana wrote: I'm convinced :) I'll probably add it with Ken while we're at CMU in a couple of weeks when we can test it together. This is precisely the kind of thing we love to see! Thanks. Bron. On Tue, Oct 7, 2014, at 10:23 PM, Michael Menge wrote: Hi, as we have had an other crash of mupdate master last week, we used the patch on our production system. After the patch was added the load on mupdate master was dropping form about 10 to about 1. After one week of using it we have not found any problems. As I have not received any other feedback, I added it to the bugtracker. https://bugzilla.cyrusimap.org/show_bug.cgi?id=3866 Pleas consider adding it to 2.5 and 2.4.next Regards Michael Quoting Michael Menge : Hi, Quoting Michael Menge : Quoting Michael Menge : By thew way, the reason I was so surprised in the first place was, that I have been fooled by the documentation: Quoting https://cyrusimap.org/docs/cyrus-imapd/2.4.17/install-murder.php Configuring the frontends [...] However, because the frontends only talk to the mupdate master via a slave running on the local machine, you will also need to set up a slave on the same machine, in the SERVICES section of cyrus.conf, like so And an other misleading DOC ! Quoting http://www.cyrusimap.org/mediawiki/index.php/Cyrus_Murder_Mail_Delivery UMich patch Patch Patches are against 2.2 but are being moved to 2.3 Lmtpproxyd will now use the local mailboxes.db Quoting Wesley Craig : On 29 Sep 2014, at 10:08, Michael Menge wrote: thanks for your mail. By any chance do you still have the patch? In fact, I don't. Dusting off my notes, I recall now that instead of patching this (bogus) code, we instead decided to configure the frontends as "unified", while leaving the backends "standard". The only downside of this approach was that a naive admin could potentially create a user's mailbox on a frontend. Sorry I said that we ported that code forward: in fact we simply got the effect of consulting mailboxes.db without porting forward. :wes I have patched my lmtpd to use the local mailbox.db in all cases, unified Murder, and standalone cyrus already did this. I tested it with a few testmails on my test system, but as i don't have a unified setup or a standalone test system at the moment i didn't test these setups. I would appreciate a review. 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 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 Email had 1 attachment: + smime.p7s 7k (application/pkcs7-signature) -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 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ächterst
Re: PATCH for lmtp was [frontend lmtp connections to mupdate master]
Hi, is there anything missing from my side, or something that I can do to help that my patch can be included? Regards Michael Quoting Nic Bernstein via Info-cyrus : Bron, We're starting to run into this same issue -- lmtp proxies fail to deliver mail when mupdate master craps -- and so started to investigate this thread. However, it doesn't look like Michael Menge's patch made it in. Your thoughts? -nic On 10/07/2014 08:17 AM, Bron Gondwana wrote: I'm convinced :) I'll probably add it with Ken while we're at CMU in a couple of weeks when we can test it together. This is precisely the kind of thing we love to see! Thanks. Bron. On Tue, Oct 7, 2014, at 10:23 PM, Michael Menge wrote: Hi, as we have had an other crash of mupdate master last week, we used the patch on our production system. After the patch was added the load on mupdate master was dropping form about 10 to about 1. After one week of using it we have not found any problems. As I have not received any other feedback, I added it to the bugtracker. https://bugzilla.cyrusimap.org/show_bug.cgi?id=3866 Pleas consider adding it to 2.5 and 2.4.next Regards Michael Quoting Michael Menge : Hi, Quoting Michael Menge : Quoting Michael Menge : By thew way, the reason I was so surprised in the first place was, that I have been fooled by the documentation: Quoting https://cyrusimap.org/docs/cyrus-imapd/2.4.17/install-murder.php Configuring the frontends [...] However, because the frontends only talk to the mupdate master via a slave running on the local machine, you will also need to set up a slave on the same machine, in the SERVICES section of cyrus.conf, like so And an other misleading DOC ! Quoting http://www.cyrusimap.org/mediawiki/index.php/Cyrus_Murder_Mail_Delivery UMich patch Patch Patches are against 2.2 but are being moved to 2.3 Lmtpproxyd will now use the local mailboxes.db Quoting Wesley Craig : On 29 Sep 2014, at 10:08, Michael Menge wrote: thanks for your mail. By any chance do you still have the patch? In fact, I don't. Dusting off my notes, I recall now that instead of patching this (bogus) code, we instead decided to configure the frontends as "unified", while leaving the backends "standard". The only downside of this approach was that a naive admin could potentially create a user's mailbox on a frontend. Sorry I said that we ported that code forward: in fact we simply got the effect of consulting mailboxes.db without porting forward. :wes I have patched my lmtpd to use the local mailbox.db in all cases, unified Murder, and standalone cyrus already did this. I tested it with a few testmails on my test system, but as i don't have a unified setup or a standalone test system at the moment i didn't test these setups. I would appreciate a review. 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 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 Email had 1 attachment: + smime.p7s 7k (application/pkcs7-signature) -- Nic Bernstein n...@onlight.com Onlight, Inc. www.onlight.com 6525 W Bluemound Road, Suite 24 v. 414.272.4477 Milwaukee, Wisconsin 53213-4073 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
