looking for Cyrus mail format documentation
A couple people have suggested to me that I use Cyrus-IMAP as opposed to Courier-IMAP, and have given some good arguments for that decision direction. However, I have still have one show stopper for that switch: some external programs that work directly with the storage space of all the mail. Due to the nature of some of these programs, accessing that mail by means of the IMAP protocol or any delivery protocol is not an option. What I want to examine at this point is the potential ease of converting those programs to work with the format Cyrus-IMAP stores its mail. Had Cyrus-IMAP used the Maildir format, this would be a simple unplug Courier and plugin Cyrus. The issue is not about converting existing messages (the transition will be done with all empty mailboxes). The issue is knowing the details of the format in its entirety. I've looked around the web site and the source file tree and I find no documentation on this format. I have been told two different stories about references to other formats it is like. But then, I've also heard people tell me Cyrus-IMAP really does use Maildir format (and as far as I can see, that simply is not true). So basically, I'm asking if any documentation(s) exists which would described (preferrably in a standards style) just what the format is. Please don't refer me to the source code, as I already have that, and I've never found that method to be a clean way to deal with all the issues (too often semantics are missed because the implementation doesn't push requirements to the edge). Documents in ASCII, HTML, or PDF preferred. I was also looking for documentation on SASL. That I found in the RFCs. That's the kind of thing I'm looking for regarding the file formats. -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| -
Re: looking for Cyrus mail format documentation
Hello, One of the disadvantage of using Cyrus might be that there is no API to the mail store other than the IMAP protocol. You simply cannot go mucking around the mail store with external programs without the potential to cause problems. That said, mail is stored in directories that map unto folders and each message has its own file. Seems pretty straight forward until you realize that the file names and directories have metadata associated with them that the IMAP server process needs and maintains. One simply does not mkdir in someone's account and expect the corresponding folder to show up. Nor can you simply create a file with what appears to be an appropriate name and have the message show up in a folder. Cyrus documentation calls the IMAP server a black box. This is defined to mean that the users do not have access to the account/data accept through the well defined ( :-/ ) IMAP protocol. This black box concept also extends to a certain extent to the administrators of the servers. Best way to learn something is through experience. Set up a server and look at how it does things. If you opt for compiling it yourself choose the flat file options for all the databases. This will leave the data in a format that is human readable, sorta, and you can figure out what is going on. Regards, Earl Shannon Phil Howard wrote: A couple people have suggested to me that I use Cyrus-IMAP as opposed to Courier-IMAP, and have given some good arguments for that decision direction. However, I have still have one show stopper for that switch: some external programs that work directly with the storage space of all the mail. Due to the nature of some of these programs, accessing that mail by means of the IMAP protocol or any delivery protocol is not an option. What I want to examine at this point is the potential ease of converting those programs to work with the format Cyrus-IMAP stores its mail. Had Cyrus-IMAP used the Maildir format, this would be a simple unplug Courier and plugin Cyrus. The issue is not about converting existing messages (the transition will be done with all empty mailboxes). The issue is knowing the details of the format in its entirety. I've looked around the web site and the source file tree and I find no documentation on this format. I have been told two different stories about references to other formats it is like. But then, I've also heard people tell me Cyrus-IMAP really does use Maildir format (and as far as I can see, that simply is not true). So basically, I'm asking if any documentation(s) exists which would described (preferrably in a standards style) just what the format is. Please don't refer me to the source code, as I already have that, and I've never found that method to be a clean way to deal with all the issues (too often semantics are missed because the implementation doesn't push requirements to the edge). Documents in ASCII, HTML, or PDF preferred. I was also looking for documentation on SASL. That I found in the RFCs. That's the kind of thing I'm looking for regarding the file formats.
Re: looking for Cyrus mail format documentation
A couple people have suggested to me that I use Cyrus-IMAP as opposed to Courier-IMAP, and have given some good arguments for that decision direction. However, I have still have one show stopper for that switch: some external programs that work directly with the storage space of all the mail. Due to the nature of some of these programs, accessing that mail by means of the IMAP protocol or any delivery protocol is not an option. You'd need to change how those applications work. Cyrus is a sealed box, external access to the mailstore is forbidden. One of the many reasons Cyrus is so fast and stable (stable, at least for us, in almost a geological sence, very impressive). What I want to examine at this point is the potential ease of converting those programs to work with the format Cyrus-IMAP stores its mail. I think you pretty much can't. I've looked around the web site and the source file tree and I find no documentation on this format. I have been told two different stories about references to other formats it is like. But then, I've also heard people tell me Cyrus-IMAP really does use Maildir format (and as far as I can see, that simply is not true). It does not use maildir. It actually can use several storage backends, flat file to sleepcat and some others. Rumor of an SQL backend, that might be what your looking for. I was also looking for documentation on SASL. That I found in the RFCs. That's the kind of thing I'm looking for regarding the file formats. SASL documentation?! There is some floating about. I love SASL, but the shreds of documentation are universally terrible.
Re: looking for Cyrus mail format documentation
On Fri, 31 Jan 2003, Earl R Shannon wrote: Cyrus documentation calls the IMAP server a black box. This is defined to mean that the users do not have access to the account/data accept through the well defined ( :-/ ) IMAP protocol. This black box concept also extends to a certain extent to the administrators of the servers. Obviously the mail store access is not limited to the IMAP protocol, one can also use LMTP and POP3, and NNTP if you're using the 2.2 branch. There's also some utilities such as deliver that can let you do various things to the mail store. Best way to learn something is through experience. Set up a server and look at how it does things. If you opt for compiling it yourself choose the flat file options for all the databases. This will leave the data in a format that is human readable, sorta, and you can figure out what is going on. This is really only useful for educational purposes, not for actually running a mail store where other programs want direct access. The only way to accomplish the latter legitimately is to use the cyrus source directly. Often times mailbox access semantics change slightly from version to version, and if you're not using all the same code (which assumes it is only dealing with one version of itself), then you can run into trouble. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: looking for Cyrus mail format documentation
On Fri, 31 Jan 2003, Adam Tauno Williams wrote: SASL documentation?! There is some floating about. I love SASL, but the shreds of documentation are universally terrible. If you have specific suggestions as to what needs to be added, please let us know. If you actually have text, that'd be even better. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: looking for Cyrus mail format documentation
Adam Tauno Williams said: SASL documentation?! There is some floating about. I love SASL, but the shreds of documentation are universally terrible. AFAIK, this is also true for much of the software that CMU produces, however the quality of the software has been so good that no one seems to mind too much. I think O'Reilly could tap a big market by writing books on some of the CMU sofware projects. -- Brian
Re: looking for Cyrus mail format documentation
Hello, You are correct on all counts. I was simply trying to make a point, and IMAP is the major protocol used to access the mail store, at least it is here. Nor did I mean to imply that any server that one set's up to see how things worked should be a production machine. In fact, because one would be changing things to see how they affected clients, etc. I would expect it to be a test platform. But that does now beg the question. There must be some form of coordination between the various processes as they access the mail store. Can this not be abstracted out and put in an API to make it easier for people to write their own applications? I would venture a guess to say that the API already exists in some form, it just needs to be formalized and published. Regards, Earl Shannon Rob Siemborski wrote: On Fri, 31 Jan 2003, Earl R Shannon wrote: Cyrus documentation calls the IMAP server a black box. This is defined to mean that the users do not have access to the account/data accept through the well defined ( :-/ ) IMAP protocol. This black box concept also extends to a certain extent to the administrators of the servers. Obviously the mail store access is not limited to the IMAP protocol, one can also use LMTP and POP3, and NNTP if you're using the 2.2 branch. There's also some utilities such as deliver that can let you do various things to the mail store. Best way to learn something is through experience. Set up a server and look at how it does things. If you opt for compiling it yourself choose the flat file options for all the databases. This will leave the data in a format that is human readable, sorta, and you can figure out what is going on. This is really only useful for educational purposes, not for actually running a mail store where other programs want direct access. The only way to accomplish the latter legitimately is to use the cyrus source directly. Often times mailbox access semantics change slightly from version to version, and if you're not using all the same code (which assumes it is only dealing with one version of itself), then you can run into trouble. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Per-Domain-Quota in 2.2 with virtual domains turned on ?
Christian Schulte wrote: Ken Murchison wrote: I just committed support for per-domain quotas which works for all domains except for the default domain (the code to make it work for the default domain would be particularly crufty). To set a domain quota, do something like the following in cyradm: sq @domain.tld 1024 To try this out, either do an update from CVS or apply the following (relatively small) patches: http://bugzilla.andrew.cmu.edu/cvsweb/src/cyrus/imap/mailbox.c.diff?r1=1.134.4.14r2=1.134.4.15 http://bugzilla.andrew.cmu.edu/cvsweb/src/cyrus/imap/mboxlist.c.diff?r1=1.198.2.29r2=1.198.2.30 Sorry for not answering a longer time. I did not have the time to concentrate on cyrus the last days. I just updated from cvs and started looking at the domain quota. Could it be that the quota binary does not support the -f option for virtdomains correctly ? For me quota does not report anything for mailboxes for which cyradm displays data and so I think quota cannot fix also ?! I'm certain that I forgot to look at the quota program when I added the domain quota stuff. Its also possible that the quota program is broken w.r.t virtdomains in general. I'll look at it soon. Actually I wrote a patch last night to get rid of mkimap -d! I added a new switch to imap/imapoptions which is called virtdomains_autoconfig and defaults to disabled. If enabled the function mailbox_create() in mailbox.c creates the configdirectory/domain/d/domain/... and the sievedir/domain/d/domain/ directories if compiled with USE_SIEVE and if the domain does not already exist. I'l have to talk to Rob and Larry again, but I think that if we're interested in creating the directories on the fly, we'd want to do them as needed (create just what we need now, not the entire tree) and do this regardless of whether we're using virtdomains. Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: looking for Cyrus mail format documentation
On Fri, 31 Jan 2003, Earl R Shannon wrote: But that does now beg the question. There must be some form of coordination between the various processes as they access the mail store. Can this not be abstracted out and put in an API to make it easier for people to write their own applications? I would venture a guess to say that the API already exists in some form, it just needs to be formalized and published. Of course there is. Its (mostly) localized within libimap.a, and the headers that go along with that library. I still don't recommend this to someone who just wants to get their applications to play nice with cyrus though, the externally defined protocols and applications are much more well defined than the contents of libimap.a ever will be (since changing external APIs is generally consdiered bad form ;). If someone wants to do work to document the internal API, I'd love to see it. I suspect the best way to do this would be to further comment all the stuff in the header files directly, since documentation maintained separatly is likely to go out of date. Perhaps a general overview could go in doc/internal. Actually, we've been talking for a while about refactoring the mboxlist API, since its grown in somewhat unsightly ways (especially with the murder code). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
cyradm: Login failed: generic failure at ... Cyrus/IMAP/Admin.pm
Hi,
still having troubles with cyrus!
MAJOR PROBLEM : I cannot set up mailboxes.
Getting access to cyrus gives me:
# cyradm --user cyrus --auth login localhost
IMAP Password:
Login failed: generic failure at
/usr/lib/perl/5.6.1/Cyrus/IMAP/Admin.pm line 114
cyradm: cannot authenticate to server with login as cyrus
This is exactly the error I get when I try --auth login. Try with --auth
plain. If that is rejected as an unworthy mech, see if cyrus-sasl was
compiled with the --enable-plain option. Failing that you can try it with
--auth CRAM-MD5.
If all of this fails, check the owner (user and group) of your sasldb2 file
(on my system, /etc/sasldb2; yours may be different). The file should be
owned by cyrus with 600 permissions. On some systems (esp. sendmail
8.12.x), the permissions may need to be 640 with the group of smmsp (or
whatever group sendmail belongs to).
Further information You may need:
imtest checks fails?
helium:~# imtest -u cyrus -a cyrus -p imap -m login -v localhost
S: * OK helium Cyrus IMAP4 v2.1.11 server ready
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS
NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT
THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE AUTH=OTP AUTH=DIGEST-MD5
AUTH=CRAM-MD5
S: C01 OK Completed
Please enter your password:
C: L01 LOGIN cyrus {7}
S: + go ahead
C: omitted
S: L01 NO Login failed: generic failure
Authentication failed. generic failure
Security strength factor: 0
. logout
* BYE LOGOUT received
. OK Completed
Connection closed.
and /v/l/syslog gives:
Jan 31 14:15:01 helium imapd[20345]: badlogin: localhost[127.0.0.1]
plaintext cyrus SASL(-1): generic failure: checkpass failed
Though I have set passwords for cyrus :
helium:~# sasldblistusers2
cyrus@helium: userPassword
[EMAIL PROTECTED]: userPassword
cyrus@localhost: cmusaslsecretOTP
cyrus@helium: cmusaslsecretOTP
[EMAIL PROTECTED]: cmusaslsecretOTP
cyrus@localhost: userPassword
/etc/imapd.conf:
configdirectory: /var/lib/cyrus
defaultpartition: default
partition-default: /var/spool/cyrus/mail
partition-news: /var/spool/cyrus/news
newsspool: /var/spool/news
admins: cyrus
imap_admins: cyrus
sasl_pwcheck_method: saslauthd
allowplaintext: yes
allowanonymouslogin: no
popminpoll: 1
umask: 077
PLEASE HELP!
Re: looking for Cyrus mail format documentation
Earl R Shannon wrote: But that does now beg the question. There must be some form of coordination between the various processes as they access the mail store. Can this not be abstracted out and put in an API to make it easier for people to write their own applications? I would venture a guess to say that the API already exists in some form, it just needs to be formalized and published. The point is if you expose the internal API for accessing the mailstore you are stuck with it and can't make changes. I can't imagine there is a big need for this or other people wanting to write code to implement that API, so if you really want to do this it is probably better as Rob suggested to just link to the Cyrus code that manipulates it (and watch for version skew between programs accessing the mail store). -- John A. Tamplin Unix System Administrator Emory University, School of Public Health +1 404/727-9931
Re: looking for Cyrus mail format documentation
On Fri, 31 Jan 2003, John Alton Tamplin wrote: The point is if you expose the internal API for accessing the mailstore you are stuck with it and can't make changes. I can't imagine there is a big need for this or other people wanting to write code to implement that API, so if you really want to do this it is probably better as Rob suggested to just link to the Cyrus code that manipulates it (and watch for version skew between programs accessing the mail store). Well, I don't recommend this for anything that isn't part of the cyrus distribution. The chance of version skew (especially in subtle ways) is very high, and certainly this isn't a good option if the library is being linked staticly. For any external program, I strongly recommend you only use the standard/provided interfaces (protocols, and deliver) and *NOT* the internal APIs. Documentation of the internal APIs is useful from a cyrus developer standpoint, but not from a usefulness to users standpoint. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: exim and cyrus
Hi.. you don't say which Exim you're using. I'd recommend at least Exim 4.12, which can use the lmtp transport to the unix domain socket Cyrus lmtpd is listening on. appendfile does exactly that and misses Cyrus completely. Is your imapd a cyrus imapd? telnet to port 143 and see what it says. Matt
sendmail webmail
For some of our users webmail has replaced client-based (Netscape) email as their program of choice. We set up webmail so that our users could access their email off campus, but more and more users prefer it for on campus email. Now we have suddenly had a problem with webmail -- not sending email messages to local (on campus) addresses. Students can not send messages to other students, faculty or staff; faculty and staff can not send messages to each other or to students. We can send to off campus addresses, and (I think) we are receiving mail from all senders off campus (and on campus when sent via Netscape). Here are the last samples of messages in the maillog on Thursday (before I made the changes indicated below): --- ((The first message was sent, and was received - it is to an off campus addess)) to:name@mchsi.com, ctladdr=root (0/0), delay=00:00:03, xdelay=00:00:03, mailer=esmtp, pri=30008, relay=gateway.mchsi.com [204.127.203.150], dsn=2.0.0, stat=Sent (Message received: 20030130181112 [EMAIL PROTECTED]) alias database / etc/mail/ailases.db out of date from=root, size=8, class=0, nrcpts=1, msgid=200301301815, [EMAIL PROTECTED], relay=root@localhost SYSERR (mail): Cannot execute /usr/cyrus/bin/deliver: No such file or directory [EMAIL PROTECTED], ctladdr=root (0/0), delay=00:00:00, xdelay=00:00:00, mailer=cyrus, pri=30008, dsn=4.0.0, stat=Operating system error ((The above message was not sent, it was not received)) --- I've updated the aliases.db file, and corrected the SYSERR (mail) -- the deliver file was missing, but I renamed one called deliver.old to deliver. (Actually I compared the deliver.old file on our webmail server to the deliver file on our email server, and when they were exact, I renamed the deliver.old to deliver on the webmail server.) Should I try copying the deliver file from the working email server to the webmail server? Now the error messages are gone, but mail is still not delivered - the status is Deferred -- ((I just tried to sent this message to myself this morning)) [EMAIL PROTECTED], ctladdr=root, (0/0), delay=17:21:19, xdelay=00:00:00, mailer=cyrus, pri16251772, dsn=4.0.0, stat=Deferred The /usr/spool/mqueue directory is filling up with messages; most are system-generated messages sent to me (all stat=Deferred). Again, webmail messages sent off campus are sent and received, as indicated in the maillog file. We have two identical Linux servers: RedHat 5.1, sendmail 8.10.1, Cyrus IMAP and IMP (Horde) 2.2 for Webmail on just one. (Old I know, but it was working -- if it ain't broke don't fix it was our attitude and we were hoping to wait till summer to do a major upgrade.) One is our email server and one is our web server -- with webmail. Sendmail works fine on the email server; web pages are fine the the web server, but webmail and any email sent from within a web page does not sent to on campus email addresses. Since faculty and admins, as well as students, use Webmail from off campus, this is beginning to become a black eye for our dept. Any help would be appreciated. -- Thanks, Dan Bishop Network Administrator Baptist Bible College Springfield, MO
Murder and Backend Authentication
I'm working on getting a Murder setup and I can authenticate and pull mail directly from the backend server. However, when I try to proxy the connection I get this in /var/log/messages on the proxy/master: Jan 31 13:40:35 zeus pop3[5437]: login: SERVER[192.168.247.241] hbeatty plaintext Jan 31 13:40:35 zeus pop3[5437]: couldn't authenticate to backend server: no mechanism available Jan 31 13:40:35 zeus pop3[5437]: couldn't authenticate to backend server I get this in /var/log/imapd.log on the backend server: Jan 31 13:45:01 draco pop3[32718]: accepted connection Jan 31 13:45:01 draco master[32724]: about to exec /usr/cyrus/bin/pop3d Jan 31 13:45:01 draco master[32688]: process 32718 exited, status 0 Jan 31 13:45:01 draco pop3[32724]: executed With this in mind it would seem that when using the proxy the authentication method is different somehow. Is this correct?
Re: Conversion/Migration
On Tue, 28 Jan 2003, John A. Tamplin wrote: Rob Siemborski wrote: This really shouldn't be necessary. admins can authorize as any user (e.g. login as user cyrus with the password for them, but get rights as rjs3). Most SASL mechanisms allow this, though the regular imap LOGIN command does not. As far as I know, UW imap-utils mbxcvt can only do login (with or without TLS, so perhaps you could do client certificates and external authentication to get around it). For my purposes, it was easier just to hack saslauthd temporarily. UW imap-utils will do plain, cram-md5, login and gss. Actually, all the utils are now combined into one utility (mailutil). I modified mailutil to do proxy login (as described by Rob above) so that I can run conversion/migration while the new server is accepting new mail. -- Igor
Re: Murder and Backend Authentication
What SASL mechanism are you using between your frontend and backends? Or rather, what mechanisms are your backends advertising? -Rob On Fri, 31 Jan 2003, Hank Beatty wrote: I'm working on getting a Murder setup and I can authenticate and pull mail directly from the backend server. However, when I try to proxy the connection I get this in /var/log/messages on the proxy/master: Jan 31 13:40:35 zeus pop3[5437]: login: SERVER[192.168.247.241] hbeatty plaintext Jan 31 13:40:35 zeus pop3[5437]: couldn't authenticate to backend server: no mechanism available Jan 31 13:40:35 zeus pop3[5437]: couldn't authenticate to backend server I get this in /var/log/imapd.log on the backend server: Jan 31 13:45:01 draco pop3[32718]: accepted connection Jan 31 13:45:01 draco master[32724]: about to exec /usr/cyrus/bin/pop3d Jan 31 13:45:01 draco master[32688]: process 32718 exited, status 0 Jan 31 13:45:01 draco pop3[32724]: executed With this in mind it would seem that when using the proxy the authentication method is different somehow. Is this correct? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: exim and cyrus
On Thu, Jan 30, 2003 at 03:49:57PM +0100, Peter Burggraef wrote: I don't know, what exim and cyrus are donig. It's all explained in cyrus/doc/install-configure.html As Matt says you need to tell it use the lmtp protocol. From memory this transport is not included in exim by default, and you need to uncomment it in your Makefile. Cheers, Patrick (cyrus and exim working in harmony :-) )
Re: looking for Cyrus mail format documentation
On Fri, Jan 31, 2003 at 08:57:50AM -0500, Adam Tauno Williams wrote: | It does not use maildir. It actually can use several storage backends, flat | file to sleepcat and some others. Rumor of an SQL backend, that might be what | your looking for. SQL would be harder to do for what I'm doing. Discrete files made it easier (e.g. Maildir). That it can do several backends might make it possible to plug something else in. I could like into that. | I was also looking for documentation on SASL. That I found in | the RFCs. That's the kind of thing I'm looking for regarding | the file formats. | | SASL documentation?! There is some floating about. I love SASL, but the shreds | of documentation are universally terrible. What I need in SASL isn't nearly as involved. I may be able to plug my auth data in somewhere or convert it to LDAP or something. -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| -
Re: Murder and Backend Authentication
My conf file looks like this:
##
# Global info's
##
configdirectory: /var/imap
partition-default: /var/spool/imap
unixhierarchysep: yes
altnamespace: yes
imapidresponse: no
##
# Authentification User rights
##
admins: cyrus murderbackend murderproxy
sasl_pwcheck_method: saslauthd
allowanonymouslogin: no
sasl_mech_list: PLAIN LOGIN
# sasl_auto_transition: yes
##
# Quota Message size limit
##
quotawarn: 90
autocreatequota: 10240
# maxmessagesize: 10485760
lmtp_overquota_perm_failure: no
##
# ACL
##
defaultacl: anyone lrs
##
# Virtual Domain Support
##
virtdomains: yes
defaultdomain: starburn.net
##
# mupdate parameters
##
mupdate_authname: cyrus
mupdate_password: SuperSecretPassword :)
mupdate_port: 2004
#mupdate_realm:
mupdate_retry_delay: 20
mupdate_server: zeus.email.starband.net
mupdate_workers_start: 5
mupdate_workers_minspare: 2
mupdate_workers_maxspare: 10
mupdate_workers_max: 50
mupdate_username: cyrus
proxyservers: murderproxy
And when I use imtest:
[root@draco root]# imtest -u hbeatty -a hbeatty localhost
S: * OK draco Cyrus IMAP4 v2.2.prealpha server ready
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS
NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT
THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE
MUPDATE=mupdate://zeus.email.starband.net/
S: C01 OK Completed
Please enter your password:
C: L01 LOGIN hbeatty {4}
S: + go ahead
C: omitted
S: L01 OK User logged in
Authenticated.
Security strength factor: 0
- Original Message -
From: Rob Siemborski [EMAIL PROTECTED]
To: Hank Beatty [EMAIL PROTECTED]
Cc: Cyrus-Info [EMAIL PROTECTED]
Sent: Friday, January 31, 2003 2:29 PM
Subject: Re: Murder and Backend Authentication
What SASL mechanism are you using between your frontend and backends?
Or rather, what mechanisms are your backends advertising?
-Rob
On Fri, 31 Jan 2003, Hank Beatty wrote:
I'm working on getting a Murder setup and I can authenticate and pull
mail
directly from the backend server.
However, when I try to proxy the connection I get this in
/var/log/messages
on the proxy/master:
Jan 31 13:40:35 zeus pop3[5437]: login: SERVER[192.168.247.241] hbeatty
plaintext
Jan 31 13:40:35 zeus pop3[5437]: couldn't authenticate to backend
server: no
mechanism available
Jan 31 13:40:35 zeus pop3[5437]: couldn't authenticate to backend server
I get this in /var/log/imapd.log on the backend server:
Jan 31 13:45:01 draco pop3[32718]: accepted connection
Jan 31 13:45:01 draco master[32724]: about to exec /usr/cyrus/bin/pop3d
Jan 31 13:45:01 draco master[32688]: process 32718 exited, status 0
Jan 31 13:45:01 draco pop3[32724]: executed
With this in mind it would seem that when using the proxy the
authentication
method is different somehow. Is this correct?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
cyradm
I'm having a little trouble with the cyradm tool, firstly I'd like to point out that I'm only running Cyrus in a lab am not that familiar at this point. I'm authenticating using saslauthd -a pam, everything is working fine from an imap perspective, only imaps, using local acccounts, it's running on Redhat. Only issue is the cyradm tool won't connect to the local server. I've tried, using the --auth switch with a whole load of permutations, unix,plain,pam,saslauth, tha man pages lists --auth[mechanism] without specifying the mechs explicitly. My account is listed as an admin in /etc/imap.conf, put an entry in /etc/saslauthdb2 just in case, but am still having difficulties. A quick rundown of how what against this tool auths against would be most helpfull. Thanks up front apologies if this question's a little low-brow. Daryl
Re: Per-Domain-Quota in 2.2 with virtual domains turned on ?
Ken Murchison wrote: I'l have to talk to Rob and Larry again, but I think that if we're interested in creating the directories on the fly, we'd want to do them as needed (create just what we need now, not the entire tree) and do this regardless of whether we're using virtdomains. mkimap should only be necessary for installing the cyrus system, I think. Without virtdomains one does mkimap exactly one times for installing purposes and does not need it ever again. Administration can completely be done with nearly every IMAP-client. With virtdomains this should work also, I think but does notI cannot administer cyrus only with an IMAP-client if using virtdomains and that was something I needed... --Christian--
Re: Murder and Backend Authentication
You aren't offering any SASL mechanisms. I believe the 2.2 code even
supports STARTTLS (and therefore PLAIN).
You need to support a SASL mechanism that allows proxy authentication.
The regular IMAP login command isn't good enough.
-Rob
On Fri, 31 Jan 2003, Hank Beatty wrote:
And when I use imtest:
[root@draco root]# imtest -u hbeatty -a hbeatty localhost
S: * OK draco Cyrus IMAP4 v2.2.prealpha server ready
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS
NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT
THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE
MUPDATE=mupdate://zeus.email.starband.net/
S: C01 OK Completed
Please enter your password:
C: L01 LOGIN hbeatty {4}
S: + go ahead
C: omitted
S: L01 OK User logged in
Authenticated.
Security strength factor: 0
- Original Message -
From: Rob Siemborski [EMAIL PROTECTED]
To: Hank Beatty [EMAIL PROTECTED]
Cc: Cyrus-Info [EMAIL PROTECTED]
Sent: Friday, January 31, 2003 2:29 PM
Subject: Re: Murder and Backend Authentication
What SASL mechanism are you using between your frontend and backends?
Or rather, what mechanisms are your backends advertising?
-Rob
On Fri, 31 Jan 2003, Hank Beatty wrote:
I'm working on getting a Murder setup and I can authenticate and pull
mail
directly from the backend server.
However, when I try to proxy the connection I get this in
/var/log/messages
on the proxy/master:
Jan 31 13:40:35 zeus pop3[5437]: login: SERVER[192.168.247.241] hbeatty
plaintext
Jan 31 13:40:35 zeus pop3[5437]: couldn't authenticate to backend
server: no
mechanism available
Jan 31 13:40:35 zeus pop3[5437]: couldn't authenticate to backend server
I get this in /var/log/imapd.log on the backend server:
Jan 31 13:45:01 draco pop3[32718]: accepted connection
Jan 31 13:45:01 draco master[32724]: about to exec /usr/cyrus/bin/pop3d
Jan 31 13:45:01 draco master[32688]: process 32718 exited, status 0
Jan 31 13:45:01 draco pop3[32724]: executed
With this in mind it would seem that when using the proxy the
authentication
method is different somehow. Is this correct?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
Cyrus SASL 2.1.11 Released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'd like to announce the release of Cyrus SASL 2.1.11 on ftp.andrew.cmu.edu. This version is primarily a bug-fix release. Specifically, it addresses a number of issues in the build system, a memory leak in the doors IPC method for saslauthd, and fixes the NTLM server side support to only require one of the LM or NT methods. I'd like to thank all the contributors and bug reporters that worked on this release, especially Jeremy Rumpf, Igor Brezac, Simon Brady, and Ken Murchison. Please send any feedback either to [EMAIL PROTECTED] (public list) or to [EMAIL PROTECTED] Development issues can also be addressed on [EMAIL PROTECTED] - -Rob - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 Comment: Made with pgp4pine 1.76 iQA/AwUBPjrcLWes8cJc4y/MEQJOfwCg7LvdDUkwcXwLn07aROwg5CqULhQAn3nY KlF24b4fit8jFN3G38RkmrCg =Fzfk -END PGP SIGNATURE-
Cyrus SASL 2.1.11 Release URL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apologies, the URL for the distribution was not included in the previous announcement. The URL for the Cyrus SASL 2.1.11 release is: ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-sasl-2.1.11.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-sasl-2.1.11.tar.gz - -Rob - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 Comment: Made with pgp4pine 1.76 iQA/AwUBPjrclWes8cJc4y/MEQLm5QCeKnEt+dWsO6DtIQDc7fxoM3UpcfYAn0nn Rwio0qkEHqJX5WBf+H2cYHlj =fdbz -END PGP SIGNATURE-
Re: Murder and Backend Authentication
PLAIN is your only choice (so you'll need to be sure you can get a TLS
layer between the frontend and backend). Like I said, I believe 2.2 has
this code. I know 2.1 does not.
-Rob
On Fri, 31 Jan 2003, Hank Beatty wrote:
OK. That makes sense. Are there any SASL mechs that can use PAM?
- Original Message -
From: Rob Siemborski [EMAIL PROTECTED]
To: Hank Beatty [EMAIL PROTECTED]
Cc: Cyrus-Info [EMAIL PROTECTED]
Sent: Friday, January 31, 2003 3:18 PM
Subject: Re: Murder and Backend Authentication
You aren't offering any SASL mechanisms. I believe the 2.2 code even
supports STARTTLS (and therefore PLAIN).
You need to support a SASL mechanism that allows proxy authentication.
The regular IMAP login command isn't good enough.
-Rob
On Fri, 31 Jan 2003, Hank Beatty wrote:
And when I use imtest:
[root@draco root]# imtest -u hbeatty -a hbeatty localhost
S: * OK draco Cyrus IMAP4 v2.2.prealpha server ready
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS
NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT
THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE
MUPDATE=mupdate://zeus.email.starband.net/
S: C01 OK Completed
Please enter your password:
C: L01 LOGIN hbeatty {4}
S: + go ahead
C: omitted
S: L01 OK User logged in
Authenticated.
Security strength factor: 0
- Original Message -
From: Rob Siemborski [EMAIL PROTECTED]
To: Hank Beatty [EMAIL PROTECTED]
Cc: Cyrus-Info [EMAIL PROTECTED]
Sent: Friday, January 31, 2003 2:29 PM
Subject: Re: Murder and Backend Authentication
What SASL mechanism are you using between your frontend and backends?
Or rather, what mechanisms are your backends advertising?
-Rob
On Fri, 31 Jan 2003, Hank Beatty wrote:
I'm working on getting a Murder setup and I can authenticate and
pull
mail
directly from the backend server.
However, when I try to proxy the connection I get this in
/var/log/messages
on the proxy/master:
Jan 31 13:40:35 zeus pop3[5437]: login: SERVER[192.168.247.241]
hbeatty
plaintext
Jan 31 13:40:35 zeus pop3[5437]: couldn't authenticate to backend
server: no
mechanism available
Jan 31 13:40:35 zeus pop3[5437]: couldn't authenticate to backend
server
I get this in /var/log/imapd.log on the backend server:
Jan 31 13:45:01 draco pop3[32718]: accepted connection
Jan 31 13:45:01 draco master[32724]: about to exec
/usr/cyrus/bin/pop3d
Jan 31 13:45:01 draco master[32688]: process 32718 exited, status 0
Jan 31 13:45:01 draco pop3[32724]: executed
With this in mind it would seem that when using the proxy the
authentication
method is different somehow. Is this correct?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
Re: Murder and Backend Authentication
OK. That makes sense. Are there any SASL mechs that can use PAM?
- Original Message -
From: Rob Siemborski [EMAIL PROTECTED]
To: Hank Beatty [EMAIL PROTECTED]
Cc: Cyrus-Info [EMAIL PROTECTED]
Sent: Friday, January 31, 2003 3:18 PM
Subject: Re: Murder and Backend Authentication
You aren't offering any SASL mechanisms. I believe the 2.2 code even
supports STARTTLS (and therefore PLAIN).
You need to support a SASL mechanism that allows proxy authentication.
The regular IMAP login command isn't good enough.
-Rob
On Fri, 31 Jan 2003, Hank Beatty wrote:
And when I use imtest:
[root@draco root]# imtest -u hbeatty -a hbeatty localhost
S: * OK draco Cyrus IMAP4 v2.2.prealpha server ready
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS
NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT
THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE
MUPDATE=mupdate://zeus.email.starband.net/
S: C01 OK Completed
Please enter your password:
C: L01 LOGIN hbeatty {4}
S: + go ahead
C: omitted
S: L01 OK User logged in
Authenticated.
Security strength factor: 0
- Original Message -
From: Rob Siemborski [EMAIL PROTECTED]
To: Hank Beatty [EMAIL PROTECTED]
Cc: Cyrus-Info [EMAIL PROTECTED]
Sent: Friday, January 31, 2003 2:29 PM
Subject: Re: Murder and Backend Authentication
What SASL mechanism are you using between your frontend and backends?
Or rather, what mechanisms are your backends advertising?
-Rob
On Fri, 31 Jan 2003, Hank Beatty wrote:
I'm working on getting a Murder setup and I can authenticate and
pull
mail
directly from the backend server.
However, when I try to proxy the connection I get this in
/var/log/messages
on the proxy/master:
Jan 31 13:40:35 zeus pop3[5437]: login: SERVER[192.168.247.241]
hbeatty
plaintext
Jan 31 13:40:35 zeus pop3[5437]: couldn't authenticate to backend
server: no
mechanism available
Jan 31 13:40:35 zeus pop3[5437]: couldn't authenticate to backend
server
I get this in /var/log/imapd.log on the backend server:
Jan 31 13:45:01 draco pop3[32718]: accepted connection
Jan 31 13:45:01 draco master[32724]: about to exec
/usr/cyrus/bin/pop3d
Jan 31 13:45:01 draco master[32688]: process 32718 exited, status 0
Jan 31 13:45:01 draco pop3[32724]: executed
With this in mind it would seem that when using the proxy the
authentication
method is different somehow. Is this correct?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
Re: Per-Domain-Quota in 2.2 with virtual domains turned on ?
Christian Schulte wrote: Ken Murchison wrote: I'l have to talk to Rob and Larry again, but I think that if we're interested in creating the directories on the fly, we'd want to do them as needed (create just what we need now, not the entire tree) and do this regardless of whether we're using virtdomains. mkimap should only be necessary for installing the cyrus system, I think. Without virtdomains one does mkimap exactly one times for installing purposes and does not need it ever again. Administration can completely be done with nearly every IMAP-client. With virtdomains this should work also, I think but does notI cannot administer cyrus only with an IMAP-client if using virtdomains and that was something I needed... My point is (and I _think_ Rob agrees) is that mkimap shouldn't be needed at all. If we try to create a file whose parent directories don't exist, we just create them on the fly. This means that if you don't have any users whose userid hashes to 'x', then this directory will never be created. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: Murder and Backend Authentication
On Fri, 31 Jan 2003, Ken Murchison wrote: Like Rob said, just PLAIN, which will require you to use STARTTLS, which is only in 2.2. That being said, since you will likely only have one or two proxy admins, you could just put them in sasldb2 and use DIGEST-MD5. This may break some clients, since they may then try to authenticate using DIGEST-MD5 to the backend (Say, via a referral), and then get upset when they can't. You really want a uniform authentication enviornment for the aggregator. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Murder and Backend Authentication
Hank Beatty wrote:
OK. That makes sense. Are there any SASL mechs that can use PAM?
Like Rob said, just PLAIN, which will require you to use STARTTLS, which
is only in 2.2. That being said, since you will likely only have one or
two proxy admins, you could just put them in sasldb2 and use DIGEST-MD5.
- Original Message -
From: Rob Siemborski [EMAIL PROTECTED]
To: Hank Beatty [EMAIL PROTECTED]
Cc: Cyrus-Info [EMAIL PROTECTED]
Sent: Friday, January 31, 2003 3:18 PM
Subject: Re: Murder and Backend Authentication
You aren't offering any SASL mechanisms. I believe the 2.2 code even
supports STARTTLS (and therefore PLAIN).
You need to support a SASL mechanism that allows proxy authentication.
The regular IMAP login command isn't good enough.
-Rob
On Fri, 31 Jan 2003, Hank Beatty wrote:
And when I use imtest:
[root@draco root]# imtest -u hbeatty -a hbeatty localhost
S: * OK draco Cyrus IMAP4 v2.2.prealpha server ready
C: C01 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS
NAMESPACE UIDPLUS ID NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND SORT
THREAD=ORDEREDSUBJECT THREAD=REFERENCES IDLE
MUPDATE=mupdate://zeus.email.starband.net/
S: C01 OK Completed
Please enter your password:
C: L01 LOGIN hbeatty {4}
S: + go ahead
C: omitted
S: L01 OK User logged in
Authenticated.
Security strength factor: 0
- Original Message -
From: Rob Siemborski [EMAIL PROTECTED]
To: Hank Beatty [EMAIL PROTECTED]
Cc: Cyrus-Info [EMAIL PROTECTED]
Sent: Friday, January 31, 2003 2:29 PM
Subject: Re: Murder and Backend Authentication
What SASL mechanism are you using between your frontend and backends?
Or rather, what mechanisms are your backends advertising?
-Rob
On Fri, 31 Jan 2003, Hank Beatty wrote:
I'm working on getting a Murder setup and I can authenticate and
pull
mail
directly from the backend server.
However, when I try to proxy the connection I get this in
/var/log/messages
on the proxy/master:
Jan 31 13:40:35 zeus pop3[5437]: login: SERVER[192.168.247.241]
hbeatty
plaintext
Jan 31 13:40:35 zeus pop3[5437]: couldn't authenticate to backend
server: no
mechanism available
Jan 31 13:40:35 zeus pop3[5437]: couldn't authenticate to backend
server
I get this in /var/log/imapd.log on the backend server:
Jan 31 13:45:01 draco pop3[32718]: accepted connection
Jan 31 13:45:01 draco master[32724]: about to exec
/usr/cyrus/bin/pop3d
Jan 31 13:45:01 draco master[32688]: process 32718 exited, status 0
Jan 31 13:45:01 draco pop3[32724]: executed
With this in mind it would seem that when using the proxy the
authentication
method is different somehow. Is this correct?
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
imapd's hang when maxchild count is reached
Hi, we are currently testing our installation of cyrus-imapd 2.1.11 using a self-written Perl script that's imitating real use. We intend to contribute the script when we've cleaned it up a little. Anyway, during our tests we noticed something strange. In /etc/cyrus.conf we have the line: imap cmd=imapd listen=cyrus.rrz.uni-koeln.de:imap prefork=10 maxchild=200 When the number of impad processes reaches 200, no more processes are spawned, just as it should be. However, sometimes, not immediately, but definitely after a while *all* imapd processes will hang if we try to open more connections to port 143. This is 100% reproducible. If we kill one of the scripts and the number of processes goes down, all the imapd's get unstuck, but not until that happens. I've checked the archives but haven't seen mention of this problem. Is this a known issue? Is there a workaround? This is on Red Hat Advanced Server 2.1: cyrus.rrz.uni-koeln.de ver name : Cyrus IMAPD version: v2.1.11-Invoca-RPM-2.1.11-16 2002/12/04 14:53:12 vendor : Project Cyrus support-url: http://asg.web.cmu.edu/cyrus os : Linux os-version : 2.4.9-e.10enterprise environment: Cyrus SASL 2.1.10 Sleepycat Software: Berkeley DB 4.0.14: (November 18, 2001) OpenSSL 0.9.6b [engine] 9 Jul 2001 CMU Sieve 2.2 TCP Wrappers mmap = shared lock = fcntl nonblock = fcntl auth = unix idle = poll dirhash = full mboxlist.db = skiplist subs.db = flat seen.db = skiplist duplicate.db = db3-nosync tls.db = db3-nosync -- Sebastian Hagedorn M.A. - RZKR-R1 (Flachbau), Zi. 18, Robert-Koch-Str. 10 Zentrum für angewandte Informatik - Universitätsweiter Service RRZK Universität zu Köln / Cologne University - Tel. +49-221-478-5587 msg10764/pgp0.pgp Description: PGP signature
Re: Murder and Backend Authentication
On Fri, 31 Jan 2003, Eric S. Pulley wrote: Sorry if this is just obvious but... Everyone keep stating that STARTTLS is not supported in 2.1.x I'm assuming that it just doesn't work for the Backend Authentication in a Murder since I'm using it to connect to my standalone server just fine. Or do I have something very worng going on here? Yes, that's roughly correct. All the server-side STARTTLS code is implemented. However, the proxys do not have code to make use of STARTTLS when they connect to the backend, so STARTTLS isn't an option for proxy-backend authentication (not client-proxy or client-backend authentication, that works fine) in 2.1. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
ctl_deliver not finishing
I'm having a bit of a problem on our IMAP server. There are several instances of ctl_deliver, some running for over 2 days. # ps -ef|grep deliver cyrus 331 303 27 Jan 29 ? 2671:33 ctl_deliver -E 3 cyrus 6736 303 26 12:48:32 ? 112:04 ctl_deliver -E 3 cyrus 2647 303 27 Jan 30 ? 1281:16 ctl_deliver -E 3 Looking at /var/adm/messages, process 331 generated the following error: Jan 29 12:48:40 ix ctl_deliver[331]: DBERROR db4: DB_ENV-log_flush: LSN past current end-of-log The system is Solaris 5.7, cyrus-imapd-2.1.5, cyrus-sasl-2.1.5, db-4.0.14 Any idea on recovering the problem gracefully? What might be causing it, and any fixes? Thanks -B -- Brandon High [EMAIL PROTECTED] Epinions, Inc. Unix System Administrator He who laughs last thinks slowest.
Re: looking for Cyrus mail format documentation
On Fri, Jan 31, 2003 at 09:57:40AM -0500, John Alton Tamplin wrote: | Earl R Shannon wrote: | | But that does now beg the question. There must be some form of | coordination between the various processes as they access the | mail store. Can this not be abstracted out and put in an API to | make it easier for people to write their own applications? I would | venture a guess to say that the API already exists in some form, | it just needs to be formalized and published. | | The point is if you expose the internal API for accessing the mailstore | you are stuck with it and can't make changes. I can't imagine there is | a big need for this or other people wanting to write code to implement | that API, so if you really want to do this it is probably better as Rob | suggested to just link to the Cyrus code that manipulates it (and watch | for version skew between programs accessing the mail store). One of the needs I have is to build a two-way mail store replica. Either node may be delivered to, and either node may be accessed by the user but only one at a time. The two nodes are topologically and geographically far apart, and bandwidth between them is to be considered costly and thus should be not much more than the cost of actually transferring content. If mail arrives at one, it should be replicated to the other ASAP. If mail is deleted at one, it should be deleted from the other ASAP. If mail is moved around between folders unchanged, it should be moved the same on the other without transferring content. Now here is the big one: If the two nodes are unreachable between each other, changes have to be stored in a way they can be re-syncronized when reachability is again established. And this may involve some changes to both and some issues that have to be dealt with as best as possible such as noting dates of changes (it can be assumed the two nodes are time syncronized). This is one of needs I have. -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| -
Re: cyradm: Login failed: generic failure at ...Cyrus/IMAP/Admin.pm
On Fri, 31 Jan 2003 14:14:53 +0100 Dennis Leist [EMAIL PROTECTED] wrote: # cyradm --user cyrus --auth login localhost IMAP Password: Login failed: generic failure at /usr/lib/perl/5.6.1/Cyrus/IMAP/Admin.pm line 114 cyradm: cannot authenticate to server with login as cyrus (snip) sasl_pwcheck_method: saslauthd In this configuration, PLAIN and LOGIN authentications use saslauthd instead of sasldb. Are you running saslauthd? -- Happy Go Lucky! OBATA Akio / [EMAIL PROTECTED]
Re: looking for Cyrus mail format documentation
Phil Howard wrote: One of the needs I have is to build a two-way mail store replica. Either node may be delivered to, and either node may be accessed by the user but only one at a time. The two nodes are topologically and geographically far apart, and bandwidth between them is to be considered costly and thus should be not much more than the cost of actually transferring content. If mail arrives at one, it should be replicated to the other ASAP. If mail is deleted at one, it should be deleted from the other ASAP. If mail is moved around between folders unchanged, it should be moved the same on the other without transferring content. Now here is the big one: If the two nodes are unreachable between each other, changes have to be stored in a way they can be re-syncronized when reachability is again established. And this may involve some changes to both and some issues that have to be dealt with as best as possible such as noting dates of changes (it can be assumed the two nodes are time syncronized). This is one of needs I have. Then I would suggest a better way of doing that than trying to figure out what changes have happened by looking at low-level data structures would be to put proxies in front of Cyrus (LMTP, IMAP, and if you use it POP). The proxies would pass the data on to the local Cyrus to do the action as well as contacting the other proxy to duplicate the work. If the other proxy is not accessible, keep a log of the work that needs to be performed (but allowing disconnected operation when the other node is not truly down will likely lead to changes that can't be automatically resolved -- better would be to have 3, run two-phase commit and only commit if you get agreement of two, but that may not be practical) and do those changes when the other proxy comes back up. The level of abstraction you want is precisely the level you get at the higher level protocols rather than having to dig through all the folders and see what has changed. Of course replicating some things such as seen state will be quite painful, and you may need to do some hacks to keep uids unique between the machines. -- John A. Tamplin Unix Systems Administrator
Re: looking for Cyrus mail format documentation
On Fri, Jan 31, 2003 at 08:33:41PM -0500, John A. Tamplin wrote: | Phil Howard wrote: | | One of the needs I have is to build a two-way mail store replica. Either | node may be delivered to, and either node may be accessed by the user but | only one at a time. The two nodes are topologically and geographically | far apart, and bandwidth between them is to be considered costly and thus | should be not much more than the cost of actually transferring content. | If mail arrives at one, it should be replicated to the other ASAP. If | mail is deleted at one, it should be deleted from the other ASAP. If | mail is moved around between folders unchanged, it should be moved the | same on the other without transferring content. Now here is the big one: | If the two nodes are unreachable between each other, changes have to be | stored in a way they can be re-syncronized when reachability is again | established. And this may involve some changes to both and some issues | that have to be dealt with as best as possible such as noting dates of | changes (it can be assumed the two nodes are time syncronized). | | This is one of needs I have. | | Then I would suggest a better way of doing that than trying to figure | out what changes have happened by looking at low-level data structures | would be to put proxies in front of Cyrus (LMTP, IMAP, and if you use it | POP). The proxies would pass the data on to the local Cyrus to do the | action as well as contacting the other proxy to duplicate the work. If | the other proxy is not accessible, keep a log of the work that needs to | be performed (but allowing disconnected operation when the other node is | not truly down will likely lead to changes that can't be automatically | resolved -- better would be to have 3, run two-phase commit and only | commit if you get agreement of two, but that may not be practical) and | do those changes when the other proxy comes back up. The level of | abstraction you want is precisely the level you get at the higher level | protocols rather than having to dig through all the folders and see what | has changed. If by proxy in from of Cyrus you mean to implement a layer of IMAP that is connected to by clients, and then connected to Cyrus on some hidden port, then I'd say that's not really practical. That would mean doing an implementation of IMAP, and it is things like this that I was trying to avoid in the first place. I might as well just directly access the files, and hence have my own IMAP implementation. But it's to avoid this that I get so many suggestions to use Cyrus (or Courier) instead. Doing the syncronizing at the filesystem later won't be too hard, although a few hacks are needed (for example deletes are saved as an empty file with zero permissions, dated when the delete happened, until after the syncronization clears it everywhere). | Of course replicating some things such as seen state will be quite | painful, and you may need to do some hacks to keep uids unique between | the machines. How does Cyrus manage uids? I hope these are not uids in /etc/passwd. -- - | Phil Howard - KA9WGN | Dallas | http://linuxhomepage.com/ | | [EMAIL PROTECTED] | Texas, USA | http://ka9wgn.ham.org/| -
